はじめに
よく言われることであるが、システム開発の失敗の大半は要件定義の失敗によるものである。
システム開発における失敗とは具体的に何かというと、Q（顧客と合意した品質への期待値）・C（顧客と合意した予算）・D（顧客と合意した納期）のうち1つ以上を満たせないことである。
前段はこれくらいにして、本題、要件定義のポイントである。
要件定義のポイントは2つで、”顧客にちゃんとスコープを認識してもらうこと” “対象のスコープのシステムを開発するにあたり、必要なカネと納期を合意すること”である。
“顧客にちゃんとスコープを認識してもらうこと”
具体的に、決めるべきスコープは以下である。
- 利用するユーザは誰か？
- システムを利用する業務・ユースケースにはどんなものがあるか？
- データ連携を行いたいデータ・連携先システムはどれだけあるか？
- 画面機能、バッチ機能、インターフェース機能、ジョブはそれぞれいくつあるか？
- 画面機能、バッチ機能、インターフェース機能、ジョブにどのような機能性を期待するか？
これらがドキュメントに明記されていて、顧客がそれぞれのドキュメントの内容について腹落ちできていればOKである。
具体的なドキュメントとしては最低限以下。
- 業務フロー（誰がどんな業務をするときに使うか？を表したもの。スイムレーンチャートのような形式）
- 機能一覧（画面、バッチ、インターフェース、ジョブの全量に対し、開発難易度をつけたもの）
- 要件一覧（機能一覧の難易度付に影響する業務要件、システム要件を明記したもの）
- DFD（機能とデータの関連性を示したもの）
- 画面イメージ（どんなレイアウト、何を押したら何が起こるかがわかるもの）
これらについてドキュメントベースで顧客と丁寧にすり合わせを行い、合意を取り付ける。
“対象のスコープのシステムを開発するにあたり、必要なカネと納期を合意すること”
上記で「何のために、何を作るか」を明確にし、その上でカネと納期を決める。
カネについては、まず前述の機能一覧をインプットに、この難易度の機能をいくつ作るなら大体このくらいの工数かかるな、を勘定してみて（会社によっては、標準的な難易度別工数テーブルみたいなものがあるのでそこに照らして）、工数を人積みにならして、会議工数や管理工数、移行工数などを積み上げて算出する。※この辺は長くなりそうなので別で解説する
上記のプロセスで生み出した費用は、「根拠のある費用」となる。この「根拠」が非常に大事である。
根拠が明確になっていれば、顧客に提示して「高い」と言われたときに「この機能（や要件）を削ったら安くできますよ」という交渉ができる。また、基本設計以降で要件や機能が追加になった時も「前回の断面と比べて予算がx%増えています。なぜならここが増えたからです」と説明することができる。理由なき値引きや無償労働をしないために、作り手としては根拠を持った見積もりをしたい。
また、顧客としてもプロジェクトオーナーに予算に対する増減を説明する必要が生じるため、根拠を出してあげることは歓迎されるものである。
大事なことなので改めて。根拠とセットで見積もりを提示して、顧客と合意を得ることが肝要である。
納期については、最悪どこまでにサービスインできないといけない、があって、それがスコープ・予算と噛み合わないなら、スコープ（機能や要件）を減らしてでも納期に収められるようにする必要がある。
サービスインの日程、そこから逆算した各種イベント（稼働判定やユーザ教育など。顧客側の繁忙期なども考慮してあげたい）を明記して、顧客と合意を得ることが肝要である。
おわりに
色々と走り書きで書いてしまったが、また折を見て加筆修正をするなり、もう少し説明が必要なところは別記事にするなどは今後検討したい。
コメント