他部署の協力を得るためにも、初めにしっかり「すり合わせ」をして方向性を合わせる事は非常に大切です。

　有りがちなのは、５Ｗ１Ｈレベルで確認が取れていなかったり、思わぬメンバーから話が違う、聞いていない。とクレームがはいったり、役割分担が不明確で実際に進める際に、それは○○の仕事だと思っていた。などです。

初めから完璧なものは造れませんし、状況も変わっていきます。一度決めたから大丈夫ではなく、その後も確認して行く事は大切ですが、やはり最初がやはり肝心です。

後で揉めるよりは最初に揉めておいた方が実害は絶対に少ないです。

実害だけでなく初めに話せば説明と受け取ってもらえますが、揉めた後で説明しても言い訳のようにとられてしまうから不思議です。

　その為に、私は開発計画書と称した書類を作成し議論していました。以下に開発計画書に記載すべきと思われる項目は以下のようなものになります。

1、背景

開発を始めるに至った背景、社内状況、市場状況等を記載

2、開発の目的・目標

２－１）目的

その開発は何のためにするのか？ということです。例としては以下のようなものを想定しています。

• コストダウンのため、
• A社の参入障壁になっている品質案件で、他社を凌駕し、新規に参入するため、
• B社向けで、他社に劣っている〇△の品質で、他社を凌駕し、シェアーアップを測る。

２－２）目標

目的を達成するための道しるべ、となる目標。５W1Hを入れて、具体的に何を達成すれば良いのか、メンバーが共有できることが非常に大切になります。

３、開発範囲

　対象機種、対象ライン、対象工程等、やらないことも記載した方がはっきりして良い。

４、開発コンセプト

　　目標を達成するためのより具体的な方法、また、開発を進めるにあたっての全体の考え方、という意味で開発コンセプトといった言葉を用いています。

　例えば梱包容器のコスト削減で言えば以下のようになります。

• 容器仕様見直しによる50%以上のコストダウン、
• 品質やハンドリング性能は前機種同等以上、
• 前機種と使用上互換性がある事

５、開発進捗状況

　詳細資料はデザインレビューの結果を添付資料とし、量産対応の目途が得られた旨を簡単に記載。

６、開発体制

6-1)開発責任者

　この開発を進める責任者、他部署とのインターフェイスも務める。

　参考までに私はデザインレビューの際に設計/開発チームのリーダー(課長職相当）が開発規模/困難度に応じて責任者を決める事としていた。役職で事前に決めておいてもよいが、ガイドライン程度で、決定者が誰か決めておく方が運用しやすい。

　社内プロジェクトとなる場合、必ずしも、設計/開発部門のメンバーが責任者にならなくても良い。

6-2)設計審査/決裁者

　開発責任者とは別に最終的な決裁者を決めておく必要がある。決裁者は社内の決裁基準があるのならそれに準じるのが望ましい。

6-3)役割分担/責任者

　設計/開発部門だけではないので役割分担と責任者/メンバーを決める。他部署のメンバーは具体的にどういった仕事をしてもらうのか、イメージを共有し、先方に決めてもらうのが良い。

6-4）インターフェイス

　例えば隔週の進捗会議の開催、等、この会議ですべてのアクションを決めて行く。スケジュールを都度調整するのも大変なので定例会議をお勧めします。

　各部門の考えを集約し、開発計画書にまとめ上げるのは非常に大変です。私も色々失敗して来ました。上手く交渉しまとめ上げていくにはどうすれば良いのか、次回、お話したいと思います。

７、制約条件

お金や人材など無尽蔵にあるわけではありません。本格検証を進める上での制約条件、前提条件を洗い出して初めに確認しておきます。

８、主要マイルストーン/スケジュール

要素技術を量産レベルで問題ないか検証して行くのが本格検証ですので、量産化するまでのマスタースケジュールを作成し、開発計画書にまとめて各部門と協議することになります。

したがって、マスタースケジュールは全体を見渡して、マイルストーンを明確にし、主要な課題を示したスケジュール表となります。

具体的には以下のようなイメージです。

まとめ

本格検証を進めるには各部署の協力が不可欠であり、初めにしっかり検証の進め方、開発体制などの進め方をしっかり「すり合わせ」をして方向性を合わせる事が非常に大切になります。