- 人数の少ない競合が勝つのは、人を大胆に減らしたからではなく、1人ひとりがより多くの成果を出せるよう仕事を設計したからです。
- 注目すべき数字は、1人あたりの売上と、仕事1件あたりのコストです。社員数だけを見ても、多くはわかりません。
- まずは自社の実際の業務プロセスを測ることから始めます。人を減らす話は、まだ考えなくて構いません。
1. 2028〜2029年の競争の姿
「半分の人数で回す」という言葉は、実際より恐ろしく聞こえます。すべての会社が社員の半分を解雇しなければならない、という意味ではありません。自社では人が6回手をかける仕事を、競合は1回で済ませているかもしれない、という意味です。競合はその差を、値下げや、より早い顧客対応に回せます。
今後2〜3年で、AIツールは指示を待つアシスタントから、仕事を継続的に引き受け、さまざまなデータやツールを呼び出し、例外だけを人に回すシステムへと変わっていく可能性が高いでしょう。ワークフローを前もって設計しておいた会社は、売上の伸びより緩やかなペースで人を増やしながら、処理量を拡大できます。従来型の会社は、売上が伸びるたびに、事務スタッフ、調整役、管理職を増やし続けることになります。
「半分の人数」が表しているのは、取引1件あたりにかかる人の手作業(Human Touch)の差です。これまでは人がメールを開き、データをコピーし、書類を作り、承認を求め、システムを更新していた仕事でも、人が確認するのは全体の10〜30%で済むようになるかもしれません。競合が先にそこに到達すれば、その差を値下げ、サービスの追加、新規顧客の獲得への投資に使えます。
2. 競争の差は、ツールの契約よりも仕組みから生まれる
同じツールを買った2社で結果が違うのは、よくあることです。1社目では、社員が必要なときにAIに質問し、答えを自分でシステムにコピーし直しています。もう1社は、データがシステム間で自動的に流れるように整えています。差を生んでいるのは、仕事の組み立て方です。
2つの会社が同じAIモデルを使っても、結果が異なることがあります。1社目では、社員がその都度AIに質問し、答えをシステムに書き写します。2社目には、共通のデータ、業務ルール、ワークフロー、監視の仕組みがあり、AIが繰り返しの仕事を一日中引き受けられます。両者を分けているのは組織のオペレーティングシステム、つまり仕事を回す仕組みです。プロンプトの上手さはほとんど関係がありません。

