【イノベーションを生み出すマネジメント】第16話 プロジェクト中止の経済学～サンク・コストとオポティニティ・コスト
◆ゲートがうまく機能しない理由
前回、ステージゲートの話をしたが、ステージゲートを導入している企業の話を聞いてみると、必ずしも、ステージゲートの理念通りに運用されているとは言い難い状況にあるという話をよく聞く。具体的にいえば、ゲートの評価が厳密に機能していない。
その理由が、プロジェクトを中止するプロセスがないことだ。この問題は別にイノベーションや製品開発に限ったことではなく、プロジェクトマネジメント全般の問題である。今回はこの問題について考えてみよう。
一般論として、イノベーションプロジェクトはアイデア出しから、実行段階に移るところでプロジェクトとして組織が承認して、予算をつけていることが多い。ステージゲートでいえば最初のアイデアの絞り込みゲート以前は予算をつけず、最初のゲートを通過したアイデアがプロジェクトをして予算をつけられる。
アイデア出しまでの取り扱いは多様である。もちろん、アイデアの段階からプロジェクトとしている組織もなくはないが、一般的ではない。部門の予算でまかなったり、１５％ルールのように予算管理の俎上に載せないというやり方をしているところもある。
◆サンク・コスト
最初のゲートをくぐる、つまり、プロジェクト予算がつくと、本来はゲートごとに中止判断をすることになるのだが、ここに一つ厄介な問題がある。それは、サンク・コストである。日本語では、埋没費用という。
サンク・コストとは、事業に投下した資金のうち、事業の撤退・縮小を行ったとしても回収できない費用のことである。一般にはプロジェクトの中間成果物の内、他に転用できない成果物の開発にかかったコストはサンク・コストになる。
サ ンク・コストが厄介なのはあとの意思決定に影響を与えるためである。たとえば、製品開発のプロジェクトに計画以上のコストがかかっているときに、赤字を覚 悟で追加投資をすることがよくある。これはサンク・コストにより、プロジェクトを中止するとそれまでの投資分が回収できなくなるという心理的な作用が働く ためであり、これがサンク・コストの厄介さでもある。
◆なかなか面白い．．．
ゲートが機能していない理由の一つはこのサンク・コストであり、その背景にあるのが担当者に失敗の汚名を着せたくないという心理である（もちろん、部下の失敗は自分の失敗として跳ね返ってくるという保身的な心理もある）。
なので、なかなか面白いとか、見込みはあるといった言葉でごまかして、プロジェクトを継続しようとする。アイデアレベルであればともかく、実行フェーズに移ってこんな評価しかできないプロジェクトは即刻中止すべきだ。
◆オポティニティ・コスト
プロジェクトを中止しない言い訳としてサンク・コストがある一方で、それを許しているコスト概念に「オポチュニティ・コスト」がある。日本語では機会費用と言われ、ある行動を選択することで失われる、他の選択肢を選んでいたら得られたであろう利益を意味している。
こちらは、意識することに問題があるのではなく、無視していることに問題がある。プロジェクトを中止しないということは、そのプロジェクトにより赤字が出ること以外に、機会損失を起こしている可能性がある。この点を確信犯的に無視している企業が多い。
昔 からある中小企業の経営論理に、「人を遊ばしておくのなら赤字の仕事でもさせておいた方がよい」というのがある。これは中小企業であれば正しい。中小企業 であればとあえていった理由は、事業が少なく、資本が小さいからだ。この場合、いい時もあれば悪いときもあるとある程度長期間で収支を見ていくことが必要 で、赤字の仕事を全部やめたら、会社を潰す可能性もある。
◆大企業はオポチュニティ・コストを重視すべき
問題は 大企業がこの発想でやっていることだ。大企業の場合、事業の数が多いので、まず、すべての事業が悪くなることはない。併せて、資本が大きいので、ある程度 の期間は耐えることができる。したがって、赤字の仕事をする必要はなく、むしろ、オポチュニティ・コストを気にすべきである。それが、将来の利益につなが る。
つまり、大企業の場合、プロジェクトの中止は非常に重要な判断であるにも関わらず、サンク・コストを強調し、オポチュニティ・コストを無視することによって、中止という意志決定をしようとしない。むしろ、サンク・コストばかり強調して、プロジェクトの延命を図る。
◆中止のプロセスがない
中止の意思がないので、当然のことながらプロセスがない。プロセスがない場合、中止することは必ずしも賢明とは言えなくなる。
た とえば、ＩＴベンダーがいう「顧客がいるのでプロジェクトは中止できない」というロジックがその典型だ。プロジェクトがうまく行かなくて、投げ出したいと いうケースにおいてはそのとおりだ。しかし、中止を契約に折り込んでプロジェクトを進めていれば話は別だ。たとえば、顧客に起因する問題の発生においては プロジェクトを中止できるという条項を入れている契約書は少なくない。この条項に基づくと、発注者が発注仕様の詳細を決めることができない場合にはキャン セルできる。
だが、現実にキャンセルしようとすると、そのあとのプロセスを明確に決めておかないと混乱を来し、顧客に迷惑をかけるだけで はなく、自分たちも傷を負うことになる。たとえば、スルガ銀行とＩＢＭの問題がそうだ。キャンセルは通常の業務プロセスと比較して、較べものにならないく らいにいろいろな問題が生じることが予想される。だから、プロセスを作り、そこに知恵を蓄積していくことが不可欠で、その場の思い付きで処理をすると泥仕 合になる。
◆中止のプロセスと失敗の許容
話が脱線したが、言いたいことは中止のプロセスを作るということだ。イ ノベーションで失敗を許すべきという考え方がある。この問題はここにも絡んでくる。精神論として失敗を許すというのはそんなに難しいことではないと思う。 しかし、現実問題として、失敗にかかった費用の処理をどうするか、中間成果をどうするかとなったときに、そんなに単純な話ではなく、プロセスがなくてはで きないことである。
ここは水掛け論になるが、失敗されると面倒なので失敗を認めない、失敗を認めないので失敗処理のプロセスができない、プロセスができないので面倒であるという構造になっている。
この問題に対処するには、前提を「失敗を許す」に変えて、その前提でのビジネスプロセスを構築していく必要がある。このインフラが重要である。
◆関連セミナー
本連載に関連して、以下の講座を行います。奮ってご参加ください。
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆イノベーションの理論と実際 ◆7PDU's
日時：2013年05月29日（水） 10:00-18:00（9:40受付開始）
場所：銀座ビジネスセンター（東京都中央区）
講師：好川哲人（エムアンドティ・コンサルティング）
詳細・お申込 http://pmstyle.biz/smn/innovation.htm
主催 プロジェクトマネジメントオフィス
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【カリキュラム】
１．技術によるイノベーション
２．ビジネスモデルイノベーション
３．デザインドリブンイノベーション
４．イノベーションマネジメント
５．イノベーション・リーダーシップ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| | 
コメント