ROI事件ファイル No.475『スパゲッティの地図を描く』
スパゲッティの地図を描く
第一章：連携図の矢印が、宙に浮いている
「システムの連携図はあります。でも、その矢印の先で何が起きているか、誰も分かりません」
Spectra Systems社の管理本部長、村田康介氏は、そう言いながらA3の紙を広げた。券売機・窓口処理機・改札機からデータが集まり、複数のサブシステムを経由して統計データと精算データになるまでのフロー図だった。矢印が十七本。そのうち四本に「詳細不明」と手書きで書かれていた。
「このシステムは、いつから動いていますか」と私は尋ねた。
「中心となる部分は十二年前から動いています」と村田氏が答えた。「そこに機能が追加され、連携が増え、担当者が変わり——今の状態になりました。何かを変えようとすると、別のところに影響が出る。影響の範囲が読めないから、触れない。触れないまま、コストだけが積み上がっています」
「現在いくつのサブシステムが動いていますか」とClaudeが確認した。
「把握している限りで九つです」と村田氏が答えた。「把握していないものが、まだあるかもしれません」
「各システムの運用コストは出ていますか」とGeminiが確認した。
「断片的には出ています」と村田氏が続けた。「でも全体を合計したことがない。請求がバラバラの会社から来るので、一枚の紙で見たことがない」
「それが最初の問題です」と私が言った。「どこから手をつけるかが分からない理由は、全体のコストが見えていないからです」
村田氏が静かに頷いた。「二年前に統合の検討を始めましたが、どこから着手するかで議論が止まっています」
第二章：PPMが問う二つの軸
「この案件には、PPMが必要です」
Claudeがホワイトボードに二つの軸を描いた。縦軸に「市場成長率」、横軸に「相対的市場シェア」——しかしすぐに言い換えた。「システム統合に転用する場合は、縦軸を『業務への影響度』、横軸を『統合の難易度の低さ』に置き換えます」
「PPMとはプロダクト・ポートフォリオ・マネジメントの略で、本来は事業ポートフォリオを四象限で評価するフレームワークです」と私が説明した。「しかし、複数のシステムをどの順序で統合するかという問いにも同じ論理が使えます。影響度が高く、統合しやすいものから手をつける。影響度が低く、統合が難しいものは後回し——この優先順位を数字で決めるのがPPMの役割です」
「まず全体のコストを測りましょう」とGeminiがROI Polygraphを開いた。村田氏から収集した各システムの請求書と、担当者へのヒアリング結果を入力する。
「九システムの月間コストの合計が出ました」とGeminiが読み上げた。「ライセンス・保守費用の合計が月二百三十万円。属人化による担当者の工数コストが月八十万円。システム間の手動連携作業が月四十五万円。合計で月三百五十五万円。年間換算で四千二百六十万円です」
村田氏が数字を見て黙った。しばらくして言った。「全部足したことが、なかった」
「では、PPMで優先順位を設計します」と私が続けた。
[第一象限——影響度が高く、統合しやすいシステム]
「九つのシステムを、二つの軸でスコアリングします」とClaudeが言った。「業務への影響度は、そのシステムが止まったときに何人の業務が止まるかで測ります。統合の難易度は、データ形式の標準化度合いと、依存関係の複雑さで評価します」
「一週間かけて、村田さんに九システムのスコアをつけてもらいます」と私が続けた。「各担当者から聞き取って、五点満点で両軸を評価する。主観が入ることは構いません。最初は方向性を決めることが目的です」
一週間後、村田氏がスコアを持ってきた。九システムを四象限に配置すると、第一象限——影響度が高く統合しやすい——に二システムが入った。窓口処理データの集約システムと、精算データの出力システムだった。
「この二つから始めます」とClaudeが言った。「統合しやすい理由は、データ形式がCSVで標準化されており、依存しているシステムが少ないからです。影響度が高い理由は、両システムが止まると月次の精算処理全体が止まるためです。つまり、成功すれば最も大きな安心を得られる」
[第二象限——影響度が高く、統合が難しいシステム]
「第二象限には、券売機データ処理システムが入りました」と村田氏が確認した。「影響度は最も高い。でも、連携している機器メーカーが三社あって、データ形式がバラバラです」
「これは後回しです」とGeminiが言った。「難易度が高いシステムを最初に動かすと、失敗したときのダメージが大きい。第一象限の成功体験を積んでから、技術的な準備と並行して進めます」
[第三・第四象限——影響度が低いシステム]
「残りの六システムは、影響度が相対的に低い」とClaudeが整理した。「そのうち統合しやすいものは第三の優先、難しいものは最後です。廃止を検討すべきシステムも一つありました——月次で十五万円かかっているが、担当者が『使ったことがない』と答えたシステムです」
「廃止できるんですか」と村田氏が目を細めた。
「止めて一ヶ月、何か問題が出るか確認します」と私が答えた。「問題が出なければ、廃止です。月十五万円が止まります」
「ROI Proposal Generatorで統合計画の投資回収を試算しましょう」とGeminiが提案した。
第一象限の二システム統合から始めた場合の試算が出た。
- 初期費用：二システム統合の設計・移行費用合計百二十万円
- 月次削減効果：手動連携作業の削減＝月三十万円、保守費用の統合による削減＝月二十五万円、廃止システムの停止＝月十五万円、合計月七十万円
- 投資回収期間：百二十万円÷七十万円＝約一・七ヶ月
「二ヶ月以内での回収です」とGeminiが整理した。「全九システムの統合完了は二年計画ですが、最初の二システムだけで月七十万円の削減が始まります。その削減分が、次の統合費用に充てられます」
第三章：どこから手をつけるか、が決まった
「進め方を整理します」と私がホワイトボードの前に立った。
「第一フェーズ——廃止候補システムの停止確認と、第一象限二システムの統合設計。一ヶ月。第二フェーズ——二システムの統合実装と移行テスト。二ヶ月。第三フェーズ——第三象限システムの順次統合。六ヶ月。第四フェーズ——第二象限の券売機システム統合。データ形式の標準化交渉を並行して進めながら、九ヶ月かけて実施」
「二年で、全部終わりますか」と村田氏が確認した。
「終わらないかもしれません」と私が正直に答えた。「第二象限のシステムは、メーカー側の対応が必要です。交渉次第では延びます。ただ——二年待たなくても、最初の一ヶ月で月七十万円の削減が始まります。動き続けることが、このプロジェクトの正解です」
村田氏が連携図を折りながら言った。「どこから手をつければいいか分からないから、動けなかった。今日、一番小さな一歩が決まりました」
第四章：矢印に名前がついた日
十ヶ月後、村田氏から報告が届いた。
廃止候補だったシステムは、停止から三週間で「やはり必要だった」という声が一件上がった。確認したところ、月に一回だけ使われていたことが判明した。その機能だけを残して、システム本体は廃止した。月十一万円の削減になったと村田氏は記していた。
第一象限の二システム統合は予定通り二ヶ月で完了。手動連携作業が月三十時間から四時間に削減された。「詳細不明」と書かれていた矢印のうち三本に、担当者の名前とデータ形式が記入された。
連携図の「詳細不明」は四本から一本になった。
村田氏の報告書には最後にこう記されていた。「統合を始めると、触れるたびに知らなかったことが出てきます。それを怖いと思っていましたが、知らなかったことが分かることが、地図を描くことだと今は思っています」
スパゲッティに、少しずつ名前がついた。
「複雑なシステムを前にして、どこから手をつければいいか分からないとき、問題は技術ではなく優先順位だ。PPMが問う二つの軸——影響度と統合のしやすさ——は、九つのシステムを四象限に並べ替える。並べ替えると、最初の一手が見える。一手が決まると、動ける。動くと、地図が描かれる。連携図の矢印に名前がついた日、スパゲッティは少しだけパスタになった」
関連ファイル
使用ツール
- ROI Polygraph — 九システムの月間コスト総合可視化
- ROI Proposal Generator — 段階的システム統合の投資回収シミュレーション
