「小さく試す」を並べるほど、どれも深くならない理由

「小さく試す」は正しい。ただし小ささが複数に分裂すると、深さは一つも残りません。tugiloに相談が来る現場では、三つのパイロットが「それぞれ週一で報告」になり、どれも三ヶ月で止まる——という形がよくあります。悪いのは意欲ではなく、測り方と責任が一つに揃っていない並列です。

深くならない理由はシンプルで、学びが共有されないからです。Aチームの失敗がBチームの設計に入らない。経費は四つに割れたのに、型は一つも残らない。小さく始めるほど、実は「何を学ぶか」を一つに決める必要があります。

並列の小ささが生む、三つの静かな破綻

一つ目は、成功の定義がチームごとに違うことです。「速くなった」「楽になった」は気持ちとしては正しいのですが、経営判断に耐える形に揃わないと、並列は「頑張りの展示」で終わります。AIパイロットで最初に選ぶ1業務の見極め方で書いたように、最初に決めるべきは観測できる一文です。並列のときほど、この一文を全パイロットで共有しないと、比較できず、深まりません。

二つ目は、入力と型が分散し、誰の手元にも「再現手順」が残らないことです。AIは8割で動かす。「毎回違う仕事」は、あとから育てるという話は、並列のときに誤解されやすいです。「八割で四つ」ではなく、八割を一つの型に固定してから、二つ目に広げる——順番を間違えると、八割が四つに割れて、どれも六割になります。

三つ目は、現場の注意が細切れになることです。週次で四つのデモを見る経営と、四つのチャットを追う現場の両方が薄くなります。薄さは怠慢ではなく、同時多発の設計の副作用です。

深さを取り戻す順番：いま並列なら、まず一つに戻す

いきなり全部やめる必要はありません。ポイントは、並列のまま「評価だけ統一」しようとすると、また抽象論になることです。まず一つのパイロットに、他の試行の学びを週一で流し込む場を作る——深さは、ここから戻ってきます。

たとえば、経理・営業・CSの三部署で別々にAIを試している場合、会議を一つにまとめなくても、週次の冒頭五分を「いま一番型が残っているのはどこか」だけにすることはできます。残りの二つは止めなくてよい。ただし観測の言葉を揃える。これだけで、半年後に「結局どれが効いたのか」に答えられる確率が変わります。

まとめ：小ささは武器、分裂は違う

小さく試すことと、小ささを増やすことは別です。後者は、学びの深さを分散させる操作になりがちです。深さが要るときは、並列を減らす勇気のほうが、現場にとって親切なことが多いです。

深さをつくるフレーム（指でなぞれる版）

並列を整理するとき、tugiloでは次の一本線で見ます。

成功定義 → 入力 → 検証 → 確定 → 再利用

成功定義がバラバラだと、入力も検証も語れず、確定したものが再利用されません。試行の数を減らす前に、この列車のレールを一つに揃えるイメージです。

今週やるのは、これだけ

進行中の試行がいくつあってもよいので、いまチームで週次に回している報告資料の「1ページ目」だけを直す（使っているアプリは問わない）。
具体的には、1ページ目のタイトル直下に、全パイロット共通の見出しを1つだけ置く——その見出しの文言は毎週同じに固定する（例として「今週の共通成功指標」）。その直下の1行だけに、全試行で共有する「成功の定義」を書く。パイロットごとの詳細は2ページ目以降でよい。1ページ目は、この1行のための場所にする。

どこに書くかはこれ以外にしない：その週次資料の1ページ目・タイトル直下（共有リンクを開いたときの先頭スライド／先頭ページ）。SlackやNotionに別途書かず、週次で必ず全員が開くあのファイルの1ページ目に集約する。

合言葉：並列は、深さを殺す。