ダイクストラと構造化プログラミング：スケールする規律

なぜソフトウェアが成長するときにダイクストラは今も重要なのか

ソフトウェアが失敗するのは、書けないからではまれにしかありません。失敗するのは、1年後に誰も安全に変更できなくなるからです。

コードベースが大きくなると、あらゆる「小さな」変更が波及します：バグ修正が遠くの機能を壊す、新しい要件が書き直しを強いる、単純なリファクタが一週間の綿密な調整に変わる。問題はコードを追加することではなく、周囲が変わっても振る舞いを予測可能に保つことです。

約束：正しさと単純さは長期コストを下げる

エドガー・ダイクストラは、正しさと単純さを単なる“良いもの”としてではなく、最優先の目標にすべきだと主張しました。その効果は学問的な議論に留まりません。システムの理解が容易になると、チームは火消しに費やす時間を減らし、構築に集中できます。

• 正しさ はミスのコストを減らします：障害が減り、回帰が減り、“触るな”コードが減ります。
• 単純さ は変更のコストを減らします：隠れた仮定が減り、特例が減り、レビュー時の驚きが減ります。

「スケール」とは実際に何を意味するのか

人々がソフトウェアの「スケール」を語るとき、多くはパフォーマンスを指します。ダイクストラの指摘は別物です：複雑さもスケールするのです。

スケールは次のように現れます：

• 機能の増加: 新しいフロー、エッジケース、ユーザー期待。
• 人員の増加: 引き継ぎ、スタイルの違い、異なる文脈。
• 統合の増加: 外部API、データソース、失敗モード。
• 時間の経過: レガシー判断、変わる要件、部分的な書き換え。

中核の考え：構造が振る舞いを予測しやすくする

構造化プログラミングは単に厳格さを求めるものではありません。次の二つを簡単に答えられるように制御フローと分解を選ぶことです：

• 「次に何が起きるか？」
• 「どんな条件の下でか？」

振る舞いが予測可能であれば、変更は危険ではなく日常になります。だからダイクストラは今でも重要です：彼の規律は成長するソフトウェアの本当のボトルネック——十分に理解して改善できること——を狙っています。

エドガー・ダイクストラと彼の目標の簡単な紹介

エドガー・W・ダイクストラ（1930–2002）はオランダの計算機科学者で、信頼できるソフトウェアを作るための考え方に影響を与えました。初期のオペレーティングシステムに携わり、最短経路アルゴリズムなどの成果を残し、日常の開発者にとって最も重要なのは「プログラミングは結果が出るまで試すものではなく、論理的に説明できるものであるべきだ」という考えを推進したことです。

彼の中心的焦点："動くかどうか"ではなく"説明できるか"

ダイクストラは、プログラムがいくつかの例で正しい出力を出すかどうかよりも、重要なケースについて「なぜ正しいか」を説明できるかを重視しました。

コードの目的を述べられるなら、そのコードが実際にそれを行うことを段階的に議論できるはずです。この考え方は、読みやすく、レビューしやすく、英雄的なデバッグに依存しないコードにつながります。

厳しく聞こえる理由とその効果

ダイクストラの文章は厳格に感じられることがあります。彼は「巧妙な」トリック、いい加減な制御フロー、推論を難しくするコーディング習慣を批判しました。厳格さはスタイルの監視ではなく曖昧さを減らすことが目的です。コードの意味が明確であれば、意図の議論に時間を費やす代わりに振る舞いの検証に時間を使えます。

「構造化プログラミング」とは（高レベル）

構造化プログラミングは、プログラムをごちゃごちゃしたジャンプではなく、順序、選択（if/else）、反復（ループ）のような限られた明確な制御構造から組み立てる実践です。目的は単純：プログラムの経路を理解しやすくして、自信を持って説明、保守、変更できるようにすることです。

正しさ：ユーザーが頼りにする隠れた機能

