開発工程管理のポイント

1. 開発工程管理の考え方 | 3. 実装工程管理のポイント

2. 設計工程管理のポイント

設計工程を適切に定義する

設計工程を管理についても、工程をブレークダウンするという基本は変わりません。設計工程と言っても、通常はいくつかの段階があるはずです。よく目にするのは「基本設計」「詳細設計」という設計工程定義ですが、通信・ネットワークシステム開発の場合には必ずしも適切ではありません。下の図に描いた通り、通信・ネットワークシステムは多層の構造を持っています。階層ごとに設計が必要ですので、設計工程の定義は階層の数だけ行われるはずです。もちろん、対象となっている開発のスコープがどの階層までかに応じて、設計工程のどの部分から管理しなければならないかが変わってきます。システム全体が開発のスコープであればシステム設計から全てが、ノードが開発のスコープなのであればノード設計以降が管理の対象となります。

※設計工程定義の考え方については、[適切な工程定義ができているか]にも詳しい説明がありますので、合わせてご覧ください。

適切な設計工程の定義は、上流から「システム設計」「ノード設計」「ソフトウェア設計」「モジュール設計」といった定義になります。

図1. 通信・ネットワークシステム設計の階層構造

このように適切な工程定義ができると、設計工程の管理は少し分かりやすくなります。「基本設計」「詳細設計」という工程定義の仕方では、「現在、基本設計を推進中」という進捗報告を受けたときに、まだシステム設計の段階なのか、ソフトウェア設計くらいまで進んでいるのかといったことが全く分かりません。適切な工程定義を行うだけでも、それくらいのことまでは容易に把握できるようになるのです。

設計すべき要素を明確にして管理する

適切な設計工程の定義ができたら、次に行うべきことは各工程で何を設計すべきかを明確にすることです。何を設計すべきかができていないと、進捗率を担当者に自己申告させるなど、各工程の進捗状況は担当者の「勘」のみに頼って行わなくてはならなくなります。そのような管理方法では、進捗率があるところからなかなか先に進まなくなるといったことがしばしば起こります。これは、担当者自身が初期の段階で「何を設計すればこの工程が完了するのか」を把握できていないことが原因です。進捗率の定義は、(既に完了した作業の量)÷(全体でやらなければならない作業の量)です。したがって、「全体でやらなければならない作業」すなわち「何を設計すればこの工程が完了するのか」をきちんと把握できていなければ、そもそも進捗率を出すことなのできないのです。

図2. 設計すべき要素が明確でないと進捗率は出せない

ですので、設計工程を管理する際には、各工程のスタートの時点で設計すべき要素を洗い出しておくことが肝心です。通信・ネットワークシステムの開発に熟練した開発者であれば、各設計工程で設計しなければならない要素を予め把握している開発者も多いでしょう。その一つの例を、下の図に整理しておきます。そうでない場合には、遅くとも各設計工程の最初の段階で、その設計工程で設計すべき要素を開発者と話しながら整理してください。その上で、設計工程の管理は「設計すべき要素のうち、どれが完了していて、どれに着手できているのか」で行うとよいでしょう。

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

表1. 各設計工程で設計すべき要素の例

設計工程における進捗管理の注意点

設計工程の進捗管理では、一つ特に注意していただきたいことがあります。それは、単純に「設計要素N個のうちM個が完了しているから進捗率はM÷Nだ」とはいかないことです。

設計工程においては、各要素の設計が厳密に逐次的なプロセスで行われるわけではなく、特に各設計工程の初期段階では「全体像を検討する」という作業が必要になります。システム設計を例にとって考えると、ノード構成の定義→ノード間のインタフェースとシーケンスの定義→各ノードの外部仕様定義というような厳密な逐次プロセスが実現できるわけではありません。ノード構成を決めるためにも、ノード間のインタフェースやシーケンスを考える上でも、各ノードのざっくりとした役割や機能は定義されていなければなりません。システム全体の設計イメージは一度に考える必要がありますし、各ノードの外部仕様の検討結果からノード構成やノード間のインタフェース・シーケンスにフィードバックがかかるといったことも起こります。とはいえ、担当者の「勘」のみに頼った進捗管理よりは正確な管理が行えるはずです。単純に「M÷Nとはいかない」ということに注意すれば、有益な進捗管理の指標となるでしょう。

図3. 設計工程の進捗率は単純にM÷Nではない

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

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

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

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

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