ROI事件ファイル No.500『一人しか読めない設計書』
一人しか読めない設計書
第一章：三十年前のコードを、一人で守る
「三十年動いているCAD/CAMシステムを、メンテナンスできるのが社内に一人しかいません」
TechFusion社のCTO、芦沢誠也氏は、そう言いながら社内システム構成図を開いた。中央に大きく描かれているのは、自社開発のCAD/CAMシステム。プレス加工に特化した独自仕様で、国内外の全拠点で約百名が使用している。「設計データが加工工程まで自動連携する仕組みで、業務効率は抜群です。ただ、その仕組みを理解しているのは、一人だけ」
「設計書はないのですか」と私が確認した。
「ありません」と芦沢氏が答えた。「三十年前の開発当時、設計書を作る慣行がなかった。残っているのは操作マニュアルだけです。コードのコメントも限定的。担当者が頭の中で全体構造を覚えている」
「その担当者の年齢は」とClaudeが尋ねた。
「五十代後半です」と芦沢氏が答えた。「健康面の不安もあります。本人が体調を崩したら、システムがブラックボックスになる。実は去年、二週間入院しました。その間、軽微なトラブルにも誰も対応できなかった」
「フルスクラッチで作り直す案は」とGeminiが尋ねた。
「コストが膨大です」と芦沢氏が答えた。「百名が業務で使っているシステムを、ゼロから作り直すと数年かかる。その間の業務影響も大きい。現実的な選択肢ではない」
「現行システムを残しながら、設計書を作り出す方向ですね」と私が応じた。「PDCAが向いています」
第二章：PDCAが問う、四回転で資産を作る
「この案件には、PDCAが必要です」
Claudeがホワイトボードに四つの文字を書いた。P・D・C・A。
「PDCAとは、Plan（計画）・Do（実行）・Check（確認）・Act（改善）の四段階を回すフレームワークです」と私が説明した。「定番すぎて新鮮味がないと言われがちですが、リバースエンジニアリングのように『正解が事前に分からない作業』には適しています。一回の作業で完璧な設計書は作れない。AIで生成し、人が確認し、修正し、また生成する——この四回転を繰り返すことで、精度が上がります」
「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。芦沢氏から提供されたデータを入力する。
「月間の属人化コストが出ました」とGeminiが読み上げた。「メンテナンス担当者一名の月次稼働が約百八十時間、給与換算で月百二万円。バックアップ要員不在のリスク期待値を月百五十万円——担当者離脱時のシステム停止損失の期待値。担当者多忙による改修要望の滞留が月平均二十件、機会損失を月四十万円。新人育成不能による次世代人材育成コスト未投資が月二十万円。合計で月三百十二万円。年間換算で約三千七百四十万円」
芦沢氏が数字を見つめた。「リスク期待値の数字に、実感があります」
「では、PDCAで設計します」と私が続けた。
[P——Plan：何を、どこまで、どう作るかを決める]
「最初に、設計書のスコープを決めます」とClaudeが言った。「全コードの完全な設計書を一度に作ろうとすると、数年かかります。優先順位を設定します。第一に、システムの全体構造図。第二に、主要モジュール十個の詳細設計書。第三に、データフロー図。第四に、外部連携仕様書。この順で着手し、段階的に拡張します」
「どのモジュールが優先か、どう決めますか」と芦沢氏が尋ねた。
「過去三年の改修頻度で判断します」と私が答えた。「頻繁に改修される箇所ほど、属人化リスクが高い。改修ログを参照し、上位十モジュールから着手する。使われていない部分の設計書は、後回しでいい」
[D——Do：AIでリバースエンジニアリングを実行する]
「実行段階で、AIツールを使ってコードから設計書を自動生成します」とGeminiが続けた。「生成AIは、コードを読み取り、関数の役割、データの流れ、依存関係を文書化できる。一人で読み解いていた構造を、AIが下書きとして起こす」
「精度は」と芦沢氏が確認した。
「八割程度です」とClaudeが応じた。「完全自動ではありません。残りの二割は、独自仕様や歴史的経緯による部分で、AIには判断できない。ここは現行担当者が補完する。ただし、一からの執筆ではなく『AIの下書きへの追記』なので、担当者の負荷は大幅に下がります」
[C——Check：担当者と若手が協力して検証する]
「確認段階が、最も重要です」と私が続けた。「AIが生成した設計書を、現行担当者と次世代担当者候補の若手二名が一緒に検証する。担当者が『この記述は違う』と言った箇所は、なぜ違うかを若手がインタビューする。検証のプロセス自体が、暗黙知の形式化になります」
「単なる文書化ではないんですね」と芦沢氏が確認した。
「文書化は手段です」と私が応じた。「目的は、担当者の頭の中にある判断基準を組織で共有することです。検証セッションを、知識継承の場として設計します。ここをスキップすると、文書はできても次世代が育たない」
[A——Act：継続的な更新サイクルを組み込む]
「改善段階で、継続更新の仕組みを作ります」とClaudeが続けた。「設計書を作って終わりではなく、システムが変わるたびに設計書も更新する。改修時のチェックリストに『設計書の更新』を組み込み、コードと設計書が常に同期する状態を保つ。現行のシステムは、生きている資産です」
[投資回収を試算する]
「ROI Proposal Generatorで試算しましょう」とGeminiが提案した。
- 初期費用：AIリバースエンジニアリングツール契約・設計書執筆プロジェクト・若手育成プログラム・継続更新基盤構築費用合計六百二十万円
- 月次費用：AIツール継続利用・設計書管理基盤合算月十四万円
- 月次削減効果：リスク期待値の低減＝月百五万円（バックアップ要員確保で七割低減）、改修要望滞留の解消＝月二十八万円、若手育成の進展＝月十五万円、現行担当者の負荷分散＝月二十二万円、合計月百七十万円
- 月次純削減：百七十万円－十四万円＝月百五十六万円
- 投資回収期間：六百二十万円÷百五十六万円＝約四ヶ月
「四ヶ月の回収です」とGeminiが整理した。「ただし、本質的な価値はリスク低減です。担当者離脱時に予想される業務停止損失の期待値が下がる効果は、数字以上に大きい。三十年動いてきたシステムが、次の三十年も動く準備ができます」
芦沢氏が数字を確認しながら言った。「設計書を作る作業を、コストとしか見ていませんでした。リスク低減の投資として見ると、優先度が変わる」
「資産を、組織のものにする投資です」と私が応じた。
第三章：暗黙知を、形式知に変える
「進め方を整理します」と私がホワイトボードの前に立った。
「第一ヶ月——スコープ確定、優先モジュール十個の選定、AIツール選定。第二・三ヶ月——AIによる初期設計書生成、全体構造図とデータフロー図の作成。第四・五ヶ月——担当者と若手二名の検証セッション、優先モジュールの詳細化。第六・七ヶ月——外部連携仕様書、未着手モジュールへの拡張。第八ヶ月——継続更新ルールの社内ルール化、改修プロセスへの組み込み」
「若手二名は誰を選びますか」と芦沢氏が確認した。
「コードを読める意欲のある人を二名」とClaudeが答えた。「全員に教えるのではなく、まず二名を育てる。二名が育てば、その後は彼らが他の社員に伝える。ピラミッド型の知識継承が、現実的です」
芦沢氏がメモを取りながら言った。「一気に全員に展開するより、段階的に広げる方が定着しそうですね」
第四章：誰でも読める設計書が、生まれた日
十ヶ月後、芦沢氏から報告が届いた。
優先モジュール十個の設計書は、第七ヶ月に完成。AIによる初期生成と、担当者・若手による検証サイクルを四回転させた結果、精度は最終的に九十五パーセントに達した。「完全な設計書ではないが、システムを理解し、改修できる水準には達した」と芦沢氏は記していた。
最も大きな変化は、若手二名の成長に表れた。検証セッションを通じて、現行担当者の判断基準を直接学ぶ機会が継続的に発生。十ヶ月後には、二名のうち一名が、軽微な改修を独立して担当できるようになった。「教科書を読むだけでは身につかない判断基準が、文書化のプロセスを通じて伝わった」と報告書にあった。
リスク期待値の構造的な低減も実現した。現行担当者が休暇を取った際、二週間の不在期間を若手二名でカバー。発生したトラブル四件のうち、三件を若手が対応、一件のみ担当者へエスカレーション。「以前なら担当者がいないと止まっていた」と芦沢氏は記していた。
設計書の継続更新も組み込まれた。改修プロセスのチェックリストに「設計書更新」が必須項目として組み込まれ、コードと設計書のずれが構造的に発生しない仕組みになった。「設計書が古くなる、という問題がなくなった」と報告書にあった。
副次的な効果として、ベテラン担当者本人の働き方が変わった。属人化が解消されることで、休暇取得が現実的になり、夜間や休日の問い合わせが減少した。「自分が倒れたらどうなる、という不安から解放された」と本人のコメントが添付されていた。
業界での評価も上がった。同業他社からTechFusion社のリバースエンジニアリングプロジェクトについて問い合わせが入り、業界誌で事例として紹介された。「三十年前のシステムをAIで蘇らせた事例」として、製造業のレガシーシステム維持の参考事例になった。
芦沢氏の報告書の最後にはこう書かれていた。「三十年の独自仕様が、組織の財産に変わった。一人しか読めなかった設計書が、誰でも読める設計書になった日が、本当の意味でこのシステムが資産化した日だった」
属人化していた知識が、組織の知に変わった日だった。
「PDCAは、新規開発のためだけのフレームワークではない。三十年動いてきたシステムを、組織の知に変える作業にも有効だ。AIが下書きを起こし、人が検証し、また生成する——四回転を繰り返すことで、暗黙知が形式知に変わる。一人しか読めなかった設計書が、誰でも読める状態に変わるとき、システムは個人のものから組織のものへと姿を変える。三十年動いてきたコードは、三十年分の判断の集積だった。それを文書にする作業は、過去への敬意であり、未来への準備でもある」
関連ファイル
使用ツール
- ROI Polygraph — 属人化リスク・改修滞留・育成停滞コストの可視化
- ROI Proposal Generator — リバースエンジニアリングプロジェクトの投資回収シミュレーション