人々はしばしばソフトウェア品質を「速い」「美しい」「機能豊富」と表現します。ユーザーが体験する正しさは違った形で現れます：アプリが驚かさないという静かな自信です。正しさがあれば誰も気にしません。欠けていれば他はどうでもよくなります。

「今動く」か「ずっと動く」か

「今動く」はいくつかの経路を試して期待した結果が得られたことを意味します。「ずっと動く」はリファクタ後や新しい統合、高負荷、別の開発者が触った後でも意図通りに振る舞うことを意味します。

ある機能は「今動く」一方で脆弱かもしれません：

• 入力が常にクリーンであると仮定している
• ネットワーク呼び出しが常に速く返ると想定している
• ハッピーパスしかカバーしないテストしか通っていない

正しさはこれらの隠れた仮定を取り除くか、明示的にすることです。

少さなバグが大きなシステムで増幅する仕組み

小さなバグはソフトウェアが成長するとほとんど小さいままでいません。ひとつの不正確な状態、オフバイワン、曖昧なエラーハンドリングルールが新しいモジュールにコピーされ、他のサービスに包まれ、キャッシュされ、再試行され、回避策で覆われます。時間が経つとチームは「何が真か？」を問う代わりに「普段はどうなるか？」を前提にするようになります。そこでインシデント対応が考古学になります。

増幅の要因は依存関係です：小さな誤動作が多くの下流の誤動作に拡大し、それぞれが部分的な修正を生み出します。

明快さはスタイルではなく正しさの道具

明確なコードはコミュニケーションを改善するため、正しさを高めます：

• コードレビュー は意図が明白なら本質的な問題を捕まえられる。
• オンボーディング はルールが読みやすければ早く進む。部族知識に依存しない。
• インシデント は制御フローと失敗モードが追跡しやすければ早く解決できる。

プロダクトチームのための実務的な正しさ定義

正しさはこうです：我々がサポートすると主張する入力と状況に対して、システムが一貫して約束した結果を生み出し、できない場合は予測可能で説明可能な方法で失敗すること。

戦略としての単純さ、趣味としての単純さではない

単純さはコードを「かわいく」したり最小化したりすることではありません。振る舞いを予測し、説明し、恐れずに変更できるようにすることです。ダイクストラが単純さを重視したのは、それがプログラムを論理的に考えやすくするからであり、特にコードベースとチームが成長したときに効きます。

単純さとは何か（そして何ではないか）

単純なコードは同時に扱うアイデアの数が少ない：明確なデータフロー、明確な制御フロー、明確な責務。読者に多数の代替経路を頭の中でシミュレートさせないコードです。

単純さは以下ではありません：

• 行数を減らすことを最優先すること
• 「賢い」トリック、密なワンライナー、過度な抽象
• 柔軟に見せるために構造を避けること

偶発的複雑さ：意図せず追加したもの

多くのシステムが変更困難になるのは、ドメインが本質的に複雑だからではなく、偶発的複雑さを導入してしまうからです：相互に作用するフラグ、削除されない特例パッチ、以前の決定の回避のために存在する層。

各特例は理解に対する税です。コストは後で現れます：誰かがバグを直そうとして変更すると、一部を変更しただけで他が微妙に壊れることに気づくのです。

単純な設計はヒーローを不要にする

設計が単純なら進歩は着実な作業から来ます：レビュー可能な小さな差分、緊急修正の減少。チームはすべてを記憶する“ヒーロー”に頼る必要がなくなり、通常の人間の注意範囲でシステムが支えられます。

経験則：特例が少ないほど驚きは少ない

実用的なテスト：例外（「ただし…」「〜の場合を除く」「この顧客のみ」）を増やし続けているなら、偶発的複雑さを蓄積しています。振る舞いの分岐を減らす解決を好んでください。たとえその一貫した規則が最初に想像したより一般的でも、五つの特例よりは一つの一貫した規則が望ましいことが多いです。

構造化プログラミング：信頼できる明確な制御フロー

