DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第75回】すべてのプロジェクトは崩壊を運命づけられている?


【第75回】すべてのプロジェクトは崩壊を運命づけられている?

Pocket

ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

前回は、マスタースケジュール、中日程、詳細WBSという3つのスケジュール階層について考察しました。現実のプロジェクトにおいては、しっかりスケジュールを管理していても予定通り進捗が進まないことが多いものです。大幅な進捗遅延が発生した場合には、一度プロジェクトを中断して、仕切り直しをした方が良い場合があります。

今回は、そのようなプロジェクトの中断、再開始の場面を何度も目の当たりにした中で感じてきたことをご紹介します。

 

【 『しくじり先生』の教訓と「プロジェクト崩壊」の要因 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
先日、テレビ朝日のバラエティ番組『しくじり先生』で、カール・マルクスがとりあげられ、オリエンタルラジオの中田敦彦氏が熱弁をふるっているのを拝見しました。ソビエト連邦という国家の崩壊をマルクスの思想との関係で面白おかしく説明していましたが、その後日本共産党から反論があったりして、物議をかもしています。(※1)

歴史学の世界では、古代ローマ帝国の崩壊や第一次世界大戦後のドイツ・ワイマール共和国の崩壊など、国家の崩壊について、いろいろな研究がされています。ローマ帝国の崩壊については、近年では、「『変化』よりも『継続』が、政治よりも社会や宗教が重視されるようになり、『ローマ帝国の衰亡』を語るのではなく、『ローマ世界の変容』が問題とされる」傾向もあるようで、過去の事実であっても、いまだにさまざまな視点で語られるものだと、たいへん興味をそそられます。(※2)

国家の崩壊と同じように、システム開発プロジェクトの崩壊(失敗)の要因もさまざまなことが考えられます。良くあるのは次のような要因です。

< 「プロジェクト崩壊」の良くある要因 >
1.システム企画が不十分で、何を実現したいか軸が不明確
2.見積過少(見えている部分だけ)で、実現性の無い予算、納期、体制となっている
3.要件定義段階で、やりたいことが発散して収拾つかない
4.要件定義が不十分で、外部設計以降の仕様変更が多発して進まない
5.設計書やシステムの品質が悪く、レビューやテストが進まない
6.プロジェクト内の風通しが悪く、重要なデシジョンの遅れや方針変更が頻発

この他にもさまざまな要因があげられるかもしれません。しかし、どのような要因であろうと、プロジェクトが崩壊するような致命的な問題を抱えているプロジェクトであれば、必ずどこかで大きな進捗遅延が発生するはずです。たいていのプロジェクトでは、プロジェクト開始時から毎週進捗会議を開いて進捗状況を監視し、遅延が発生している場合の原因を追究して、何らかのアクションを行っているはずです。進捗遅延の原因を冷静に分析すれば「プロジェクト崩壊」まで行かない段階で、これらの原因に対する抜本的な対応を行う必要性が必ずわかるはずです。

もっと言うと、このような「プロジェクト崩壊」に至る要因が内在しているかもしれないプロジェクトであれば、この要因による兆候をしっかりモニタリングしたり、悪い兆候が表れた場合の善後策をあらかじめ関係するステークフォルダーと握っておくことで、「プロジェクト崩壊」を回避するための対応をしっかり行うことができるはずです。それが本来のプロジェクト・リスク・マネジメントの目的であることは言わずもがなです。(※3)

当ブログの 【第13回】個別リスクとプロジェクト全体リスクという二つの視点 で言及した通り、プロジェクト全体リスクへの対応戦略のひとつとして、プロジェクトの中断、再計画、再開始というアクションがあるのです。このように考えれば、プロジェクトの中断、再開始は、決して「プロジェクト崩壊」の現れというネガティブな事象ではなく、「プロジェクト崩壊」を未然に防止するために必要なプロジェクト・マネジメントのアクションのひとつととらえることができます。

 

【 プロジェクト中断・再開始時に気を付けるべきこと 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
前章で見た通り、プロジェクトの中断・再開始は、「プロジェクト崩壊」を未然防止するためのどちらかと言えば英断と言っても良いものです。しかし、せっかく関係するステークフォルダーを説得して、プロジェクトの仕切り直しを図ったにもかかわらず、再開後のプロジェクトも再開前と同じように暗礁に乗り上げることも多いのは事実です。ここでは、その原因と対策を考えてみたいと思います。

端的に言うと、プロジェクトを中断せざるをえないような進捗遅延などを発生させた根本原因に手が付けられないまま、表面的なスケジュール延期や体制強化などにとどまった再計画の場合は、必ずまた失敗するはずです。

