開発スピードを加速し、
より確かなスケールへ。

すでに使っている自動化との違い

多くのチームはすでに自動化を使っています。フォームの入力がスプレッドシートに記録され、決済がメールを送信し、デプロイがテストを実行する。これはルールベースの自動化です。人が手順を書き、ソフトウェアは毎回そのとおりに実行します。

ルールは動作が読みやすく、コストもかかりません。そして現実がルールから外れた瞬間に機能しなくなります。問い合わせ文を読んで、顧客が不満を感じているのは配送ではなく請求についてだ、と判断することはできません。

違いはこの一点に尽きます。入力が不揃いで、形式がまちまちで、人が書いた文章であるような場合、つまりルールで対応しようとすれば分岐が際限なく増えるような場合に、AIが力を発揮します。

だからこそ、AI自動化は既存のルールを置き換えるものではありません。AIが読んで判断し、ルールがその後の処理を実行する。二つは組み合わせて使うものです。

少人数のチームで成果が出やすい領域

最初に成果が出るのは、派手に見える領域ではありません。すでに特定の誰かの一週間を奪っている仕事です。

1. 01

   繰り返される顧客からの質問

   初期のサポート業務の多くは、同じ内容の質問が表現を変えて繰り返されるものです。「いまどうなっているか」「プランを変更したい」「この請求は何か」といった内容です。

   AIは問い合わせ文を読み、それが実際にはどの質問なのかを判断し、返信の下書きを作成し、例外的な内容だけを担当者に振り分けることができます。

   例

   • 問い合わせの仕分け
   • 返信の下書き
   • 注文・配送状況の案内
   • 担当者への振り分け

   目的はサポートから人をなくすことではありません。創業者が同じ質問に200回目の回答をする状況をなくすことです。

2. 02

   ツール間の情報の受け渡し

   少人数のチームが使うツール群は、設計されたものではなく、必要に応じて積み上がったものです。CRM、スプレッドシート、請求ツール、共有の受信トレイ、チャットアプリ。

   それらをつないでいるのは、たいてい人によるコピー＆ペーストです。AIは書類やメッセージを読み、必要な項目を抽出し、あるべき場所に入力できます。

   例

   • 請求書・領収書の処理
   • リード・連絡先の登録
   • 契約書・申込書の受付
   • 二つの一覧の突合

   もっとも地味な領域ですが、効果がもっとも明確に表れるのもここです。作業量を測りやすく、そして誰もやりたがらない仕事だからです。

3. 03

   自社データへの問い

   創業者は数字をどこかに持っているのに、すぐには答えられない。答えるには三つのエクスポートを手作業で突き合わせる必要があるからです。

   AIはそのデータの上に立ち、平易な問いをクエリやグラフ、短い答えに変換できます。

   • 今月、利用が止まっている顧客はどこか
   • 料金ページの公開後、登録数に何が起きたか
   • 実際に売上を支えているプランはどれか
   • オンボーディングのどこで離脱しているか
4. 04

   繰り返しだが単純ではない開発作業

   コードレビュー、テストの作成、マイグレーション、ドキュメント、リリースノート。いずれも判断を伴うため、スクリプト化しにくく、後回しにされがちです。

   AIがまず一次対応を行えば、人の役割は「作る」から「承認する」に変わります。

   例

   • コードレビューの一次確認
   • テストの自動生成
   • リリースノート
   • ドキュメントの下書き
5. 05

   同じ種類の文章を大量に書く仕事

   商品説明、掲載情報、オンボーディングのメール、多言語対応。創造性よりも量が課題になる種類のコンテンツです。

   AIが大量に下書きし、人が編集する。これにより、作業の詰まる場所が入れ替わります。

   例

   • 商品・掲載用の文章
   • ライフサイクルメール
   • 翻訳の初稿
   • 長い資料の要約

どこまで任せるかを決める

同じ仕組みでも、任せ方によってリスクは大きく変わります。最初の取り組みは、いちばん上の段階から始めるべきではありません。

• 定めた範囲内でAIが自ら実行し、何をしたかを報告する。
• AIが答えを用意し、送信や実行の前に人が承認する。
• AIは収集と要約までを行い、判断と実行は人が担う。

必要だと感じる段階より、一段下から始めてください。信頼できると分かってから上げるのは簡単ですが、対外的な失敗のあとで下げるのは高くつきます。

