はじめに
技術本部VPoEの大曽根です。
生成AIは月数千円から誰でも使える環境になってきています。
同じツールを他社も使う前提では、AIによる速度の優位は構造的に長続きしません。本当に問われているのは、AIを使って業務・役割・組織の構造そのものをどう変えるか—つまり「効率化」ではなく「変革」です。
社内でAI活用を推進してきた中で整理した「効率化と変革の違い」「変革のための考え方」「変革を担う人員要件」「自分の取り組みを振り返る問い」を、実践事例を交えてまとめました。
AIを活用して価値創出を目指すなかで何かの参考になれば嬉しいです。
なぜ「効率化」では足りないのか
効率化には限界がある：「同じ構造の延長」でしかない
効率化とは、既存の業務フローを前提としたまま処理速度を上げることです。短期的なコスト削減には寄与しますが、事業の構造的な競争力にはつながりません。
過去の技術革新でも同じパターンが繰り返されています。
- Excelの登場
- 手作業の集計が速くなりました。しかし、経営管理の設計を変えた企業だけが、データドリブンな意思決定を実現しました。
- クラウドの普及
- サーバー管理コストが下がりました。しかし、ビジネスモデルを再設計した企業だけが、新しい市場を獲得しました。
AIも同様に、効率化に使うだけでは「コストが下がる」で終わってしまいます。
変革（＝変える）とは：「何にリソースを使うか」を再配分する
AIが処理・情報整理・定型判断を担えるようになると、人間のリソースをどこに集中させるかを再設計できます。これは単なる生産性向上ではなく、組織が生み出せる価値の構造が変わることを意味します。
| 観点 | 効率化止まり | 変革した場合 |
|---|---|---|
| 人員配置 | 同じ仕事を少ない人数でこなす | 人間にしかできない領域に人を再配置する |
| 意思決定 | 判断のスピードが上がる | 判断できる人の範囲・階層が変わる |
| 競争優位 | コスト構造が改善する | 競合が模倣しにくい業務・組織設計ができる |
「効率化」と「変革」はどう違うのか
効率化と変革の差はこうなると捉えています。
| 軸 | 効率化 | 変革 |
|---|---|---|
| 問い | 今の仕事をどう速くするか | その仕事が必要かを問い直す |
| 主語 | 個人・担当者 | 組織・役割・プロセス設計 |
| 結果 | 同じアウトプットが早く出る | アウトプットの定義が変わる |
| 人の変化 | スキルアップ | 役割・人員構成・責務が変わる |
取り組み例
社内のAI活用推進の一環として、エンジニアではないビジネス職メンバーがClaude Codeを使って業務支援の仕組みを開発するという試みを進めています。
ビジネス職のメンバーが、営業管理のダッシュボードを、Claude Codeを使って開発しました。
このダッシュボードは定量数値だけではなく、営業議事録の文字起こしや社内Slackのコミュニケーション内容を生成AIを介して自律的に情報を構造化集約する仕組みになっています。
効率化との違いはどこか
これは「Claude Codeで開発が速くなった」という話ではなく、そもそも、これまでであれば「エンジニアに依頼するか、外注するか、手運用でなんとかするか、諦めるか」の四択だった業務改善が、ビジネス職本人の手で完結していることです。
ここから読み取れる変革の構造は3つあります。
① 「依頼ベース」の業務構造が変わった
従来、業務システムの改善は「ビジネス側が要件を出す → エンジニアが作る」という構造でした。これだとエンジニアの稼働がボトルネックになり、優先度の低い改善は中々着手されません。
Non-devメンバーが自力で作れる構造になると、当事者の優先度で実行できるようになります。
② 「現場の課題理解」と「実装」が同じ人になった
これまでの開発構造の場合、要件のすり合わせに一定の時間がかかり、現場の暗黙知が抜け落ちるようなケースがゼロではありませんでした。
現場理解と実装を同じ人が担えるとフィードバックループを短く・高頻度で回すことができます。
③ ビジネス職の「できることの定義」が変わった
これまで「業務改善のアイデアを出す人」だったメンバーが、「業務改善を自力で実装する人」に変わりました。これはスキルアップではなく、役割の拡張と捉えることができると考えています。
ただし、「作れた」だけでは変革にならない
「Non-devがダッシュボードを作れた」というだけでは、変革としては不十分です。
ダッシュボードが「営業の状況を可視化するツール」として置かれているだけなら、それは従来の業務改善の延長線にすぎません。BIツールでダッシュボードを作るのと本質的に変わりません。「作る人が変わった」だけで、業務そのものは変わっていません。
変革として完成させるためには、その先に少なくとも2つの段階があると捉えています。
段階A：AIによる自律的な情報収集・可視化
ダッシュボードに表示するデータを、人が手で集める・整形する状態から、AIが自律的に収集・整理・更新する状態にシフトすることです。さらに進めれば、「この案件は失注リスクが高い」「ここに介入が必要」といった判断の手前までAIが提示する状態を目指し、ダッシュボードは「見るもの」から「動くべき場所を教えてくれるもの」に変わります。
段階B：業務プロセスへの組み込み
ダッシュボードが「営業会議の議題」「マネージャーの介入トリガー」「営業担当者の日次行動の起点」として業務に組み込まれる状態にします。
たとえば——
- 営業会議が「全案件を順にレビューする会」から「AIが検出したリスク案件だけを議論する会」に変わる
- マネージャーの1on1が、状況確認ではなく「AIが提示した介入ポイント」を起点にした対話に変わる
- 営業担当者の日次行動の優先度が、AIが算出したシグナルに基づいて決まる
ここまで来てはじめて、仕事のやり方そのものが変わったと言えると思います。ダッシュボードはツールではなく、業務プロセスの一部になります。
この事例が示すもの
つまり、変革には3つの段階があると整理できます。
| 段階 | 状態 | 評価 |
|---|---|---|
| 1. 作れる | Non-devが自力でダッシュボードを作れる | 役割の境界が溶け始めた |
| 2. 自律化 | AIが情報を自律収集・可視化・判断補助する | ツール自体が能動的になった |
| 3. 業務統合 | 会議・行動・意思決定の起点になる | 業務プロセスが組み変わった |
変革を起こすための5つの考え方
1. 「速くする」より先に「なくせないか」を考える
AIを使う前に、まず「その業務、そもそも必要か」を問うこと。「毎月やっているから」「昔からあるから」という理由で続いている業務は、AIで速くするのではなく、なくせる可能性があります。
2. 「情報の独占」を解体する
「これはAさんに聞かないとわからない」という属人化の構造は、組織の最大の非効率の一つです。AIは情報の整理・検索が得意なので、ここを解体することが変革の入り口になります。
3. 「処理」と「判断」を分離し、人間は判断に集中する
仕事を分解すると「処理（情報収集・整理・定型処理）」と「判断（何をすべきか決める）」に分けられます。AIが処理を担う前提で、人間の役割を判断に集中させる構造を作ります。
4. 「職種の境界」を意図的に溶かす
「この仕事はエンジニアしかできない」「これは法務じゃないと無理」といった前提の多くは、AIによって崩れつつあります。変革とは、この越境を例外ではなく前提として組織を設計し直すことです。
5. やり方だけ変えても、仕組みを変えないと定着しない
業務のやり方をAIで変えても、評価軸・役割定義・チーム構成が変わらなければ、変革は現場の工夫で止まります。AIを前提とした業務には、AIを前提とした制度・体制がセットで必要になります。
セルフレビュー：自分の取り組みは「変える」になっているか
自身のAI活用が効率化止まりか、変革に向かっているかを判断する「問い」でセルフレビューすることも1つの有用な手段と考えています。
着手前に問う
- その仕事、そもそも存在していていいか？
- 誰の役割や仕事の定義を変えようとしているか？
- 「工数削減」を目的にしていないか？
設計中に問う
- AIを外したとき、プロセスは元に戻るか？戻るならAIは補助ツールにすぎない
- 「あの人しか知らない」情報を解体しようとしているか？
- 影響が「担当者1人」で閉じていないか？
- やり方は変わるか？「手順は同じで人が減っただけ」になっていないか
- 「誰が何を決めるか」が変わるか？
- 責任の持ち方を再設計しているか？
- 体制・チーム構成を変える必要が出てきているか？
実行後に問う
- 誰かの仕事の「中身」が変わったか？
- 評価軸・役割定義を変える必要が生まれたか？
- 「やめたこと」があるか？トレードオフのない変革はない
終わりに
AIによる効率化は「やって当たり前」のラインになっていると思っています。
これからの差は、AIを前提に組織・役割・業務をどこまで再設計できるかに移っていると感じています。
常に問い続けながら、チーム・個人でAI活用による価値最大化＝変革を目指していきたいと思います。
ギフティでは AI ツールを活用した価値創出・開発生産性向上を積極的に進めています。興味のある方はぜひお声がけください。