たとえば、失敗の原因が過少見積りによる計画の実現性の無さであった場合、プロジェクト再開時にも再見積りを行うはずですが、最初の見積りのときと同じようにまだ見えていない部分への手当てがされない可能性があります。プロジェクトを中断するくらいうまくいかないプロジェクトであれば、後続工程のどこかで仕様変更多発などの紆余曲折が何度も起きることはある程度想定できるはずです。そのような紆余曲折を見積りに加味するか、もしそれが無理であっても、それが発生した場合のリスクへの対応策を十分に計画に組み込んでおく必要があるのです。

 

また、仮にプロジェクト再開時に、十分な予算とスケジュールが確保できたとします。プロジェクト中断前までは、過酷な労働を強いられてきたプロジェクトチームのメンバーたちは、一気に気が緩んでしまう可能性があります。いや、逆に、せっかくスケジュールが見直しされたのだから、もう一回しっかりと課題を見直して、あるべきシステムに近づけるための設計見直しを本格的に始めてしまうことがあります。

中断前の過酷な状況に比べれば、再計画によりかなりスケジュールの余裕が出来たような錯覚に陥ってしまうのです。途中まで進んだ設計を抜本的に見直しする作業は、実はそんなに簡単なものではありません。そもそも設計段階で噴出した課題への対応のために時間がとられて設計作業が進んでいなかった状況であったならなおのこと、課題への対応だけに集中するのではなく、逆に進められる設計作業をどんどん進めておくべきなのです。課題への対応は、時間をかけずにスケジュールやコストとの天秤にかけて、早々に代替え運用などを検討して次々に決着させていく必要があります。

プロジェクトの中断・再開始は、「プロジェクト崩壊」を未然防止するための英断ではありますが、1度はプロジェクト計画の見直しを認めた経営者でも、2度目はさすがに許容できないはずです。

したがって、たとえ再開時に十分な予算とスケジュールを勝ち取っていたとしても、再開後のプロジェクトは退路が断たれている、まったく余裕の無い状態だと考える必要があります。それこそ、デスマーチ・プロジェクトで行うようなトリアージを最初から行っていくぐらいの危機感を持って再開後のプロジェクトに臨まないと、間違いなく「プロジェクト崩壊」のリスクが高まるはずです。

 

【 プロジェクトは崩壊を運命づけられている! 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
「プロジェクト崩壊」の未然防止策としてプロジェクト中断・再開始を行った場合、再開後のプロジェクトは退路が断たれているという危機感を持って臨む必要があることは前述の通りです。では、そもそものプロジェクトの初期状態はどうでしょうか?

プロジェクトの成功確率はまだまだ低いものであり、前述の通りプロジェクトが崩壊する要因はさまざまあることを考えると、どんなプロジェクトでも最初から再開始したプロジェクトに臨むのと同じぐらい危機感を持って臨む必要があるのではないでしょうか?

プロジェクトは独自性があるだけでなく、必ずスケジュール制約、コスト制約、そして、体制面の制約など、さまざまな制約の中で運営していく必要があります。つまり、前述したようなプロジェクト崩壊のリスクを多く抱えた状態で、かつ、そういったリスクへの対応を十分考慮した理想的な予算や期間、体制などはどれも満たされていない状態でのスタートを余儀なくされることがほとんどです。

確かに、プロジェクトで想定されるリスクを全て洗い出し、それらのリスクへの対応策を十分盛り込んだプロジェクト計画を立てることが大事なのですが、そもそも想定されるリスクへの対応が十分にとれるような予算や期間、体制などが満たされていない状態でプロジェクト計画を組み立てざるを得ないのが実情です。

つまり、ほとんどのプロジェクトは、何も工夫をしなければ「プロジェクト崩壊」が運命づけられていると言っても過言ではないと私は考えています。その中で、なんとかプロジェクトを不時着させるためには、プロジェクト目標にマイナスの影響を及ぼすかもしれないリスクへの対応だけでなく、プラスの影響を及ぼすリスクへの積極的な対応も必要であり、何よりもプロジェクト成功に向けたリアルなシナリオを描いて、そのシナリオ実現に向けてプロジェクトを引っ張っていくような主体的なマネジメントが欠かせ無いのです。(※4)

「プロジェクトは崩壊を運命づけられている!
その運命を変えるのが、PMの使命である!」

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

※1 「しくじり先生_俺みたいになるな!!」『フリー百科事典 ウィキペディア日本語版』
2016年5月6日 (金) 14:44 utc https://ja.wikipedia.org/wiki/しくじり先生_俺みたいになるな!!

※2 南川高志(2013)『新・ローマ帝国衰亡史』岩波書店

※3 プロジェクト・リスクについては、当ブログの以下の回も参照してください。
【第12回】プロジェクト・リスクとは何か?
【第15回】プラスの影響を与えるリスクを無視して良いか?
【第16回】プラスの影響を与えるリスクの具体例

※4 プロジェクト成功のシナリオと演出については、当ブログの以下の回も参照してください。
【第57回】プロジェクトの成功を演出せよ!
【第58回】ピグマリオン効果と席替え大臣

| 目次
Pocket

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事