はじめに：協業の失敗は姿勢ではなく、意思決定権が未定義であることに起因する
3Dプリンティング受注案件の遂行では、遅延や手戻りは誰かが協力しないことによって生じることはまれである。むしろ、同じ問題が3部門の間を二巡してから初めて決定されるケースの方が多い。設計部門は肉厚を緩和できると考え、プロセス部門は原図どおりに造形すべきだと考え、品質部門は図面に基づく判定を主張し、営業部門はすでに顧客へ納期を口頭で約束している。4者はすべて「協業」しているが、最終的な優先順位を決める権限を明確に委任された者はいない。部門横断協業の仕組みが「連絡経路の整備、定例会議の開催、連携強化」にとどまるなら、最も重要な3つの問い、すなわち誰が最終決定するのか、誰への事前相談が必須なのか、対立時にどの階層へエスカレーションするのかに答えることはできない。
一、協業をコミュニケーションの問題ではなく意思決定権の問題として捉え直す
協業の仕組みをエンジニアリング化する第一段階は、各部門横断事項を、ある部門へ一括して帰属させるのではなく、権限委譲可能な意思決定単位に分解することである。典型的な3Dプリンティング受注案件には、少なくとも6種類の部門横断的な意思決定点がある。技術的実現可能性の判定（その構造を造形できるか）、工程ルートの選定（材料と装置の組合せ）、納期の確約（外注工程を含む）、変更の受入れ（顧客による図面変更後に再計画するか）、不適合品の処置（補修、特採、廃却）、出荷承認（検査報告書を添付するか）である。これら6種類の意思決定点をすべて「会議で協議する」とするなら、本来数分で完了すべき判定が数日がかりの会議に引き延ばされる。
エンジニアリング上の方法は、各意思決定点に唯一の最終責任者（Accountable）を割り当てることである。重要なのは「唯一」であり、「共同責任」ではない。2人の共同責任は、管理台帳上では責任者不在と同じである。最終責任者は決定権を持ち、その他の関係者は、決定前に必ず情報を提供する被相談者（Consulted）と、決定後に結果を共有される被通知者（Informed）に分けられる。これがRACIマトリクスの核心である。すなわち、Responsible（実行）、Accountable（最終責任・決裁）、Consulted（相談）、Informed（通知）である。
二、RACIマトリクスの記入ルールとよくある誤り
RACIマトリクスの記入には、いくつかの厳格なルールがある。第一に、各意思決定単位のA欄には、必ず1つだけ印を付ける。Aが2つある場合は設計上の欠陥であり、意思決定単位をさらに細分化しなければならない。例えば「不適合品の処置」は、「欠陥等級の判定」（品質がA）と「処置方法の選定」（プロセスがA、品質がC）に分けられる。第二に、Rは複数名でもよいが、主担当の実行者を明示する必要があり、通常は括弧で示す。第三に、Cは多すぎるべきではない。1つの意思決定単位でCが3者を超える場合、その事項が過度に拡散していることを示しており、実際に決定へ影響する2～3者に絞るべきである。第四に、Iは不参加を意味しない。出荷承認のような節目では、営業部門がIであっても、結果発生後1時間以内に顧客側へ情報共有を完了しなければならない。
最も多い誤りは、マトリクスに役割ではなく部門名を記載することである。部門は組織単位であり、役割は責任の担い手である。同じ部門でも、意思決定点によって役割がまったく異なることがある。例えば品質部門は「欠陥等級判定」ではAだが、「工程ルート選定」ではCにすぎない。マトリクスは、プロセスエンジニア、プロジェクトオーナー、品質エンジニアなどの役割を行に、意思決定点を列に配置すべきである。
三、インターフェース一覧：部門間の成果物を検収可能な項目として記述する
意思決定権を定義した後の第二段階は、インターフェースの定義である。部門間の摩擦の多くは、「引継ぎ成果物が不完全」であることから発生する。設計からプロセスへ渡すモデルに材料指定がない、プロセスから製造へ渡す作業指示書にサポート除去方法がない、製造から品質へ渡すサンプルに造形ロット番号がない、といった例である。インターフェース一覧では、成果物名、引渡し時点、検収基準の3項目を明確にしなければならない。検収基準は判定可能である必要がある。例えば「モデルファイルに材料グレード、後処理要件、重要寸法の注記、版番号が含まれる」とすべきであり、「資料一式がそろっている」としてはならない。
インターフェース一覧では、各成果物に必須項目群を設定することを推奨する。プロセス部門が製造部門へ引き渡す作業指示書を例にすると、必須項目には少なくとも、装置番号、材料ロット番号、配置方向とサポート方案、積層厚さおよび主要パラメータ範囲、熱処理曲線、サポート除去および洗浄方法、検査の抜取率を含めるべきである。いずれか1項目でも欠けていれば、下流工程は受領を拒否でき、拒否期間は下流工程のリードタイムに算入しない。このルールにより、「口頭での申し送り」や「後追いでの資料補完」をプロセスから排除できる。
四、エスカレーションルール：対立を繰り返しの会議で解決してはならない
意思決定権が明確であっても、対立は生じる。そのため、都度上司を探すのではなく、あらかじめエスカレーションルールを設定する必要がある。エスカレーションルールには、時間トリガーと影響トリガーによる二重条件を採用することが推奨される。時間トリガーとは、ある意思決定点が合意済みの期限、例えば技術的実現可能性判定の24時間以内にクローズされない場合、自動的に上位階層へエスカレーションすることを指す。影響トリガーとは、その対立が閾値を超える納期変更、例えば納入日への影響が2日超となる場合、または閾値を超えるコスト変動、例えば単品コストの5%超となる場合に、即時エスカレーションを行い、同時にプロジェクトオーナーおよび顧客窓口担当者へ通知することを指す。
エスカレーション後の意思決定には、明確な最終期限とデフォルトアクションを設けるべきである。例えばプロジェクトオーナーへエスカレーションした後、8時間以内に書面による結論を出さなければならない。期限を過ぎても未決の場合は、「保守的な方案」、すなわち元の図面および元の工程で実施し、納期を延期することをデフォルトとして実行する。これにより、プロジェクトが待機状態で停止することを防げる。デフォルトアクションの存在自体が圧力の仕組みとなり、関係者が期限内に結論へ到達する動機となる。
五、協業の仕組みを検証可能な記録へ落とし込む
協業の仕組みが実際に機能しているかは、感覚で判断してはならず、3種類の記録を確認する必要がある。意思決定記録（各意思決定点の結論、責任者、時刻）、インターフェース引継ぎ記録（成果物、受領者、検収結果）、エスカレーション記録（トリガー条件、エスカレーション階層、最終結論）である。これら3種類の記録は、共有表計算シートの1行で済む程度に簡素でもよいが、必ず残さなければならない。また、月次で2つの指標を集計する。意思決定点の平均クローズ時間と、インターフェースの初回合格率である。前者は権限委譲が明確かを、後者はインターフェース定義が完全かを示す。
毎月、完了済みプロジェクトから5件を抽出して協業レビューを行うことを推奨する。重点は責任追及ではなく、マトリクス自体の修正に置く。どの意思決定点のAが実際には一度も行使されていないかは、権限委譲が細かすぎることを示す。どの意思決定点が頻繁にエスカレーションされるかは、権限階層が低すぎる、または判定基準が不明確であることを示す。どのインターフェースで受領拒否が繰り返されるかは、必須項目群の調整が必要であることを示す。マトリクスと一覧は事業の変化に応じて改訂し、版番号と発効日を保持しなければならない。
まとめ
部門横断協業をエンジニアリング化する道筋は、4つのステップに要約できる。協業事項を権限委譲可能な意思決定単位に分解し、各単位に唯一の最終責任者を割り当ててRACIマトリクスを作成する。インターフェース一覧を用いて部門間の成果物を検収可能な項目として記述する。時間トリガーと影響トリガーによる二重条件のエスカレーションルールで対立を処理し、デフォルトアクションで対応を担保する。最後に、意思決定、引継ぎ、エスカレーションの3種類の記録を月次で測定し、その結果をマトリクスの改訂へ反映する。このように構築された協業の仕組みは、個人の協力意欲に依存せず、明確な権限委譲、判定可能なインターフェース、自動的に発動するエスカレーション経路によって継続的に運用される。