にほんブログ村「機能設計書」は、設計者の頭の中にある“考えの流れ”を、第三者が見ても理解できる形で残すためのツールです
設計品質向上の要であり、製品開発の効率化にも大きく貢献します
今回は、その記入項目とポイントを整理します
機能設計書の役割
機能設計書は、設計の目的・背景・根拠・手段を体系的にまとめることで、
- チーム間での認識共有
- レビューや承認の効率化
- 技術の蓄積と継承
を実現します
特に「なぜその設計を行ったのか」という根拠を残すことは、品質保証や後工程でのトラブル防止に直結します
基本構成と記入項目
機能設計書の代表的な構成は以下の通りです
機能名（または部品名）
対象となる機能や部品を明確に記載します
機能を言う場合は〇〇（名詞）を〇〇する（動詞）の形を取ります(これ結構重要！）
目標（品質要求）
顧客要求や市場ニーズを、測定可能な数値・規格に変換して記載します
例：耐荷重500N、動作音40dB以下など
お客様は決して数値化した要求をしてくれません
技術者がお客様のニーズを数値に転換し、これが商品の性能に大きく影響します
さらに、主機能の目標値に加えて、付加的に要求される機能の目標値も設定します
その場合、下記要素を検討するなどしてヌケ・モレを防ぐことが重要です
性能・安全性・信頼性/耐久性・外観・輸送性・施工性/組立性・使用性・保守性・環境調和性・弊害抑止性・・・
新しい機能は大きな変化点です
その変化に対するリスクをしっかり検証しましょう
根拠（なぜその目標か）
目標設定の背景や理由を明確にします
顧客仕様、法規制、過去実績、競合比較などが含まれます
あくまで顧客目線がベースです
個人的は、これが最重要と考えています
目標値を適切に設置していない、安易に前例などから決めたために市場で大きな問題になった事例はたくさんあります
法規制や過去実績だけで、市場が変化する環境下でお客様に満足いただけるとは限りません
手段（実現方法）
設計案や使用技術、材料選択、構造、コスト、さらに品質要求で上げた10項目の観点で、復讐の手段を比較を比較をして手段を決定します
別シートで「技術手段評価表」を使って比べることをお勧めします
設計根拠（論理的検証）
手段後具体的設計を行い、この根拠を明確にします
「評価」での検証ではなく、あくまで設計段階での論理的な裏付けを示します
以下のような情報が主な根拠となります。
- 理論的な設計式やベースとなる実験データ、またそーのデーターから導きだされた計算式
- 引用技術方式（標準化規格や業界標準）
上記が難しい場合は、
‐適切な過去実績
ｰCAEによるシミュレーション
※「評価」とは、設計後に実物や試作品で確認する行為であり、設計根拠とは区別します
設計根拠は、評価前に設計の妥当性を理論的に確認するものです
記入のポイント
誰が読んでもわかる言葉で書く
専門用語や社内略語を減らし、初めて読む人でも理解できるようにします
数値化する
曖昧な表現を避け、可能な限り数値・規格値で示します。
「前商品と同等」とういう表現をよく見かけます
何をもって「同等」定義しなければ、設計者の都合で性能を下げてしまう場合がります
根拠を必ずセットで
目標や手段を単独で書かず、必ず根拠を添えることが必須です
この根拠を全員が理解しておくことが、お客様へ商品をお届けした時の問題発生防止につながります
また、問題発生時に「なぜ発生したのか」レビューのレベルがあります
失敗事例も記載
注意点や過去のトラブル事例を明記することで、同じ失敗を繰り返さない仕組みを作ります
書くタイミングと運用
- 設計初期から並行して記入し、後でまとめ書きしない
- チームレビューを行い、第三者の視点で抜け漏れをチェック
- フォーマットを統一し、情報比較や検索性を高める
あくまで目的に合った運用を心掛けてましょう
書くことが目的ではありません
設計完成度を高めることが目的です
まとめ
機能設計書は「説明できる設計」を実現するための必須ツールです
特に「設計根拠」を論理的に示すことは、設計品質の安定化とトラブル防止の両面で効果を発揮します
設計の妥当性は、評価の前段階で理論的に検証する
——この姿勢が、強い設計現場を作ります
コメント