システムを作り直す難しさ - 仕様は誰も知らない

文章に直すパワーがないので、勢いで公開。二度と同じ轍を踏まないように。

事実
・プロジェクトで赤字を出してしまった。
・契約自体が準委任だったので、期限が来たところで解放となったが、システムは完成せず、バグも残った状態での引き渡しとなった。
・結果、保守契約も新たなプロジェクトの話も得られず、大失敗だったといえる。
・中長期的な話もお客様としていたので、個人的にはかなり痛い失敗。。

気づき（その事実について気づいたこと、反省）
・原因はいくつか考えられるが、最大の問題は、見積もりの失敗。
・このプロジェクトは、RDBを使って実装されている検索機能を、検索エンジンに置き換えて実現するというものだった。それによって、今のシステムにかかっている負荷を下げようというもの。
・すなわち、実現すべき機能は、既存の機能そのもの。そこに落とし穴があった。
・プロジェクトはウォーターフォールで進めた。

・見積もり当初は、自分たちもお客様もそれほど大はずれしているとは思っていなかった。（お客様は若干少ないなと思ってはいたらしい。ただ、はっきり言うほど大はずれしているとは思っていなかった）
・すべての機能を正しく記載している設計書がなかった。網羅、アップデートされていないだけでなく正しくなかった。正しくないドキュメントは単に参考にならないだけではなく、間違いをよび手戻りを発生させた。
・正しい機能、要件は、ふたを開けてみると誰も知らず、今のソースにしか書いていなかった。ソースを調査する必要があった。つまり、正しい見積もり、コストはソースを調査することでしか得られなかった。
・要件定義終了の段階で、そのことに気がついておらず、結果正しくない見積もりで開始。基本設計の時点で致命的な遅れを発生し、様々な手を打つも結局リカバリーできず終了。

教訓（次の行動への目標）
・既存の機能を作り直す場合は、ウォーターフォールで進めてはいけない。アジャイルで進める。開発する機能を仕様を明確にしながら進める。仕様を知っているつもりだが、誰も本当のところは知らないと認識すること。
・できるだけ常駐する。密にリアルタイムにシステムの情報を得ること。難しい場合は、倍は設計に時間がかかると認識すること。
・コミュニケーションは担当者どうしで取れる体制にすること。別にリーダー通してやらなくてはいけない理由はない。
・準委任契約の場合は、必ず工数契約とし、出来るだけ常駐で受け、お客様の目の前で工数を消化していることを明確にすること。元々の想定していたスケジュール通りに進んでいなくても、工数はちゃんと消化されていることを常に理解してもらうこと。