ビジネスのための雑学知ったかぶり
ビジネスでも雑学は重要! 知っていると少しは役に立ったり、薀蓄を自慢できる話題をご紹介
プロフィール

RealWave

Author:RealWave
Twitterアカウントはrealwavebabaです。

馬場正博: 元IT屋で元ビジネスコンサルタント。今は「A Thinker(?)]というより横丁のご隠居さん。大手外資系のコンピューター会社で大規模システムの信頼性設計、技術戦略の策定、未来技術予測などを行う。転じたITソリューションの会社ではコンサルティング業務を中心に活動。コンサルティングで関係した業種、業務は多種多様。規模は零細から超大企業まで。進化論、宇宙論、心理学、IT、経営、歴史、経済と何でも語ります。

ご連絡はrealwaveconsulting@yahoo.co.jpまで

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

カテゴリー

ブロとも申請フォーム

この人とブロともになる

お客様カウンター

Since 2009/10/21

ブログ内検索

RSSフィード

リンク

このブログをリンクに追加する

スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

プロジェクト失敗のわけ
space-shuttle.jpg
プロジェクトにリスクはつきもの

プロジェクトは目的があり、決められた期間と決められた資源で達成するものです。逆に言うと、目的が達成されない、期限が守れない、資源を余計に使ってしまうということに一つ以上該当すると失敗ということになってしまいます。アメリカのスタンディッシュ・グループがITプロジェクトを調査したところ、
1) プロジェクトが目的、期間、予算とも計画通りで成功したものは 16.2%
2) 期間、予算を超過し、予定した機能全てを提供することはできなかったものは52.7%
3) プロジェクト自身が放棄されたもの 31.1%

という結果が出ました。これはどう見ても悲観的なデーターですが、他の調査でもプロジェクトの70%以上は何らかの形で失敗しているようです。これはITプロジェクトの話で、土木工事のようなものはプロジェクトと言ってもこれほど失敗が多いわけではないでしょう。それにして7割、8割のプロジェクトが失敗するというのはどういうことなのでしょうか。プロジェクトを製品と考えると、不良品率が70-80%ということになりますが、シックシグマの不良率が100万分の3.4という目標を設定していることを考えると、まったくの別次元です。シックスシグマとかカンバン方式が実現した品質改善をプロジェクトマネージメントではなぜ実現できないのでしょう。電球を100万個作って不良品が3.4個しかできないのに、プロジェクトの80%が不良品になるのはなぜなのでしょうか。

そもそもシックスシグマでプロジェクトを管理しようとしたとき、標準偏差とか何とかいうためには、何のデーターをグラフにしたら良いのでしょうか。宅配ピザなら配達時間をグラフに描くことは意味があるでしょうが、建築で5人家族用に2部屋しかない家を作ってしまうような失敗の平均とか標準偏差は意味があるのでしょうか。ま、このあたりはシックスシグマでも顧客満足のような大きなテーマに取り組むときは同じようなことになるでしょう。シックシグマで最初にするのはベルカーブを描くためのデーターの定義ですから、同じように何かのデーターを取ることはできるかもしれません。問題になるのは、プロジェクトは基本的に一品製品だということです。統計をとる場合、繰り返し多くのデーターを集めることが必要です。しかし、一品製品のプロジェクトではそうは行きません。あるプロジェクトの統計をとっても、プロジェクトチームはデーター収集の段階で解散しているのが普通です。次のプロジェクトはデーターを取ったプロジェクトと似ているところはあるでしょうが別物です。少なくとも電球が似ているほどは似ていません。シックスシグマに限らず、品質管理の基本である多数のサンプルによる統計的処理を行うことがプロジェクトの場合難しいのです。

統計的処理が困難である以上にプロジェクトと普通の製品が違うことがあります。それはプロジェクトは根っこの部分にリスクがあるということです。日常の業務も達成基準、時間(今日中に、今月中に)、使用できる資源は定義されていますが、リスクは非常に希なものと見なすことができます。月産一万台の自動車工場の例えおとると、大雪でサプライヤーの部品が到着しない、集団食中毒で工員が揃わない、突然金が大幅に値上がりして、触媒の価格が予算を超える、などなど色々な状況が考えられますが、毎日毎日立て続けにこのような突発事項が連続していては、安定的に月産一万台の生産を行うことは難しいでしょう。普通の製品製造に必要なのはリスク管理というより危機(クライシス)管理です。リスクに対する仕組み作りは必須ですが、これはリスクがやたらと発生するからではなく、リスクの発生の最小化を行うためのものです。

