要件定義書の必要性
独自のITシステムを導入する際に欠かせないのが「要件定義書」です。耳にしたことはあっても、中小企業では「時間がないから」「ベンダがやってくれるだろう」と軽視されがちで、結果として開発が迷走し、費用や納期が膨らんでしまうケースを数多く目にします。では、なぜ要件定義書が重要なのでしょうか。
１．要件定義書を作らないと何が起こるか
要件定義書を作らずに開発を始めると、最初の計画からつまずきます。システムのゴールが不明確なため、開発スケジュールを立てられず、着手そのものが遅れてしまいます。加えて「発注元が思い描いていた機能」と「ベンダが想定していた機能」が食い違い、後から修正が必要になり、工数・費用が膨らむことになります。
結果として、品質の低下、納期の遅延、追加費用の発生といった三重苦に陥るのです。さらに「期待した効果が得られない」という最大の問題も待っています。
私が発注先として関わったシステム構築プロジェクトでは要件が不明確で設計が思うように進まず大変苦労したことがあり、また、中小企業の発注元で要件を定められず開発が滞っていたり、使いにくいシステムを回収したいという状況はいくつも見てきています。
2．要件定義書の内容
要件定義書は、システムに求められる条件を整理し、発注元と開発ベンダが合意するための文書です。発注側が主体的にまとめてもよいですし、ベンダが主導しても構いませんが、最終的に両者が認識を一致させることが重要です。
典型的な構成は次の通りです。
- 文書情報（目的、対象範囲、関係者）
- システム概要
- 機能要件（処理フロー図の活用がおすすめ）
- 非機能要件（利用者数、セキュリティ、運用・保守）
- データ要件、外部連携、移行・導入要件
- 受入条件
- 付録（用語定義、参考資料）
特に見落とされがちなのが非機能要件です。例えば、社内専用の業務システムと一般消費者向けのECサイトでは、セキュリティ要件は大きく異なります。また、既存システムから移行する場合は、データをどう引き継ぐかを明確に記す必要があります。
こうした点を曖昧にしたまま開発を進めると、後戻りが困難になります。
3．問題が生じる要因と対策
（1）問題が生じる要因と背景
システム開発における問題の原因は、大きく分けて二つあります。
一つはベンダ側の実力差です。優秀なベンダであれば、要件定義が不十分であっても打合せの中で積極的に課題を指摘し、曖昧な点を解消してくれます。しかしすべてのベンダがそうとは限りません。
もうひとつは発注側の意識不足です。日本では「あいまいなまま進める」商習慣が根強く残っており、その結果、開発がベンダ主体となり、気づけば使いにくいシステムが高額で納品されるという事態が起こりがちです。
（2）中小企業が取るべき対策
こうした失敗を防ぐには、発注側も「自社に必要な要件を考える」姿勢が欠かせません。すべてを自社で完璧にまとめる必要はありませんが、少なくとも「どのような業務を効率化したいのか」「誰が利用するのか」「どんな制約条件があるのか」といった基本事項は整理しておくべきです。
その上で、必要に応じて専門家に相談し、要件定義書の雛形や検討プロセスを支援してもらうことも有効です。
4．まとめ
システム開発は一度走り出すと、途中での軌道修正が難しく、大きなリスクを伴います。だからこそ、発注側と開発側の認識を一致させる「要件定義」が必要不可欠なのです。
機能面だけでなく、運用やセキュリティ、移行方法までを含め、文書として合意しておくことが、結果としてコスト削減や効果の最大化につながります。
当事務所では、中小企業の立場に立ち、要件の整理や文書化のサポートを通じて、安心してITを活用できる体制づくりを支援しています。
ご興味がございましたら、こちらからお願いします。