■開発プロジェクトの失敗事例 １（No.107）
開発プロジェクトを進める上で，折角開発したものが上市（じょうし put on the market）されずに技術開発だけで終わってしまう場合がある。よくある話は，「研究所だから市場に出すか出さないかは事業部門の担当だから関係ない，我々のミッションは新しい技術開発である」と云ったことである。確かに研究所は，中長期的な視点から技術開発をする役割を担っているので，その見解は正しい。
ただ，昨今の研究所は，その会社によって違うが，純然たる技術開発だけをしていることは少ない。むしろ，半分以上は２，３年先の技術開発をやり，事業部門へ展開して製品化を目指していることになっている場合が多い。
ここで述べるのは，こうした２，３年先に製品化を前提とした研究部門における開発が上手く行かなかったケースについてである。
1年以上掛けた開発プロジェクト内容の殆どが製品化されずに技術開発しただけでお蔵入りになってしまった。つまり，折角時間を掛けて開発した成果が無駄になってしまった，つまり会社としては大きなロスが発生したのである。ところが，こうしたロスに対して，会社の誰一人として責任を感じている人が居ないのである。当事者不在なのである。不思議なことである。こうしたケースは決して稀なことではない。
そこで，技術と経営との両面からこの問題を掘り下げてみることにする。
具体的には次のような内容になる。
研究部門でスタートした開発が，早い段階から事業部門でのシステムとして搭載できないことを知りながら，技術開発のスコープとして止めることなく開発してしまった事例である。
つまり，今回のケースの原因を突き詰めると
研究部門の開発責任 ：開発スコープをやりきること
当初設定された開発スコープに対して，市場に満足する性能，品質目標を達成する技術開発を
やり終えた
事業部門の製品化責任：市場に満足する製品を提供すること
研究部門で開発した技術開発は，当初の優先度から変わり，低くなった機能や，市場要求から
見ると従来製品との互換性などの問題が解消できず，そのまま市場に出荷すると混乱を来たす
ため，開発された機能の製品化を見送った
両者とも自部門のミッション（役割）は果たしているにも拘わらず，折角開発したものが製品化を見送ることなり，会社としては大きなロスが出たのである。
開発経過をもう少し詳細に見てみると，一つの機能に関しては，開発のかなり早い時点で（設計が始まった時点），既に関連するシステムの並行開発が，事業部門の意向（機能の優先度が低下したため）を踏まえて早々頓挫している。つまり，自分達が開発しても製品化の実現ができないことがこの時点で判っていたのである。にも拘わらず，開発プロジェクトのリーダは黙々と開発を続けていたのである。
それは，自分のプロジェクトとして，スコープ外の判断がなされなかったためである。と云うか，並行開発のシステムとは関係なく開発を進めるものとしていたため，上司にそうした変化に対する判断を仰ぐこともなかったのである。一方，上司の方も並行開発のシステムがスコープ外になったことは自分の範疇のプロジェクトだったので知ってはいたが，明確な判断は避けてしまっていた。こうした場合，開発プロジェクトをストップさせるには勇気が居る。それは，今まで掛けてきた開発が無駄になり（サンク・コスト），且つ途中でストップすることはリソースを何か別のプロジェクトに振り向ける必要がある。人が足りなく逼迫したプロジェクトがある場合は，すぐにそちらに充てることができるが，通常はすぐに充てるプロジェクトが無く，開発者を遊ばせることになってしまい，ついそのまま開発を続けさせる方が余計な仕事をしなくても済むので，見てみぬ振りをしてしまう場合がある。それを，ぐっと自分の責任に背負って判断してくれる上司はそうはいないものである。
また，製品の中のもう一つの機能は市場での互換性が問題になり，結果的に製品化を見送ることになった。
これも，製品企画の段階では，互換性に関してメリット／デメリットが議論され，メリットがデメリットよりも高く，開発することに決定した経緯があった。しかし，このメリット／デメリットの部分でデメリットの部分が十分検討されていたかと云うと甚だ疑問な部分がある。つまり，検討段階で，互換性のデメリット部分が経験も浅く，クローズアップされていなかった可能性がある。トップの判断を仰いだ決定とはいえ，十分な情報が無い基での判断は決して正しいとは云えない。実際，別の部門の経験者からは，開発内容の検討段階にて，「互換性の問題が大きい。この検討を十分やっておかないと取り返しがつかないことがある。それは経験したものしかなかなか判らないが，十分な検討をしておいて欲しい。」と警告が発せられていた。開発者にとって，その警告は初めて耳にする（何となく互換性は問題がありそう程度の理解はあったが）ことで，警告された内容に関しては，具体的に検討項目に入れ，プロジェクトの計画に盛り込むことにした。しかし，ここでの検討は，言われた内容だけの検討に止まっており，広く影響範囲を検討しようとする意志まではなかった。つまり，経験者からの忠告がどれほど重要だったか十分考慮できなかったのである。
その結果，研究部門の開発の終盤になって，事業部門が引継ぎに当たって，市場での互換性問題を真剣に検討するようになった。そうすると互換性のメリットよりもデメリットが大きく製品化しない，つまり従来のままの方が市場を混乱させないことがわかり，研究部門で開発した内容は取り入れないことになった。事業部門にとっては，自分達に掛かる火の粉(市場問題の発生）を未然に防ぐことで，事なきを得たとの感覚である。結果論として，もっと早くから検討しておけばとの声もあるが，やはりどの部門も，いざ目の前にならないと真剣な検討ができないものなのである。
（続く）
開発プロジェクトを途中で中断することは勇気がいる
開発プロジェクトにはリスクがつきものである
[Reported by H.Nishimura 2009.03.02]
Copyright (C)2009 Hitoshi Nishimura
