PMstyleはこちら
第52回(2004.03.08) 
「前回のフィードバック」

前回、以下のような設問をした。この種のショートケースは非常に参加しにくいのだが、にも関わらず、10名以上の方からご意見を戴いた。まずは感謝したい。皆さんからのご意見はこのページの下にある

◆設問
 あるプロジェクトマネージャーが前のプロジェクトで、短納期化のために新しいモデリング技術を導入し、結果として、ひどい納期遅れを起こした。プロジェクト終了後に原因の分析をしたところ、新技術の作業の部分が相当見積もりより余計に工数がかかっていることが分かった。そこで、次のプロジェクトではその技術の利用を止めてしまった。

 みなさんは、この判断をどうお考えだろうか?技術論になることを避けるために、「新技術」が何かはあえて書かないが、

 従来の見積もり基準での工期 5ヶ月
 新技術の導入で目論んだ工期 4ヶ月
 結果としてかかった工期   6ヶ月

として考えてみて欲しい。

◆設問の種明かし
 実は、この状況はずいぶん古い話なのだが、実ケースである。もう今は、関数型の言語の中にオブジェクト指向が入ることは当たり前のことになっているが、15年くらい前、C++という言語が登場してきたときには、オブジェクト指向は、SmallTalkなどの影響で注目され、なおかつ、生産性や再利用性に対する期待がされた。
 もうお分かりだと思うが、前回、取り上げた例は、従来C言語でプログラムを作っていたところに、C++が出てきたときの話である。原因は開発側ではなく、開発環境の不具合だった。
 このメルマガは、IT系だけではなく、多くの分野の人にお読みいただいているし、また、IT系でもエンジニアだけではないので、技術を明かさなかったのだが、このケースを

 従来技術=C言語
 新技術=C++言語

と書いていたら、また、違った答えを書いてくださった人もいただろう。
 もちろん、それは当たり前のことなのだが、一つ、よく覚えておいた方がよいのは、抽象化してそのプロセスをきちんと具体的に展開することの重要さである。リスクのように推測の世界では、抽象的な思考と、具体的な情報を組み合わせることは特に重要である。例えば、今回、投稿いただいた中で、TomBu(31歳・SE)は

1.新技術であったため予想以上に導入・習熟に時間がかかってしまった
・ノウハウが得られ、今後は当初見積もりの工期(4ヶ月)で良さそう
→継続して新技術を使った方が良い。
・従来と同程度の工期(5ヶ月)
→今後も必要な技術なら継続使用
→特に必要ではないなら新技術の利用を止めても良い
・前回と同程度の工期(6ヶ月)
→新技術の利用を止める

2.単に見積もり誤り
・従来と同程度の工期(5ヶ月)
→今後も必要な技術なら継続使用
→特に必要ではないなら新技術の利用を止めても良い
・前回と同程度の工期(6ヶ月)
→新技術の利用を止める

という意見をくださった。TomBu(31歳・SE)は常に、このような思考をされているのだとお見受けするが、今回のように技術をブラインドするとこういう発想ができるが、CからC++と言われると、とたんにドメスティックな思考をしてしまう人は結構多い。ぜひ、具体の事象に対して、抽象的な思考ができるような習慣をつけたいものである。