利用料以外にかかるもの

ライセンス費用は通常もっとも小さい項目です。少人数のチームが見落としがちなのは、請求書に現れないコストです。

• データを使える状態に整えるための時間
• 担当者を置くこと。出力を確認し、修正し、誤りかどうかを判断する人が必要です
• 呼び出し量に応じた費用。予算ではなく、事業の成功に比例して増えます
• すでに使っているツールと接続するための作業
• 利用できない日に何をするかという備え

いずれも始めない理由にはなりません。五つではなく一つの業務から始める理由、そして稼働させる前に担当者を決めておく理由になります。

AIにできないこと

限界を早い段階で理解しておくことが、後の四半期を守ります。

• 壊れた業務プロセスは直りません。良くない業務を自動化すれば、良くない結果が速く出るだけです
• 事業そのものを理解しているわけではありません。与えた資料の範囲しか知りません
• 常に正しいわけではありません。問うべきは、誤った答えが何をもたらすかです
• 判断そのものはなくなりません。判断の場所が確認作業へ移るだけです
• まだ採用していないチームの代わりにはなりません。いまいるチームの力を伸ばすものです

この五点を理解しているスタートアップは、プラットフォームを導入して期待するだけの組織よりも、小さな最初の一歩から多くを得られます。

「うまくいっている状態」を先に書き出す

コードを書く前に、技術者でない同僚が照合できる程度の文章を一段落だけ書いてください。何が入力され、何が出力され、誰がそれを見て、判断がつかないときに何が起きるのかです。

• 入力は具体的に何で、どこから届くのか
• 出力は何で、次の工程はどの形式を必要とするのか
• それに基づいて誰が、あるいは何が動くのか
• 確信が持てないとき、どう振る舞うべきか
• 成功を判断する指標を一つ

その一段落が書けないのであれば、その業務はまだ自動化できるほど理解されていません。これは遅れではなく、一つの発見です。

先に、いまのやり方を測る

半日を使って、その仕事が現在どう行われているかを測ってください。所要時間、間違いの頻度、一週間あたりの件数です。

これがないと、後になって唯一重要な問い、つまり「以前より良くなったのか」に答える手段がありません。この工程はどの段階よりも省略されがちで、その結果、決着のつかない議論が始まります。

評価できる最小のものを作る

最初の版は、実際の入力で動き、実際の出力を生み、そして何も変更しないものにします。仕事は引き続き人が行い、仕組みはその横で動いて、答えだけが記録されます。

• 選んだ例ではなく、実際のデータを使う
• 通常の一週間と同じ件数で動かす
• 整った事例だけでなく、扱いにくい事例も含める
• 後から確認できるよう、出力を保存する

これがもっとも安価で率直な検証であり、誰にも悪い体験をさせずに済みます。

その仕事をしている人と一緒に出力を見る

業務を担当している人と並んで、出力をいくつか一緒に確認してください。ダッシュボードが一か月かけて示すことを、その人は十分で見抜きます。

• どこが正しく、どこが自信を持って間違えていたか
• ここで間違えるのは煩わしい程度か、それとも損害になるか
• 中身を読まずに送信させて良いと思えるか
• 信頼するためには、何が見えている必要があるか

最後の問いへのその人の答えが、そのままリリース基準になります。自分たちで考え出すどんな基準よりも、具体的で現実的なはずです。

ブレーキをかけたままリリースする

有用性を保てる範囲で、裁量はもっとも小さくしてください。そして、元に戻すことを簡単にしておきます。

• まずは、すべての出力を人が承認する形から始める
• 業務全体ではなく、その一部分だけに適用する
• 初日からすべての入力と出力を記録する
• チームの誰もが押せる停止手段を用意する
• 何をする仕組みで、どこで間違えるのかをチームに伝える

制限を緩めるのは一度に一つ、間を一週間空けて。問題が起きたとき、どの変更が原因かが分かります。

そして、実際に判断する

一か月後の日付をカレンダーに入れ、三つのうちどれかを決めてください。避けるべきは「やめないこと」です。信頼しきれない仕組みが、担当者のいないまま動き続ける状態です。

中止も良い結論です。学んだことさえ残っていれば。測定した基準値、うまくいかなかった事例、そして見合わなかった理由。それが二つ目の取り組みを一つ目より速くします。