記録を残してもどうせ後で見返すこともない。そう思っているなら情報の使い方がうまくない。残した情報を見て何に使えるかを考えるのではなく，使い道に合うように情報を加工するアプローチが正しい。生の情報から何か意味あることを読み解くのは大変だからだ。
記録を活用するには，活用する場を設定することが大切である。ステップ(4)～(6)で，記録した情報をどのように活用できるかを見ていこう。
step 4 使える形に整理する
勤務時間と単価からコストを算出
定量的な情報の場合，複数のプロジェクトを一つの軸で評価できる形に加工したい。作業工数であれば「工程ごと」「担当者ごと」「内製/外注」といった具合にプロジェクトの特徴に応じた相場観が浮かび上がるように記録を残せるとよい。プロジェクトから得られる定量的な情報を加工すれば，開発工数，生産性（開発規模/開発工数），品質（バグ/開発規模）などの指標を作ることができる。
アイスタイルでは，開発メンバー全員が毎日の勤務時間をプロジェクトごとに分けて専用のExcelシートに入力している。そのデータを加工することで，次のような情報を把握しようと試みている（図5）。
- (1)プロジェクトの総工数（内製）
メンバーがそのプロジェクトに費やした勤務時間を合計する。
- (2)プロジェクトの総コスト（内製）
メンバーごとに勤務時間に単価をかけて合計する。
- (3)工程ごとの工数（内製）
各工程に費やした日ごとの勤務時間を合計する。
一方，発注書から外部委託先のコストを算出する。ここからは次の情報が分かる。
- (4)外注の総コスト
発注金額を合計する。
- (5)外注比率
(2)と(4)の比率を計算する。
これ以外にハードウエアやソフトウエアの調達コストを把握している。こういう形で運用し始めたのが2006年夏頃からなので，情報の本格的な蓄積はこれからだ。ある程度，情報が集まれば「見積もりや生産性，外注比率の妥当性を評価する指標になる」（システム企画部 部長 小川敏一氏）。
step 5 反省の材料にする
反省会の内容を議事録にまとめる
定量的な情報に比べると，定性的な情報は加工して一般化するのが難しい。定性的な情報とは，失敗の原因や成功の要因を分析したものだ。反省会のような場を設けて，関係者全員がその情報を認知できるようにするのが現実的である。
ブレインプロの大砂古氏はプロジェクト完了後にメンバーを集め，学んだことを付せん紙に三つずつ書かせた。それを張り出して，プロジェクトの最中にそれぞれのメンバーの中で起きていたことと，その原因を分析した。利用者の要求に合わないシステムを作ってしまったことを反省してコミュニケーションの重要性を再認識したり，使用したパッケージについての知識不足を繰り返さないようにサポート要員の必要性を再確認したり，といったことが話し合われた。
「メンバーは一度経験したことを，その場で改めて認識することになる。それをメンバー同士で分析することでさらに印象づけられるし，メンバー間の情報共有にもなる。経験やノウハウは場に出して話し合うことが大切だ」（大砂古氏）。
Web検索エンジンの開発を手掛けるイー・エンジンでも，プロジェクトが終わるたびに反省会を実施している。一般的には稼働開始の翌週，1～2時間実施する。反省会は漫然とやるのではなく，各人がテーマを考えておく。最近実施した反省会では「プログラマ同士の情報はどのように流通していたのか，さらなる効率化に向けた案はないか，品質やユーザビリティで反省点はなかったのかを話し合った」（開発本部 三輪尚俊氏）という。
図6は，そのときの反省会の議事録である。ここで出てきた課題のうち重要そうなものは社内ポータルにも掲載する。
step 6 次に生かす
開発標準や規約に情報を追加する
開発プロジェクトの進め方は，会社ごと，担当者ごとに異なる。いわば“自己流”の世界。それに対して，開発標準を作って効率化しようという動きがある。その際に，残した記録が大いに役立つ。生の情報も開発標準という形にまで加工してしまえば，そのまま次のプロジェクトのインプットとして使えるわけである。
開発標準といってもいろいろある。大きなところでは「工程の定義」。工程をどのように分け，各工程ではどのような作業を行い，各工程ではどんな成果物を作成するかを定義する。こういうものはゼロから作ると現実離れしてしまうので，過去のプロジェクトをひな型に作るケースが多い。
出光興産では，基幹系システムのリプレースを順次，進めている。その過程で，開発標準を整備してきた。最初にリプレースした経理システムの開発プロセスを商品管理システムや物流管理システムに適用し，開発標準としての定着を図ってきた。「プロジェクトごとに特性があるので一律に標準を当てはめるのは難しいが，パターン化することでうまく運用できるのではないかと考えている」（情報システム部 次長 大塚哲司氏）。
開発工程のように大きな標準ではなく，各種の細かい規約をブラッシュアップするための材料としても記録は使える。イー・エンジンでは全プロジェクト共通で使う「コーディング規約」や「ネーミング規約」を用意しているが，まだ完全なものではない。
前回のプロジェクトで苦労した点を規約に盛り込むという作業を地道に続け，規約の使い勝手向上を図っている（図7）。最近では「ネーミング規約の中にデータ型が分かるような命名ルールを追加した」（三輪氏）という。
