• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

プロジェクトマネジメント入門

第11回 経験をノウハウとして記録する

2007/07/10 日経コンピュータ
出典:日経コンピュータ 2002年2月25日号174ページより
(記事は執筆時の情報に基づいており、現在では異なる場合があります)
目次一覧

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なりますが、この記事で焦点を当てたプロジェクトマネジメントの本質は今でも変わりません。

プロジェクトの終了時に,チームのメンバーは,得られたノウハウや教訓などを次のプロジェクトで役立つように整理して記録しておく必要がある。そのためには,プロジェクトの終了報告会できちんとプロジェクト内容を議論することが欠かせない。失敗があってもそれを責めず,今後の反省材料にできる風土を作ったり,整理した記録を保有し,活用できる仕組みを会社として持つことも必要である。プロジェクト管理ツールの利用も有効だ。

伊藤 健太郎
アイシンク 代表取締役

 プロジェクトチームが果たすべき第一の役割は当然ながら,顧客との契約に適合した成果物を作ることである。これがうまくできないとプロジェクトが成功したとは言えない。では,成果物ができれば十分であろうか。顧客に対してはそれで十分かもしれない。しかし,プロジェクトを請け負った会社組織としては不十分である。

 会社組織としては,そのプロジェクトで得られた実績や経験,教訓などを次のプロジェクトで役立つように保有しておく必要がある。そのために,プロジェクトチームは,経験や教訓,反省点,改善点などを次に役立たせるような形で残す責任がある。ここまで実施して初めて,会社組織にとって十分なプロジェクトと言える。

 とはいえ,プロジェクトのノウハウを次のプロジェクトで役立つように整理するのはなかなか難しいことである。プロジェクトの成果物を作るという目的と異なり,結果を容易に判断できないからだ。

 そもそも,プロジェクトマネジャやプロジェクトチームが,ノウハウを次に役立つ形で整理することがチームの仕事であると明確に認識していないことも多い。

苦労話の記録は簡単ではない

 筆者の経験をお話しする。ある建設工事のプロジェクトチームに筆者はメンバーとして加わっていた。納期通りに工事は終わり,客先の引き取り作業も順調に進み,プロジェクトチームは解散した。筆者を含むプロジェクトメンバーたちは新たなプロジェクトへと次々に配属されていった。プロジェクトマネジャだけはまだ新規の仕事につかず,プロジェクトの最終コストを計算したり,プロジェクトプランと実績の比較表などを作成していた。

 プロジェクトが終了して2週間ぐらい後になって,筆者は“元プロジェクトマネジャ”から呼ばれた。元というのはすでにプロジェクトチームが解散していたからである。そして,次のようなことを言われた。「伊藤君,プロジェクトはうまくいったが,資料をまとめるのでチームメンバーと話をしてみると,いろいろと今後に役に立ちそうなアイデアや,私の知らなかった苦労話が出てね。全部整理して社内に公開したいと思いついたんだが,どうだろう」。

 当時のメンバーの中では筆者が最も若手であり,相談されたというより,プロジェクトの経験や改善アイデアを整理する役に任命された格好であった。プロジェクトチームは解散していたものの,筆者もノウハウの整理は極めて重要と思い,当時の上司の許可を得て整理することにした。

 まず,整理すべき項目を作成した。良かった点,反省点,苦労した点,改善点などである。そして,それらを,設計部,製造部,営業部,制御部などに散っているプロジェクトメンバーたちに配布し,記入を依頼した。ところが1週間くらいたって,電話してみると元のプロジェクトメンバーはほとんど何もしていなかった。

 数人の方が自分のプロジェクト・ノートを見て思い出しながら作成に協力してくれた程度であった。それ以外のメンバーの反応は,「何でいまさら」というもので,プロジェクトでの出来事や改善点などを整理することなど到底できなかった。

 理由はいろいろ挙げられた。「現在のプロジェクトが忙しくて,今の仕事に関係ないことに対応する時間がない」,「記憶がはっきりしない」,「自分の失敗に関しては記録したくない」,などである。筆者は若かったこともあり,相手のところに直接行き,大声で「何で協力してくれないんですか」と怒鳴って,必死で粘ったりもした。

 しかし結局,次のプロジェクトで役立ちそうな経験やノウハウ集のようなものはできなかった。この経験を通じて強く感じたのは,「プロジェクトの経験を書類にして残すことが自分の仕事である」と考えているメンバーがほとんどいなかったことだった。むしろ,余分な仕事であるとほとんどのメンバーは感じていたのだ。

 これはメンバー本人の意識の問題だと考えるべきでない。なぜなら,これらのプロジェクトのノウハウがなくて困るのは,会社組織だからだ。したがって,会社組織として対応を考えるべき問題である。ではどうしたらよいのか。以下に五つのポイントを挙げ,順に検討していく。

(1)経験を記録に残すことはチームの仕事

 まず第一にこの認識を定着させることが大切である。「経験を整理し,次に残す形にするのはプロジェクトマネジャやプロジェクトチームの仕事である」と明確に定義しておく。プロジェクトメンバー個々の意識の問題にしてはならない。

 できればプロジェクトの最初の段階で,プロジェクトマネジャから次のようにメンバーに宣言するとよい。「今度のプロジェクトは,いままでにない特徴がある。したがって,いろいろと試行錯誤することになるだろうが,次のプロジェクトのためにも苦労した点や逆にうまくいった所,改善点などを記録するように。記録を残すことは今回のプロジェクトの一部である」。

 このような形でプロジェクトの最初に説明を受けておくと,プロジェクトメンバーも心構えができるし,記録を残すことも自分の仕事であると認識できる。プロジェクトの最後に苦労してまとめるのではなく,気が付いたときに記録しておけるようになる。ここが肝心で,終わってから記録しようとすると,筆者がかつて苦労した事態に陥りかねない。

(2)終了報告会できちんと評価をする

 だれでも自分の作成した資料について評価を知りたいものである。プロジェクトの経験を一生懸命整理しても,だれも見てくれないようだとやる気がなくなる。したがってプロジェクトの終了報告会のような機会を利用して,プロジェクトで苦労した点や改善点について率直に議論する時間を設けるべきである。

 往々にして終了報告会は,トップマネジメントがプロジェクトチームの苦労をねぎらうだけの形式的なものになりやすい。無論,苦しいプロジェクトを遂行したことに対して,敬意やねぎらいの言葉は必要である。しかし,このことはプロジェクトの評価を甘くするということではない。

 会社の将来を考えるべき責任があるトップマネジメントはあえて,「どうして今回はこのようにしなかったのか」,「次回はこのようにしてみてはどうか」,あるいはまた,「どうしてこのようなことになったのか」と,プロジェクトマネジャやチームメンバーに率直に質問すべきである。厳しい質問でも構わない。

 日本ではこうした追求をする人をやぼと見なす習慣がある。また,プロジェクトには,プロジェクトチームしか理解できない,言葉で説明が難しい苦労もある。このためプロジェクトチーム以外の人間が当該プロジェクトに対して苦言を呈しにくい雰囲気がある。しかし,あえて苦言や質問を重ねることで,プロジェクトマネジャやプロジェクトメンバーはプロジェクトについて深く考える機会を与えられることになる。

ここから先はITpro会員(無料)の登録が必要です。

次ページ (3)失敗が責められない風土を作るだれでも失敗は...
  • 1
  • 2

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る