提案書評価のポイント

2. 設計力を評価する

提案書にも設計は書かれる

提案書からどうやって設計力を評価することができるのかと疑問に思われるかもしれませんが、提案書にも「設計」は書かれています。もちろん、実際の設計工程で書かなければならないような詳細なことまでは書かれていませんが、開発企業は提案書を作成するにあたって簡易な設計を行い、その結果を提案書に反映しているはずです。

まず、本サイトが対象としている開発は通信・ネットワークシステムの開発ですから、提案書にはシステムのネットワーク構成について書かれているはずです。開発企業がなぜネットワーク構成を書けるかというと、RFPに書かれている要求を元にして簡易なネットワーク設計を行うからです。

また、システムに実装する具体的な機能についても書かれているはずです。もっとも、提案書の段階ではそれほど深くはブレークダウンされていませんので、それでは設計力は読み取れないのではないかと思われるかもしれません。ですが、管理機能というタイプの機能について書こうとすると、提案書の段階でも一定のブレークダウンが必要となります。ここで設計力が評価できます。

そして、きちんとした開発企業であれば、非機能要求（性能や信頼性などに関する要求）をどのように実現するかについても提案に織り込んであるはずです。これは簡易な非機能設計を行うということに他なりません。

ネットワーク設計の理解度を評価する

先にも述べた通り、開発企業が提案書を書く際には簡易なネットワーク設計を行い、それを提案のネットワーク構成に反映しているはずです。ここでチェックすべきことは、開発企業がなぜそのようなネットワーク構成を提案したかという理由です。ネットワーク構成には、どのようなノード（機器）をどのようにネットワーク上に配置し、それぞれのノードにどのような役割を持たせるかということが定義されているはずです。そして、それらにはなぜそのようにしたかの理由があるはずです。その理由をチェックしてください。提案書に理由まで書かれていない場合には、ヒアリングしてみると良いでしょう。

極端な話をしますと、システムにはたった一つのノードがあり、すべての機能・役割を一つのノードに持たせてしまうという設計もあり得るわけです。その設計には構成が単純になるという大きなメリットがあります。反対に、ノードの数が増えれば増えただけ複雑性が増していきます。したがって、ノードを複数にして役割を分ける、ノードの数を増やすといった設計には、複雑性を増してでもそれを選択するという合理的な理由が必ずあるはずで、開発者はそれを説明できるはずです。裏を返せば、なぜそのようなノード構成にしたのかを合理的に説明できない開発企業は、深い理解のないままにネットワーク設計を行っている可能性があると言えるのです。

なお、ノードを複数にして役割を分ける、ノードの数を増やすという設計の合理的理由になり得る事情としては次のような例が挙げられます。もちろんこれらに限定されるわけではなく、合理的な説明ができるかどうかかが重要となります。

大分類	具体例
物理的理由	空間上の制約がある 例えば、携帯電話の基地局は電波の到達範囲の制約があるため、サービスエリア内に多数設置する必要があります。
	通信帯域上の制約がある 例えば、携帯電話の基地局は一台あたりの通信帯域に上限があるため、人口密度が高い地域では基地局を密に多数設置するという設計が必要になります。
	装置の物理的性能に限界がある 大規模サービスを行う場合、一台の装置では求められるパフォーマンスを実現できずにノードの多数化による負荷分散を図らねばならない場合があります。
社会的理由	利用場所に関する要求がある 例えば、銀行ATMシステムの場合、お客様であるユーザの便利さを実現するためには、ATM端末をあちこちに配置しなければなりません。
	オペレーションを集約させたい 例えば、多数設置された機器でユーザの認証を行う場合、オペレーションの省力化のために認証情報を集約して取り扱う認証サーバを立てることが多いです。
	複数の設置者・管理者が存在する 例えば、独禁法上の理由でインフラ設置者とサービス提供者を分離しなければならないシステムでは、インフラ管理の機器とサービス提供の機器を分離する設計を行います。
	何らかの標準規格に準拠した製品を作りたい 標準規格によっては、機器構成が指定されている場合があります。なお、標準規格の背景には相応の物理的、社会的、もしくは技術的な事情があります。
技術的理由	データ同期に技術的困難がある 例えば、銀行ATMシステムを考えた場合、多数の端末間で出納データの同期を取ることは容易でなく、集中管理を行う中央サーバを立てる設計が合理的です。

表1. ノードの分割を行う合理的理由の例

管理機能設計の熟練度を評価する

通信・ネットワークシステムが持つ機能は、利用者がシステムを利用することで実現したいことを形にした機能（以下、メイン機能）と、それとは別にシステム自体を管理するために必要となる機能（以下、管理機能）とに分けることができます。提案書の段階でシステムの管理機能についてどこまで想定できているかは、開発企業が通信・ネットワークシステムの開発にどの程度熟練しているかを測る一つの指標になります。メイン機能の方はまさに発注者が実現したいとRFPに書いていることそのものの機能ですので、ほとんどの開発企業はメイン機能についてはしっかりと提案書に盛り込みます。しかし、通信・ネットワークシステム開発の経験が豊富とはいえない開発者の場合、提案書や開発初期の段階では管理機能の検討が不足しがちになります。そうすると、開発がかなり進んだところで管理機能の検討が不足していることに気付いて大慌てする、といった事態に陥ってしまいます。

一般的な通信ネットワークシステムの場合、下に挙げたような管理機能は必要性も含めて検討しておく必要があるでしょう。提案書の段階でこれらの管理機能についてきちんと言及できていれば、その開発企業は通信・ネットワークシステムの開発に熟練している可能性が高いと言えます。

管理機能	説明
システムの立ち上げ	構成ノードの立ち上げ順序は任意で良いのか、といったことは検討されるはずです。
システムの停止	いきなりシステム全体を停止するのではなく、提供中のサービスを安全に終了してから停止するといった配慮が求められるケースは多いでしょう。
サービスの一時停止と再開	メンテナンス等のためにサービスを一時停止できる機能が求められるケースも少なくありません。
システムのパラメータ変更	サービスを止めずにシステムのパラメータを変更する機能が要求される場合には、あらかじめ設計上の配慮をしておくことが必要です。
通信経路の監視	高い信頼性が要求されるシステムでは、ノード間の通信断がないことを監視する機能が求められます。通信断検出時の動作も検討が必要です。
ノードのパフォーマンス監視	高負荷が予想されるシステムでは、各ノードのパフォーマンス（CPU使用率、メモリ使用率、ディスク使用率など）を定常的に監視する機能が求められます。高負荷検出時の動作も検討が必要です。
構成ノードの再起動	一部のノードのみを再起動するとデータやステート（状態）の同期が失われるケースがあり、特別な配慮が必要となることが少なくありません。
構成ノードのプログラム更新	機能追加や不具合修正などの可能性があるため、運用中のプログラム更新に関する検討が必要です。その際、一時的にバージョンが一致しないノードが混在してしまう可能性への配慮が必要です。
構成ノードの追加	同種のノードが複数存在するシステム（例えば、基地局が多数存在する携帯電話システムなど）では、そのノードの追加についての検討が必要です。多くの場合、システムを止めずに追加できることが求められるでしょう。
構成ノードの削減	追加と同様に、メンテナンス等でノードの削減（切り離し）が行われる可能性についても検討しておく必要があります。

表2. 多くのシステムで求められる管理機能の例