Diary?

(20:24)

俺

「そういや今月分の給与明細、まだ送られてきてないよな」

同僚

「え? もう送られてきてるけど?」

こういう場合、大抵の場合間違ってるのは俺だ。なので家に帰ってきてからアパートの郵便受けの近くのゴミ箱を漁ってみたら、やはりというか何というか広告の類と一緒に捨ててた。毎度の事だけど、何やってんだ俺。

(21:16)

設計書が毒電波を発する怪文書だったせいで実装が腐敗したプロジェクトなら経験したが、妥当な設計書から壮絶極まる瘴気を放つ実装が放り出されたケースは初めてだ。昨日の時点までは「流石にこれは設計書も解読不能だろ」と踏んでいたけど、発掘した設計書は割とちゃんと書いてあったんだよな。それでこの実装になるか。どんだけフザケた外注使ったんだ、これは。

それで SI 業界にいると「実装はシステム開発全体のほんの一部で重要ではない」って言葉を聞くんだが、だからといって低品質なコードをのさばらせちゃダメだろ。ダメダメな実装は「メンテナンスが困難」「パフォーマンスが悪い」「高いバグ混入率」といった問題を抱えていて、例えばコピペだらけで 3000 行を越えるメソッドの保守とかやりたくないだろ。

大体システムってのは実装して終わりじゃなくて、その後に各種のテストが待ち受けていて、最終的にクライアントに納品して運用しなきゃいけないわけだろ。それで本番で予期せぬ問題が発生したり、新機能の追加要求が出てきたとき、実装が死んでるんで改修に余計なコストがかかるとかどう考えてもおかしいだろ。それで終いにゃメンテナンスが不可能なので全面改定みたいな話が出てきて、一部分でもいいから流用ができないかの調査に俺が投入されて、「おたくのシステム、腐敗どころか白骨化してますよ（意訳）」みたいな報告書が上がってくるわけだ。

それで実装の品質を保証しようとした結果、「Fooクラスのインスタンスを作って、そのインスタンスのbarメソッドに引数 buz を与える」みたいなレベルで記述されるプログラム設計書が作られることになって、大体そういうところは同時に余計な管理ワークが発生して、ただでさえチンカスのような管理ワークが余計チンカスになるんだよ。俺はそういった管理ワークに忙殺された結果、本来やらなければならないコードレビューなどができなくなって、さらには単体テストをまともに実施することすらできなくなって、その単体テストを通してないソースがなぜか納品されてしまい、システムテストで大炎上したという事例を知っている。そのくせこっちで共通処理をライブラリにまとめたりといった工夫をしようとすると、「当初の予定に入っていないクラスの作成は不可」とかいうお達しが来るからわけわからねえ。

結局のところこれらの問題は「言われたままにタイピングするしか能のない類人猿」を雇っていて、さらにそれをプログラマのデフォルト値としている事に起因するので、とにかく普通のコードが書ける奴を雇うしかない。別にもの凄く傑出したプログラマである必要なんて全然なくて、先に出した例だと「コピペだらけで 3000 行を越えるメソッド」とかを書かないと信頼できる程度でいい。