- 下書きの時間だけを数えた「2倍速くなった」は、たいてい当てになりません。浮いたはずの時間が、後の手直しに移っているからです。
- 仕事を受けてから顧客に届くまでを測り、やり直しになった作業もコストとして数えてください。
- 効果があるのは、作業を2回に分けるやり方です。1回目でアイデアを出し、2回目で正確さを確かめてから送り出します。
「2倍速い」をビジネスの言葉で定義する
60分かかっていた下書きを社員が15分で書き上げても、データの誤りのために3回も手直しが必要なら、その仕事は少しも速くなっていません。測るべきは、仕事を受けてから顧客に届くまでの時間です。入力作業の時間はその一部にすぎません。
AIは数秒で文章を作るので、多くのチームはとても速くなったと感じます。けれどもその後で、事実の確認、トーンの修正、正しいファイル探し、何度もの承認依頼に時間を取られることがあります。下書きの時間だけを測っていると、会社はありもしない成果を見ることになります。リードタイムは、依頼を受けてから受け手が成果を受け入れるまでを測り、待ち時間、手直し、差し戻された作業も含めてください。
まず、仕事の単位をはっきり決めます。たとえば「承認済みの見積書」「上司が判断に使えるレポート」「問い合わせを解決できた顧客への回答」です。次に、少なくとも20〜30件の仕事でベースライン（導入前の基準値）を取り、簡単・普通・難しいケースに分けておきます。AIは標準的なケースには強くても、例外の処理時間まで同じ割合で縮めてくれるとは限らないからです。
時間がどこで消えているかを探す
開発チーム向け · 技術的な詳細
1件の仕事のタイムラインを作り、Touch Time（人が手を動かす時間）、Machine Time（システムが処理する時間）、Wait Time（データや承認を待つ時間）、Rework Time（戻って直す時間）に分けます。AIが向いているのはTouch Timeの削減で、システム連携ができればWait Timeも減らせます。一方で、指示書と品質ゲートがなければRework Timeは増えます。
5段階の作業ラインを設計する：Frame、Gather、Create、Check、Act
1件の仕事を、課題を理解し、情報を集め、手を動かし、確認し、引き渡すまでの流れ作業として見てみてください。AIが大いに役立つ段階もあれば、まったく役に立たない段階もあります。どの段階がどちらに当たるかを知っていれば、実際に速くなります。
Frameでは課題を絞り込み、受け手、目標、範囲、完了の定義（Definition of Done）を決めます。Gatherでは信頼できる情報源からデータを集めます。CreateではAIに要約、選択肢の作成、下書きを任せます。Checkではルールと根拠に照らして、権限のある人が確認します。Actでは送信、システムの更新、次の仕事の起票を行います。5つの段階に分けておくと、「AIの答えがよくない」とひとまとめにせず、どこで問題が起きたのかを特定できます。
| 段階 | AIが手伝えること | 人が引き続き責任を負うこと |
|---|---|---|
| Frame | 質問を投げて、指示書の不足を埋める | 本当の意図と制約を決める |
| Gather | 検索し、取り出し、整理する | 情報源と権限を選ぶ |
| Create | 下書き、要約、比較 | 進め方とトレードオフを選ぶ |
| Check | 抜け漏れや形式を確認する | 事実、数字、ポリシーを検証する |
| Act | タスクの作成、システムの更新 | 影響の大きい操作を承認する |
手直しを減らす指示書
指示書は7つの問いに答えている必要があります。どんな成果が欲しいのか、誰が使うのか、その人はすでに何を知っているのか、インプットはどこから来るのか、してはいけないことは何か、どんな形で納品するのか、合格の基準は何か、です。そこに良い例と不合格の例を1つずつ添えます。プロンプトに形容詞をいくつも足すより、こうした明確さのほうがずっと効きます。
大事な情報をAIに推測させてはいけません。情報源がそろっていなければ「止まってデータを求める」よう指示します。数字を正確に合わせる必要があるなら、モデルの外にある計算式や計算システムを使います。ポリシーを引用するなら、そのバージョンと日付を添付します。こうした制約をワークフローに組み込んでおけば、安全性が一人ひとりの記憶に左右されなくなります。
4つの品質ゲート
- Fact：重要な主張にはすべて出典か確認した人がいる
- Number：数字をルールで再計算できる
- Policy：内容がポリシーと権限に沿っている
- Audience：受け手が理解でき、次に何をすればよいかわかる
後工程に負担を押しつけずに速くする例
営業部門：Meeting-to-Proposal
開発チーム向け · 技術的な詳細
商談の前に、システムが顧客データ、やり取りの履歴、関連ニュースを事前資料にまとめます。このとき事実と推測は分けておきます。商談の後は、AIがメモをペインポイント、判断基準、ネクストステップに整理します。営業担当が提案内容と条件を選ぶと、システムが承認済みのテンプレートから文書を下書きし、送付前には品質ゲートが価格、範囲、約束事項をチェックします。目標は1回目で通る提案書で、下書きを何本作れたかは問題にしません。
オペレーション部門：Ticket-to-Resolution
AIがチケットを読んで分類し、過去の履歴を引き出し、ナレッジベースから確認手順を提案します。確信度（Confidence）が低いときや、リスクのある言葉が含まれているときは、システムがすぐにシニア担当者へ回します。標準的なケースには早く回答でき、専門家は背景情報のそろった例外だけを見れば済みます。こうしてチームは、安全性を落とさずに処理能力を増やせます。測る指標は、解決までの時間、一次解決率（First-contact Resolution）、再オープンの件数です。
管理職：Data-to-Decision
AIにレポートをゼロから書かせる代わりに、定義の決まったKPIをシステムに取り出させ、変化を指摘させ、問いを立てさせます。管理職は現場で原因を確かめ、判断を下し、その前提を記録します。次のサイクルでは、システムが実際の結果を予想と比べます。こうすると書式を整える時間が減って考える時間が増え、判断そのものはモデルに渡さずに済みます。
試すときは、同じ期間にAIを使う仕事と従来どおりの仕事をランダムに割り振り、季節、仕事量、担当者の腕の差による影響を除きます。一般的な仕事は中央値（Median）で、時間のかかるケースはP90で測ります。顧客は平均値より、極端に遅かったケースのほうを強く感じるからです。
個人の成功をチームの標準にする
開発チーム向け · 技術的な詳細
仕事のできる人ほど、なぜうまくいくのか本人以外にはわからない自分専用のプロンプトを作りがちです。その人が辞めれば、効率も一緒に失われます。効果が確かめられたものは、ワークフローカード（Workflow Card）にまとめます。トリガー、インプット、プロンプトまたはテンプレート、確認手順、責任者、バージョン、合格・不合格の例を書き込んだカードです。カードは1か所に保管し、データ、ポリシー、ツールが変わったら見直します。
自分をごまかさないダッシュボード
| 指標 | どう良くなるべきか | 危険信号 |
|---|---|---|
| End-to-end Lead Time | 仕事全体で実際に短くなる | 下書きだけが速い |
| Right-first-time | 1回目で通る割合が増える | 手直しの回数が増える |
| Cost per Accepted Output | 確認コストを含めても下がる | APIの費用は安いが、確認の人件費がかさむ |
| Exception Rate | 横ばいか減少 | システムが簡単な仕事しか受けていない |
| Customer/Receiver Outcome | 回答が速くなり、満足度も上がる | 出力は多いが使われていない |
やめる基準（Stop Rule）は前もって決めておきます。たとえば、エラーが2週間続けて基準を超えたら下書きモードに戻します。確認にかかる時間が節約できた時間を上回るなら、指示書を直すか、そのユースケースを止めます。チームが使わない場合は、原因がUXなのか、信頼感なのか、実際の仕事に合っていないのか、KPI同士がぶつかっているのかを確かめます。何でも研修を増やして解決しようとしないでください。
2倍速くなる理由は、AIだけとは限りません。誰も読んでいないレポートをやめる、承認者を減らす、共通データを正しく整えるといったことのほうが、AIより大きな効果を生む場合もあります。AIで成果を上げている会社は、既存の業務プロセスにAIを貼りつけるのではなく、仕事そのものを設計し直す中にAIを組み込んでいます。
TECHNIQUE · 手を抜かずに速くする
2段階（Two-pass）で進める：1回目で幅を広げ、2回目で精度を上げる
最終的な答えを1回でAIに作らせようとしないでください。1回目は課題を分解させ、足りない情報を指摘させ、3つの進め方を提案させます。人が方向を選び、事実を補います。そのうえで2回目に、テンプレートとチェックリストに沿って成果物を作らせます。手順が1つ増えたように見えますが、後工程での手直しは大きく減ります。とくに提案書、レポート、複数の部署を通す必要のある文書で効果があります。
20-60-20ルール
時間の20%を指示書づくりに、60%をAIと人の共同作業に、残りの20%を確認と受け手に合わせた仕上げに充てます。確認が何度も続けて20%を超えるなら、インプット、テンプレート、仕事の範囲のどこかにまだ問題があります。確認担当者をせかしても解決しません。
ヒント：テンプレートには成果物にちなんだ名前をつけます。「Proposal-SME-v3」のようにして、「最新のすごく良いプロンプト」のような名前は避けます。不合格だった例も残しておきましょう。間違った例のほうが、長い説明よりも範囲をはっきり示してくれます。
知識を、現場で使える問題解決の仕組みへ
問題の核心
スピードを上げるには、仕事の流れ全体を直す必要があります。下書きの段階だけを急がせて確認作業を次の人に残しても、速くはなりません。
段階を踏んだ解決の進め方
- 実際の仕事を少なくとも20件選び、Touch、Wait、Reworkの時間を測る
- Frame、Gather、Create、Check、Actの5段階に品質ゲートを組み込んだワークフローを設計する
- 小さなグループで試し、受け入れられた成果物（Accepted Output）、P90、エラー、1件あたりのコストを測る
仕事のできる人のコツを、チーム全員が使えるワークフローにする
AIで速くなったとチームが言うとき、私たちが知りたいのは、どこが速くなったのか、そして次の工程で誰の負担が増えたのかです。そこでDNA Makerは、依頼を受けてから受け手が成果を受け入れるまで、実際の仕事を追いかけるところから始めます。作業時間、待ち時間、手直しの時間を分け、仕事の責任者と一緒に指示書、品質ゲート、例外を決めます。仕事が「十分に良い」かどうかを判断する知識は、これまでどおりお客様のチームが持っています。私たちはその知識を、目に見えて測れる業務プロセスとして整理するお手伝いをします。そうすれば個人のプロンプトが失われることも、ミスが後工程の確認担当者に押しつけられることもなくなります。
課題がはっきりすれば、DNA MakerはAI Work AssistantをWebアプリケーションやモバイルアプリケーションとして設計できます。指示書を受け取り、既存システムからデータを取り出し、仕事を下書きし、ルールに沿って確認し、承認に回し、監査ログを残すところまでを1つの流れで行うものです。AIエージェントが背景情報を集めたり、複数の段階にまたがる作業をこなしたりすることもありますが、重要な場面で判断する権限は人に残します。プロダクトデザイン、システム連携、開発、評価、監視から、エンジニアの確認のもとでAIによる自律型開発（AI Autonomous Development）を使って開発とテストを速めるところまで、一貫してお手伝いできます。チームが毎日繰り返している仕事があれば、その実際の流れを見ながら、削るべき部分、自動化すべき部分、人に残すべき部分を一緒に切り分けますので、ご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
この表は、経営層、業務の責任者、開発チームが同じ言葉を別々の意味に取らずに話し合うためのもので、暗記する必要はありません。意味と例に加えて、右端の質問も読んでください。こうした質問から、開発を始める前に隠れていた範囲、リスク、コストが見えてくることがよくあります。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| API | システム同士がデータをやり取りするための標準的な窓口 | CRMから顧客データを取り出して事前資料に入れる | どのシステムと連携できますか？権限やデータ量に制限はありますか？ |
| Quality Gate | 仕事が次に進む前に通過しなければならないチェックポイント | 提案書を送る前に、価格と出典を確認する | 合格の基準はルールで測りますか、それとも専門家が判断しますか？証拠はどう記録しますか？ |
| Human-in-the-loop | 重要なポイントで人が確認・判断する仕組み | AIが下書きし、送信ボタンはアカウントの担当者が押す | 人はすべてのケースを確認しますか、それともリスクの高いケースだけですか？ |
| Automation | 決まった条件に従って、繰り返しの手順をシステムに実行させること | 会議の後、入力し直さずにタスクを作る | システムが間違えたら、どうやって止めて元に戻し、誰に知らせますか？ |
| Audit Log | 誰が、またはどのシステムが、いつ何をしたかの記録 | 提案書がどのバージョンのデータを使ったかをさかのぼって確認する | どのくらい前までさかのぼって確認できる必要がありますか？ |