ハクソク

世界を動かす技術を、日本語で。

システム思考

2026年2月6日原文(theprogrammersparadox.blogspot.com)

概要

  • ソフトウェア開発には 進化的アプローチ と 設計主導アプローチ の2大流派が存在
  • 進化的手法は 早く始めやすい が、複雑性と依存関係の管理が課題
  • 設計主導手法は 全体最適化が可能 だが、 初期コストと調整負荷 が高い
  • 依存関係の扱い方 が両者の根本的な違い
  • バランスの取れた中間案 が理想だが、実践例は少ない

ソフトウェア開発における「進化」と「設計」アプローチ

  • ソフトウェア開発には 2つの主流アプローチ が存在
    • 進化的アプローチ ：小さく始めて徐々に機能追加
    • 設計主導アプローチ ：事前に詳細な仕様を策定し構築
  • 進化的手法は スタートアップのような起業家精神 に近い
  • 設計主導手法は 高層ビル建設のような工学的手法 に近い

大規模システムの進化的成長の実例

  • 大企業内で 3000以上のシステム が50年かけて進化
  • 多様な 技術スタック・ベンダー が混在
  • 全体として見れば 不安定なシステム群 となる
  • システム数を減らせば データ・セキュリティ・運用の問題 が大幅に減少
  • 複雑性は1/10以下 に圧縮可能な可能性

依存関係と複雑性管理

  • 両流派の根本的な違いは 依存関係の扱い方
  • 進化的手法： 依存関係を後回し にし、まず開発を優先
  • 設計主導手法： 依存関係を事前に設計 し、全体最適を目指す
  • 設計主導は 調整・コミュニケーション負荷 が高く、短期的には進化的手法が速い
  • 依存関係を後で解決するとコスト増、修正や調整が困難化

技術的知識とキャリアパスの影響

  • 最新技術の変化 や 経験不足 が設計主導型の障壁
  • 多くのエンジニアは 実務経験5年未満
  • 進化的プロジェクトは楽しい が、スケールすると ストレス増大
  • 設計主導型はストレスが少なく、着実な進行 が可能

両者のメリット・デメリット

  • 進化的手法： 早期開発・柔軟性・少ない会議 が魅力
    • だが、 大規模化で破綻リスク や 技術的負債の増大
  • 設計主導手法： 品質・信頼性・再利用性向上
    • だが、 初期設計・調整コスト が高い

バランス型アプローチの模索

  • 理想は中間的なバランス型
    • 依存関係を意識しつつ、進化的開発と設計主導を組み合わせ
    • リリースごとに振り返り・リファクタリング を実施
    • イテレーションの大きさ も状況に応じて調整
  • スピードと品質のトレードオフ を意識
  • 進化的手法は動的だが混沌としやすい
  • 設計主導手法は安定だが初動が遅い
  • 両者の適切な使い分け と 定期的な見直し が重要

結論

  • 大規模システム開発 では、部分ごとに 進化的手法と設計主導手法を使い分け
  • 無秩序な進化はコスト増大、 過度な設計も機動力低下
  • 最適なバランス探求 と 継続的な改善活動 が成功の鍵

Hackerたちの意見

「機能する複雑なシステムは、必ず機能する単純なシステムから進化してきたことがわかる。逆の命題も真であるようだ：ゼロから設計された複雑なシステムは決して機能せず、機能させることもできない。動作する単純なシステムから始めなければならない。」ガルの法則

└

ほんとそれ。

└

ああ、セカンドシステム効果とそこから学んだ教訓だね。

└

よく引用されるけど、実際に厳密に正しいのか疑問だな。「機能する」の定義を合理的に考えた場合ね。機械工学では確実に当てはまらないよ。

└

みんなこれを誤解して、物置から超高層ビルを段階的に作れると思ってるんだよね。

└

ここで重要なのは「ゼロから」という部分だと思う。通常、新しい（2番目、3番目、何でも）システムを古いものに置き換えるとき、前の設計の良い部分と悪い部分を考慮に入れるから、もはやゼロからではないんだ。それが成功を可能にするんだよ（少なくとも私の経験では、たいてい成功した）。

