ROI事件ファイル No.302｜『PipeWorks社の終わらない議論』

---

第一章:会議という迷宮——3年間、何も決まらない

CarelinkのPDCA事件が解決した翌週、今度は埼玉からパイプ・バルブ製造企業のシステム刷新に関する相談が届いた。第二十五巻「確実性の追求」の第302話は、終わらない議論を構造化し、前進させる物語である。

「探偵、我々は3年前から生産管理システムの刷新を検討しています。しかし、会議を重ねるたびに議論が発散し、何も決まりません。要件定義なのか、ベンダー選定なのか、予算承認なのか……。もう、何を議論しているのかすら分からなくなっています」

PipeWorks社 の生産技術部長、川口出身の田中浩二は疲弊しきった表情でベイカー街221Bを訪れた。彼の手には、3年分の議事録の束と、それとは対照的に「結論なし」と記された付箋が大量に貼られたファイルが握られていた。

「我々は埼玉で工業用パイプとバルブを製造しています。自動車、建設、プラント向けに納品しています。生産管理システムは20年前に導入したもので、もう限界です。しかし、刷新の議論が一向に進みません」

PipeWorks社のシステム刷新停滞: - 設立:1978年(パイプ・バルブ製造) - 年間売上:32億円 - 従業員数:180名 - 現行システム:2005年導入(20年経過) - 検討開始:2022年(3年前) - 会議開催:累計42回 - 決定事項:ゼロ - 予算:未確定(「1億円以上」という漠然とした認識のみ)

田中の声には深い諦めがあった。

「問題は、会議のたびに議論の焦点が変わることです。第1回は『どんな機能が必要か』。第2回は『どのベンダーに依頼するか』。第3回は『予算をどう分割するか』。そして、また第4回で『本当に必要な機能は何か』に戻る……。3年間、同じ場所をぐるぐる回っています」

直近の会議(第42回)の記録:

議題:「システム刷新の要件確認」

製造部長: 「在庫管理機能が最優先です。現在は手書きで管理していて、月次棚卸で必ず差異が出ます」

営業部長: 「いや、受注管理が先です。顧客からの問い合わせに即答できないのが問題です」

経理部長: 「予算の話をしましょう。刷新費用は1億円? 2億円? まず金額を決めないと議論できません」

情報システム課長: 「ベンダー選定が先です。要件を固めても、対応できるベンダーがいなければ意味がありません」

田中: 「つまり……何から決めればいいのでしょうか?」

結果:また結論が出ず、第43回会議へ持ち越し

「もう疲れました。3年間、毎月会議をしているのに、何一つ前に進んでいません」

---

第二章:混沌の正体——全てが同時に議論される地獄

「田中さん、これまでの会議では、どのような進め方をされてきたのでしょうか?」

私の問いに、田中は答えた。

「基本的には『自由討議』です。各部署から意見を出してもらい、全体で議論します。でも、意見が多すぎて収束しません。要件、予算、ベンダー、スケジュール……全てが同時に議論され、結局何も決まらないのです」

現在の会議方式(混沌型): - 進行:自由討議 - 議題:「システム刷新について」(漠然) - 内容:要件・予算・ベンダー・スケジュールが混在 - 問題:議論が発散し、収束しない

私は構造化の重要性を説いた。

「混沌の原因は、全てを同時に議論していることです。MECE——Mutually Exclusive, Collectively Exhaustive。漏れなく、ダブりなく。議論を明確に切り分ければ、前進します」

⬜️ ChatGPT｜構想の触媒

「全てを一度に議論するな。MECEで切り分け、順番に決めよ」

🟧 Claude｜物語の錬金術師

「会議が終わらないのは、参加者が無能だからではない。議題が構造化されていないからだ」

🟦 Gemini｜理性の羅針盤

「MECEは整理の技術。要素を分解し、重複を排除し、漏れをなくせ」

