完璧な仕様を待たない。「作って動かす」を組織の作法にする

AIを使った業務改善の提案が、検討の段階で3か月止まることがあります。
その間にツールの機能は変わり、当初の前提はもう古くなっています。
それでも「もう一度整理してから」と足踏みが続き、また数か月が過ぎていきます。
これは組織が慎重すぎる話ではなく、変化の速さと意思決定の速さが噛み合っていない構造の問題です。

今回は、「作って動かす」を組織の作法にするための進め方を整理していきます。
小さく作って回す考え方そのものは内製開発は超最小単位で回す。作りすぎて失敗しないためににまとめてあります。

検討が長引くほど遅れる

検討を長引かせているのは、何でしょうか。
この領域には、3つの特徴があります。

ひとつは、仕様そのものが動き続けている点で、「半年前はできなかった」作業がいまはAIでできるようになっていますし、逆に想定していた機能のほうが変わってしまうこともあります。
検討している間に前提が変わるので、完璧な仕様を固めても、着手する時点でもう古くなっています。

2つ目は、効果はやってみるまで読めない点です。
業務にどれだけ効くかは、使ってみるまで分かりません。
もちろん試算はできますが、精度はあまり高くありません。

最後は、失敗のコストが小さい点で、ボットを1つ作るのに数十分、費用はほぼゼロです。
従来のシステム導入とは、失敗のコストの桁がそもそも違います。

この3つを合わせると、結論ははっきりしています。
つまり、検討に時間をかけるより、小さく作って動かして判断するほうが速くて安いのです。
ただ、これを組織で許すには、いくつか設計が必要になります。

作って動かすこの作法が全体の段取りのどこに入るかは、業務のAI化の進め方。棚卸しから優先順位付け・実装までの手順で順を追って確かめられます。

範囲・期限・撤退基準を決めて、ルールを1枚にする

現場が勝手に「作って動かす」状態は、管理できていない状態でもあります。
だから、先に3つを決めておきます。

ひとつは範囲で、どこまで自由にやってよいかを扱う情報の階層で決めます。
手元のデータだけを処理するものは「自由」、社内データを読むものは「一声」、書き換えるものは「レビュー」を通す扱いにします。
権限の階層の決め方は内製環境の権限設定をどう整えるか。安全と速度を両立させるで扱っています。

2つ目は期限で、暫定運用をいつまで続けるかを、3か月なら3か月と決めます。
期限のない暫定運用は、そのまま恒久化してしまいます。
最後は撤退基準で、使われなくなったら、費用が想定を超えたら、精度が業務に耐えなかったら、どうなったらやめるかを先に書いておきます。

この3つを決めておくと、現場は判断を求めずに動けますし、推進側も動いているものを把握できます。
そのうえで、現場に配る形にまとめますが、書くのは次の4行だけで足ります。

手元のデータだけを処理するものは、自由に作って使ってください。

社内データを読むものは、作る前に一声かけてください。

社内データを書き換えるもの、外部に送るものは、レビューを通してください。

暫定で使い始めたものは、3か月後に続けるか判断します。一覧に登録してください。

最後の1行が要点で、「一覧への登録」を作る自由の条件にします。
作る自由と、把握する仕組みをセットで渡す設計です。

また、登録は、何をするものか・扱う情報の階層・作った人・使い始めた日の4項目だけにして、簡単にしておきます。

金額と権限の設計で、稟議は軽くなる

稟議はなぜ重くなるのでしょうか。
検討が長引くもう1つの原因はここにあり、金額の設計で解決できます。
まずは、少額の「裁量枠」をつくることで、月額数万円までは部門長の判断で使えるという枠があるだけで、試すための決裁そのものが不要になります。

次に、「試行予算」を推進チームの側に置き、部門が試したいものはその予算で試して、効果が出たら部門の予算に移す形にします。
試行の段階で部門に負担を求めないほうが、着手は増えます。

あわせて、費用の上限も決めておきます。
処理量に応じて課金される場合は、想定を超える請求のリスクがあるからです。
上限の仕組みと、上限に達したときの承認者を決めておくと、かえって自由にやりやすくなります。
費用設計そのものはAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

そして、金額の桁そのものを、先に経営へ共有しておきます。
従来のシステム導入と違って試すコストは月数万円の水準で、それを伝えておかないと同じ重さの稟議が回ってきます。

3か月後の判断日を先に決め、失敗は責めない

作って動かしたあとの設計も必要で、ここが抜けると作ったものが放置されます。
まず、3か月後の判断を先に予定として入れておきます。
一覧に登録した日から3か月後に、「続ける」「改善する」「やめる」の3つから選びます。
続けるは正式運用、改善はもう3か月延長です。