◆膾(なます)を吹くのが問題ではなく、羮(あつもの)に懲りるのが問題
 さて、そのTomBu(31歳・SE)さんも含めて、ご回答戴いた方の多くは、新技術では生産性の低下はつき物であることも踏まえて、原因の分析もできない状況で、新しい技術の利用を止めるのは如何なものか?という意見であった。これには、賛成である。
 また、組織の問題にも言及され、新技術導入の際の基準作り、組織としてのリスクマネジメントの重要性を主張された方もいらっしゃった。これも重要なポイントだ。
 このようなポイント以外で重要なポイントは、基準つくりというポイントと関係があるが、この適用は次もおそらく失敗するだろうということだ。言い換えると、次のプロジェクトでも適用のリスクは残る。この際に、リスクをどう捉え、リスクマネジメントとして何をするかという点が問題である。ここではもちろん、なぜ、今回、納期遅れが起こったかという分析が重要である。これはほとんどの方が指摘されている。ただし、それだけでは不十分で、どの程度のスピードで技術に成熟するのか、成熟がどのように今回の問題を解消するのか、次のプロジェクトでは計画をどうするのかといったところが肝心である。
 実は、「羮に懲りて膾を吹く」という成語にこめた意味は、一つは、失敗したから止めるというのではダメということなのだが、もう一つは、失敗したら次は完全にしようというもの現実的ではないということだ。

◆リスクはシステムとして対処する
 今回のケースの結論を読んで、インチキだと思われた方も多いだろうが、常に、リスクはついて回るし、納期遅れといった大きなレベルのリスク事象を完全に回避することはまずできない。なおかつ、同じリスク事象も、プロジェクトの実施期間、あるいは、次のプロジェクトでは変わることが多い。今回のケースでは、開発環境の不具合がなくなったら、習熟度の問題がでてくるだろう。つまり、一つのリスクを回避できると思ったら、その結果、どういうリスクが生まれるかを常に考えておく必要がある。これは、ブレークダウンしていけば洗いつくせるかというと実はそうではない。構造だけではなく、因果関係が含まれるので、ブレークダウンしてもすべては洗い出せない。システムとして捉え、システムとして対策をしなければならない。
 これが、プロジェクトはシステムであり、プロジェクトマネジメントにはシステム思考が必要だといっている所以でもある。


