物理上のシステム構成物と論理上のシステム構成物
システム開発における成果物について整理をしたい。
上記の記事で、システムとは何かについて、紹介した。記事内の図では、サブシステムとサブシステムが通信線によりつながっていて、一つのシステムを構成している。今回は、より具体的な例として、これらのシステムを、物理上のシステム構成物として示したい。下記図[論理上のシステム構成物欄]は、PCの情報をモニタに表示するシステムである。PC側で作成した映像情報を、通信線を介してしてモニタに転送し、モニタ上で映像情報を表示させるシステムである。サブシステムとしてモニタが配置されており、もう一つのサブシステムとしてPCが配置されている。二つのサブシステムは、通信線によって接続されている。
これらのシステムを実現するために必要な設計書は何かについて考えてみたい。そのために、まず物理上のシステム構成物を、論理上のシステム構成物に置き換えてみることとする。下記図[論理上のシステム構成物欄]が、物理上のシステム構成物を、論理上のシステム構成物に置き換えた結果だ。物理上のシステム構成物としてのサブシステム(モニタ)は、ハードウェアと、ハードウェアに組み込まれるソフトウェアに置き換えられた。同様に、物理上のシステム構成物としてのサブシステム(PC)は、ハードウェアと、ハードウェアに組み込まれるソフトウェアに置き換えられた。通信線はハードウェアに置き換えられた(通信線には、ソフトウェアは存在しない)。そして、サブシステム(モニタ)のハードウェア、サブシステム(PC)のハードウェアは、ハードウェア(通信線)を介して、接続されている。
このように置き換えてみると、必要な設計書が明確になってくる。少なくとも必要な設計書は、①サブシステム(モニタ)のソフトウェア設計書とハードウェア設計書、②通信線のハードウェア設計書、および、③サブシステム(PC)のソフトウェア設計書とハードウェア設計書となる。これらがあれば、少なくとも実装はできるようになる。
しかしながら、これらの設計書があれば、システムが作れるかというと、NOである。これらの設計書は、実装をするための設計書であり、顧客が求めるシステムを実現することを第一目標とした設計書ではないのだ。通常、顧客の要件定義書に記載された要件を満足するために、システムはどのような振る舞いをしなければならないのか？については、システム全体という観点で設計書が作成されなければならない。そのような設計書は、システム設計書と呼ばれる。今回の例では、さらに必要な設計書として、④システム設計書、⑤サブシステム(モニタ)設計書、および、⑥サブシステム(PC)設計書がある。システム設計書で記載することは、サブシステム間がどう連携し、システムを動作させるのかという点であり、サブシステム設計書で記載することは、ソフトウェアとハードウェアを、どう連携させ、サブシステムを動作させるのかという点である。
論理上のシステム構成物における設計成果物の全体像
システム開発として必要な成果物を再度整理したい。下図は、二つのサブシステムからなるシステムの成果物定義をしたものだ。サブシステム内では、ハードウェアの上にソフトウェアが載っている(下図では、便宜上、ハードウェアの隣にソフトウェアを配置している)。二つのサブシステム間はハードウェア、すなわち、物理的な通信線によって接続されている。これらのシステムを実装するためには、まず、ハードウェア、ソフトウェア、それぞれに対する設計書が書かれなければならない。そして、ハードウェアとソフトウェアを組み合わせて動かすためのサブシステム設計書もなければならない。また、サブシステム同士を組み合わせて動かすためのシステム設計書もなければならない。従って、必要な設計書は、システム設計書、サブシステム設計書、ソフトウェア設計書、ハードウェア設計書となる。
読者の中には、設計書がとても多いと思われる方もいるかもしれない。しかしながら、このような層別で設計書を作らねば、成果物の抜け漏れを出してしまう可能性があるのだ。大きなシステムになってくると、ソフトウェアの担当やハードウェアの担当が分かれてくる。担当が分かれてしまうことにより、ソフトウェアとハードウェアの責務領域がしっかり事前に協議されぬまま開発が進んでしまい、作るべき設計書が作られていなかったということがあり得るのだ。いわゆる、設計のお見合いだ。この設計書はソフトウェア領域で作るべし、この設計書はハードウェア領域で作るべし、ということを示す上位の設計書が必要なのだ。通常、このような設計書は、システム設計書と呼ばれる。ソフトウェアを作るためでもなく、ハードウェアを作るためでもない、システムを作るための設計書であり、ソフトウェア設計書とハードウェア設計書の上位に位置する。
ソフトウェア設計書とハードウェア設計書の間で起こる問題は、サブシステム間でも発生する。サブシステム内に閉じる領域をしっかり設計したものの、サブシステム間の通信領域については、どちらが主導的に話を進めるのか、という点で揉めることがある。この場合においては、サブシステム担当に責務はなく、サブシステムの上位に位置する、システム担当に責務がある。責務といっても、やることはシンプルであり、システムを実現するために書くべき内容を設計書として書くだけである。サムシステム間の通信の例では、通信ケーブルとして何を採用する、通信規格として何を採用するとだけ書いたものでもそれは立派な設計書だ。
「設計のお見合い」を防ぐためには、要件を実現するために、何をしなければいけないのか？という観点で、段階的に設計書をブレークダウンしながら作っていくとよい。まずシステム設計書を作成し、サブシステムが、それぞれ、何をやるのかを決める。次にサブシステム設計書を作成し、サブシステムとして何をやるのかを明確化する。その次に、ソフトウェア設計書とハードウェア設計書を作成し、ソフトウェアとハードウェアを実装できるまで、内容を詳細化する。このような手順で、システムの具現化に向けて、設計書を拡充させていくことで、考慮もれのない設計ができるのだ。「要件を実現するために」という意識をもって、設計をしよう。
ちなみに、これらのシステム開発成果物は、下記記事のV字モデルと整合が取れるように、定義されている。参考として、ご一読いただきたい。
