はじめに

本番環境で障害が起きた。ユーザーへの影響は30分。復旧は終わっている。これから原因を分析し、再発防止策を決める。メンバーは5人。全員が優秀だった。

最初の10分は順調だった。タイムラインを確認し、直接原因を特定した。問題はここからだ。再発防止策の議論に入った瞬間、5人が5つの方向に走り始めた。

Aは「監視のしきい値を変えるべきだ」と言った。正しい。
Bは「カナリアリリース（一部のユーザーだけに先行公開する手法）を入れるべきだ」と言った。正しい。
Cは「そもそも基本設計の問題だ」と言った。正しい。
Dは「テストカバレッジが足りない」と言った。正しい。
Eは「アラートの設計を見直すべきだ」と言った。正しい。

全員が正しいから、議論が収束しない。30分が経った。結論は出ない。誰も間違ったことを言っていないのに、何も決まらない。

賢い人が集まれば問題は解決する──そう思っていた。その信念が崩れるまでに、いくつかの失敗が必要だった。

賢い人ほど自分のバイアスに気づけない

IQが高いほど、自分のバイアス（偏り）に気づけない。直感的には矛盾しているように聞こえます。賢い人は論理的思考ができるのだから、バイアスにも気づけるはずです。

しかし、逆です。高い知性は、バイアスの「検出」には役立ちません。むしろ、バイアスを「正当化」する能力を高めます。

また、賢い人ほど「自分は客観的に判断できている」と確信していますが、これが盲点を深くします。賢い人は、自分の直感を支持する論拠を素早く構築できます。反証を巧みに退けられます。結果として、バイアスに基づいた判断を「論理的に正しい」と提示してしまいます。

冒頭の振り返り会議を思い出してください。5人のエンジニアは全員が優秀で、全員が論理的で、全員が「自分の提案が最も合理的だ」と確信していました。確信しているから、他者の提案を「それも一理あるが、自分のアプローチの方が根本的だ」と位置づけます。5人が5人とも同じことをしています。議論が収束しないのは当然です。

正直に告白します。私自身がこの罠の典型にハマっていました。

技術選定の議論で、私は「論理的に正しい（と思い込んだ）選択」を押し通したことがあります。Rust（プログラミング言語）で書くべきだと主張しました。パフォーマンス要件、型安全性、将来のメンテナンス性──それらを「客観的に」分析した結果、Rustが最適だと信じていました。

しかし、実際には「Rustを使いたい」が先にあり、それを正当化する論理を後から組み立てていた。賢さが、この自己欺瞞（じこぎまん）を完璧に偽装してくれました。

「合理的判断」で失うもの

自分のバイアスに気づけない、バイアスを論理で偽装する──こうした「賢さの罠」に陥る原因は2つです。

戦略的無知──自分の信念に反する情報を、意図的に避ける行動です。新しい開発基盤に移行すべきデータがあるのに、見ないことにします。チームのアンケート結果が自分のマネジメントスタイルに否定的だったとき、「回答数が少ないから有意ではない」と退けます。情報が目の前にあるのに、無視します。無知ではなく、戦略です。

機能的愚鈍（ぐどん）──組織の中で批判的思考を停止する圧力です。「なぜこのプロセスが必要なのか」と問うと面倒なことになります。前例に従う方が安全です。異議を唱えると「空気を読めない人」と見なされます。だから考えません。考えないことが、組織内での最適戦略になっています。

チームの中に「なぜ」を問わない空気があるとき、それは個人の知的怠惰ではありません。「なぜ」を問うことにインセンティブがない構造の問題です。「深く考えること」には生産性の定義がなく、「前例に従うこと」が代理指標になります。考えても評価されません。考えなくても評価されます。なら、考えないほうが合理的です。

正直に告白します。私自身、機能的愚鈍（ぐどん）に加担した経験があります。

前職で、明らかに形骸化した承認フローがありました。本番反映の前に3人の承認が必要ですが、全員が中身を見ずにボタンを押していました。「これ、意味ありますか？」と言えば変えられました。しかし言いませんでした。言えば、承認フロー全体の再設計を任されることが目に見えていたからです。言わないことを選んだのは、私の「合理的判断」でした。

その後、何も起きませんでした。承認フローは形骸化したまま回り続け、障害も起きず、誰も困らない。私の判断は結果として「正しかった」ことになります。

ただ、自分の中に小さな澱（おり）のようなものが残りました。あのとき言わなかったことを、ときどき思い出します。何も起きなかったから問題ではない、とは思えなかった。機能的愚鈍の厄介さは、ここにあります。沈黙が罰せられないどころか報われるから、構造は温存される。「合理的判断」と呼んだものの正体は、たぶん、そういうことです。

