見積もり仮想体験、準備から始めるべし：プロジェクトの闇、見積もりに光を！（2）（1/2 ページ）

見積もりに必要な情報とはどのようなものだろうか？ 具体的なシステム・モデルを例題として見ていこう。

見積もりを行うための準備

　前回の「見積もり、まずはざっくり理解せよ」では、「ソフトウェア開発のプロジェクトとひと口にいっても、（中略）見積もりの対象の要素が異なるソフトがたくさんあります」と書き、「ソフトの特性によって使うべき見積もり手法も分かれるのが普通」と紹介しました。

　それらの見積もりの手法を試し、尺度を用いて見積もりを実際に作っていくための準備をしましょう。

　今回は、アーキテクチャやシステム特性にあまりこだわらず、少し簡単なプロジェクトを題材にしたいと思います。

　機能の広さや、タスクの深さ、品質の重さといった、前回の「見積もり、まずはざっくり理解せよ」の図のように、3次元の軸を考えながら見積もり作業を進めたいと思います（図1）。

図1　前回取り上げた図。立方体で機能の数である広さと作業（タスク）の深さ、非機能要件などの重さで、システムの大きさを表す

　今回は、見積もりの対象となるアーキテクチャを絞ります。

　読者の中で比較的多くの方が携わっているであろう.NETのWebアーキテクチャを用いたクライアント／サーバ型システム（Webベースのリッチクライアントのシステム）で検証を進めたいと思います。

見積もりターゲットのアーキテクチャは

　まず主要なアーキテクチャですが、以下のようになります。

• .NETとC#
• クライアント／サーバ型システム（リッチクライアント）
• SOAP通信
• Web管理画面（ASP.NET）

　これは業務管理システムです。また、今回分析の対象となるプロジェクトは、50人月以下の中規模以下のものを想定しています。

　このような事例としては、小さいのではと思う方もおられると思います。

　筆者はこれまで、数百人月?数千人月のプロジェクトの運営にも携わってきました。しかしながら現実問題として、そういった重要プロジェクトに位置付けられるような規模のプロジェクトで、見積もりやスケジューリングをする機会に恵まれるプロジェクトマネージャ（PM）やシステムエンジニア（SE）は一部です。むしろ、多くのPMやSEが見積もりの機会に巡り合うのは、10人以下のチームで数カ月で構築するようなプロジェクトではないでしょうか。

　また、ある程度規模のあるプロジェクトとなると、RFP的な前提事項を説明するだけで、記事2回分ぐらいはありそうですし、見積もり手法の全体像を俯瞰（ふかん）するだけでも大変なことになります。モデルは、シンプルで簡単な方がいいのです。

見積もり要素をRFPから確認

　基本的にはWebとクライアント／サーバ型システムを併用した業務管理システムです。

・システム名：ICカードによる情報管理システム

　ある部屋の利用者は会員証として受け取ったICカードをPCに接続されたリーダにタッチすることで入室情報が書き込まれます。その入室情報は管理者と本人にメールで通知されます。

　ただし、PCを操作する前、そもそもその執務室に出入りするための物理的な電子錠の解錠などはシステムと関係なく行われますので、システムの範囲外とします。

　管理者は、Webからその情報を管理することができます。具体的には、端末（入室時の）の利用や停止、会員の利用可否などです。会員登録自体は会員登録用のアプリケーションが入室時に利用するPCにインストールされており、PCから行います。端末のネットワークや表示画面などの設定も、この管理機能から設定できます。

図2　今回実際に見積もりをしていくシステムの概念図

　特殊な見積もりの要件として「デバイス制御」があります。ただし今回はドライバが提供されているので、その部分は見積もりの範囲外です。ただし、そのドライバを呼び出す形でデバイスと情報のやりとりを行わなければいけません。