なぜ過去の経験が生かされないのか。現場の声から探った。失敗の連鎖を断ち切るには，プロジェクトの情報を記録し，活用する技術が必要だ。

　開発メンバーからの報告を聞いて，プロジェクト・マネージャ（PM）の大木太一氏（仮名）は肩を落とした。

　「ERPのデータで不具合が起きています。製品の不具合のようです」。

　リカバリに時間がかかるので開発作業が遅延することが確実になった。このプロジェクトを終えた今，大木氏は肩を落とした理由をこう振り返る。

　「前回のプロジェクトでも，同じメンバーで同じ不具合を経験していたんです。それを回避する設計は分かっていたはず。なのに，また同じミスを繰り返してしまった。それがとても残念だったのです」。

　前回のプロジェクトの教訓が生きていなかった。

終わらせ方が悪いと後で困る

　同じ失敗を繰り返す現場は，プロジェクトの“終わらせ方”に問題がある。写真コンテンツの提供サービスを手掛けるアマナの石亀幸大氏（情報システム部 マネジャー）も，終わらせ方が良くなかった過去プロジェクトの亡霊に悩まされた。別の担当者が作った販売管理システムの再構築プロジェクトに携わったのだが，途中でおかしな事態に遭遇した。

　プログラムの一部を切り出し，ベンダーに機能変更を依頼したところ，ベンダーから「挙動がおかしい」との指摘が寄せられるようになった。

　調べてみると，中途半端に作られたまま放置されているプログラムや，業務フローが変わって使われなくなったプログラムが，混ざっていることが分かった。こんな状態では，おかしな挙動が出るのは当たり前である。

　石亀氏は，Excelで機能の一覧表を作り，ユーザーに一つずつ確認した。問題なく使われている機能と，使われていない機能を区別し，問題ないと判断できたプログラムをベースに再構築を進めることにした。

　前のプロジェクトの記録が残っていないことが問題だった。どういうトラブルが発生し，何が課題として残っているのか。そういうことを記録として残しておく必要があった。

資産を発掘し活用する

　プロジェクトが人間の営みである以上，失敗はあるだろう。しかし，同じ失敗を繰り返さないようにすることはできる。

　ブログ・サービスの「アメブロ」を運営するサイバーエージェントは，前のプロジェクトの経験を次に生かす仕組みを作ることで，同じ失敗を減らすことに成功した。

　以前は，度重なる稼働直後のシステム障害に悩まされていた。「もちろんテストで出たバグは十分つぶしていましたが，テスト項目が足りなかったのです」（新規開発局 エンジニアグループ 佐藤真人氏）。

　従来は，エンジニアが個々にテスト項目を作成していた。しかし，このやり方だとテストの精度がエンジニアのスキルに依存する。同一PCから複数のアカウントでログインするなど，顔の見えない利用者はエンジニアが想定できないイレギュラーな操作をする。それらすべてをテスト項目として網羅するのが困難だった。

　そこで2006年8月，クロスチェック委員会という組織を設置して，テストのプロセスを見直した。イレギュラーな操作まで網羅するテスト項目を委員会が作成し，チェックすることにしたのである。

　「テスト項目は過去のプロジェクト案件で問題になったものを中心に整理して作りました。さらに新たに問題が起きればその項目も随時追加していきます」（佐藤氏）。

　化粧品のサイト「@COSME」を運営するアイスタイルの小川敏一氏（システム企画部 部長）も経験をノウハウにつなげた一人だ。100％内製で開発してきた同社が，2005年に初めて開発をアウトソースしたときのことだ。スケジュールは遅延。品質も満足のいくものにならず，問題が多発してしまった。その原因をプロセス共有の不備にあると見た小川氏は，要件定義書やSLA（サービス・レベル契約）のひな型など外部委託先と情報をやり取りするドキュメントを用意したのである。

　「まだ完璧なものではないが，前回苦労した問題はこれでつぶせる。納期や品質は劇的に改善されたと思います」（小川氏）。

　一つのプロジェクトは，それが終わるときに次のプロジェクトのために見えない資産のもとを残している。それをうまく発掘し，活用できる資産としてブラッシュアップしていける現場は，同じ失敗を繰り返さない。