提案書評価のポイント

4. 見積もりの妥当性を評価する |

5. 計画案から開発推進力を評価する

開発の推進力とは何か

システムの開発を成功させるためには、開発企業に十分な技術力がなければならないことは言うまでもありません。しかし、技術的に優れていれば開発を成功されられるかというと、それだけでは不十分です。ごく小規模な開発であれば、優れた技術を持つエンジニア達があれやこれやとやりながら開発を成功させるということも可能でしょう。しかし、一定以上の規模の開発になると、そうはいきません。狭義の「技術力」とは異なる「開発の推進力」(プロジェクト管理能力を含む)がなければ、開発を成功させることはできなくなります。「技術力」と「開発推進力」の両方がそろって、初めて開発力があると言えるのです。

では、開発の推進力とはどのような力なのでしょうか。基本にあるのは、適切な計画を立てて、実際の開発状況と計画の乖離を正確に把握し、その乖離を解消して計画を遂行していく力です。開発途中で計画の見直しが必要になることもままありますが、その場合でも「計画→乖離の把握→乖離の解消」というフローに違いはありません。

これらのうち、開発状況と計画の乖離を解消する力については、提案書の段階で見極めることはなかなか難しいかもしれません。一方で、有意義な計画を立てる力と開発状況と計画の乖離を把握する力については、提案書からある程度は評価することが可能です。具体的には、提案書の開発計画で適切な工程定義ができているか、適切な成果物イメージができているかを見ることで、これらの能力を評価することができるのです。

図1. 開発を成功させるための要因

適切な工程定義ができているか

ウォーターフォールの要素を取り入れたシステム開発の場合、開発をいくつかの工程に区切って計画を立てます。インクリメンタルな開発であっても、一つ一つの反復それぞれに関しては、工程を区切って計画を立てることになるはずです。よって、適切な計画を立てられるかどうかは、適切な工程定義ができるかどうかに左右されます。一般には、「基本設計→詳細設計→実装→試験」のような開発工程の区切りをよく目にします。ですが、通信・ネットワークシステムの開発の場合には、闇雲にこのような開発工程の区切り方をするのは必ずしも適切ではありません。開発工程の区切り方、すなわち工程定義の仕方については、きちんと体系だった考え方があります。

通信・ネットワークシステム開発における工程定義の基本は、下の図の通りです。階層構造を持っていることに注目してください。

図2. 通信・ネットワークシステム開発の工程定義の基本構造

通信・ネットワークシステムは、図にもあるように、システムは複数のノード(機器)から構成されていて、ノードはいくつかのソフトウェア(OS、プロセスやタスク、ミドルウェア、共有ライブラリなど)から構成されていて、ソフトウェアはいくつかのモジュールから構成されていて・・・という階層構造を持っています。設計はこの階層ごとに行う必要がありますし、試験もまた同様です。システム設計をした結果、システムを構成する各ノードがどのような役割や機能を持つべきか(=ノードの外部仕様)が決まるのです。ノードの外部仕様が決まることで、外部仕様をどのようにして満たすのかの検討(=ノード設計)ができるようになります。すべての部分が上流(図中ではシステム設計)から下流(図中ではモジュール設計)へと一方通行に流れていくというわけではありませんが、工程の枠組みとしてはこのような構造になります。

提案書に書かれた計画を評価する際には、きちんとこの基本的枠組みを理解した上で工程定義をしているかを確認してください。必要に応じて、どのような意図で工程定義を行ったのかを開発企業からヒアリングするとよいでしょう。なお、常に上の図の通りの工程定義が行われるわけではないことにはご注意ください。工程定義にバリエーションが生じる要因の例については、次の表に整理しています。

要因例説明
開発スコープの範囲開発企業にとっての開発スコープが異なれば、どの工程からどの工程までを計画に盛り込むかは異なります。例えば、特定のノードの開発のみがスコープである場合、計画される開発工程はノード設計からノード試験までとなります。
サブシステムの存在複数のノードが連携してまとまった役割を果たす「サブシステム」を構成するような開発の場合、システム設計とノード設計の間に「サブシステム設計」の工程が入り、ノード試験とシステム試験との間に「サブシステム試験」の工程が入ります。
ソフトウェアの規模フトウェアの規模が大きくなると、ソフトウェアを構成するモジュールの規模も大きくなります。すると、単純にモジュール設計をしただけでは実装工程での飛躍が大きくなるため、モジュールをさらにサブモジュールに分割するという設計が行われることがあります。この場合、モジュール設計と実装の間に「サブモジュール設計」が、実装とモジュール試験との間に「サブモジュール試験」が入ることになります。
意図的な工程の省略・融合当サイトで説明した工程定義の枠組みを理解した上で、敢えていくつかの工程を省略もしくは融合する場合があります。例えば、杓子定規に工程を区切ると非常に小さな工程ができてしまいオーバーヘッドが大きくなるという場合に、小さな工程を他の工程と融合して一つにまとめるというケースがあります。

