システム

ここでは、語られることが比較的多い設計開発プロセスについては後述することにして、まずは「準備がすべて」と言い切ることができる当代一流のアスリートたちに倣い、多少大袈裟な表現をもって設計開発に対する私たちの考え方を述べたいと思います。

「システム設計開発の半分は、設計開発の開始以前に終わっている。」

システム設計開発を成功に導くために、設計開発それ自体と同じか、それ以上に重要だと考えられているプロセスが存在します。それは、設計開発する対象である顧客の要求を明確に理解する、という段階であり、これはシステム設計開発では一般に、要求獲得、および要求定義と呼ばれるプロセスです。実際には、要求を理解するだけでは十分とは言えないことが多く、要求の優先順位を付けると共に、体系化し、仕様化とモデリング化を行い、検証し、妥当性を検討します。要求の無矛盾性、一貫性を保つために、顧客に要求の一部修正を願う必要性に迫られることもあります。要求対象の前に、要求自体を設計する、という言い方もできるかも知れません。

何故、この要求定義プロセスが重要かと言えば、要求定義は設計開発の上流プロセス、上位レイヤに位置する概念であること、そしてシステムの機能要求や非機能要求と言ったレベルでは洩れることがある、顧客のビジネスレベルでの要求をも含めた妥当性の検討を可能にすること、などが理由として挙げられます。例えば、システム設計開発を大幅に遅らせてしまう要因の一つに、仕様変更があると言われています。仕様変更は概して後になってから上流から下りてくるものですが、上流における間違いを下流において訂正することは困難を極めることがほとんどです。それに対する根本的な解決策として、先立って適切な要求を定義することが有効であり、手戻りのリスクをかなり小さくすることに貢献します。
※要求定義プロセス、および要求の分類種別の理解にはBABOKが参考になります。
※要求が明確に定義できない場合、プロトタイピング、またはアジャイルな設計開発から始めるというアプローチもあります。

筋の良いシステム設計開発を行うためには、設計開発内容や設計開発プロセスにフォーカスを合わせるだけでは不十分です。私たちは顧客のソリューション要求（機能要求、非機能要求）を理解し、それをビジネス要求から考えても妥当な形に近付けられるよう、顧客との対話による継続的な理解を常に心がけています。言うなれば要求定義プロセスは、設計開発に先立つ品質の作り込みとも言えるものではないかと考えています。

要求定義・設計ツール、テクニック

• ブレインストーミング、ビジネスルール（オペレーション）分析、機能分解、インターフェイス分析、インタビュー、非機能要求の分析、観察、問題のトラッキング、要求ワークショップ、リスク分析、根本原因分析　ほか
• データフロー図、データモデリング、プロセスモデリング、シナリオとユースケース、シーケンス図、状態遷移図、状態遷移マトリクス　ほか
• 見積り、ベンチマーキング、メトリクスとKPI、プロトタイピング ほか

要求定義では上述したようなツール群を駆使し、分析、モデリング、評価することによって、文章だけで記述するよりも分かり易く理解し、説明することができます。