└

このコメントを追加するためにここに来たよ。 https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

└

一部のシステムは、その複雑さに完全にコミットする必要がある。単純な形ではうまく機能しないこともあるからね。多くの文脈において、「システム思考」は、より単純なサブシステムに還元できないシステムの設計について明示的に述べられていることが多い。時には、全てを受け入れなければならないこともあるよ。いくつかのタイプのソフトウェアでは、運用プロトタイプを構築するコストが、実際のコードを書くコストに漸近的に収束する現象もあるんだ。（これは、プロトタイプを構築することで納品リスクが大幅に減少すると思っている管理職に説明するのがいつも楽しいことだよ。）

ソフトウェア開発には、本当に大きくて複雑なものをどう作るかについての二つの主要な考え方がある。 > 最近では、徐々に複雑さを進化させていくのが一般的な考え方だ。小さく始めて、どんどん追加していく。 > もう一つの考え方は、すべての複雑さを事前に完全に理解した大規模な仕様を作成してから構築するというものだ。AIが人々のソフトウェアの作り方に面白い変化をもたらすと思う。実装そのものではなく、仕様を作成し、反復する方向に進むだろう。ある意味、仕様はソフトウェアの最もコンパクトな定義だ。1行あたりの知識密度は、どのプログラミング言語よりも高い。これにより、仕様は読みやすく、考えやすく、反復しやすくなる—AIや仲間と一緒に。オープンソースプロジェクトが、実装ではなく仕様に完全に依存するようになるのを想像できる。これらの仕様は議論され、人々がプルリクエストの代わりに考えを寄せることができる。アイデアが具体的であればあるほど、実際の仕様に「マージ」される可能性が高くなる。メンテナは、「アイデアのマージリクエスト」をレビューし、仕様を更新する前にAIアシスタントと議論する方が、コードをレビューするよりも簡単だろう。仕様はソフトウェアの実装と同様にバージョン管理でき、実行中のバージョンや安定版リリースを持つことができる。プラットフォーム固有の注意点やライブラリの推奨をリストした付録を含めることもできる。良い仕様があれば、開発者はどんな言語でも自分のツールを作れる。新しいバージョンの仕様を取得し、現在のものと比較して、AIに差分を実装させたり、自分に必要なことや不要なことを議論させたりできる。似たように、自分の要件で仕様を「パッチ」する方が、既製のソフトウェアを修正するよりも簡単だろう。面白い時代だね。

└

オープンソースプロジェクトが、仕様に完全に依存するようになるのを想像できる これは本当に良い観察だね、君の予測は当たると思う。これにはSaaSに対する影響がある。お金を節約するためにvibecodeが必要な例のSaaSを想像できる。今それが不可能な理由は、Claudeができないからではなく、君が提案したように、正しい仕様を得るのが大変だからだ。よく書かれた仕様は、そのソフトウェアのドメインにおけるベストプラクティスだけでなく、法的なコンプライアンスの面倒くさいことも含まれている。適切なモジュール化された仕様があれば、もっとvibecodedなSaaSが見られるようになると思う。全体的に、君の予測は本当に強いと思う。

└

これに関するアイデアに興味がある。仕様のための異なるコンパクトなDSLを考えたことがあるけど、構造化されていないもの（ファイル固有の所有権の境界を超えた）は、私にはうまく機能している。

└

アイスバーグは、主に仕様だよ[0]。どんなデータが保存され、どのようにやり取りされるかを正確に定義している。コミュニティはまず仕様変更について広く議論する。最近のクロスプラットフォームSQL UDFについてのものを見てみて[1]。まだ大規模なLLM駆動の言語実装は見ていないけど、確かに可能だと思う。LLMにJavaの実装を必要な言語に翻訳するように指示する方が簡単だろう。vibe-codedな言語は、企業のデータに大きなダメージを与える可能性がある。[0] https://iceberg.apache.org/spec/ [1] https://lists.apache.org/thread/whbgoc325o99vm4b599f0g1owhgw...

Hacker Newsで議論の続きを見る