製品設計プロセスと要件定義基本設計

製品設計プロセス

製品設計プロセスの要件定義の進め方

建築の現場で「製品設計」と聞くと、設備機器・建材・ユニット（トイレ、EV、制御盤、サッシ、耐震部材など）を想像する方が多いはずです。ここで言う要件定義は、単に仕様書を集める作業ではなく、「なぜ必要で、何を満たすべきか」を関係者が同じ言葉で言える状態を作ることが核心です。
要件定義が弱いと、後の基本設計・詳細設計で「想定していた前提」がズレていることが発覚し、納まり・干渉・法規・メンテが一気に噴き出します。システム開発の整理ですが、要件定義はWhy/What、基本設計はHowという切り分けは、建築の製品設計でもそのまま役に立ちます。
要件定義で、最低限そろえるべき要素（建築従事者向けの実務寄り）は次のとおりです。

• 用途・目的：誰の何の課題を解くのか（例：保全の工数削減、漏水リスク低減、エネルギー削減）。
• 性能要件：数値で語れるもの（耐火、耐食、耐圧、耐震、騒音、流量、消費電力など）。
• 制約条件：設置スペース、搬入経路、既存躯体条件、停電時の挙動、点検頻度、交換周期。
• 法規・基準：消防、建築基準、設備関連、社内基準、発注者仕様。
• 受入条件：検査方法、立会い、引渡し成果物（取説、竣工図、属性情報など）。

意外に見落とされがちなのが「検出可能性（見つけやすさ）」を要件段階で語ることです。後述のFMEAでは検出難易度を評価し、RPN（影響度×発生頻度×検出難易度）で優先順位を付けますが、検出方法を後回しにすると“検出できない不具合”が現場に残ります（たとえば壁内結露や、稀に発生する制御異常など）。FMEAの枠組みでは検出難易度を10段階で扱い、検出不可に近いほど点数が高くなるため、設計で「どう検知するか」を先に置くのが合理的です。

参考：工程FMEAの定義、RPN（影響度×発生頻度×検出難易度）、検出難易度の考え方
FMEA（故障モード影響度解析）の概要とRPN算出・検出難易度の考え方

製品設計プロセスの基本設計の設計情報

基本設計は「ユーザーがわかる粒度で各機能を設計する」段階だと整理されます。これを建築の製品設計に置き換えると、「発注者・設計・施工・保全が、同じ図面・同じ仕様で合意できる粒度」に落とす工程です。つまり、詳細図や製作図に入る前に、関係者の論点を潰すための設計情報を用意します。
基本設計で押さえる設計情報（例）は、次のように“後工程が止まる原因”から逆算すると漏れが減ります。

• インターフェース：建築側（躯体・仕上）と製品側（機器・ユニット）の取り合い寸法、固定方法、荷重条件。
• 運用シナリオ：通常運転、停電・断水・火災信号時、点検時の状態遷移。
• 施工性：搬入・揚重・仮置・組立・養生・試運転の順序と必要スペース。
• 保全性：点検口寸法、フィルタ交換動線、消耗品の交換周期、工具要件。
• 検査性：どこをどう測るか、合否基準、記録の残し方（紙かデータか）。

この段階で効果が大きいのが、レビューの“参加者設計”です。建築の製品設計は、設計者だけで閉じると、施工や保全の現実が後から入ってきて手戻りになりがちです。基本設計レビューには、少なくとも施工側（手順・仮設・安全）と保全側（点検・交換・故障対応）を入れて、要件が現場で成立するかを早い段階で検証します。

また、基本設計は「決めた理由」を残す工程でもあります。要件定義→基本設計→詳細設計という流れの中で、なぜその案を採用したか、なぜ別案を捨てたかが残っていないと、半年後の変更協議で同じ議論を繰り返すことになります。システム設計の文脈でも、基本設計段階で没案も含めて文書化することが推奨されており、建築の設計変更協議でも強い武器になります。

製品設計プロセスのV字モデルとテスト

建築の製品設計は「作って終わり」ではなく、試運転・性能確認・引渡しで価値が確定します。ここで役に立つのがV字モデルの考え方で、要件定義・基本設計・詳細設計といった開発工程に対して、対応するテスト（受入、結合、単体など）を対応付けて抜け漏れを防ぐ整理です。V字モデルは、どの設計成果物に対してどのテストが対応するかを明確にでき、テスト漏れを防ぎやすいとされます。
建築の製品設計に翻訳すると、例えば次のように“対応関係”を最初に宣言しておくと、引渡し直前のバタつきが減ります。

• 要件定義 ↔ 受入（性能）確認：要求性能（流量、温度、騒音、非常時挙動など）をどう確認するか。
• 基本設計 ↔ 結合（取り合い）確認：干渉、配管勾配、点検性、制御連携（火報・BMS）をどう確認するか。
• 詳細設計 ↔ 単体（部品・機器）確認：機器単体の動作・設定・安全機能をどう確認するか。

