ソフトウェア開発における、実現可能性を判断することの重要性
ソフトウェア開発をする上で、要求が実現可能か否かの判断は非常に重要です。その理由は、開発工程の後半のフェイズで実現不可能であることが発覚しても、後戻りがきかない場合があるからです。冷静に考えれば誰でも理解できることですが、なぜかこの手の失敗は多く発生しています。では、失敗しないためには、どのようなアプローチをすればいいのでしょうか。今回は、これに対するひとつの考え方をご紹介します。
1．求められていることは何なのか？
“求められていること”、これはソフトウェアを開発する上で非常に重要であると共に、必ず抑えるべきポイントです。これを外してしまうと実現可否以前に、要求通りのソフトウェアを完成させることができなくなってしまうからです。
求められていること＝要求事項です。
この要求事項は、分類すると以下のようになります。
上記の表は、ソフトウェアに対する品質属性モデルとして、米国ヒューレット・パッカード社の社員が提唱したモデルとして多くのエンジニアが参考にしています。モデルの分類項目の頭文字を取って、“FURPS+”と呼んでいるものです。
これらは、出来上がったソフトウェアを品質の観点から評価する項目ですが、逆に見ると、どのような出来上がりイメージのソフトウェアを開発すればいいのか、を検討する上で欠くことのできないものです。このモデルの分類項目についての要求事項を明確化することで、依頼者が“求めていること”に対して、齟齬がないソフトウェアを開発する基礎となる要求項目を洗い出すことが可能となります。
実際、要求項目の整理はそれほどたやすいことではありません。これらの分類に沿って、全ての利害関係者から要求を引き出すことは、非常に困難な作業となりますが、今回のコラムでは、その部分への言及は割愛させていただきます。
2．要求事項に対する実現可能性の判断
要求項目をソフトウェアへ正確に反映させるための手法が、ソフトウェア開発プロセスになります（厳密に言えば要求項目を引き出し、整理する部分も含みますが）ここでは、ソフトウェア開発プロセスそのものについての話ではなく、どのような開発プロセスであっても、要求項目に対する実現可能性を見極めるのに必要な概念を紹介します。
ソフトウェア開発エンジニアが、要求項目を分析してシステムとして動作させる視点としては、以下のような整理方法があります。これは、ソフトウェアのアーキテクチャを表現するビュー（視点）でシステムをモデル化することを意味しています。
この図は、RUP（Rational Unified Process：IBM社）の開発プロセス内で定義されているものです。今回のテーマである、ソフトウェア開発における実現可能性の判断については、ソフトウェア・アーキテクチャをどのように構築するかが重要なポイントとなります。上記の図と照らし合わせて解説していきましょう。
・ユースケースビュー
要求項目を表すビューです。ここでは、特に技術的なリスクに深く関係するユースケースを意味し、要求項目をユースケースを用いる前提で書いています。要求項目を他の手法で整理している場合も置き換えて考えることができます。
・論理ビュー
ソフトウェアの論理的な構造を表すビュー。代表的なモデルとしては、クラス図、シーケンス図などで表現されます。技術的なリスクに深く関連するユースケース（要求項目）をソフトウェアの論理構造としてどのように組み立てるかをモデル化することになります。ソフトウェアの論理構造には、前述のFURPS+も深く関わり、性能、保守性、制約事項などがソフトウェア構造を左右する場合があるので、それらとの整合性が保持できているかも重要となります。
・実装ビュー
論理ビューでモデル化されたソフトウェアが、どのような物理的コンポーネントになるのかをモデル化し、その関係を表したものです。論理ビューでは、あくまでもソフトウェアの論理的な関係を表現したものですが、そのモデルが実際にはどのようなコンポーネントになるかを表現したものです。
・配置ビュー
実装ビューでモデル化したコンポーネントが、動作するために配置されるノード（サーバなど）を表したモデルです。このビューもFURPS+との関係性が深く、分散された拠点での処理制約などがあれば、物理的な配置場所に影響を与えますし、性能や信頼性などの要求項目も実際の配置場所に対して強く影響する場合もあります。よって、FURPS+の分類で整理された要求項目との整合性が重要になります。
・プロセスビュー
配置されたノード（サーバなど）内で、ソフトウェアがどのような処理形態で動作するのかをモデル化したものです。例えばソフトウェアの並行処理性と処理の多重度を明確にモデルとして表現します。これは性能面や信頼性に対する要求項目と密接に関係しているので、FURPS+との整合性が重要になります。
3．最後に
要求項目をソフトウェアで実現できるのかを検討する場合、4＋1ビューの論理ビューのみの検討では、要求事項を満たすことのできないシステムを作ることになります。要求項目の機能（Functionality）を実現することに終始すると、結果として論理ビューを中心にソフトウェア開発が実施され、その他の要求項目（非機能要件）が抜け落ちてしまうのです。
非機能要件とは、FURPS+の中の“F”以外全てです。使い易さ、信頼性、性能、保守性、制約事項の要求項目が欠落したシステムは、たとえ機能的には要求項目を満たしていても、“使えるシステム”ではありません。
また、要求項目を実現する4つのビューでシステムをモデル化することで、異なる要求項目の間でシステム的に成立し得ない問題を明確にできます。例えば、多くの拠点で利用されるソフトウェアにおいて、各拠点に分散せざるを得ない要求項目と非常に高いレベルの性能を求められた場合、この異なる要求項目が両立し得るかは、4つのビューによる分析から導き出すことが可能です。つまり、4つのビューは、ソフトウェアの構造（アーキテクチャー）を作り出す上で必要となるビュー（視点）を整理したものであり、ソフトウェアの基本的構造を確立させる作業を開発工程の早い段階で実施することで、要求項目が実現できることか、できないことかを明確にできます。
よって、FURPS+で分類された要求項目に対して4＋1ビューでモデル化することで、正しい実現可能性の判断を促すことになります。