前回までに、営業戦略、市場・競合分析、そして仮想カタログによって開発コンセプトを明確にしました。
しかし、それだけでは詳細設計を始めることはできません。
まずは現状を理解し、装置として実現すべき性能を具体的な仕様へ展開する必要があります。
そのために作成するのが**開発仕様書（設計仕様書）**です。
現状を理解する
開発仕様を考える前に、まず現状を把握します。
既存機の設計や市場不具合、競合製品などを確認し、何を残し、何を改善し、どこで競争力を高めるのかを整理します。
現状を正しく理解することが、新しい開発の出発点になります。
装置仕様をUnit仕様へ展開する
開発仕様書とは、営業要求を並べた資料ではありません。
装置として求められる性能を、各Unit・各モジュールが実現すべき性能仕様へ展開した設計資料です。
例えば、装置仕様で**TP（処理能力）**が要求されるなら、
•搬送時間
•動作速度
•シーケンス
•各Unitの処理時間
など、各Unitが実現すべき性能仕様へ展開します。
また、装置仕様でパーティクル性能が要求されるなら、
•発塵基準
•動作条件
•評価条件
など、設計・評価可能な仕様へ展開します。
このように装置仕様を各Unitの性能仕様へ落とし込むことで、設計者は初めて「何を実現すべきか」を明確に理解できます。
担当コアエンジニアが作成する
装置は複数のUnit・モジュールで構成されています。
そのため、各Unitの担当コアエンジニアが開発仕様書を作成し、PLや関係部門でレビューを行います。
レビューでは、
•開発コンセプトとの整合性
•Unit間の仕様整合
•技術的な実現性
•評価可能な仕様になっているか
を確認し、開発仕様を確定します。 その後、この仕様書を基に詳細設計へ進みます。
実践知
私が経験した複数の開発現場では開発仕様書を作成しないまま詳細設計を進めているメーカーを見たことがあります。
そのような開発では、設計者自身が「何を実現するのか」を十分に理解しないまま設計を進めてしまいます。
さらに、その内容を他の設計者も共有できません。
つまり、
自分が何を実現しようとしているのかを十分理解しないまま設計し、周囲もその設計意図を知らない状態になってしまうのです。
その結果、
•Unit間の仕様が合わない
•設計者ごとに解釈が異なる
•評価段階で多くの手戻りが発生する
など、設計品質に大きな影響を与えます。
開発仕様書を作る目的は、書類を作ることではありません。
設計者自身が「何を実現するのか」を整理し、その内容を開発メンバー全員で共有することです。
この土台ができて初めて、品質の高い詳細設計が可能になります。
まとめ
開発仕様書とは、
装置仕様を各Unit・各モジュールが実現すべき性能仕様へ展開した設計資料です。
そして、詳細設計とは、その仕様を実現するための具体的な方法を設計する工程です。
「何を実現するのか」が明確になって初めて、「どう実現するのか」を考えることができます。
だからこそ、開発仕様書は単なる書類ではありません。詳細設計の品質を左右する、最も重要な設計資料なのです。
本質
開発仕様書は書類ではない。
開発メンバー全員が同じゴールを共有するための設計資料である。
金言＞「何を実現するか」が仕様。「どう実現するか」が設計。