ROI事件ファイル No.447『三十年前の設計者が残した暗号』
三十年前の設計者が残した暗号
第一章：CSVが出ないシステム
「CSVを出力しようとすると、エラーが出て止まります。三十年前から、ずっとそうです」
海外に本社を構えるGlobex Corporation社のITマネージャー、ジョン・スミス氏は、オンラインの画面越しにそう言った。落ち着いた口調だったが、その言葉の重さは伝わってきた。三十年間、誰もその問題を解決しなかったということだ。
「販売管理システムは、スクラッチ開発ですか」と私は尋ねた。
「当時の社内エンジニアがゼロから作りました。その後、業務の変化に合わせて何度もカスタマイズを重ねてきた。しかし、最初に設計した人間はとっくに退職していて、今では誰もソースコードの全体を把握していません」
「秋から新規業務が始まるとのことでしたが」とGeminiが確認した。
「ええ。新しい取引先との契約で、月次の販売データをCSV形式で提出することが条件になっています。それが今のシステムでできない。パッチを当てようとしたのですが、どこを触れば何に影響するか分からなくて、開発会社も手を出せないと言っています」
「社内の担当者の状況は」とClaudeが尋ねた。
「今年で定年を迎える方が二名います。このシステムの運用を知っているのは、実質その二名だけです。属人化が限界に来ている。秋の問題だけでなく、来年以降のリスクとしても、このシステムをどうするかを決断する時期が来ています」
問題は、CSVが出ないという一点ではなかった。三十年という時間軸の中に、複数の問題が層を成して埋まっていた。
第二章：六つの座標で問題を解剖する
「この案件には、6D-MATRIXが必要です」
Geminiがホワイトボードに六つのマスを並べた。現在・過去・未来の時間軸と、WHY・HOW・WHATの視点軸が交差する。
「6D-MATRIXとは」と私が説明を始めた。「問題を六つの次元から同時に観察するフレームワークです。多くの場合、問題は現在の症状だけを見て対処しようとする。しかし、症状の背後には過去の経緯があり、その問題を放置することで生まれる未来のリスクがある。さらに、なぜ問題が起きているか、どう解決するか、何を変えるべきかが絡み合っている。六つの座標を全て埋めることで、問題の全体像が初めて見えます」
「では、一つずつ埋めていきましょう」とClaudeが促した。
[現在 × WHAT：今、何が起きているか]
「CSV出力の機能が存在しない。または実装されているが動作しない。月次データの提出が手動での転記か提出不能な状態にある。担当者の作業負荷が高く、ミスが発生しやすい環境にある」
[過去 × WHY：なぜこうなったか]
「三十年前のスクラッチ開発時点では、CSV出力という概念がビジネス要件に存在しなかった。その後のカスタマイズはすべて、その時点での業務要件に対応したもの。設計の全体像を持つ人間が退職するたびに、ナレッジが失われ、次の担当者は現状維持しかできなくなった」
「これが三十年の構造です」と私が強調した。「誰かが悪意を持って放置したわけではない。知識が退職とともに消えていく組織では、システムは時間とともに『触れないもの』になっていく」
[未来 × HOW：このまま放置したらどうなるか]
「ROI Polygraphでリスクシナリオを分析してみます」とGeminiがツールを開いた。
入力した条件——担当者二名の定年退職、新規業務の開始、現行システムの解読不能な状態——から弾き出されたリスク評価は厳しいものだった。来年中に対応しなければ、新規取引先との契約履行が不能になる確率が高く、属人化リスクの顕在化により業務停止につながる可能性があるという試算だった。
「未来の×HOWは」とClaudeが続けた。「段階的なカスタマイズでの対応か、全面リプレイスか、の二択です。カスタマイズは短期的には安価に見えますが、誰も全体を把握していないシステムへの追加改修は、リスクの上にリスクを積み上げることになります」
[三軸の交点：WHATを変える覚悟]
「6D-MATRIXの六マスを埋めると」と私がまとめた。「解が一つに収束します。全面リプレイスです。ただし——」と私は続けた。「リプレイスにあたって最も重要な設計思想の転換は、『業務をシステムに合わせる』ことです」
「どういう意味ですか」とジョン氏が聞いた。
「三十年間、システムを業務に合わせてカスタマイズしてきた結果が今の状態です。次のシステムでは、逆の発想を徹底する。パッケージシステムの標準機能を最大限使い、業務プロセスの側を変える。カスタマイズを最小限にすることで、次の三十年間、誰でも運用できるシステムになります」
第三章：秋までの逆算
ジョン氏がメモを取りながら、静かに言った。「三十年分の問題が、六つのマスに収まったのは驚きでした。複雑に見えていたものが、整理されると単純に見えてくる」
「6D-MATRIXの効果は」とGeminiが応じた。「問題を分解することで、『今すぐ解決すべきこと』と『時間をかけて変えるべきこと』が区別できるようになることです。秋までに必要なのはCSV出力機能だけです。これは新システムへの完全移行前に、仮の連携ツールで対応できる可能性があります」
「つまり」と私が具体化した。「二段階の解決策です。第一段階——秋までに、CSV出力機能だけを暫定実装する。既存システムからデータを抽出してCSVに変換するツールを外付けで開発する。これで新規取引先との契約は履行できます。第二段階——来年中に、全面リプレイスを完了させる。担当者二名の定年前に、引き継ぎドキュメントと新システムへのデータ移行を並行して進める」
「この二段階が重要なのは」とClaudeが補足した。「秋の問題と来年の問題を分けることで、それぞれに最適なペースで対応できるからです。一つのプロジェクトにまとめると、秋の締め切りに引きずられて、長期的な設計が粗くなります」
ジョン氏が力強く頷いた。「来週、社内の担当者二名に6D-MATRIXを見せます。彼らの知識をドキュメントに落とし込む作業を、今から始めなければいけない」
第四章：三十年後の設計者へ
彼との通話が終わった後、Claudeが静かに言った。「三十年前の設計者は、悪いシステムを作ったわけではないのですね。その時代のベストを尽くした。ただ、引き継ぎの設計がなかった」
「そうだ」と私は答えた。「システムは人が去っても残る。しかし、システムを理解する知識は人と共に去る。三十年後も誰かが使い続けるシステムを作るためには、技術の設計と同じくらい、知識の引き継ぎを設計しなければならない」
窓の外では、夕暮れの空が深い青に変わり始めていた。
九ヶ月後、ジョン氏から報告が届いた。
秋の新規業務開始前に、CSV変換ツールの暫定実装が完了。取引先へのデータ提出が無事に始まった。並行して進めた全面リプレイスは、担当者二名の定年退職前にデータ移行が完了。引き継ぎドキュメントは百七十ページに及んだという。
新システムはカスタマイズゼロで稼働を開始。運用開始から三ヶ月、誰かに聞かなければ操作できないという声は出ていない。
ジョン氏はこう記していた。「6D-MATRIXで問題を六つの座標に分けたことで、担当者二名との対話が変わりました。『なぜこうなったか』を責める場ではなく、『これからどうするか』を設計する場になった。三十年の記録を引き出すには、その問いの向きが大切でした」
三十年前の設計者が残した暗号は、次の三十年への贈り物に変わった。
「三十年続くシステムの問題は、技術の劣化ではなく、知識の消滅から始まる。6D-MATRIXが提供するのは、現在・過去・未来という時間軸と、WHY・HOW・WHATという視点軸が交差する六つの座標だ。この六マスを埋めることで、症状の背後にある構造が見え、今すぐ解決すべきことと時間をかけて変えるべきことが分かれる。問題を分解することは、解決策を単純にすることだ」
関連ファイル
使用ツール
- ROI Polygraph — 属人化リスクと業務停止シナリオの定量評価
