ぼくはITコンサルタントとして、同じ会社に16年在籍しています。
「AIを使いこなせれば生き残れる」というのが、いまコンサル業界でいちばんよく聞く言葉です。でもぼくから見ると、これは問いの立て方がずれています。問題はスキルではなく、ビジネスモデルそのものが崩れているかどうかです。今回は、その話と、これから書いていく連載の目録を整理します。
16年、転職しなかった#
16年、ぼくはITコンサルタントを続けてきました。業界としては珍しい長さです。
転職しなかったわけではなく、しないで済んでいる、というのが正確なところです。仕事に愛着があり、毎年違うクライアントと違う問いに向き合えてきたので、外に出る理由を作る必要がなかった。
ただ正直に言うと、この事実は感度が鈍くなっていた証拠でもあります。外から揺さぶられる経験が少ない分、変化の速度感覚が甘くなる。
そのぼくが、ここ1〜2年で「ヤバい」と感じています。担当するクライアントの中に、テクノロジーリテラシーが高い業種が複数あります。そこで起きているのは、旧来型のコンサル支援案件のパイプラインが急速に細っているという現象です。スキルの問題ではありません。「AIで自分たちでできる」と判断された領域から、案件が消えています。
「ITコンサル AI 仕事術」では答えにならない理由#
これはコンサルタントだけの話ではありません。
「専門性を磨いて、クライアントにフィーをもらう」——この構造で成立しているB2Bビジネス全体が、同じ揺さぶりを受けています。弁護士、税理士、フリーランスのマーケター、採用コンサル、デザイン事務所、エンジニアリング顧問。形は違っても「専門家の時間と知識を売る」モデルは共通です。
AIが壊しているのは、その共通の土台のほうです。
「専門性」の希少性が下がるとき#
専門家ビジネスの価値源泉は、「クライアントが持っていない知識・判断力を提供すること」にあります。情報の非対称性と、習得コストの非対称性——この2つが、フィーの正当性を支えていました。
AIはこの非対称性を急速に縮めます。クライアントが自力で調べ、自力で問いを立て、自力で叩き台を作れるようになる。専門家に頼む前に「AIで試してみる」が当たり前になったとき、頼む理由の閾値が下がります。
既存のAI論はほぼすべて、「スキルアップで生き残れ」という結論に収斂しています。「AIを部下にせよ」「プロンプトを磨け」「AIが苦手な人間的スキルで差別化せよ」——どれも間違いではありません。でもぼくは、それが答えだとは思っていません。問いがスキルではなく、ビジネスモデルの側にあるからです。
クライアントが学んだとき、コンサルは何になるか#
「問いの立て方」はコンサルの核心スキルだとされています。確かにそうです。でもクライアント側がAIを使って自力で問いを立てられるようになったとき、コンサルは何になるでしょうか。
ぼくの観察では、2つのパターンが見えています。
1つ目は、「念のためのセカンドオピニオン」です。コンサルはもはや主役ではなく、クライアントが自分で出した結論を確認する相手になる。安心のための外付け機能です。
2つ目は、「スケープゴート」です。AIを使って自分たちで意思決定をしたが、うまくいかなかったとき、「専門家に確認してもらった」という免責の証拠としてコンサルが使われる。ぼくにはこちらが、よりリアルな未来に見えます（詳しくはこちらの記事に書いた）。
どちらも、コンサルが「主体的な価値の提供者」ではなくなっています。クライアントの習熟速度が上がるほど、この構造は加速します。
フィーモデルが崩れる前に変えるべきもの#
Time & Material（稼働時間×単価）モデルが前提として成立してきたのは、「プロが時間をかけないと出せない成果物」があったからです。
AIはこの前提を壊します。半日かかっていた調査が数十分になる。1週間かかっていたドキュメント構成の叩き台が数時間で出る。効率化すればするほど、T&Mモデルは自分たちの首を絞めます。
「でも品質が違う」という反論はあります。ぼくもそう思っていました。ただ、クライアントがその品質差を見抜けなくなってきているのが現実です。見抜けない差は、市場では差ではありません。
フィーモデルをバリューベースや成果報酬型に切り替える方向は正しいと思っています。ただしそれは、「コンサルが出した成果でクライアントの事業が変わる」という関係を先に作らないと意味がありません。モデルだけ変えるのは、ただのリスク転嫁です。
2017年のぼくへ#
ここまで書いてきたのは「今の話」です。でもぼくが本当に考えさせられたのは、過去の自分と対峙したときでした。
2017年7月、ぼくは「新規プロジェクトをアサインされたら最初に3冊読む」という記事を書きました。インプットの速度と質を上げるための、当時のぼくの仕事術です。
今なら同じことを、Deep ResearchとAIの読み込みで数十分でできます。
「3冊読む」に費やしていた数日間は、ぼくにとって「準備の誠実さ」のような感覚がありました。時間をかけることが、真剣さの証明でもあった。でも今の視点から振り返ると、それは「ぼくの作業時間を売っていた」だけでもあります。
知識を蓄積するプロセスに価値があった時代は、終わりました。問いが立てられ、構造が見え、判断できること——そこにしか価値は残っていません。2017年のぼくに言えるとしたら、「もっと早く手を動かせ」です。
そしてこの「書き直し」を、過去記事1本だけでなく、ITコンサルとしての仕事術全体でやろう、というのが連載の主旨です（経緯は以前の記事に書いた）。
連載でやること：レイヤー別リバイブ目録#
連載でぼくが書き直していくのは、ITコンサルとして16年積み上げてきた仕事の形そのものです。
書き直しの単位は5つのキャリアレイヤー。それぞれを2つのアプローチで整理します。マトリクスの軸を、先に共有しておきます。
マトリクスの読み方：縦軸はキャリア、横軸はアプローチ#
このマトリクスは、縦軸と横軸でできています。
縦軸は、キャリアレベル。ジュニアコンサルタント／シニアコンサルタント／マネージャー／シニアマネージャー／ディレクターの5段階です。日本のコンサルティングファームで一般的に使われる職位を採っています。
横軸は、アプローチの2タイプ。
- Efficiency（既存業務の強化） いまの仕事のやり方を維持したまま、AIで速く・安く・品質高く回す
- Transformation（AIネイティブな再定義） AIがあることを前提に、仕事の前提・成果物・関係性そのものを再定義する
EfficiencyとTransformationは、二者択一ではありません。「どちらに重心を置くか」のグラデーションです。
ぼくの当面のフォーカスはEfficiency側に置きます。AIネイティブとして即効性を出せるのは「QCDバランスの破壊」、つまり従来の半額以下のコストで圧倒的なスピードと品質を出すことだからです（詳しくはこちらの記事に書いた）。
ただし賞味期限は約2年と見ています。クライアントのAIリテラシーが追いついた瞬間、Efficiencyの差別化は消えます。だからこそ、各レイヤーで Transformation 側に何を仕込むかが、連載の本丸になります。
5レイヤーで書き直す内容#
縦軸の5レイヤーについて、それぞれ「役割」と「Efficiency／Transformationで書く中身」を一言ずつ整理します。連載各回の予告でもあります。ただし、これはあくまで現時点の案です。書き進める中で順序や内容は変わります。
ジュニアコンサルタント：記録係から「文脈の理解者」へ#
役割は、指示されたタスクをQCDを守って完遂すること。「自走できる新人」のレイヤーです。
Efficiency側は、議事録の自動要約、デスクトップリサーチの高速化、スライド構成のドラフト生成、課題ログの自動抽出といった作業時間そのものの圧縮。
Transformation側は、役割の主語そのものが変わります。議事録を作る人から、論点が成立しているかを判断する人へ。データを集める人から、仮説の前提条件を設計する人へ。スライドを作る人から、読み手が何を決めるべきかを設計する人へ。AIが「同じ成果物」を出してくれる前提に立ったとき、人間に残るのは「何を作るべきかを定義する側」です。
シニアコンサルタント：レビュアから「ジャッジの設計者」へ#
役割は、小チームを率いてメンバーのQ/C/Dとアウトプットに責任を持つこと。「自分一人」から「チームの総和」に責任範囲が広がるレイヤーです。
Efficiency側は、進捗の自動集計、誤字脱字や形式チェックの自動化、テンプレートからの提案ドラフト生成、過去事例の高速検索。
Transformation側は、レビューや育成の「主体」がAIに移ります。自分でレビューする人から、レビューの視点と基準を設計する人へ。ジュニアに直接教える人から、自分の思考パターンをプロンプトとして資産化し配布する人へ。提案書を作る人から、AIが生成した複数シナリオの中で最適解を選ぶ人へ。「自分が優秀であること」ではなく、「自分の判断構造を組織のアセットに変えること」が価値の中心になります。
マネージャー：調整役から「プロジェクト経営者」へ#
役割は、Q/C/Dに加えてF（収支）とP（人）の最大化に責任を持つこと。プロジェクトをひとつの事業として経営するレイヤーです。
Efficiency側は、実績工数からの収支予測の自動化、評価シートの下書き生成、勤怠異常の検知、過去トラブル事例の高速検索。
Transformation側は、管理から判断への主語の移動です。数字を管理する人から、何に投資するかを決める人へ。人を評価する人から、一人ひとりの成長軌跡を設計する人へ。自分の判断で決める人から、AIに反対論者を演じさせて確証バイアスを外から検証した上で決める人へ。「調整」をAIに預け、自分の時間は「投資判断」と「人の成長設計」だけに使い切るレイヤーです。
シニアマネージャー：監視者から「事業の開拓者」へ#
役割は、複数案件の横断統治、エグゼクティブ・リレーション、新規ドメイン開拓。担当範囲が一気に5〜10倍に広がるレイヤーです。
Efficiency側は、全案件のダッシュボード自動集計、競合分析の自動化、契約書の自動レビュー、エグゼクティブ向けサマリーの自動生成。
Transformation側は、役割の主語が大きく書き換わります。複数案件を監視する人から、どの案件が火を噴くかを先読みして予防介入する人へ。顧客のニーズに応える人から、顧客が気づいていない課題を先に定義して持ち込む人へ。組織を作る人から、AIを前提にした職位・役割・評価の定義そのものを設計する人へ。情報処理はAIに完全に外注し、自分の時間は「判断」と「先回りの問いの設計」だけに使う、というシフトです。
ディレクター：完成形がない、リアルタイムの試行錯誤#
役割は、組織能力の再定義と、市場への新たなアドレス方法の設計。
ここだけは、完成された手法を整理する場ではありません。いま試みているのは、自社のナレッジと提案事例をAIで体系化して新規提案の初速を上げること、連載や登壇コンテンツをAIで二次活用して商談の問いに即答できる状態を作ること、RFP回答の初稿をAIに任せて自分は「この案件でしか出せる強みの設計」に集中すること——どれも派手ではありませんが、現在進行形の実験です。
「AIが正解を出す時代に、クライアントがディレクターに1時間数百ドルを払う最後の理由は何か」——この問いに、リアルタイムで答えを書いていきます。
連載の重心と最終目標#
連載の重心は、最初は Efficiency 側に置きます。ジュニア・シニアレイヤーから順に、過去記事をBeforeとして引用しながら書き直していきます。
そのうえで2年以内に、Transformation 側——脱・人月商売、事業オーナーとしての視座、AI前提の次世代オペレーションモデルへの移行——にぼく自身が踏み込み、その記録を書きます。
「どのレイヤーのどの話を先に読みたいか」、フィードバックがあれば順序を変えます。
まとめ：リブートは、業界への愛着の表明#
「コンサルタントはAIで要らなくなる」とぼくは感じています。そしてそれが嫌だから、書き直しています。
サバイバルのために書いているのは本当です。でもそれだけではなく、16年かけて積み上げてきた仕事の形を、「AIが来たから解体する」ではなく「AIを前提に再構築する」という形で残したい、という愛着が根っこにあります。
あなたが今の仕事に感じている違和感は、何でしょうか。スキルの問題でしょうか、それともビジネスモデルの問題でしょうか。ぼくは後者だと思っています。