賢さが壊した現場

賢い人が集まっても問題が解決できない──そこには、あるパターンが隠されています。

個人としては全員が優秀。個人としては全員が正しいことを言っている。しかし、集団としての判断が構造的に歪んでいる。

ここで、私のチームで起きた「2つの罠」を書きます。1つは「データの使い方の罠」、もう1つは「成功体験の罠」です。

まずは「データの使い方の罠」について。私たちのチームは「データドリブン」を標榜（ひょうぼう）していました。主観ではなくデータで判断する。正しいように聞こえます。しかし、ある時期から、私たちの「データドリブン」が実は「確証バイアスドリブン」だったことに気づきました。

確証バイアスとは、自分の仮説を支持するデータだけを集め、反する証拠を無視する傾向です。新機能をリリースした後、KPIが上がったデータだけを報告します。下がった指標は「ノイズ」として無視します。A/Bテストで「有意差あり」の結果が出るまで条件を変えて繰り返します。

もう1つの「成功体験の罠」について。科学界のある分野では「再現性の危機」と呼ばれる問題があります。心理学の有名な実験の半数以上が、追試で再現できませんでした。私たちの職場の「成功事例」も、再現性を検証されていません。

規模は違いますが、私のチームでも同じ構造を経験しました。

オンプレミスで安定稼働していたシステムのクラウド移行を提案したとき、「今うまくいっているのに、なぜリスクを取るのか？」という反論に全員が頷きました。反論は合理的でした。しかし2年後、スケーリングの限界に直面したとき、あの判断を全員が悔やむことになります。成功体験は、未来のリスクを見えなくする遮蔽物（しゃへいぶつ）です。

ある時点で成功した判断が、別の時点でも正しいとは限らない。成功には、時効のようなものがあります。

システム思考の世界に、こういう言い方があります。「システムは部分の振る舞いの総和ではない。部分の相互作用の産物である」。チームも同じです。冒頭の振り返り会議と同じ構造です。個人の知性を足し合わせても、チームの知性にはなりません。5人の知性の「総和」ではなく、5人の「相互作用」が結果を決めます。

集合知はIQで決まらない

では、チームの知性は何で決まるのか。個人の知性が集まっても機能しないなら、チームの知性は何で決まるのか。この問いに答える手がかりがあります。

チームの成績を最も強く予測するのは、メンバーの平均IQではない。効くのは別のものです。

1つは、相手の感情を読み取る力──誰が困っているか、誰が言いたいことを飲み込んでいるかに気づける感受性。もう1つは、発言の平等性──特定の個人が議論を支配せず、全員に発言機会が行き渡っていること。

つまり、チームの知性を決めるのは「誰がいるか」ではなく「どう関わるか」です。

振り返れば当然かもしれません。5人の天才が全員同時に話し、誰も聞いていないチーム。5人の普通の人が順番に話し、互いの発言を受けて考えるチーム。良い判断ができるのは後者です。しかし、私たちは採用のとき「優秀な個人を集めれば強いチームになる」と信じています。個人の能力にばかり注目し、関わり方の構造を見ていません。

第1回のコラムで書いた「あの人が悪い」と同じ構造がここにもあります。「あの人が優秀だからチームが強い」も、「あの人が悪いからチームが弱い」も、どちらも個人に原因を帰属させています。チームの成果は個人の能力の総和ではなく、個人の間の関係性──構造──によって決まります。

ここで1つ、この議論への反論を想定しておきます。「それは賢さの問題ではなく、コミュニケーションの問題だろう」という声です。もっともです。

しかし、賢さが問題を悪化させる固有のメカニズムがあります。普通のコミュニケーション不全は「伝わっていない」ことが原因です。賢い人のコミュニケーション不全は「全員が正しいことを伝えている」のに収束しません。

普通のコミュニケーション不全は、情報を補えば解決します。賢い人のコミュニケーション不全は、全員が十分な情報を持っているのに解決しません。情報ではなく、自分の正しさへの確信が障壁だからです。それは単なる伝達技術では解決しません。

必要なのは「賢い人」ではなく「疑える構造」

ここまでの議論は、IQという物差しでは測れないものに何度も触れてきました。しかし、IQとは別の知性の軸があるのではないか？

知的謙虚さ、感情の制御、直感の較正（自分の直感がどの程度正確かを把握する能力）。「自分は間違っている可能性がある」と疑えること。感情的に反応しそうなときに一歩引けること。「たぶんこうだ」と感じたとき、その「たぶん」の確度を適切に評価できること。

