AIで安く早く作れた。その後の責任を、誰が引き受けるのか

作れたことと、会社で使うと決めることは別です

動くものが目の前にあると、私たちはつい「もう使える」と感じます。しかし、そこで確かめられたのは、多くの場合、想定した操作で期待した結果が返ったことです。顧客ごとの情報が分かれているか、通信が途切れた後に処理が重ならないか、利用者が困ったときに元へ戻せるかまでは、それだけでは分かりません。

だから私が最初に分けたいのは、「何が実演できたのか」と「何を確認済みとして扱うのか」です。仮のデータで主要な流れを試せたなら、試作としては立派な成果です。限られた担当者だけで試すなら、その範囲を決めて次へ進めます。反対に、確認していない条件まで含めて本番利用を認めるなら、それは技術上の見落としではなく、事業上の判断になります。

試作を試作と呼ぶことは、成果を小さく見せることではありません。成果の範囲を正しく言葉にすることで、価値を失わずに次の判断へつなげられます。問題なのは、試作の成功を理由に、別の条件で使えることまで証明されたように扱うことです。

私が決めるべきなのは、どこまでを完成と呼ぶかです

「完成」は、開発者だけが決める技術用語ではありません。個人の試作、チーム内の限定利用、日常業務での利用、顧客へ提供するサービスでは、必要な確認も、許容できる失敗も変わります。利用する人が増え、実データを扱い、外部とつながるほど、完成に含める範囲は広がります。

事業責任者である私が受け取るべきなのは、単なる合格の一言ではありません。どの条件で確かめたのか、何はまだ確かめていないのか、残る問題が起きたときに何が影響を受けるのかです。その情報を、開発、業務、運用の担当者から集め、どの範囲なら使い始められるかを決めます。

未確認の項目があること自体は、失敗ではありません。未確認なら、今回認める利用範囲に含めない。必要なら追加で確かめる。影響が小さく元へ戻せるなら、条件を限って試す。その区別ができれば、すべてが揃うまで止める必要も、分からないまま全面導入する必要もありません。

「問題は見つからなかった」と「必要な条件を確かめた」は、同じ報告ではありません。

私が完成と呼ぶときには、利用範囲、確認した条件、未確認の事項、運用を担う人、次に判断を見直す時点までを含めます。それが揃って初めて、会社としての「使い始める」が成立します。

安くしたのか。誰かに押しつけただけなのか

AIで作れば安くなる。この期待は、間違いではありません。仕様の整理、実装、修正の一部が速くなり、外部へ依頼する範囲を小さくできる場面は確実にあります。ただし、AIサービスの利用料と、従来の外注見積もりだけを比べても、本当の差は分かりません。

外注費には、要件の確認、例外への対応、テスト、導入支援、記録、問い合わせ対応などが含まれていたかもしれません。AIで作った結果、それらが不要になったのであれば削減です。社内の誰かが後から手作業で補うのであれば、費用が消えたのではなく、別の人の時間へ移っただけです。

「AIでここまで作れたのだから、従来の見積もりと比べれば十分に安い」。そう見えるのは自然です。ただ、短くできた仕事と、まだ残っている仕事は分けたいのです。利用者からの質問、誤ったデータの訂正、変更後の確認、障害時の対応、利用アカウントの管理。こうした運用を誰が担い、どれだけ時間を使い、必要な判断を誰が行うのかまで見えて、初めて費用を比較できます。

担当も予算も置かなかった仕事は、消えたのではなく、問題が起きた場所へ流れていきます。

導入を決める時点で運用の担当と予算がないなら、事業責任者がその不確実な負担を引き受けたことになります。記録に残していなくても、その事実は変わりません。

便利になったときほど、次の一線を誰が決めるのか

最初の利用がうまくいくと、次の要望が生まれます。仮のデータではなく実データを使いたい。自分だけでなくチームにも使わせたい。検索するだけでなく、更新や送信まで任せたい。社内の実験を、日常業務や顧客向けの機能へ広げたい。

これらは、見た目には小さな機能追加でも、事業としては新しい導入判断です。触れる情報、操作できる範囲、失敗したときの影響が変わるからです。前の段階で問題がなかったという事実は、前の利用範囲に対する証拠であって、次の範囲まで自動的に保証するものではありません。

「そのたびに承認を取っていたら、現場のスピードが落ちる」。この指摘はもっともです。だから、変更のたびに判断するのではなく、今の範囲で担当者が進めてよい変更と、事業責任者が改めて判断する変更を、あらかじめ分けておきます。影響が限られ、元へ戻せる変更は速く進める。扱うデータや操作権限、利用者、外部への提供範囲が変わるときは、一度立ち止まる。

便利になったときほど、境界は見えにくくなります。だからこそ、誰が次の一線を決めるのかを先に置いておきます。それは挑戦を遅らせるためではなく、一度の失敗で取り組み全体が止まることを避けるためです。

責任者の仕事は、すべてを知ることではなく、未確認のまま決めないことです

事業責任者が技術のすべてを理解しているふりをしても、良い判断にはつながりません。反対に、「専門的なことは分からない」と、導入の判断まで誰かへ渡すこともできません。私の役割は、専門家に何が言えて何が言えないのかを示してもらい、その確認に必要な時間と権限を渡したうえで、残る不確実性を引き受けるかどうかを決めることです。

すでに現場で使われていて不安が見つかった場合も、慌ててすべてを捨てるとは限りません。影響の大きい操作を止める、扱う情報を限る、元の手順へ戻せるようにする、確認する担当を決める。まず被害を広げない範囲に戻し、確かめたうえで再開する選択があります。

同時に、専門家の仕事も「危険です」と告げて終わりではないと考えます。どの範囲なら続けられるのか、何を確かめれば次へ進めるのか、現場が判断できる形で示すことが必要です。事業と技術がそれぞれの責任を持ち寄ってこそ、AIを一時的な試作で終わらせず、使い続けられる仕組みにできます。

最終的に私が決めるのは、単なる導入の可否ではありません。どこまで使うのか。誰が運用するのか。何に予算を置くのか。どの条件なら止め、何を確認できたら再開するのか。その判断が曖昧なままなら、システムだけが完成しても、事業としては完成していません。

早く作れたことを成果にするために、使い続ける責任まで宙に浮かせない。それが、事業責任者として私が引き受ける判断です。