この差は複利のように積み上がります。ワークフローが動き出すと、会社にはフィードバックと例外の事例がたまり、システムが改善し、コストが下がり、チームには次の業務プロセスを設計する時間ができます。ばらばらに試しているだけの会社には、共有して学べるデータがありません。どの部門もゼロから始め、本当の仕事をAIに任せる踏ん切りがつきません。
もう1つは意思決定の速さです。報告書が自動で要約され、問題がすぐに通知されれば、経営層は価格、在庫、キャンペーンを早く調整できます。つまり優位性には、人件費の削減に加えて、問題の発見が遅れることによる損失の削減も含まれます。
3. 従来型の会社と、AIを前提とした会社の比較
| 観点 | 従来型の会社 | AIを前提に設計した会社 |
|---|---|---|
| 仕事の量が増えたとき | 人とチームリーダーを増やす | システムの処理能力と、例外を見る人を増やす |
| 顧客対応 | 順番待ちと営業時間に左右される | 定型の質問にはすぐ答え、難しい案件は人に回す |
| 書類 | 毎回手作業で作成・確認する | 共通のデータから作成し、抜き取りで確認する |
| 新製品 | 複数の部門と大きな予算を待つ | プロトタイプを早く作り、小さなグループで試す |
| 管理職 | 仕事を割り振り、進み具合を追いかける | 品質と例外を見て、ルールを調整する |
AIを前提とした会社は、人数を最小にする必要はありません。人は、信頼を築く仕事、判断が必要な仕事、新しいアイデアを生む仕事に充てます。顧客体験を損なわない限り、コストの低さは、全部門で一律に人を削るよりも長続きする強みになります。
4. 自社が取り残されるリスクを見極める
Lead-to-Quote(問い合わせから見積もりまで)、Order-to-Cash(受注から入金まで)、Issue-to-Resolution(問題の受け付けから解決まで)のような中核の業務プロセスを3つ選び、同じデータを何回入力しているか、引き継ぎ(Handoff)は何か所あるか、仕事の何%が定型的なケースか、社員が本当に判断に使う時間は何分かを確かめます。かかる時間の半分以上が検索、コピー、要約、受け渡しに使われているなら、自動化できる余地は大きいといえます。
データの仕組みも確認します。商品リスト、価格、契約、顧客履歴が個人のファイルに散らばっていると、AIで仕事をつなぐのは難しくなります。今のうちにデータとアクセス権限を整えておく会社ほど、技術が進んだときに新しいモデルを早く取り入れられます。
- 売上を10%伸ばすのに、人員もほぼ10%増やさなければならない
- 管理職が週に1日以上を、報告書の取りまとめと仕事の催促に使っている
- 顧客が、すでにシステムにある情報を待たされている
- AIのプロジェクトはいくつもあるのに、単位コストが実際に下がったことを示す数字がない
- データの責任者も、AIシステムの登録台帳もない
5. 今日から見直し始めるべき5つのこと
- 業務プロセスのベースラインを取る:重要なワークフローについて、処理量、作業時間(Touch Time)、待ち時間(Wait Time)、エラー、1件あたりのコスト(Cost/Task)を測ります。
- 正となるデータ(Source of Truth)をつくる:商品、顧客、方針、価格のデータを定め、それぞれに責任者と更新の周期を決めます。
- 1つの経路を最後まで自動化する:チャットボットを全部門にばらまかず、ROIがあり、結果を検証できるワークフローから始めます。
- 人が扱う例外を設計する:AIが処理するケース、人が引き受けるケース、そのSLAを決めます。
- 継続的な測定の仕組みをつくる:ダッシュボードでは、プロンプトの数を数えるだけで終わらせず、品質、コスト、スピード、顧客にとっての成果まで見えるようにします。
こうした準備は、技術が変わっても価値を失いません。業務プロセス、データ、ガバナンスは、世代の違う多くのモデルにそのまま使えるからです。AIが完成するのを待ってからデータを整えようとしてはいけません。その頃には、土台を整えた競合が何回も先に事業を広げています。

6. 慌てず、遅れすぎず、人員を計画する
職種ごとに、仕事のうちAutomate(自動化)、Augment(AIで補強)、Human-led(人が主導)がどれだけを占めるかで分類します。すぐに解雇する必要はありません。欠員が出ても補充しない、人を売上を生む仕事に移す、チームリーダーにシステムのキュー(処理待ちの一覧)の管理を教える、といった方法があります。処理能力に大きな余裕があるとデータが示したときに初めて、組織の構造について、透明性をもって判断します。

投資すべきスキルは、業務プロセスの設計、品質のチェック、データの活用、例外の判断、顧客への対応、そして現場の知識をシステムが使えるルールに変えることです。事業を理解し、AIを使いこなせる社員は、手作業を速くこなすだけの社員よりも、はるかに大きなレバレッジを発揮できます。
要員シナリオ(Workforce Scenario)を3通り用意します。AIによって効率が20%、40%、60%上がる場合です。それぞれについて必要な人数、新しい役割、リスキリングにかかる時間を計算します。こうしておけば、実際の効果が見える前に、縮小するかもしれない職種で長期の採用をしてしまうことを防げます。
7. 流行をすべて追いかけずに投資する
開発チーム向け · 技術的な詳細
投資をポートフォリオとして、Core Efficiency(中核業務の効率化)、Growth(成長)、Future Options(将来の選択肢)に分けます。Core Efficiencyには明確な投資回収の目標を置き、Growthはリード(見込み客)、コンバージョン、新製品に結びつけます。Future Optionsには限られた試験予算と判断の期日を設けます。どのプロジェクトにも、業務プロセスの責任者(Process Owner)と撤退基準(Exit Criteria)が必要です。
開発チーム向け · 技術的な詳細
実績のあるワークフローができる前に、大規模なプラットフォームのプロジェクトを始めるのは避けます。かといって、互いにつながらない個別のツールを作るのもよくありません。ID管理(Identity)、データへのアクセス、評価、ログ、コスト管理について共通の基準を決め、そのうえで各チームが同じ土台の上にユースケースを作っていきます。
8. 調整しながら進める3年間のロードマップ
1年目:中核のワークフローを測定し、2〜3件のユースケースを本番運用に乗せ、データとセキュリティの基準を整えます。目標は、証明できる事業上の成果と、それを再現できる中核チームです。

