■開発現場の悩み・問題点を解く １９ （No.336）
中断すべきプロジェクトが止まらないでムダな開発が行われている。
開発現場の実情
開発をスタートした時点とは，その後の開発状況・環境（内外）などの変化によってプロジェクトとしての進め方が変わってくる場合がある。特に，開発プロジェクトとしてスタートしたものの，このまま開発を続けても市場に受け容れられないことが起こる。それは以下のような場合である。
なぜ，ムダなプロジェクトが中断できないのか？
開発現場として，上述したような製品化が困難，或いは不可となったプロジェクトでも，そのまま開発が行われていることをしばしば見掛ける。一旦，新製品開発プロジェクトとして登録され，開発がスタートすると，環境変化（内部・外部）があったからといって，開発がムダになることが判っていてもストップできない状況にある。
開発のプロジェクトリーダには，プロジェクトを当初設定された目標をスムーズに完遂させる使命が与えられている。したがって，目標到達が困難な状況が発生したりすれば，直ちに対処すべき方策を練り，軌道修正をしなければならない。与えられた権限内で対処できない場合は，上に報告して援助を申請したり，他からの援助を受けて，初期の目標を必達しなければならない。
しかし，開発プロジェクトリーダ自身が，上述した内部・外部の環境変化により，プロジェクト自体をストップさせることは先ずあり得ないし，その権限を与えられてはいない。ストップさせるべきと感じること自体が，自己否定することに近く，余程誰の目から見ても明らかな状態になるまで，ストップできないのが実態である。何故なら，少し悪化した環境程度なら，プロジェクト内で軌道修正しようとすることが可能であり，また上に申告すること自体躊躇することが多い。
また，開発プロジェクトリーダ自身としては，折角ここまで開発を進めてきているので，例え製品化ができなくとも，開発した技術は次に活かせるので，技術開発だけはやり遂げたいと感じることが多い。この考え方は技術者としては当然のことで，技術の蓄積があってこそより良い製品が市場に送られるのだからである。しかし，経営的に見ると，この考えは技術者の独りよがりで，別のプロジェクトに開発リソースを向けて新たな開発をすることと十分な比較をしての判断では無いことが多い。今までの流れ上，技術開発を完了した方が良いと考えているだけであることが多い。
こうしたプロジェクトの中断を判断するのは開発プロジェクトリーダの役割ではなく，その上のプロジェクトをさせている上司の役割である。ところが実態は，開発プロジェクトリーダに任せっきりで，プロジェクトの中断を判断する役割を積極的に担う上司は少ない。開発の中断をすれば今までの開発のロスが明らかになり，マイナス要素になる。ところが，開発をそのまま続行して，製品化されないままプロジェクトが完了しても，誰の責任にもならないからである。敢えて火中の栗を拾う役割をしないのである。これが殆どの企業の開発実態である。
こうしたムダなプロジェクトの続行はこれまで山ほど見てきた。現在もどこかで多くのプロジェクトがそうした状態で続行されていると思われる。
規定・基準などは？
大企業ならずとも，企業の中では新製品開発管理規程（規定・基準など）があり，新製品を開発する手順があるはずである。そこには，開発のやり方だけでなく，開発ステップを進めていく段階で次に進むかどうか判断するゲート（会議・又は書式など）が設けられていて，開発当事者（開発リーダ）から報告を受け，その上の上司が判断・承認することになっていることが多い。
ところがこの実態は，きっちりプロジェクトを進めるか否かを判断していることは少なく，規定や基準があるから，形式的に会議や書類を作成しているだけのことが多い。具体的な技術内容の吟味や原価構成の検討など詳細な部分の検討はきっちり実施されている場合が多い。だが，実際，開発プロジェクトを中断した事例がどれだけあるか，見直して貰ったら明らかで，途中中断は殆ど無いのが一般的な傾向である。以前は，他社に多少遅れたりしても成長市場では受け容れられることが多く，途中中断は殆ど無かったが，最近は市場の反応も敏感で，容易に受け容れられないことが多いので，以前よりはＧＯ−ＮＯの判断基準が厳しくなっているかも知れない。
こうした規定や基準の中に，次の開発ステップに進むかどうかの判断をきっちり盛り込み，実際の運営上で，上司がきっちり判断することを実施すれば，少なくともこれまでのようなムダな開発続行は回避されるものである。しかし，現実には・・・。
開発ロスを無くす仕組みとは
最初に述べた開発現場の実情で，開発プロジェクトを中断した方が良いと感じるのは誰か？ 市場環境の変化などは営業第一線の市場情報を把握している者である。内部事情の変化は，その内容にも依るが，プロジェクト自体のことは，やはりプロジェクトリーダであり，内部の経営事情などはその関連の責任者であろう。こうした内外の環境変化を開発途上でフィードバックできている仕組みが重要なのである。
一般的に開発ロスは早い段階に手を打つほど被害は少ないと言われている。開発の初期段階であれば，開発プロジェクトそのものに関わった人件費や研究開発費だけで済み，設計完了した量産目前まで進むと量産を目論んだ先行手配している費用など，関係部門が拡大し費用も膨らむ。さらに一旦量産まで入ってしまうと，量産初期に掛かる費用など，開発段階とは比較にならない費用（数倍から数十倍に膨らむ）になってしまう。だから，製品化が困難と判断した時点が早ければ早いほど開発ロスの被害は少なくできる。
つまり，開発の初期段階から常に，製品化に向けて，次の開発ステップに進むべきか否かを判断するゲートを設ける開発過程の仕組みが必要なのである。これが所謂，新製品開発管理規程（呼び名は各企業によって違うが）なる，開発のステップ及び進捗判断を示すものである。こうした開発のきまりが開発をスムーズ且つロスを少なくさせる仕組みなのである。
多くの企業がこうした開発のきまりを設けているが，その運用実態がどうなのかが，一番問題なのである。立派な仕組みはあっても，形骸化している例は多く見受けられる。それが一番問題であり，きまりを作ることはもちろん，それを実際に運営できることが重要なのである。
ムダな開発プロジェクトが進んでいませんか？
開発ルールを遵守して，開発の次ステップへの移行が判断できていますか？
[Reported by H.Nishimura 2013.09.02]
Copyright (C)2013 Hitoshi Nishimura
