にほんブログ村〜設計の意図と根拠を“見える化”するという発想〜
「この設計、なぜこうしたんですか？」
開発の現場でこんな質問が投げかけられたとき、返ってくる答えはこんな感じだったりしま
「過去の実績ベースで問題なかったから」
「他社も似たような設計をしているから」
…うーん、それって本当に根拠と言えるでしょうか？
お客様が本当に求めている品質なのか、設計の意図は正しく伝わっているのか,その根拠は論理的か
私は長年、設計レビューや現場のトラブル対応に関わってきましたが、
「見えない設計意図」
が原因で起こる問題を（自分がやってしまった問題も含めて）たくさん経験してきました🤣
そして前回設計の「見える化」の必要性について記事にしました
そこで今回は、そんな“設計の見える化”を実現する技術文書「機能設計書」について、その目的や効果、現場での使いどころをご紹介します。
設計意図を共有化できないことによる無自覚な問題点
設計は“理詰め”のようでいて、意外と“感覚的”に進んでいる部分も多いものです
（残念ながら私の経験上・・・😵💫）
「この構造は従来と同じだから」
「とりあえず目標は前回と同等で」
「他社も同レベル」
といった、弱い根拠をベースに判断して進んでしまう
その結果、お客様が受け入れられる品質目標、それを達成するための設計根拠・ポリシーが共有できない
その“見えない根拠”が、設計品質の低下を招き、後々の品質問題や手戻りにつながっていきます
何度痛い思いをしたことか😱
設計検討の際に
「その目標はどうやって決めたのか？」
「なぜその値にしたのか？」
と聞かれて、明確な答えに詰まることも多いです
設計とは本来、論理的に説明可能な技術判断の積み重ねのはずなのに、その技術判断が「見える化」されていない状況です
設計の「意図」を「見える化」する「機能設計書」
機能設計書とは、「その目標値を設定したのか」「なぜその設計にしたのか」「どうやってその品質を確保するのか」を明文化するための文書です
単なる図面や仕様書では表しきれない設計者の思考プロセスを、関係者に伝えるための“設計の説明書”とも言えます
特に重要な機能要素に絞って、「目標」「目標の設定根拠」「手段」「設計の論理的根拠」をセットで記述するのがポイントです
- 目標（品質要求）：お客様が求めている価値を技術的な数値に変換したもの（基本性能だけでなく、耐久性・コスト・使用性含む）
- 根拠（なぜその目標か）：なぜその数値や目標値が妥当か、背景・前提・基準を明確にする
- 手段（その機能をどの技術手段で実現するのか）：設計アイデア・構造・材料・技術などの選択肢
- 設計の論理的根拠：手段を使って品質要求を実現できる論理的根拠、考え方、データーベースを明確化
これらをセットで記録することで、設計の妥当性を社内外で共有し、レビューや承認もスムーズになります
また、技術資産として蓄積し、次世代に繋げます
機能設計書がもたらす３つの効果
前回の記事で「設計の見える化」には3つの効果があると書きましたが、ここでもそのまま当てはまります
開発の質が高まる
目標や設計の根拠を言語化することで、開発メンバーと共通認識ができ、レビューでの議論も深まります
トラブルの芽を早い段階で摘み取ることができるのです
技術の資産化と人材育成が進む
ベテランの「なんとなく」を形式知として記録することで、若手への教育ツールにもなります
属人化を防ぎ、組織全体の設計力も強化できます
業務効率が向上
後工程での確認作業や調整も減り、設計から量産までの流れがスムーズになります
この見える化を実現させるのが「機能設計書」になります
そして「機能設計書」そのものを作成することにより「設計の論理性と妥当性を高める」ことができます
設計者の「感覚的な判断」に論理の軸が加わり、技術的な説明力が格段に上がります
「なぜその構造？」「なぜその材料？」と聞かれても堂々と答えられるようになります
設計者個人のスキルアップにも大きく貢献できることになるでしょう
「ありがちな課題」にこそ効く！
私が現場でよく見てきた“あるある”課題にも、「機能設計書」が効きます。
- トラブルが起きても設計意図がわからず、原因が曖昧に…
- 担当者が異動・退職し、設計の背景がブラックボックスに…
- 若手が図面だけを見て表面的に真似するだけの設計に…
- レビューで「その根拠は？」と問われて答えに詰まる…
これらは、設計が「見える化されていない」ことで起きる問題
まさに、機能設計書が真価を発揮する場面です
面倒でも「開発ルール」に組み込むべき
「書くのが面倒そう…」という声もあります
でも、このひと手間が、後に発生する品質対応を防いでくれるなら、よっぽどありがたい話です
しかし、設計者は目先の問題解決を優先し、将来起きうるリスクに対してのアクションが弱くなる傾向があります
（実際、私もそうでした🤣）
この気持ちを払拭するには
開発プロセスのルールにして開発時段階移行承認の条件にする
ことが絶対です
どこの開発での、開発プロセスが標準化されており、商品化推進を決定するタイミング、出図、技術試作、量産試作、量産等には何らかの商品があるはずです
承認条件に「機能設計書」によるデザインレビューを条件にすれば、いやおうなしに書かざるを得ません
設計者に求められるのは「語れる力」
最「設計図を描く」ことが仕事ではなく、「なぜそれを描いたのかを語れる」ことが設計者の本当の力です。
機能設計書はそのためのツールであり、組織全体で設計の質を底上げする仕組みです。
論理的な説明ができることで、設計の品質も、技術者としての自信も高まっていきます
次回は、実際にどんなふうに「機能設計書」を書くのか、紹介します！
コメント