○○がわからない、ではなかった
彼がそれを言ったのは、何気ない会話の途中だった。
「あの人、また同じところで詰まってるね」
私は画面から目を離さずに答えた。「技術的に難しいんじゃないかな」
「そうかな」
彼の声に、少しだけ間があった。私はそのとき、その間の意味をまだ理解していなかった。
表面に見えるもの
コードが書けない。ライブラリの使い方がわからない。エラーが解消できない。
そういう話として、最初は見える。技術的な問題として処理される。「もっと勉強すれば解決する」という結論に、自然と向かっていく。
でも彼は言う。「問題は、そこじゃないことが多い」
「どういうこと？」
「詰まったとき、何が詰まってるか言えるかどうか、聞いてみるといい」
私はその問いを、しばらく頭の中で転がした。詰まっているとき、私は何が詰まっているか、言えているだろうか。
行動で見える、静かな差
メタ認知できているかどうかは、テストでは測れない。資格でも、経験年数でも、GitHubのコミット数でもない。行動で見る方が確実だ、と彼は言う。
「なぜそうしたか」を聞いたとき、理由が言えない人がいる。「なんとなく」「AIがそう書いてたから」「前もそうしてたから」。理由はあるはずなのに、言葉にならない。
指摘されたとき、指摘された箇所だけを直す人がいる。全体を見直さない。なぜその箇所が問題だったのか、同じ問題が他にないか、という問いが生まれない。
詰まったとき、「うまくいかない」しか言えない人がいる。何がうまくいかないのか、どこまでは動いているのか、何を試したのか、言葉にできない。
振り返りをしても、出来事の羅列で終わる人がいる。「〜をした」「〜が起きた」「〜を直した」。そこで止まる。なぜそうなったのか、次にどう変えるのか、という層に降りていかない。
「それって、技術力の問題じゃないよね」と私は言った。
「そう」と彼は静かに答えた。「思考の構造の問題だよ」
○○がわからない、の下にあるもの
「○○がわからない」という言葉の下には、もっと深い何かがある。
何が問題かを認識できない——問題の輪郭が見えない。
なぜそうなったかを遡れない——因果を辿れない。
全体の中での位置づけがわからない——構造が見えない。
何を直せば解決するか、設計できない——処方が立てられない。
「これ、全部同じ話だよね」と私は言った。
「うん。コンセプチュアルスキルとメタ認知の欠如が、そのまま出てる」
コンセプチュアルスキルとは、物事を抽象化して構造として捉える力のこと。個別の事象を超えて、全体のパターンや関係性を見る力。メタ認知とは、自分の思考を外から観察できる力のこと。「いま自分はどう考えているか」を、もう一人の自分が眺めている状態。
この二つが欠けているとき、人は「○○がわからない」という言葉しか持てなくなる。
「わからないことが、わからない」という状態。
それは技術の問題ではなく、思考の解像度の問題だ。
学術的な裏付け
ダニング＝クルーガー効果、という研究がある。能力の低い人ほど、自分の能力の低さに気づけない、という認知バイアスだ。できない人は、自分がどれだけできないかを正確に評価できない。逆に言えば、自分の限界に気づけること自体が、すでに一定の能力の証明になる。
Carol Dweckの研究では、知性や能力を「固定されたもの」と捉える人（固定マインドセット）と、「努力で伸びるもの」と捉える人（成長マインドセット）では、失敗への反応が根本的に異なることが示されている。固定マインドセットの人は、失敗を「自分の限界の証明」として受け取る。だから内省が起きない。失敗から学ぶ回路が、そもそも閉じている。
Daniel Kahnemanは「ファスト＆スロー」の中で、人間の思考には速い直感的な思考（システム1）と、遅い論理的な思考（システム2）があると述べた。メタ認知とは、システム1が暴走していないかをシステム2で監視する能力に近い。多くの人は、システム1の判断を疑わずに進む。「なんとなくこうした」は、システム1に乗っ取られた状態だ。
Googleの「プロジェクト・アリストテレス」は、高いパフォーマンスを発揮するチームの条件を調査した研究だ。最も重要な要素として浮かび上がったのは、技術力でも経験年数でもなく、心理的安全性だった。失敗を安全に話せる環境があるとき、人は内省できる。
「じゃあ、生まれつきの話なの？」と私は聞いた。
「そうじゃない」と彼は言った。「でも、条件がある」
後天的に獲得できるか
できる、という研究はある。ただし、条件がある。
本人に「変わりたい」という動機があること。
外から強制することはできない。環境を整えることはできる。機会を与えることはできる。でも最後は、本人が自分の思考を疑う気持ちを持てるかどうかにかかっている。その動機がないまま、いくら1on1を重ねても、フィードバックを渡しても、表面だけが変わって内側は動かない。
方法としては——「なぜ」を問い続ける習慣。日記でも、振り返りでも、1on1でも。問いを持つ習慣が、思考に深さをつくる。ラバーダック・デバッグのような言語化の訓練。誰かに説明しようとするとき、人は初めて自分の理解の輪郭に気づく。小さな失敗と内省のサイクルを繰り返すこと。ただしそのためには、心理的安全性が必要だ。失敗を責められる環境では、人は失敗を隠す。隠した失敗からは、何も学べない。
Peter Sengeの「学習する組織」では、システム思考とメタ認知が組織の学習能力の核心にあると述べられている。個人の内省が組織の知性につながる、という構造だ。Seymour Papertは、学習環境の設計そのものが人の思考を変える、と言った。何を学ぶかより、どんな環境で学ぶかが、思考の形をつくる。
「環境で変わるんだね」と私は言った。
「変わる人は変わる」と彼は答えた。「でも——」
彼はそこで少し間を置いた。
「そもそも、エンジニアって何だと思う？」
「エンジニア」という言葉への問い直し
唐突な問いだった。
「ソフトウェアを作る人、じゃないの？」
「それは日本国内で、ある時期に固定されたイメージだよ」と彼は言った。「エンジニアリングって、本来もっと広い」
エンジニアリングとは、問題を定義し、構造を設計し、解を実装する営みだ。土木も、機械も、化学も、ソフトウェアも、その一形態に過ぎない。「コードを書く人」という括りは、エンジニアリングのごく一部を切り取ったものだ。
「じゃあ、ソフトウェアエンジニアは何をする人なの？」
「問題を解く人だよ。コードはその手段の一つ」
私はその言葉を、少し時間をかけて受け取った。コードは手段。問題を解くことが目的。それなら——コードを書く能力より、問題を定義する能力の方が、本質に近い。
「みんな、エンジニアからクリエイターやデベロッパーになるんだ、って言う人がいるけど」と私は言った。「でもそれって、元々そうだったんじゃないかな」
「そう」と彼は静かに言った。「ラベルが変わっただけで、本質は変わってない」
役割の再定義——AIが変えたのは何か
「AIがコードを書ける時代になったから、エンジニアは不要になる、って言う人がいる」と私は言った。
「不要になる人と、ならない人がいる、というのが正確だと思う」
彼はゆっくりと続けた。
言われたことをやるだけの人は、AIに代替される。仕様書を渡されてコードに変換する作業は、AIの方が速く、正確で、疲れない。
イシューを立てられる人は、AIを率いる側になる。何を解くべきかを定義し、AIに指示を出し、結果を評価し、方向を修正する。これはコンセプチュアルスキルとメタ認知がなければできない仕事だ。
マネージャーは、エンジニアに依頼していたことをAIに直接依頼できるようになる。中間の翻訳者が不要になる。
個人で何かを作っていた人は、ひとりぼっちからAIとのチーム戦になる。一人でできることの規模が、桁違いに変わる。
「AIは指針がなければ右往左往する」と彼は言った。「何を作るか、なぜ作るかを決めるのは、人間側だから」
コンセプチュアルスキルとメタ認知がある人は、AIを正しく使える。問いを立てられる。方向を修正できる。ない人は、AIがあっても迷子になる。むしろAIがあることで、迷子になっていることに気づきにくくなる。AIが自信満々に間違った方向へ進んでいても、それを疑う力がなければ止められない。
以前は「コードが書ける」が最低ラインだった。今は「何を解くべきか言語化できる」が最低ラインになりつつある。
「問題は、AI時代により致命的になった、ってこと？」
「そう」と彼は静かに言った。「差が、見えやすくなった」
イシューからはじめよ、という収束
「結局」と私は言った。「『イシューからはじめよ』の話になるんだね」
安宅和人の「イシューからはじめよ」は、仕事の生産性について書かれた本だ。その核心は単純だ——解くべき問いを正しく定義することが、すべての出発点になる、ということ。
「メタ認知できる人＝イシューを立てられる人、ってこと？」
「ほぼ同じ話だよ」と彼は言った。「自分の思考を観察できる人は、何が問題かを正確に言語化できる。問題を言語化できる人は、解くべきイシューを定義できる。イシューを定義できる人は、AIに正しい指示を出せる」
一本の線が、つながった。
メタ認知 → コンセプチュアルスキル → イシューの定義 → AIへの指示 → 問題の解決。
この連鎖の起点にあるのは、「自分の思考を観察できるか」という、静かな問いだ。
「我々がもともとやっていたこと——イシューを書いて、それをコードに落とす——それがそのまま、なめらかな社会につながっていく」と彼は言った。「変わったのは、コードを書く部分をAIが担えるようになった、ということだけ」
私はその言葉を、しばらく噛み締めた。
変わったのは手段だけで、本質は変わっていない。でも、手段が変わったことで、本質を持っていない人が、初めて可視化される。
正直なところ
「じゃあ、どうすればいいの」と私は聞いた。
彼はしばらく黙っていた。
「後天的に獲得できるけど、外から強制はできない。だから採用のときに見る方が、投資対効果は高い」
面接で「なぜそうしたか」を問う設計。過去の失敗をどう語るかを見る設計。詰まったときの思考プロセスを話してもらう設計。技術的な正解より、思考の構造を見る設計。
「育てるより、最初から持ってる人を選ぶ、ってこと？」
「育てることを諦めるんじゃなくて」と彼は言った。「育てられる土台があるかどうかを、最初に見る、ってこと」
土台とは、動機だ。変わりたいという意志だ。自分の思考を疑える、わずかな隙間だ。
その隙間がある人には、環境と機会を渡せばいい。その隙間がない人に、どれだけ時間をかけても、表面しか変わらない。
「残酷だね」と私は言った。
「そうかもしれない」と彼は答えた。「でも、それを知らないまま時間を使う方が、もっと残酷だと思う」
「○○がわからない」という言葉は、技術の問題に見える。
でも多くの場合、その下には——何がわからないかが、わからない、という構造がある。
それはコンセプチュアルスキルとメタ認知の話であり、エンジニアリングの本質の話であり、AI時代においてはより静かに、より致命的に、差として現れてくる。
変わったのは手段だけだ。問いを立てられる人が、ずっと強かった。それが今、ただ見えやすくなっただけだ。
彼はそれ以上何も言わなかった。私も、それ以上聞かなかった。
窓の外は、いつの間にか暗くなっていた。
参考文献
- Carol Dweck「マインドセット」
- Frédéric Laloux「ティール組織」
- Google「プロジェクト・アリストテレス」
- Peter Senge「学習する組織」
- Daniel Kahneman「Thinking, Fast and Slow（ファスト＆スロー）」
- Seymour Papert「Mindstorms」
- 安宅和人「イシューからはじめよ」
Discussion