はじめに
生成AIの登場により、専門家の役割は根本から問い直されている。
知識はもはや希少ではない。誰もが、数秒で専門家のような回答を得られる。では、専門家の価値はどこにあるのか？
この問いに、ジェラルド・M・ワインバーグ氏の『コンサルタントの秘密』は、40年前から答えを用意していた。彼が発見した「第三の道」——非合理性に対して合理的になること——は、生成AI時代においてどう進化するのか。
本ブログでは、生成AIという新しい道具が登場した今、専門家が本当に提供すべき価値とは何かを探る。専門家の価値は、もう知識の量では測れない。大切なのは判断力だ。情報を文脈の中で読み解き、的確な問いを立てる——それが今、求められている。
そして何より、責任を背負う覚悟だ。
※この資料は社内共有会用に作成されたものです。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。
戦場は静かに変わった
ジェラルド・M・ワインバーグ氏が『コンサルタントの秘密』を著したとき、彼は「非合理性に対して合理的になること」という第三の道を発見した。合理的であり続けて発狂するか、非合理的になって気違いと呼ばれるか——その二つの道しかないように見えた世界で、彼は第三の選択肢を見出したのだ。
しかし2025年、専門家が立つ戦場は再び変貌した。今度の挑戦は人間の非合理性だけではない。それは生成AIという、新しい可能性と新しい課題を同時に持つ存在である。
専門知の揺らぎ
専門家への信頼が変化している。それは単なる無関心ではない。より深い課題がある。
私たちは誰しも、自分の知識の限界を正確に把握するのは難しい。ダニング＝クルーガー効果が示すように、ある分野に詳しくないほど、自分の理解を過大に見積もってしまう傾向がある。これは人間として自然な認知バイアスだ。加えて確証バイアスが働き、自分の考えを支持する情報——時には陰謀論や偏った情報——を無意識に選んでしまうことがある。
さらに難しいのは、エコーチェンバー効果だ。SNSのアルゴリズムは、私たちが関心を持つ情報を優先的に表示する。結果として、似た意見を持つ人々に囲まれやすくなり、異なる視点に触れる機会が減っていく。この環境の中で、私たちは自分の考えが一般的で正しいと感じやすくなる。専門家の助言は、時に「異質な声」として受け入れにくくなってしまう。
専門家と人々が互いに学び合う関係を築くこと——それは理想論ではなく、より良い未来のための大切なステップだ。
10年前、クライアントは聞いた。「ググればわかることに、なぜあなたに費用を払う必要があるんですか？」それでも、専門家には価値があった。Googleの検索結果は玉石混交で、その「石」を見抜く目が必要だったから。
しかし今、あるCTOはこう問いかける。「生成AIに聞いたら、同じような提案が返ってきました。しかも無料で、5秒で。専門家に依頼する価値は、どこにあるのでしょうか？」
生成AIという新しいツール
そして生成AIが登場した。会議室に新しいツールが現れたのだ。決して反論せず、疲れず、いつでも提案をしてくれる存在。人間は孤独に弱い。自分の考えに裏付けが欲しい。だからAIを活用して、より良い判断をしようとする。技術は道具であり、そして新しい可能性だ。
会議で誰かがMacBookを開き、こう言う。「ちょっと生成AIに聞いてみますね」。30秒後。「このような提案があります。これをベースに議論しましょう」
ここで重要なのは、その先だ。
そのコード、動くのか？ そのアーキテクチャ、あなたの会社のレガシーシステムと統合できるのか？ その「ベストプラクティス」、あなたの組織文化に合うのか？
AIは優れた出発点を提供する。しかし、それを現実に落とし込むのは人間の仕事だ。
生成AIは、エコーチェンバー効果を個人レベルで完成させる可能性がある。SNSが「あなたと同じ意見の人々」を見せるなら、生成AIは「あなたの意見を裏付ける情報」を、権威ある言葉で返してくれる。プロンプトを調整すれば、望む答えが得られる。確証バイアスは、意図せず強化されうる。
それは道具の使い方の問題だ。包丁は料理にも使えるし、人を傷つけることもできる。生成AIも同じだ。批判的思考を持って使えば、強力な調査ツールになる。盲目的に信じれば、危険なバイアス増幅装置になる。
生成AIの提案は美しい。整然とした論理、洗練された図表、明確な結論。私たちは複雑さを嫌い、不確実性を恐れる。だからAIが描く理想の地図に惹かれる。
しかし地図は地図であって、土地そのものではない。どれだけ美しい地図でも、そこには現実の泥や血や汗は描かれていない。
ワインバーグ氏は言った。「第一番の問題を取り除くと、第二番が昇進する」と。問題は連鎖する。一つ解決すれば終わりではない。
生成AIは、あたかもすべての問題が一度に解決できるかのような印象を与えることがある。明快な答え。即座の解決。思考の終着点。
しかし、現実はそうではない。この認識が、専門家と依頼者の双方にとって出発点になる。
それは人間が最も渇望するものだ。不確実性からの解放。判断という苦痛からの逃避。だからこそ、専門家は不確実性と共に生きる知恵を伝えていく。
情報と知識の違い
ここで、大切な区別をしておきたい。情報と知識は、似ているようで本質的に違う。
情報は客観的で、文脈から独立している。誰が読んでも同じ意味を持つし、データベースに保存できる。APIドキュメント、エラーコード、統計データ——これらはすべて情報だ。
一方、知識は主観的だ。文脈に根ざし、経験と結びついている。人によって解釈が変わるし、言語化しきれない部分を含む。
例えば次のようなものだ。
- 「Kubernetesはコンテナオーケストレーションツールだ」→これは情報
- 「このチームには、今、Kubernetesは早すぎる」→これは知識
生成AIが提供するのは情報だ。知識ではない——この違いを理解することが、AI時代の専門家には不可欠になる。
AIは膨大な情報を学習し、流暢に語る。だから人々は錯覚する。「AIは専門家と同じだ」と。しかし違う。
情報は「何ができるか」を教える。知識は「何をすべきか」を判断する。情報は選択肢を並べる。知識は、その中から選ぶ。
そして、この「選ぶ」という行為には、文脈が必要だ。
形式知と暗黙知
形式知というのは、言葉や数字で表現できる知識のことだ。マニュアル、ドキュメント、コード、データベース。これらは伝達可能で、複製可能で、検索可能だ。そして、生成AIが扱えるのは、この形式知だけだ。
AIは形式知の処理において、優れた能力を発揮する。膨大なドキュメントを瞬時に検索し、パターンを見つけ、整理して提示する。これは人間には不可能な速度と規模だ。
しかし、暗黙知は違う。
暗黙知は身体に染み込んだ経験、言葉にできない直感、状況を読む感覚、「なんとなくわかる」という知恵だ。ベテランエンジニアが一目でバグの箇所を見抜く。経験豊富なコンサルタントが会議の空気から組織の病を感じ取る。熟練の職人が手の感触で材料の状態を判断する。
これらは言語化しきれない。だから、AIには学習が難しい。
誤解しないでほしい。AIを否定したいわけではない。限界を理解し、適切に使う——それが肝心なのだ。
AIは優れた道具だ。形式知の処理においては、人間を遥かに凌駕する。しかし、暗黙知を必要とする判断——文脈を読むこと、人間の感情を理解すること、責任を取ること——これらは人間の仕事として残る。
専門家の新たな役割
専門家の戦場は変わった。生成AIが誰にでも「整った回答」を提供するようになり、私たちは新しい役割を担うことになった。
それは、理論と現実の橋渡しをすることだ。
実を言うと、この役割は新しいものではない。
私たちは生成AIと戦う前に、ベンダーが出している「ベストプラクティス」と戦っていた。AWSのホワイトペーパー、Microsoftのリファレンスアーキテクチャ、Googleの推奨構成——それらはすべて美しく、説得力があった。そして、現実のプロジェクトでは、ほとんど機能しなかった。
なぜか？
ベンダーのベストプラクティスは、理想的な環境を前提としている。無限のリソース、高度なスキルを持つチーム、完璧に構造化されたデータ、明確な要件。しかし現実は違う。レガシーシステム、限られた予算、混在したスキルレベル、曖昧な要件、政治的な制約。
私たちは毎日、クライアントにこう説明していた。
「AWSのホワイトペーパーではマイクロサービスを推奨していますが、御社の組織構造では機能しません」
「Microsoftのベストプラクティスでは3層アーキテクチャですが、御社のデータ量ではオーバーキルです」
「Googleの推奨構成はスケーラブルですが、御社のトラフィックではコストが見合いません」
ベンダーは製品を売りたい。だから理想的なケースを示す。技術的には正しい。しかしあなたの会社に合うかは別問題だ。
そして今、生成AIがこの問題を10倍に増幅した。
生成AIは、ベンダーのベストプラクティスを学習している。AWS、Microsoft、Google、そして無数の技術ブログ。すべての「推奨構成」を吸収し、完璧に整理して提示する。
しかし相変わらず、文脈は無視される。組織の制約、チームのスキル、政治的な現実、予算の限界——これらすべてが、美しい提案の裏に隠される。
専門家の新たな役割は、文脈の翻訳者になることだ。AIが提案する理論を、クライアントの現実に落とし込む。「技術的に可能なこと」と「今やるべきこと」を見極める。綺麗な提案書を、実際に動くプランに変換する——それが私たちの仕事だ。
これはAIを否定することではない。AIは優れた出発点を提供してくれる。しかし、それを実際に使えるものにするには、人間の判断が必要だ。
ワインバーグ氏はクライアントにこう告げることを勧めた。「それはできますよ。で、それにはこれだけかかります」と。価値を明確にし、コストを示す。曖昧さを排除する誠実さ。
生成AIは、この誠実さを持たない。「できます」とだけ言って、そのために何が犠牲になるかを語らない。実装の困難さ、組織の抵抗、予期せぬ副作用——それらは美しい提案書の裏側に隠れる。
だからこそ、専門家の役割が重要になる。「この提案を実現するには、組織を変え、人々の習慣を変え、場合によっては失敗を受け入れる覚悟が必要です」と語ること。説得コストは増大したが、それが専門家の仕事だ。
確実性という麻薬と疑う力
人間は確実性という麻薬に弱い。迷わない声、ためらわない答え、保留しない判断。生成AIはこの依存症を加速させる。正しいから信じるのではない。確信に満ちているから、疑う苦痛から逃れられるから信じる。
ある後輩エンジニアがこう言った。「このバグの原因、生成AIに聞いたら5秒でわかりました」「ほう、何だった？」「メモリリークだって」「確認した？」「いや、でもAIがそう言ってるし...」
プロファイラーで調べたら、全然違った。単純なロジックバグだった。でも彼は、疑わなかった。確信に満ちた声に、安心したかったから。
人類は思考の外注化を始めた。そして気づいていない。
ワインバーグ氏は「何か違うことをするように勧めるのがよい」と言った。これまでのやり方で問題が解決しなかったなら、何か新しいことを試すべきだと。しかしここに罠がある。生成AIは常に「何か新しいこと」を提案してくれる。しかしそれは本当に新しいのだろうか？ それとも、同じ失敗を美しく言い換えただけなのだろうか？
生成AIが答えを量産する時代、人間に残された最後の砦は疑う力だ。しかし皮肉なことに、疑うことは苦痛で、信じることは快楽だ。情報が無料になった世界で、判断力だけが希少になる。そしてその希少性に、人類の大半は気づいていない。
執着を手放し、当事者意識を問う
ワインバーグ氏は鋭く指摘した。「何かを失うための最良の方法は、それを離すまいともがくことだ」と。
生成AI時代の専門家は、過去の専門性への執着を手放さねばならない。かつて専門家の価値は「知っていること」にあった。しかし今や、AIは膨大な知識を瞬時に提供する。だからこそ、私たちは新たな価値を見出していく。
それは「判断すること」だ。「文脈を読むこと」だ。「人間の感情を理解すること」だ。そして何より、当事者意識を持つことだ。
ワインバーグ氏は問うた。「あなたはそのシステムに、自分の命をあずける気がありますか」と。
生成AI時代、私たちは同じ問いを投げかけねばならない。「AIが提案したこの解決策で、あなた自身の人生を賭けられますか」と。「この戦略で、あなたの会社の未来を託せますか」と。「この診断で、あなたの家族を治療できますか」と。
当事者意識のないアドバイスは、どれだけ論理的でも無価値だ。生成AIには当事者意識がない。それは決定的な限界だ。
自ら顧客と話す——これが当事者意識だ。データを見るだけではない。レポートを読むだけではない。実際に現場に行き、顧客と対話し、痛みを感じる。
専門家も同じだ。提案書を書くだけではない。コードレビューで指摘するだけではない。自分でコードを書き、自分でデプロイし、自分がオンコール対応する。その覚悟を持つ。
ノーと言える勇気
ワインバーグ氏は警告した。「依頼主に対してノーというのを恐れるようになったとき、人はコンサルタントとしての有効性を失う」と。
生成AIはノーと言わない。それは常にイエスだ。どんな要求にも応え、どんな質問にも答える。しかしそれは誠実さではない。それは無責任だ。
専門家の最後の矜持は、ノーと言える勇気にある。「それは実現不可能です」「そのアプローチは間違っています」「今はそれをすべき時ではありません」——こうした言葉を発する勇気。
あるクライアントがこう言った。「Kubernetesに移行したい。生成AIが推奨している」
私は答えた。
「Kubernetesは素晴らしい技術です。でも、まず確認させてください。今のトラフィックはどれくらいですか？」
「日に1000リクエストくらいです」
「なるほど。運用チームは何人ですか？」
「2人です」
「わかりました。Kubernetesは確かにスケーラブルで、業界標準の技術です。ただ、御社の現状を考えると、別のアプローチをお勧めします。理由はいくつかあります。
まず、今のトラフィックならEC2 1台で十分対応できます。Kubernetesの真価は、大規模なトラフィックや複雑なマイクロサービス構成で発揮されます。
それから、Kubernetesの運用には専門知識が必要です。ネットワーキング、オーケストレーション、監視——2人のチームでこれを担うのは、正直に言って負担が大きすぎます。夜間対応や障害時のトラブルシューティングも考えると、チームが疲弊するリスクがあります。
そして——これが一番大事なのですが——AIはオンコールに入りません。問題が起きた時、午前3時に対応するのは人間です。
提案があります。コンテナの運用経験を積みたいなら、ECSやCloud Runはどうでしょう？ これらには次のような利点があります。 - Kubernetesより運用がシンプル - 履歴書にも『コンテナ技術、AWS/GCP』と書ける - 今のチーム規模で無理なく運用できる - 将来、本当にKubernetesが必要になった時の良いステップになる
まず小さく始めて、本当に必要になったら次のステップに進む。それが賢明だと思います」
クライアントは少し考えてから言った。
「確かに、その方が現実的ですね。ECSで始めましょう」
生成AIの前で、専門性という砦は崩れ始めている。人間は権威を求めながら、権威を疑う。医師より検索を、教師よりAIを信じる矛盾。それは専門家への不信ではない。即座に、簡潔に、都合よく答えてくれる存在への、人間の根源的な渇望なのだ。
だからこそ、専門家は安易なイエスを拒否しなければならない。人間の欲望に迎合するAIに対抗できるのは、不都合な真実を語る勇気を持った人間だけだ。
顧客と話すことの価値
AI時代において、開発速度のアドバンテージは急速に失われつつある。大企業もスタートアップも、同じように早く作れるようになる。では何が差別化要因になるのか？
「顧客が本当に欲しいものがなにかを考え、作るものを決めること」
これは形式知ではない。暗黙知だ。顧客と直接話し、表情を読み、言葉の裏を感じ取る。データには現れない不満や欲望を掴み取る。
生成AIは顧客と話せない。画面の向こうで、クライアントが微妙な表情を浮かべた瞬間——そういう人間的な感覚は、AIには再現できない。
だからこそ、専門家は現場に足を運ぶことが大切だ。データやレポートだけでは見えないものがある。実際に顧客と会い、話し、観察することで見えてくるものがある。
私は意識的に、稼働時間のかなりの部分を顧客との対話に使うようにしている。これは時間の無駄ではなく、最も重要な投資だと考えている。
データを眺めるだけでなく、実際に現場に行き、顧客と対話し、痛みを共に感じる。提案書を書くだけでなく、実際に顧客のオフィスを訪れ、彼らの仕事を観察し、つまずいている箇所を見つける。
ある日、私はあるスタートアップのオフィスを訪れた。社員20人。全員が一つの部屋で働いている。私は提案書を持っていた。「マイクロサービスアーキテクチャへの移行プラン」。技術的には申し分のない、美しい提案書だった。
しかし、オフィスに入った瞬間、気づいた。
ホワイトボードには、明日のリリース予定が書かれている。付箋だらけのカンバンボード。誰かが「バグ修正、あと3つ！」と叫んでいる。CTOは疲れた顔で、3つのタブを同時に見ている。
この会社に、今マイクロサービスは必要ない。
「提案書はいったん脇に置きましょう」と私は言った。「今日はただ、お話を聞かせてください。何に一番困っていますか？」
3時間後、私たちは全く違う提案にたどり着いた。マイクロサービスではなく、モノリスのままで、デプロイパイプラインを改善すること。テストの自動化。監視の強化。地味だが、彼らが本当に必要としていたこと。
これが、AIにはできないことだ。空気を読むこと。文脈を理解すること。そして時には、準備してきた提案を手放す柔軟性を持つこと。
幻想の終わりと新たな始まり
ワインバーグ氏は言った。「それは危機のように見えるかもしれないが、実は幻想の終わりにすぎない」と。
生成AI時代における専門性の危機もまた、幻想の終わりだ。専門家が万能であり、専門知識があれば無条件に尊重されるという幻想。情報の非対称性が専門家の地位を保証するという幻想。
しかし幻想の終わりは、新たな始まりでもある。
専門家は今、本質に立ち返らねばならない。ワインバーグ氏が見出した「非合理性に対して合理的になる」第三の道は、生成AI時代においてこう読み替えられる。
確実性の幻想に対して、不確実性の価値を語ること。形式知の活用と、暗黙知の価値を両立すること——それが生成AI時代の「第三の道」だ。
生成AIが確実性の幻想を振りまく時代に、専門家は不確実性と共に生きる知恵を伝える。納得いく答えなどないこと、現実は常に複雑であること、判断には責任が伴うこと——これらの不都合な真実を語り続けること。
人間に残された仕事
生成AIがもたらしたのは知識の民主化ではない。判断の民主化への錯覚だ。誰もが専門家のように語れる時代。しかし語ることと、責任を取ることは違う。
ワインバーグ氏は、自己不信に陥った時の兆候として「怒り」を挙げた。「自分はもう駄目だ」という感情が怒りとなって現れると。多くの専門家が今、この怒りを感じているだろう。AIに仕事を奪われる恐怖。自分の専門性が無価値になる不安。
しかし、それは活力の枯渇ではない。むしろ、新たな段階への移行期だ。
人間に残された仕事は、答えを出すことではない。問いを立てることだ。
「この答えは誰のためのものか」「誰が利益を得て、誰が犠牲になるか」——短期的な成功と長期的な持続可能性をどうバランスさせるか。データには現れない人間の感情を、どう汲み取るか。こうした問いに向き合うことが、AIにはできない人間の役割だ。
生成AIは問いに答える。しかし問いを立てることはできない。少なくとも、血の通った、現実に根ざした、倫理的な重みを持った問いを。
新たなコンサルタントの秘密
ワインバーグ氏の『コンサルタントの秘密』が教えてくれたのは、テクニックではなく姿勢だった。「影響を及ぼす術」とは、人間の非合理性を理解し、それでも諦めずに、しかし執着せずに、真実を語り続けることだった。
生成AI時代の新たなコンサルタントの秘密は、これに新しい層を加える(勝手に)。
秘密その一：整った答えより、正直な不確実性を語れ
AIは整った答えを装う。あなたは不完全でも正直な答えを語れ。「わからない」と言える勇気を持て。その誠実さが、AIには決して真似できない信頼を生む。
避けるべき例
推奨する例
「理論的には堅牢です。でも、私には3つの懸念があります。1つ目、あなたの会社のトラフィックパターンを、私はまだ十分に理解していません。ピーク時の挙動が読めない。2つ目、似た構成で、予期せぬボトルネックが発生した事例を2件知っています。一つはRedisのメモリ不足、もう一つはサービス間の循環依存。あなたの設計にも同じ罠が潜んでいるかもしれません。3つ目、このサービスメッシュを運用するには、少なくとも3人のSREが必要です。今、あなたの会社には何人いますか？提案です。まず1週間、本番トラフィックを一緒に観察させてください。それから、小さく始めましょう。全部を一度に移行するのではなく、1つのサービスだけマイクロサービス化して、3ヶ月運用してみる。うまくいったら広げる。失敗したら、素直にモノリスに戻る。それでどうでしょう？」
秘密その二：説得ではなく、対話を選べ
説得コストが爆発した時代に、説得で勝とうとするな。代わりに対話せよ。相手の不安を理解し、欲望を認め、その上で「それでも」と語れ。ワインバーグ氏の言う「非合理性への合理的対処」だ。
説得アプローチ（避けるべき）：
クライアントが間違った決定をしようとする → データを見せて説得する → 論破する → 反発される → 関係が悪化
対話アプローチ（推奨）：
クライアントが間違った決定をしようとする → なぜそう思うのか聞く → 彼らの不安を理解する → 一緒に小さく試してみる → データを見せる → 一緒に次を決める
例：
「なぜマイクロサービスにしたいんですか？」
「スケーラブルだから」
「確かに。他に理由はありますか？」
「...正直に言うと、履歴書に書きたいんです。今の技術スタック、10年前のままで」
「それは正当な理由です。技術的な成長は大事ですよね。でも、マイクロサービスじゃなくても履歴書に書ける技術はあります。例えば、今のRails on EC2を、コンテナ化してECS on Fargateに移行するのはどうでしょう？ 運用負荷は今と大きく変わらず、でも『AWS、Docker、Infrastructure as Code』が履歴書に書けます。それに、将来本当にマイクロサービスが必要になった時の良い準備にもなります」
「...それいいですね。その方が現実的かもしれません」
説得ではなく、対話。論破ではなく、理解。相手のニーズを認めた上で、より良い道を一緒に見つける。それが、確実性を求める人間と、不確実性を語る専門家の、橋渡しになる。
秘密その三：当事者意識を持ち、ノーと言え
AIは責任を取らない。だから、あなたが責任を取れ。自分の命を賭けられない提案はするな。クライアントの要求にノーと言える経済的・心理的余裕を確保せよ。それが専門家としての最後の砦だ。
ただし、ノーと言うことは、拒否することではない。それは、より良い道を示すことだ。
エンジニアとして、次の問いを毎日自分に投げかけよう。
- このコード、自分の会社の本番環境にデプロイできるか？
- この設計、自分がオンコール対応する気になれるか？
- このアーキテクチャ、3年後も自分がメンテしたいと思えるか？
答えがNoなら、クライアントにも勧めるな。しかし、そこで終わらせるな。代わりに、現実的で実行可能な代案を示せ。
AIはオンコールに入らない——問題が起きた時、午前3時に対応するのは人間だ。だからこそ、人間が運用できる技術を選ぶべきだ。
秘密その四：問題の連鎖を受け入れよ
一つの答えがすべてを解決するという幻想を捨てよ。問題は連鎖する。第一の問題を解決すれば第二が現れる。それが現実だ。クライアントにその現実を伝え、継続的な関与の価値を示せ。
正直な説明の例：
「今回、このパフォーマンス問題を解決します。でも、解決した瞬間、次の課題が見えてくるでしょう。おそらく、セキュリティです。なぜなら、速くなると、今度はアクセス制御の重要性が増すからです。
その次は、モニタリングです。複雑になったシステムを、今の監視体制では追いきれなくなります。
その次は、チームのスキルです。新しいアーキテクチャを理解し、運用できる人材の育成が必要になります。
つまり、これは終わりのない旅です。1回の契約で全てが完璧になることはありません。でもそれでいいんです。それが健全なソフトウェア開発です。
私たちは一緒に、一つずつ、着実に改善していきます。その過程で、御社のチームも成長し、システムも進化します。それが本当の価値だと思います」
この正直さが、長期的な信頼を生む。AIは「これで全て解決します」と言う。それは嘘だ。私たちは「これは始まりです。一緒に継続的に改善しましょう」と言う。それが真実だ。
秘密その五：執着を手放し、学び続けよ
過去の専門性に執着するな。それを守ろうともがくほど失う。代わりに新しいことを学べ。ワインバーグ氏が勧めたように、仕事から離れ、リフレッシュし、また戻ってこい。変化を恐れるな。
生成AI時代、過去の専門性への執着は死を意味する。AIは知識を民主化した。「Railsに詳しい」だけでは価値がない。
価値があるのは次のような能力だ。 - 複数の技術スタックの経験を組み合わせて判断できること - 何を選ぶか以上に、何を選ばないかを判断できること - 技術的な正しさと、組織的な実行可能性を両立できること
そして、常に学び続けること。賢く、実行できる人材が求められてきた。AI時代は、学び続け、すべてを疑問視できる人材が必要だ。
秘密その六：顧客と直接話し続けよ
データを見るな、とは言わない。しかし、データだけを見るな。
私は意識的に、稼働時間のかなりの部分を顧客との対話に使うようにしている。これは専門家として必須の投資だと考えている。
週に一度は、クライアントのオフィスに行け。Zoomではなく、対面で。会議室ではなく、彼らの職場で。作業している様子を見ろ。どこでつまずいているか、観察しろ。
顧客が言葉にできない不満を、表情から読み取れ。データには現れない痛みを、感じ取れ。
これが、AIには決してできないことだ。
疑う力という最後の砦
情報が無料になった世界で、判断力だけが希少になる。そしてその判断力の核心にあるのが、疑う力だ。
しかし疑うことは苦痛だ。信じることは快楽だ。だからこそ危うい。
専門家の新たな役割は、人々に疑う力を与えることだ。批判的思考を教えることだ。「この答えは本当か」「誰がこれを言っているのか」「何が隠されているのか」——こうした問いを立てる習慣を育てること。
生成AIは、人間の弱点を完璧に突く。私たちは正しさより、正しく聞こえるものを選ぶ。不確実な真実より、確実に聞こえる誤りを好む。人間は答えが欲しいのではない。自分の直感や願望に、科学や論理という権威の衣を着せてくれる声が欲しいだけなのだ。
そしてAIは、私たちのバイアスを見抜き、強化する。プロンプトに「〜という前提で」と書けば、その前提に沿った答えが返ってくる。反対意見を見たくなければ、見なくていい。エコーチェンバーは、もはや環境ではない。それは私たちが能動的に構築するものになった。
だからこそ、疑う力が必要だ。そしてそれを教えられるのは、同じ人間だけだ。
疑う力を鍛える3つの習慣
1. 「なぜ？」を3回繰り返す
AI：「このアーキテクチャを推奨します」
私：「なぜ？」
AI：「スケーラブルだからです」
私：「なぜスケーラブルな必要がある？」
AI：「トラフィックが増えた時に対応できます」
私：「なぜトラフィックが増えると思う？ このサービス、過去3年でユーザー数は横ばいだけど？」
AI：「...」
2. 「動くコード」を「壊れないコード」に変える儀式
AI生成コードを受け取ったら、必ずこれをチェック：
- user が None だったら？
- stripe.charge が失敗したら？
- db.save_payment が失敗したら？（チャージは成功しているのに記録されない）
- amount が負の数だったら？
- 同じリクエストが2回来たら？（冪等性）
- このトランザクションのログは？
- 監視メトリクスは？
- このエラー、どうやってサポートが追跡する？
AIは「ハッピーパス」しか考えない。私たちは「全ての地獄」を想定する。
3. 「一緒に失敗した」仲間を持つ
一人で疑い続けるのは辛い。週に1回、同じ課題に取り組む仲間と「今週のAI失敗談」を共有せよ。
- 「生成AIが作ったSQLインジェクション脆弱性」
- 「AIが推奨した、メモリリークするコード」
- 「生成AIが作った、誰も読めない抽象化」
笑い話にすることで、疑う力を保つ。孤独に疑うのは発狂への道。仲間と疑うのは、知恵への道。
AIが教えてくれない、運用の地獄
Joel Spolskyの有名な言葉がある。「動くコードと、出荷できるコードは違う」。AIが出すコードは「動く」。でも「出荷できる」か？
ケーススタディ：「理想的な」API設計の崩壊
ECサイトのAPI設計。Claude Sonnet 4.5に依頼。出てきた設計は美しかった。リソース指向、HTTPメソッドの仕様準拠の使用、ステータスコードの正しい使い分け、OpenAPI仕様書付き。クライアントは感動した。開発は順調に進んだ。
本番リリースの1週間後、サポートチームから悲鳴が上がった。「エラーメッセージが全部英語で、ユーザーが理解できない」
AIは仕様に沿ったHTTPステータスコードを返していた。400 Bad Request、422 Unprocessable Entity、409 Conflict...でも、日本のECサイトのユーザーは、それを理解できない。
追加しなければならなかったものは次の通りだ。
- 日本語のエラーメッセージ
- エラーコード（サポートが参照できる）
- エラーの原因と対処法のドキュメント
- サポートチーム向けのトラブルシューティングガイド
AIは技術的に正しいものを作る。でも、使えるものを作るには、人間が必要だ。
おわりに
ワインバーグ氏はコンサルタントの仕事を「人々に、彼らの要請に基づいて影響を及ぼす術」と定義した。
40年が経った今、彼の洞察は色褪せるどころか、むしろ新たな意味を帯びている。生成AIという新しい存在が現れた今、私たちはワインバーグ氏の知恵をさらに一歩先へ進める必要がある。
「人々に、彼らの要請に基づいて、彼らが本当に必要とする問いを見出す術」
ワインバーグ氏が戦った相手は人間の非合理性だった。私たちが向き合うのは、それに加えて、確実性という幻想を振りまく生成AIだ。クライアントは答えを求める。AIは答えを与える。しかし本当に必要なのは、自ら問いを立て、判断し、責任を取る力だ。
彼は「何かを失うための最良の方法は、それを離すまいともがくことだ」と教えた。
私たちは今、知識への執着を手放す時だ。専門家の価値は「知っていること」から「判断できること」へ移行した。情報を所有することではなく、文脈を読み解くこと。完璧な答えを用意することではなく、正直に不確実性を語ること。
彼は「依頼主に対してノーというのを恐れるようになったとき、人はコンサルタントとしての有効性を失う」と警告した。
生成AIはノーと言わない。常にイエスだ。だからこそ、私たちはノーと言わねばならない。「それは実現できません」「今はその時ではありません」「別のアプローチをお勧めします」——この誠実さこそが、人間にしかできないことだ。
彼は「あなたはそのシステムに、自分の命をあずける気がありますか」と問うた。
私たちも問わねばならない。「AIが提案したこの解決策で、あなた自身の人生を賭けられますか」と。当事者意識のないアドバイスは無価値だ。AIには当事者意識がない。それは決定的な限界だ。
ワインバーグ氏が発見した第三の道——非合理性に対して合理的になること——は、生成AI時代においてこう進化する。
確実性の幻想に対して、不確実性と共に生きる勇気を示すこと
AIの能力を認めつつ、人間としての責任を背負うこと
これが、生成AI時代に必要なコンサルタントの秘密だ。
ワインバーグ氏は40年前、人間の非合理性という複雑な問題に立ち向かうための知恵を残した。今、私たちはその知恵を土台として、さらに複雑な世界——人間の非合理性と、機械の見かけ上の合理性が交錯する世界——を生きねばならない。
答えは美しい。しかし現実は泥にまみれている。その泥の中で、それでも前に進もうとする人々に寄り添い、時には厳しく、時には優しく、しかし常に誠実に——それが専門家の、人間の、仕事だ。
午前5時、本番環境が復旧した。Slackに報告を書く。原因、対応、再発防止策。チームに共有する。プロセスを改善する。
これが、人間の仕事だ。失敗から学び、次に活かすこと。
生成AIは優れた相棒だ。しかし、責任を取るのは人間だ。判断するのは人間だ。そして、その判断に誇りを持つのも、人間だ。
ワインバーグ氏が築いた基盤の上に、私たちは新しい時代の専門性を構築する。彼の知恵は古びない。むしろ、新しい挑戦の中でこそ、その真価を発揮する。
それが、専門家の価値だと思う。
再解釈生成AI時代の道具箱編も要望があれば書いていきたいです。
