はじめに
数年前、私は大きなプロジェクトに取り組んでいました。SREとして、メール配信システムの大規模な障害に直面していました。毎日数百万通のメールを処理するシステムが、突然、配信遅延を起こし始めました。遅延は徐々に悪化し、やがてメールが数時間も届かなくなりました。ユーザーからの問い合わせが殺到しました。経営層からのプレッシャーも増していきました。
いくら調べても原因が分かりません。データベースのクエリを最適化しました。キャッシュを増やしました。サーバーのスペックを上げました。でも、問題は解決しませんでした。設定を何度見直しても、どこがおかしいのか分かりません。
数日間、問題と向き合いました。さまざまな知識を集めました。組み合わせを試しました。でも、決定的な答えは見つかりませんでした。疲れて、その日は諦めて寝ることにしました。
ベッドに入って、目を閉じました。眠れませんでした。頭の中で、断片的な知識がつながり始めました。Webサービスで学んだバックプレッシャー。メールシステムのキューイング。DNSの問い合わせ。これらは別々の領域の知識でした。ところが根本的な構造、同じではないでしょうか。外部リソースへの依存。過剰な要求。システムの過負荷。
そうか、と思った瞬間、はっきりと目が覚めました。メールシステムにバックプレッシャーを適用できます。キューが一定の長さを超えたら、新しいメールの受け入れを制限します。そうすれば、DNS問い合わせの数も自然と制御されます。
眠れなくなりました。頭の中でアイデアが次々と展開されます。実装の方法。監視の設計。エラーハンドリング。そのまま朝まで考え続けました。
朝になって、すぐに検証を始めました。シミュレーションを書きました。小規模な環境で試しました。うまくいきました。
これが、私が異なる分野の知識をつなげる力を実感した瞬間でした。Webとメールという別々の領域を結びつけることで、新しい視点が生まれます。見えなかったものが見えます。できなかったことができます。
しかし一年後、別のプロジェクトで私は再び行き詰まりました。今度は違う理由でした。あまりにも多くのアイデアを詰め込みすぎました。システムが複雑になりすぎたのです。新しい技術、最新のパターン、すべてを取り入れようとしました。つなげることへの夢中になりすぎて、何が本当に必要かを見失っていました。
その時、私は気づきました。つなげることだけが答えではありません。断つことも同じくらい重要なのです。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。
問題解決の8つの段階
あのメール配信システムの問題に戻りましょう。私はどうやって解決策を見つけたのでしょうか。振り返ってみると、問題解決とは、明確な段階を経るプロセスでした。
このプロセスは8つの段階で構成されていました。
- 問いを明確にする
- 大きな問題を小さく分解する
- 関係者の望みを理解する
- 直接関係する分野とその外から知識を集める
- 組み合わせを試しては捨てる
- 意識を手放して無意識へ任せる
- ふとした瞬間にアイデアが出現するのを待つ
- 他者の視点で検証し現実で試す
この8つの段階は順番通りに進むわけではありません。行ったり来たりします。戻ることもあります。1つでも欠けると、あまり良い解決策は生まれません。ただし経験を積むと、いくつかの段階を素早く通過できます。場合によっては飛ばせることもあります。飛ばすことと欠けることは違います。例えば似たような問題を何度も解決していれば、問いの明確化や知識の収集は、ほぼ無意識にできるようになります。
実際、私の問題解決では、これらの段階を何度も行き来しました。知識を集めながら組み合わせを試します。組み合わせを試しながら問いを見直します。他者による検証を受けて問題の分解へ戻ります。一度無意識へ任せた後、また知識を集め直します。第一段階から第八段階まで、順番に一度ずつ進むのではありません。螺旋を描くように、何度も同じ段階を通過します。しかし通過するたびに、理解が深まり、解決策が洗練されていきます。
そして重要なことを言っておきたいです。これは私の問題解決のプロセスです。あなたにはあなたのプロセスがあります。人によって得意な段階も、時間のかけ方も、順序も違います。このプロセスを参考としつつ、自分へ合った形としてカスタマイズしてほしいです。
これから、この8つの段階を1つずつ詳しく見ていきましょう。それぞれの段階で何が起きるのか。どんな落とし穴があるのか。どうすれば効果的に進められるのか。メール配信システムの具体例を使いながら、問題解決のプロセスを解き明かしていきます。
では、第一段階から始めましょう。
第一段階: 解くべき問いを明確にする
最初、私は問題を「メールの配信が遅い」と捉えていました。でも、これは問いではありません。観察の記述です。問いとは、現在と望む未来の間に横たわる溝を、言葉で明確に描くことです。
私は問いの形を変えました。「なぜメールの配信が遅いのか」ではなく、「どうすれば安定して配信できるのか」。そして、溝の幅を測定可能にしました。「99%のメールを5分以内に配信する」。
なぜ測定可能でなければならないのでしょうか。測定できないものは、改善できないからです。「速くしたい」では、どこまで改善すればいいのか分かりません。「5分以内」なら、達成したかどうか判断できます。次に何をすべきか決められます。
問いの輪郭を定めるということは、無限の可能性の空間に、一本の線を引くことです。この線の内側だけを探索し、外側は探索しません。そう決めることです。私は、速度の問題よりも、安定性の問題に意識を向けることを選びました。これは選択であり、同時に放棄でした。
問いが曖昧なら、解もまた曖昧です。問いが明確なら、解の輪郭もまた明確になります。すべては最初の線の引き方で決まります。
でも、ここで重要な認識があります。最適な問いは、最初から設定できません。だから、仮の問いを設定します。進めながら修正します。問い自体を、何度も見直します。問いを固定するのではなく、更新し続ける柔軟さが必要です。
実際、私はこの問いを何度も修正しました。最初は「配信を速くする」でした。でも、関係者と話して（第三段階）、「安定性が重要だ」と気づきました。知識を集めて（第四段階）、「99%」という具体的な数字を設定しました。組み合わせを試して（第五段階）、「5分以内」という時間を決めました。第一段階は、最初に一度やって終わりではありません。他の段階を経ながら、何度も戻ってきて、問いを磨き続けます。
測定可能な目標を設定するとき、私はいくつかの基準を考えました。まず、達成可能性。あまりに高い目標は、チームを疲弊させます。次に、意味のある改善。現状が「10分以内に90%」なら、「9分以内に91%」では意味がありません。そして、ビジネス価値。「5分以内に99%」は、来週のキャンペーンを成功させるのに十分な水準でした。
問いの設定は、プロジェクト全体の方向性を定める基盤です。この段階を急いではいけません。時間をかけて、本当に解くべき問いは何かを考えます。関係者と対話します。現状を分析します。そして、測定可能で、達成可能で、意味のある目標を設定します。
第二段階: 大きな問題を小さく分解する
「安定して配信する」という問いは、まだ1つの塊でした。塊のままでは、手がつけられません。だから、私はそれを構成要素に分解しました。
メール配信システムは、時間軸に沿って展開するプロセスです。受信、キューイング、処理、送信。この連鎖のどこで、時間が失われているのでしょうか。ログを読みました。メトリクスを見ました。そして発見しました。処理の段階で、時間が消えていました。
さらに細かく見ました。処理とは何でしょうか。それは、内容の検証、宛先の解決、サーバーの選択という3つの行為でした。この中のどれが、時間を奪っているのでしょうか。
測定しました。宛先の解決でした。外部のDNSサーバーへの問い合わせが、予想以上に多かったです。そして、その一部がタイムアウトしていました。
分解するとは、全体を部分に還すことです。そして、部分の中に、真の問題を見つけることです。大きな問いは、答えられません。小さな問いは、答えられます。分解の精度が、解決の可能性を決めます。
しかし、分解にも技術がいります。どの粒度で止めるか。細かくしすぎると、全体が見えなくなります。粗すぎると、具体的な行動につながりません。この判断は、経験によって磨かれます。最初は粗く分解します。必要なら、さらに細かく分解します。段階的に進めます。
私は、問題を階層的に整理しました。第一階層：メール配信システム全体。第二階層：受信、キューイング、処理、送信という4つのフェーズ。第三階層：処理フェーズの中の検証、解決、選択という3つのステップ。そして第四階層：宛先解決の中のDNS問い合わせ。
この階層構造を可視化することで、どこに焦点を当てるべきかが明確になりました。そして重要なのは、各階層での問題が、どう他の階層に影響するかを理解することです。
分解した後、もう1つ重要な作業があります。それぞれの部分が、どう影響し合っているかを理解することです。部分を独立したものとして扱うのではなく、システムとして捉えます。宛先の解決が遅いと、キューが詰まります。キューが詰まると、受信も遅くなります。すべてはつながっています。
DNS問い合わせの遅延が、なぜシステム全体の遅延につながるのでしょうか。それは、処理がブロックされるからです。1つのメールがDNS問い合わせを待っている間、次のメールは処理できません。キューに溜まっていきます。やがてキューが溢れます。新しいメールが受け入れられなくなります。この因果関係を理解することで、解決策の方向性が見えてきます。
ただし、この分解も一度ではうまくできませんでした。最初は「処理が遅い」としか分かりませんでした。でも、知識を集めて（第四段階）、ログを詳しく読んで、「DNS問い合わせだ」と特定できました。そして、組み合わせを試す中で（第五段階）、「DNS以外の部分も見直すべきか」と再び分解に戻りました。分解は、一度やって終わりではなく、理解が深まるたびに、より精緻になっていきます。
分解は、分析の技術です。全体を部分に分け、部分の関係を理解し、真の問題を特定します。この段階を丁寧に行うことで、次の段階での探索が効率的になります。
第三段階: 関係者の望みを理解する
ここで重要な認識がありました。私が解決したい問題は、私の問題だけではありません。他者もまた、この問題に関わっています。そして、彼らはそれぞれ異なる視点から、異なる何かを望んでいます。
開発チームは、変化を最小限にすることを望んでいました。なぜなら、大きな変更は、予測できないリスクを生むからです。彼らには、別のプロジェクトもあります。時間は限られています。彼らと話したとき、「システムの根幹を変えるような解決策は避けてほしい」という懸念を聞きました。彼らは安定性を重視していました。
運用チームは、透明性を望んでいました。システムの状態が見えなければ、障害時に対応できません。複雑さは、透明性の敵です。彼らは、夜中に呼び出されることを恐れています。「何が起きているか分からないシステムは、運用できない」と彼らは言いました。彼らには、明確な監視とアラートが必要でした。
ビジネス側は、速度を望んでいました。来週、重要なキャンペーンがあります。それまでに、問題を解決しなければなりません。予算も限られています。「理想的な解決策よりも、来週までに動く解決策が欲しい」と彼らは言いました。彼らには、時間が最も重要でした。
これらの望みは、時に矛盾します。安定性と速度。シンプルさと機能性。理想と現実。でも、解決策とは、これらの矛盾する望みが交差する一点を見つけることです。
すべての視点を無視すれば、解決策は使われません。技術的に優れていても、運用チームが理解できなければ、保守できません。ビジネスの期限に間に合わなければ、価値がありません。1つの視点だけを優先すれば、他の視点から拒絶されます。
だから、私は時間をかけて、それぞれの望みを聞きました。対話しました。どこまで妥協できるか。何が絶対に譲れないか。この対話を通じて、解決策の制約条件が明確になりました。
開発チームとの対話から：「既存のキューシステムを置き換えるのではなく、その上に制御層を追加する形なら受け入れられる」という妥協点が見つかりました。
運用チームとの対話から：「キューの長さ、処理速度、DNS問い合わせ数の3つのメトリクスを可視化すれば、十分に監視できる」という具体的な要件が見えました。
ビジネス側との対話から：「根本的な解決ではなく、段階的な改善でも良い。まず来週のキャンペーンを乗り切れる水準にして、その後さらに改善していく」という現実的なアプローチが決まりました。
そして、制約条件こそが、創造性を引き出します。無限の可能性は、かえって選べません。制約があるから、選べます。「既存システムを大きく変えない」「一週間以内に実装できる」「監視可能な設計にする」という制約が、探索すべき解決策の空間を明確に定義しました。
視点の交差点を見つけることが、実行可能な解決策への道です。そして、この交差点は、対話を通じてしか見つかりません。一人で考えていても、他者の視点は想像できません。実際に話を聞きます。実際に議論します。その過程で、初めて、すべての視点が満足できる解決策の輪郭が見えてきます。
第四段階: 知識を集める - 直接関係する分野と、その外から
問題が明確になりました。制約も理解しました。次は、知識を集める段階です。
私は2つの方向から探索しました。問題に直接関係する分野と、その外です。
問題に直接関係する分野とは、この問題そのものに関する知識です。メールシステムのアーキテクチャ。DNSの仕組み。キューの実装。過去の障害の記録。これらは、問題が存在する領域の全体像です。この全体像を把握することで、何が起きているかを理解できます。
私はまず、過去の障害レポートを読みました。似たような問題は起きていないでしょうか。どう対処したでしょうか。一年前に、小規模な遅延問題がありました。その時はDNSキャッシュを増やして解決したと記録されていました。でも、今回の規模では、同じ解決策は通用しないと分かりました。
次に、メールシステムの実装を読みました。どのライブラリを使っているでしょうか。どんな設定があるでしょうか。キューの実装はどうなっているでしょうか。コードを読むことで、システムの制約と可能性が見えてきました。
しかし、問題に直接関係する分野だけを見ていても、新しい視点は生まれません。なぜなら、その分野の知識で解決できるなら、問題はとうに解決されているはずだからです。
だから、その外を探索します。別の分野で、構造的に似た問題は、どう解決されたでしょうか。
Webサービスでは、外部APIへのアクセスが過剰になった時、どう対処するのでしょうか。バックプレッシャーという概念を使います。流量を制御します。負荷が高い時、新しい要求を受け入れるのではなく、意図的に待機させます。そうすることで、システム全体の崩壊を防ぎます。
私はバックプレッシャーについて、以前のプロジェクトで学んでいました。外部の決済APIが遅くなった時、同僚がその仕組みを実装するのを見ました。その時は「Webではこういう手法があるのか」と理解しました。でも、それはWebサービスの話だと思っていました。メールシステムには関係ない、と。
でも、ある夜、ベッドの中で考えていて、気づきました。構造は同じです。Webの外部API呼び出しも、メールのDNS問い合わせも、外部リソースへの依存という点では変わりません。分野が違うだけで、本質的な問題は同じでした。
データベースでは、書き込みが多すぎる時、どうするのでしょうか。バッチ処理を使います。個々の書き込みではなく、まとめて書き込みます。これも、私が以前のプロジェクトで学んだパターンでした。
ネットワークでは、パケットが多すぎる時、どうするのでしょうか。キューイングとドロップを使います。これは、大学時代にネットワークの授業で習った内容でした。当時は理論として学んだだけで、実践で使うとは思っていませんでした。
この原理は、分野を超えて適用できます。なぜなら根本的な構造が同じだからです。外部リソースへの依存。過剰な要求。システムの過負荷。これはWebやメール、データベース、ネットワークといった異なる領域においても、本質的には同じ問題です。
別の分野から持ち帰った概念を、今の問題の文脈に翻訳します。これが、問題解決の核心です。既存の要素を、新しい形でつなげること。
私はノートに書き出しました。左側に「メールシステムの問題」。右側に「別の分野の解決策」。そして、線でつないでいきました。DNS問い合わせの過剰とAPI呼び出しの過剰。キューの詰まりとネットワークの輻輳。処理の遅延とデータベースの書き込み遅延。
ところがここで注意すべきことがあります。すべての情報を集めることはできません。無限の時間をかければ、無限の情報が集まります。ただし時間は有限です。だから選びます。何を集めるか。何を集めないか。
私は、課題に直接関係する情報を優先しました。「面白いけど、今回は関係ない」情報は、後回しにしました。例えば、メールの暗号化技術についての記事を見つけました。興味深かったですが、今回の遅延問題には関係ありません。ブックマークはしましたが、深く読むのはやめました。
サンクコストの罠へは陥らないようにしました。「ここまで読んだから最後まで読もう」ではなく、「関係ないと分かったから、ここで止める」という判断を何度も繰り返しました。
情報収集には終わりがありません。だから、どこかで線を引きます。「これだけ集めれば十分」と判断します。この判断の基準は何でしょうか。それは、次の段階に進めるかどうかです。組み合わせを試すのに十分な要素が揃ったでしょうか。揃ったと感じたら、次に進みます。足りないと感じたら、もう少し集めます。
私は、知識を集めながら、頭の中で組み合わせを試し始めていました。そして、組み合わせを試すうちに、「この情報が足りない」と気づいて、また知識を集めに戻ります。第四段階と第五段階を何度も行き来しました。三日間、この往復を繰り返しました。
第五段階: 組み合わせを試しては捨てる
知識が集まりました。次は、それらを組み合わせる段階です。
私の前には、無数の可能性が広がっていました。A、B、C。それぞれ単独で使うこともできます。組み合わせることもできます。AとB。AとC。BとC。AとBとC。さらに、実装の詳細によって、それぞれの組み合わせは無限の変種を持ちます。
可能性の空間は、想像を超えて広いです。すべてを試すことは不可能です。だから、歩く道を選ばなければなりません。
A：DNSキャッシュの増強。以前の障害でうまくいった方法です。でも、今回の規模では不十分だと直感していました。
B：バックプレッシャーの導入。キューが一定の長さを超えたら、新しいメールの受け入れを制限します。Webサービスで有効だったパターンです。
C：非同期処理の最適化。DNS問い合わせを並列化して、待ち時間を減らします。
私は頭の中で、1つずつ試しました。AとBをつなげます。どうなるでしょうか。DNSキャッシュを増やし、同時にバックプレッシャーで流量を制御します。効果はありそうです。でも、持続可能でしょうか。キャッシュは、メモリを消費します。無限に増やせません。そして、DNSの情報は変化します。キャッシュが古くなったら、間違った宛先に送ってしまいます。リスクが高いです。
じゃあAとCは。DNSキャッシュを増やし、非同期処理を最適化します。処理は速くなります。でも、根本的な問題は解決しません。DNS問い合わせ自体の数は減りません。外部のDNSサーバーへの負荷は変わりません。一時的には改善するかもしれませんが、負荷が増えれば、また同じ問題が起きます。
BとCは。バックプレッシャーで流量を制御し、非同期処理を最適化します。面白いです。流量が制御されれば、DNS問い合わせの数も自然と減ります。そして、非同期処理で、個々の問い合わせも速くなります。この組み合わせは、有望です。
この探索の過程で、重要なことに気づきます。ほとんどの組み合わせは、うまくいきません。1つ試して、うまくいかないから捨てます。また1つ試して、やはりうまくいかないから捨てます。その時は「ちょっと試しただけ」に感じます。しかしこの小さな捨てるを繰り返していると、気づいたら膨大な数の組み合わせを試して捨てています。毎日コンビニで小さな買い物をしていたら、数ヶ月後に気づいたら20万円使っていたような感覚です。1つ1つは大したことないですが、積み重なると大きいです。
でも、この失敗の積み重ねが、最終的な成功を導きます。なぜなら、失敗することで、何がうまくいかないかが分かるからです。そして、それは何がうまくいくかを知る手がかりになります。
私は、さらに細部を検討しました。BとCの組み合わせが良さそうです。でも、どう実装するでしょうか。
バックプレッシャーを、どのレベルで実装するでしょうか。受信の段階でしょうか。キューイングの段階でしょうか。処理の段階でしょうか。それぞれの選択肢を考えました。受信の段階での制限は、メール喪失のリスクを伴います。送信元へエラーを返すことになります。これは避けたいです。キューイングの段階を適切と判断しました。キューへ入れる前に、キューの長さをチェックします。長すぎたら一時的な受け入れ遅延を実施します。
キューの長さの閾値を、どう設定するでしょうか。1000通でしょうか、5000通でしょうか、10000通でしょうか。この数字は、システムの処理能力とメモリ容量から決まります。メトリクスを見ました。通常時のキュー長は1000通以下でした。ピーク時で3000通程度でした。閾値を5000通に設定すれば、通常時は影響せず、異常時だけ制御できます。
非同期処理を、どう最適化するでしょうか。DNS問い合わせを並列化します。しかし何個まで並列化できるでしょうか。並列度が高すぎると、DNSサーバーへ負荷をかけすぎます。最適なバランスを見つける必要があります。
可能性の空間を歩くとは、ほとんどの道を捨てることです。残った一本の道を、さらに磨くことです。そして、この過程は、決して直線的ではありません。行ったり来たりします。戻って、別の道を試します。時には、最初の分岐点まで戻ります。迷路を歩くように、試行錯誤を繰り返します。
BとCの組み合わせに絞りました。でも、まだ確信は持てません。頭の中でシミュレーションします。キューが5000通を超えます。新しいメールの受け入れが遅くなります。その間、処理は進みます。非同期処理が最適化されているから、処理は速いです。キューが減ります。また受け入れが再開します。
うまくいきそうです。しかし本当にうまくいくかは、実装してみないと分かりません。実装してみたら新しい疑問が出てきます。「閾値は本当に5000で良いのか」。そう思って、また問いへ戻ります（第一段階）。「監視はどうするか」。そう考えて関係者と話します（第三段階）。組み合わせを試す段階は、あらゆる段階への入り口です。
次の段階へ進む前に一度休憩します。疲れてきました。
第六段階: 意識を手放して無意識に任せる
探索を続けていると、疲労が蓄積します。思考が鈍ります。どの組み合わせを試しても、前に進んでいる気がしません。行き詰まります。
このとき、最も逆説的で、最も効果的な行為があります。それは、問題を手放すことです。
私は、その日の夜、問題を意識の外に置きました。夕食を作りました。ゆっくり食べました。映画を見ました。早めに寝ました。問題について考えないように、意識的に努力しました。
「今日の自分には解けない。明日の朝の自分に任せよう」。そう決めました。深夜まで考え続けても、疲れた頭では良い答えは出ません。むしろ、間違った方向に固執してしまいます。だから、意識的に諦めます。今の自分ではなく、明日の自分に託します。
なぜこれが重要なのでしょうか。意識は、強力ですが制約も多いです。意識は、一度に1つのことしか考えられません。逐次的です。線形です。そして、既存の思考パターンに縛られます。「こうあるべきだ」という規範に従います。「前回はこうだった」という経験に引きずられます。
私が「DNSキャッシュを増やすべきだ」と一度考えると、その思考パターンから抜け出しにくくなります。意識は、その方向に固執します。別の可能性を見落とします。
でも、無意識は、そういう制約を受けません。無意識は、並列に、複数の可能性を同時に探索できます。規範に縛られません。自由につながりを試せます。時には、意識が「不可能だ」と判断したつながりも試します。
意識の支配を手放すとは、無意識という、より広大な処理能力に、問題を委ねることです。そして、無意識が何かを見つけたとき、それは閃きとして、意識に返されます。
でも、誤解してほしくないのは、無意識に任せるためには、その前に十分な準備が必要だということです。知識を集めなければ、無意識は何も組み合わせられません。組み合わせを試さなければ、無意識は探索の方向が分かりません。意識的な努力の後に、初めて、無意識の並列処理が効果を発揮します。
私は、三日間、問題と向き合いました。知識を集めました。組み合わせを試しました。そして、疲れました。その疲労が、意識を手放すサインでした。「ここまでやった。あとは明日の自分に任せる」。そう決めることで、心が軽くなりました。
その日の夜、私は諦めて寝ることにしました。でも、実際には、諦めたのではありませんでした。意識的な努力を手放して、無意識に問題を委ねただけでした。そして、その無意識が、ベッドの中で答えを見つけることになります。
休憩の仕方にも、技術があります。意識的に問題から離れます。仕事の話をしません。メールをチェックしません。コードを見ません。別のことに意識を向けます。料理をします。散歩をします。音楽を聴きます。体を動かします。
睡眠も重要です。睡眠中、脳は情報を整理します。記憶を統合します。つながりを再構成します。十分な睡眠なしに、創造的な思考は生まれません。明日の朝の自分が答えを見つけるためには、今日の夜、しっかり眠ることが必要です。
ただし、今回の私のように、眠ろうとした瞬間にアイデアが出現することもあります。それもまた、無意識の働きです。
第七段階: ふとした瞬間にアイデアが出現する
その日の夜、ベッドに入りました。疲れていました。早く眠りたかったです。でも、目を閉じた瞬間、それは起きました。
突然、アイデアが浮かびました。というより、アイデアは常にそこにあって、ただ私がそれを認識していなかっただけだという感覚でした。
メール処理のキューにバックプレッシャーを実装します。キューが一定の長さを超えたら、新しいメールの受け入れを制限します。同時に、非同期処理を最適化して、DNSキャッシュを効率的に使います。そうすれば、DNSへの問い合わせ数が自然と制御されます。
これです。BとCの組み合わせです。Aは不要でした。DNSキャッシュを増やすのではなく、システム全体の流量を制御することで、結果的にDNSへの負荷を減らします。
そして、もう1つ重要なことに気づきました。バックプレッシャーと非同期処理は、互いに補完し合います。バックプレッシャーが流量を制御します。その制御された流量の中で、非同期処理が効率的に動きます。並列度を上げすぎる心配がありません。なぜなら、そもそも流量が制限されているからです。
はっきりと目が覚めました。もう眠れません。頭の中で、次々とアイデアが展開されます。監視の方法。アラートの設定。エラーハンドリング。実装の手順。キューの閾値は5000でしょうか。いや、動的に変えるべきでしょうか。運用チームには何を伝えるべきでしょうか。
ベッドから出ました。ノートを開きました。すべて書き出しました。なぜなら、この種のアイデアは、すぐに忘れてしまうからです。夢のように、掴んだと思った瞬間に、すり抜けていきます。
朝まで眠れませんでした。でも、それで良かったです。朝になったら、すぐに検証を始めました。
アイデアの出現は、予測できません。意図して起こせるものでもありません。でも、条件を整えることはできます。知識を集めます。組み合わせを試します。疲れたら手放します。そして、無意識に任せます。この一連のプロセスを経ることで、アイデアが出現する確率は高まります。
寝る前、散歩をしている時、眠りから覚める瞬間。これらの状態に共通するのは、意識が緩んでいることです。意識の統制が弱まっています。だから、無意識からのメッセージが、意識に届きやすくなります。
つながりは、探すものではありません。出現するのを待つものです。そして、出現した時、それを逃さずに捕まえるものです。
第八段階: 他者の視点で検証し、現実で試す
朝になりました。一睡もしていませんでしたが、頭は冴えていました。アイデアが出現しました。でも、それは原石です。そのままでは使えません。研磨する必要があります。
まず、自分で検証しました。シミュレーションを書きました。人工的に大量のメールを生成し、さまざまな閾値を試しました。3000通、5000通、10000通。それぞれの場合で、システムがどう振る舞うか観察しました。
そして、他のエンジニアに説明しました。特に、メールシステムに詳しくない人を選びました。なぜなら、彼らは私の前提を共有していないからです。彼らの視点は、私の盲点を照らします。
説明しながら、言葉に詰まりました。「ここで、バックプレッシャーが...」。どう説明すればいいのでしょうか。自分でも理解が曖昧だと気づきました。
「なぜバックプレッシャーが必要なのか」と聞かれました。改めて考えました。根拠を整理しました。論理を組み立て直しました。「DNSの問い合わせが多すぎるから」ではありません。「システム全体の過負荷を防ぐため」だと理解し直しました。
別のエンジニアが聞きました。「キューが5000通を超えたら制限するって言ったけど、その5000という数字はどこから来たの」
良い質問でした。私は、朝のシミュレーションで決めたと説明しました。しかし彼は納得しませんでした。「シミュレーションを見たっていうけど、それは通常時のトラフィックでしょ。今回は異常時の話だから、通常時のデータだけで決めていいの」
確かに。さらにデータを集めました。実際のトラフィックパターンで検証しました。
5000通が適切だと確認できました。でも、さらに重要な発見がありました。閾値を固定するのではなく、動的に調整した方が良いということです。システムの処理能力は、時間帯によって変わります。夜間は処理能力が高いです。昼間は低いです。固定の閾値ではなく、処理能力に応じて変化する閾値の方が効果的です。
これは、他者との対話から生まれた改善でした。一人で考えていたら、気づかなかったです。
批評とは、他者の視点を通じて、自分の認識を修正するプロセスです。他者の問いが、自分の理解の穴を教えてくれます。他者の疑問が、自分の論理の弱点を示してくれます。
そして、小規模な環境で実装しました。理論は現実と出会いました。新しい問題が見つかりました。キューが溢れた時の処理。監視メトリクスの設定。エラーハンドリング。ログの出力形式。アラートの閾値。1つずつ解決しました。
理論的には正しくても、実装すると問題が出ます。だから、試します。問題が出たら、修正します。この反復を通じて、アイデアは研磨されます。原石は、使える形になります。
実装の過程で、さらに気づいたことがあります。BとCの組み合わせだけでは不十分でした。監視（D）も必要でした。キューの長さを可視化しなければ、バックプレッシャーが機能しているか分かりません。アラート（E）も必要でした。問題が起きた時、すぐに気づけなければ意味がありません。
運用チームと話しました（第三段階に戻りました）。「どんなメトリクスが必要か」と聞きました。彼らは、3つのグラフを要求しました。キューの長さの推移。処理速度の推移。DNS問い合わせ数の推移。そして、アラートの条件も具体的に提示してくれました。
これらを実装するために、また知識を集め直しました（第四段階に戻りました）。監視ツールの使い方。メトリクスの設計。アラートの設定方法。そして、これらを組み合わせて（第五段階に戻りました）、全体の設計を修正しました。
最初の設計は、実装を通じて進化しました。最終的な解決策は、最初のアイデアよりも複雑でした。しかしより現実的で堅牢でした。第一段階から第八段階まで、私は何度も行き来しました。その往復のたびに解決策は磨かれていきました。
批評という研磨を経て、アイデアは現実で機能する解決策になります。そして、この研磨のプロセスこそが、問題解決の本質です。洗練されたアイデアが突然生まれるのではありません。粗いアイデアを、何度も磨いて、ようやく使える形になります。
解決策の完成
これらの段階を経て、私は解決策を実装しました。バックプレッシャーを導入し、非同期処理を最適化しました。結果、メールの配信遅延は解消されました。99%のメールを5分以内での配信が可能になりました。
そして、来週のキャンペーンも、問題なく乗り切ることができました。
振り返ってみると、私は8つの段階を何10回も行き来しました。問いを明確にして分解します。知識を集めて組み合わせを試します。そこで行き詰まり、問いへ戻ります。関係者と話して新しい制約へ気づきます。知識を集め直します。無意識へ任せてアイデアが出ます。検証して問題を発見し分解へ戻ります。
この螺旋を描くような往復が、解決策を洗練させていきました。最初の問い「配信を速くしたい」は、最終的に「99%のメールを5分以内に安定して配信する」になりました。最初のアイデア「DNSキャッシュを増やす」は、最終的に「バックプレッシャーと非同期処理の組み合わせ」になりました。
異なる分野の知識をつなげることで、問題は解決できます。でも、やみくみにつなげるだけでは、解決しません。
問いの輪郭を定めます。全体を断片に還します。視点の交差点を見つけます。直接関係する分野とその外から知識を集めます。可能性の空間を歩きます。意識の支配を手放します。つながりの出現を待ちます。批評という研磨を経ます。
これらの段階を何度も行き来して、初めて、本当に価値のある解決策が生まれます。問題解決とは、プロセスです。偶然ではなく、必然です。そして、このプロセスを理解し、意識的に実践することで、誰でも効果的な問題解決ができるようになります。
なぜ私たちはつながりを見出すのか
私自身の人生を振り返ると、つながりを見出すことは、喜びそのものでした。
プログラミングを学び始めた頃、初めてループと配列をつなげて理解できた瞬間。「ああ、こうやって使うのか」と気づいた時の興奮。今でも覚えています。それまで、ループと配列は別々の概念でした。でも、ループで配列の要素を1つずつ処理できると理解した時、2つの概念がつながりました。霧が晴れるような感覚でした。
データ構造とアルゴリズムをつなげて、効率的なコードが書けた時の達成感。最初、私はアルゴリズムを理論として学んでいました。でも、実際のコードで使ってみると、実行速度が劇的に改善しました。O(n²)からO(n log n)への変化を、体感として理解できました。理論と実践がつながった瞬間でした。
別の言語を学んで、以前の言語との共通点を発見した時の「そういうことか」という驚き。Go言語からRustに移った時、最初は戸惑いました。でも、所有権やライフタイムといった概念を理解した時、メモリ管理の本質が見えました。Go言語でガベージコレクションに任せていたことを、Rustでは明示的に制御します。異なるアプローチですが、根本的な問題は同じだと気づきました。
チーム開発で、エンジニアの視点とデザイナーの視点をつなげて、より良いユーザー体験を作れた時。私は、機能が動けば良いと思っていました。でも、デザイナーと一緒に仕事をして、ユーザーがどう使うかを考えるようになりました。技術的な実装とユーザー体験がつながりました。そして、より良いプロダクトが生まれました。
ビジネスの要求と技術的な制約をつなげて、実現可能な解決策を見つけた時。最初、ビジネス側の要求は「無理だ」と判断することが多かったです。ところが対話を重ねるうちに、本当に必要なことが見えてきました。技術的な制約の中で、ビジネスの価値を最大化する方法を見つけられました。
異なるバックグラウンドを持つ人たちと議論して、自分一人では思いつかなかった視点を得た時。インフラエンジニア、フロントエンドエンジニア、データサイエンティスト。それぞれが異なる視点を持っています。その視点をつなげることで、より包括的な解決策が生まれました。
これらの瞬間は、純粋に楽しかったです。新しいつながりを見つけることは、謎が解けることです。霧が晴れることです。世界が少し明確になることです。そして、それは課題解決にも直結しました。
問題に直面した時、別の分野の知識とつなげることで解決できた経験は数え切れません。インフラの問題を、Webの知見で解決しました。あのメール配信システムの問題がそうでした。パフォーマンスの問題を、データベース設計の知識で解決しました。遅いクエリを、インデックスの最適化で改善できました。チームの問題を、プロダクト開発の経験で解決しました。スプリントの進め方を、別のチームのやり方を参考に改善できました。
つながりを見出すことは、私にとっての喜びであり、学びの源泉であり、課題解決の手段でした。
この喜びが、私たちを新しい発見へと駆り立てます。課題解決の源泉になります。
でも、生成AIの時代には、何が変わったのか
しかし、生成AIが誕生した今、状況は変わりつつあります。
ChatGPTやClaudeに問いを投げると、瞬時に答えが返ってきます。知識を集める段階が、数秒で終わります。組み合わせを試す段階も、AIが代わりにやってくれます。アイデアの出現を待つ必要もありません。すぐに解決策が提示されます。
確かに、速いです。効率的です。でも、何かが失われています。
それは単に「喜びを失う」という話ではありません。もっと本質的な問題があります。
AIが提示するつながりは、AIの文脈でのつながりです。私の文脈でのつながりではありません。
私がループと配列をつなげた時、それは私のコードの中で、私の問題を解決するために、つながりました。私の手を動かして、私のエラーを見て、私の頭で理解しました。だから、次に似た問題に出会った時、自分でつなげられます。
でも、AIの答えをそのまま使うと、そのつながりは私のものになりません。AIがどうやってつなげたのか、なぜそうつなげたのか、私の文脈では本当に正しいのか、分かりません。そして、次に似た問題に出会った時、また同じようにAIに聞くしかありません。
これは、この文章で語ってきた8つの段階との関係で考えると、より明確になります。
第一段階の「問いを明確にする」。AIに曖昧な問いを投げても、それなりの答えが返ってきます。だから、問いを明確にする訓練ができません。でも、問いが曖昧なら、答えもまた曖昧です。AIが返した答えが、本当に自分が求めていた答えなのか、判断できません。
第二段階の「問題を分解する」。AIは既に分解された答えを返します。だから、どう分解されたのか、なぜそう分解されたのか、自分の問題にとって適切な分解なのか、分かりません。
第三段階の「関係者の望みを理解する」。これはAIには絶対にできません。私のチームの運用チームが何を恐れているか、ビジネス側が本当に求めているものは何か、AIは知りません。でも、AIの答えをそのまま使うと、この段階を飛ばしてしまいます。
第四段階の「知識を集める」。AIは既に知識を持っています。だから、自分で知識を集める必要がありません。でも、自分で集めないと、どの知識が重要か、どの知識が自分の文脈に合うか、判断できません。
第五段階の「組み合わせを試す」。AIは最適な組み合わせを提示します。でも、なぜ他の組み合わせがダメなのか、自分で試していないから分かりません。そして、断つべき組み合わせを自分で見極める能力が育ちません。
第六段階の「無意識に任せる」。AIに聞けば瞬時に答えが出ます。だから、無意識が働く時間がありません。でも、無意識の並列処理こそが、意外なつながりを生み出します。
第七段階の「アイデアが出現する」。AIがアイデアを提示します。でも、それは私のアイデアではありません。私の頭の中でつながりが出現する瞬間を、経験できません。
第八段階の「検証する」。これが最も重要です。AIの答えを検証せずに使うと、間違った答えに気づけません。でも、検証するためには、前の7つの段階を理解している必要があります。
プロセスが圧縮されすぎて、各段階で得られる学びが失われます。そして、最も危険なのは、つながりを断つ能力が育たないことです。
AIの答えには、全てがつながっているように見えます。でも、実際には、自分の文脈に合わない部分があります。複雑すぎる部分があります。不要な部分があります。それらを断つ必要があります。でも、自分でつなげる経験がないと、何を断つべきか判断できません。
この文章で語ってきたように、問題解決とは、つなげることと断つことの往復運動です。でも、AIに全てを任せると、つなげることだけが起きて、断つことが起きません。そして、つながりすぎた複雑な解決策を、そのまま実装してしまいます。あの失敗したプロジェクトと同じことが起きます。
では、生成AIの時代に、どうすればいいのでしょうか。
AIを、対話の相手として使います。答えを得るのではなく、自分の考えを確認するために使います。
第一段階で、問いを明確にした後、AIに聞きます。「この問いは明確か」と。AIの答えを見て、自分の問いを修正します。
第二段階で、問題を分解した後、AIに聞きます。「この分解は適切か」と。AIの分解と比較して、自分の分解を見直します。
第四段階で、知識を集めた後、AIに聞きます。「他にどんな知識があるか」と。AIが提示した知識の中から、自分の文脈に合うものを選びます。合わないものは断ちます。
第五段階で、組み合わせを試した後、AIに聞きます。「この組み合わせは有効か」と。AIの答えを見て、自分が見落としていた組み合わせに気づきます。でも、最終的には自分で判断します。
第八段階で、検証する時、AIに聞きます。「この設計の問題点は何か」と。AIが指摘した問題を、自分で検証します。そして、必要なら修正します。
重要なのは、AIの答えをそのまま使わないことです。AIの答えを、自分の文脈に翻訳します。自分の制約条件に合わせて修正します。不要な部分を断ちます。そして、自分の頭で理解してから、使います。
ここで、もう1つ重要な洞察があります。AIと書籍では、知識の与え方が根本的に違います。
AIは、私の質問に答えます。私が「ループとは何か」と聞けば、ループについて教えてくれます。私が「配列とは何か」と聞けば、配列について教えてくれます。でも、AIは「次にどういう質問をすべきか」を教えてくれません。私の文脈で、私の質問に、答えるだけです。
一方、書籍は違います。著者が、入門者に対して、「この順番で学べば、つながりが見えてくる」という道筋を設計しています。最初にループを説明します。次に配列を説明します。そして、ループと配列を組み合わせる例を示します。この順番には、意味があります。著者が何年もかけて習得した知識を、どういう順序で、どういうつながりで学べば理解できるか、深く考えて構成されています。
書籍は、知識そのものだけでなく、知識のつながりの構造を教えてくれます。
AIに「ループと配列をどう組み合わせるか」と聞けば、答えは返ってきます。でも、なぜループの後に配列を学ぶべきなのか、なぜその逆ではないのか、この2つの概念がどう関連しているのか、その関連性を理解するためには何を知っておくべきか、そういう「メタ的なつながり」は教えてくれません。
これは、この文章で語ってきた8つの段階との関係で、より深刻な問題になります。
第一段階の「問いを明確にする」。書籍を読むと、著者が「こういう問いを立てると良い」という例を示してくれます。章立てそのものが、問いの構造を示しています。でも、AIに質問すると、自分が立てた問いにしか答えてくれません。「次にどういう問いを立てるべきか」は、自分で考えなければなりません。
でも、初学者は、次にどういう問いを立てるべきか、分かりません。だから、同じような質問を繰り返したり、重要な問いを見逃したりします。書籍なら、著者が「この章の後は、こういう問いが生まれるはずだ。だから次の章でそれに答える」という構成を作っています。
第二段階の「問題を分解する」。書籍は、複雑な問題をどう分解するかの例を示してくれます。章が進むごとに、徐々に複雑な問題に取り組んでいきます。その過程で、分解の技術を学べます。でも、AIに質問すると、既に分解された答えが返ってきます。分解のプロセスは見えません。
第四段階の「知識を集める」。書籍は、どういう知識を、どういう順番で集めるべきか、道筋を示してくれます。関連する知識への参照を示してくれます。でも、AIは、質問された知識だけを返します。「この知識を理解するためには、先にあの知識を学ぶべきだ」という構造は見えません。
AIは、点で答えます。書籍は、線で教えます。
点だけを集めても、線にはなりません。自分で点をつなげなければなりません。でも、どう点をつなげるべきか、初学者には分かりません。だから、間違ったつなげ方をしたり、つなげるべき点を見逃したりします。
書籍は、著者が既につないだ線を見せてくれます。その線をなぞることで、つなげ方を学べます。そして、次に別の点に出会った時、自分でつなげられるようになります。
もちろん、AIにも利点はあります。自分の文脈に特化した答えが得られます。書籍にない最新の情報が得られます。対話的に質問を深掘りできます。でも、知識のつながりの構造を学ぶためには、書籍の方が優れています。
だから、私は両方を使います。書籍で、知識のつながりの構造を学びます。どういう順番で学べば理解できるか、著者の道筋をたどります。そして、その構造を理解した上で、AIで具体的な疑問を解消します。自分の文脈に合わせた応用例を聞きます。
書籍が線なら、AIは点です。線を理解してから、点を集めます。点だけを集めても、線は見えません。でも、線を理解していれば、点をどこに配置すべきか分かります。
生成AIの時代だからこそ、書籍の価値が高まります。AIは答えを速く返してくれますが、答えに至る道筋は示してくれません。書籍は遅いですが、道筋を示してくれます。その道筋こそが、つながりを見出す能力を育てます。
AIは、8つの段階を圧縮してしまいます。だから、意識的に8つの段階を経験する必要があります。AIを使いながらも、問いを明確にする時間を持ちます。知識を集める時間を持ちます。組み合わせを試す時間を持ちます。無意識に任せる時間を持ちます。
そして、つながりを断つ訓練を、意識的に行います。AIの答えの中から、「これは自分の文脈には合わない」と判断して、断ちます。「これは複雑すぎる」と判断して、シンプルにします。「これは不要だ」と判断して、削除します。
生成AIは、強力なツールです。うまく使えば、問題解決を加速できます。でも、全てを任せると、つながりを見出す能力も、つながりを断つ能力も、両方失います。
だから、自分の頭でつなげます。AIに任せません。そして、自分の文脈で断ちます。AIの答えを鵜呑みにしません。
速さだけを求めるのではなく、理解の深さを求めます。効率だけを求めるのではなく、没入する時間を確保します。AIを使いながらも、8つの段階を意識的に経験します。
それが、生成AIの時代に、つながりを見出し続けるための道です。
異なる領域を結びつけることで、新しい価値が生まれる
プログラミングを始めた頃、私は1つの言語しか知りませんでした。それでコードを書いていました。でも、別の言語を学んだ時、視野が広がりました。「ああ、こういう書き方もあるのか」。そして、1つの言語で学んだパターンを、別の言語で応用できることに気づきました。
チーム開発を始めた時、私はエンジニアしか知りませんでした。でも、デザイナーと働き始めた時、視点が変わりました。「なるほど、ユーザーはこう見ているのか」。ビジネス側の人と話した時、優先順位の付け方が変わりました。「そうか、これが重要なのか」。
異なる視点をつなげることで、理解が深まります。問題の本質が見えます。解決策が生まれます。
これは、つながりの本質です。アイデアとは、既存の要素の新しい組み合わせです。まったく新しいものなど、存在しません。すべては、既存の要素を、新しい方法でつなげたものです。でも、その組み合わせ方が新しければ、それは価値ある解決策になります。
つなげてください。異なる知識を。異なる視点を。異なる人々を。つなげることで、世界は進歩します。
でも、私は間違った
その大きなプロジェクトに戻りましょう。つながりの力を知った私は、すべてをつなげようとしました。最新の技術を学びました。新しいパターンを適用しました。異なる領域のベストプラクティスを取り入れました。マイクロサービス、イベント駆動、関数型プログラミング、リアクティブプログラミング。すべてを組み合わせました。設計は美しかったです。紙の上では理想的でした。
でも、実装を始めると、問題が次々と出てきました。複雑すぎて、誰も理解できません。デバッグに膨大な時間がかかります。新機能の追加が困難になります。パフォーマンスは改善しましたが、開発速度は大幅に低下しました。チームは疲弊していきました。
私は混乱しました。すべてを正しくつなげたはずでした。最適な技術を選び、最新のパターンを適用し、ベストプラクティスに従いました。なぜ、うまくいかないのでしょうか。
数週間悩んだ後、私はある事実に気づきました。問題は、つなげすぎたことでした。必要ないものまでつなげました。複雑にする必要のないところを複雑にしました。そして何より、間違った前提を断てなかったことが問題でした。
私は「最新の技術は優れている」という前提を疑いませんでした。「複雑なアーキテクチャは柔軟性をもたらす」と信じ込みました。でも、これらの前提は、私たちのプロジェクトには合っていませんでした。チームは小さく、変更は頻繁で、複雑さを管理するリソースはありませんでした。シンプルなアプローチの方が、遥かに適していました。
つなげることに夢中になりすぎて、断つべきものを見逃していました。そして、もっと根本的な問題がありました。学んだことを、アンラーンできなかったのです。
アンラーンとは、学習を解除することです。一度学んだ知識や信念を、意識的に手放すことです。これは、新しいことを学ぶよりも難しいです。なぜなら、学んだことは、自分の思考の一部になっているからです。それを疑うことは、自分自身を疑うことになります。
私は、過去のプロジェクトで学んだパターンを持っていました。「大規模システムではマイクロサービスが有効だ」「イベント駆動は疎結合をもたらす」。これらは、確かに正しい状況もあります。でも、すべての状況で正しいわけではありません。
過去の成功体験は、時に次の失敗の原因になります。以前うまくいったアプローチが、今回もうまくいくとは限りません。でも、人間は過去の成功を手放すことが難しいです。「これで成功したのだから、今回も使うべきだ」と考えてしまいます。
アンラーンは、新しい知識を得る前に、古い知識を疑うことです。「この知識は、今の状況に本当に適用できるのか」と問うことです。そして、適用できないと分かったら、躊躇なく手放すことです。
その時、私は理解しました。つなげることだけが答えではありません。もう半分は、断つことです。そして、断つためには、まずアンラーンすることが必要なのです。
つながりを断つことは技術である
つなげることは本能ですが、断つことは技術です。
一度見出したパターンを否定することは、本能に反します。「これとこれは関係がある」と信じているものを、「いや、関係ない」と認めることは、認知的な苦痛を伴います。既に投資した時間と労力が無駄になります。自分の判断が間違っていたと認めなければなりません。
断つことは、本能ではありません。技術です。意識的に訓練しなければ、身につきません。
コードを書いていて、ある実装に三時間かけたとします。でも、レビューで別のアプローチの方が良いと指摘されます。この時、人間の本能は「三時間を無駄にしたくない」と抵抗します。でも、優れたエンジニアは躊躇なく捨てます。三時間のサンクコストより、今後何年も保守されるコードの品質の方が重要だと知っているからです。
つながりを断つ技術を持っていない人間は、一度つなげたものを手放せません。そして、つながりはどんどん増えていきます。最初は小さな勘違いだったものが、関連する情報を次々と取り込んで、巨大な信念体系になります。そして、その信念体系全体を否定することは、もはや不可能になります。
この現象は、エンジニアリングの世界だけでなく、あらゆる分野で起きます。医療の診断、ビジネスの意思決定、人間関係の理解。そして、最も極端な形で現れるのが、陰謀論です。
つながりを断つ技術がないと、どうなるでしょうか。陰謀論という極端な例を見れば、その危険性がよく分かります。
物語に囚われるということ
陰謀論や物語に深く囚われている人間を観察していて気づいたことがあります。彼らは新しいつながりを作ることが得意です。一見無関係な出来事から、驚くべき関連性を見出します。その発想力は、時に感心するほどです。問題は、彼らがつながりを断てないことです。
普通の人間は、仮説を立てます。「AとBには関係があるかもしれない」。そして検証します。証拠を探します。反証も探します。もし関係がなさそうなら、その仮説を捨てます。つながりを断ちます。
でも、物語に囚われた人間は違います。「AとBには関係がある」と一度信じたら、もう断ちません。反証が出てきても、別の解釈で説明します。証拠がなくても、証拠の不在を何らかの理由で正当化します。つながりを断つのではなく、さらに別のつながりを作って補強します。
これは、つながりの創造性の問題ではありません。つながりの破棄能力の問題です。
エンジニアがバグに遭遇したとします。「このエラーは、たぶんメモリリークが原因だ」と仮説を立てます。調査します。でも、メモリ使用量は正常でした。この時、優れたエンジニアはすぐに仮説を捨てます。「メモリリークではない」と認めて、別の原因を探します。
でも、経験の浅いエンジニアは、最初の仮説に固執することがあります。「メモリ使用量が正常に見えるのは、測定方法が間違っているからだ」と考えます。「実は隠れたメモリリークがあるはずだ」と探し続けます。数時間を無駄にした後、ようやく別の原因に気づきます。
つながりを断てないことが、探索を非効率にします。物語に囚われた人間も同じです。最初の仮説に固執して、それを支持する情報だけを集め続けます。反証する情報は、何らかの形で無効化されます。つながりは増え続けますが、決して減りません。そして最終的に、巨大で複雑で、誰にも検証不可能な信念体系ができあがります。
もちろん、これは陰謀論だけの話ではありません。私たち全員が、程度の差こそあれ、この傾向を持っています。自分が信じたいことを信じ、信じたくないことを疑います。都合の良い情報を集め、都合の悪い情報を無視します。
だからこそ、意識的につながりを断つ訓練が必要なのです。
エコーチェンバーとは、つながりを断つ機会がない空間だ
SNSのエコーチェンバーが問題なのは、同じ意見ばかりが反響するからだと言われます。でも、本質はそこではありません。本質は、つながりを断つ機会がないことです。
人間は誰でも、間違ったつながりを作ります。「これとこれは関係がある」と思い込みます。でも、通常はそのつながりを断つ機会があります。友人が「それ、違うんじゃない？」と指摘してくれます。本を読んでいて、自分の考えと矛盾する事実に出会います。議論の中で、自分の論理の穴に気づきます。これらの経験が、間違ったつながりを断つきっかけになります。
でも、エコーチェンバーの中では、そのきっかけがありません。全員が同じつながりを信じています。だから、誰もそれを疑いません。間違ったつながりでも、誰も指摘しません。むしろ、そのつながりを補強する情報ばかりが流れてきます。
つながりを作る機会は無限にありますが、つながりを断つ機会はゼロです。
これは、情報の多様性の問題ではありません。つながりの新陳代謝の問題です。健全な思考には、つながりを作ることと断つことの両方が必要です。でも、エコーチェンバーの中では、作ることだけが起きて、断つことが起きません。
だから、つながりは増殖し続けます。最初は小さな偏見だったものが、関連する情報を取り込んで、巨大な世界観になります。そして、その世界観を支えるつながりは、あまりに多く、あまりに複雑になって、もはや1つ1つを検証することすら不可能になります。
私がエコーチェンバーから出た方がいいと思うのは、多様な意見を聞くためではありません。つながりを断つ機会を得るためです。自分が信じているつながりを、誰かに疑ってもらうためです。「それ、本当に関係あるの？」と聞かれて、立ち止まって考えるためです。
検証とは、つながりを一度断つことだ
あのプロジェクトを一からやり直した時、私は新しいアプローチを取りました。つなげる前に、断つことから始めました。
本当に必要な機能は何でしょうか。不要なものは何でしょうか。どの前提が正しく、どの前提が間違っているでしょうか。1つ1つ検証しました。そして、断つべきものを断ちました。
検証とは、自分のつながりを一度断つことです。自分にとって自明なつながりを、疑ってみます。本当につながっているのでしょうか。それとも、自分がそう信じているだけでしょうか。
アイデアが浮かんだら、それを他者の視点で見ます。自分一人で考えていると、自分のつながりが正しく見えます。でも、他人に説明しようとすると、論理の穴が見えます。「ここ、つながってないじゃん」と気づきます。
他人は、あなたの思い込みを共有していません。だから、あなたが当然だと思っているつながりを疑います。「なぜAとBがつながるの？」と聞きます。その質問に答えられないとき、そのつながりは思い込みだったと分かります。
実際に他人に説明する必要はありません。頭の中で、他人の視点を想像すればいいです。「このアイデアを、知識のない人に説明するとしたら、どう説明するか」。説明しようとすると、自分の理解が曖昧な部分が見えてきます。
あなたが見ているものは、他人にも見えるでしょうか。この問いが、つながりの妥当性を確認します。自分だけに見えるつながりは、主観です。他人にも見えるつながりが、客観です。
そして、実装します。頭の中でつながっていても、現実ではつながらないことがあります。理論的には正しくても、実装すると問題が出ます。だから、試します。そして、問題が出たら、そのつながりを断ちます。
実装とは、つながりの淘汰プロセスです。無数のつながりを試して、ほとんどを捨てます。残ったわずかなつながりが、本当に機能するアイデアになります。
ここで重要なのは、部分的に断つ能力です。アイデア全体を捨てるのではなく、うまくいかない部分だけを捨てます。AとBとCのつながりのうち、Bだけがうまくいかないなら、Bを断って、AとCのつながりを残します。そして、Bの代わりにDを試します。
破棄とは、全体を捨てることではなく、不要な部分だけを切り離すことです。手術のように、病んだ部分を切除して、健康な部分を残します。
問題解決とは、既存のつながりを断つことから始まる
プロジェクトをやり直した結果、設計はシンプルになりました。理解しやすくなりました。開発速度は上がり、バグは減り、パフォーマンスも改善しました。そして何より、チーム全員が幸せになりました。
何が変わったのでしょうか。つなげることを減らしました。断つことを増やしました。
課題を設定する段階で、他のすべての課題を断ちました。収集する段階で、無関係な情報を断ちました。咀嚼する段階で、ほとんどの組み合わせを断ちました。実装する段階で、うまくいかない部分を断ちました。
無数の可能性の中から、ほとんどを捨てました。残ったわずかなものを磨きました。それが、問題解決でした。
彫刻家は、石を削ります。削ることで、形が生まれます。作家は、言葉を削ります。削ることで、文章が研ぎ澄まされます。エンジニアは、コードを削ります。削ることで、設計が明確になります。
問題解決とは、加えることではなく、削ることです。つなげることだけではなく、断つことです。そして、断つことができて、初めて、本当に価値のあるつながりが残ります。
断つ技術を身につける
では、どうすればつながりを断てるようになるのでしょうか。
私は新しい技術を学ぶとき、必ず反証を探します。「この技術は素晴らしい」という宣伝文句を読んだら、すぐに「この技術の欠点は何か」を探します。「どんな場合には向いていないか」を調べます。最初から反証を探すことで、技術と「素晴らしい」の間の安易なつながりを断ちます。そして、どんな文脈で、どんな問題に対して、この技術が有効なのか、正確に理解できます。
コードを書いたら、一度捨てます。ゼロから書き直します。同じ機能を、別のアプローチで実装してみます。これは時間の無駄に見えるかもしれません。でも、最初の実装と「正しい」の間のつながりを断つ訓練になります。「動いたから正しい」と思い込みません。別のアプローチの方が、もっと良いかもしれません。実際に書き直してみると、最初の実装の問題点が見えてきます。
一年前の自分と、今の自分で、考えが変わったことを書き出します。「以前はこう思っていたが、今はこう思う」。これは、過去の自分と現在の自分の間のつながりを断つ訓練になります。「過去の自分が信じていたことは、今の自分も信じるべきだ」という思い込みを捨てます。実際にやってみると、驚くほど多くのことが変わっていることに気づきます。
時間をかけたものを、躊躇なく捨てます。三時間かけて書いたコードでも、より良いアプローチがあれば書き直します。一週間かけて調べた技術でも、プロジェクトに合わなければ採用しません。これは、努力と成果の間のつながりを断つ訓練になります。「時間をかけたから価値がある」という思い込みを捨てます。価値があるかどうかは、どれだけ時間をかけたかではなく、どれだけ問題を解決するかで決まります。
自分が信じていることを、他人に説明します。特に、その分野に詳しくない人に説明します。説明しながら、「あれ、これ、うまく説明できないな」と気づくことがあります。それは、自分の理解と「正しい」の間のつながりが、実は曖昧だったということです。説明できないということは、本当は理解していないということです。
つながりと断つことの往復運動
つながりを断つことは、難しいです。認知的にも、感情的にも、社会的にも。
一度見出したパターンを忘れることは、ほとんど不可能です。自分の判断が間違っていたと認めることは、苦痛です。周りの人間が信じているつながりを断つことは、孤立を意味します。
それでも、断たなければなりません。なぜなら、断たなければ、成長できないからです。
間違ったつながりを持ち続けている限り、正しいつながりは作れません。古い理解を手放さない限り、新しい理解は得られません。過去の自分に固執する限り、未来の自分にはなれません。
断つことは、破壊ではありません。更新です。古いバージョンを削除して、新しいバージョンをインストールすることです。
プログラムは、定期的に更新しなければ、脆弱性を抱えたまま動き続けます。思考も同じです。定期的につながりを見直して、間違ったつながりを断って、新しいつながりを作らなければ、脆弱なまま考え続けることになります。
おわりに
あのプロジェクトから数年が経ちました。今、私は別のプロジェクトに取り組んでいます。相変わらず、設計で悩むことはあります。アプローチで迷うことはあります。でも、以前とは違うことが1つあります。
躊躇なく捨てられるようになりました。
一週間かけて書いたコードでも、より良い方法があれば書き直します。チーム全員で決めた設計でも、問題があれば提案し直します。昨日まで正しいと思っていたことでも、今日は疑えます。
これは能力の問題ではありませんでした。姿勢の問題でした。サンクコストを恐れない姿勢。過去の判断に縛られない姿勢。そして何より、間違いを認めることを恐れない姿勢。
人間は、つながりを見出す生き物です。パターンを探します。関係性を発見します。意味を作り出します。これは本能です。でも、つながりを断つことは本能ではありません。意識して訓練しなければ、身につきません。
プログラミングを学び始めたとき、私は「どうやってつなげるか」ばかり考えていました。データ構造とアルゴリズムをつなげます。フロントエンドとバックエンドをつなげます。理論と実装をつなげます。
でも、本当に重要だったのは「どうやって断つか」でした。間違ったアプローチを断ちます。無駄な複雑性を断ちます。過去の判断を断ちます。そして、最も難しいのは、自分の思い込みを断つことでした。
つながりを断つことは、否定ではありません。更新です。昨日の自分を否定するのではなく、今日の自分にアップデートします。古いバージョンを削除して、新しいバージョンをインストールします。
でも、ここで誤解してほしくないことがあります。これは「つながるな」「つなげるな」という話ではありません。つながることは人間の本能であり、問題解決の源泉です。それを否定することは、人間であることを否定することに等しいです。
私が言いたいのは、つなげたものを、多様な面で検証してほしいということです。
「AとBは関係がある」と思ったとき、それを検証します。技術的に正しいでしょうか。論理的に整合しているでしょうか。他の事例でも成り立つでしょうか。他者から見ても妥当でしょうか。実装してみて機能するでしょうか。
そして、検証した結果、うまくいかなかったら、そのつながりを保持しておいてよいか、もう一度考えます。
もしかしたら、部分的には正しいかもしれません。ある条件下では有効かもしれません。別の文脈では使えるかもしれません。だから、すぐに断つ必要はないこともあります。でも、「常に正しい」「すべての状況で有効」と思い込むのは危険です。
つながりには、適用範囲があります。前提条件があります。文脈があります。これらを無視して、つながりを普遍化しないこと。「この状況では有効だが、別の状況では違うかもしれない」と認識すること。この謙虚さが、つながりを適切に扱う技術の核心です。
検証してダメだったつながりを、無理に保持し続けません。でも、すぐに捨てる必要もありません。保留にしておきます。別の角度から見直します。条件を変えて試してみます。そして、やはりダメだと分かったら、そこで初めて手放します。
異なる知識をつなげます。異なる視点をつなげます。異なる人々をつなげます。そして、検証します。技術的に。論理的に。実践的に。多様な面から。そして、考え直します。このつながりは本当に有効でしょうか。どんな条件で成り立つでしょうか。どんな状況では成り立たないでしょうか。
つなげることと検証すること。そして必要なら手放すこと。この往復運動ができて、初めて、本当の解決策が生まれます。そして、つながりに対して誠実であることが、この往復運動を可能にします。