構造化プログラミングは実行経路を追いやすく書くという単純なアイデアで、大きな影響を持ちます。多くのプログラムは三つの構成要素—sequence（順序）、selection（選択）、repetition（反復）—から構築できます。絡まったジャンプに頼る必要はほとんどありません。

三つの構成要素（人間向けの説明）

• Sequence: ステップAを行い、その次にB、次にCを行う。
• Selection: 条件に基づいて経路を選ぶ（例：if/else, switch）。
• Repetition: 条件が成り立つ間、あるステップ群を繰り返す（例：for, while）。

これらの構造から制御フローを構成すると、上から下へ読めばプログラムの動作を説明できることが多く、ファイル中を“瞬間移動”する必要が減ります。

何を置き換えたか：スパゲッティ的な実行経路

構造化プログラミングが標準になる前、多くのコードベースは任意のジャンプ（古典的な goto スタイル）に頼っていました。問題はジャンプ自体が常に悪いのではなく、無制限のジャンプが実行経路を予測困難にすることです。すると「ここにはどうやって来たか？」「この変数の状態は？」といった問いにコードが明確に答えられなくなります。

なぜ明快さが実チームで重要か

明確な制御フローは、人間が正しいメンタルモデルを作るのを助けます。そのモデルはデバッグ、プルリクのレビュー、時間制約の下で振る舞いを変えるときに頼るものです。

構造が一貫していると変更は安全になります：ある分岐を変えても別の分岐に影響しにくく、ループをリファクタしても隠れた抜け道を見落としにくい。可読性は単なる美学ではなく、既存の動作を壊さずに振る舞いを変える基盤です。

推論ツール：不変条件、前提条件、事後条件

ダイクストラは単純な主張をしました：コードが正しい理由を説明できれば、それを恐れずに変更できるということ。三つの小さな推論ツールが実務で有効です——チームを数学者にする必要はありません。

不変条件（invariants）：「常に成り立つ事実」

不変条件は、特にループ内でコードが実行されている間に常に成り立つ事実です。

例：カート内の価格を合計しているとします。役に立つ不変条件は「total はこれまで処理した項目の合計に等しい」です。その不変条件が各ステップで保たれていれば、ループ終了時の結果は信頼できるものになります。

不変条件は「次に何が起きるべきか」ではなく「決して壊れてはいけない事実」に注意を集中させるため強力です。

前提条件と事後条件：日常の契約

前提条件（precondition） は関数が実行される前に成り立っているべきことです。事後条件（postcondition） は関数が終わった後に保証することです。

日常例：

• 前提条件：「残高が十分なときだけ引き出せる」
• 事後条件：「引き出し後、残高は正確にその金額だけ減り、負にならない」

コードでは、前提条件が「入力リストがソート済み」で、事後条件が「出力リストはソート済みで、元の要素に挿入要素が加わっている」といった具合です。

書き留めることがコーディングとレビューをどう変えるか

これらを（非形式的でも）書き留めると設計が鋭くなります：関数が期待することと約束することを決めるので、自然と小さく焦点の合ったものになります。

レビューでは議論がスタイル（「こう書きたい」）から正しさ（「この不変条件を維持しているか？」「前提条件を強制するか文書化するか？」）へと移ります。

軽量な実践：バグが集中する箇所にコメントを残す

形式的な証明は不要です。バグが多いループや複雑な状態更新を一つ選び、その上に一行の不変条件コメントを追加してください。将来誰かが編集する際、そのコメントはガードレールのように働きます：もし変更でその事実が壊れるなら、コードは安全ではなくなります。

テストと推論：それぞれ何が保証でき、何ができないか

テストと推論は同じ結果（意図した振る舞い）を目指しますが、アプローチが異なります。テストは例を試して問題を発見します。推論は論理を明示化して問題のカテゴリを予防します。

テストの得意分野

テストは実用的な安全網です。回帰を捕まえ、現実的なシナリオを検証し、チーム全員が実行できる形で期待を文書化します。

