PMstyleはこちら	第５１回（2004.03.01）　 「羮（あつもの）に懲りて膾（なます）を吹く」
◆失敗に学ぶ 　「羮に懲りて膾を吹く」という成語がある。 　吸い物の熱いのにすっかり懲りて、冷たいなますまでふうふうと吹いて食べるかのように、一度失敗したのに懲りて用心しすぎることのたとえのことだ。 　プロジェクトマネジメントの重要性が認識されるようになり、さらにリスクマネジメントへの関心も高くなってきている。そのような今日この頃、感じているのが冒頭の「羮に懲りて膾を吹く」ことが多いことだ。 　話がそれるが、この２年くらい、注目を浴びてきたのが、失敗学であり、また、組織学習である。プロジェクトマネジメントにおいてはレッスンズラーンドがそれに相当しているが、失敗に学ぶことは決して悪いことではないし、いまさら言うまでもなく進歩するためには不可欠なことである。 ◆何のために学ぶのか 　そのような中で、忘れられがちなのは、何のために学ぶかという問題である。失敗に学ぶのは何のためか？このクエスチョンは意外と難しい。ある人は即座に、同じ失敗を繰り返さないためだと答えるだろう。改善というのはそういう発想であるし、同じ失敗を繰り返すというのは、愚の骨頂であるし、許されることでもない。例えば、過小見積もりによる納期遅れをほぼ同じシステム構築で繰り返したとすれば、プロジェクトマネージャーだけではなく、組織そのものの能力も疑われるだろう。 　しかし、一概にそうは言えないケースもある。例えば、人類が月に立つまでには、何度となく同じ失敗を繰り返している。これに対して、同じ失敗を繰り返しているので愚の骨頂だとはいえない。 　ここで問題なのは、同じ失敗とは何かである。同じ失敗とは同じところで失敗することではない。「同じやり方」をして同じところで失敗をすることである。特に、リスクに対する学習をする際には、この点に注意する必要がある。 　やり方をかえれば失敗しても仕方ないというつもりはない。しかし、どこまでいっても優先されるのはプロジェクトの目的であり、プロジェクトの目的を歪めてまでリスクを重視するのはナンセンスだというしかない。リスクマネジメントとは、プロジェクトの目的を達成するためにどのようなリスクがあるかを明確に、できるだけ早い時期からその目標を達成に向けて、リスクへの対処をしていくことである。 ◆リスクをとるためのマネジメント 　言い換えると、リスクマネジメントは、「リスクをとる」ために行うマネジメントであり、「リスクを避ける」ために行うマネジメントではない。冒頭に「羮に懲りて膾を吹く」が気になるというのはそういう意味である。 　日本のプロジェクトマネジメントの特徴はリスクをとらないことだった。特に、ＩＴ系のプロジェクトではこの傾向が強かった（リスクがないという意味ではない。そのように考えても開発マネジメント（エンジニアリング手法）の未熟さゆえのリスクが相当ある）。その意味で、リスクマネジメントが普及しなかったのは当然だと思っていた。ただ、リスクがあることも事実で、リスクマネジメントが普及することは好ましいことだ。ところが、リスクマネジメントの導入をしたとたんに工期は長くなるし、予算も大きくなる。これではリスクマネジメントの導入目的が本末転倒である。リスクマネジメントを導入するのであれば、例えば、工期の２０％短縮を目指し、結果として５％程度改善されたとか、そういったスタンスと効果を得たいものである。 ◆設問 　あるプロジェクトマネージャーが前のプロジェクトで、短納期化のために新しいモデリング技術を導入し、結果として、ひどい納期遅れを起こした。プロジェクト終了後に原因の分析をしたところ、新技術の作業の部分が相当見積もりより余計に工数がかかっていることが分かった。そこで、次のプロジェクトではその技術の利用を止めてしまった。 　みなさんは、この判断をどうお考えだろうか？技術論になることを避けるために、「新技術」が何かはあえて書かないが、 　従来の見積もり基準での工期　５ヶ月 　新技術の導入で目論んだ工期　４ヶ月 　結果としてかかった工期　　　６ヶ月 として考えてみて欲しい。 ◆関連するセミナーを開催します ╋【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋ 　■　プロジェクト知識マネジメント〜質の高い振返りでプロジェクトを変える◆7PDU's 　　日時・場所：【東京】2019年 03月 26日（火）　 10:00-18:00（9:40受付開始） 　　　　　　　　　　　　　　ちよだプラットフォームスクウェア（東京都千代田区） 　　　　　　　　 　【大阪】2018年 12月 19日（水）10:00-18:00（9:40受付開始） 　　　　　　　　　　　　　　大阪市中央公会堂（大阪市北区） 　　講師：鈴木　道代（株式会社プロジェクトマネジメントオフィス、ＰＭＰ、ＰＭＳ） 　　詳細・お申込　http://pmstyle.biz/smn/lesson20.htm 　　主催　プロジェクトマネジメントオフィス、共催：ＰＭＡＪ ╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋ 　【カリキュラム】 　１．振返りとマネジメント 　２．組織レベルの振り返り方法 　３．プロジェクト・業務レベルの振り返りの方法 　４．個人レベルの振り返り 　５．３つのレベルの振返りを統合し、ナレッジとする 　６．プロジェクトのタイプと振り返りの目的と方法 　　・ルーティン 　　・クリエイティブルーティン（アジャイル） 　　・イノベーション ╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋
前の記事 | 次の記事 | 記事一覧
著者紹介 好川哲人、ＭＢＡ、技術士 株式会社プロジェクトマネジメントオフィス代表、PMstyleプロデューサー ２０年以上に渡り、技術経営のコンサルタントとして活躍。プロジェクトマネジメントを中心にした幅広いコンサルティングを得意とし、多くの、新規事業開発、研究開発、商品開発、システムインテグレーションなどのプロジェクトを成功に導く。 １万人以上が購読するプロジェクトマネジャー向けのメールマガジン「PM養成マガジン（無料版）」、「コンセプチュアル・マネジメント（無料）」、書籍出版、雑誌記事などで積極的に情報発信をし、プロジェクトマネジメント業界にも強い影響を与え続けている。 メルマガ紹介 本連載は、「PM養成マガジン」にて、連載しております。メルマガの登録は、こちらからできます。
スポンサードリンク
読者からのコメント
新技術での運用に慣れる(習得)までの時間を考慮しなかったのが原因だと思う。 素人（３５歳・事務職） 分析の結果、新技術が先々効果をもたらす物であれば、次開発でも使用するべきと感じました。 その為の苦労を、無にしてしまう決断と思います。 匿名希望 その新技術を採用して失敗（納期遅れ）したのかの原因を探り、その新技術に問題があるのか、適用方法に問題があったのかの切りわけが必要だと考えられます。その切りわけを行った上で、新技術に問題があるのであれば、採用しないということも考えられるが、適用方法の誤りであった場合、その新技術はどんなプロジェクトに適していたのかや適用するのにどんな前提があったかを調査し、その上で、再度、新技術を導入してみる価値はあるかと思われます。 細谷　将信（２９歳・（株）中央コンピュータシステム） いつも為になるメルマガありがとうございます。今回のメルマガに出ていた設問に対しての意見を。 新技術を導入することに対してのリスクが検討、検証されておらず、単に新技術が納期短縮に繋がるとしか判断されていない。納期が遅れたことによる検証も行わずに、技術の利用をやめてしまうのはあまりに乱暴な判断だと思う。 今後の新技術を導入する際の考え方、様々なリスクを踏まえて会社としての基準を検討すべきだと思う。 この回答に対して何か意見いただけるのでしょうか？ 匿名希望 新技術を導入することによって短期的に生産性が低下したり、品質が低下することは、想定されることである。これを恐れていては新技術の導入など不可能\であり、進歩していく世の中の技術についていけないことは言うまでもない。新技術を導入するときに、パイロットとしてのテーマ選定は正しかったか、未習熟による生産性の低下と品質の低下懸念に対して、どれだけの防止策を考えられたかが問題であり、そのリスク管理ができていない組織の問題と考えます。 万年火消しのプロマネ（４４歳・ＩＴ系プロジェクトマネージャ） はじめまして。毎号、興味深く拝見させて頂いております。 新技術の導入について、そもそも１回目から削減効果を期待する事が危険であると思う。上司などからは「最初は時間がかかっても学習効果で後半からは大幅に短縮できるはず」などと言われる事が多々あるが、そんなにうまく行く訳がない。 そもそも１プロジェクトの前半で覚えたことが後半で流用できる範囲は限られるので大幅な学習効果は望めない。最後までトライ＆エラーの繰り返しで大幅工数増が現実的なのではないだろうか。設問の回答としては継続するべきで、メンバーの変更・能\力、次プロジェクトでどこまで流用可能\かのか・・・などにもよるだろうが、 1回目：６ヶ月、２回目：５ヶ月、３回目：４ヶ月 と見るのが妥当ではないだろうか。 ＩＴ系開発の立場で意見を書かせて頂きました。 PMPビギナー（３１歳・IT系リーダ職） 新技術が正しく理解/運用されれば目的は達成される。 今回納期遅延を起こした原因を分析し、そのプロジェクトで対応可能かどうかを判断する。一般論では対応すべきであるが、中には事情があって向かない場合もある。その場合は代替え案/更に改良案を考え対応する。 いずれにしても元に戻せばよいというのは？？ myfairlady（５０歳・IT関連） 新技術が本当に効果が出るものであると考えて導入しようとして決めたのであれば、簡単にやめるべきではないでしょう。問題は「何故思い通りにいかなかったのか」「どこが足りなかったのか」を分析した上で判断するべきだと思います。 経験的には新しいことを導入する時には「使いこなし」ができないためその能力が充分出せないことがしばしばありますよね。今回もそういう事例では？ 萩原　一嘉（３７歳・会社員） 今回の結果だけで見極めるのは難しいですね。 工数が余計にかかった原因によると思います。 1.新技術であったため予\想以上に導入・習熟に時間がかかってしまった ・ノウハウが得られ、今後は当初見積もりの工期(4ヶ月)で良さそう →継続して新技術を使った方が良い。 ・従来と同程度の工期(5ヶ月) →今後も必要な技術なら継続使用 →特に必要ではないなら新技術の利用を止めても良い ・前回と同程度の工期(6ヶ月) →新技術の利用を止める 2.単に見積もり誤り ・従来と同程度の工期(5ヶ月) →今後も必要な技術なら継続使用 →特に必要ではないなら新技術の利用を止めても良い ・前回と同程度の工期(6ヶ月) →新技術の利用を止める TomBu（３１歳・ＳＥ） 新技術の導入自体が生んだ混乱(習得・慣れに時間が掛かったなど)が原因となって工期が延びたのか，本質的に時間が掛かる手法だった(技術の見通しが甘かった)のかを検討する必要があるでしょう。習得後は新技術に利があるなら，他の人員にも新技術を浸透させ，他プロジェクトでも積極的に採用していくべきと考える。 オケマツ（３７歳・ＳＥ） たくさんのご回答、ありがとうございまいした。次回のメルマガでコメントさせて戴きます。新たな意見、読者の方の意見に対する意見も募集します。下のフォームからご投稿ください。 好川哲人 　　高度情報処理技術者試験の論文集の山口です。いつもメールマガジン拝読しております。 　回答を送ろうと思いつつ、あっと言う間に日が経ってしまいました。皆さんの回答を拝見した上なので、非常に心苦しいのですが、私は全く違った考えを持っていたので、あえて送信させて頂きます。 　まず、私はIT系のプロジェクト経験しかございませんので、その前提で考えている事をお断りさせて頂きます。 ---- 「従来」　vs「見積り」：20%減 「見積り」vs「結果」　：50%増 「従来」　vs「結果」　：20%増 　結論として、これだけの開きがあったのでは、今後の適用を検討する価値も無いと思います。つまり、設問のプロジェクトマネージャの判断は正しいと思います。 　私の判断の基準は以下の通りです。 a.新技術の作業の部分に工数が余計にかかっており、新技術の取得・教育に余計に工数がかかった訳では無さそうである。つまり、今後も目論んだ程の生産性向上は見込めない。 b.数字の開きが 20%以上もあり、それだけでIT系の場合は、プロジェクトは赤字になる事が必須である。 　従来の見積もり基準での工期　5.0ヶ月 　新技術の導入で目論んだ工期　4.0ヶ月 　結果としてかかった工期　　　4.5ヶ月 くらいでしたら、ぎりぎり検討してみようかと思います。 c.新技術導入の目的が「短納期」である。もしも、これが業界標準となりつつある技術の導入であれば、話は別です。先行投資の意味を含め、検討する値はあるでしょう。 　以上、好川さんの導きたかった方向性とは違う回答になっているかもしれませんが、こういう風に考える人も居るんだな・・・という事でお許し下さい。 山口 ヒカル（３７歳、高度情報処理技術者試験の論文集） 導きたい方向はありませんので、どんどん、自由な意見をお願いします。このケースの場合、現実的な判断としても現実の行動も異なるものが出てきてもおかしくないと思います。それは、ケースとしての情報不足というだけではなく、本質的に難しい判断だからです。 好川哲人 （１）ディベートができない プロジェクトマネージャへの問題点の指摘が個人への糾弾（人格攻撃）になりがち、というプロジェクト総括のあり方自体を改善することが、先決かと思います。 プロマネ人材にはディベート教育を必須とする、というのはいかがでしょうか。 個人への冷徹な評価は、人事考課でやってもらえば済むことですし。 （２）日本語の難しさ 上記（１）に関連して、幼稚な実験ですが、翻訳サイトで以下の文章を英訳してみました。 サイトでの翻訳ですので、実践英語とはかけ離れているかと思いますが、ご容赦のほど。 （日）このプロジェクトは太郎のせいで失敗した。 （英）This project went wrong because of Taro\'s fault. 両者を見比べてみると判りますが、日本語だとこれだけで皆が納得してしまう様な雰囲気が漂います。「太郎のせい」というところの行間にいくらでも意味を込められますので。 対して英語の場合には、「Taro」のところには余り目が行かず、「fault」とは一体何だったのか？と徹底追及したくなりませんか？ 上記は単純で幼稚な例ですので判りやすいですが、現実のビジネスの現場において、上記日本語例の様な評価はごく普通に行われているのではないかと考えます。 この日本語の難しさは、当方も顧客との要件定義の局面で悩まされることがよくあります。 反面、「プロジェクト目標の共有化」が出来て以降は、「行間を読め」のコミュニケーションが通じるので有り難いのですが。 MT（３９歳、流通系IT子会社）