AI によって、何かを「作る」コストは急速に下がっています。
コードを書く。資料を作る。情報を調べる。データを整理する。画面を作る。テストする。以前なら専門家が何日も、何ヶ月もかけていた仕事を、Codex や Claude のような AI と一緒に、短時間で進められる場面が増えました。
以前、noteで「開発会社に頼めば 1,000万円かかるものが、AI なら 3万円でできた」という話について書きました。
1,000万円 と 3万円が本当に同じ範囲を指しているのかは分けて考える必要がありますが、実装の値札が大きく変わり始めていること自体は間違いないと思います。
AI が強くなったことで、これまで高価だった「問題を解く能力」は、多くの人が利用できるものになってきました。
では、問題を解くことが安くなったとき、何が難しい仕事として残るのでしょうか？
長年コンサルとして企業の現場に入り、業務改善や DX、AI活用、システム設計、組織改善に関わってきた中で、私は強く感じていることがあります。
実際の会社では、「そもそも何が問題なのかが、最初から分かっていることのほうが少ない」 ということです。
会社が相談してくる「問題」が、本当の問題とは限らない
例えば、ある会社から 「人が足りない」 と相談されたとします。
本当に人手が足りないケースもありますが、業務を一つずつ紐解いて見ていくと、報告のための報告、確認のための確認、他部署へ渡すためだけの整形作業など、顧客価値につながらない仕事が積み上がっていることがあります。
この場合、採用だけを考える前に、業務そのものを減らせないかを考える必要があります。
「この業務を自動化したい」という相談も同じです。
システムを作ることはできます。
しかし、その業務が過去の経緯だけで残っているなら、
自動化するより 「なくしたほうがよい」 可能性があります。
「Aさんに仕事が集中している」という話も、Aさんの能力や人員配置だけの問題とは限りません。ルールや責任範囲が曖昧なために、誰も判断できない確認、部署間の調整、通常の手順から外れた例外処理が、責任感のある Aさんへ集まっているのかもしれません。
表面に見えている問題と、その問題を生んでいる構造は違います。
だから私は、依頼された問題をそのまま問題として扱わないことが大切 だと考えています。
相談内容を否定するのではなく、その説明が実態と合っているかを確かめる。確認した結果、最初の相談どおりの問題だったなら、その解決へ進めばよいのです。
会社は、自分自身のことを完全には説明できない
では、現場の人に詳しく話を聞けば、本当の問題は分かるのでしょうか。
実際にはそれほど簡単ではありません。
会社の中に情報がないわけではなく、さまざまな理由で、その情報が一つの説明になっていないからです。
知りすぎているから、説明できない
業務フローをヒアリングすると、「これを確認して、入力して、送るだけです」と説明されることがよくあります。
しかし、その「確認」の中には、いくつもの判断が折り畳まれています。
どの状態なら先へ進めてよいのか。必要な資料はそろっているか。誰の承認が必要か。通常と違う場合はどうするのか。何をもって確認済みとするのか。いつまでに処理する必要があるのか。
熟練者は、こうした判断を無意識に行っています。本人にとっては当たり前すぎて、それが独立した作業や知識だという認識すらありません。
知らないから説明できないのではなく、知りすぎているから説明できないのです。
聞き手にも、まだ問いがない
一方で、ヒアリングする側に業務知識がなければ、必要な質問そのものを思いつけません。
たとえば、「査定する」という説明を受けたとき、その中に真贋判定、付属品の確認、相場の参照、状態の評価が含まれていると知らなければ、どこを掘り下げればよいか分かりません。
これは、相手が答えてくれないという問題ではありません。
答えが出てこないのではなく、問いが立たないのです。
分かっていても、言いづらいことがある
現場によっては、認識していても説明しにくい事情があります。
実際にはルールどおり運用していない。ある部署との関係が悪い。過去の判断を蒸し返したくない。責任を負いたくない。抱えている業務量が、自分や部署の権威・発言力につながっている。
業務を整理することで、誰かの役割や権限が変わるなら、整理そのものに抵抗が生まれる場合もあります。一方で、問題を伝えても否定され続け、「言っても無駄だ」と説明を諦めている人もいます。
すべての会社で、誰かが意図的に情報を隠しているわけではありません。何を聞くかに加えて、誰が同席しているか、話した内容がどう扱われるか、実情を話せる関係があるかも関わってきます。
業務が整理されない理由は、単なる情報不足とは限りません。利害や責任、社内政治、人間関係も、実際の業務を形づくる要素です。
誰も、会社の全体を見ていない
営業は、営業から見た会社を知っています。管理部は管理部から見た会社を知り、現場担当者は日々の実務を知っています。経営者は数字と報告から会社を見て、システム担当者は仕様とデータを見ています。
それぞれの説明は、その立場から見れば正しいことが多いと思います。しかし、全員の話をつなげると、しばしば同じ業務について説明が食い違うことがあります。
そこで「誰の話が正しいか」を決めても、実態には近づけません。
見るべきなのは、なぜそれぞれの立場から見ると、その説明になるのかです。
情報も責任も部署ごとに分かれている会社では、誰かが全体像を持っているとは限りません。
問題発見の起点は、「問い」より前にある
AI 時代には、問題設定力や正しい問いを立てる力が重要になると言われます。私もそのようなことを言ってきました。
ただ、現場で問題を見つける過程を考えると、「問い」から始まるわけではありません。
問いを立てる前に、違和感があります。
「誰でもできます」と聞いていたが、実際には 1アクション目で詰まる。
「決まった手順です」と説明されたが、実際には担当者によって微妙に違う。
「確認するだけなのですぐです」と言われても、人によって処理時間が大きく違う。
「人が足りません」と言うけれど、売上・利益に関係ない作業が大量にある。
どれも説明と現象が一致していません。
この小さなズレを、「そういうものだ」と流さずに拾う。なぜ違うのだろうと仮説を持つ。その仮説があって初めて、「詰まるのは何が足りないのか」「担当者はどこで判断しているのか」「この確認は誰のために存在するのか」という問いが生まれます。
問題発見は会議室で突然賢い問いを思いつくことではありません。
現場を観察し、違和感を持ち、仮説を立て、問いに変える。
その問いをもとに、さらに事実を集めていく。
私はこの順序が重要だと思っています。
コンサルは、会社で本当に起きていることを「復元」する
以前、ある業務について、担当者から何度聞いても「目視で確認するだけです」と説明されたことがありました。
ところが、何度目かのヒアリングで、たまたま隣にいた別のスタッフが「でもあれ、時期で確認場所を変えていますよね」と言いました。その一言で、説明に含まれていなかった重要な条件分岐が初めて表に出てきました。
担当者が嘘をついていたわけではありません。本人の中では、その分岐まで含めて「目視で確認する」という一つの動作になっていたのだと思います。
このようなことは、現場では珍しくありません。
だからコンサルは、相手から完成した答えを聞き出しているわけではありません。発言だけでなく、実際の行動、資料、データ、システム、ルール、例外、人間関係、過去の経緯、そして説明との矛盾を突き合わせます。
「この会社では、本当は何が起きているのか」という仮説をつくり、追加のヒアリングや観察、資料、データで確かめていきます。
私は、この仕事を 「会社の実態を復元すること」 だと捉えています。
コンサルの価値は、最初から正解を知っていることや、フレームワークに当てはめることだけではありません。誰もまだ一つの構造として説明できていない会社の姿を、現場に散らばった断片から組み立て直すことにあります。
ただし、自分が組み立てた説明も仮説です。例えば、Aさんへの仕事の集中を「責任範囲が曖昧だからだ」と考えたとしても、担当者の熟練度や、扱う案件の難しさが違う可能性もあります。自分の仮説に合う話ばかりを拾わず、合わない事実が出たら説明を見直す必要があります。
調べることにも時間と費用がかかります。原因と対応範囲が明確な小さな修正まで、会社全体の調査に広げる必要はありません。判断を間違えたときの影響や、残っている不確かさに応じて、どこまで確かめるかを決めます。
外部の立場だから見えやすいことはあります。社内の常識に染まっておらず、部署を横断して話を聞きやすいこともあります。
ただし、外部であること自体が本質ではありません。
社内 PM、経営企画、事業責任者であっても、内部の常識をいったん脇に置き、複数の事実を横断して構造を見ることはできます。
大切なのは肩書ではなく、観察、違和感、仮説、問い、事実収集、構造化を往復しながら、本当に解くべき問題を定義する力です。
問題を見つけるだけでは、会社は変わらない
一方で、問題を発見し、AI で綺麗なスライド提案書にまとめただけでは現場は変わりません。
業務の流れを変える。役割と責任を決める。システムを作り直す。AI を業務へ組み込む。分散しているデータをつなぐ。現場の人に実際に使ってもらう。運用して、問題が起きれば直す。
例えば、Aさんへの判断依頼を減らすなら、誰がどこまで決めてよいかを合意し、通常の案件は担当者が進め、例外は適切な責任者へ回せるようにする。その流れに合わせてシステムを変えるところまでが、一つの改善になります。
正しいと思っていた設計も、現場へ入れると想定どおりには動かないことがあります。
説明された手順と実際の使われ方が違うこともあれば、設計時には見えていなかった例外が出てくることもあります。便利になる人がいる一方で、別の部署に負担が移ることもあります。
そのため、「問題発見」と「実装」は本来一度で終わる直線的な工程ではありません。
観察し、問題を定義し、再設計して、実装する。そして使われ方をもう一度観察し、必要なら問題の定義から見直す。この循環を回して、ようやく仕組みが現場になじんでいきます。
FDE は、問題発見から実装までをつなぐ人
最近、AI の領域で FDE（Forward Deployed Engineer）という職種が注目されています。
企業によって役割の範囲は異なりますが、私が重要だと感じているのは、「何を作るべきか」が完全には分かっていない現場へ入り、問題を発見し、それを実際に動く仕組みまで持っていくという職能です。
顧客の要望をそのまま仕様に変換するのではなく、現場を見て、本当に解くべき問題を探す。必要なものを作り、導入し、使われ方を観察する。そして、うまくいかなければ設計し直す。
この、作る、導入する、観察する、再設計するという循環は、私がコンサルとして行ってきた問題発見や業務・システムの再設計ともつながっています。問題を発見して提案することと、動く仕組みを現場へ持ち込むことを、一続きの仕事として捉える点に共通するものを感じます。
もちろん、すべてのコンサルが FDE になるわけでも、FDE だけがこの仕事をできるわけでもありません。FDE は、AI 時代に起きている価値の移動を分かりやすく表している、現在の職能の一つです。
実装が安くなるほど、問題発見と現場実装の価値が上がる
以前は、システムを作ること自体が高価でした。何百万、何千万、それ以上。
そのため、課題を整理する人、要件を決める人、設計する人、実装する人、導入する人へ工程を分けることには、大きな合理性がありました。
しかし、AI によって実装のコストと時間が下がると、ボトルネックは少しずつ前後へ移ります。
「どう作るか」だけでなく、「何を作るか」。さらに、「本当にそれを作るべきか」「現場で使える状態までどう持っていくか」が、プロジェクトの成否をより大きく左右するようになります。
ここで重要なのは、「AI には現場が分からないから、結局は人間が必要だ」という話ではありません。
AI は今後も進歩し、要件整理や業務分析、設計、テスト、導入支援まで、いま以上にさらに多くの工程を担うようになると思います。
ただ、推論の精度が上がることと、判断に必要な事実がそろうことは別です。先ほどの「時期で確認場所を変える」という分岐も、別のスタッフの発言によって初めて説明に加わりました。人間も、一度のヒアリングだけでは見落とします。
何を観察し、誰に聞き、どの記録と突き合わせるか。AI に文脈を伝える手前には、その文脈を見つけ、確かめる仕事があります。集める事実が変われば、AI と検討できる内容も変わってくるからです。
さらに、試作や修正を短時間で進められれば、現場で得た仮説を動くものにして確かめ、観察した結果を次の設計へ戻しやすくなります。
何を作るかを考えた人やチームが、この往復にも関わることで、最初に抱いた違和感や設計の背景を修正までつなげられます。
実装が安くなるほど、問題発見と現場実装を横断できる人の価値が上がります。
FDE が注目される背景には、単なる新しい職種の流行ではなく、この構造変化があるのではないかと私は見ています。
人間が担う「問題発見」とは何か
では、AI が問題を解ける時代に、人間は問題をどう見つけるのでしょうか？
少なくとも現場では、問題設定とは、与えられた情報だけを見ながら、会議室で正しい問いを考えることではありません。
現場へ行く。人の話を聞く。実際の動きを見る。資料とデータを確かめる。表向きのルールと実運用のズレを見る。誰も気に留めていない例外を見る。部署ごとの説明をつなぐ。過去の経緯や責任の所在、人間関係まで含めて、「なぜこの運用になっているのか」を考える。
その大量の事実の中から、「何かがおかしい」を見つける。
そして、その違和感を仮説へ変え、検証できる問いにしていくことです。
そのために、説明を聞いた後で、実際の作業も見せてもらう。
「確認するだけ」と言われたら、何を見ているかを声に出しながらやってもらう。
手が止まった場所や、別の画面を開いた瞬間が、次に聞く手掛かりになります。
通常の手順に加えて、「うまくいかなかったのは、どんなときですか」と聞けば、普段は説明されない成功の条件が見えてきます。
「明日から新人に任せるなら、最初に何を教えますか」という聞き方も、本人が省略していた前提知識を引き出す助けになります。
書類やデータがどこから来て、誰の手を通り、どこへ渡るのかを追う方法もあります。担当者の説明だけでは見えなかった、部署の間の作業を確かめられます。
こうすれば必ず問題を見つけられるわけではありません。それでも、一つの説明を実作業、資料、データ、別の人の説明と突き合わせることで、ズレに気づく機会はつくれます。
そこから仮説を立て、問いを具体化し、事実を集め直す。
問題を定義して実装した後も、使われ方を見て確かめる。
最初の仮説が外れたなら修正が必要ですし、余計な負担を生んだなら、その負担にも対応しなければなりません。
ここまでは、方法の話です。
しかし実際には、もう一つ難しいことがあります。問題がまだ問題として共有されていない段階では、その違和感を持っている人が、自分だけかもしれないということです。
問題が共有されるまでの孤独な時間
私はこの仕事を、非常に孤独な仕事だとも感じています。
すでに問題として共有されていることなら、「どう解決するか」を一緒に考えられます。
しかし、問題がまだ問題と呼ばれていない段階では、自分が感じている違和感を、周囲も感じているとは限りません。
「今までこれで回ってきた」
「そこまで調べる必要があるのか」
「それは必要ないでしょ」
「そこまで頼んでないんで」
そう受け止められれば、調べるための時間も、変えるための協力も、簡単には得られません。
こちらは問題を見つけようとしていても、周囲には、わざわざ仕事を増やしているように見えることさえあります。
その時点では、自分にも十分な説明ができません。何かがおかしいとは感じている。でも、何がおかしいのか、なぜ放置できないのかを、まだ相手が納得できる形にできていない。自分の見立てが間違っている可能性もあります。
その状態で、違和感をなかったことにせず、同時に、自分が正しいと決めつけずに、事実を確かめ続ける。
ここに、この仕事のしんどさがあります。
だから、この仕事は一人で正しさを押し通すことではないのだと思います。
自分にしか見えていなかった違和感を、他の人も確かめられる事実にする。
そして、その事実を、一緒に取り組める問題へ変えていく。
実際に動く仕組みまで持っていくには、この過程も必要です。
「問題を解く人」から、「問題を見つけて実装する人」へ
AI によって、解決能力そのものは民主化していきます。
以前なら専門家しかできなかった分析、開発、資料作成、調査を、多くの人が AI とともに行えるようになってきています。これは大きな変化ですし、私は前向きな変化だと考えています。
ただ、何を解くべきかは、自動的に与えられるわけではありません。
会社の本当の問題は、資料や会議、依頼書の中に、完成した文章として置かれているとは限りません。
人の行動、何気ない会話、例外、矛盾、言いづらい事情、そして説明と現象の間にある小さな違和感の中に埋まっています。
これから価値を持つのは、問題を与えられて解く人だけではありません。
問題がまだ問題と呼ばれていない段階から入り、それを発見し、定義し、そして解決策を実際に動く形まで実装できる人です。
その仕事は、ときに孤独です。
まだ誰にも共有されていない違和感を持ち、十分に説明できないまま事実を集め、周囲からは余計な仕事に見えるものを、確かめ続けなければならないことがあります。
しかし、その孤独な違和感を、他の人も確認できる事実へ変え、会社として扱える問題へ変え、さらに現場で動く仕組みへ変えていく。
そこに、AI 時代の人間の仕事が残るのだと思います。
コンサルと FDE は、職種としては違います。ただ、AI 時代に相対的な価値が高まる職能という点では、かなり同じ方向を向いていると感じています。
AI によって「どう解くか」の選択肢が増えた今だからこそ、「何を解くのか」、そして「本当にそれを解くべきなのか」を、現場の事実から考え直す。
そこから、人間の次の仕事が始まるのだと思います。