見出し画像

AIに任せる場所は、技術では決まらない

前回まで、AIの出力を柵で縛る話と、約束を台帳に置く話を書きました。どちらも根っこは同じで、人の注意という、いちばん希少な資源をどこに使うかの話です。今回はその配分の原則を書きます。

AIに何を任せ、何を人が握るか。この線引きを「技術的に難しいかどうか」で決めている現場をよく見ます。難しい部分は人が書き、定型はAIに任せる。一見もっともですが、この基準は間違っていると思っています。

「全部うちで作る必要、あるの?」

小売チェーンの情報システム部が、システムの全体地図を役員会に持ち込んだ場面を想像してください。役員の質問は身も蓋もありません。「この地図の全部を、うちで作るわけ? いくらかかるの?」

良い質問です。答えるには、地図に色を塗る必要があります。塗り分けは三色です。

。その会社の競争力の源泉になっている領域。ここの出来が事業の成否に直結し、他社より深く、速く進化させ続けなければならない部分。

支援。事業に固有で必要だが、そこで他社に勝つ必要はない領域。まっとうな会社ならどこでもやっている。

汎用。どの会社の業務にもあり、完成度の高い既製品が世の中に存在する領域。会計、給与、認証、メール配信。

判定基準は一つしかありません。そこでの優位が、うちの競争力になるか。 技術的な難しさでも、コードの量でも、開発者の思い入れでもありません。

核は、機能一覧では描けない

この本の題材にした架空の小売チェーンの核は「限定品の売り方の設計」でした。抽選は公平、先行販売は上位会員への敬意、特売は雑にやらない。お客は売り方を信用して来ている。在庫や注文は大事だが、そこで他社に勝つ必要はない、という色分けです。

面白いのは、核の輪郭が持たせない機能でも描かれることです。この会社の抽選には「会員ランクで当選を優遇しない」という固い決め事があります。優遇は数行で実装できます。それでも入れない。外れた人全員に「どうせ上位会員が取ったんでしょう」と思わせた瞬間、抽選の値打ちが消えるからです。

断る機能を明文で決めることも、核の設計です。そしてこの判断は、技術の側からは絶対に出てきません。業務の側にしか、断る理由がないからです。

三色は、そのまま注意の配分表になる

ここからがAI時代の話です。この三色は、もともと「予算と人をどこに厚く配るか」を決めるための道具でした。核は最良の人で内製し、支援は簡素に確実に、汎用は買う。

AIが実装を安くした今、この配分表の意味が一段広がりました。核には人間の注意を注ぎ、支援と汎用はAIと既製品に大きく委ねる。 以前「AIの書いたコードは、もう全部は読めない」で、人が読む場所を選び抜くと書きました。どこを読むかの答えが、この色分けです。核の判断が通る場所、つまり業務ルールの門番、金額や在庫の計算、そして仕様そのものは人が読む。画面の配線やデータの詰め替えは、機械の網と別のAIの目に委ねる。

冒頭の「技術的な難しさで線を引く」がなぜ間違いか、これで言えます。難しさで引くと、人の注意が汎用の領域に吸われるからです。認証基盤の自作、独自フレームワーク、社内共通ライブラリの磨き込み。開発者の腕が鳴る場所と、会社が勝つ場所は、しばしば違います。AIが「作れてしまう」時代には、この誘惑はむしろ強まります。汎用を上手に作り込む楽しさは、核から注意を吸い取る税金です。

逆向きの事故もあります。核をAIに丸投げすること。 汎用は委ねてよい、ではなく、委ねてよいのは汎用だけ、と読んでください。競争力の源泉を「ありがちな答え」の生成機に任せた会社は、競合と同じものを持つことに全力で投資したことになります。

全部を大事にすると、どこも育たない

この配分でいちばん多い失敗は、「うちはどの業務も大事」という態度です。大事さと競争力は別の軸です。すべてが核だと言うことは、傾斜配分の放棄、つまり実質的にどこにも注力しないことと同じです。

そしてもう一つ。核は固定資産ではありません。事業が動けば、核も動きます。十年前は「店舗網と品揃え」が核だった会社が、いまは「売り方の設計」を核にしている。色分けは一度きりの儀式ではなく、節目ごとの定期健診です。 AIに任せる範囲も、それに合わせて動きます。

線引きの主語は、業務

AIに何を任せるかは、技術の問いに見えて、実は「うちは何の会社なのか」という問いです。この問いに答えられる文書が一枚あると、線引きは毎回ぶれなくなります。核が何で、なぜ価値なのかを一ページに煮詰めた宣言文。その一枚が、人の注意の配分表であり、AIへの委任状の範囲指定でもあります。

ボトルネックはモデルにある。どこに人の注意を使うかを決める仕事は、業務の言葉からしか始まりません。

次回は実録回です。AIに動く画面を十数分で作らせ、会議の代わりに「動くもの」で要件を確かめた話。作って確かめる方が、話し合って決めるより速くなった実感を書きます。


この連載の元になった書籍『モデルを育てる ― 要件を探り、MVPで確かめ、境界で分ける実践ドメイン駆動設計』(有原悠)では、この「核・支援・汎用」の色分けと、核に注ぐための道具立てを、架空の小売チェーン「アオバ堂」の業務を題材に組み立てています。

※Kindle Unlimited読み放題対象です。

▼ 前の話

▼ 次の話


いいなと思ったら応援しよう!