プロジェクトは違います。ユーザー部門に画面を見せたら「こんなもの頼んでいない」と言われた、パッケージがバグだらけだった。機器の納入が遅れた。下請けがつぶれた。キーの人材が退社したなどなど、リスクは多大にあり、しかも滅多に起きないものなどではありません。プロジェクトにとってリスクは決して「思いがけないもの」ではなく、「起きうるという想定で対処すべきもの」なのです。ところがリスクの想定は簡単なものではありません。ハインリッヒの法則のところでも書きましたが、リスクがトラブルとして表面化するのは、複数の事象(たとえばコーヒーポットが割れていて、バスはスト)が組み合わさって起きるため、思いもかけないことで発生することが多いのです。

それでもリスクの発生を予測し十分な準備をすれば、危機の多くは避けられます。しかし、プロジェクトの多くは「xxに間に合わせる」(xxは工場完成、創立記念日、合併実施など何でも良い)という内容とは無関係に期限が決められることも多く、さらに予算もプロジェクトの中身より「xx億円以内に収めなければダメ」といった、よく言えば経済原則、悪く言えば財布の事情で制限が勝手に作られてしまいます。「これしか金がない」というのは、物を値切るには良いテクニックかもしれませんが、プロジェクトの予算を見積もるのに良い方法とは言えません。

もっと悪いこととして、プロジェクトの目的が明確でないことがあります。これは言ってみれば自動車を作ろうとしているのか、飛行機を作ろうとしているのか、はたまたシステムキッチンを作ろうとしているか、はっきりしていないということで、これではそもそも品質管理などできようはずもありません。橋を架けるようなプロジェクトであれば成果物は誰の目からも比較的明らかですが、「学力の向上」のような目的を掲げると、目的達成のためのプロジェクトの成果物(たとえば学校建設、図書の無料配布、母子家庭の援助などなど)を、何にするかがはっきりしなくなってしまいます。プロジェクトの予算も期限も成果物に対して設定するしかないのですが、成果物自身が目的とずれていてはプロジェクトの発注者が満足しなくてもしかたありません。

 大きな努力が注ぎ込まれたのにもかかわらず、プロジェクトの品質管理は満足できるレベルかはほど遠い状況にあります。これが、たとえば自動車であれば新車を受け取って、すぐにディーラーに駆け込むということはありません。30年前の自動車と今の自動車では品質に格段の差があります。電気製品、飛行機、薬、どれを取っても品質は年々向上して不良品にお目にかかる確率は、昔と比べ著しく小さくなっています。しかし、プロジェクトでは、徹夜徹夜の連続で病人が続出したり、予算オーバーでプロジェクトマネージャーが首になったりは相変わらず普通のことです。目的と成果物の整合性にいたっては、IT業界では昔より悪くなっていると思われます。今から40年も前にIBM のS360の開発者であったフレデリック・P・ブルックスは人をつぎ込んでも、開発期間(月数)は反比例して短縮することはないという事実をThe Mythical Man Month(人月の神話)という本で著しました。彼がその著書の20周年記念版で「いまだに人月の神話が多くの人に読まれているのは驚きだ」と言っていますが、それからさらに20年の歳月が流れました。IT業界では人月以上の有効な管理指標は生み出されていません。今でもブルックスは、同じ驚きをもってプロジェクト管理の現状を見ているのでしょうか。

fredbrooks02.jpg
フレデリック・P・ブルックス
スポンサーサイト

テーマ:経営 - ジャンル:政治・経済

この記事に対するコメント

この記事に対するコメントの投稿














管理者にだけ表示を許可する


この記事に対するトラックバック
トラックバックURL
→http://realwave.blog70.fc2.com/tb.php/45-774ed013
この記事にトラックバックする(FC2ブログユーザー)

淋しがりや

超ウキウキなんですけど。おかげでブログも進むよ またいっしょだね。うれしくない?【2006/10/16 22:17】

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。