伝説のパソコン：９８ＦＥＬＬＯＷ物語（１５）ー開発管理のノウハウ（２）
開発管理のノウハウ（２）
２．フロント・プロセスを最重視する
「開発プロセスとは不確実なものを確実にしていくプロセス」と言われます。不確実な要素を早い段階で確実にしてゆくためには開発のフロント・プロセスへの取り組みが重要です。
開発プロジェクトの成否は開発のフロント・プロセス（前工程：仕様ＦＩＸ、開発リスク分析、開発線表作成、設計＆デザインレビュー、試作機評価ーーなどの開発の前段プロセス）を重視して、如何に練った開発計画を作成できるかによって8割方は決まってしまいます。（フロント・フォーカス重視）
図４はフロント・プロセスのマネジメントに失敗して、技術問題を完全に解決できないで積み残したまま後工程に移行して、結果として後工程で問題が多発し、その対策に多大の対策工数を費やした失敗プロジェクトのイメージ例です。
黒線は計画した投入工数ですが、実績は赤線の投入工数となり後工程で大幅な追加工数を投入せざるを得なくなっています。
そうなった原因は次のようなことが考えられます。
① 製品仕様のＦＩＸが予定日より大きくシフトしたが、後工程の日程は出荷日程をキープするためにシフトをさせることができず後工程にしわ寄せとなった。そのため、設計品質の作り込みに時間が十分に掛けられず試作機の完成度が悪かった。
② 製品仕様ＦＩＸが遅れた分を取り返すための応援リソースなどのリカバリー策が適切に組織的に打たれなかった。
③ 開発計画時に「開発リスク分析」が不十分で、リスクヘッジ策を開発線表に織り込んでいなかった。（リスクヘッジ策とは例えば、ボードやＬＳＩの改版が余分に入るマージン日程を開発線表で計画するなど）
④ 試作段階で後工程評価項目（互換性、システム評価、環境･ノイズ，ＡＰ評価）をできるだけ前倒し実施する計画となっていなかった。 その結果、量産先行機（ＰＰ）段階で技術問題が多発し、多くの手戻り工数が発生した。
⑤ 試作機（ＥＳ)、量産先行機（ＰＰ)の完成度が不十分で、余裕がないまま量産（ＭＰ）工程に入らざるを得なくなり、潜在問題の発見を見落とした。 そして出荷後に問題発見され大きな対策費用が発生した。
以上の例より、開発プロセスは後工程よりも、むしろ前工程が如何に大事か、フロントプロセスにフォーカスする重要性が理解できると思います。
ところが、現実には開発の前工程では、開発部の特定グループに任せられてスモールスタートする場合が多いことや、出荷日程が半年先で切迫感がまだまだないことから、フロント・フォーカスが十分にできていないケースが多いのです。
後から考えると、９８ＦＥＬＬＯＷの超速２ヶ月の開発リードタイムは、逆に超短納期かつビッグプロジェクトであるが故に、このフロント・フォーカスに必死にならざるを得ず、後工程に大きな問題を持ち越さなかったことが成功した大きな要因の１つであったと考えられます。
Follow me!
“伝説のパソコン：９８ＦＥＬＬＯＷ物語（１５）ー開発管理のノウハウ（２）” に対して1件のコメントがあります。