重要なのは、テストを「現場でやるもの」だけにしないことです。設計段階でできる検証（シミュレーション、干渉チェック、施工手順の机上検討）を、テスト計画として扱うことで、現場試運転の負担が軽くなります。V字モデルはウォーターフォールに対してテスト工程を対応させた考え方として整理されるため、上流でテストを設計する発想と相性が良いです。

製品設計プロセスのFMEAとデザインレビュー

建築の製品設計では「不具合が起きないようにする」だけでなく、「起きても致命傷にならない」「早く検出できる」設計が求められます。ここでFMEA（故障モード影響解析）は、故障モードを事前に洗い出し、影響を分析・評価して対策する手法として整理されています。FMEAは製品設計段階に使う設計FMEA（DFMEA）や、製造工程に使う工程FMEA（PFMEA）などに分類されるため、建築の製品設計では“設計”と“施工手順”の両方に適用しやすいのが利点です。
実務で使いやすい進め方は、「納まり・施工・保全のどこで失敗するか」を起点に、故障モード→影響→原因→検出→点数化の順で埋めるやり方です。工程FMEAの説明では、影響度・発生頻度・検出難易度を評価し、RPN（影響度×発生頻度×検出難易度）を算出して優先順位を付けるとされています。さらに、影響度は基本的に下げにくいので、発生頻度または検出難易度を下げる対策を考える、という方針が明確です。

現場寄りの“意外と効く”FMEAの論点は、次の3つです。

• 設備・人・材料・方法・計測まで含めて故障モード対象にする（施工手順や検査方法もリスク源になる）。
• 検出方法が「目視」だけの項目は、検出率100%にならない前提で評価する（人の確認は必ず揺らぐ）。
• 点数の粒度は10段階にこだわらず、現場に合う段階に調整して運用を回す（4～5段階化するケースがある）。

この枠組みをデザインレビューに持ち込むと、レビューが「感想戦」から「優先順位の合意」に変わります。例えば、漏水・結露・火災時停止・停電復帰・誤操作など、影響が大きいのに検出が遅れるものはRPNが跳ね上がりやすく、設計で“検出と隔離”を組み込むべき対象として浮かび上がります。

参考：FMEAの分類（工程FMEA、設計FMEA）、影響度・発生頻度・検出難易度、RPNの考え方
工程FMEA／設計FMEAとRPN（影響度×発生頻度×検出難易度）の具体

製品設計プロセスの独自視点の変更管理

検索上位の一般論では「要件定義→基本設計→詳細設計」と“工程の説明”が中心になりがちですが、建築の製品設計で本当に差が出るのは「変更管理」です。建築は、施主都合・法規協議・納まり・サプライチェーン都合で変更が起きる前提の産業なので、変更をゼロにするより「変更の影響を小さくし、判断を速くする」設計が重要です。
独自視点として提案したいのは、要件定義の時点で“変更の種類”を分類し、基本設計に「変更が波及する場所」をわざと見える化しておくことです。たとえば次のように、変更の入口を設計情報に埋め込みます。

• 性能変更（例：必要風量増）→ 影響箇所：機器容量、電源、騒音、ダクト寸法、支持金物。
• 納まり変更（例：梁貫通不可）→ 影響箇所：配管ルート、勾配、点検口位置、施工手順。
• 運用変更（例：夜間停止）→ 影響箇所：制御シーケンス、停電復帰、アラーム、保全手順。
• 部材変更（例：代替品採用）→ 影響箇所：耐食、ガスケット、締結トルク、検査方法。

そして、変更が入ったらFMEAの該当行を更新し、RPNが上がるところだけを“追加レビュー”にかけます。FMEAは複数名で実施すると網羅性・客観性が高まるとされているため、変更管理でも「設計・施工・品質・保全」の小チームで短時間に回す運用が向いています。変更協議のたびに全体会議を開くのではなく、RPNで“危ない変更”だけを抽出して時間を使う、という発想が建築プロジェクトには特に効きます。

最後に、設計情報の作り方としておすすめなのが「検出方法」を成果物に含めることです。工程FMEAの説明では、検出難易度は検出される確率として扱われ、目視確認は100%にならない点が明記されています。つまり、設計段階で“測れる・検知できる・ログが残る”状態を作るほど、現場での不具合の長期化を防げます。

参考：検出難易度の扱い（目視は100%にならない）、複数名での実施が有効という注意点
検出難易度と複数名実施の注意点（FMEA運用の要所）

CHAOJIBAO 1組（主音声と副音声） 基板 半田 付け はんだ 練習キット はんだ付け 練習 キット 部品 回路はんだ付けキット 電子製品 プロセスアセンブリ DIYコンポーネントの教育とトレーニング（DIYオーディオ）