本園明史『要求定義のチェックポイント427』

要求定義のチェックポイント427

システム開発・導入プロジェクトの中でも「要求定義フェーズできちんと顧客の要求を吸い上げてまとめきることができるか」という点は非常に重要であろう。顧客の要求を理解しきれていなかったり顧客の要求の変更が起こったりして手戻りや迷走の発生する事例は、システム業界を見渡せば「業界スタンダード」とすら言えそうである。
俺の勤務先はパッケージシステムの販売・導入がメインだが、それでもカスタマイズがないわけではないし、パッケージと言えどもパッケージの機能と顧客の運用の整合性を取るための打ち合わせは必ず存在する。また多くのパッケージベンダーではファーストユーザーの導入プロジェクトで「モノ」を作りながら導入することがよくある。つまり実態として、パッケージベンダーと言えどもファーストユーザーがスクラッチ開発になるケースは少なくない。そしてプロジェクトが炎上したり、それどころかもう炎上を通り越してぺんぺん草も生えないほど全てが燃え尽きてもなおプロジェクトの終了条件すらよくわからなかったりするケースは、もはや当たり前のように見てきている。炎上プロジェクトの中には「議事録を残していない」「課題一覧を作って顧客と共有していない」「スケジュールや期日がわからないまま働いている」といった驚くべき事実もあるが、では一体「確認すべきこと」「検討すべきこと」とは何だろうか、と考えて本書を手に取ってみた。
本書は要求定義フェーズのみを対象としているが、驚くのはチェックリストの多さである。427はさすがに多すぎる。将来的に自分たちでカスタマイズする必要があると思われる。
なお本書では大きく「検討」と「ヒアリング」のリストを作っているが、以下の10の「検討」ポイントは、俺が特に感銘を受けたものである。特に「開発可否の判断プロセスを通らない要求は、決して開発対象とならないことが保証されるか」などは、これを顧客に理解してもらった上で守りきることができれば、炎上プロジェクトの数は激減するはずであろう。

• 開発可否の判断対象となる要求は、ドキュメントで管理されている要求のみであることが保証されるか
• 開発可否の判断プロセスを通らない要求は、決して開発対象とならないことが保証されるか
• 開発が却下された要求について、開発側から代替案を提示することが可能か
• 開発が却下された要求について、顧客から再び強く要求された場合の対応は決まっているか
• 機能と開発資源のトレードオフの関係を顧客に説明することができるか
• 品質とコストのトレードオフの関係を顧客に説明することができるか
• 解決策を暗示しているような質問はないか
• 回答期限までに回答が得られなかった場合の対応は決まっているか
• テストは「システムが正しく動作することを保証するものではない」ということを顧客に理解してもらうことが可能か
• 要求フェーズの終了をどのように判断するか

「ヒアリング」リストも多く挙げられているので、個人的に唸ったものを1つだけ挙げたい。

• 要求はすべて御社内のコンセンサスが取れていると考えても良いですか

担当者ごとや部署ごとで矛盾した要求を出していることは実際よくある。俺は恥ずかしながら意識したことはなかったが、顧客の中での整合性を担保してもらうことは絶対に行うべきだし、現在それが行われていないなら、顧客内でコンセンサスを取るための打ち合わせを実施してもらうべきである。
最後に、本書は「要求定義」フェーズを対象としている。言葉としては当然「要求定義」と「要件定義」は異なるのであるが、実際には要件定義フェーズの中で顧客の要求整理を行うことが大半であり、差し当たり本書も「要件定義」フェーズについて書かれた本だと理解して問題ないと思われる。