不明確な仕様

▼

勘所４

開発作業に着手する前に、十分な工数をかけて要求を分析・評価し、要件定義を明確にすべし。

背景

プロジェクトが失敗する、あるいは開発段階でトラブルが起こる最も大きな要因は「不明確な仕様」にあります。

システム開発では、顧客の業務をビジネスモデルに落とし、そこからシステムモデルに転換してプログラムコードを生成します。
ビジネスモデルを作る段階でどんな機能を持たせるかの要求からシステム要件を決めます。

この時、要求が曖昧であると、後工程で要求に合わないということから手戻りが発生し、長時間労働発生のリスクが高まることになります。

解決策

この問題への対応は、「発注者は何が目的か」、「どういう機能が必要か」というシステム構築における顧客の要求を明確に定義し、それをシステムに正しく反映させることにつきます。
問題はそれを、どのように進めるかです。
以下は、そのための役立つ工夫や施策です。

解決策１

開発作業に着手する前の工程で仕様を分析・評価し、要件定義を明確にするため、仕様のひもとき作業に十分に時間を費やすこと。
プロトタイプを作成し要件定義の精度を上げることも有効です。

解決策２

発注者が業務を理解しているかどうかを確認したうえで、対応策を考えること。
また、プロジェクトに顧客の業務に精通する人材を配置することも重要です。

解決策３

要件が明確に定義できないときは、要件定義と設計開発を分けて契約し、設計開発の見積もりは要件が明確に定義されてから行います。

解決策４

システム構築における顧客の要求を科学的に定義し、システムに正しく反映させる方法や考え方については、一般社団法人情報サービス産業協会がまとめた「要求工学知識体系（REBOK）」が参考になります。
この体系が示す顧客の要求を獲得・定義・検証・管理するプロセスを実践することで要求仕様の曖昧さをなくし、要件を明確にすることが出来ます。

ヒントとなる取組事例

■株式会社ユビキタスの取組

顧客のスキル・レベルに応じて（特にIoT関連で製造業の顧客のネットワーク技術レベルは高くない）、プロジェクトの前行程において、リスク対応の一環として仕様のひもとき作業に時間を費やし、要件を確定することが重要です。
顧客がIT技術に習熟していない場合、仕様書の完成度が高くないため、責任の所在と対策を明確にするためにQ＆Aを準備して疑問点について一つ一つつぶしていきます。
仕様のひもとき作業は、仕様書を熟読して疑問点を洗い出し、実現可能性の検討（フィジビリティスタディ）に時間をかけます。
プロジェクト計画書作成段階でWBS（ワークブレークダウンストラクチャ）を起こすことになりますが、いかに仕様詳細レベルまで記述するか、要求仕様を精査して疑問点を徹底的にクリアにすることが必要です。

■TDI プロダクトソリューション株式会社の取組

新規案件は、仕様が曖昧のため、要件定義、設計段階のフェーズごとに契約を締結しました。
また、長年継続している案件では、特殊分野の技術・知識が必要であり、それらを習得している人材の知見や経験から作業手順等のマニュアル化を進め平準化をしています。

リストに戻る

MENU

不明確な仕様

開発作業に着手する前に、十分な工数をかけて要求を分析・評価し、要件定義を明確にすべし。