「システム担当AI」が問う、経営者が定義すべき「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点を必ず説明させるフォーマットを設けましょう。

• 解決する「事業上の課題」：数字で示せるもの（時間削減、機会損失など）
• 代替案とその比較：なぜこのツールなのか、他社製品や内製ではなぜだめなのか
• 「説明」の継続コスト：導入後、そのシステムの状態や効果を継続して報告するための方法と想定工数

この「説明の継続コスト」を意識することが、属人化を防ぎ、ITを資産として管理する意識を生みます。

3. 「Mill」的なアプローチを、既存資産の定期健診に使う

自社にレガシーシステムがあるなら、「Mill」のようなコード解析AIを、大規模リプレースの事前調査ではなく、「IT資産の定期健康診断」の道具として位置づけます。目指すのは全体像の把握という巨大な目標ではありません。「主要モジュールの依存関係図を最新にする」「特定の業務ルールがコードのどこに書かれているかの索引を作る」など、小さく実現できる「説明の断片」を積み上げることです。

説明責任はコストではなく、ITを経営資源にするための投資

「Mill」に代表されるAIは、ITの説明責任を果たすための「技術的なコスト」を下げてくれます。しかし肝心なのは、その説明を「誰が」「何のために」「どんな形で」求めるのかという、経営側の要求定義です。

障害者施設のデジタル化が難しいのは、デジタル化そのもののせいではありません。その価値を多様な関係者に説明し、合意を形づくるプロセスが難しいのです。企業でもまったく同じことがいえます。

経営者が「このシステムは何をしているのか？」と問うこと。そしてその問いに答えるための時間と予算を、「コスト」ではなくIT資産の価値を保ち、高めるために欠かせない「投資」と認識すること。それが、ブラックボックスになったITを、説明でき、戦略的に使える本当の「経営資源」へと変える、最も確実な第一歩です。

説明できないITは、もはや資産ではなく、いつ爆発するかわからない負債でしかありません。その負債を見える化し、管理できる状態に戻す作業こそが、いま経営に最も求められているIT戦略の実践といえるでしょう。