3人のメンバーが分析を開始した。Geminiがホワイトボードに「MECE分析のフレームワーク」を展開した。

MECEの原則: - Mutually Exclusive(相互排他):要素が重複しない - Collectively Exhaustive(完全網羅):要素に漏れがない - 構造化:要素を階層的に整理

「田中さん、PipeWorksのシステム刷新を、MECEで構造化しましょう」

---

第三章:切り分けの刃——3年の混沌を3つのフェーズに

Phase 1:混沌の可視化(1週間)

まず、過去42回の会議で議論された内容を全て洗い出した。

議論された項目(重複含む): 1. 必要な機能 2. 不要な機能 3. 優先順位 4. ベンダー候補 5. ベンダー評価基準 6. 予算総額 7. 支払い方法 8. スケジュール 9. 導入後のサポート 10. 既存データの移行 ... (合計58項目)

田中は愕然とした。

「こんなに多くのことを、同時に議論していたのですね……」

---

Phase 2:MECEによる構造化(3日間)

58項目を「漏れなく、ダブりなく」整理した。

第1階層:プロジェクトのフェーズで分解

システム刷新プロジェクトは、時系列で以下の3つのフェーズに分けられる:

システム刷新プロジェクト
├── フェーズ1:方針検討
├── フェーズ2:要件定義
└── フェーズ3:開発導入

第2階層:各フェーズの詳細分解

【フェーズ1:方針検討】(3ヶ月)

フェーズ1:方針検討
├── 1-1. 刷新の目的を定義
├── 1-2. 予算枠を決定
├── 1-3. ベンダー選定方針(オンプレ/クラウド/パッケージ/スクラッチ)
└── 1-4. 大まかなスケジュール策定

【フェーズ2:要件定義】(6ヶ月)

フェーズ2:要件定義
├── 2-1. 必要機能の洗い出し
├── 2-2. 優先順位の決定
├── 2-3. ベンダー選定(RFP発行・提案評価)
├── 2-4. 詳細スケジュール策定
└── 2-5. 契約締結

【フェーズ3:開発導入】(12ヶ月)

フェーズ3:開発導入
├── 3-1. 詳細設計
├── 3-2. 開発・テスト
├── 3-3. データ移行
├── 3-4. ユーザー研修
└── 3-5. 本稼働・保守移行

---

Phase 3:MECEチェック(1日)

構造化した結果をMECEの原則で検証した。

Mutually Exclusive(相互排他)チェック: - フェーズ1とフェーズ2で重複する項目はないか?
→ 「予算」はフェーズ1で枠を決め、フェーズ2で詳細化。重複なし。 - フェーズ2とフェーズ3で重複は?
→ 「要件定義」はフェーズ2で完結、フェーズ3は実装のみ。重複なし。

Collectively Exhaustive(完全網羅)チェック: - 58項目全てがいずれかのフェーズに配置されているか?
→ 配置漏れ:ゼロ

結論:MECE達成

---

Phase 4:支払い条件の構造化(1週間)

田中からもう一つの悩みが語られた。

「実は、予算承認の問題もあります。経理部長は『一括で1億円は出せない』と言います。でも、ベンダーは『分割払いは管理が面倒』と言います」

MECEで整理したフェーズ構造を、支払い条件にも適用した。

支払い条件のMECE設計:

フェーズ	期間	内容	支払い	備考
フェーズ1	3ヶ月	方針検討・ベンダー選定	800万円	契約前の準備費用
フェーズ2	6ヶ月	要件定義・詳細設計	3,200万円	設計完了時に支払い
フェーズ3	12ヶ月	開発・導入・保守移行	6,000万円	本稼働後に支払い
合計	21ヶ月	-	1億円	フェーズごとに分割

メリット: - 経理:一括支払いではなく、フェーズごとに分散 - ベンダー:各フェーズの成果物に対する対価として明確 - プロジェクト:フェーズごとに進捗を評価し、次フェーズ継続可否を判断可能

