□------------------------------------------------------------------□
□　ＦＰ法を適用した見積りガイドラインの作成
□------------------------------------------------------------------□

---------------------------------------------------------------------
（設問ア）
---------------------------------------------------------------------
1.プロジェクトの概要
----
1.1.Ａ社発注システムの再構築
----
　Ａ社は東日本を中心に１００店舗を展開する中規模の
スーパーである。Ａ社の本社系発注システムは、９４年
に、ホストからクライアント・サーバーへのダウンサイ
ジングが図られていた。しかしながら、クライアント
ＯＳやミドルウェアの度重なるバージョンアップに伴い、
増加の一途を辿るＴＣＯにシステム部は強い抵抗を感じ
ていた。一方で、Ａ社経営戦略として西日本への進出が
決定された事から、業務システムにも再構築が求められ、
システム部としてはイントラネット化の方針を決定した。
　私はＥ社に勤務しており、Ａ社発注システムの再構築
について、営業時点より参画し、受注後はプロジェクト
マネージャとして設計・開発を指揮する事となった。
----
1.2.新しい見積り方法の確立
----
　一方で私の勤務するＥ社においては、以下の理由から
見積り方法の見直しが急務となっていた。
　a.プロジェクトの損益状況にバラツキが大きく、その
　　原因は、見積りの属人性にあることが判っていた。
　b.システムの短工期・小規模化に伴いプロジェクトの
　　数は増える一方で、ベテランクラスのＳＥを配置す
　　る事が難しくなってきた。
　c.社内で一般的に用いられていた見積り方法は、画面
　　数と画面当りの生産性によるものであり、多機能化
　　するクライアント・サーバや、イントラネットでは
　　誤差が大き過ぎる。
　このような背景から、Ａ社プロジェクトに携わるにあ
たり、新しい見積り技術を確立させる事を特命事項とし
て上司から要請された。また、私はこれに応えるために
社内の有識者と共に見積りＷＧを発足させた。
---------------------------------------------------------------------
（設問イ）
---------------------------------------------------------------------
2.見積りガイドラインの作成
----
2.1.ＦＰ法の採用
----
　ＷＧの最初の活動は、まず見積り技法を選択すること
であった。これについては、社内の一部でも検討が進め
られていた事や、業界の動向からもＦＰ法を採用する事
で全員の意見が一致した。
　ＦＰ法では、アプリケーション機能単位に入出力項目
数・要求されるパフォーマンス等の、複雑度・影響度を
加味しながら工数を見積もる。しかしながら、オリジナ
ルのＦＰ法では手順が非常に複雑であり、何等かの簡易
型へのカスタマイズが必要であるとの結論に至った。
　雑誌等で紹介されている先進的な同業他社の事例を参
考に検討を重ねた結果、以下の簡易ＦＰ法をＷＧでの結
論とした。
　a.見積りの単位は画面では無く、画面に含まれる機能
　　とする。特に画面から起動される一括更新等、バッ
　　クグラウンドにある機能を漏れなく抽出すること。
　b.機能毎に、入出力項目数・ロジックの複雑さ等を加
　　味して難易度を３段階評価する。ここでは、極力属
　　人性を無くすために、難易度を決定する要素を数値
　　化した。
　c.難易度別生産性テーブルから、開発工数を導き出す。
　　ここでは使用するＲＡＤツール毎に数種類のテーブ
　　ルを用意した。
----
2.2.過去のプロジェクトから得られた知見
----
　純然たるソフトウェア開発工数はＦＰ法により導き出
す事が可能であるが、プロジェクト全体としてはその他
にも必要となる工数が多くある。例えば、プロジェクト
マネージメントやユーザ教育、開発メンバーの導入教育
等がこれに該当する。
　ＷＧではＦＰ法のカスタマイズを進めると同時に、社
内アンケート調査を実施して、過去のプロジェクトにお
ける画面・帳票数による開発規模と開発実績工数の実績
収集を行った。散布図に整理した結果、開発規模が大き
くなる程、その他作業工数の割合が大きくなり、１００
人月を超えるプロジェクトでは２割以上を占める事が
判った。
　ＷＧでは、その他作業項目を整理した結果、１５項目
に至った。しかし、その他作業工数については、ユーザ
の参画度合いや、プロジェクトメンバーのスキルなど、
環境により左右される部分が多く、作業項目の洗い出し
に止まり、見積り方法を決定するには至らなかった。
　以上、簡易ＦＰ法と、その他作業工数を合計し、全体
の見積りとすることをガイドラインとして整理した。
---------------------------------------------------------------------
3.プロジェクトへの適用
---------------------------------------------------------------------
3.1.否定的な意見
----
　ＷＧで整理したガイドラインをＡ社向けプロジェクト
のメンバーに説明したところ、以下の否定的な意見が上
がって来た。
　a.機能数での見積りは、従来の画面数に比べ非常に手
　　間がかかってしまう。
　b.詳細設計であればともかく、基本計画時点ではとて
　　も機能数を洗い出すことは出来ない。
　c.同様に基本設計が完了していない時点で、難易度を
　　設定することも難しい。
　私はプロジェクトマネージャである事から、プロジェ
クト方針として強引にガイドラインの使用を強いる事は
可能であったが、それではメンバーのモラルダウンにな
ることから、プロジェクトメンバーとＷＧと合同での意
見交換を行う場を設定した。
----
3.2.ガイドラインを実用化するための施策
----
　Ａ社向けプロジェクトメンバーと協議の結果、ガイド
ラインを適用するために、以下の対策を実施することと
した。
　a.作業面の煩雑さについては、ＥＸＣＥＬシート等の
　　サポートツールを充実させる。
　b.上流工程における機能の不確定要素については、見
　　做しの画面・機能を見積りに含むこととする。
　c.見做しの画面・機能数を見積り、難易度を設定する
　　上で、参考資料として過去の代表的なプロジェクト
　　との実績を公開する。
　何よりも、今回のガイドラインの作成は、社内に共通
の物差しを用意し、誰もが再現可能な見積り手法を整備
する事が目的である事を理解させ、ガイドラインに不足
している部分については改定を重ねる事を説明し、Ａ社
向けプロジェクトにおいて試行するに至った。
---------------------------------------------------------------------
（設問ウ）
---------------------------------------------------------------------
4.評価と改善の方向性
----
4.1.プロジェクトの評価
----
　ガイドラインに従って見積りを行い開発を行った結果、
最終的には１割弱の工数を残したところで、プロジェク
トは終了に至った。これは、Ａ社向けプロジェクトが
１００人月を超える規模であった事を鑑みると、高い精
度の見積りであったと判断できる。
　また、機能レベルでの見積りを行った事は、誤解の余
地が少なく、Ａ社からも高い評価を頂いている。
----
4.2.改善の方向性
----
　ガイドラインに示した難易度別生産性テーブルや見做
し画面・機能数の見積り対実績については、より多くの
実績とメンテナンスの仕組みがあってこそ、精度が上が
るものである。そこでＷＧでは、今回暫定的に用意した
ＥＸＣＥＬの見積りワークシートをベースに、実績の入
力まで可能とするシステム化を次の活動として考えてい
る。
　見積りは工程が進むほど精度が上がる事は当然である
が、受注可否のリスクや、お客様側のプロジェクト体制
を整備する観点からも、いたずらに契約を先延ばしする
ことは出来ない。これについては、お客様と我々システ
ムインテグレータが互いに幸せになるためには、計画・
設計・開発の工程別契約を結ぶことにあると考えている。
これは言い換えると、全工程の一括契約では見積りの精
度が甘く、相当のリスク管理が必要である事を意味して
いる。
　私は今回のガイドラインの普及と共に、リスク管理・
契約管理についても検討し、社内管理規程を充実させて
いきたいと考えている。