表1. 工程定義のバリエーション要因の例

適切な成果物イメージが描けているか

特に設計の工程について言えることですが、開発の状況を理解し、計画との乖離を正しく認識するためには、各工程での成果物に関するイメージが出来上がっている必要があります。成果物のイメージが出来上がっていないということは、何をすればその工程が完了となるのかが把握できていないということです。ゴールを把握できていないようでは、現状が計画に乗っているのかどうか、乖離があるとすればどの程度なのかといったことを正しく認識することはできないでしょう。

そこで、開発状況と計画の乖離を把握する力が開発企業にあるのかどうかを提案書の段階で見極めるためには、開発企業が各設計工程の成果物イメージを適切に描けているかどうかを確認してみてください。単に「○○設計書を作成する」というだけでは不十分です。各設計工程でどのような内容の設計書を行い、設計書にどのような内容のことを書くのかのイメージが出来上がっている必要があります。一般に、各設計工程で設計すべきことは次の図のような枠組みで考えることができます。

○○の設計工程に着目すると、前工程の成果物である○○要求仕様または○○外部仕様をINPUTにして設計が行われ、○○の内部設計と構成要素である△△の外部仕様が作られる。△△の外部仕様は、次工程である△△設計に投入される。

図3. 設計工程の基本的枠組み

システム設計のケースを例に考えてみましょう。システム設計のINPUTは、システムの要求仕様です。要求仕様を元にして、システムの内部設計としてノード構成、ノード間インタフェース(プロトコル)、ノード同士のシーケンスなどを設計します。そして、各ノードがどのように振る舞わなければならないかを各ノードの外部仕様として定義することになります。これは一例ですが、このようなかたちで開発企業が各設計工程の成果物内容について適切なイメージを持っているかどうかを確認してください。あくまで一例ですが、システム設計以外の設計工程についても、成果物内容イメージの例を次の表に整理しておきます。

設計工程成果物内容イメージの例
システム設計
  • システム内部設計
    • システムをどのようなノード構成で実現するのかを定義
    • ノード間インタフェース(プロトコル)を定義
    • ノード同士の相互作用をシーケンスなどで整理
  • ノード外部仕様(ノード毎)
    • ノードがどのように振る舞うのかを詳細に定義
ノード設計
  • ノード内部設計
    • ノードをどのようなソフトウェア(OS、プロセス/タスク、ミドルウェア、共有ライブラリなど)によって構成するのかを定義
    • 場合によってはハードウェアに関する事項を整理
    • ソフトウェア間のインタフェース(プロセス/タスク間インタフェース)を定義
    • ソフトウェア間の相互作用をシーケンスなどで整理
  • ソフトウェア外部仕様(ソフトウェア毎)
    • プロセス/タスクについては、どのように振る舞うのかを詳細に定義
    • OS、ミドルウェア、共有ライブラリなどについてはAPI仕様を定義(別途用意されている場合には不要)
プロセス設計
  • プロセス内部設計
    • プロセスにどのようなスレッドを立てるのかを定義
    • 場合によってはハードウェアに関する事項を整理
    • プロセスをどのようなモジュール構成で実現するのかを定義
    • スレッド間の相互作用をシーケンスなどで整理
    • モジュール間の相互作用をシーケンスなどで整理
  • モジュール外部仕様(モジュール毎)
    • モジュールがどのように振る舞うのかをAPI仕様を含めて定義
モジュール設計
  • モジュール内部設計
    • サブモジュールを定義する場合
      • モジュールがどのようなサブモジュール構成で実現するのかを定義
      • サブモジュール間の相互作用をシーケンスなどで整理
    • サブモジュールを定義しない場合
      • モジュールの内部処理を設計
  • サブモジュール外部仕様(サブモジュールを定義する場合のみ)
    • サブモジュールがどのように振る舞うのかをAPI仕様を含めて定義

表2. 各設計工程の成果物イメージの例

無料小冊子のお申込みはこちら

株式会社システム計画研究所のオフィシャルサイトはこちら

通信・ネットワークシステム開発に関するご相談はこちら

サーバ監視・ネットワーク監視ツール isNetSentry-S のサイトはこちら

信頼できるITシステムの開発と利用を支援する技術情報提供サイト「信頼のシステム開発.COM」はこちら