エグゼクティブ・サマリー
- コンソーシアム型導入とは、一社では担えない範囲を、複数の主体が役割を分けて一つのプロジェクトとして進める方式である。仲良く集まることが目的ではなく、単独では成立しない案件を成立させるための構造である。
- 向くのは、①投資が単独では回収できない ②必要な技術が一社に揃わない ③現場が複数事業者にまたがるのいずれかに当てはまる案件だ。逆に、一社で完結できる案件をコンソーシアムにすると、意思決定が遅くなるだけで何の得もない。
- 成否を分ける最大の要素は技術ではなく、意思決定構造である。「全員で決める」と決めた瞬間に、そのプロジェクトは何も決められなくなる。運営会議・実務会議・作業部会の三層に分け、各層の決定権限を文書で固定する。
- 費用分担は「頭割り」を避ける。受益に比例させるか、拠出の形（現金／現物／工数）を分けるかのどちらかにしないと、後から必ず不公平感が噴き出す。
- 事務局は参加者の一社が兼務しない方がよい。その一社の利害が調整に混じるからである。中立の第三者が事務局を持つと、揉め事の九割は起きる前に消える。
なぜ一社で進められない案件があるのか
ロボット導入の相談を受けていると、一定の割合で「この案件は、この会社一社では絶対に終わらない」と分かるものがある。たとえば、地域の複数の中小製造業が同じ工程で同じ人手不足に困っているが、一社あたりの生産量では自動化装置の投資が回収できない、という場合。あるいは、倉庫の自動化を進めたいが、荷主・物流事業者・倉庫オーナーが別会社で、誰が投資して誰が便益を得るのかが噛み合わない、という場合。
こうした案件で「まず自社でできることから」と一社に閉じてしまうと、たいていは小さなPoCで止まる。動かない技術のせいではなく、投資判断が成立する規模に届かないからだ。詳しくはロボット導入の失敗パターンと回避でも触れたが、止まる理由の多くは技術の外側にある。
コンソーシアム型は、この構造的な行き詰まりに対する回答である。ただし、複数主体を集めた瞬間に、一社では起きなかった別種の難しさが発生する。本稿は、その難しさをプロジェクトマネジメントの技術として扱う。
1. コンソーシアム型が向く案件、向かない案件
まず判定である。以下の三条件のうち、少なくとも一つに明確に当てはまることが前提になる。
| 条件 | 具体的な症状 | コンソーシアムで解ける理由 |
|---|---|---|
| 投資が単独で回収できない | 一社あたりの処理量が装置の稼働率に届かない。回収年数が10年を超える | 複数社で装置・拠点・稼働時間を共有し、稼働率を上げて回収年数を圧縮する |
| 技術が一社に揃わない | ハンドは作れるが視覚認識がない。装置はあるが現場運用の設計ができない | 要素技術を持つ主体をそれぞれ呼び、統合の責任だけを一箇所に置く |
| 現場が複数事業者にまたがる | 投資する主体と便益を得る主体が違う。作業者の雇用主が複数社 | 便益の配分と費用の分担を、同じテーブルで同時に決める |
逆に、次の場合はコンソーシアムにしない方がよい。一社の一拠点で完結し、その一社に投資判断の権限と予算がある案件である。この場合、外部を呼ぶ理由は技術の調達だけであり、それは通常の発注で足りる。「せっかくだから他社も誘おう」という善意が、意思決定を三倍遅くする例を何度も見てきた。
判定にもう一つ加えるなら、「このコンソーシアムが解散したあと、誰が運用を続けるのか」に答えられるかである。答えられない場合、実証で終わる可能性が高い。運用主体の不在は、定着化・運用設計で扱った問題と同じ根を持つ。
2. 組成——誰を、どの順番で呼ぶか
組成でよくある失敗は、集めやすい主体から先に集めることだ。順番には意味がある。
第一に、現場を持つユーザー企業を確定する。 コンソーシアムの中心は、実際にロボットが動く現場である。現場が決まらないうちにメーカーやSIerを呼ぶと、議論が一般論から降りてこない。最低一社、できれば二社以上の現場を、具体的な工程レベルで押さえる。
第二に、運用を担う主体を決める。 導入後に誰が日々の立ち上げ・停止・軽微なトラブル対応をするのか。ユーザー企業の現場が担うのか、専任の運用事業者を入れるのか。ここを組成段階で決めておかないと、装置が入った翌月に「誰の仕事なのか」で止まる。
第三に、技術を持つ主体（メーカー・SIer）を呼ぶ。 この段階なら、現場と運用条件が具体化しているので、技術側も現実的な提案ができる。選び方はロボット選定の勘所とSIerの選び方に譲る。
第四に、必要に応じて自治体・大学・金融機関を加える。 自治体は用地・規制対応・地域内の横展開で効き、大学は評価手法と人材育成で効く。ただし、この二者を「箔付け」で呼ぶと、会議の出席者が増えるだけで実務は一ミリも進まない。参加者には必ず、その主体でなければ埋まらない役割を割り当てる。
役割の定義は、次の粒度まで落とす。
| 主体 | 提供するもの | 受け取るもの | 意思決定への関与 |
|---|---|---|---|
| ユーザー企業 | 現場・作業データ・立会工数 | 自動化された工程・運用ノウハウ | 運営会議で議決権を持つ |
| メーカー | 装置・技術情報・保守 | 実証データ・導入実績・改良点 | 実務会議で提案、運営会議は報告 |
| SIer | 統合設計・据付・立上げ | 統合ノウハウ・継続受注機会 | 実務会議で提案、運営会議は報告 |
| 運用事業者 | 日常運用・稼働管理 | 運用受託の事業機会 | 実務会議で議決権を持つ |
| 自治体 | 規制対応・用地・広報・資金制度の案内 | 地域課題の解決・横展開の素地 | 運営会議でオブザーバーまたは議決権 |
| 大学 | 評価設計・計測・人材育成 | 研究データ・実証フィールド | 作業部会を主導 |
| 事務局 | 進行・記録・調整・成果物管理 | 運営フィー | 議決権を持たない |
事務局が議決権を持たないことが重要である。進行役と当事者を兼ねると、調整が交渉に変質する。
3. 意思決定構造——三層に分ける
複数主体プロジェクトが止まる最大の理由は、決定権限が曖昧なことだ。「関係者の合意を得て進める」という表現は、実務上は「誰も決めない」と同義である。次の三層に分けて、各層で決められることを文書に固定する。
運営会議（月1回・各社の意思決定者）——投資、スコープ、スケジュールの大枠、費用分担、成果物の帰属を決める。ここに出てくる人は、自社に持ち帰らずにその場で是非を言える立場でなければならない。「持ち帰って検討します」が続く会議は、層の設計が失敗している。
実務会議（隔週・各社の実務責任者）——要件、仕様、現場調整、課題の解消を決める。運営会議に上げるのは、費用が動く事項とスケジュールが動く事項だけに限る。この線引きを明文化しておかないと、あらゆる論点が運営会議に集まり、月一回しか物事が進まなくなる。
作業部会（随時・実作業者）——計測、設計、試験、記録を実行する。決定はしないが、実務会議に上げる材料をつくる。
各層で必ず決めておく事項は次の通りである。
- 定足数と議決方法（全会一致か、多数決か、中心となるユーザー企業の同意を必須とするか）
- 決められなかったときのエスカレーション先と、その期限
- 議事録の確定手順（誰が書き、いつまでに異議がなければ確定とするか）
三つ目は軽視されがちだが、コンソーシアムでは議事録が唯一の共有記憶である。「言った・言わない」が起きた時点で、そのプロジェクトの信頼残高は目に見えて減る。議事録は会議の翌営業日までに配布し、三営業日以内に異議がなければ確定、という運用が現実的だ。
4. 費用と成果物の分担——先に決める、必ず文書にする
費用分担の設計は、組成の初期に済ませる。装置が動き始めてから議論すると、必ず揉める。主要な4モデルは次の通りである。
| モデル | 決め方 | 向く場面 | 注意点 |
|---|---|---|---|
| 均等分担 | 参加社数で頭割り | 参加者の規模・受益がほぼ同じ | 規模差があると小規模企業が離脱する |
| 受益比例 | 処理量・削減工数などの指標で按分 | 受益が数値で測れる | 指標の定義で揉めるので先に合意する |
| 現物・工数拠出 | 現金の代わりに装置・場所・人を出す | 資金は乏しいが資産や人がある主体 | 拠出の金銭換算ルールを事前に決める |
| 段階拠出 | 構想は薄く、実装で厚く | 参加のハードルを下げたい初期 | 段階の切り替え条件を明記する |
実務上は、構想・PoC段階は均等または少額の段階拠出、実装段階は受益比例という組み合わせが機能しやすい。入口を軽くして参加者を集め、投資判断の段階で本気の主体だけが残る構造になる。
成果物の帰属も同時に決める。最低限、次の三つを分けて扱う。
- プロジェクトで新たに生まれた設計・データ——共有とするか、拠出比率で分けるか
- 各社が持ち込んだ既存の技術・ノウハウ——持ち込んだ主体に帰属し、プロジェクト内の利用範囲だけを定める
- 実証で得られた稼働データ——誰が保有し、誰が二次利用できるか
三つ目は、後になって最も価値が出る資産である。稼働データの扱いを空欄にしたまま進めると、成果が出たあとで交渉が始まる。データの保有・利用範囲についてはロボット稼働データの収集・可視化基盤の観点も併せて設計するとよい。
5. スケジュール——導入7工程にマイルストーンを置く
コンソーシアムであっても、通るべき工程は単独導入と変わらない。①RXビジョン／構想策定 ②要件定義・PoC・選定・組成 ③構築スケジュール／ToBe業務設計 ④システム設計 ⑤開発・導入 ⑥定着化 ⑦運用、の7工程である。違うのは、各工程の終わりに「参加者全員の合意を取る関門」を明示的に置く点だ。
| 工程 | 関門で確認すること | 合意の形 |
|---|---|---|
| ①構想策定 | 対象範囲・目標値・期限が全社で同じか | 構想書への各社押印または議事録での明示合意 |
| ②要件定義・PoC | PoCの合格基準に全社が納得しているか | 評価基準書の確定 |
| ③ToBe業務設計 | 誰の作業がどう変わるかを、現場が理解しているか | 業務フロー図の現場レビュー完了 |
| ④システム設計 | 各社の担当範囲と接続点が確定したか | 分担表・インタフェース仕様の確定 |
| ⑤開発・導入 | 検収基準と立会者が決まっているか | 検収要領書の確定 |
| ⑥定着化 | 運用主体と教育計画が決まっているか | 運用体制図の確定 |
| ⑦運用 | 費用負担と改善サイクルの継続方法 | 運用フェーズの契約または覚書 |
②のPoCで特に注意したいのは、合格基準を主体ごとに別々に持たないことだ。メーカーは「装置が仕様通り動いたか」、ユーザー企業は「現場が楽になったか」を見ている。この二つを並べたまま実証に入ると、終わったあとで評価が割れる。基準は一本化する。設計の詳細はPoC（実証実験）の設計と評価を参照されたい。
6. 三大崩壊パターンと処方
（a）決まらない。 症状は、同じ論点が三回以上会議に出てくること。原因はほぼ、決定権限のない人が会議に出ていることである。処方は、運営会議のメンバーを差し替えるか、決定期限を切って「期限までに異議がなければ事務局案で確定」という運用に変えること。後者は強引に見えるが、実務では有効に働く。
（b）抜ける。 症状は、特定の主体の出席率が下がり、宿題が返ってこないこと。原因は、その主体にとっての受益が見えなくなったことである。処方は、離脱を責めるのではなく、役割と受益をその場で再定義すること。役割が消えたなら、円満に外れてもらう方がプロジェクトのためになる。参加者は多いほど良いという発想を捨てる。
（c）揉める。 症状は、費用・データ・成果物の帰属をめぐる議論が長引くこと。原因はほぼ例外なく、初期に文書化しなかったことである。処方は事後にはない。だからこそ、第4節の内容を組成の初期に片付ける。
三つに共通する予防策は、事務局が中立であることだ。参加企業の一社が事務局を兼ねると、その社の利害が調整に混じり、他の参加者が発言を控えるようになる。会議は静かになるが、それは合意ではなく沈黙である。
7. 事務局の実務——実際に何をするのか
事務局の仕事は、会議室を予約することではない。実務は次の五つである。
- 論点の整理と先出し——会議の三営業日前に、決めるべき論点と選択肢、事務局案を配る。会議は議論ではなく決定の場にする
- 議事録と決定台帳の管理——「いつ、何を、誰の合意で決めたか」を一覧で保持する。半年後に必ず参照される
- 課題管理——課題ごとに担当・期限・状態を持ち、毎回の会議で更新する。担当が空欄の課題は存在しないものと同じである
- 主体間の個別調整——会議の場で言いにくいことは、事前に個別で聞く。会議で初めて対立が表面化する状況は、事務局の準備不足である
- 成果物の集約と品質管理——各社が出す設計書・報告書の粒度を揃える
この五つを、参加企業のいずれとも利害を持たない立場で回せるかどうかが、コンソーシアム型の実質的な成否を決める。
まとめ
コンソーシアム型導入は、一社では成立しない案件を成立させるための構造である。その代わり、意思決定・費用分担・成果物帰属という、単独導入では発生しない三つの設計課題を背負う。
要点を繰り返す。向く案件かを先に判定する。現場と運用主体から順に組成する。三層で決定権限を固定する。費用と成果物の帰属は組成初期に文書化する。事務局は中立に置く。 この五つを守れば、複数主体プロジェクトの難しさの大半は、事前設計で吸収できる。
RobiZyは、ロボットを売らないNPO法人である。特定のメーカーやSIerの製品を推す立場にないため、コンソーシアムの事務局として、参加者のいずれとも利害を持たずに調整に入ることができる。ユーザー企業・メーカー・SIer・運用事業者・自治体・大学の間に立ち、組成から運用移行までを中立のコーディネーターとして伴走する。
「複数社で何かできないか」という構想段階の、まだ座組も決まっていない状態からのご相談を歓迎する。むしろ、座組が固まる前の方が、設計できる余地は大きい。