ROI事件ファイル No.417『図面という名の言語』
図面という名の言語
第一章：三つのCAD、一つの船
「同じ船を、三つの異なる言語で設計しています」
TechFusion社の情報システム部長は、三枚の図面を並べて見せた。全て同じ船舶の断面図だが、それぞれ異なるCADシステムで作成されている。
「当社は造船業界で技術革新をリードしていますが、内部を見ると、CADシステムが混在しています。船体設計はCAD-A、機関設計はCAD-B、電気設計はCAD-C——それぞれが別のソフトウェアです」
情報システム部長の声には、長年この問題と向き合ってきた疲労が滲んでいた。
「さらに複雑なのは、グループ会社間での情報連携です。本社で作成した図面を、協力会社に送る。しかし、協力会社のCADシステムが異なるため、データが開けない。結局、PDFに変換して送り、協力会社が手作業で入力し直す」
彼が取り出した資料には、年間の図面変換・再入力にかかる時間が記録されていた。年間約12,000時間。一隻の船を作るのに、約500時間が図面の変換作業に消えている。
「そこで、PLM——Product Lifecycle Managementシステムの導入を検討しています。全てのCADシステムを統合し、情報を一元管理する。しかし」と彼は言葉を区切った。「何から始めればよいのか、誰が責任を持つのか、いつまでに完了すべきか——全てが曖昧なのです」
それは、複雑な問題を前に、思考が麻痺している状態だった。
第二章：六つの問い
「この案件は、まず問題を整理することから始めましょう」
Geminiがホワイトボードに、六つの単語を書いた。What、Why、Who、When、Where、How——5W1H、問題を構造化する基本の枠組みだ。
「5W1Hモデルとは」と私は説明を始めた。「複雑に絡み合った問題を、六つの視点から解きほぐす手法です」
「多くのプロジェクトが失敗するのは」とClaudeが続けた。「問題の全体像が把握できないまま、部分的な解決策に飛びつくからです」
情報システム部長が尋ねた。「しかし、私たちの問題は明確です。CADシステムが混在していることが問題なのでは」
「それは表面的な問題です」と私は答えた。「なぜ混在しているのか、それを解決することで何が得られるのか——この『なぜ』が明確でなければ、適切な解決策は見つかりません」
[What：何を実現するのか]
「まず、Whatです」とGeminiが説明した。「TechFusion社は、PLMシステムで何を実現したいのですか」
情報システム部長が答えた。「CADシステム間の情報連携を円滑にしたいです」
「それだけですか」と私は尋ねた。
「いえ」と彼が続けた。「設計変更の履歴管理も課題です。現在は、誰がいつ何を変更したのかが追跡できません。そして、部品表の自動生成も実現したい」
「つまり」とClaudeが整理した。「What——①CADシステム間のデータ連携、②設計変更履歴の管理、③部品表の自動生成。この三つが実現すべきことです」
「しかし」と私が指摘した。「優先順位はどうですか。全てを同時に実現しようとすると、プロジェクトが肥大化します」
情報システム部長が考え込んだ。「最も緊急なのは、CADシステム間のデータ連携です。これができないと、協力会社との連携が困難になります」
[Why：なぜ必要なのか]
「次に、Whyです」と私が続けた。「なぜこの問題を解決する必要があるのか。それを明確にしないと、投資判断ができません」
「図面変換に年間12,000時間かかっていると仰いましたね」とGeminiが確認した。
「ええ」と情報システム部長が頷いた。
「時給を3,000円とすると、年間3,600万円のコストです」とClaudeが計算した。「しかし、金銭的コストだけではないはずです」
「その通りです」と情報システム部長が答えた。「変換作業には時間がかかるため、設計変更が頻繁に発生すると、スケジュールが遅延します。納期遅れは、顧客との関係に影響します」
「さらに」と彼が続けた。「手作業での再入力は、ミスのリスクがあります。過去に、寸法の転記ミスで部品が合わず、作り直しになったことがあります」
「つまり」と私が整理した。「Why——①年間3,600万円のコスト削減、②納期遅延の防止、③品質リスクの低減。これらが、PLM導入の理由です」
[Who：誰が推進するのか]
「三つ目は、Whoです」とGeminiが説明した。「プロジェクトを誰が推進するのか。これが曖昧だと、プロジェクトは進みません」
情報システム部長が困った表情を見せた。「それが問題なのです。情報システム部がリードすべきか、設計部がリードすべきか、決まっていません」
「PLMシステムは、誰が最も使うのですか」と私は尋ねた。
「設計部です」と彼が答えた。
「では、設計部長がプロジェクトオーナーになるべきです」とClaudeが提案した。「情報システム部は、技術面でのサポート役」
「しかし」と情報システム部長が懸念を示した。「設計部長は、システムの専門家ではありません」
「だからこそ」と私が答えた。「両者の協力が必要なのです。設計部長が『何を実現したいか』を決め、情報システム部長が『どう実現するか』を支援する。この役割分担を明確にしてください」
「さらに」とGeminiが付け加えた。「グループ会社からも代表者を入れるべきです。彼らが実際にシステムを使う当事者ですから」
[When：いつまでに完了するのか]
「四つ目は、Whenです」と私が続けた。「期限がないプロジェクトは、永遠に終わりません」
「予算の関係で、2027年初頭までに稼働させたいです」と情報システム部長が答えた。
「それは約10ヶ月後ですね」とClaudeが確認した。「しかし、全ての機能を10ヶ月で実装するのは現実的でしょうか」
情報システム部長が首を振った。「おそらく無理です」
「では」とGeminiが提案した。「フェーズを分けましょう。第一フェーズ——最優先のCADデータ連携機能を6ヶ月で実装。第二フェーズ——設計変更履歴管理を追加で4ヶ月。第三フェーズ——部品表自動生成を次年度に実装」
「つまり」と私が強調した。「When——第一フェーズは2026年8月末、第二フェーズは2026年12月末、第三フェーズは2027年度内。この段階的なスケジュールが現実的です」
[Where：どこで導入するのか]
「五つ目は、Whereです」とClaudeが説明した。「全社一斉に導入するのか、特定の部門から始めるのか」
「PLMシステムは、本社と主要な製造拠点で導入します」と情報システム部長が答えた。「そして、グループ会社全体への展開を視野に入れています」
「しかし」と私が指摘した。「最初から全拠点に導入すると、問題が起きた時に影響範囲が大きくなります」
「では、どうすれば」
「パイロット導入です」とGeminiが提案した。「最初の3ヶ月は、本社の一つの設計チームだけで試験運用します。問題を洗い出し、改善してから、他の拠点に展開する」
「つまり」とClaudeが整理した。「Where——第一段階は本社の船体設計チーム、第二段階は本社全体、第三段階はグループ会社。この段階的な展開が、リスクを最小化します」
[How：どのように実現するのか]
「最後に、Howです」と私が説明した。「これが最も具体的な実行計画になります」
「PLMシステムの選定から始める必要があります」と情報システム部長が言った。
「その前に」とGeminiが指摘した。「現状のCADシステムの詳細な調査が必要です。どのバージョンを使っているか、どのようなデータ形式か、どのようなカスタマイズがされているか——これらを全て洗い出してください」
「そして」とClaudeが続けた。「PLMベンダーとの協議で、『どのCADシステムとの連携が可能か』を確認します。全てのCADに対応できるPLMは存在しないかもしれません」
「つまり」と私が整理した。「How——①現状調査(1ヶ月)、②要件定義(1ヶ月)、③PLM選定(1ヶ月)、④パイロット導入(3ヶ月)、⑤本格展開。この5ステップで進めます」
第三章：構造化された明晰さ
情報システム部長は、ホワイトボードに整理された5W1Hを見つめていた。
「これまで、『PLMを導入する』という漠然とした目標しかありませんでした。しかし、5W1Hで整理すると、何を、なぜ、誰が、いつまでに、どこで、どのように——全てが明確になりましたね」
「5W1Hモデルの価値は」と私は答えた。「複雑な問題を分解し、一つずつ答えられる形にすることです」
Claudeが静かに言葉を添えた。「そして、六つの問いに答えることで、プロジェクトの全体像が見えてきます。見えない敵とは戦えませんが、見える問題は解決できます」
Geminiが付け加けた。「さらに重要なのは、この整理を関係者全員で共有することです。What、Why、Whoが共有されていれば、チーム全体が同じ方向を向けます」
情報システム部長が立ち上がり、深く頭を下げた。「ありがとうございます。来週、設計部長と協力会社を集めて、キックオフミーティングを開きます」
彼が去った後、Claudeが感心したように言った。「5W1Hは、シンプルですが強力ですね」
「ああ」と私は答えた。「しかし、5W1Hの真価は、問いを立てることではなく、答えを明確にすることにある。曖昧さは、プロジェクトの敵だ。明確さこそが、確実な前進を可能にする」
窓の外では、港に停泊する船が見えた。
十ヶ月後、TechFusion社から報告が届いた。
パイロット導入の3ヶ月で、船体設計チームのCADデータ連携が成功。協力会社への図面送付時間が、従来の2時間から15分に短縮されたという。
そして、予期せぬ発見があった。PLMシステムで設計変更の履歴が可視化されたことで、「どの設計変更が頻繁に発生するか」が分かり、標準化のヒントが得られたという。
六つの問いは、確実な一歩を生み出していた。
「複雑な問題の前で、人は思考停止する。What・Why・Who・When・Where・How——六つの問いで問題を構造化することで、混沌は秩序に変わる。そして、小さなパイロットで確認することで、理論は現実となる。明確な問いと、小さな検証——それが、複雑性を突破する道である」
関連ファイル
