分散開発管理のポイント

2. 拠点間の分担のポイント | 4. 拠点間のコミュニケーション管理

3. 真っ先にすり合わせるべきこと

組織が異なれば暗黙の前提が異なる

開発には複数の人々が関わる以上、コミュニケーションが上手くいかなければ開発は上手くいきません。コミュニケーションがうまくいかないケースの原因としては、コミュニケーションの量が不足している場合と質がよろしくない場合とがあるでしょう。コミュニケーションの質が悪くなる原因として、コミュニケーションを行う当事者間で「暗黙の前提」が共有できていないというケースがしばしば見られます。自然言語を使うにせよ何らかのダイアグラム(図表)を使うにせよ、コミュニケーションには暗黙の前提が必ず存在します。だからこそ、UML(Unified Modeling Language、統一モデリング言語)などでは表現の標準化を行い、システム開発・ソフトウェア開発に関わる人々の間で「暗黙の前提」を広く共有できることを目指しているのです。ただ、現時点では暗黙の前提の共有に問題がないレベルにまでUMLが広く、そして深く浸透しているとは言い難い状況です。

一つの組織内で開発が閉じている場合、この問題はさほどの大きな問題にはならないことも多いでしょう。その組織の構成員がある程度定着的である場合には、それまで行ってきた開発経験を通じて、それなりに暗黙の前提が共有されているものです。また、コミュニケーションの質の問題を量(時間や密度)で解決するといったことも行いやすいでしょう。しかし、分散開発では大きな問題になることが少なくありません。それぞれの拠点はそれぞれの経験を通じて、それぞれ異なる暗黙の前提を持つようになっているはずです。また、それをコミュニケーションの量で埋めることも容易ではありません。ですので、開発の初期の段階で暗黙の前提について拠点間ですり合わせておく必要があるのです。

図1. コミュニケーションと暗黙の前提

設計思想をすり合わせる

通信・ネットワークシステムの開発を行う際にすり合わせておかなければならない「暗黙の前提」として、設計思想があります。設計思想というのは、「どのような考え方で設計を行っていくのか」という設計の基本となる考え方・方針のことです。と言ってもなかなかイメージができないでしょうから、具体的に説明をすることとします。

通信・ネットワークシステムの設計で大きな工数がかかり、かつ難易度も高いのは、異常系やバリエーションケースの設計です。正常系の設計はさほど難しくないケースがほとんどです。しかし、通信・ネットワークシステムでは数多くのノードが独立して動作することになるため、ノード間の同期が常に取れているとは限らず、無数の異常系やバリエーションケースが存在することになります。この無数にある異常系やバリエーションケースの設計をどのように行うかについては、少なくとも2つの異なる考え方(設計思想)が存在します。

一つ目の設計思想は、「列挙型設計」です。この設計思想は、異常系のケースやバリエーションケース各々について、各ノードが行うべき動作を個別に設計していくという考え方です。ですので、この設計思想に基づく設計ではすべての起こり得る状況に対して個別の設計が必要となるため、膨大な量の設計が必要になります。一方で、状況ごとに動作をきめ細やかに定義できる、異常家やバリエーションケースの動作が一目で分かりやすいといったメリットがあります。

図2. 異常系・バリエーションケースの列挙型設計

そしてもう一つの設計は、「ポリシーベース設計」です。この設計思想では、異常系のケースやバリエーションケース各々について個別に設計を行うということは原則として行いません。その代わりに、異常系やバリエーションケースを分類できる包括的なカテゴリを定義し、カテゴリごとに行うべき動作の指針(ポリシー)を定義します。こうすることで、膨大な量の設計を行わなければならないということは避けられ、工数の抑制につながります。一方で、異常系やバリエーションケースの動作が一目では分からない(ポリシーを解釈して考える必要がある)といったデメリットもあります。また、設計の性質上、状況ごとのきめ細やかな動作定義は原則としてできないため、異常系やバリエーションケースの動作をできるだけ共通化していくと言った設計方針の際に使いやすい設計思想であると言えます。

図3. 異常系・バリエーションケースのポリシーベース設計

通信・ネットワークシステム開発においてどのような設計思想を採用するかについては、開発の始めの段階で拠点間での認識合わせを行っておく必要があります。なぜなら、設計思想が異なればソフトウェアの内部設計(基本構造)が異なってくるからです。列挙型設計に適したソフトウェアの基本構造と、ポリシーベース設計に適したソフトウェアの基本構造は異なります。上流設計を行う拠点とソフトウェア設計を行う拠点とで考えている設計思想が異なると、ここにミスマッチが生じてしまいます。

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

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

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

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

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