設計課題

システムに対する要件が、システムの構成要素（システム、サブシステム、アプリケーション、プログラム、コンポーネント、クラスやモジュールなどなど）に段階的詳細化に従って割り付けられていく。その際、構成要素の設計に対して設計課題や目標を割りつけるというときの要件とは、非機能要件だ。機能要件は課題や目標として取り上げていない。

もしかしたら、このあたりの誤解（根源的原因）が議論の齟齬を生んでいる可能性があるかもしれないと思い、少し書いてみる。

構成要素に割りつけられる機能要件はMustだ。目標がどうこうでなく必ず実現しなければならない。ユーザーが100個の機能を要望しているのに、設計段階で95個しか対応しないということはありえない。勿論、要件定義段階や以降のスコープ制御ではありえるが、そういったツッコミはなしでのこと。つまり、構成要素に対する設計課題という場合、機能要件ではなく、暗黙的に非機能要件のことを言っている。

FRUEMPなどのFunctionality(機能性)は機能充足性とでも呼ぶべき非機能要件だ。Functionality＝機能要件？を参照のこと。これは、100個の機能要件のうち95個しか対応していないので機能性＝95％ですというようなものではない。あくまで機能は100％を満たしていなければならない。機能性は、機能を100％を満たすためにそのトレードオフとして、犠牲となって失われる他の非機能要件の程度を示していると言える。たとえば、機能は満たしているがセキュリティが劣るとか、標準に沿ってないとかだ。無駄な認証が2回必要になったが機能は実現できたとか、コードはスパゲッティだが何とか動くといったことなのだ。FURPS+では制約も含めているので、定義によっては、機能を満たすためにコストを200万円上積みしなければならなかったというような状況も機能性の評価に含められるかもしれない。

設計では、どの抽象レベルの設計においても設計課題は設定される。アーキテクチャ設計は勿論だが、最小の構成要素のクラスの内部設計などのような構築設計においても、通常課題が与えられている。SWEBOKにも明示されている4つなどが代表的だ。あまりにも暗黙的に扱われ過ぎていて、課題として明示することなく、クラスの内部設計やコーディングが行われている。だから「何となく」行っているように感じてしまうのだろう。SWEBOKでは確か、複雑さの最小化、変更の予測、標準、テスト容易性を挙げていたと思う。これらは暗黙的な課題になってしまっているかもしれないが、本来ならクラスの内部設計やコーディングを担当者に割り当てる際には、設計課題として提示するべきものだ。特にオフショアだったら明示すべきだろう。機能を満たすだけではダメで、シンプルで分かりやすく、変更に対応しやすく、標準に沿っていて、テストしやすいように設計しコードを作成する必要があるということを明示する訳だ。

「何となく」設計や構築ができる人というのは、典型的な設計課題とその解法をノウハウ(暗黙知)として持ち得ているといえる。現在私がテーマとしているのは、こういった暗黙知をどうやって形式知として展開するかということだ。考えられることは、設計課題とその解法のセットを形式知のノウハウとして公開し、設計のタスクに対して明確な設計課題を提示し、さらにその設計課題から形式知ノウハウを参照できるようにしてやることだ。

きれいに話が繋がった。