要件定義を甘く見ていた会社が払うことになる、3つのコスト
「完成したシステムが、思っていたものと全然違った。」
この原因のほとんどは、開発会社の技術力ではなく、要件定義の段階で起きています。
要件定義とは何か
要件定義とは、「何を作るか」を言語化するプロセスです。
- 誰が使うのか
- 何のために使うのか
- どういう操作ができる必要があるか
- どういう状態になったら「完成」か
これを発注者側がまとめ、開発会社と合意するのが要件定義です。これが甘いと、どれだけ優秀な開発会社でも期待通りのものは作れません。
要件定義を甘くすると払う3つのコスト
コスト1：手戻りの開発費
「これは要件に含まれていなかった」という判断で、追加費用が発生します。開発途中の変更は、最初から作り直すより高くつくことがほとんどです。プロジェクト全体の費用が当初見積もりの1.5〜2倍になるケースも珍しくありません。
コスト2：スケジュールの遅延
追加要件・変更対応が発生するたびに、リリース日が後ろにずれます。システムの稼働が遅れることで、業務改善の機会損失が生まれます。
コスト3：社内の信頼コスト
「IT化しようとしたのに、結局使えないものができた」という経験が社内に積み重なると、次のIT投資に対して社員が懐疑的になります。これは数字に表れないコストですが、長期的には最も高くつくものです。
発注前に用意すべき「要件整理の最低ライン」
完璧な要件定義書は不要です。まず以下の4点が言語化できていれば、開発会社との初回相談は進められます。
- 目的： このシステムで何の課題を解決するか（1文で）
- 利用者： 誰が、何人、どれくらいの頻度で使うか
- 必須機能： これがなければ意味がない機能（3つ以内に絞る）
- 完成の定義： どうなったら「成功」と判断するか
ディレクターが間に入ると何が変わるか
発注者と開発会社の間にITディレクターが入ることで、要件整理・ドキュメント作成・開発会社とのコミュニケーションを代行・サポートできます。
「要件定義って何から始めればいいかわからない」という状態からでも、一緒に整理することができます。