複雑な問題に向き合っていると、「本当にこれを解決できるのだろうか」と感じる瞬間があります。
私は複雑なAIシステムを段階的に開発するなかで、一度決めた設計を修正したり、前提条件を整え直したり、テストによって想定外の問題を発見したりする経験を何度もしてきました。
一つの問題を解決したと思えば、その先で新しい問題が見つかる。正しいと思っていた設計が、実装を進めたことで十分ではなかったと分かることもあります。
そうした状況が続くと、ふと疑問が生まれます。
これほど複雑なシステムが世の中に存在するなら、解決策があったはずです。
OS、データベース、インターネット、クラウド、検索エンジン。私たちが日常的に利用している技術の多くは、一人の人間がすべてを把握することが難しいほど複雑です。
それでも、人類はそれらを作ってきました。
では、複雑な問題を完全に理解してから作り始めたのでしょうか。
おそらく、そうではありません。
複雑な問題に対する人間の強さは、最初からすべてを理解できることではなく、分からないものを少しずつ「扱えるもの」へ変えていけることにあります。
本記事では、Nexus AIで実際に複雑な開発を進めてきた経験と、これまで蓄積してきた問題解決に関する知識を抽象化し、複雑な課題を扱う方法を10の原則として整理します。
これは「科学的に確立された普遍的な10原則」を主張するものではありません。
複雑な問題へ向き合うなかで繰り返し有効だった考え方を、Nexus AIの問題解決フレームとして体系化したものです。
この記事で扱う中心的な考え方は、一文にすると次のようになります。
複雑な問題に直面したとき、人はどうしても「正しい答え」を探そうとします。
原因を完全に特定し、最適な解決策を考え、その通りに実行すれば問題は解決する。
これは間違った考え方ではありません。
問題が十分に小さく、原因も比較的明確なら、この方法はよく機能します。
たとえば、Webサイトの一つのボタンが表示されないのであれば、CSS、HTML、JavaScript、キャッシュなど、原因候補を調べて修正できます。
しかし問題が大きくなると、事情が変わります。
複数のシステムが連携し、それぞれに状態があり、ある処理の結果が次の処理へ影響し、例外や障害にも対応しなければならない。
このような状況では、問題が起きた時点で、
といったこと自体が分からない場合があります。
つまり、「問題は見えているが、答えがまだ存在しない」のです。
私自身、複雑なAIシステムの開発を進めるなかで、こうした状態へ何度も入りました。
当初は、設計変更や修正が何度も発生することを「開発がうまく進んでいない兆候」と見る感覚もありました。
しかし、実際には逆のケースも多くあったのです。
問題を解いている最中は、かなりエネルギーを使います。それでも一つずつ原因を整理し、構造を見直し、実装して確かめていくことで、結果的には以前より良い状態へ進めることが少なくありません。
そして、そこまで突き詰めても解決しない場合には「修正方法が足りない」のではなく、そもそもの設計を見直す必要があるという新しい発見につながります。
ここで重要なのは、壁そのものを悪い兆候と決めつけないことです。
複雑な問題では、壁にぶつかったことで初めて、これまで見えていなかった未知が表面化することがあります。
問題解決という言葉から、多くの人が想像しやすいのは、次のような直線的な流れです。
単純な問題では、このモデルで十分です。
しかし複雑な問題では、「原因を特定する」段階からすでに難しくなります。
原因候補が複数あり、複数の要因が相互作用している場合もあります。さらに、検証しなければ原因かどうか分からないこともあります。
そこで実際の問題解決は、より循環的になります。
この循環を重ねながら、未知の範囲を少しずつ縮めていきます。
この違いは非常に重要です。
直線モデルでは、最終的な正解がどこかに存在し、人間の仕事はそれを見つけることだと考えます。
一方、複雑な問題では、解決過程そのものによって新しい情報が生まれます。
だからこそ、問題解決能力を「最初から正しい答えを出す能力」と定義すると、複雑な問題へ弱くなります。より重要なのは、分からない状態でも前へ進み、現実から情報を得ながら認識を更新できることです。
これは、Nexus AIでこれまで扱ってきた「失敗をデータとして扱う」という考え方ともつながります。
失敗を終点ではなく情報として扱えば、結果が出なかった試行も次の判断材料になります。
さらに、実験回数が増えるほどフィードバックを得る機会も増えます。
AIによって実験コストが下がることで、仮説検証を繰り返しやすくなったという構造も、問題解決と深く関係しています。
ここまでの考え方を、Nexus AIでは10の原則として整理します。
「原則」という言葉を使う以上、それが原理・法則とどう違うのかも押さえておくと、以降の理解がぶれにくくなります。
| 原則 | 何をするのか |
|---|---|
| 分割 | 巨大な問題を小さな問題にする |
| 抽象化 | 不要な細部を隠し、重要な構造や契約を見る |
| 境界設計 | コンポーネントや責任範囲を明確にする |
| PoC | 本当に可能か、小さく作って確かめる |
| 段階的実装 | 一度に完成させず、成立範囲を少しずつ広げる |
| テスト | 「動くはず」を「実際に動く」へ変える |
| 観測 | ログや状態などから、内部で何が起きているかを見る |
| フォールバック | 失敗しても全体を壊さないようにする |
| 再設計 | 前提が間違っていれば、設計そのものを変える |
| 技術的負債の管理 | 今解かなくてもよい問題を把握したうえで意図的に後回しにする |
これらは独立した10個のテクニックではなく、大きく見ると
という五つの役割へ整理できます。
この構造を理解すると、「今どの問題解決手法を使うべきか」も見えやすくなります。
たとえば、問題が大きすぎて何から手を付ければよいか分からないなら、必要なのはテストより先に「分割」かもしれません。
原因を推測できても確認できないなら、「PoC」や「テスト」が必要です。
問題が起きていることは分かるのに、内部で何が起きているか分からないなら、「観測」の不足が疑われます。
つまり10原則は、問題へ一律に適用するチェックリストではなく、未知の状態に応じて選ぶための道具でもあります。五つの役割それぞれが具体的にどう機能するのか、循環としてどうつながっているのかは、後段で改めて整理します。
複雑な問題を解く最初の段階は、答えを考えることではありません。
まず、人間が扱える大きさと構造へ変えることです。
ここで重要になるのが、
の三つです。
複雑な問題をそのまま頭の中へ入れようとすると、人間の認知負荷は急激に高くなります。
システム開発なら、UI、認証、データ保存、外部API、権限、エラー処理、状態管理など、複数の問題が同時に存在します。
これらをすべて一つの「システムを完成させる」という問題として考えると、どこから始めればよいか分からなくなります。
そこで最初に行うのが分割です。
「巨大な問題」を、
へ分けていきます。
ただし、単に細かくすればよいわけではありません。
細かすぎると、それぞれが何のために存在するのか見えなくなります。
重要なのは、独立して考え、検証し、改善できる粒度まで分けることです。
この問題については、Nexus AIですでに「粒度設計」という観点から詳しく扱っています。
分割の目的は、問題を小さく見せることではありません。
解ける単位へ変換することです。
分割した後にも、まだ大量の情報があります。
そこで必要になるのが抽象化です。
抽象化とは、細部を無視することではありません。
今考える必要のない細部をいったん隠し、重要な関係だけを見ることです。
たとえば、ある外部サービスとシステムを接続するとします。
そのサービス内部でどのようなコードが動いているかを、接続する側がすべて理解する必要はありません。
重要なのは、
という契約です。
このように細部を隠せるからこそ、人間は巨大なシステムを扱えます。
もし一つのWebページを表示するために、CPUの命令、ネットワーク通信、OS内部処理、Webサーバー、データベース、ブラウザレンダリングまで毎回すべて意識しなければならないなら、現代のWeb開発は成立しません。
抽象化とは、複雑性を消す技術ではありません。
複雑性を「今見なくてもよい状態」にする技術です。
分割と抽象化を行っても、責任範囲が曖昧であれば問題は再び絡み合います。
そこで必要になるのが境界設計です。
境界設計では、
を明確にします。
境界が曖昧なシステムでは、一つの変更が複数の場所へ影響しやすくなります。
逆に境界が明確なら、内部実装を変更しても、外部との契約を守る限り影響を限定できます。
Nexus AIでは、WordPressのリファクタリングを通じて「責務の混在」が問題を複雑にし、「責任で分ける」ことで保守性が高まる構造も扱ってきました。
境界設計は、コードの内部構造だけの話でもありません。AIと人間が共同で開発を進める場面でも、どちらが何を担当するのかという境界を明確にすることが、開発フロー全体の質を左右します。
さらに、境界を機能させるには「何を頼むか」だけでなく「どんな前提・仕様のもとで動いてもらうか」という設計も欠かせません。AI活用における役割指定とコンテクスト設計の違いは、この点と直接関わっています。
また、境界の重要性はコード設計だけではありません。
AI、Webセキュリティ、人間認知という異なる領域でも、「入力」「解釈」「実行」の境界が崩れることで問題が生まれるという共通構造があります。
問題を理解可能な形へ分けたら、次に必要なのは「考えること」から「確かめること」への移行です。
複雑な問題では、思考だけでは答えが出ないことがあります。
こうした問いは、最終的に現実へ触れなければ答えが出ません。
そこで重要になるのが、
です。
PoCはProof of Concept、つまり概念実証です。
完成品を作る前に、そもそもこの考え方が成立するのかを小さな実験で確かめます。
たとえば、新しい外部APIを利用したシステムを構想しているとします。
最初から管理画面、データ保存、エラー処理、課金、UIまで全部作る必要はありません。
まず最小限のコードでAPIへ接続し、必要なデータが取得できるか確かめればよいのです。
成立しなければ、その時点で設計を見直せます。
成立すれば、次の段階へ進めます。
PoCの強みは、「失敗を安くすること」にあります。
大きく作ってから方式そのものが成立しないと判明するより、小さく試して早く分かったほうが損失は小さくなります。
この発想は、AI時代に実験コストが下がることで、試行回数そのものが競争力になるという考え方とも一致します。
PoCで実現可能性が確認できても、すぐに完成形を作る必要はありません。
むしろ複雑なシステムでは、段階的に成立範囲を広げるほうが安全です。
たとえば、
というように、各段階で「ここまでは成立している」という基準点を作ります。
これは単に作業を細かくすることとは違います。
各段階を検証可能な完成状態として扱うことが重要です。
段階的実装の大きな利点は、問題が起きたときに原因範囲を限定できることです。
昨日まで正常だったものへ一つの変更を加え、その後問題が起きたなら、調べるべき範囲はかなり狭くなります。
一方、一度に大量の変更を加えれば、どこが原因なのか分からなくなります。
この意味でも、段階的実装は「開発速度を落とす慎重策」ではありません。
問題解決速度を維持するための設計です。
人間は、設計を考えていると「これなら動くはずだ」と感じます。
しかし、「動くはず」と「実際に動く」は別物です。
テストはその差を埋めます。
テストによって確認するのは、単に成功するかどうかだけではありません。
など、設計上の仮説を現実へ照合します。
私自身の開発経験でも、テストによって「想定していた構造では足りない」と分かることが何度もありました。
その瞬間だけを見ると、修正作業が増えたように感じます。
しかし実際には、テストをしたから未知を発見できたのです。
もしテストせずに先へ進んでいれば、その問題はより大きな状態で後から現れていた可能性があります。
ここで、問題に対する見方が変わります。
テストをして問題が発生したとしても、何が起きたのか分からなければ解決できません。
そこで必要になるのが「観測」です。
複雑なシステムでは、外から見える結果だけでは原因を判断できないことがあります。
たとえば、「処理が失敗した」という事実だけでは、情報が足りません。
複数の可能性があります。
観測とは、内部で何が起きているかを見えるようにすることです。
システム開発なら、ログ、ステータス、エラー記録、メトリクス、履歴などが代表的です。
そして、この原理はシステムだけに限りません。
マーケティングでも同じです。
売上が下がったという結果だけでは原因は分かりません。
アクセスが減ったのか、クリック率が下がったのか、購入率が下がったのか、客単価が変わったのか。
観測点を増やすことで、問題をより小さな領域へ絞れます。
原因特定が速い熟練者が強い理由も、単純に知識量が多いからとは限りません。
問題が起きたとき、「どこを観測すれば、原因候補を切り分けられるか」を知っているからです。
さらに、Nexus AIではWordPressセキュリティについても「運営とは観測と改善の継続である」という構造を扱っています。
問題が起きてから対応するだけではなく、変化を観測し続けることで異常を発見し、改善へつなげていく考え方です。
観測可能性が高まるほど、問題は「なんとなくおかしい」という状態から、「この部分でこの条件のときに異常が起きている」という状態へ変わります。
つまり、観測は、未知を情報へ変換する仕組みだと言えます。
ここまでで、複雑な問題は少しずつ姿を変えてきました。
しかし、複雑な問題では、それでも失敗そのものを完全になくすことはできません。
次に重要になるのは、失敗しないことではなく、失敗しても全体を壊さないこと。そして、失敗から得た情報によって設計そのものを更新できることです。
ここまでの段階では、問題を理解し、試し、観測できる状態へ変えてきました。
しかし、どれだけ丁寧に設計しても、複雑なシステムから失敗を完全になくすことは困難です。
外部サービスが停止するかもしれません。想定外の入力が来るかもしれません。通信が途中で切れることもあれば、実装時には存在しなかった条件が後から加わることもあります。
このとき、「絶対に失敗しない仕組み」を目指し続けると、問題解決そのものが行き詰まることがあります。
必要なのは、失敗をゼロにすることではありません。
失敗が起きることを前提として、その影響範囲を管理することです。
そこで重要になるのが、
という二つの原則です。
フォールバックとは、通常の方法が使えなくなったときに備えて、代替手段や安全な退避先を用意しておく考え方です。
たとえば、ある外部サービスへ強く依存した業務があるとします。
そのサービスが停止した瞬間に業務全体まで停止するなら、サービス自体の性能とは別に、システム全体として大きな脆弱性を抱えています。
そこで、
といった逃げ道を用意します。
重要なのは、「絶対に障害を起こさない」と考えることではありません。
障害が起きたときに、どこまで壊れることを許容するのかを事前に設計することです。
私は、AIサービスに限らず、Nexus AIの運用全体をセキュリティ・バックアップ・ワークフローも含めて冗長化を前提に構築しています。
これはNexus AIだけで培った考え方ではなく、これまでのWebサイト運用やコンサルティングの経験を統合した判断基準です。
それでも足りないケースが出てくることはあるため、その都度より安定して動作するフォールバックを検討しています。
Nexus AIでは、AIサービスの障害をきっかけに、重要なのは一つのサービスへ依存することではなく、「止まらない仕事」を設計することだと整理してきました。
また、AIとの共同開発でも、何が起きても処理を続けることが必ずしも正しいとは限りません。
前提が不足しているときや、設計思想と矛盾する可能性があるときには、むしろ安全に停止し、人間の判断へ戻す必要があります。
ここには共通する原理があります。
問題解決とは「進み続けること」ではなく、壊れない範囲で進めることでもあるということです。
すべての失敗を防げなくても、その失敗がシステム全体へ波及しなければ、問題は管理可能になります。
もう一つ重要なのが、「すべての問題を今すぐ解決する必要はない」という考え方です。
問題が見つかると、人はそれを取り除きたくなります。
しかし複雑なプロジェクトでは、発見した問題をすべてその場で解決していたら、いつまでも本来の目的へ到達できないことがあります。
そこで必要になるのが、今解く問題と、後で解く問題を分けることです。
ソフトウェア開発では、その代表例として「技術的負債」という言葉があります。技術的負債というと、「雑なコード」「後で困る悪い設計」のような否定的な意味で捉えられがちです。
しかし、ここで扱いたい上位概念はもう少し広いものです。
重要なのは「把握しているかどうか」です。
存在すら認識していない問題は、単なる潜在リスクです。
認識しているのに理由もなく放置しているなら、管理されているとは言えません。
しかし、
と判断したうえで後回しにするなら、それは意思決定です。
私が携わっているプラグイン開発でも、MVPの段階で完璧な仕様を構築することは目指していません。現在必要な実装と、将来的に実装予定の内容を明確に分離し、どの段階で検討するのかという判断基準もあわせて持つようにしています。
こうして管理することで、技術的負債は単なる阻害要因ではなく、開発を前へ進めるための整理棚として機能します。
この考え方はソフトウェア開発だけのものではありません。
新しいビジネスを始めるときに、最初から完璧な組織、ブランド、業務システム、商品ラインナップを整える必要はありません。まず価値提供が成立するかを確かめ、必要になったものから整備していく方法もあります。
つまり、未解決＝失敗ではありません。
未管理＝リスクなのです。
未解決の問題であっても、その存在・影響範囲・対応時期を管理できているなら、前へ進むことができます。
ここまで紹介してきた方法を使えば、多くの問題を少しずつ扱える状態へ変えていけます。
しかし、それでも解決しないことがあります。
このような状態では、「修正方法が足りない」と考える前に、別の問いを立てる必要があります。
そもそも、最初の設計前提は正しかったのでしょうか。
複雑な問題解決では、最初に立てた仮説が間違っていることがあります。
そのこと自体は異常ではありません。
最初の時点では情報が足りなかったからです。
開発を進め、テストを行い、実際の挙動を観測したことで、当初は存在しなかった情報が増えています。
つまり、最初の設計時と現在では、判断材料そのものが違います。
それにもかかわらず、「最初に決めたから」という理由だけで設計を維持し続ければ、新しい情報を意思決定へ反映できません。
私自身、複雑なAIシステムを開発する過程で、修正によって前へ進めるケースだけでなく、「局所的な修正を続けるより、そもそもの構造を見直したほうがよい」と判断する場面も経験してきました。
これは開発が後退したわけではありません。
実装と検証によって、以前より正確に問題を理解できるようになった結果です。
この視点を持つと、「設計変更」の意味が変わります。
最初の設計を守り抜くことが成功なのではありません。
新しい情報に応じて、より適切な構造へ更新できることのほうが重要です。
これは、他者や新しい情報から学ぶことで評価モデルそのものを更新するという考え方にもつながっています。
また、知識を持っていることと、実際に使える形で理解していることも同じではありません。
実務では予想外が起こり、その経験によって頭の中のモデルが更新されます。
問題解決において重要なのは、自分の最初の答えを守ることではありません。
現実に合わせて、自分の認識を更新し続けることです。
ここまで10原則を順番に見てきました。
改めて整理すると、これらは次の五つの状態変化を作っています。
| 状態変化 | 対応する原則 | 役割 |
|---|---|---|
| 理解可能にする | 分割・抽象化・境界設計 | 問題を人間が扱える構造へ変える |
| 検証可能にする | PoC・段階的実装・テスト | 分からないことを実験できる状態へ変える |
| 観測可能にする | 観測 | 内部で起きていることを情報へ変える |
| 制御可能にする | フォールバック・技術的負債の管理 | 失敗や未解決問題の影響範囲を限定する |
| 更新可能にする | 再設計 | 新しい情報に合わせて前提そのものを変える |
ここで、10原則を単なる方法論としてではなく、一つの循環として見てみます。
最初にあるのは「未知」です。
何が原因なのか分からない。実現できるか分からない。どこから手を付ければよいかも分からない。
そこから、
未知
↓
理解可能 分割・抽象化・境界設計
↓
検証可能 PoC・段階的実装・テスト
↓
観測可能 観測
↓
制御可能 フォールバック・技術的負債の管理
↓
更新可能 再設計
という変化を作ります。
そして、再設計したら終わりではありません。
新しい設計を実装すると、その先にまた別の未知が見つかることがあります。
しかし、最初と同じ場所へ戻ったわけではありません。
以前よりも、
という状態になっています。
つまり、循環しているように見えても、実際には理解が積み上がっています。
問題解決は、未知 → 正解という一度きりの移動ではありません。
未知 → 管理可能 → 新しい未知 → より高い管理可能性という反復なのです。
これは、「失敗をデータ化する」「実験回数を増やす」「評価モデルを更新する」といったNexus AIの既存記事が、なぜ一つの問題解決体系としてつながるのかを説明する構造でもあります。
そして、個別の最適化だけではなく、全体の流れを見ることも欠かせません。
一つひとつの部品が正常でも、システム全体として詰まっている場所があれば、成果はそこに制約されます。
10原則の目的も、個々の手法を完璧に実行することではありません。
問題解決という流れ全体を前へ進めることです。
この10原則は、最初から理論として作ったものではありません。
出発点になったのは、AIをビジネスで業務活用するためのプラグイン開発を進めていて感じた違和感でした。
こうした状態が何度も続くと、「なぜこんなに壁が出てくるのだろう」と感じます。
実際に、実装を進める中でレビュー自体が何度も重なることがありました。1〜2回でMergeできる場合もあれば、5回以上のレビューと修正が重なったこともあります。
それだけ修正が続くと、「このPhaseは本当に完了できるのだろうか」と感じる瞬間もありました。それでも一つずつ修正を重ねることでレビューを通過し、次のPhaseへ進むことができています。
また、Phaseの修正改善だけでなく、そもそも前提条件が足りていないという問題に直面したこともあります。そのときは既存のIssueをいったんblockedとして停止し、前提となるIssueを複数作成したうえで、最終的に統合するというプロセスを踏みました。
複数の前提Issueの中でも何度も修正改善が発生し、「本当に綺麗に統合できるのか」と感じる場面もありましたが、最終的には統合され、Phaseを分解したからこそ、より良い実装になったと感じています。
壁だと思っていたものが、実はより良い設計へのステップだったということです。
こうしたIssueの分解・統合や、ChatGPT・Codexとの役割分担の詳しいプロセスは、以下の記事で扱っています。
問題解決の最中は、楽なプロセスではありません。
原因を考え、条件を整理し、修正方法を比較し、実際に試し、その結果をまた評価する。思考量も判断量も増えるため、かなりエネルギーを使います。
しかし振り返ると、その壁を越えた後には、以前よりシステムの理解が深まっていることが多くありました。
そして、ときには「この問題を今の設計のまま解こうとしていること自体が間違っている」と気づくこともありました。
ここから、私の認識が変わりました。
修正が発生することと、開発が失敗していることは同じではありません。
むしろ複雑な問題では、実装したからこそ未知が見つかり、それを一つずつ情報へ変えている場合があります。
こうした経験から学び、認識モデルを更新し続けるという姿勢そのものについては、以下の記事でさらに掘り下げています。
これは「設計段階ですべてを見抜く能力が足りなかった」という話だけでもありません。
複雑なシステムには、実際に動かすまで観測できない情報があります。
だから、設計 → 実装 → 観測 → 学習 → 再設計という循環そのものを開発プロセスへ組み込む必要があります。
私が最初に抱いた、「これほど複雑なシステムが世の中に存在するなら、解決策があったはずだ」という疑問への答えは、ここにあるのだと思います。
人類は、複雑な問題を最初からすべて見通せるようになったのではありません。
見通せない問題でも、前へ進める方法を発達させてきたのです。
今回の出発点はシステム開発でした。
しかし「未知を管理可能にする」という構造を抽象化すると、適用範囲は大きく広がります。
新しい事業を始めるとき、市場のすべてを理解してから参入することはできません。
対象顧客を分け、小さく商品を作り、実際に販売し、反応を観測します。
売れなければ原因を考え、商品、価格、訴求、顧客設定などを更新します。
これは、分割 → PoC → 観測 → 再設計そのものです。
広告やLPでも、最初から最高の訴求が分かるとは限りません。
仮説を作り、実際のクリック率やコンバージョン率を観測し、改善していきます。
重要なのは「最初から当てること」より、外したときに、なぜ外れたのか学べる状態を作ることです。
完成品を何年もかけて作り、それから市場へ出す方法だけが正解ではありません。
最小限の価値を形にし、利用者の反応を見ながら段階的に機能を追加していく方法もあります。
PoCや段階的実装という考え方は、そのまま応用できます。
AIへ仕事を任せる場合にも、「AIが必ず正解すること」を前提にすると運用は不安定になります。
重要なところでは人間が確認する。失敗したら安全に停止する。別の手段を用意する。実際の結果を見て指示や仕組みを改善する。
AIを使うこともまた、不確実性を管理するシステム設計として捉えられます。
学習でも、分からないものをいきなり完全理解する必要はありません。
問題を小さく分け、分からない場所を特定し、実際に問題を解き、間違えた部分から自分の理解モデルを更新します。
知識だけではなく経験によって理解が深くなる理由も、同じ構造で説明できます。
複数の人間が関わるほど、すべてを中央で理解・管理することは難しくなります。
役割を分け、責任範囲を明確にし、判断できない状況ではエスカレーションし、問題があれば運用ルールそのものを見直す。
ここでも、分割・境界設計・観測・フォールバック・再設計が機能します。
このように表面的な対象は違っていても、「分からない状態を、少しずつ扱える状態へ変えていく」という深層構造は共通しています。
だからこそ、10原則はシステム開発だけのテクニックではなく、より広い「問題解決フレーム」として再利用できます。
では、実際に難しい問題へ直面したとき、10原則をどのように使えばよいのでしょうか。
すべてを上から順番に適用する必要はありません。
重要なのは、今の問題がどの状態で止まっているのかを診断することです。
たとえば、次のように問い直せます。
| 状況 | 問い | 検討する原則 |
|---|---|---|
| 何から手を付ければよいか分からない | 問題が大きすぎないか？ | 分割 |
| 情報量が多すぎて整理できない | 今、本当に見る必要がある情報は何か？ | 抽象化 |
| 複数の問題が絡み合っている | 誰が何を担当するのか曖昧ではないか？ | 境界設計 |
| 実現できるかどうか自体が分からない | 小さく試せないか？ | PoC |
| 一度に変更する範囲が大きい | 成立範囲を段階的に広げられないか？ | 段階的実装 |
| 正しいはずなのに確信できない | 現実で確認する方法はあるか？ | テスト |
| 問題は起きているが原因が見えない | 内部状態を観測できているか？ | 観測 |
| 一つの失敗で全体が止まる | 代替経路や安全な停止方法はあるか？ | フォールバック |
| 問題が多すぎて先へ進めない | 今、本当に解く必要がある問題か？ | 技術的負債の管理 |
| 修正しても問題が繰り返される | 前提そのものが間違っていないか？ | 再設計 |
この問いを持っているだけでも、「問題が難しい」という曖昧な状態から抜け出しやすくなります。
たとえば、「何をやってもうまくいかない」ではなく、「原因候補を切り分けるための観測情報が足りない」と表現できれば、次にすることが見えます。
あるいは、「大量の問題を抱えている」ではなく、「今解く必要がある問題と、後で解ける問題を区別できていない」と捉え直すこともできます。
これは非常に重要な変化です。
問題解決では、正しい答えを持っていること以上に、「問題を解ける形で定義できること」が強いからです。
本記事では10原則を一つの問題解決体系として俯瞰しました。
一方、それぞれの原則にはさらに深いテーマがあります。
特に最初に理解したいのは、巨大な問題をどう分けるかという「粒度設計」です。
次に、問題が起きたときに原因候補をどのように絞り込むのかを理解すると、観測と診断の精度が上がります。
仮説を実際に試し、結果から学ぶという観点では、「実験回数」と「失敗のデータ化」が重要です。
さらに問題が大きくなれば、個別部分だけではなくシステム全体を見る必要があります。
失敗そのものをなくせない状況では、冗長化や安全な停止という設計思想も重要になります。
このように、本記事はそれぞれの記事の内容を一つにまとめ直したものではありません。
それぞれの知識が「問題解決」という大きな体系のどこに位置するのかを示す親記事です。
今後、境界設計、観測可能性、フォールバック、技術的負債などをさらに深掘りする記事が増えれば、この知識体系はさらに成長していきます。
この記事の出発点は、一つの素朴な疑問でした。
「これほど複雑なシステムが世の中に存在するなら、解決策があったはずだ。」
複雑なAIシステムを開発していると、何度も壁にぶつかります。
問題を解いている最中は、決して楽ではありません。
しかし振り返れば、そのプロセスによって、それまで見えなかった未知が情報へ変わっています。
本記事では、その過程を10の原則として整理しました。
これらをさらに上位から見ると、
理解可能にする
↓
検証可能にする
↓
観測可能にする
↓
制御可能にする
↓
更新可能にする
という一つの流れが見えてきます。
そして、そこからまた新しい未知へ向かいます。
重要なのは、未知が完全になくなることではありません。
新しい未知に出会ったときにも、「分からないから進めない」のではなく、「どうすれば扱える状態へ変えられるか」と考えられることです。
問題解決能力とは、正解を知っている能力ではありません。未知を少しずつ管理可能な状態へ変えていく能力です。
人類が巨大で複雑なシステムを作れたのも、最初からすべてを理解していたからではないでしょう。
分からないものを分け、試し、観測し、失敗から学び、必要なら前提そのものを変える。
その循環によって、「まだ分からない領域」を少しずつ「扱える領域」へ変えてきた。
そう考えると、壁にぶつかることの意味も変わります。
壁は、必ずしも「進めなくなった場所」ではありません。
次に管理可能へ変えるべき未知が、姿を現した場所なのです。
必ずしもそうではありません。最初に全体の方向性や重要な制約を設計することは必要ですが、複雑な問題では実際に試さなければ分からないことがあります。
そのため、設計 → 小さく実装 → 検証 → 観測 → 設計更新という循環を前提にしたほうが、現実に適応しやすくなります。
必ずしもそうではありません。もちろん設計不足によって修正が増える場合もあります。一方、複雑な問題では、実装しなければ観測できなかった条件が後から見つかることもあります。
重要なのは「変更があったか」ではなく、新しい情報によって変更する合理的な理由があるかです。
その必要はありません。現在の目的へ影響しない問題であり、存在とリスクを把握し、後から安全に対応できるのであれば、意図的に保留することも合理的です。
問題を残すことと、問題を放置することは違います。
PoCは「考え方自体が成立するか」を確かめる実験、段階的実装は成立が分かったものを小さな完成状態の積み重ねで本番へ近づける方法です。詳しくは本文中の「第2段階―未知を検証可能にする」をご覧ください。
知識は重要ですが、それだけではありません。複雑な問題では、最初から答えを知っていないことも多いため、
といった能力が重要になります。つまり、問題解決能力とは「正解を多く知っていること」だけではなく、未知の状態から学びながら解決可能な状態へ変えていく能力でもあります。
投稿をシェアする
Web制作・デザイン・マーケティング・コンサルティング等の経験を積み、ChatGPTコミュニティ Nexus AIを立ち上げる。AI技術を活用して、コミュニティ運営に役立てている。
