「何が動いているか」を説明できないIT資産の危うさ
先日、二つのニュースがほぼ同時に報じられました。一つは、ソースコードを解析し、対話形式でシステムの仕様や構造を「説明」してくれるAIエージェント「Mill」の実機デモ。もう一つは、障害者施設における行政文書のデジタル化推進事業に関する環境省のヒアリングです。
一見すると、先端テクノロジーと社会的インフラという、全く次元の異なる話題のように思えます。しかし、この二つを「経営×IT」のレンズで見ると、共通する一つの核心的な課題が浮かび上がります。それは、「経営層に対して、現存するITが『何をしているのか』を説明する責任（説明責任）が、これまで果たされてこなかった」という問題です。
「Mill」のようなツールが求められる背景には、長年ブラックボックス化した既存システム（レガシーシステム）の存在があります。一方、障害者施設のデジタル化が進まない背景には、紙文化や予算制約だけでなく、デジタル化の「目的」と「効果」を関係者に明確に説明・合意するプロセスの難しさがあります。どちらも「説明」の欠如が根本にあるのです。
「Mill」が示す、IT説明責任の技術的解決可能性
「Mill」のデモが示したのは、AIを活用して、ソースコードという「How（どう動くか）」の記述から、ビジネスロジックや仕様という「What（何をしているか）」「Why（なぜそうなっているか）」を抽出し、平易な言葉で説明する可能性です。
これは技術的に画期的ですが、経営視点で重要なのはその「用途」です。従来、既存システムの全容把握は、当時の開発者に依存する属人的な作業であり、多大な時間とコストがかかっていました。その結果、「把握するコストが高すぎるから、わからないまま運用する」という不合理な経営判断が常態化してきたのです。
「Mill」のようなツールは、このコストを劇的に下げ、「IT資産の可視化と説明」を日常的な経営管理の一環にできる可能性を開きます。つまり、技術的負債の棚卸しが、年に一度の大プロジェクトではなく、必要に応じて実行可能な日常業務になるのです。
説明責任が果たせない三つの構造的要因
では、なぜこれまでITの説明責任は果たされなかったのでしょうか。三つの構造的要因があります。
1. 言語の断絶
技術者と経営者では、使用する言語が根本的に異なります。技術者は「API」「データベーススキーマ」「マイグレーション」といった用語で説明しますが、経営者が知りたいのは「その機能がどの顧客プロセスを支えているのか」「変更するとどの収益ラインに影響するのか」です。この翻訳作業が組織的に制度化されていません。
2. 評価基準の不一致
情シス部門の評価が「システムの安定稼働（障害ゼロ）」に偏重しているため、既存システムに手を加えてまで「可視化・説明」を行うインセンティブが働きません。むしろ、触らないことが安全策とされる風土さえ生まれます。
3. 「説明」そのものの価値が見積もられていない
経営側も、「システムが何をしているか説明してもらう」ことへの対価（時間とお金）を正当な投資として認識してきませんでした。結果、説明は「無料で当然」のサービスとみなされ、品質と深度は後回しにされてきたのです。
障害者施設のデジタル化が直面する「説明」の壁
もう一つのニュース、障害者施設のデジタル化事業は、この「説明責任」問題を別の角度から照射します。ここでの課題は、デジタル化の「受益者」と「負担者」が異なることです。
デジタル化により業務効率が上がるのは職員（負担者）ですが、その効果は間接的であり、直接の「受益者」である利用者への効果（サービス品質向上など）を定量化して説明するのは困難です。さらに、行政からの補助事業である場合、「なぜこのツールを選ぶのか」「他の選択肢はなかったのか」という説明責任が、施設運営者から行政に対して発生します。
これは、企業内で言えば、「事業部門（現場）が導入を欲するSaaSの費用対効果を、経営層や情シス部門に対して明確に説明できない」状況と酷似しています。「なんとなく便利そう」では予算は降りず、かといってROIを厳密に算出するのは現実的でない。このジレンマが導入を阻むのです。
経営者が始めるべき「IT説明責任」の第一歩
この問題を打破するには、経営者自らが「ITに対する説明責任のフレーム」を定義し、要求することが出発点です。具体的な第一歩を三つ提案します。
1. 「事業地図」と「システム地図」の関連付けを要求する
主要な顧客プロセス（見込み客獲得→契約→サービス提供→請求→アフターサービス）を描いた「事業地図」を作成し、その各ステップを「どのシステム（またはSaaS）がどう支えているか」を関連付けた「システム地図」の作成を情シスまたは各部門に求めます。ツールとしては、MiroやLucidchartなどの図形描画ツールで十分です。この作業自体が、ITのビジネスへの貢献を可視化する第一歩です。
2. 新規IT投資の「説明書」フォーマットを制度化する
新しいツールやシステムの導入提案時には、以下の3点を必ず説明させるフォーマットを設けましょう。
・解決する「事業上の課題」：数字で示せるもの（時間削減、機会損失など）
・代替案とその比較：なぜこのツールなのか、他社製品や内製はなぜダメなのか
・「説明」の継続コスト：導入後、そのシステムの状態や効果を継続的に報告するための方法と想定工数
この「説明の継続コスト」を認識することが、属人化を防ぎ、資産として管理する意識を生みます。
3. 「Mill」的アプローチを、既存資産の定期健診に活用する
自社にレガシーシステムが存在するなら、「Mill」のようなコード解析AIの活用を、大規模リプレースの前調査ではなく、「IT資産の定期健康診断」のツールとして位置づけます。目的は全容把握という巨大な目標ではなく、「主要モジュールの依存関係図を最新化する」「特定の業務ルールがコードのどこに記述されているか索引を作る」など、小さく実現可能な「説明の断片」を積み上げることです。
説明責任はコストではなく、ITを経営資源化する投資
「Mill」に代表されるAIは、ITの説明責任を果たす「技術的コスト」を下げます。しかし、肝心なのは、その説明を「誰が」「何のために」「どのような形式で」求めるかという経営側の要求定義です。
障害者施設のデジタル化の難しさは、デジタル化そのものではなく、その価値を多様なステークホルダーに説明し合意形成するプロセスの難しさにあります。企業においても全く同じです。
経営者が「このシステムは何をしているのか？」と問うこと、そしてその問いに答えるための時間と予算を「コスト」ではなく、IT資産の価値を維持・向上させるための必須「投資」と認識すること。これが、ブラックボックス化したITを、説明可能で戦略的に活用できる真の「経営資源」へと転換する、最も確実な第一歩なのです。
説明できないITは、もはや資産ではなく、いつ爆発するかわからない負債でしかありません。その負債を可視化し、管理可能な状態に戻す作業こそが、今、経営に最も求められるIT戦略の実践と言えるでしょう。