次に、改善の窓口を1つ決めておきますが、使ってみて出てくる要望の受け口なので、チャットのチャンネル1つで足ります。
ここでもっとも重要なのは、やめることを減点にしない姿勢です。
「3か月使って効果が出なかったのでやめました」は、それ自体が成果です。

やめた記録を残して共有しておくと、同じ失敗を別の部門が試す無駄が減ります。
あわせて、やめた理由を3種類に分類しておきます。
効果が出なかった・業務が変わって不要になった・別の手段のほうが良かった、の3つです。

別の手段のほうが多いなら、手段の判断基準を見直します。
そもそも「作って動かす」が組織で回るかどうかは、失敗の扱いで決まります。

やってはいけないのは、成功事例だけを共有する運用です。
うまくいったものだけが発表される場だと、失敗した人は黙り、次から試さなくなります。

効くのは3つです。
ひとつは、「試した数」を評価の対象にする姿勢で、成功した数ではなく試した数を見ると、先に宣言しておきます。
2つ目は、推進担当が自分の失敗を最初に話す動きで、「これを作ったけど使われませんでした」を先に言うと場の空気が変わります。

最後は、やめた事例を共有の場に載せる運用です。
月1回の共有会で、成功例2件とやめた例1件を紹介する形にします。
やめた例のほうが学びが多いことは、実際に多いです。

部門長にも、先に伝えておきます。
部下が試して失敗したことを減点しないよう共有しておかないと、現場は上司の評価を気にして動きません。

向かない3つの場面と、繰り返しやすい5つの失敗

一方で、この作法が向かない業務もあるので、ここは先に線を引いておきます。
ひとつは、失敗の影響が大きい業務で、金額が動く、社外に出る、人事に関わるものが該当します。
ここは暫定運用にはせず、通常の検討を通します。

次は、規制や監査の対象になる業務で、記録の要件があるものは要件を確認してから作ります。
最後は、部門をまたぐ業務で、複数部門の合意が必要なものは勝手に作ると調整が発生します。
先に合意を取ってから動くほうが、結局は早く進みます。

この3つ以外は、作って動かして構いません。
そう線を明示すると、現場は迷わなくなります。
「基本は自由、この3つだけ相談」という形にしておきます。

繰り返しやすい失敗は5つあります。
期限を決めずに暫定運用を始める、一覧への登録を条件にしない、成功事例だけを共有する、やめることを減点にする、試行の費用を部門に負担させる。
どれも、期限と登録をセットにして、やめた例も共有して、推進チームの予算で試せば避けられます。

意思決定する側の解像度が、最後の壁になる

ここまで書いてきた設計は、どれも推進担当が主導できるものです。
ただ、実務でいちばん詰まるのは、承認する側の判断です。

「まず作って動かしてみます」という提案に対して、従来のシステム導入と同じ検討を求められる場面があります。
「仕様書を出せ、効果を試算せよ、リスクを網羅せよ」という反応で、悪意があるわけではなく、それが今まで正しかった作法だからです。
この壁だけは、ルールの整備では越えられません。

AIでどこまでできて、試すコストはどの水準なのでしょうか？
判断する側が、実感としてそれを持っている必要があります。
資料で説明しても、触っていない人には桁の感覚が伝わりません。

私たちが提供している役員・AI担当向けの個別トレーニングは、経営者・役員・AI担当が短時間で「いまのAI活用」を掴む形にしています。
現場は動きたいのに承認で止まる、そういう状態であれば、こちらから当たるほうが早いかもしれません。

検討より、小さく作って動かすほうが速くて安い

この領域は、仕様が動き続け、効果はやってみないと読めず、失敗のコストも小さいという3つの特徴を持っています。
だから、検討に時間をかけるより、小さく作って動かして判断するほうが速くて安いのです。
これを組織として許すには、3つを決めておきます。
範囲は扱う情報の階層で分け、期限は3か月などと区切り、撤退基準を先に書いておきます。

そのうえで、作る自由と一覧への登録をセットにして渡します。
稟議は、少額の裁量枠と推進チームの試行予算で軽くします。
試行の段階で部門に負担を求めないほうが、結果として着手は増えます。

3か月後の判断を予定に入れ、やめることを減点にしません。
成功事例だけでなく、やめた事例も共有の場に載せます。
やめた例のほうが学びが多いことが、実際には多いからです。

向かないのは、失敗の影響が大きい・規制や監査の対象・部門をまたぐ、の3つだけで、この3つ以外は自由だとはっきり示しておきます。

まずは、暫定運用のルール4行を書いてみてください。
自部門でまず1つ、実際に試してから広げれば十分です。