火消し

【水曜日】
抱えてるタスクがなかなか終わらなくて残業してると、チームリーダーが来てこういいました。
「他のチームがやってる案件が炎上してるので、申し訳ないけれども今のタスクは一旦置いておいてそちらに火消しとして入ってください」

これを聞いて、最初は喜びました。なにせ今抱えてるタスクが「5-6個のアプリのフロントリファクタ(PC/ガラケー/スマフォ)」か「全アプリの裏側支援ツールの作成」という非常に重くて胃のキリキリする仕事ばかりなので、そこから逃げれるのは非常に嬉しい！
それに、こういう形で火消しで入るのは今までにもあって経験してるので、炎上してるとしてもそんなにひどいことにはならんだろ、とか思ってました。
なので、ヘラヘラ笑いながら「いいっすよ」と二つ返事で引き受けたのでした。
ちなみに、このとき他２人の先輩エンジニアも投入されることが決定していました。この２人とは今までも何度か炎上案件やってきたので、実力は知ってるし余裕だろうとは思いました。ただ、これだけのメンツが同時に投入されることに、ほんの少し驚きと不安はありました。それでも何とかなるだろう、という算段は大きかったです。

【木曜日】
プロジェクトのリーダーとミーティングして案件の説明を受けました。
他社の都合もあるためにスケジュールがずらせなく、ケツも迫ってるということでそれなりにしんどい印象は受けましたが、振られたタスクは想定よりも随分少なかったのでした。
正直、この程度の量なら今までを振り返ってもむしろ炎上のうちにも入らないな、と思い楽勝ムードでそのまま仕事に入りました。
とりあえず、コードと設計を見始めました。設計をちょっと見たところで、大きな違和感というか、設計上まずいところがいくつも出てきました。
自分「ここ、現状の設計だと要件満たせないですよ」
担当「明日がテスト開始で間に合わないのでこのまま行かせてください」

【金曜日(今日)】
昨日の衝撃の事実に動揺しつつも、とりあえずやりたいことやどう実装すべきかを一旦把握しようと思い、通常は10時始業にも関わらず今日は７時３０分に出社して企画書と仕様書を漁ることにしました。
部屋を見渡すと案件の担当者は既に存在していました。どうやら徹夜だったようです。
大変なんだな、と同情の念を持った後、共有フォルダの中から企画書と仕様書を探しました。
しかし、なんということでしょう！企画書が見つからないではありませんか！これでは何をやりたいのかが分かりません。
仕様書はなんとか見つかりました。しかし、例によって、非常にカオスな仕様書です。仕様自体はあまり多くなさそうなのですが、書いてる内容が意味不明な箇所が目につきます。
これを、別案件で徹夜していた新卒の横で、「こいつら全員○ねばいいのに」と呪いの言葉を吐きながら読み進めていきました。新卒の子には申し訳なかったかな、と正直今では反省しています。

午後になって一通りやるべきことは把握したので手を動かし始めました。
まずは既存機能との連携機能の実装に手を付けます。通常なら2～3時間で終わる内容です。
しかし、ここで問題発生です！既存機能を担うモジュール群にテストがありません！しかも、一つ一つの関数がかなり肥えていて、処理が複雑すぎていろいろ不具合を抱えていそうです。
このまま開発を進めても大きな爆弾を抱えるだけです。なので、まずはこのモジュール群のテスト追加とリファクタをすることにしました。
しかし、仕様を把握してないので、この部分の仕様を別途把握する必要が出てきています…。
ということで、いまココ。

【今までの炎上案件の特徴】
ここで今までのことを振り返ってみました。ざっと思いあたった共通点は以下の通りです。
・やりたいことははっきりしてる
・ただし、やりたいこと多すぎて仕様が非常に膨大
・その膨大な仕様に対して開発期間が異常に短い
・遅々として進まない状況とは別にプランナーがやりたいことを追加して仕様が増える
・一応、担当エンジニアの中には優秀なベテランがいて、そもそも実現できない、ということはない

要するに「時間が全然足りないのでリソース投入してスピードアップすれば解決するよね」という割と単純なものだったと思います。
自分の特性として、ある特定の領域で専門性をおおいに発揮するほどの深さはないが、だいたい何でもできるし実装が早いというのがあるので、今までの問題についてはこれらがある程度マッチしていたと思います。

【今回の特徴】
今回は以下のような特徴です。
・ケツが厳格に決まっている
・やりたいことがあやふやで決まっていない
・やりたいことが決まってないけど時間がないのでとりあえず仕様をつくる
・とりあえずの仕様ですごく危なっかしいけど時間がないのでとりあえず設計する
・とりあえずの設計なので穴がいっぱいありそうだけど時間がないのでとりあえずコードを書く
・とりあえずのコードなので要件を実現できてるのか分からないし、整理されてないのでリソース追加してもスケールしない
・チームの大半が半年以内に入った人ばかりで、社内の設計方針について精通してないし実力も未知数なところが多い

このような感じで、ネットでよく見るSI系の典型的な大型プロジェクトの失敗例に似通っています。

【設計ミスをコードによる補完で逃げること】
設計ミスを指摘した際、設計を直してる時間はないのでコードでなんとかするのでこのままで行かせてください、と何度かいわれました。時間がないことはこちらも把握してるので、問題認識をした上で同様の解決策を提案することもあります。
しかし、やはり設計ミスは後々に悔恨を残すので、できればやめたいなと思っています。例えば、レコードのユニーク性を担保したいのであれば、INSERTのときSELECT文を発行しまくってチェックを繰り返して弾くよりは、テーブルにユニーク制約をかけてやった方が圧倒的に楽で不具合も少ないです。
とにかく設計は後になればなるほどやり直しが効きづらくなっていきます。耐震構造が震度５の建物をどんなに強化したところで、基盤や骨子が駄目なら一旦全部壊して一からやり直さないと、それ以上耐震性能が上がらないのと同じです。

なので、せめてあと１週間早く入って設計の立て直しができる状況だったらどれほど楽だったろう、と思っています。
とにかく今はここからどうやって立て直すか…。