要件定義が8割の件。

訳あって炎上案件の火消しの話。⑤

「上流工程」の大切さについては、開発案件にかかっている人は全員が分かると思う。

　RFP→要求仕様確定→要件確定

ウォーターフォールでもアジャイルでも、少なくともまず1回はここまでしなくては作り始めることができない。
ここが擦り合っていないと大幅な手戻りが発生する。

そこから、設計書→詳細設計→受託開発になるか、それとも、モックアップからのイテレーションで回していくかのやり方はいくつかある。
とはいえ、やはりGOALが一致していないと（あるいはある程度）かなり厳しい。

今回の案件ではこれがかなり微妙だった。
C/Oされてから巻き直した仕様が多過ぎた。

要件を確定するのに必要な要素は以下の5つだと思う。
5番目はかなり邪道だけれども、大事なポイントだと思う。どんなに理想論を唱えても5番目が無理なら、すべてがご破算。

　1)クライアント運用想定（現行業務・改善業務）
　2)業務必要機能（開発対象となる機能の必要機能）
　3)システム要件（構成・外部接続・非機能・拡張性・セキュリティ等）
　4)法令遵守（税法・商法・個人情報保護法等）
　5)実現可能性（提供システムの限界・開発環境・人的スキルセット等）

この前提で行くと、要件定義には、「提供システムの理解」と「運用・業務洗い出し」が必須。
そして、「顧客とGOAL一致しているエビデンス」までがセット。

なぜ無い…

いや、違うな。

8割はあった。リリース後ではあるがｗ

そこまでの膨大な量を見れば、短期間でよくできたと思う。私なら途中で諦めてたと思う。

が、2割なかったら、そこが炎上の火種になる。実際なった。
作ったシステムの2割をやり直しというのは、実際開発工数の20%なわけで。
それをC/O後に対応するのはなかなかしんどい。

ある連携システムは、要件を確認したらまるまる全部作り直しだったものまである。大幅な手戻り。そこまでにかけた工数はすべて無駄。
何を顧客とすり合わせたんだ！と叫びたくなる（叫んだ）。

土台の設計を間違えて、積み木が少しずつズレ、結局歪んだ家が出来上がった。

要件定義は基礎工事。基礎は大切に。