６月１日からダイエットを始めて、苦節5ヵ月、遂に目標の71.5kgを達成した。(´・ω・`)
ピークから計算すると５ヵ月で9kgの減量というわけだ。長かった……。
が、実際の所、その時にお腹の中に何が入っているかで1～2kgくらい動いてしまうから、ちょっと何か食べたらすぐに73kgになってしまうだろう。
本当の目標は71.5～72.5kgの維持、平均体重72kgの維持を目指したい。
当然、リバウンドにも警戒しなければならないから、今すぐ元のような食生活に戻るわけではない。
しかし、ここが一つの節目だな。
今後は久しぶりにラーメンとか食べて行ける身分に戻りたい。
いや、まずは天ぷら蕎麦かな。
何にせよ、やれやれだぜ。(´・ω・`)
設計フェーズ完了。今日からテスト開始ということになっているんだけど。
これはやり過ぎだろう。(#´^ω^`)
試験の結果、処理が一部抜けていることが見つかった、とかそのくらいならザラにあるけどよ～。
機能一覧から丸抜けしている。しかも１つや２つじゃねえ。４機能丸抜け。
これが設計完了100%のシロモノかね。
僕も機能の辻褄が合わないことは指摘していたけど、これほど巨大に欠落しているとは思わなかった。
１０月末の期日に向けてもう実装完了に向わなきゃいけないのに、４機能追加はちょっと厳しいぞ……。
間に合わへんちゅ～の。(´・ω・`)
うげっ……。(；´-ω-`)
設計の矛盾を多数指摘したら、「処理が抜けていました」とかで、バッチが２本追加。
そのうち１本は重い。(；´-ω-`)
これは設計完了じゃないんだって。設計書のレビュー中の間違いでしょ。
指摘するほど自分の仕事が増えていく。
しかし指摘しないわけにもいかない、という……。(；´-ω-`)
休日労働中。(´・ω・`)
完成度１００％の設計書を見ながら実装してるんだけど、う～ん。
分かんないよ、これ。空白だもん。エクセルに着色しているだけ。これが完成度１００％かね？
まあ、僕はこれでも一応、ハイスキルエンジニアというポジションにあるから、設計書に空白が目立っても要件や処理の前後関係から本来そこに埋まっているべき記述が何なのかを手繰り寄せるくらいのことはやるんだが。
それでも分かんない部分はある。能力の限界。
だから問い合わせは送ってるんだけど、返事ゼロ。
月曜から実装と並行してテスト開始とか言ってるけど、僕が問い合わせしている設計書の指摘事項３０コを返信してからテスト開始だよね？
そりゃそうだろう。設計書のレビュー指摘事項修正よりも試験開始が優先なんてありえないじゃん。
つまるところ、デタラメで良いなら進捗は進められるのよ。
結合テストに着手すれば、それは予定通りの日付で着手だ。
しかし、必ず結合テストの過程で意味不明になって、結合テスト期間に膨大な設計書修正作業、ソース修正作業が発生する。
結合テストフェーズで設計書の加筆をすることになるんだ。
これをデタラメと言う。
ふざけんなよ、本当に！！
ここでやっかいなのが、こんな状況でも「設計チームがデタラメなのが悪いんだ！！」みたいな姿勢は取れない、ということ。
それは一山いくらの馬の骨のプログラマーの対応策。僕はハイスキルエンジニア、上級職という位置付けだから、幅広い手厚いフォローアップが伴わないと肩書に即さなくなってくる。
しかし、問題の連中はデタラメやってる自覚も無い。自覚が無い人間ほど御し難いものは無いわけで。
自覚さえあれば僕が介入することが出来るんだが、
(・ω・)「オンスケですが何か？」
みたいなぽや～んとした輩に介入すると、逆に僕が悪者になるリスクがある。
どうしたら良いもんか、くそっ。
やれやれやれやれ、やっとやってくれたか。(´・ω・`)
日本人にとって皇族というのは特殊なものであるから、その皇族の一人を伴侶に迎えたこの小室圭という庶民が、果たしてその重責に相応しい人材であるかどうか。
そこは何とも評価が難しくて、僕には到底分からん雲の上レベルである。
しかし、難しい話とは言え、無職やフリーターも同然ではいくら何でもちょっと……という感はあった。
眞子様が生活苦に喘ぐとか、イメージもしたくないんだよ！！
プリンセスなんやで！！
しかし、旦那がNY司法試験に合格したことで、何とか面目が立ったな。
これで何とか「ニュースを聞いている国民の方が居たたまれない」という事態はクリアだろう。
僕もホッとしたわ、やれやれやれやれ。。。
しかしこの小室圭という男、何とも胡散臭さが先立っていたけど、司法試験合格でそれも解消に向かうか？
NY司法試験合格ってからには、日本の普通の弁護士よりも上級くらいのランク感あるじゃない？
外国の法律を英語で理解しているってことなんだから。
完全無欠の天才とまでは言えないだろうけど、僕の身近にはいないくらいの秀才だってのは本当なんだろうな。
とにかく、やれやれやれやれ。。。
今後はこの勢いで輝かしいエリート街道を進んで欲しい。
ケチが付いた話なんか聞きたくない。
ディズニーの王子様路線で頼むわ、本当に。
国民の夢を代行しとるんやで。(´・ω・`)
状況を問い質してみたら、返事は「一日遅れ」だった。(´・ω・`)
マズいなぁ。そんなはずがないんだよ。
僕の見立てだと一週間遅れている。(；´・ω・`)
どうして見通しの見解に差が生まれるかと言うと、作業を忘れているからだ。
現時点においては、本気で一日遅れだと思っている。
しかし、来週になると、
(; ﾟДﾟ)「あっ、これ忘れてた」
(; ﾟДﾟ)「あっ、これもやらなきゃ」
(; ﾟДﾟ)「えっ、これ重い」
みたいに気が付く。そうなるのが目に見えている。
だが、現時点においては気付いていない。参ったな～。
この手の「自覚無き者」への対処は実に難しい。
無論、見通しが間違っている事を一つ一つ説明することは可能であるが、僕はそれは悪手だと思うんだよなぁ。
現時点において自覚していないのであれば、それをくどくど説明しても煙たがられるだけだ。
(# ﾟДﾟ)「うるさいなぁ。ウズのおっちゃんは」
みたいな感じにしか聞こえないだろう。
困り果て、泣きが入った時でなければ、他人は他人の意見を聞かない。
これが世の中の真実。
( ；Д；)「どうしたら良いんでしょう、ウズさん？」
と、この藁をも掴む思いになるまで待たねばならん。
そうなって初めて人は僕の言う事を聞く。
だが、そこまで待ってるとダメージも大きくなるのも事実であり……。
どうすっかな～。
とりあえず、みんなが見える場所で軽く忠告を入れておくか。軽くね、軽く。
「ああ、ウズさんはもっと前から気付いてたんだな」
「だが、他の人はそれをスルーした」
という雰囲気が醸成出来れば、まあいいだろう。
プロジェクトが負うダメージ部分は、後でリカバリーする。
このプロジェクトは僕が５割増しで労働しなければ成り立たない。
だが、それをやるのは今ではない。
泣いて頼み込まれるのを待ってからでなければ、誰も僕の苦労に気付かないまま終わってしまうどころか、僕が「五月蠅い人」という扱いにされてしまうからな。
トラブってるプロジェクトでは立ち振る舞いに気を付けないと。
やる気はあるけど、悪者にされない為の計算は必要。大人の知恵やな(´・ω・`)
ちょっと実装への影響が大きい大規模の設計ミスと目される部分があって。(´・ω・`)
ミスにも「規模」があって、パラメータの設定間違いとか、小さいミスならとりあえず実装を進めて後から直せばＯＫ。
「エラー系が全面欠落」とか、こういう巨大な抜けがあると、見切り発車で実装しても全部無に帰すリスクが高い。
というわけで、昨日は指摘事項を整理して送り出し、早めに休憩した。
１０時間くらい眠って体調も随分良くなったわい。
こういう頑張っても仕方が無い時に休んで体力を回復し、戦いの時に備えておくのも大事なスキルよね。
今日はその結果が戻ってくるから、今日は頑張らないと。(´・ω・`)
僕は技術力が高いと評価されて今の地位にいるわけだが、違うって。分かって貰いたいのはそこじゃないって。(´・ω・`)
こんなデタラメの設計書を渡されてよ～。
いや、無論、プログラミングが特技であるのは本当で、実装の生産性には自信がある。でもそういう風に言われたら、まるで僕が技術オタクみたいに聞こえるじゃないか。
違うって。
デタラメの設計書を渡されて。
(；´-ω-`)「いや、おかしい。こんな設計で要件が満たされているはずがない」
と気付く。
僕は要件定義のキャッチアップが伴うプログラマーなのよ。
そして、一切説明を受けていないけど、転がっている資料を自分で探して調べて、
(´・ω・`)「設計はこうなっていますが、要件定義書にはこのように書かれています。この場合、この処理のこの部分でエラーが生じた場合、それをオペレータに通知する必要がある。従って、この部分にエラー系を実装し、ＤＢにエラーメッセージを登録する処理が必要ではありませんか？」
と問い合わせるとかさ～。
立場は確かにプログラマーだ。しかし、設計者以上に要件定義に精通し、実装工程から設計工程に情報をフィードバックすることが出来る。
プロマネの素養のあるプログラマーである、という点が最大の長所なのよ。カタワみたいなプログラマーは余ってる。各方面に理解があることが大事になるんだ。
しかし、分かるかね、このストレスが。
全部デタラメや！！
おかしいんやって、こんなことは。
こんなことやってたら本職の実装が全然進まんやろが。口先だけの実装フェーズ、実態は設計レビューが僕の仕事になっとる！！
その辺の単金いくらのプログラマーなら設計書を押し付ければそれを鵜呑みにして実装するのであろうが。
このウズマス様を騙せると思うな！！
この設計は間違っとる！！ 要件を網羅出来ているはずがない！！
叩き殺したろか！！
このプロジェクトは管理が緩くって、要は最終的に問題が起きなければ良いってだけなのよね。(´・ω・`)
しかし、本格的なプロジェクトには進捗管理というものがあり、進捗管理の中にはマイルストーン判定というものがある。
例えば、設計完了とはどういう条件を満たす事を意味するのか？
条件とは、例えば、設計書を一通り書いて、レビューを受け、レビュアーがＯＫを出す。レビュアーがＯＫした事を以て完了とする、とか。
小さなプロジェクトだとこんなもんだけど、大きいプロジェクトだとレビュー時間とか指摘件数とかの査定があって、査定チームからＯＫが出た事を以て完了する、とか。
まあ、定義は色々あるのよ。
では、このプロジェクトの場合は何か？
なのよ。アカンって。
( ﾟДﾟ)「設計進捗100%です！！」
(´・ω・`)「どこが100%や」
アカンって。
僕の観点から見て、この設計書は完成したと言えない。スカスカ過ぎる。
試験項目を作る時に「あれ？ このバッチってこういう時どんな挙動すれば良いんだっけ？」みたいに分かんなくなっちゃって手が止まるのが目に見えている。
後工程で作業が停滞して立ち戻りが必要になる設計書は、完成したものとはいえないだろう。
それもちょっとなら良いよ？ 別に１００点満点の設計書を作れと言ってるのではなく、８０点くらいなら吸収出来よう。６０点が最低ラインだ。
でも、この設計書は４０点だ。最低ラインに届いてない。
開発が完了したモジュールでもバグが残っている事はある。しかし、起動すらしないものを完成したとは言うのは無理あるでしょ？
そういうこと。最低水準を満たしていないものは完成と言えないんだよ。
この４０点のシロモノを６０点に引き上げるには、一週間は必要だろう。
つまり、このプロジェクトは実質的には一週間遅延してる。設計担当者が完了したと言えば設計フェーズ完了になるのだろうが、実質的には完了してない。
今は遅延を報告するべき時なんやって。定義が無いから何とでも言えるけど、実質的に遅れてる。オンスケを言い張ったらアカンって。
アカンって。(´・ω・`)
こりゃヤバい。精神おかしくなってきた。(；´・ω・`)
実装をガタガタガタガタやりながら魂のルフランを繰り返し聞きつつインディアンクラブを振り回しているとか、客観的に普通じゃないよね。
我ながらどうしてこうなっちゃうのか。
本性がちょっと普通じゃない感は自覚してるんだけどね。(；´・ω・`)
一を聞いて十を知る、じゃねえよ、バカヤロ～。このプロジェクト、マジでキツいって。(´・ω・`)
いや、なんかさ、知らんうちにステータスが増えてるのよ。
元々は
だったのが、いつの間にか、
になってる。
(；´・ω・`)「処理中が増えた！？ ってことは処理完了とそれ以外を読み分ける必要があるからであって、関係ありそうな部分は……」
って思って調べると、実際そっちも修正の必要があるのよ。
( ﾟДﾟ)「ステータス増えました」
じゃねえよ。
ステータスに「処理中」が増えたその要件定義的な理由と、その結果としてシステム全体のどこに改修を加える必要があるのか。
それを網羅していなければ設計とは言えんだろうが。
それを整理して伝達するのが設計チームの責任、その結果をソースに反映するのが実装チーム……と言うか僕一人しかいないから僕の仕事だ。
実際には「ステータス増えました」の言葉も無くて、知らんうちにドキュメントが差し代わってる。
問い合わせたからこの言葉が来た。問い合わせなければほったらかしだった。
つまるところ、プログラマーの僕の視点としては、プログラマーが設計や要件定義の変動を自らキャッチアップして自発的に実装にフィードバックしなければ成り立たないプロジェクト、という状況。
いや、これ、キッツイってマジで。
僕は会議とかにも出席してないんだから。臭いを嗅ぎつけるだけでも高難度クエスト。
って言うか実装だけで既に負荷ＭＡＸ。前工程のお粗末な部分をフォローアップする余力はもう無い。
マジキツいって。(；´・ω・`)
ちょっとヤバいって、このプロジェクト。(；´・ω・`)
( ﾟДﾟ)「この設計でお願いします」
(#´^ω^`)「こんな設計のはずがない！！」
ずっとこんなことやってる。(；´・ω・`)
(#´^ω^`)「こんな設計のはずがない！！」
僕のこれは極めて重要なことやってるんやで。
これ、その辺のタワケが実装していたら、腐った設計がそのままズルズル行ってしまうでな。
僕が止めているから進捗が進まんのだけど、僕が止めなければ破滅や。(#´^ω^`)
( ﾟДﾟ)「ウズマスの野郎、うるせーな。仕事増やしやがって」
じゃねーぞ。
ここで止めなければ来月破滅する。
今止めれば、デスマで乗り切れる。
断固として止めなければならん。
本当に勝負所。(；´・ω・`)
土日も仕事してるけど、この設計書では進捗上がらないぞ。(；´・ω・`)
説明が曖昧なのよね。
僕が作っているのはcsvファイルを読み込んでＤＢに登録するバッチなんだけど、設計書にこんな記述がある。
新規契約の場合のみ、入力可能。じゃあ、新規契約以外の時は？？？
正解はこう。
当たり前っしょ？
支払方法が「銀行引き落とし」か「クレジットカード払い」か？ それは新規契約の時に決める項目であり、解約処理の時にそんな値が来るのはおかしいから、そんなデータが来たらエラーにして処理を止める。
それがこの設計には載ってないんだよな～。
まあ、ハッキリ言って僕は１～１００まで指示して貰わねば実装出来ないわけじゃない。上記みたいな所があれば、「ああ、書き忘れてるんだな」と自分で気付く。
「そこまで詳細に書かなくても理解出来るでしょ？」くらいの話には応じられる。
しかし、エラー番号とその文言は設計者に決めて貰わねば絶対無理じゃない？
つまり、この設計は記述を簡略化しているんじゃない。ただ抜けているだけ。
「省略」と「欠落」は違う話なのよ。
ただ記述を端折っているだけの部分と、本当に記述が欠落している部分が入り乱れている。全ての記述がチープだから本当に難解。
(´・ω・`)「果たしてこれは設計者が意図してわざわざこのような設計にしているのだろうか？ ただ考慮してないだけであろうか？」
こんなこと考えながら実装してたら時間がいくらあっても足らんわ。
流石にキツいって、これは。(´・ω・`)
やっぱりキッツいよ、このプロジェクトは。(；´・ω・`)
こういう時、僕は「進捗ヤバいなら、なおさら少しでも作業しなきゃ！！」ではなくて、「少し落ち着こう」と考えるタイプだね。
作業に集中していると色々とクラッシュしてくる。整理フェーズを時々設けないと。
まずよ～、やっぱりこれ、設計が……。50点だよ、これは。
初回案という程度には出来ているけど、このままでは作業出来ないから、僕が査読して手直ししなければならない。
事実上、僕はプログラマーであると同時に、設計のレビュアーでもあるんだ。
しかし現実は実装に専念してやれやれ、という進捗。そこに50点のシロモノのレビューが乗ってくるのはキツいキツい。
って言うか、そもそも月末までに設計が終わるんかしら？
月末時点でそもそも設計が未完成だったら、実装どうこうじゃないわな。進捗管理されてないからその辺の見通しもよく分からない。
と考えると、実装を続けるべきだろうか？
つまり、「自分はこのプロジェクトではプログラマーの立場だから」という前提を取り消し、僕が設計と進捗管理に本格的に介入するのが正解ではないか？
「進捗が遅れているから頑張らなきゃ！！」じゃなくて、プロジェクトの前提に立ち戻って、広い視野で物事を考えるべき時が今なんじゃないか。
本来それを考えるのはマネージャーなのだが、このプロジェクトはマネージャー見習いが経験積む為にやってるだけから、こういう視点など持ってるはずが無い。
僕が「自分はプログラマーだから」と、愚直に作業に専念していたらプロジェクトが死んでしまう。
どう立ち振る舞うべきか。このまま現在の立場を維持するべきか、僕がプロジェクト全体を仕切る方向に切り替えるべきか。
前者だとプロジェクト自体がヤバい。
後者は人間関係に角が立ち、かつ僕個人の責任も重くなるのがリスクだ。
どう振る舞うのが正解なのかなぁ。
風呂にでも入りながらじっくり考えるか。
やっぱり人生で大事なのは、作業遂行能力が高いかどうかではなく、正解の選択肢を選ぶことが出来るかどうか、だよね。
難しいなぁ。(´・ω・`)
やれやれ、ようやく設計チームから「設計完成」の連絡が来たぞ。(；´・ω・`)
この一言さえあれば僕が動ける。
この自称完成した設計、ハッキリ言って間違いだらけなんだけど、僕にはどこが間違っているか分かるからな。
(｀・ω・´)「この設計書のこの部分はおかしい。本来こうあるべきものを書き間違えているでしょう？」
という指摘を出しまくれば、それは僕が書いているのと同じだから、今度こそ本当に完成する。
本来、プログラマーってのは設計書に書かれている内容をその通りに実装するのが仕事だが、現実はそうじゃないのよ。
間違った設計書が降りて来るのが常だから、プログラマーが自発的に気付いて差し戻さねばならん。
「設計書の間違いに自ら気付くことが出来るか？」はプログラマーの腕前の一つよね。
ま～、とにかく、ここからが本番だ。(´・ω・`)
画面１０画面、バッチ１０本、この全てが設計完成度２０～６０％なんだよなぁ。(´・ω・`)
完全完成しているものが一つも無い。要は設計者が実力不足で良く分からんから、分かる範囲内をポロポロ書いてるだけなのよ。
だから進捗０～６０％までは頑張って進むかもしれないが、６１～９９％の間でパタッと手が止まるのが目に見えている。
その６０％ってのも、「上の方の６０％はＯＫだが、下の方の４０％は未着手」というように整理されているわけではなく。
全体的に歯抜け。「全体的に６０％くらいは埋まってるけど、全体的に４０％くらい不均一に歯抜けや間違いが散りばめられている」という。
それは実質的にはゼロと同じなんや。ふざけんなよ、本当に。(#´^ω^`)
設計書が全てデタラメ……と言うか未完成で萎え。(´・ω・`)
未完成のページとデタラメのページの見分けがつかん。
たぶん、全部未完成だと思うのだが。
まだ書いている途中のものに対して「これ、間違ってますよ」とは言えんからな。しかし気になって仕方が無い。
でも設計書の完成を待ってたら納期間に合わないから、勝手に実装してる。
「設計書には書いてないけど、要件の辻褄を考えれば本来こうなっているはずだ」
勝手に設計を予測して実装してる。ってか、そうとしかならんもん。
ＤＢ設計とCSVファイル設計が完了した時点で、残りは深く考えるまでもなく、自ずとそう帰結するようにしかならんような話やがや。
何をやっとるんや？(´・ω・`)
このプロジェクト、結構ヤバいな。(；´・ω・`)
ヤバいと言っても、所詮は小規模プロジェクト。小規模ならば何とでもゴリ押し可能ではあるのだが。
弊社社長と僕の２人でゴリ押しは最終手段。
その最終手段が発動になる気配、ギリギリ感を感じて来た。
って言うか、設計やってる若い衆、ギブアップしろ。
お前らの力量ではもう追い付かない。ベテランに全部丸投げする以外に打開する手段は無いんや。僕は実装チームだから設計チームに苦言する立場に無い。自分で気付け。
一体どういうスケジュールでプロジェクトを終わらせるつもりや？
10月末に実装完了のスケジュールなのに、このままでは10月末に設計も終わっとらんやろ。
お前らは「見通し」という概念が欠落しとる。
「いや、これちょっとヤバいんじゃない？」と現状を振り返る観点が無い。
だから感じるべき危機感を感じず、漫然と作業し続けられるんや。
所詮は小規模プロジェクト。
泣き付けばベテラン陣でフォロー可能だが、泣き付くべき時は今なんやぞ。
月末に進捗を問われて窮するみたいなオチは観ているこっちがやるせないからやめてくれ。
今すぐギブアップしろ。
熟達しろとは言わん。
「自分の手に余るかどうか」は自分で理解するべき。(´・ω・`)
今週はしんどいなぁ。(；´・ω・`)
今週から新プロジェクトが始まってね、僕は常套手段として、プロジェクトの前半ほどフルパワーで働いて、後半に余力を残すというスタイルを取るのよ。
「時間的余力が全てを解決する」の一点張りの男。
だから最初である今週が一番大変。(；´・ω・`)
しかし、何とかペースは上々かなぁ。
何と言ってもこのプロジェクト、形が無い。
まず、機能数不明。
画面とバッチを作って欲しいみたいなんだけど、バッチの総量が分かんない。
まあ、聞いている話から概ねの規模感は何となく察するんだけど、機能一覧としてのリストアップがまだ出来てない。
総量が分かんないから進捗率も算出出来ず。進捗率が見えない以上は、出来るだけ早く進めておくしかやり様が無い。
次に、画面項目不明。
画面に表示する項目が明らかにデタラメなのよ。モックは僕が作ったんだけど、類似システムを参考にそれっぽく作っただけだから、今となってはＤＢに存在しないカラムが画面に出ているような状況。
ただ、主キーだけは正しいから、それを踏まえて作れる部分だけ作ってる。
最後に、スケジュール不明。
実装完了は今月末だが、テストは今月中に開始する。この「テスト」って一体なんなのよ？
僕の実装完了が月末だったらテストの開始なんて出来ないでしょ？
「テストを始めたいから先に完成させて欲しい機能」と「後回しで良い機能」があるはずなんだけど、どれがどれか分からん。
って感じで、とにかく計画みたいなものが壊滅してて。(；´・ω・`)
見習いが経験を積む為にマネージャーやってるから、手に余ってるんだな。
「マネージャーが見習いだから、プログラマーの方にベテランを置く」という布陣。
と言うわけで、とにかくプロジェクトがどう横転しても下流工程で吸収可能な状況に持ち込む必要があって、その為に今週はずっとフルパワーである。
こんなやり方、基本ありえんでな。
プロマネプログラマーのウズ様に感謝せ～よ。(´・ω・`)
そろそろプロジェクトが本格始動なんだけど、既に半分グダってるな。マネージャーどこ行ってしもうた？(；´・ω・`)
と言うのも、若手の育成という観点から、このプロジェクトは若手に仕切ってやって貰おうという意図があるみたいなんだけど、そのマネージャー代理が自分の作業で忙しくてマネージメントまで手が回らなくなっちゃってるような。
だから作業指示もスケジュールも何も無い。(；´・ω・`)
が、まあ、僕はベテランだから、そういうのも汲み上げて作業を進めてしまうんだが、流石に管理が虚無の状況を続けるのも不健全っしょ。
明日は朝に軽く情報交換しましょう、という話をもちかけておいた。その中でスケジュール感や要件定義の角度、優先順位も見えてくるだろう。
プログラマーではあるが、同時にマネージャー補佐であるという、この謎ポジション。
僕みたいなのは何て言えば良いんだろうね。何でも屋が極まってる。(´・ω・`)
テレビ神奈川で銀河鉄道９９９が再放送されてたんだけど、やっと終わった。全１１３話。(；´・ω・`)
小さい頃から観たかったんだけど、流石に全話を完走するエネルギーは無いので、最後の２話「青春の幻影 さらば999 前編・後編」だけ観て終わりとした。
最終回は有名だよね。偶にＴＶで「２１世紀に残したいアニメ」みたいなのがあると、大抵は紹介されるから、鉄郎とメーテルがお別れして終了、という最終回であることは知っている人も多かろう。
銀河鉄道９９９を語る上では、やっぱりメーテルがぶっちぎりの人気キャラであろう。
松本零士作品を代表する人気ヒロイン。かつ、地球上の全アニメを見渡しても比肩するキャラは存在しないんじゃないか？ 一つの究極完成形というポジションを確立しており、今後も並ぶことは無いだろう。
アニメキャラの一人という枠を超えてるよね。(´・ω・`)
しかし、結局、最後まで謎は残ったね。ミステリアスな部分が魅力のキャラだから当然なのかもしれんが。結局、メーテルは何者なんや？(；´^ω^`)
いや、女王プロメシュームの娘ってのは確定だけどさ、問題はボディよ。
銀河鉄道999の世界観的に、登場キャラはみんな「生身の人間 or 機械化人間」のどっちか一方のはずなんだけど、メーテルだけはどっちにも当てはまらないっしょ。
絶対、見た目通りの年齢のはずがないよ。外見年齢は１８歳くらいだろうが、実年齢は１００歳か２００歳か分からん。人間であるはずが無い。
かと言って、機械化人間の特徴も無い。
一番の特徴は精神性で、銀河鉄道999の人間は機械化すると精神が荒廃するが、メーテルの精神性は人間である。でも描写的には不老不死としか思えん。
だから「体は生身だけど、クローンで記憶を引き継いでいる」みたいな理屈だと、違和感あると思うのよ。事実上の不老不死なら、それは機械の身体を持ってるのと同じやろ。血液がありゃいいってもんじゃない。
不死性を維持したまま、精神性は人間寄りである、というカラクリ。
一体なんなんや？
全然分からん。正真正銘の魔女。(；´・ω・`)
まあ、その辺は永遠に明かされることは無いのだろうね。
ともかく、銀河鉄道９９９は名作だった。
近年は昔のアニメのリメイクが流行っているが、宇宙戦艦ヤマトと違って銀河鉄道９９９は作風を近年に合わせるのが難しい感があるから、リメイクは期待できないかも。
思い出として大切に収納しておきたい。(´・ω・`)
お～し、話題作「メイドインアビス」に、遅れながら視聴が追い付いたぞ。(｀・ω・´)
しかし、懐かしいなぁ、つくしあきひと先生……。
この先生、僕と同世代のはずなんだよね。
２０年前、僕が大学生だった頃、既に「凄いイラストレータがいる」と話題だった。当時は個人サイトにイラストを投稿するアマチュアだったと思うんだけど、今やプロに進んだんだな。
20年前からず～っと僕は好きだった。
が、僕もちょっと仕事や家庭の都合でアンテナが張れてなくて(;^^)
先生が漫画家、アニメータに転身し、こんな話題作を展開していると気付いたのは最近なのよ。
知ってから慌てて、「何てことだ、あの大先生が！！」と思い、モチベーションを上げてやっと視聴が追い付いた。
先生の作品は、やはり20年間変わらず緻密だね。
中央には可愛らしいキャラを据えるんだど、背景には悲しみがある。
陰と陽の両方の勘所を合わせ持つと言うか。
人生観がイラストに反映されてるんじゃないかなって迫力がある。
何より、20年前に好きだった先生が、今やアニメ放送まで達成しているのは実に嬉しいね。
メイドインアビス、第三期は当然観るし、その後も活躍して貰いたい。
20年前からのファンは沢山いるはずですぞ。(´・ω・`)