しかしテストはバグの存在を示せるだけで、存在しないことは示せません。すべての入力、すべてのタイミング変動、すべての機能間の相互作用を網羅することは不可能です。多くの「自分の環境では動く」問題は未テストの組み合わせ——稀な入力、特定の操作順序、いくつかのステップを経て初めて現れる微妙な状態——から起きます。

推論が保証できること（とできないこと）

推論はコードの性質を証明することに関係します：「このループは常に終了する」「この変数は決して負にならない」「この関数は無効なオブジェクトを返さない」など。うまく行えば境界やエッジケースに関する欠陥の大きな分類を排除できます。

制約は労力と適用範囲です。製品全体に対する完全な形式証明はほとんど経済的ではありません。推論は選択的に使うのが有効です：コアアルゴリズム、セキュリティに関わるフロー、金銭処理、並行処理など失敗コストが高い箇所。

スケールするためのバランスの取れたアプローチ

テストを広く使い、失敗が高コストな場所には深い推論を適用します。

両者の橋渡しとなる実用的手法は、意図を実行可能にすることです：

• 内部仮定のためのアサーション（例：「インデックスが範囲内である」）
• 関数入出力の前提条件／事後条件（契約）
• 持続する真実のための不変条件（例：「カート合計は項目の合計に等しい」）

これらはテストの代わりではなく、網を締める技術です。漠然とした期待を検査可能なルールに変え、バグを書きにくくし、診断を容易にします。

規律：チームが「巧妙さ負債（cleverness debt）」を避ける方法

「巧妙」なコードは瞬間的には勝利に感じられます：行数が少ない、きれいなトリック、気分が良くなるワンライナー。しかし巧妙さは時間や人を跨いでスケールしません。6か月後に作者がトリックを忘れ、新しいメンバーが文字通り読んで隠れた仮定を見落とし、振る舞いを壊します。それが巧妙さ負債です：短期的スピードを長期的混乱で買うこと。

規律はチームの加速装置

ダイクストラの要点は「退屈なコードを書け」ではなく、規律ある制約がプログラムを論理的に考えやすくするということです。チームでは制約が意思決定疲労を減らします。もし命名規則、関数の構造、「完了」の定義といったデフォルトが決まっていれば、毎回のプルリクで基本事項を再議論する必要がなくなり、その時間はプロダクト作業に戻ります。

規律は日常の習慣として現れます：

• コードレビュー は新奇性より明快さを評価する（「他の人が安全に変更できるか？」）。
• 共有標準（フォーマット、命名、エラーハンドリング）でコードベースが一貫した声に聞こえるようにする。
• リファクタを継続的な保守として扱う：小さなクリーンアップを常に行う。

コード上での「規律」の外観

巧妙さ負債を蓄積しない具体的習慣：

• 小さな関数：ひとつの仕事をし、入力と出力が明白。
• 明確な名前：意図を説明する（calculate_total() は do_it() より優先）。
• 隠れた状態を持たない：グローバルを最小化し副作用を明示的に渡す。
• まっすぐな制御フロー：順序に依存するロジックやマジック値、トリックで動く設計を避ける。

規律は完璧さではなく、次に来る変更を予測可能にすることです。

モジュール性と境界：変更を局所化する

モジュール性は単に「コードをファイルに分ける」ことではありません。決定を明確な境界の背後に隠し、他が内部の詳細を知らなくていいようにすることです。モジュールは厄介な部分（データ構造、エッジケース、性能上の工夫）を隠し、小さく安定した公開面を提供します。

モジュールが爆発範囲を縮める方法

変更要求が来たとき理想は：1つのモジュールが変わり、他は触られないこと。これが「変更を局所化する」の実用的意味です。境界は偶発的結合を防ぎます。ある機能を更新したら三つの他が壊れる、という状況を避けられます。

良い境界は推論も容易にします。モジュールが何を保証するか述べられれば、毎回実装全体を読み返さなくても大きなプログラムを論理的に扱えます。

