マネージメントだけだと、「ガンバレガンバレ」しか言えなくなるのでつらい

自分は、ソフトウェアの受託開発でコードを書く案件の時もあれば、要件定義や進捗管理をする時もある。
役割を適宜入れ替えていくのは、良いことだと思っている。
役割を固定化しないで臨機応変に案件をこなすことで、人が余るとか足りないとかが起きにくくなって、経営的にも楽になって、結果働く人にも優しくなっているはず。

それはそれとして、最近コードを書くことが少なくなってきてる。
「俺は、まだまだコードを書けるんだ。読めるんだ」
とは思っていても、案件の中でコードを書いてないと、いざというときに、その案件のコードを素早く自分で調べたり直したりできない。
レビューと言っても、断片的なその部分のコードの書き方以上のコメントができない。
十分な時間があれば、あらかじめもっと丁寧にコード読んだりしておけると言いたいが、十分な時間があったためしがない。
さらに読んでるだけじゃなくて一部のコードを書くのが大事だなって最近思う。
自分が書いたところや、その周辺だったら「あー、あそこらへんね」って、大変そうか些末なことか想像つくけど、そうじゃないところは、予想もつかないことになってることがある。

工程の最後になったら、もういまさら自分がコード読んでもすぐに理解できないし、他の人にする質問はされるほうにとっては邪魔でしかない。

コードを書いた人に、調べてとか直してとかどれくらいかかる？とか頑張って言って、結果を別の人に伝えるしかなくて、
「あー、俺って今、いらない中間管理職の仕事してるんじゃないかなぁ」
と思ってつらいなぁ・・・と思うことが最近多い。

細かく状況を把握しようとすると、マイクロマネージメントで嫌がられるんじゃないかと思う。かといって聞かないと自分がわからない。
「無尽蔵に時間があれば俺だって自分でできるんだよ」
と思ってしまうのが・・・
以前在籍した会社の部長や課長が、営業や工数管理しかしてないのに
「俺だって、やろうと思えばプログラム書けるけどやってない」
と言っていたのを
「いや、無理でしょ」
と思っていたのを思い出す。
自分も、あの部長や課長みたいになってきてる。
あの頃の部長や課長は、(20年経ったけど）今、どんな仕事してるんだろうなぁ。

みずほ銀行システム統合、苦闘の19年史

読了。

過去２回、システムトラブルが起きた時に出版された日系コンピューターの書籍も読んだし、システム移行までの様子も伝わってきたので、全体的に、いつかどこかで見た内容だった。
ただ、過去のトラブルについて以前読んだ書籍よりも整理して説明されていたなと思う。


ところで、新システムは、サービス思考アーキテクチャになっていて、新しいサービスに素早く対応できるとのことだったが、本当だろうか？
できるかどうかは、これからわかってくるんだと思うけど、終戦の年に時代遅れで過去最大級の戦艦、大和を建造した二の舞になってないだろうか？

日本IBM が DB2 を、富士通が Symfowareを、日立は HiRDB を使っていたことと、全体に、超高速開発手法を使っていたということが書いてあって、その２点は、大丈夫なのかなぁ・・・と思った。