◆関連するセミナーを開催します
この講座は、コンセプチュアルな思考について学ぶ講座です。
自身の業務やマネジメントを創造的、かつ、高品質にしたい方にお勧めのセミナーです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ◆コンセプチュアル思考〜見えないものに挑む思考法                ◆(7PDU's)
  日時・場所:【東京】2017年 11月 07日(火)10:00-18:00(9:40受付開始)   
              国際ファッションセンター(東京都墨田区)
          【大阪】2018年 02月 06日(火)10:00-18:00(9:40受付開始)   
              大阪市中央公会堂(大阪市北区)
  講師:好川哲人(エム・アンド・ティ コンサルティング代表)
  詳細・お申込 http://pmstyle.biz/smn/conceptual_thinking.htm
  主催:プロジェクトマネジメントオフィス、共催:PMAJ
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
 【カリキュラム】
  1.思考をコンセプチュアルにするとは
  2.思考をコンセプチュアルにする思考法
  3.思考をコンセプチュアルにする思考ツール
  4.コンセプチュアルな思考を妨げるもの
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

入門編はこちらです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆コンセプチュアルスキル入門〜本質を見極め、行動するスキル   ◆(7PDU's)
  日時・場所:【東京】2018年 01月 18日(木)10:00-18:00(9:40受付開始)   
              国際ファッションセンター(東京都墨田区)
          【大阪】2018年 01月 23日(火)10:00-18:00(9:40受付開始)   
              大阪市中央公会堂(大阪市北区)
  講師:好川哲人(エム・アンド・ティ コンサルティング代表)
  詳細・お申込 http://pmstyle.biz/smn/conceptual_skill.htm
  主催:プロジェクトマネジメントオフィス、共催:PMAJ
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
 【カリキュラム】
  1.概念的に考えて、具体的な行動をする
  2.本質を見極めるスキル
  3.洞察力を高める
  4.応用力を高める
  5.コンセプチュアルが行動を変える〜ケーススタディ
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
前の記事 | 次の記事 | 記事一覧
著者紹介
好川哲人、MBA、技術士
株式会社プロジェクトマネジメントオフィス代表、PMstyleプロデューサー
20年以上に渡り、技術経営のコンサルタントとして活躍。プロジェクトマネジメントを中心にした幅広いコンサルティングを得意とし、多くの、新規事業開発、研究開発、商品開発、システムインテグレーションなどのプロジェクトを成功に導く。
1万人以上が購読するプロジェクトマネジャー向けのメールマガジン「PM養成マガジン(無料版)」、「PM養成マガジンプロフェッショナル(有料版)」や「プロジェクト&イノベーション(無料)」、書籍出版、雑誌記事などで積極的に情報発信をし、プロジェクトマネジメント業界にも強い影響を与え続けている。

メルマガ紹介
本連載は、「PM養成マガジン」にて、連載しております。メルマガの登録は、こちらからできます。
スポンサードリンク
読者からのコメント
新技術での運用に慣れる(習得)までの時間を考慮しなかったのが原因だと思う。 素人(35歳・事務職)
分析の結果、新技術が先々効果をもたらす物であれば、次開発でも使用するべきと感じました。
その為の苦労を、無にしてしまう決断と思います。
匿名希望
その新技術を採用して失敗(納期遅れ)したのかの原因を探り、その新技術に問題があるのか、適用方法に問題があったのかの切りわけが必要だと考えられます。その切りわけを行った上で、新技術に問題があるのであれば、採用しないということも考えられるが、適用方法の誤りであった場合、その新技術はどんなプロジェクトに適していたのかや適用するのにどんな前提があったかを調査し、その上で、再度、新技術を導入してみる価値はあるかと思われます。 細谷 将信(29歳・(株)中央コンピュータシステム)
いつも為になるメルマガありがとうございます。今回のメルマガに出ていた設問に対しての意見を。
新技術を導入することに対してのリスクが検討、検証されておらず、単に新技術が納期短縮に繋がるとしか判断されていない。納期が遅れたことによる検証も行わずに、技術の利用をやめてしまうのはあまりに乱暴な判断だと思う。
今後の新技術を導入する際の考え方、様々なリスクを踏まえて会社としての基準を検討すべきだと思う。
この回答に対して何か意見いただけるのでしょうか?
匿名希望
新技術を導入することによって短期的に生産性が低下したり、品質が低下することは、想定されることである。これを恐れていては新技術の導入など不可能\であり、進歩していく世の中の技術についていけないことは言うまでもない。新技術を導入するときに、パイロットとしてのテーマ選定は正しかったか、未習熟による生産性の低下と品質の低下懸念に対して、どれだけの防止策を考えられたかが問題であり、そのリスク管理ができていない組織の問題と考えます。 万年火消しのプロマネ(44歳・IT系プロジェクトマネージャ)
はじめまして。毎号、興味深く拝見させて頂いております。

新技術の導入について、そもそも1回目から削減効果を期待する事が危険であると思う。上司などからは「最初は時間がかかっても学習効果で後半からは大幅に短縮できるはず」などと言われる事が多々あるが、そんなにうまく行く訳がない。
そもそも1プロジェクトの前半で覚えたことが後半で流用できる範囲は限られるので大幅な学習効果は望めない。最後までトライ&エラーの繰り返しで大幅工数増が現実的なのではないだろうか。設問の回答としては継続するべきで、メンバーの変更・能\力、次プロジェクトでどこまで流用可能\かのか・・・などにもよるだろうが、
1回目:6ヶ月、2回目:5ヶ月、3回目:4ヶ月
と見るのが妥当ではないだろうか。
IT系開発の立場で意見を書かせて頂きました。
PMPビギナー(31歳・IT系リーダ職)
新技術が正しく理解/運用されれば目的は達成される。
今回納期遅延を起こした原因を分析し、そのプロジェクトで対応可能かどうかを判断する。一般論では対応すべきであるが、中には事情があって向かない場合もある。その場合は代替え案/更に改良案を考え対応する。
いずれにしても元に戻せばよいというのは??
myfairlady(50歳・IT関連)
新技術が本当に効果が出るものであると考えて導入しようとして決めたのであれば、簡単にやめるべきではないでしょう。問題は「何故思い通りにいかなかったのか」「どこが足りなかったのか」を分析した上で判断するべきだと思います。
経験的には新しいことを導入する時には「使いこなし」ができないためその能力が充分出せないことがしばしばありますよね。今回もそういう事例では?
萩原 一嘉(37歳・会社員)
今回の結果だけで見極めるのは難しいですね。

工数が余計にかかった原因によると思います。
1.新技術であったため予\想以上に導入・習熟に時間がかかってしまった
・ノウハウが得られ、今後は当初見積もりの工期(4ヶ月)で良さそう
→継続して新技術を使った方が良い。
・従来と同程度の工期(5ヶ月)
→今後も必要な技術なら継続使用
→特に必要ではないなら新技術の利用を止めても良い
・前回と同程度の工期(6ヶ月)
→新技術の利用を止める

2.単に見積もり誤り
・従来と同程度の工期(5ヶ月)
→今後も必要な技術なら継続使用
→特に必要ではないなら新技術の利用を止めても良い
・前回と同程度の工期(6ヶ月)
→新技術の利用を止める
TomBu(31歳・SE)
新技術の導入自体が生んだ混乱(習得・慣れに時間が掛かったなど)が原因となって工期が延びたのか,本質的に時間が掛かる手法だった(技術の見通しが甘かった)のかを検討する必要があるでしょう。習得後は新技術に利があるなら,他の人員にも新技術を浸透させ,他プロジェクトでも積極的に採用していくべきと考える。 オケマツ(37歳・SE)
たくさんのご回答、ありがとうございまいした。次回のメルマガでコメントさせて戴きます。新たな意見、読者の方の意見に対する意見も募集します。下のフォームからご投稿ください。 好川哲人
  高度情報処理技術者試験の論文集の山口です。いつもメールマガジン拝読しております。

 回答を送ろうと思いつつ、あっと言う間に日が経ってしまいました。皆さんの回答を拝見した上なので、非常に心苦しいのですが、私は全く違った考えを持っていたので、あえて送信させて頂きます。

 まず、私はIT系のプロジェクト経験しかございませんので、その前提で考えている事をお断りさせて頂きます。

----

「従来」 vs「見積り」:20%減
「見積り」vs「結果」 :50%増
「従来」 vs「結果」 :20%増

 結論として、これだけの開きがあったのでは、今後の適用を検討する価値も無いと思います。つまり、設問のプロジェクトマネージャの判断は正しいと思います。

 私の判断の基準は以下の通りです。

a.新技術の作業の部分に工数が余計にかかっており、新技術の取得・教育に余計に工数がかかった訳では無さそうである。つまり、今後も目論んだ程の生産性向上は見込めない。

b.数字の開きが 20%以上もあり、それだけでIT系の場合は、プロジェクトは赤字になる事が必須である。

 従来の見積もり基準での工期 5.0ヶ月
 新技術の導入で目論んだ工期 4.0ヶ月
 結果としてかかった工期   4.5ヶ月

くらいでしたら、ぎりぎり検討してみようかと思います。

c.新技術導入の目的が「短納期」である。もしも、これが業界標準となりつつある技術の導入であれば、話は別です。先行投資の意味を含め、検討する値はあるでしょう。

 以上、好川さんの導きたかった方向性とは違う回答になっているかもしれませんが、こういう風に考える人も居るんだな・・・という事でお許し下さい。
山口 ヒカル(37歳、高度情報処理技術者試験の論文集)
導きたい方向はありませんので、どんどん、自由な意見をお願いします。このケースの場合、現実的な判断としても現実の行動も異なるものが出てきてもおかしくないと思います。それは、ケースとしての情報不足というだけではなく、本質的に難しい判断だからです。 好川哲人