第1話｜実装の前に決めるべき「3 つの問い」

「ツール選定」より前に決めること

AI 導入の話はツールから始まりがちです。どの SaaS にするか、どの基盤モデルにするか、社内で動かすかクラウドかなど。これらはどれも重要ですが、ツール選定の前に決めておかないと判断軸そのものがブレる問いが 3 つあります。

1. 1. 何を成果として測るのか
2. 2. 誰が責任者になるのか
3. 3. やめる条件は何か

この 3 つに答えがないままツール選定を始めると、半年後に「使われているけれど効果がわからない」「誰も全体を把握していない」「やめる理由が無く惰性で続く」という典型的な停滞に入ります。

成果は「業務単位」で書く

第1の問いは「何を成果として測るのか」です。ここでよくある失敗は、AI 主語で成果を書いてしまうことです。「AI で生産性を 30% 上げる」のような書き方は、何が起きれば達成かが定義できません。

代わりに、業務単位で書きます。「営業部の商談メモ整形にかかる週次工数を、20 時間から 10 時間に減らす」のように、誰の・どの作業の・何時間／何件が、どう変わるかを具体に書きます。AI を別ツールに置き換えても、この成果指標は変わらないという形にしておくのがコツです。

業務単位で書けない案件は、まだ実装に進む段階ではありません。ここで止まるなら、現場のヒアリングからやり直します。

責任者を 1 人に決める

第2の問いは「誰が責任者になるのか」です。AI 導入は、業務部・情シス・経営企画・法務の境界に立つことが多く、責任の所在が曖昧になりやすい領域です。

最低限決めるべきは次の 3 役です。

• - 業務オーナー（業務部の課長級）：成果指標の達成責任
• - 技術オーナー（情シスの担当）：システム構成と運用責任
• - 全社オーナー（経営企画または DX 推進）：横断ルールとの整合責任

このうち、現場で困ったときに判断する一次窓口を業務オーナーに置きます。技術オーナーや全社オーナーに決定権を集中させると、現場が動けなくなります。技術と全社は「枠」を決め、業務オーナーが「中身」を回す、という分担です。

やめる条件を最初に書く

第3の問いは「やめる条件は何か」です。導入後にどんな数字や事象を見て継続／中止を判断するかを、契約前に決めておきます。

書き方の例:

• - 3 か月後に成果指標の進捗が 30% 未満なら見直し
• - 月間のリカバリ工数（誤回答による手戻り）が削減効果の半分を超えたら撤退検討
• - 重大事故（情報漏えい・誤回答による顧客クレーム）が 1 件でも起きたら即時停止

この条件を成果指標の隣に書いておくと、半年後に「続けるか／やめるか」の議論が短時間で終わります。

本シリーズの進め方

このシリーズでは、上記 3 つの問いに答えた前提で、PoC から本番昇格までの設計を扱います。第2話は PoC のスコープと KPI、第3話は PoC から本番への昇格基準。第4話以降は既存システム接続、データ準備、セキュリティ、運用、コスト、ベンダー選定、本番昇格チェックリストと進みます。

実装設計の核は、技術ではなく「やめる勇気を持てる枠を最初に作っておくこと」です。やめられる導入は、安心して始められます。

この回のまとめ：

• - ツール選定の前に「成果」「責任者」「やめる条件」の 3 つを決める。
• - 成果は業務単位で書き、AI を主語にしない。
• - 責任者は業務／技術／全社の 3 役、現場一次窓口は業務オーナー。
• - やめる条件を成果指標の隣に書いておく。
• - やめられる導入は、安心して始められる。