人間は一度成功した経験を持つと,その成功体験からなかなか抜け出せないものだ。そして,過去の成功事例をそのまま今に利用しようとする。過去の成功事例を基にやった方法でうまくいかなかったときには「やり方自体に間違いはなかった。今回うまくいかなかったのは○○○が悪いからだ!」と考えてしまう。成功体験という呪縛に縛り付けられてしまうのである。

 システム開発プロジェクトにおいても同様である。新しい試みやチャレンジをすること無く過去の成功体験に縛られていては,より大きな成果を得ることは出来ない。それどころか何か問題が発生したときに,解決の糸口にたどり着くまでに時間がかかるばかりである。

過去の成功体験に固執したKさん

 Kさんは数カ月前A社のシステム開発プロジェクトのプロジェクト・マネージャ(PM)として無事カットオーバーを終えたばかりの中堅技術者である。KさんにとってはPMとして初めてのプロジェクトであったにもかかわらず,ユーザーから高い評価を得ることができた成功プロジェクトであった。今回,A社で別のシステム開発プロジェクトが立ち上がった際にも,PMとして名指しで任命されるほどであった。

 今回のプロジェクトは,前回と同じWebシステム開発プロジェクトである。利用するデータベースや帳票基盤も同じものであり,Kさんとしては直前の成功体験から今回もうまくいくと開発前から考えていた。

 早速,Kさんは前回の成功体験を基に要員手配,チーム編成,システム・アーキテクチャ設計,システム開発方法論などを固めていった。実際にプログラミングをお願いする協力企業も前回と同じ企業を指名入札した。すべては成功体験に裏打ちされた手配を行ったはずであった。

 しかし,実際のプロジェクトは前回のようにはうまく進まなかった。それは,前回同様に見えたシステムの性質が,実態としては全く異なることに起因していた。確かにWebシステムではあるが,システム要件に前回はなかったAjaxを用いることを前提としていた。また,UML表記法を使うことは同じであったが,開発手法については前回のウォータフォールに対して,今回はユーザー側のIT部門からの強い要望によりUP(Unified Process)で行うことになった。加えて,社内で手配した要員のスキルも,前回のベテランぞろいとはかなり異なり,新人~中堅を主軸とした玉石混交のメンバーであった。さらに,協力企業のメンバーがAjaxに関して不慣れなメンバーが多かった。

 これでは,プロジェクトはうまく進まない。それでもKさんはその原因を考え,前回と比較しどこが違っていて何が悪いのかを考えた。そして,出来る限り前回取った方式や対策を流用しようと努力した。他のサブリーダーからは前回のやり方ではうまくいかないという指摘を何度も受けたが,それを聞くたびにKさんは「やり方は間違っていない。問題点はほかにある。メンバーのモチベーションやスキルはどうなんだ?」という具合で,指摘を聞き入れることが出来なかったのである。

 結局このプロジェクトは大幅に遅延する。失敗プロジェクトと言わざるを得ない結果となった。

「愛着」と「執着」

 以前,ソフトブレーンの宋文洲によるメールマガジンに「愛着と執着(宋文洲の日本の長所・短所 連載17)」というのがあった。

-------------------------------------------------------------
愛着と執着は,紙一重である。執着となれば自己中心になり,他人の迷惑になっても気が付かない。周りから批判されると「愛着」だと思い込み,よけいに反発してしまう。(中略)愛着とは多くの選択肢がある中で,あえてある選択を行う時に限って成り立つ概念である。
ソフトブレーン社メールマガジン 2005.10.14(第32号)より
-------------------------------------------------------------

 Kさんは過去の成功体験による方法にこだわるばかりに,いつしかその方法に「執着」してしまっていた。まさに成功体験という呪縛にがんじがらめに縛り付けられていたに違いない。そのため,頭のよいKさんは,頭では別の方法が良いと理解していながらも,どうしても一歩外に踏み出すことが出来なかったのである。

 これはKさんだけの問題ではない。Kさんと同じように,分かっているが踏み出せないということは誰にでもある。PMともなれば,収益向上,原価削減という名のもと,失敗は許されないという外からの束縛も強くなる。

 「リスクが怖いから実績のある過去の方法を取りたい」と言う人もいる。しかし,これではリスクに向き合うことなく,ただリスクを遠ざけているだけである。それどころかいつまで経ってもリスクを克服することはできない。

 プロジェクトは千差万別の生き物だ。一つとして同じプロジェクトは存在しない。様々なリスクが毎回違った形で表面化し,その都度PMの頭を悩ませる。一方で,リスクがあるからこそPMの存在意義がある。乱暴な言い方をすれば,リスクとどう戦い克服するかがPMの腕の見せ所であり,だからこそ面白いのである。このリスクと戦う方法として過去成功した方法に執着していては,勝てる戦も勝てなくなってしまう。

 PMたるもの,リスクに対して正面から向き合い,どう対処するか複数の選択肢を検討した上で,最善の方法を選択しなければならない。愛着心から過去成功した方法を採用する場合があっても問題ない。しかし,執着心からほかの選択肢を排除してまで過去成功した方法を採用してはならない。

PMは過去の経験を糧に挑戦し続けよ

 PMに限らず,人が成功体験をすることは非常に重要である。成功体験こそがその人を一回りも二回りも大きくする。これについては異論の余地がない。問題は,その成功体験をどう生かすかということである。この成功体験を生かすということは,過去の成功体験にとらわれるということではない。特にシステム開発プロジェクトの場合,自分の担当したシステムに愛着が湧き,過去の成功体験が絶対的な方法であるかのような錯覚に陥ることは多い。

 誤解してほしくないのは,愛着がわくこと自体が問題だと言っているのではない。大いに愛着を持ってほしい。ここで言いたいのは,愛着から執着に変わる危険性である。愛着から執着に変わってしまうと,問題の本質が見えなくなるばかりでなく,問題の原因を外に探そうとしてしまうのである。この「問題を外に探す」シグナルこそが成功体験にとらわれてしまったという証拠なのだ。

 PMたるもの,過去の成功体験に執着してはならない。過去の成功体験は自身の貴重な経験として正しく認識し,次のステップへの礎とすべきなのだ。そして,その礎の上に立って挑戦し続ける姿こそ,現代の日本企業に求められる後輩に背中を見せられるPMの姿であると筆者は考える。


上田 志雄
ティージー情報ネットワーク 技術部 共通基盤グループ マネージャ
日本国際通信,日本テレコムを経て,2003年からティージー情報ネットワークに勤務。88年入社以来一貫してプロジェクトの現場を歩む。国際衛星通信アンテナ建設からシステム開発まで幅広い分野のプロジェクトを経験。2007年よりJUAS主催「ソフトウェア文章化作法指導法」の講師補佐。ソフトウェア技術者の日本語文章力向上を目指し,社内外にて活動中。