2年目:部門をまたいでワークフローをつなぎ、特定の業務に特化したエージェントを加え、役割と処理能力の計画を自動化された仕事に合わせて見直します。目標は、1人あたりの売上と、製品を市場に出すスピードをはっきりと伸ばすことです。
3年目:運営モデル(Operating Model)、価格設定、そしてAIによって可能になる新しい提案を見直します。たとえば一人ひとりに合わせたサービス、リアルタイムの対応、低コストの新製品などです。会社の組織構造は実際の成果をもとに見直し、従来の人員計画を前提条件にはしません。
まとめ:人数が半分の競合が先を行く理由は、削減の大きさより、全員がより多くの成果を出せるように設計された仕組みにあるのかもしれません。企業は業務プロセス、データ、測定から始め、要員シナリオを用意し、ポートフォリオとして投資するべきです。今日始めれば、価格とスピードの圧力が差し迫る前に、学ぶための時間を確保できます。
コスト面の優位を、測定できる仕組みに変える
自社のどこで時間が失われているかを知っているのは、営業や経理の責任者と、毎日その仕事をしている現場の人たちで、ソフトウェア会社にはわかりません。DNA Makerはコードを書く前に、そうしたチームと一緒に座り、顧客から連絡が来た瞬間から代金を回収する日までの実際のワークフローをたどって、同じデータを何回入力し直しているか、引き継ぎは何か所あるか、どんな案件が定型的なケースで、どんな案件は常に人の判断が必要かを確かめます。この段階でお渡しするのは見積書ではなく、経営者が自社の単位コストをよりはっきりつかめる業務フロー図です。
その後、私たちが一緒に形にすること
その業務フロー図をもとに、共通のデータを1つのワークフローにつなぐシステムを設計します。定型の仕事はシステムが継続して引き受け、例外だけを人のキューに回します。経営層が、仕事を受けてから納品するまでの時間と取引1件あたりのコストを毎週確認できるダッシュボードも用意します。私たちは必ず、効果を測定できるワークフロー1つから始めます。チームが実際に試せるプロトタイプ(試作版)を作り、ベースラインと比べて効果を測り、それから範囲を広げます。時間がかかっているとわかっていながら手をつけられずにいる業務プロセスがあれば、まずはその実際のデータを一度見せていただくところからご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
この記事の用語は、業務プロセスの測定とシステム連携に関するものです。予算を承認する前に、右端の質問を開発チームに聞いてみてください。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Workflow | 始まりから成果が出るまでの仕事の流れ。各段階の担当者と条件を明確にしたもの | 顧客が見積もりを依頼してから、見積書を発行し、値引きが承認されるまで | このワークフローは誰から始まり、誰で終わりますか?時間はどこで測りますか? |
| Handoff | 仕事が、ある人やチームから別のチームに渡される地点。順番待ちやデータの抜け漏れが起きやすい | 営業が経理にデータを送って価格を計算してもらい、返事を待つ | 引き継ぎを何か所減らせますか?残った引き継ぎにはどれくらい時間がかかりますか? |
| Cycle Time | 仕事が入ってから納品するまでの合計時間。実際の作業時間に加えて、待ち時間も含む | 見積書の実作業は40分でも、サイクルタイムは2日 | サイクルタイムはシステムで自動的に測りますか?それとも人が手で入力しますか? |
| Baseline | プロジェクトを始める前の基準となる数字。本当に改善したかどうかを比べるために使う | システム導入前の月の、見積書1件あたりのコスト | ベースラインがなければ、元が取れたかどうかをどう判断しますか? |
| System Integration | 既存のシステムどうしをつなぎ、同じデータを入力し直さずに受け渡せるようにすること | CRMと会計システムをつなぎ、価格が自動的に一致するようにする | 既存のシステムはどんな方法でつなげますか?つなげない場合はどうしますか? |
