AIで仕事が速くなっても、会社が速くなるとは限らない
実装に5営業日かかっていた仕事が、生成AIを使うことで1日で終わるようになったとします。
80％の短縮です。
では、このプロジェクト全体も80％速く終わるでしょうか。
たとえば、実装の前後に次の工程があったとします。
あくまでこれは説明のための仮想例ですが、実装工程だけを見れば80％速くなりました。しかし、プロジェクト全体では31日から27日。短縮率は約13％です。
では、残りの26日には何が起きているのでしょうか。
要件を確認する。レビューを待つ。判断できる人へ情報が届くのを待つ。承認を待つ。本番へ出してよいかを確認する。
仕事には、実際に手を動かしている時間だけでなく、次の工程へ進むまでの時間があります。
生成AIによって「作る時間」が短くなるほど、これまでその陰に隠れていた「待ち」が目立つようになります。
AIで個人の仕事が速くなったからといって、会社全体も同じ割合で速くなるとは限りません。
AIが速くするのは「作業」。会社を速くするのは「流れ」です。
作業時間と、仕事が終わるまでの時間は同じではない
ソフトウェア開発では、一つの作業だけでなく、変更が利用者へ届くまでの流れ全体を見る考え方があります。
DORAでも、コード変更から本番反映までのリードタイムや、変更を滞りなく届けるためのValue Stream全体が重視されています。
ここで重要なのは、コードを書いている時間だけを見るわけではないことです。
実装が終わったあと、レビュー待ちになっていないか。変更の承認を待っていないか。次の担当へ渡るまで、どこかで滞留していないか。
一つの仕事には、「作っている時間」と「待っている時間」の両方があります。
たとえばAIを導入し、資料作成を3時間から30分へ短縮できたとします。それ自体は明確な効率化です。
しかし、その資料が上司の確認待ちで3日止まり、顧客へ出す日が以前と変わらなければ、顧客から見えるリードタイムはほとんど変わりません。
コードを1日で作れるようになっても、レビュー開始まで4日待つなら同じです。
調査結果を午前中に出しても、「次の定例会議で判断しましょう」となれば、実際に動き始めるのは翌週です。
一工程の生産性向上と、業務全体のリードタイム短縮は別の問題です。
AI導入で「何時間削減できたか」を見ることは必要です。
その上で、もう一つ見たい数字があります。
その結果、顧客が待つ時間は何時間、何日短くなったのか。
そこまで見て初めて、AIの速度が会社の速度へ変わったかを確認できます。
AIが速くなるほど、「決める時間」が見えてくる
AIが会社の意思決定を遅くするわけではありません。
むしろ、以前から存在していた時間が、目立つようになると考えた方が近いでしょう。
単純な数字で考えてみます。
AI導入前
作る 10
決める 5
これがAIによって、
AI導入後
作る 2
決める 5
になったとします。
「決める」が5から10へ増えたわけではありません。以前と同じ5です。
ただ、全体に占める比率は大きくなりました。
これまで10という作業時間に隠れていた5が、急に大きく見えるようになったわけです。
生成AIについても、文章作成や要約、翻訳、コーディングなど、個別作業での生産性向上が確認される一方、それを企業レベルの成果へ変えるには、組織能力や業務プロセスなどの補完的な要素が必要だとOECDは整理しています。
つまり、
AIを導入した。
一人当たりの作業時間が減った。
だから会社全体の生産性も同じだけ上がった。
とは限りません。
AIは新しいボトルネックを生むというより、これまで作業時間の陰に隠れていたボトルネックを見えやすくします。
作る時間が短くなったあと、何を待っているのか。
そこに、次の改善対象があります。
承認は必要。それでも「承認待ち」は必要か
待ち時間という話をすると、「では承認をなくせばよい」と考えたくなります。
それも違います。
本番システムの変更、個人情報を扱う処理、セキュリティに関わる設定。
金融、製薬、医療など、法令や規制への対応が求められる業務や、高額な投資判断では、品質保証、内部統制、職務分掌、リスク管理のために確認や承認が必要です。
承認そのものを悪者にするべきではありません。
見るべきなのは、必要な判断と、判断者を待っているだけの時間を分けられないかという点です。
DORAでも、変更承認について、外部承認へ依存する重量級のプロセスだけでなく、ピアレビュー、自動テスト、継続的インテグレーション、監視などを組み合わせながら、変更の安全性と流れの両方を改善する考え方が示されています。
すべての変更を同じフローへ流す必要があるのか。
小さく可逆的な変更と、大規模な本番変更を同じ承認にしていないか。
順番に確認しているレビューを、一部並行できないか。
あらかじめ基準を決め、その範囲内なら現場で進められないか。反対に、どの条件なら上位判断へ上げるのか。
AI利用でも同じです。
AIが高速に案を生成できるからといって、すべて自動で進めればよいわけではありません。
どのリスクなら現場で判断できるのか。どの処理なら正式な承認が必要なのか。
NIST AI RMFでも、AI利用における責任やガバナンス、リスクに応じた管理が重要な要素として扱われています。
必要なのは、承認をなくすことではありません。
承認品質を守りながら、承認のために仕事が止まっている時間を減らすことです。
「返信が早く、進めやすかった」が選定理由になった
ここから少し、開発工程ではなく、顧客との仕事を見てみます。
ディーシステムでは、過去のコンペ終了後、顧客へ選定理由を確認したことがあります。
その際、最初に挙げられたのが、
「返信が早く、進めやすかった」
という趣旨の評価でした。
もちろん、返信の速さだけで選定されたという意味ではありません。技術、提案内容、価格、体制など、複数の要素があったはずです。
それでも、応答の速さが顧客の記憶に残る評価だったことには意味があります。
顧客から見ると、仕事の途中にはいくつもの「待ち」があります。
相談を送ったが、届いているのか分からない。確認すると言われたものの、いつ回答されるのか分からない。対応可能なのかも、次に何が起きるのかも見えない。
こちら側では調査していたとしても、相手から見れば、仕事が止まっているように見えることがあります。
反対に、
「確認しました。担当者へ確認を始めています」
「この一点だけ追加で確認させてください」
「現時点では判断できないため、今日中に○○まで調べます」
と返せば、まだ結論が出ていなくても、次の行動が始まったことは分かります。
サービス品質の研究でも、Responsiveness、つまり顧客の依頼や問題へ迅速に対応することは、品質を構成する要素の一つとして扱われています。
顧客にとって、こちらが何時間作業したかより、「いつ次へ進めるのか」が重要な場面があります。
相手を待たせないことも、仕事の品質です。
「電話してほしい」に、いつ電話するか
現在進行中のプロジェクトでも、似た場面があります。
顧客側の担当者とチャットでやり取りしている中で、
「電話してほしい」
と連絡が来る。
その場合、確認できれば、その場で電話するという動きが行われています。
ここで重要なのは、電話という手段そのものではありません。
次の定例会議まで寝かせず、必要なコミュニケーションを始めることです。
もちろん、その場で答えを出せないことはあります。
状況を聞かなければ判断できない。社内へ確認する必要がある。責任者の判断が必要になる。
それでも、確認を始めることはできます。
ここでは、「即答」と「即応」を分けて考えると分かりやすくなります。
即答は、その場で結論を出すことです。
即応は、受け取ったことを伝え、必要な確認を始め、次の人へつなぎ、次に何をするのかを決めることです。
すべてに即答する必要はありません。必要なのは、次の行動を始めるまでの時間を短くすることです。
判断時間そのものをゼロにする必要もありません。
判断を雑にしてはいけない仕事もあります。
減らしたいのは、判断を始めるまで何も起きていない時間です。
急な人員相談で重要だったのは、「探す速さ」より「探し始める速さ」
人員調整でも、同じ構造が見えます。
ディーシステムでは、大規模案件で追加人員について相談を受けた際、相談段階からすぐ候補者の探索を始めた事例があります。
必要なスキルを確認し、複数方面へ連絡する。候補となる人材を探し、社内のプロパー社員も含めて調整しながら、必要な体制を組めるか検討する。
こうした動きを、相談を受けたあと早い段階から始めました。
この事例で注目したいのは、「短期間で人材を集められた」という結果だけではありません。
いつ探し始めたか。
です。
来週の会議で検討する。月末に要員状況をまとめる。まず社内資料を作ってから相談する。
そうしている間にも、顧客側の必要時期は近づいていきます。
結論が出ていなくても、結論を出すための行動は始められます。
必要なスキルを聞き、候補へ声をかけ、社内の空き状況を確認する。不足情報があれば、顧客へ聞く。
問題解決の速度は、処理そのものだけでなく、着手までの時間でも決まります。
速さは、個人の性格ではなく組織の設計でも決まる
では、顧客から連絡が来たら、社員全員がもっと急いで動けばよいのでしょうか。
そういう話ではありません。
担当者本人が素早く動こうとしても、誰に相談すればよいか分からない。必要な情報へアクセスできず、小さな判断にも上司の許可が必要になる。
決裁者が誰か分からず、次の会議まで相談できない状態なら、仕事は止まります。
本人の努力では解決できません。
反対に、自分で判断してよい範囲が分かっていて、必要な情報を確認できる。
小さな判断なら現場で進め、大きなリスクだけ上位者へ上げる。迷ったときのエスカレーション先も決まっている。
そうした状態なら、行動開始までの時間を短くできます。
B2Bサービスの研究でも、顧客ニーズへ迅速に対応するため、現場の従業員へ日常的な判断権限を持たせるEmployee Empowermentが論点になります。
つまり、速さを個人の性格だけで考えると不十分です。
速さは、権限と情報の設計でも決まります。
「もっと早く返してください」と担当者へ求める前に、その担当者が次の一歩を自分で踏み出せる構造になっているかを見る必要があります。
小さい会社が速いのではない。「意思決定距離」が短い会社が速い
企業規模についても、同じように考えられます。
「大企業は遅い。中小企業は速い」
と整理するのは簡単ですが、実際にはそこまで単純ではありません。
大企業には、専門人材、資金、データ、ガバナンス、顧客基盤など、規模による明確な強みがあります。
一方、OECDでは中小企業が柔軟性や市場変化への反応性を発揮できる可能性も指摘されています。ただし、資金、人材、管理能力などでは制約もあります。
そこで、会社の人数とは別に、この記事では「意思決定距離」という見方をしてみます。
正式な学術用語ではなく、仕事の流れを見るための整理です。
たとえば、
顧客
↓
担当
↓
課長
↓
部長
↓
本部
↓
判断
という仕事があります。
一方で、
顧客
↓
担当
↓
判断できる人
で済む場合もあります。
ただし、階層が少なければ必ず速いという意味でもありません。
小さな会社でも、誰が決めるのか分からなければ止まります。必要な情報が共有されていなければ、判断できません。
反対に、大きな組織でも、権限と基準が明確なら、すべての案件を経営層まで上げる必要はありません。
見るべきなのは会社の人数より、必要な情報が、実際に判断できる人へ何段階で届くのか。
です。
AIによって処理距離が短くなっても、意思決定距離が長いままなら、会社全体は速くなりません。
小さいこと自体が競争力なのではありません。
短い意思決定経路を、本当に仕事の速度へ変えられることに意味があります。
AI導入で見直すべきなのは、ツールだけではない
AI導入の成果として、
「資料作成時間を50％削減した」
「コード生成時間を70％削減した」
「調査時間を3時間から30分へ短縮した」
といった数字は分かりやすく、重要です。
ただ、その数字で終わらせず、仕事がどこまで進んだかを見てみます。
資料作成時間が半分になった結果、提案書は何日早く顧客へ届いたでしょうか。
コードを1日で生成できた結果、本番反映日はどれだけ早くなったでしょうか。
障害原因の候補をAIがすぐに出した結果、実際の対応開始はどれだけ早まったでしょうか。
AI導入後には、次のような区間を見る方法もあります。
ここまで見ると、「AIを入れたのに思ったほど全体が速くならない」理由も探しやすくなります。
AIへ高速な処理能力を与えるだけでなく、その結果を会社の次の行動へ高速につなぐ仕組みが必要です。
AIの速度を、会社の速度へ変えられるか
AIによってコードを書く時間や、資料を作る時間が短くなれば、その分だけ会社も速くなる。
そう考えたくなります。
しかし、顧客が待っているのは、コードを書いている時間だけではありません。
返事を待つ。必要な情報が集まるのを待つ。判断やレビュー、承認を待つ。作業が始まり、本番へ反映されるのを待つ。
作る時間が短くなるほど、こうした時間の割合は相対的に大きくなります。
だから、AI導入後に見るべきなのは「何時間削減できたか」だけではありません。
仕事がどこで止まっているのか。
誰が判断するのか。
現場で決めてよい範囲はどこまでか。
どの判断だけを上へ持っていくのか。
必要な情報は、判断できる人へすぐ届いているか。
そして、顧客が待つ時間は実際に短くなったのか。
そこまで含めて、会社の仕事の流れを見直す必要があります。
AIが会社へ与える速度を生かせるかどうかは、どのモデルを導入するかだけでは決まりません。
その処理結果を、判断と次の行動へどれだけ早くつなげられるかにも左右されます。
AIが速くするのは「作業」。会社を速くするのは「流れ」。
次に読む記事
AIで短くなった作業の先に、どれだけ「待ち」が残っているのか
一つの作業が速くなっても、レビュー、確認、承認、担当者への引き渡しで仕事が止まれば、全体のリードタイムは大きく変わりません。
仕事が始まってから終わるまでの時間を、「作業」と「待ち」に分けて考えます。
その仕事、本当に一週間かかりますか。仕事を遅くする「待ち時間」の正体
公開URL
AIが「作る」ようになったあと、人には何が残るのか
文章、コード、資料などをAIが短時間で作れるようになるほど、人には目的を定め、条件を整理し、出力を評価し、次の判断へつなげる仕事が残ります。
AI時代に、人が設計すべきものを考えます。
AIが「作る」時代に、人は何を設計するのか
システムそのものの複雑さは、会社の速度へどう影響するのか
AIによって一つひとつの処理が高速になっても、システム間の依存や変更範囲が複雑であれば、確認やテスト、調整には時間がかかります。
AI時代に、シンプルなシステムが持つ意味を考えます。
シンプルなシステムを、AI時代の競争力に変える
参考資料
DORA｜Streamlining Change Approval
