要件定義後の設計・開発工程でも発注者の主体的関与は不可欠【第5回】

基本設計（外部設計）

　プロジェクトの骨格を定める工程です。要件定義で明確にした機能や要求に対し、それらをどのように実現するのかを具体的に定めるのが目的です。具体的には、要件定義で決まった機能について、機能単位で詳細化を進めていきます。基本的な設計内容には次のようなものが含まれます。

●画面設計：画面のレイアウトや画面間の遷移（画面遷移図）を整理します
●データベース設計：システムで利用するデータのテーブルを定義します
●インフラ設計：サーバーの概要やネットワーク構成、セキュリティ対策などを技術的な観点からの設計します

　基本設計を通じて、システムが持つべき機能や構造を明確にし、後の詳細設計のための準備を整えます。一般に基本設計の段階では、プロジェクトのワイヤーフレームやモックなどが作成され、初めて具体的なプロジェクトの形が可視化されます。ただし、この段階で「ゴールが思っていたものと違う」という認識のズレが生じると、その後の手戻りが大きくなります。

　当社の例では、ワイヤーフレームを要件定義の段階から作成することがあります。仕様の検討と同時に視覚的な形を確認することで、設計工程に入ってから「思っていたものと違う」という重大な認識のズレが発生するのを減らすためです。

詳細設計（内部設計）

　基本設計で定めた内容を、開発エンジニアがプログラミングで実装できるレベルにまで、さらに具体的に落とし込む工程です。設計内容には次のようなものが含まれます。

●処理フローの定義: 画面操作やデータ更新などの要求に対し、システム内部でどのような手順で処理が進むのかを示す「処理フロー」を具体的に設計します
●データの受け渡し: 画面とサーバーの間でデータをやり取りするための方法を定めます
●エラー処理: 想定外の事態（エラー）が発生した場合の処理フローを明確にします

　基本設計だけでも開発は可能ですが、基本設計と詳細設計はシステム品質を担保する上で欠かせない工程です。詳細設計があいまいだと、開発エンジニアが迷いながらコーディングすることになり、品質の低下や、その後の大きな手戻りにつながるリスクが高まります。

発注者の心構え

　設計工程において基本設計は特に、プロジェクトの骨格を決める極めて重要なフェーズです。それだけに発注者は、要求定義までの工程同様に、開発ベンダーとの積極的なコミュニケーションを図ることが重要です。

　具体的には、開発ベンダーが作成した基本設計書、とりわけ画面設計や画面遷移の成果物を、最終ユーザーの視点に立って徹底的にレビューしなければなりません。この段階で「こんなはずではなかった」という懸念や要素を残してしまうと、後の工程での手戻りコストが膨大になるからです。

　提示された設計案について、技術的な実現の可否や、それがユーザーに与える影響についても、開発ベンダーと深く議論を交わし、認識のズレを解消することも不可欠です。

　基本設計工程における発注者側のレビューの質と積極性が、その後のプロジェクトの成功を左右し、ひいてはベンダーとの信頼関係を築く上で非常に重要な要素になります。