インターフェースは約束（並列作業を可能にする）

インターフェースは約束です：「この入力を与えれば、この出力を作り、このルールを守る」。その約束が明確ならチームは並列に作業できます：

• ある人がモジュールを実装し、
• 別の人がそのインターフェースを使って呼び出し側を作り、
• QAは約束された振る舞いに基づいてテストを設計する。

これは官僚的なことではなく、大きくなるコードベースで安全な協調ポイントを作ることです。

ドリフトを防ぐ簡単なモジュールチェック

大規模なアーキテクチャレビューをする必要はありません。軽量なチェックを試してください：

• 入力/出力: モジュールの入力、出力、副作用を数行で列挙できるか？できないなら多機能すぎ。
• 所有権: 振る舞いと変更の責任者は誰か？所有されていないモジュールはゴミ置き場になりがち。
• 依存関係: "あらゆるもの" に依存していないか？必要最小限にするほど驚きが減る。

よく引かれた境界は「変更」をシステム全体のイベントから局所的な編集に変えます。

なぜこれらの考えが（チーム、コードベース、時間で）勝つのか

ソフトウェアが小さいうちはすべてを頭の中に入れておけます。スケールするとそれは不可能になり、失敗モードが明らかになります。

よくある症状：

• ある驚きのコーナーケースに起因する障害
• すべての変更がリスクに見えるためリリースが遅くなる
• マイナーな更新で下流が脆くなる統合

構造は認知負荷を下げる

ダイクストラの中心的な賭けは「人間がボトルネックである」ということです。明確な制御フロー、小さく定義された単位、論理的に考えられるコードは審美的選択ではなく、容量を増やす手段です。

大きなコードベースでは、構造は理解のための圧縮のように働きます。関数に明示的な入出力があり、モジュールに名前を付けられる境界があり、ハッピーパスがすべてのエッジケースと絡み合っていなければ、開発者は意図を再構築する時間を減らし、意図的な変化に時間を使えます。

チーム規模にもスケールする

チームが大きくなるとコミュニケーションコストは行数より速く増えます。規律ある可読なコードは貢献に必要な部族知識を減らします。

これはオンボーディングで即座に現れます：新しいエンジニアは予測可能なパターンを辿り、少数の慣習を学び、長い“トラップ”の説明なしに変更できます。コード自体がシステムを教えてくれるのです。

インシデントは追跡しやすく、巻き戻しも安全になる

インシデント時は時間が乏しく信頼が弱い。前提条件や意味のあるチェック、まっすぐな制御フローのあるコードはプレッシャー下で追跡しやすい。

さらに重要なのは、規律ある変更は巻き戻しもしやすいことです。小さく局所的な編集と明確な境界は、ロールバックが新しい障害を生む可能性を減らします。結果は完璧ではなくても、驚きが少なく、回復が速く、年と貢献者が増えても保守可能なシステムです。

独善的にならずにダイクストラを適用する

ダイクストラの主張は「古い書き方で書け」ではなく「説明できるコードを書け」です。この考え方はすべてを形式証明にすることなく採用できます。

原則を日常の習慣に変える

推論を安くする選択から始めてください：

• 単純な制御フローを好む：大きな多分岐ルーチンより小さい関数の集まり。
• 副作用を減らす：変異は必要な場所に近づけ、関数がグローバル状態を密かに変更しないようにする。
• 明確な契約を使う：入出力とエラー振る舞いを型、名前、コメントで明示する。

良いヒューリスティック：関数が何を保証するかを一文で要約できないなら、多分やりすぎです。

小さな「構造のアップグレード」（書き換え不要）

大規模なリファクタは不要です。継ぎ目で構造を追加してください：

• 複雑なループを名前付き関数に切り出し、各反復で成り立つことを定義する。
• "魔法" 条件をよく名付けた述語に置き換える（例：isEligibleForRefund）。
• 厄介な状態遷移を単一の関数でカプセル化して他が誤用できないようにする。

