プロジェクトは一つずつ違う。状況の異なるいくつものプロジェクトの情報が積み重なるほどその価値は増していく。記録が本当の意味で威力を発揮するのは,複数のプロジェクトの情報をまとめて参考にできるようになり,必要な情報にすぐアクセスできるようになったときだ。

 テクノサージの勝藤氏は「前のプロジェクトのアウトプット(残した記録)が次のプロジェクトのインプットとして,サイクルを回せるような運用を作ることが必要だ」と指摘する。

 運用をうまく回すには,そのための仕掛けを作っておくことが必要である。ステップ(7)~(9)では仕掛けの例を見ていこう。

step 7 入力の手間を減らす
既存システムのデータを流用

 報告書に書くべき内容の多くは,本来,開発業務やマネジメント業務を遂行する中で既に記録されている。例えば,下記のような感じだ。

  • 工数→勤怠管理
  • 金額→見積もり
  • バグ/エラー/障害→品質管理
  • スケジュール→進捗管理
  • 問題・課題→リスク管理
  • 開発の趣旨→計画書

 多くはシステム化されていたり,ファイルとしてパソコンに保管されているものだろう。これらのデータを流用できれば報告書を作成する手間は大幅に削減できる。

 記録が残されている他システムからデータを自動入力できるようにしたのが,日立システムアンドサービスが開発した「プロジェクト管理システム」である(図8)。「スケジュール管理システムや就業管理システム,販売管理システムなどから一定期間ごとにバッチ処理で必要なデータをコピーしている」(プロジェクトマネジメント本部 プロジェクトマネジメント部 部長 千種実氏)という。そのため,稼働後にわざわざ記録を残すための二重入力の必要がなくなる。

図8●STEP7 入力の手間を減らす<br>手間ヒマをかけずに情報を残せる仕組みを作ろう。図は,日立システムアンドサービスが開発したプロジェクト管理システムで,完了報告書に記載すべき情報が自動的に取得できる。
図8●STEP7 入力の手間を減らす
手間ヒマをかけずに情報を残せる仕組みを作ろう。図は,日立システムアンドサービスが開発したプロジェクト管理システムで,完了報告書に記載すべき情報が自動的に取得できる。
[画像のクリックで拡大表示]

 こうした運用ができる前提は,プロジェクト・マネジメント自体がきちんと運用されていることである。「そもそも計画書を作成していなかったり,必要なマネジメントプロセスを省いているプロジェクトも中にはある」(テクノサージ 勝藤氏)。それでは,記録を残すことも活用することもできない。

 日立システムアンドサービスではこのシステムを稼働した2003年以降,報告書を作成するプロジェクトが大きく増えた。「対象プロジェクトのうち,9割以上が作成するようになった」(千種氏)という。

step 8 データベースに蓄積する
複数プロジェクトの情報を一元管理

 残した記録を現場のノウハウとして定着させるには,複数プロジェクトのデータを一元的に管理する仕組みが必要だ。見積もりや品質の指標などはある程度の量がそろわないと精度を上げられない。

 また,情報の量をそろえるためにはその粒度もそろえなければならない。日本ユニシスでは,以前から報告書の中で工夫や教訓を自由記入してもらっていた。しかし,それだと人により書く内容や書き方がバラバラになってしまっていた。そこで,「工数比と工期比の実績」「外注の選択と管理」「お客様満足度」といった具合に書き方に制約を加え,書き方のガイドラインも定義した。

 野村総合研究所(NRI)では,二つの形で過去プロジェクトの情報を蓄積している。一つは,プロジェクト関連のデータベース。ここには過去に実施した対象プロジェクトのすべての記録が蓄積されている。

 定量データとしては「開発規模(FP,ステップ数など)」「ドキュメント量」「開発期間/工数」「コスト」など。定性データとしては「教訓,ノウハウ」「顧客との関係」など。プロジェクトの特性として「開発形態(新規,機能追加ほか)」「適用業務」「開発基盤」などを一元的に格納している(図9)。

図9●STEP8 データベースに蓄積する<br>複数のプロジェクトの情報を1 カ所に格納し,一元的に管理できる仕組みを作ろう。図は,野村総合研究所の「プロジェクト・データベース」と「システムプロジェクト白書」の概要。
図9●STEP8 データベースに蓄積する
複数のプロジェクトの情報を1 カ所に格納し,一元的に管理できる仕組みを作ろう。図は,野村総合研究所の「プロジェクト・データベース」と「システムプロジェクト白書」の概要。
[画像のクリックで拡大表示]

 2000年に運用開始して以来,年間100~200プロジェクトが対象となっている。ただ,入力データが少なかったり,異常値だったりするものもあるので,使えるデータとしては年間50~100プロジェクト分になる。正確なデータを集めるのは意外に難しく,場合によっては品質管理本部の担当者が現場に直接赴いてヒアリングすることもある。今では,見積もり手法の一つ,FP(ファンクション・ポイント)法で必要となる生産性係数の基礎データも百数十件分が蓄積されており,「見積もりの精度向上に使えるようになってきた」(生産性向上推進部 上級専門スタッフ 横山健次氏)という。さらに「途中経過をレビューする際にも,NRIの標準値と乖離していないか,乖離しているとすればその理由は何なのかという視点を持つことができる」(横山氏)。

 もう一つは,プロジェクト白書。データベースに蓄積された情報を担当者が分析,整理してまとめたものだ。

 白書は特に「見積もりに使える各種指標が充実している」(横山氏)という。分量はA4判で40~50ページ。年2回(10月に中間報告,4月に最終報告),イントラネットで公開している。

step 9 閲覧する仕組みを作る
自由な切り口で分析する

 最後のステップは,蓄積した複数プロジェクトの情報を簡単に閲覧する仕組みを作ること。先に見た野村総合研究所が作成しているプロジェクト白書はその一例と言える。それ以外にも,やり方はいろいろある。

 日本ユニシスでは,プロジェクトの記録を格納した社内データベースに,関係するすべての社員がアクセスできるようにしている(図10)。

図10●STEP9 閲覧する仕組みを作る<br>複数のプロジェクトの情報をまとめて検索し,再利用できる仕組みを作ろう。図は,日本ユニシスのプロジェクト実績閲覧システム。全社員がExcel 形式でダウンロードし,自由な切り口で加工できる。
図10●STEP9 閲覧する仕組みを作る
複数のプロジェクトの情報をまとめて検索し,再利用できる仕組みを作ろう。図は,日本ユニシスのプロジェクト実績閲覧システム。全社員がExcel 形式でダウンロードし,自由な切り口で加工できる。
[画像のクリックで拡大表示]

 閲覧の方法を考えるに当たっては,利用者がなるべく自由な切り口で加工できるようにすることを優先した。「業種ごとに見たいとか,システムの種類ごとに見たいとか,人によって検索の切り口は違う」(日本ユニシス 服部氏)からだ。

 データは表形式に整理している。縦軸にプロジェクトが並び,横軸に工数や生産性などの項目が並ぶ。