チームに必要なのは「賢い人」ではなく、「賢く疑える人」ではないか？　しかし、「賢く疑える人」を集めれば解決するのか。それもまた「個人の能力に帰属させる」思考ではないか。

もう一歩進めれば、必要なのは「賢く疑える人」ではなく「賢く疑える構造」です。個人が賢く疑える能力を持っていても、組織が疑うことを許さなければ機能しません。冒頭の5人のエンジニアは賢く疑える人だったはずです。しかし、構造がそれを封じました。

さらにもう一歩。「賢く疑える構造」を設計する主体は誰か？

構造を設計するのもまた人間であり、その人間もバイアスを抱えています。つまり、バイアスを持った人間が、バイアスを補正する構造を設計するという再帰的な困難がここにあります。完璧な構造は存在しません。存在しませんが、「自分たちの構造にも盲点がある」と前提に置くこと自体が、構造の一部になり得ます。

ここで、AIと一緒に仕事をしている技術者として、正直に書いておきたいことがあります。

私は日常的にコード生成AIを使っています。設計の壁打ち相手にもします。率直に言って、助かっています。ある種のタスク──既知のパターンの適用、定型コードの生成、大量のドキュメントからの情報抽出──では、人間より速く、しばしば正確です。AIを「脅威」として語りたいのではありません。道具として優れている場面は多い。

ただ、使い込むほど見えてくる特性があります。AIは訓練データのパターンから統計的にもっともらしい出力を生成します。それは「考えている」のとは違います。ある設計判断についてAIに相談すると、整合性のある回答が返ってきます。しかし、その回答が「このチームの文脈で本当に正しいか」を判断するのは、私です。

AIは「この回答は間違っているかもしれない」とは考えません。自己修正の指示を出せば修正しますが、それは「疑った」のではなく「新しい入力に反応した」だけです。

この章で議論してきた「賢さの罠」──自分のバイアスに気づけない、確証バイアスを論理で偽装する──は、人間に固有の問題でした。AIにはバイアスへの自覚そのものがありません。

人間は少なくとも「自分は間違っているかもしれない」と疑える可能性を持っています。半年後にまた同じ過ちを犯すとしても、「あ、今やっている」と気づく瞬間が来得る。その可能性自体が、AIの構造にはないものだと思います。

第1回のコラムでAIが「生産性」の意味を変えつつあると書きました。第2回のコラムで数字の外に意味があると書きました。第3回で少しだけ見えてきたのは、取り戻すべき生産性の輪郭かもしれません。速さでも賢さでもない。「これで正しいのか」と立ち止まれる力──疑うことの生産性、とでも呼べるもの。

AIが速さと正確さを提供してくれる時代に、チームに残る固有の価値は、自分たちの判断を自分たちで疑い、修正し続けられることにあるのではないか。まだ確信はありませんが、そんな気がしています。

おわりに

振り返り会議の場面に戻ります。

5人が5つの方向に走り、30分経っても結論が出ない。あの場で私が試したのは、問いの変更でした。

「誰の提案が正しいか」ではなく、「何がこの結果を構造的に生んだか」と聞き直しました。

すると、議論の質が変わりました。「監視のしきい値」「デプロイ」「基本設計」「テスト」「アラート」──5つの提案は、実は1つの構造の5つの断面だったことが見えてきた。

デプロイ前のテストが不十分で、デプロイ後の監視でカバーしようとしていた。監視が追いつかず、障害が拡大した。根本は「デプロイ前の品質保証とデプロイ後の監視のバランス」という構造の問題でした。5人が個別の断面を正しく指摘していたが、構造を見ていなかった。

同じ5人から、違う答えが出てきました。人は変わっていません。問いが変わった。 問いが変われば、賢さの使い方が変わります。個人の知性は変えられなくても、知性が発揮される構造は設計できます。

ただし、これは成功談として語りすぎるべきではありません。

翌月、別の障害で同じことを試みました。しかし今度は、私自身が5人の当事者の1人で、自分の提案に固執していました。問いを変える側ではなく、変えられる側にいるとき、あの冷静さは持てませんでした。

あの場で問いを変えられたのは、私がたまたまファシリテーターの立場にいたからです。もし私が5人のうちの1人で、自分の提案に確信を持っていたら、同じことができたか。おそらくできなかった。問いを変える権限が誰にあるか──これもまた構造の問題です。

個人の認知を超えた「構造」が必要だ。 個人が疑える能力を持っていても、組織がそれを封じれば機能しません。疑いを構造的に許す仕組み──制度──が要ります。次回は、善意と制度の関係を見ていきます。

第4回を読む

参考資料

↓連載第2回の記事はこちら

↓連載第1回の記事はこちら

SNSシェア

• シェア
• Tweet