これらは段階的な改善で、次の変更の認知負荷を下げます。

コードレビューの問いかけで自分に厳しくなる

変更をレビュー（または作成）するとき、自問してください：

• 「ここで何が成り立たねばならないか？」（不変条件、想定、必要な状態）
• 「何が安全に変えられるか？」（どの部分が呼び出し元に影響を与えず変わってよいか）

レビュワーがすぐに答えられないなら、コードは隠れた依存を示しています。

手順ではなく理由をドキュメント化する

コードをそのまま説明するコメントは古くなります。代わりになぜ正しいかを書いてください：主要な仮定、守っているエッジケース、仮定が変わったら何が壊れるかの要点。短い注記（例：「不変条件：total は常に処理済み項目の合計」）は長い説明文より価値があります。

これらの習慣を収める軽量な場所が欲しいなら、共通のチェックリストを作って /blog/practical-checklist-for-disciplined-code にまとめてください。

AI支援の開発はどこにフィットするか（規律を失わずに）

現代のチームはAIで開発を加速しています。リスクはおなじみです：今日のスピードが説明できない生成コードによる明日の混乱になること。

ダイクストラ的にAIを使う方法は、AIを「構造的思考の加速装置」として扱い、置き換えにしないことです。たとえば、チャットでウェブやバックエンド、モバイルを作るようなプラットフォーム（例：Koder.ai）で作る場合、次のように意図とレビューを明確にしてください：

• 明確な契約 を要求する："このエンドポイントの前提条件、事後条件、エラー挙動を定義して。"
• 状態フローに不変条件を要求する："このチェックアウト状態機械の各ステップ後に何が常に真であるべきか？"
• 計画モード を使い、実装の詳細を生成する前にモジュール、インターフェース、責務へ分解する。
• スナップショットとロールバック を活用し、変更を小さく可逆に保つ。これは局所的編集と安全な取り消しの規律を反映します。

最終的にソースをエクスポートして別の場所で動かすとしても、生成されたコードは説明できるコードであるべきです。

正しく、単純で規律あるコードのための実用チェックリスト

これは軽量な「ダイクストラ寄り」チェックリストで、レビュー、リファクタ、マージ前に使えます。これは一日中証明を書くためではなく、正しさと明快さをデフォルトにするためのものです。

クイックスセルフチェック（新規コードとリファクタ）

• 60秒で同僚に説明できるか？ 多くの「信じてくれ」で始まる説明が必要なら簡素化する。
• 制御フローは明白か？ 直線的なコードを優先し、ループや分岐を小さく保ち、隠れた抜け道や深いネストを避ける。
• 前提条件と事後条件は何か？ コメントやドックストリング、関数名に書いておく。言えないなら多分やりすぎ。
• 各関数は一つの仕事と明確な境界を持っているか？ 入力が入り、出力が出る――グローバル状態依存は最小限に。
• このループを正しく保つ不変条件は何か？ "total は処理済み項目の合計" のような一行が助けになる。
• 必要以上の巧妙さはないか？ コードが案内役を必要とするなら、巧妙さ負債を蓄積しています。

質的に測るべきこと

• 説明のしやすさ: モジュールを知らない人が何をするか正しく説明できるか？
• テストしやすさ: エッジケースは自然にテスト可能か、それとも面倒なセットアップとモックが必要か？
• 変更リスク: 要件が変わったとき、何が壊れるか予測できるか？すべての変更が怖いなら境界が漏れている。

実用的な次の一手

一つの乱れたモジュールを選び、まず制御フローを整理してください：

1. 小さな関数を切り出して明確な名前を付ける。
2. もつれた分岐を単純な明示的ケースに置き換える。
3. 特例を端に移し（入力検証、早期リターン）、境界をはっきりさせる。

その後、新しい境界の周りに集中したテストを数件追加してください。関連パターンをもっと見たい場合は /blog を参照してください。