デカルトの「分割して考えよ」は、システム設計の基本原則そのものである

デカルトの「分割して考えよ」は、システム設計の基本原則そのものである

「難問の一つ一つを、解きうるかぎり多くの小部分に分割せよ」——デカルト『方法序説』

1637 年に書かれた『方法序説』のこの一節は、システム設計の教科書にそのまま置いても違和感がないほど、現代の私たちの仕事の芯を捉えています。

ただ、現場で「分割」がうまく働かないとき、私たちが躓いているのは本当に「分け方」なのでしょうか。

本稿では、デカルトが示した「分割」の思想を、システム設計の実務と往復しながら読み直してみます。

1. 「分割」はデカルトの四規則のうちの一つにすぎない

inline-1

『方法序説』第二部でデカルトは、思考を導くための規則を四つ並べています。

  • 明証: 明晰判明に真と認めたものだけを受け入れる
  • 分析: 困難な問題を、解けるだけの小部分に分割する
  • 総合: 単純なものから順に、複雑なものへ積み上げる
  • 枚挙: どこにも見落としがないかを、全体にわたって確かめる

よく引かれるのは「分析」の規則だけですが、デカルト自身は、分割は単独では機能しない前提でこの四つをセットにしています。単純なものから順に積み上げる「総合」、そして全体を見渡して確かめる「枚挙」が伴って、はじめて「分割」は思考の道具として働きます。

システム設計で「分け方」に苦労するとき、多くの場合で足りていないのは分割の技術ではなく、どの順序で組み直すか見落としをどう検証するかの側なのではないでしょうか。

2. システム設計の各フェーズに四規則を重ねる

システム設計の工程を眺めると、この四規則はそのままマッピングできます。

要件定義のフェーズは、「分析」が最も強く求められる段階です。顧客の業務を、機能・利用者・状態・時間軸のどれで切るかで、後続の工程が大きく揺れます。「商品を検索する」「カートに入れる」「決済する」という分け方は一見自然ですが、これは機能軸で切った結果にすぎません。在庫・会員状態・配送経路で切れば、まったく別の要件図が立ち上がります。

アーキテクチャ設計のフェーズは、「総合」の色合いが濃くなります。レイヤー、サービス境界、ドメインといった設計判断は、分割された要素をどう積み直すかの決定です。マイクロサービスという言葉だけを取り出せば「分けろ」に聞こえますが、実際の設計者が悩んでいるのは境界をどこに置くかであり、これは分けた後にどう束ねるかを前提にした、総合の問いではないでしょうか。

分けることと束ねることは、同じ設計行為の表裏である。

詳細設計・実装のフェーズでは、分割された単位に責任を割り当てる作業が中心になります。クラスや関数の単位で「この箱は何を受け持つか」を定める営みは、分割と総合を同時に走らせているとも言えます。

そしてテストのフェーズには、「枚挙」が待っています。単体・結合・システムテストと積み上げて、全体に見落としがないかを確かめる——デカルトが最後に置いた規則は、現代の品質保証の手前にそのまま残っているのです。

3. 「分けすぎ」が起きるとき、置き去りにされているのは「総合」と「枚挙」

inline-2

「分割すれば解決する」という期待が、現場ではしばしば裏切られます。マイクロサービス化を急いだ結果、サービス間の通信と依存関係が肥大し、かえってシステムが動かなくなる——こうした事例は、設計の失敗というより、四規則の後半を置き去りにした結果と読むこともできます。

分割だけを繰り返したシステムは、総合の道筋が設計されていないため、分けた要素を統合するコストがどこかで支払われることになります。API 設計、イベント駆動、共通モデル——これらは総合の道具ですが、分割の段階でその道具が先に見えていないと、後から接ぎ木のように貼り付けることになります。

さらに厄介なのは、「枚挙」の欠落です。分けた要素のどこに穴があるかを、全体にわたって確かめる視点が抜けると、ユースケースの抜け漏れや例外パスの未定義が、本番で初めて露呈します。統合テストを書くタイミングになってようやく「そもそもこの機能のあいだに、何が通るはずだったか」を誰も書いていない、という事態は、分割の失敗というより枚挙の不在なのではないでしょうか。

適切な粒度で分けるためのコツは、結局のところ「総合と枚挙が回せる大きさに留める」ことに収斂するのかもしれません。変更の経済性、凝集度と結合度、チームのコミュニケーションコスト——こうした判断材料は、どれも分けた後のことを考えた上での、分け方の指標です。分割の答えは、分割の内側では決まらない。

まとめに代えて

デカルトが書き残した四規則のうち、システム設計に流用されているのは「分析」の規則だけではありません。むしろ、私たちの現場でうまく働かないのは、残る三つ——明証・総合・枚挙——の方ではないでしょうか。

分けた先で、何を単純なものとして置き、どう順に積み直し、どこに見落としがないかを精査する。

次に設計に取りかかるときに、デカルトの上記4点を思い出してみるのもよいかもしれません。

参考

  • ルネ・デカルト『方法序説』(谷川多佳子 訳、岩波文庫、1997年)
SHARE
Workspace with laptop

その問いを、一緒に考えませんか。

MOC Labs は、AI 活用・DX 推進・業務改善・思考法の現場で、コンサルティングと実装の両面からご支援します。記事を読んで広がった問いがあれば、お気軽にご相談ください。

MOC Labs にお問い合わせ