Diary?

(00:33)

昨日は散々だった。何がって、 12:00 ぐらいに出社して 22:00 まで働いてた。アリエネエ。そして今日も午後から出社して働かんといかん。ふざけるなと言いたいどころか既に上司にも散々不満を叩きつけているのだが、どっちにしろ暫く俺はここにいないといけない。

それでも状況が好転まではいかないものの、ある程度は先が見えてきたこともあって最後のカードを切らずに済みそうだ。いやまあ、今後の状況次第じゃ容赦なく切るけどね。少なくとも、今年度いっぱいは俺の持っているカードは MTG での「ヨーグモスの意志」クラスのエンドカードになるからな。

今のプロジェクトのクソなところは一つ二つではなくプロジェクトの全てがクソなので書くと長くなるのだが、とりあえず俺らの会社の最大のチョンボは時間と人の見積りが最悪だったということに尽きる。恐らく前のプロジェクトのコードの引き継ぎがあるのでそれほど実際のコード量は多くならないと踏んでいたのだろうが、

• 前のプロジェクトのコードが腐っていたため、そのまま使うと木造住宅の上にサンダーバード基地を作るようなものになってしまう
• 異常な検証機構やバカバカしい環境のためにコーディングやテストよりもくだらない文書作成と体裁チェックに時間がかかる
• コードを書くその前にコードと殆ど等価なドキュメントを書かされる (俺は完全に無視していたし今も無視してる。バレないようにすればいいだけの話だ)

などの理由で実際にはとんでもない量の作業が発生していた。その上難しい部分は全て俺に回すという前提の元にスキルに問題のある野郎を連れてきて OJT もどきをさせようとしたのが問題だ。というか、研修を一月かそこらやっただけのペーペーをいきなり連れてくるなド畜生。

確かにソフトウェア開発における見積りはとても大変だというのはわかる。正確な見積りなんて出せるはずもなく、正確にコストを算出したいなら全てが終わってから計算する以外に方法はない。そしてそれが今のビジネスでは出来ない以上、誤差が出るのは仕方がない。そしてその仕方のない誤差を受け入れられないからこそ、プロジェクトが火の車になるわけだ。はっきりいってこんな突貫工事じゃひどい品質のコードが出来上がるに決まっているのだが、恐らく向こうもまともな品質評価は行っていないだろう。

そもそも、この現場における品質の定義を開発者が知らない時点でゲームセットだ。恐らくバカみたいに標準や規約を守らせれば品質が上がると考えているのだろうが、俺からすれば未経験かつ入社一年目のガキが取りまとめた標準なんぞを守って品質なぞあがるはずもないと思うし、そもそも標準や規約は仕事をより上手く進めるために存在する物であり、今のように現場に混乱をもたらすような標準なんぞとっとと捨てるべきなんだが。

そして例えば品質評価にソフトウェアメトリクスの計測ツールを使うのであれば全ての開発者がその評価基準を知っているべきだし、本来なら全ての開発者がそのツールを使えるようにするべきだ。どうして現場でコードを書いている人たちを蔑ろにするのか。そもそも俺たち以外のチームではドキュメントの担当者とコーディングの担当者が別人のケースが殆どなのだが、人的にも時間的にもドキュメント・コード・テストの三つが乖離すればするほどソフトウェアの品質は落ちていく。このことは「人間は物事を簡単に忘れる」「相手に自分の意志を完全に伝えることは不可能」という二点から自明だ。

ちなみに今のプロジェクトはウォーターフォールで進められているが、このプロジェクトの後ウォーターフォールを肯定する輩は俺たちの会社にはいないだろう。「ウォーターフォールはあと20年消えない」に書かれている指摘は全て正しい。