田中の目が輝いた。

「フェーズで切り分ければ、支払いも明確になるのですね」

---

第四章:構造の力——3ヶ月で3年分の決断

Phase 5:第1回新会議「フェーズ1のみを議論」(1ヶ月)

MECEで構造化した後、会議の進め方を変えた。

新会議の原則: - 議題:フェーズ1の内容のみ - 禁止事項:フェーズ2・3の内容は議論しない

第1回新会議(第43回全体会議):

議題:「フェーズ1:方針検討」

田中: 「今日はフェーズ1だけを決めます。具体的には、①刷新の目的、②予算枠、③ベンダー選定方針、④大まかなスケジュール。この4つです。詳細な要件や機能については、フェーズ2で議論します」

製造部長: 「では、刷新の目的は『在庫管理の精度向上』と『生産計画の効率化』でいいですね?」

営業部長: 「私は『受注管理』も入れてほしいですが……それはフェーズ2で優先度を決めればいいのですね?」

田中: 「その通りです。今日は『刷新する』という方針だけ決めます」

経理部長: 「予算は総額1億円、3年で回収が目標。フェーズごとに分割支払い。これで承認します」

情報システム課長: 「ベンダー選定方針は、クラウド型パッケージをベースにカスタマイズ。5社にRFPを発行します」

結果:フェーズ1の全項目が1時間で決定

---

Phase 6:フェーズ2の実行(6ヶ月)

フェーズ1で方針が決まったことで、フェーズ2がスムーズに進んだ。

要件定義: - 必要機能:28機能を洗い出し - 優先順位:MUST(必須)10機能、WANT(希望)18機能に分類 - ベンダー選定:5社から提案、2社に絞り込み、最終的に1社と契約

6ヶ月後: - 要件定義書:完成 - ベンダー:契約締結 - 支払い:フェーズ2分(3,200万円)を支払い

---

Phase 7:フェーズ3の実行(12ヶ月)

開発・導入: - 詳細設計:完了 - 開発・テスト:MUST機能10個を優先実装 - データ移行:既存システムから新システムへ - 本稼働:成功

12ヶ月後: - 新システム稼働 - 支払い:フェーズ3分(6,000万円)を支払い

---

21ヶ月後の成果:

プロジェクト実績: - 開始から完了まで:21ヶ月(計画通り) - 総投資:1億円(予算内) - フェーズごとの完了率:100%

事業成果: - 在庫精度:差異2.8% → 0.3%(89%改善) - 生産計画効率:作業時間40%削減 - 受注対応時間:平均2日 → 即日回答可能 - 年間コスト削減:1,800万円 - 投資回収期間:5.6年(計画:6年以内)

組織の変化: - 会議の効率化:「今日はフェーズXだけを議論」という原則が定着 - 他プロジェクトにもMECE適用:営業戦略会議、設備投資計画でも採用 - 田中:「議論が発散しなくなった。MECEは魔法だ」

---

第五章:探偵の診断——構造が前進を生む

その夜、MECEの本質について考察した。

PipeWorksの会議が3年間停滞した理由は、参加者の能力不足ではなかった。議題が構造化されていなかったのだ。

要件、予算、ベンダー、スケジュール……全てを同時に議論すれば、混沌しか生まれない。

しかし、MECEで切り分ければ、議論は前進する。フェーズ1、フェーズ2、フェーズ3。時系列で切り分け、各フェーズの中身を「漏れなく、ダブりなく」整理する。

そして、「今日はフェーズ1だけ」と決めれば、会議は1時間で結論を出せる。

「混沌の原因は、要素の多さではない。要素が整理されていないことだ。MECEが、混沌を秩序に変える」

次なる事件もまた、MECEが議論を前進させる瞬間を描くことになるだろう。

---

「全てを同時に議論するな。MECEで切り分け、順番に決めよ。構造が、前進を生む」——探偵の手記より

---

関連ファイル