ROI事件ファイル No.445『六月の保守切れと五つの舞台』
六月の保守切れと五つの舞台
第一章：バラバラに動く五つの部署
「経理は会計システムを変えたい。人事は給与システムを変えたい。購買は独自のシステムを入れたい。管理会計の担当役員は、出力が遅いと毎月怒っています。そして私には、六月という締め切りがある」
Globex Corporation社のシステム部長、中村亮氏は、五本の指を立てながらそう言った。一本ずつが、それぞれ別の方向を向いている。
「スマイル会計システムの保守期限が六月末で切れます」と中村氏が続けた。「この機会に、会計・給与・人事を一体型のERPに移行したいと考えている。しかし各部署が動きを止めてくれない。経理は『うちが使いやすいシステムを選ぶ』、人事は『給与計算の複雑な設定は絶対に変えたくない』、購買は『既に別のシステムを見積もり中』と言っている」
「管理会計システムの問題は別ですか」と私は確認した。
「別です。月次の管理会計レポートが、月末締め後に出力されるまで二日かかっています。役員が翌日には見たいと言っているのに対応できていない。こちらは現行システムの設計上の問題で、ERPを変えても解決しない可能性があります」
「つまり」とClaudeが整理した。「一つの依頼の中に、五つの異なる問題と、五つの異なる利害関係者が存在している」
中村氏が深く頷いた。「このまま進めると、各部署がバラバラにシステムを導入し、かえって連携が取れなくなる未来が見えています。しかし全部署を一つのERPに統合しようとすると、誰かの要望を無視することになる」
第二章：舞台ごとの俳優と小道具
「この案件には、シーンキャスト理論が必要です」
Geminiがホワイトボードに横長の表を描いた。縦軸に「シーン」、横軸に「アクター（主役）」「オブジェクト（道具）」「アクション（動作）」と書き込む。
「シーンキャスト理論とは」と私が説明を始めた。「業務を『シーン』という単位で切り分け、そのシーンに必要なアクター（人）とオブジェクト（システム・ツール）を最適な組み合わせで割り当てるフレームワークです。一つの大きなシステムで全員を満足させようとするのではなく、シーンごとに最適な配役を決める発想です」
「五つの部署の要望が衝突しているのは」とClaudeが続けた。「全員が同じ舞台に立とうとしているからです。シーンを分けると、俳優と小道具の最適な組み合わせが見えてきます」
Geminiがホワイトボードの表を埋め始めた。
[シーン1：月次会計処理] アクター：経理部。オブジェクト：会計ERPのコアモジュール。要件は仕訳の正確性と監査対応。カスタマイズ不要のスタンダード機能で対応可能。
[シーン2：給与・人事管理] アクター：人事部。オブジェクト：給与計算エンジン（ERP内包または専用連携モジュール）。要件は複雑な給与規定の再現性。ここは人事の「絶対変えたくない」という声を尊重し、現行設定を移植できるかをベンダー選定の必須条件にする。
[シーン3：購買管理] アクター：購買部。オブジェクト：購買専用システム（ERP外付け）。要件は発注から支払いまでのフロー管理。購買が既に見積もり中のシステムが会計ERPとAPI連携できるかを確認する。
[シーン4：管理会計レポート] アクター：役員・経営企画。オブジェクト：BIツール（データ抽出・可視化）。要件は月末締め翌日の出力。これはERPの問題ではなく、データパイプラインの問題。Strategic ROI Intelligenceでデータ構造を分析し、BIツールによる自動集計を別途設計する。
[シーン5：システム間連携] アクター：IT部門。オブジェクト：APIゲートウェイ。要件は会計・給与・購買・BIが同一データを参照できること。シーンは分かれていても、データの「原本」は一つに統一する。
「五つのシーンに分けると」と私がまとめた。「全部署を一つのERPに押し込む必要はないことが分かります。コアの会計・給与をERPで統合し、購買は専用システムを外付けでAPI連携し、管理会計はBIツールで別途解決する。この三層構造が、六月の保守切れに間に合う最短経路です」
第三章：六月に向けた逆算
中村氏は表を眺めながら、少し表情が和らいだ。
「部署ごとに戦っていたのが、舞台ごとに分けたらスッキリしました。購買の独自システムも、連携仕様さえ合えば認めていいということですね」
「その通りです」と私が確認した。「シーンキャスト理論の核心は、統一することが目的ではなく、連携することが目的だという発想の転換です。同じ舞台に立つ必要はない。ただし、舞台と舞台をつなぐ通路——データの標準化とAPI設計だけは妥協してはいけない」
「六月までのスケジュールを逆算すると」とGeminiが提案した。「今すぐやるべきことは三つです。一つ目、会計・給与ERPのベンダー選定を四月中に完了。二つ目、購買システムのAPI仕様を三月中にベンダーに確認。三つ目、管理会計のBIツール設計を並行して開始。ERPの移行と管理会計の改善は、別プロジェクトとして走らせることで、互いの遅延がリスクにならない」
「人事部への説明は」とClaudeが提案した。「『給与計算の設定は変わらない』という約束を、ベンダー選定の評価基準に明記してください。評価項目に『現行給与設定の移植可能性』を加え、ベンダーに証明させる。これで人事部の不安は解消されます」
中村氏が立ち上がった。「明日、各部長にこの五つのシーンを見せます。争っていた全員が、実は別の舞台の俳優だったと気づけば、話が変わるかもしれない」
第四章：幕が上がる順番
彼が去った後、Claudeが静かに言った。「全員を一つのシステムに収めようとすることで、かえって誰も満足しない状況が生まれていたのですね」
「そうだ」と私は答えた。「統合は手段であって、目的ではない。シーンキャスト理論が教えるのは、複雑な要件を分解して、それぞれに最適な配役をすることだ。舞台が分かれていても、物語は一つにつながる」
窓の外では、春の陽光が差し込み始めていた。六月まで、あと三ヶ月。
八ヶ月後、中村氏から報告が届いた。
六月の保守切れ前にERP移行を完了。給与計算設定は百パーセント移植に成功し、人事部からの反発はなかった。購買システムはAPI連携で会計ERPと接続、月次の仕訳取り込みが自動化された。
管理会計レポートの出力遅延は、BIツールの導入により翌日出力を実現。役員からの苦情が止んだという。
中村氏はこう記していた。「シーンを分けたことで、各部長が『自分の舞台』の話として理解できました。全員が同じ部屋で同じシステムを議論していた時には見えなかったものが、舞台ごとに話すと整理できた。シーンキャスト理論は、システムの設計ではなく、人を動かす言語だと感じました」
五つの舞台が、一つの物語になった夜だった。
「複雑なシステム統合の失敗は、技術の限界ではなく、設計思想の欠如から生まれる。シーンキャスト理論が問うのは、誰が、何のために、その道具を使うか、だ。全員を一つのシステムに押し込むのではなく、シーンを分けて最適な配役をする。統合の目的はデータの一元化であり、システムの一元化ではない。この区別が、六月の締め切りを期日通りに動かし、誰も置き去りにしない移行を可能にする」
関連ファイル
使用ツール
- Strategic ROI Intelligence — データ構造の分析と管理会計パイプラインの設計支援
