最終更新日：
本稿は、ソフトウェアエンジニアリングを「要求を実装する作業」ではなく、「システムをあるべき状態へ導き続ける経験的な設計・制御活動」として捉え直す。中心となる比喩は reconciliation loop である。ここでは reconciliation loop を、あるべき状態と現在状態との差分を観測し、コード、設計、運用、組織プロセスの変更によって差分を小さくし、その結果に基づいて方針自体も更新する反復的な営みと定義する。
この見方は、Scrum の経験的プロセス制御、Kubernetes controller の状態調整、自己適応システムのフィードバックループなど、観測と適応を重視する既存の考え方と接続できる（Schwaber & Sutherland, 2020; Kubernetes Documentation, n.d.; Kephart & Chess, 2003）。一方で、あるべき状態は最初から完全には定義されない。性能、信頼性、保守性、開発速度、セキュリティ、コスト、説明責任、組織能力などの制約は相互に衝突し、途中で変化する。さらに、制約だと思われていたものが、観測を通じて変更可能な前提や単なる慣習だったと分かることもある。方針決定は、複数の目的を同時に改善しようとする多目的最適化問題にも見えるが、実務では有限な予算、人員、期限、既存システム、法規制、運用能力が先に境界を作る。そのため、本稿ではこれを、複数の制約を同時に満たす構成を探す制約充足的な探索として捉える。ただし、厳密な制約充足問題そのものではなく、プロトタイプ、リリース、計測、障害、ユーザーフィードバックを通じて経験的に進められる。
さらに本稿は、ソフトウェアエンジニアリングとマネジメントの同型性を論じる。マネジメントもまた、方針を立て、状況を観測し、資源を配分し、制約を調整し、組織をあるべき姿へ導く営みである。ただし、ソフトウェアエンジニアリングには、方針をコード、テスト、継続的インテグレーションと継続的デリバリー、インフラ構成やポリシーをコードとして扱う実践、すなわち Infrastructure as Code や Policy as Code などの実行可能な人工物へ変換できるという固有性がある（Amazon Web Services, n.d.; Open Policy Agent, n.d.-a）。少なくともインフラ構成やアクセス制御のように機械で扱える領域では、方針を観測・検証・自動化・再現の対象にできる。
AI 支援開発が実務上の選択肢として存在感を増す現在、少なくとも定型的・局所的な実装タスクでは、AI 支援によって完了時間が短くなりうることが報告されている（Peng et al., 2023）。一方で、組織全体のデリバリ性能や品質への影響は一様ではない。DORA 2024 は、AI 利用が個人の生産性などに正の関連を示す一方、デリバリ安定性とスループットには負の関連を示したと報告した（DORA, 2024）。続く DORA 2025 と DORA の 2026 年記事は、AI を組織の強みと弱みを増幅する要因として捉え、スループット改善と不安定性増加が同時に起こりうると整理している（DORA, 2025; DORA, 2026）。だからこそ、どの問題を解くべきか、どの制約を優先すべきか、どのリスクを観測可能にしてから進むべきかを判断する能力は、むしろ重要になる。この能力は才能だけではなく、制約の言語化、熟練者の判断過程の可視化、実践共同体への参加、意図的練習、結果からの反省によって育てられる専門職技能である。評価においても、コード量や短期成果だけでなく、判断前の仮定、実行中の観測、事後の学習を含めて見る必要がある。
結論として、ソフトウェアエンジニアリングとは、システムを reconciliation loop により導き、その方針決定を制約充足的な探索として経験的に進めることである。
ソフトウェアエンジニアリングは、しばしば「要求を聞き、設計し、コードを書き、テストして届ける活動」と説明される。この説明は間違っていない。しかし、実務の感覚からすると、少し静的すぎる。私たちが日々向き合っているのは、最初から輪郭のはっきりした要求でも、完成すれば安定して価値を出し続ける成果物でもない。利用者の期待は変わり、市場や法制度は変わり、技術基盤も組織の能力も変わる。そのたびに、昨日まで妥当だった設計や運用が、今日の現実から少しずつずれていく。
本稿では、ソフトウェアエンジニアリングを「システムをあるべき状態へ導き続ける営み」として捉え直す。ここでいうシステムには、コードだけでなく、利用者、運用、開発組織、意思決定のプロセス、制度的な制約も含まれる。ソフトウェアの価値は、コード単体の内部に閉じて存在するのではなく、それが置かれた環境との関係の中で立ち上がる。したがって、環境が変われば、同じコードであってもあるべき状態から外れうる。
この捉え方は、AI が日常的にコード生成を支援する時代にいっそう重要になる。実装案を生成し、試すコストが下がりうるほど、エンジニアリングの焦点は「どれだけ速く作るか」だけではなく、「どの問題を解くべきか」「どの制約を優先すべきか」「どの変更を今は避けるべきか」へ移っていく。コードを書く速度が上がっても、システムを望ましい方向へ導く判断が弱ければ、変更の量は増えても価値は増えない。
この判断は、目立つ成果として現れにくい。よい判断の成果は、しばしば「起こらなかった障害」「増えなかった複雑性」「スムーズに進んだ移行」として現れるからである。ソフトウェアエンジニアリングを実装量だけで測ると、このような判断の価値を見落としやすい。
本稿の中心に置くのが、reconciliation loop である。reconciliation loop とは、あるべき状態と現在状態との差分を観測し、その差分を小さくするようにシステムを変更し、変更の結果を再び観測する反復的な営みを指す1。本稿では、この言葉を特定技術に閉じた用語ではなく、ソフトウェアエンジニアリング全体を理解するための比喩として用いる。
ただし、実務では「あるべき状態」そのものが最初から明確ではない。性能、信頼性、保守性、開発速度、セキュリティ、コスト、ユーザー体験、組織の能力は、しばしば互いに衝突する。したがって、方針決定は単に正しい要求を選ぶ作業ではない。複数の制約を同時に扱い、どこを満たし、どこを緩め、どこを後で検査するかを決める探索でもある。
本稿の問いは、次の四つである。第一に、ソフトウェアを変化する環境に適応し続けるものとして捉えるなら、エンジニアリングの中心は「完成」ではなく何になるのか。第二に、方針や要求が最初から明確ではないことを前提に、それらを実装と観測を通じてどのように形成し、扱っていくのか。第三に、方針決定は単なる意思決定なのか、それとも複数の制約を同時に満たそうとする経験的な制約充足的探索なのか。第四に、その判断能力は才能なのか、それとも教育と実践によって育てられる技能なのか。
以降では、まずソフトウェアが変化する環境の中で進化し続けるシステムであることを確認する。次に、reconciliation loop の構造と、あるべき状態が揺れ動くことによって生じる難しさを扱う。そのうえで、方針決定を制約充足的な探索として捉え、Scrum やマネジメント、組織や制度との接続を検討する。最後に、この判断能力を専門職技能として育て、評価する方法を考える。
本稿の中心命題は、次のとおりである。ソフトウェアエンジニアリングとは、システムを reconciliation loop により導き、その方針決定を制約充足的な探索として経験的に進めることである。
ソフトウェアは、しばしば「作って納品するもの」として語られる。もちろん、一定の範囲を設計し、実装し、リリースする局面はある。しかし、実務で価値を生み続けるソフトウェアは、そこで終わらない。利用者、市場、法制度、技術基盤、競合環境、組織構造が変わる限り、ソフトウェアも変わり続ける。同じコードが昨日は有効でも、今日の業務やユーザー期待には合わなくなることがある。
この性質を理解するうえで、Lehman のソフトウェア進化則は重要である。Lehman は、現実世界に埋め込まれ、その環境と相互作用するソフトウェアを E-type system と呼び、そのようなシステムは継続的に適応しなければ有用性を失うと論じた（Lehman, 1996）。E-type system は、数学的に閉じた問題を解くプログラムではなく、人間や組織の活動と結びついたシステムである。継続運用され、利用者、業務、市場、制度と相互作用する業務システム、Web サービス、社内ツール、プラットフォームの多くは、この性質を持つ。
この見方に立つと、ソフトウェアの価値はコード単体の内部にあるわけではない。価値は、コードが利用者や組織の環境の中でどう働くかによって決まる。注文処理システムは、注文の流れ、在庫管理、配送、会計、顧客対応と結びついて初めて価値を持つ。開発者向けツールは、チームの開発プロセス、レビュー文化、リリース頻度と結びついて初めて意味を持つ。環境が変われば、同じ機能でも価値は変わる。
Parnas の software aging も、この点を補強する。software aging は、ソフトウェアが物理的に摩耗するという意味ではない。変更の蓄積、設計意図の喪失、ドキュメントと実装の乖離、利用環境の変化によって、ソフトウェアが理解しにくく、変更しにくく、現実に合わなくなることを指す（Parnas, 1994）。つまり、ソフトウェアは動いているからといって、健康であるとは限らない。
この劣化は、単にコードが悪くなることだけを意味しない。組織の知識が失われることもある。最初の設計判断を知る人が離れる。運用上の暗黙知が特定の人に閉じる。テストの意図が分からなくなる。リリース判断の根拠が残らない。こうした状態では、システムは現在も動いているように見えても、次の変化に応答する力を失っていく。
したがって、ソフトウェアエンジニアリングを「完成品を作る活動」としてだけ捉えると、実務の中心を見失う。より適切なのは、「変化する環境に対して、システムを調整し続ける活動」と見ることである。ここでいう調整には、コードの変更だけでなく、テストの追加、運用監視の改善、アーキテクチャの見直し、チーム内の役割分担の変更、意思決定プロセスの整備も含まれる。
この章の結論は、ソフトウェアには継続的な導きが必要だということである。システムは、環境から切り離された完成品ではない。環境との関係の中で、あるべき状態から少しずつずれていく。そのずれを観測し、解釈し、縮めていく構造が必要になる。次章で扱う reconciliation loop は、そのための基本的な見方である。
前章では、ソフトウェアが変化する環境の中で導き続けられるシステムであることを確認した。では、導くとは何をすることなのか。本稿では、その基本構造を reconciliation loop と呼ぶ。reconciliation loop とは、あるべき状態と現在状態との差分を観測し、その差分を小さくするために変更を加え、結果を再び観測する反復的な営みである。
この構造は、Kubernetes controller の説明に分かりやすく現れている。Kubernetes の controller は、クラスタの現在状態を観測し、宣言された desired state、すなわちあるべき状態に近づけるように動作する（Kubernetes Documentation, n.d.）。たとえば、ある Deployment で Pod が三つ必要だと宣言されているのに二つしか動いていなければ、controller は不足分を作ろうとする。ここでは、あるべき状態、現在状態、差分、その差分を解消する操作が明確である。
ただし、本稿でいう reconciliation loop は、Kubernetes に限定される技術用語ではない。ソフトウェアエンジニアリング全体を理解するための比喩である。プロダクトの価値、システムの信頼性、開発組織の能力、運用の安定性にも、あるべき状態と現在状態の差分がある。売上が足りない、エラー率が高い、レビューが詰まる、障害対応が属人化している、設計意図が共有されていない。これらはいずれも、何らかのあるべき状態とのずれとして捉えられる。
自己適応システムの研究でも、似た構造が扱われている。Kephart と Chess は、autonomic computing の文脈で、自己管理システムが監視、分析、計画、実行を知識基盤の上で回すことを論じた（Kephart & Chess, 2003）。この構造は MAPE-K loop と呼ばれる。MAPE-K は Monitor、Analyze、Plan、Execute over Knowledge の略であり、知識基盤の上で監視、分析、計画、実行を行うフィードバックループを表す。
ソフトウェアエンジニアリングにおける reconciliation loop も、この MAPE-K loop に近い。現在状態を観測し、差分を分析し、変更を計画し、実行し、結果を知識として蓄積する。ただし、ソフトウェアエンジニアリングでは、対象がコードだけに閉じない。利用者行動、組織構造、運用体制、リリースプロセス、法制度上の制約も観測対象になる。したがって、loop を回すには、ログやメトリクスだけでなく、ユーザーインタビュー、レビュー、ふりかえり、障害報告、事業上の判断も必要になる。
重要なのは、reconciliation loop が「正解を一度で作る」発想ではないということである。あるべき状態を仮に置き、現在状態との差分を見て、変更し、結果から学ぶ。うまくいけば継続し、うまくいかなければ方針を修正する。これは、失敗を前提にするという意味ではない。不完全な情報のもとで現実に働きかけ、観測可能な結果から学ぶという意味である。
この見方は、制御理論やサイバネティクスとも接続できる。Wiener は、制御と通信を扱うサイバネティクスの基礎を論じた（Wiener, 1948）。ただし、本稿では、制御理論の数理へ深く踏み込むことを目的にしない。実務上重要なのは、システムを導くためには、目標、観測、差分、変更、再観測の循環が必要だという理解である。
この章では、reconciliation loop を、ソフトウェアエンジニアリングの基本構造として定義した。しかし、ここには大きな難問が残る。あるべき状態が最初から明確であれば、loop は比較的単純である。現実には、あるべき状態そのものが曖昧で、途中で変わる。次章では、この難しさを扱う。
reconciliation loop は、あるべき状態と現在状態との差分を縮める構造である。しかし、ソフトウェアエンジニアリングでは、あるべき状態が最初から完全に分かっていることは少ない。要求は曖昧で、関係者の期待は一致せず、環境仮定は不完全である。したがって、エンジニアリングは単に与えられた要求を実装する作業ではなく、何をあるべき状態と見なすかを形成していく作業でもある。
では、あるべき状態はどのように定まるのか。ここで重要なのは、あるべき状態を定めることが、単純な宣言ではないという点である。事業価値、利用者の期待、技術的実現可能性、運用能力、法規制、期限、コストといった複数の条件を同時に満たしながら、受け入れ可能な方針を探さなければならない。この章ではまず、要求や問題理解が実装前に閉じないことを確認し、そのうえで reconciliation loop がなぜ二重になるのかを整理する。
要求工学の文脈で、Zave と Jackson は要求、仕様、環境仮定の関係を整理した。要求は環境において望まれる条件であり、仕様は機械が満たすべき性質であり、環境仮定は機械の外側の世界について置かれる前提である（Zave & Jackson, 1997）。この整理は、要求を単なる機能一覧として扱わないために有用である。ソフトウェアは、環境の中で要求を満たすために設計される。
しかし、実務ではさらに難しい。要求を満たす仕様を考えるだけでなく、何を要求として扱うべきか自体が変わる。ユーザーは最初から自分の必要を正確に言語化できるとは限らない。事業側の優先順位も、競合状況や組織の都合によって変わる。技術的に試してみて初めて、当初の要求が過大だった、あるいは別の要求の方が重要だったと分かることもある。
この性質は、Rittel と Webber が wicked problem と呼んだ問題に近い。wicked problem とは、問題定義が固定されず、解決案を試すこと自体が問題の理解を変えるような問題である（Rittel & Webber, 1973）。この概念はもともと社会計画の文脈で提起されたものだが、システム開発を wicked problem として扱う議論もある（Yeh, 1991）。ただし、すべてのソフトウェア開発が同じ程度に wicked であるわけではない。探索的なプロダクト開発や業務プロセスを含むシステム開発では、この性質がしばしば現れる。顧客管理システムを作ることが目的だと思っていたら、実際には営業プロセスの再設計が必要だったと分かる。検索機能を改善するつもりが、データ品質や商品分類の問題に行き着く。問題は実装前に完全には閉じていない。
Dorst と Cross は、設計過程において問題空間と解決空間が共進化すると論じた（Dorst & Cross, 2001）。解決案を考えることで問題の見え方が変わり、問題の再定義が次の解決案を変える。Ralph の Sensemaking-Coevolution-Implementation theory も、ソフトウェア設計において、意味づけ、問題と解の共進化、実装が絡み合うことを示している（Ralph, 2015）。設計は、先に問題を完全に理解してから始まるものではない。作ることを通じて、問題を理解していく。
この見方に立つと、reconciliation loop は二重のループになる。一つ目は、現在状態をあるべき状態へ近づけるループである。二つ目は、あるべき状態そのものを学習し、更新するループである。前者だけなら、目標値へ収束する制御に近い。後者を含めると、ソフトウェアエンジニアリングは、目標を形成しながら進む設計活動になる。二重性の理由は、あるべき状態が外部から完全な形で与えられないからだけではない。あるべき状態を定める活動が、複数の制約の中で候補を作り、試し、比較し、捨て、また選び直す探索だからである。
この二重性は、実務上の意思決定を難しくする。何を作るか、どの品質を優先するか、どの制約を受け入れるかは、固定された答えではない。実装、プロトタイプ、リリース、計測、障害、利用者の反応を通じて、判断材料が増える。その材料をもとに、方針を更新する必要がある。
したがって、よいソフトウェアエンジニアリングは、最初の要求を盲目的に守ることではない。もちろん、契約や説明責任は重要である。しかし、現実から学んだことを無視して、最初の方針だけを守るなら、システムは環境との整合性を失う。あるべき状態は、最初に完全に与えられるものではなく、reconciliation loop の中で形成され続ける。次章では、この「あるべき状態を定める」活動を、制約充足的な探索としてもう少し具体的に見る。
前章では、reconciliation loop が二重になる理由を、あるべき姿を定める活動そのものの性質に求めた。本章では、その外側のループ、すなわち「何をあるべき状態と見なすか」を決める活動を扱う。あるべき状態が最初から明確ではないとしても、実務では方針を決めなければならない。どの機能を先に作るか、どの設計を採るか、どの品質リスクを受け入れるか、どの技術的負債を今返すか。これらの判断では、複数の制約が同時に現れる。
制約には、性能、信頼性、保守性、開発速度、セキュリティ、コスト、説明責任、ユーザー体験、既存システムとの互換性、チームのスキル、組織構造などがある。しかも、これらはしばしば衝突する。性能を上げるために複雑な最適化を入れれば、保守性が下がるかもしれない。セキュリティを強めれば、ユーザー体験や開発速度に影響するかもしれない。将来の拡張性を確保しようとすれば、今のリリースが遅れるかもしれない。
この意味で、方針決定は多目的最適化問題のようにも見える。多目的最適化問題とは、複数の目的を同時に扱い、それらの間のトレードオフを考慮しながら、より望ましい解を探す問題である。この比喩は、品質、速度、コスト、保守性、ユーザー体験などを同時に考えるという意味では有効である。
しかし、本稿では多目的最適化問題ではなく、制約充足問題という言葉を主に用いる。制約充足問題とは、与えられた複数の制約を同時に満たす値や構成を探す問題である。理由は、実務では「何を最大化するか」より先に、「何を満たさなければ破綻するか」が現れるからである。予算、人員、期限、既存システム、法規制、セキュリティ要件、運用能力のような有限な条件は、望ましい指標ではなく、まず守るべき境界として働く。ソフトウェアエンジニアリングでは、設計、リリース計画、テスト戦略、移行手順について、単一の目的関数を最大化するというより、複数の条件の中で破綻しない構成を見つける場面が多い。ここで見つけようとしている構成は、単なる実装案だけではない。「このプロダクトは何を実現すべきか」「このリリースでどこまでを目指すべきか」という、あるべき姿の候補そのものでもある。
Search-Based Software Engineering は、この観点を研究領域として扱ってきた。Search-Based Software Engineering とは、ソフトウェア工学上の問題を探索や最適化の問題として捉える研究領域であり、Harman と Jones がその考え方を明確に提示した（Harman & Jones, 2001）。その後の包括的なサーベイは、Search-Based Software Engineering が要求、プロジェクト計画、テスト、保守、再工学など、ソフトウェアライフサイクルの広い範囲に応用されてきたことを整理している（Harman, Mansouri, & Zhang, 2012）。この研究は、ソフトウェアエンジニアリングが候補空間の中からよりよい解を探す活動であることをよく示している。ただし、これは実務上の方針決定一般が、厳密な制約充足問題として定式化できるという意味ではない。
ただし、実務上の方針決定を、そのまま純粋な数理問題として扱うことはできない。第一に、制約そのものが曖昧である。「保守しやすい」「ユーザーに分かりやすい」「チームにとって無理がない」といった制約は、数式に落としにくい。第二に、制約は途中で変わる。組織の方針、利用者の期待、法制度、技術基盤が変われば、昨日の制約は今日の制約ではなくなる。第三に、制約の重みづけは関係者によって異なる。事業責任者、セキュリティ担当、運用担当、開発者、ユーザーは、それぞれ違うものを重く見る。
さらに重要なのは、制約だったものが制約でなくなることもしばしばある、という点である。たとえば、既存システムとの互換性は絶対条件だと思われていたが、実際には一部の利用者だけが必要としていたと分かることがある。短い納期は動かせない前提に見えても、リリース範囲を分ければ交渉可能な条件になることがある。特定の技術選定が固定されているように見えても、運用チームの懸念を観測し、代替案を比較すれば、別の構成を選べる場合もある。つまり、制約は外から与えられた境界であるだけでなく、観測と対話を通じて、その強さや実在性を見直される対象でもある。
したがって、実務で必要なのは、制約を完全に形式化して一度で解く能力ではない。制約を発見し、衝突を明らかにし、仮定を置き、受け入れ可能な妥協点を見つけ、その結果を実装と運用で検証する能力である。同時に、制約だと思っていたものが本当に制約なのか、単なる慣習、誤解された要求、変更可能な設計判断、交渉可能な前提ではないのかを見直す能力でもある。ここでいう経験的手法とは、厳密さを捨てることではない。不完全な情報のもとで、観測可能な現実に学ぶ態度である。実装や運用で得た観測は、選んだ手段の良し悪しだけでなく、そもそも目指すべき状態の妥当性も検査する。
方針決定の質は、選んだ案だけでなく、選ばなかった案の扱いにも現れる。優れた判断は、「この案がよい」と言うだけではない。「この制約を重く見た」「この仮定が崩れたら見直す」「このリスクは観測可能にする」「この選択肢は今は捨てるが、将来戻れるようにする」といった形で、判断の条件を残す。これにより、後から学習できる。
この章の結論は、ソフトウェアエンジニアリングにおける方針決定は、制約充足問題として読めるが、完全に形式化された数理問題ではないということである。それは、ハード制約、ソフト制約、目的、交渉可能な前提が混在する現実の中で、制約そのものを発見し、更新し、時には制約から外しながら進む経験的な制約充足的探索である。この探索があるから、reconciliation loop は二重になる。内側では現在状態を目標へ近づけ、外側ではその目標自体を制約の中で探索し続ける。この性質は、次章で扱う Scrum の経験的プロセス制御とも接続する。
前章では、あるべき姿を定める活動が制約充足的であり、かつ探索的であるため、reconciliation loop が二重になると述べた。では、その二重の loop を、個人の勘や場当たり的な調整だけに任せず、組織としてどう回すのか。ここで一つの例になるのが Scrum である。Scrum は、しばしば会議体や開発手法の名前として理解される。Daily Scrum、Sprint Planning、Sprint Review、Sprint Retrospective といったイベントを実施することが Scrum だと見なされることもある。しかし、Scrum Guide が強調する中心は、透明性、検査、適応に基づく経験的なプロセス制御である（Schwaber & Sutherland, 2020）。
透明性とは、判断に必要な情報が関係者に見える状態である。検査とは、成果物や状況を定期的に確認し、あるべき状態との差分を見つけることである。適応とは、検査によって分かった差分に基づき、次の行動や方針を変えることである。本稿の比喩でいえば、この三つは reconciliation loop を組織的に回す条件として読める。
Product Goal と Sprint Goal は、あるべき状態や短期目標を暫定的に表現する装置である。Product Goal はプロダクトが向かう将来状態を示す。Sprint Goal は、その短い期間で何を達成するかを表す。一方、Product Backlog はあるべき状態そのものというより、そこへ向かうために必要だと考えられる仮説や作業を透明化し、順序づける装置である。これらは、完全な仕様書ではない。現時点での仮説であり、次の観測と学習のための焦点である。
Sprint Review は、現在状態を観測し、あるべき状態との差分を確認する場である。ここで重要なのは、単に完了した作業を報告することではない。プロダクトの現在の姿を見て、利用者や関係者の反応を得て、次に何を変えるべきかを考えることである。Sprint Retrospective は、プロダクトではなくチームやプロセスの現在状態を観測する場である。チームがよりよく働くために、どのずれに対処すべきかを扱う。
このように見ると、Scrum は単なる開発管理の手順ではなく、組織がプロダクトを導くための reconciliation loop として読める。あるべき状態を暫定的に置き、短い周期で現在状態を観測し、差分を解釈し、次の変更に反映する。しかも、その loop はプロダクトだけでなく、チームの働き方にも向けられている。Product Goal や Sprint Goal は、制約充足的な探索の途中で置かれる暫定解であり、Sprint Review や Sprint Retrospective は、その暫定解と現実のずれを検査する機会である。
もちろん、Scrum は万能ではない。すべての組織、すべてのプロダクト、すべての不確実性にそのまま適用できるわけではない。Scrum のイベントを形式的に実施しても、透明性がなく、検査が浅く、適応が起きていなければ、reconciliation loop は回っていない。逆に、Scrum という名前を使っていなくても、あるべき状態と現在状態の差分を観測し、組織的に学習しているなら、同じ構造は存在する。
Scrum の価値は、方針と環境が不確実で、経験的に学習する必要がある状況で特に大きい。最初に完全な仕様を作って直線的に実装するのではなく、短い周期で現実から学ぶ。これは、第4章で述べた二重の reconciliation loop、第5章で述べた経験的な制約充足的探索と整合している。
この章の結論は、Scrum を会議体の集合としてだけでなく、reconciliation loop の観点からも読めるということである。そのように読むと、Scrum の目的は「決められたイベントを守ること」ではなく、「透明性、検査、適応を通じて、プロダクトと組織をあるべき姿へ導くこと」だと分かる。
ここまでの議論を踏まえると、ソフトウェアエンジニアリングはマネジメントに近い活動だと見えてくる。マネジメントもまた、方針を立て、状況を観測し、資源を配分し、制約を調整し、組織をあるべき姿へ導く営みである。ソフトウェアエンジニアリングがシステムを導く活動だとすれば、それは広い意味でマネジメントである。
この指摘は、エンジニアリングを管理職の仕事に還元するものではない。むしろ、設計や実装の中にマネジメント的な判断が含まれていることを見えるようにするための指摘である。どの設計を採るかは、将来の変更コストを管理する判断である。どのテストを自動化するかは、品質リスクと開発速度を調整する判断である。どの障害対応を仕組み化するかは、運用負荷と再発防止を扱う判断である。
Stafford Beer の管理サイバネティクスは、この見方を支える。Beer は、組織を環境変化に適応し続ける自己制御システムとして捉えた（Beer, 1972; Beer, 1985）。Viable System Model は、組織が存続可能であるために必要な調整、制御、情報の流れを扱う枠組みである。ここでいう存続可能とは、環境変化の中でも目的を保ち、必要に応じて自分自身を変えられるという意味である。
ソフトウェアプロダクト、開発組織、運用体制は、いずれも目的を持つ社会技術システムとして捉えられる。社会技術システムとは、技術的な構成要素と人間・組織的な構成要素が結びついたシステムであり、この見方は社会技術システム工学とも接続する（Baxter & Sommerville, 2011）。プロダクトの信頼性は、コードだけでなく、監視、オンコール、リリース手順、障害対応訓練、意思決定権限によって左右される。開発速度は、フレームワークだけでなく、レビューの流れ、チーム間の依存、採用や育成によって左右される。
このため、技術的判断と組織的判断は分離しにくい。Conway は、システムを設計する組織のコミュニケーション構造が、そのシステム設計に反映されると論じた（Conway, 1968）。この観点から見ると、アーキテクチャ上の境界は、チーム間の境界と関係しやすい。権限管理は、セキュリティ設計であると同時に組織設計でもある。CI/CD の整備は、技術的な自動化であると同時に、リリース判断の制度化でもある。ソフトウェアエンジニアは、コードを書きながら、実際には組織の行動可能性も設計している。
一方で、ソフトウェアエンジニアリングには、通常の組織マネジメントとは異なる固有性がある。ソフトウェアでは、方針をコード、テスト、継続的インテグレーションと継続的デリバリー、Infrastructure as Code、Policy as Code などの実行可能な人工物へ変換できる。継続的インテグレーションと継続的デリバリーは、変更を継続的に統合し、検証し、リリース可能な状態へ近づける実践である。Infrastructure as Code はインフラ構成をコードとして管理する実践であり、AWS は、コードによってインフラの desired state を定義し、自動化や環境の複製を可能にするものとして説明している（Amazon Web Services, n.d.）。Policy as Code は一般に、ポリシーを機械で検証または適用可能な形で表現する実践である。たとえば Open Policy Agent は、ポリシーをコードとして指定し、Kubernetes、CI/CD pipeline、API gateway などに適用できる汎用ポリシーエンジンとして説明されている（Open Policy Agent, n.d.-a）。また、Open Policy Agent の公式文書は、継続的インテグレーションと継続的デリバリーのパイプラインで、設定の検証や組織ポリシーの適用を行う例も示している（Open Policy Agent, n.d.-b）。
これにより、少なくともインフラ構成やアクセス制御のように機械で扱える領域では、観測、検証、自動化、再現性を強く持たせられる。方針を口頭の努力目標に留めず、テストやパイプラインや権限設定として実装できる。もちろん、すべてを自動化すればよいわけではない。しかし、方針を実行可能な人工物へ変換できることは、ソフトウェアエンジニアリングの大きな特徴である。
この章の結論は、ソフトウェアエンジニアリングとマネジメントには同型性があるということである。どちらも、あるべき状態と現在状態の差分を扱い、制約を調整し、システムを導く活動である。ただし、ソフトウェアエンジニアリングは、その方針を実行可能な人工物へ落とし込める点で固有の力を持つ。この力は、次章で扱う組織や制度のソフトウェア的な性質を考えるうえで重要になる。
ここまで、ソフトウェアエンジニアリングを、システムをあるべき状態へ導く reconciliation loop として論じてきた。この見方は、コードやプロダクトだけでなく、組織や制度にも一定の範囲で広げられる。とくに、アクセス制御、デプロイ権限、CI/CD の検査、監査ログ、ポリシーエンジンのようにソフトウェアへ埋め込まれる制度は、人間の行動を制約する実行可能なルールとして振る舞う。
Lessig は、サイバースペースにおいてコードやアーキテクチャが行動を規制することを論じた（Lessig, 2000）。この指摘は、現在のソフトウェア組織にもよく当てはまる。たとえば、誰が本番環境にデプロイできるか、どのテストを通らなければマージできないか、どのログが保存され、どの監査証跡が残るかは、単なる技術設定ではない。それらは、組織が何を許し、何を防ぎ、どの行動を自然なものにするかを決める制度である。評価制度、承認フロー、職務分掌のような制度も同じ比喩で読める部分はあるが、人間の解釈、納得、権力関係に強く依存するため、コード化されたルールと同列には扱えない。
Infrastructure as Code や Policy as Code は、この境界をさらに曖昧にする。Infrastructure as Code は、インフラ構成をコードとして記述し、再現可能に管理する実践である（Amazon Web Services, n.d.）。Policy as Code は一般に、セキュリティ、コンプライアンス、運用ポリシーなどを機械で検証または適用可能な形で表現する実践である。たとえば Open Policy Agent は、ポリシーをコードとして指定できる汎用ポリシーエンジンであり、継続的インテグレーションと継続的デリバリーのパイプラインで設定の検証や組織ポリシーの適用に使えることを示している（Open Policy Agent, n.d.-a; Open Policy Agent, n.d.-b）。これらは、組織上の方針を実行可能な人工物へ変換する。言い換えれば、マネジメント上の判断がコードの形を取り、システムの振る舞いを直接制約する。
この見方には大きな利点がある。少なくともインフラ構成やアクセス制御のように機械で扱える領域では、制度を文章や会議体だけに閉じ込めず、観測、検証、自動化、再現性の対象にできるからである。たとえば、セキュリティ要件を口頭の注意喚起に留めるのではなく、権限設定、CI/CD の検査、依存ライブラリの監視、監査ログの保存として実装できる。組織のあるべき状態を、できるだけ実行可能な仕組みに落とすことで、reconciliation loop の観測性と再現性は高まる。
一方で、人間を含む制度は Kubernetes controller のように単純には reconcile できない。人間には解釈、納得、権力、感情、抵抗、学習がある。ルールを追加すれば、行動は変わる。しかし、その変化が望ましい方向とは限らない。評価制度を変えれば、指標は改善するかもしれないが、指標に合わせた局所最適が起きるかもしれない。承認フローを厳格にすれば、リスクは下がるかもしれないが、責任の所在が曖昧になり、誰も主体的に判断しなくなるかもしれない。
したがって、組織や制度をソフトウェア的に見ることは有効な比喩であるが、危険な比喩でもある。制度は人間の行動を制約するが、人間は制度を解釈し、迂回し、学習し、時には制度そのものを変える。制度設計にも reconciliation loop が必要である。制度を作り、現場での振る舞いを観測し、意図しない副作用を検出し、制度を更新する。制度を一度作って終わりにしないことが、組織を扱うソフトウェアエンジニアリングには欠かせない。
この章の結論は、制度をすべてコード化すべきだということではない。むしろ逆である。コード化できるもの、会話として残すべきもの、人間の裁量に委ねるべきものを見分けることが重要である。ここでも、方針決定は制約充足問題になる。自動化による再現性、現場判断の柔軟性、監査可能性、心理的安全性、開発速度、責任の明確さを同時に扱わなければならない。ここでいう心理的安全性とは、チームのメンバーが対人関係上のリスクを取っても安全だと共有して信じられる状態であり、懸念、失敗、疑問を表明できる条件でもある（Edmondson, 1999）。優れたソフトウェアエンジニアは、プロダクトだけでなく、組織や制度の制約も秤にかけながら、システム全体を導いている。次章では、このような判断能力をどのように育て、評価するべきかを扱う。
ここまでの議論では、ソフトウェアエンジニアリングにおける方針決定を、複数の制約を扱う経験的な制約充足として見てきた。その対象は、コードや設計だけでなく、プロダクト、組織、制度にも広がる。では、この判断能力は才能なのだろうか。それとも技能なのだろうか。
本稿の立場は明確である。個人差はある。しかし、これは才能だけで説明すべきものではなく、専門職技能として育成し、評価すべき能力である。なぜなら、優れた判断は、単なる直感や性格ではなく、状況の見方、制約の言語化、過去事例との照合、仮説の検証、結果からの学習によって成り立つからである。これらは教育可能であり、訓練可能であり、組織として支援できる。
ただし、この技能は見えにくい。コードの行数、実装速度、チケット消化数のような表面的な指標では捉えにくい。優れた判断は、派手な成果として現れるとは限らない。むしろ、障害を未然に防ぐ、依存関係を複雑にしない、将来の移行余地を残す、チームが理解できる設計に落とす、といった形で現れる。結果だけを見ると「何も起きなかった」に見えることがある。これは、レジリエンス工学でいう Safety-II の発想とも相性がよい。Safety-II は、失敗だけでなく、日々の変動の中で物事がうまくいく条件にも注目する安全観である（Hollnagel, 2014）。
専門家の判断が外から見えにくいことは、ソフトウェアに限らない。Klein は、消防、医療、軍事などの現場で、熟練者が限られた時間と情報のもとで意思決定する過程を研究し、自然主義的意思決定という領域を整理した（Klein, 1998）。自然主義的意思決定とは、統制された実験室ではなく、時間制約、不確実性、利害の大きさ、チーム内調整を含む現実の状況で、人がどのように判断するかを扱う研究領域である。熟練者は、すべての選択肢を表に並べて比較するとは限らない。状況を過去の経験と照合し、もっともらしい行動案を立て、その帰結を頭の中でシミュレーションし、破綻しなければ実行する。ソフトウェアエンジニアの設計判断にも、これに近い場面が多い。
このような技能は、経験年数だけで自動的に伸びるわけではない。Dreyfus と Dreyfus の技能獲得モデルは、学習者が規則に依存する初心者から、状況をより全体的に捉える熟練者へ進む過程を説明する（Dreyfus & Dreyfus, 1980）。初心者には明示的な手順やレビュー観点が必要である。一方、熟練者は、文脈、例外、関係者、将来の変化まで含めて判断する。しかし、熟練者の判断を「センスがある」で片づけてしまうと、初心者は何を学べばよいか分からない。教育上重要なのは、熟練者の暗黙知を、完全には形式化できないとしても、観察可能なふるまい、問い、比較軸、判断理由として外に出すことである。
Schön は、専門職の実践を「技術的合理性」だけでは説明できないと論じた。技術的合理性とは、あらかじめ定義された問題に対して、既存の理論や技法を適用すればよいと見る立場である。これに対して Schön は、専門家が実践の最中に状況を読み替え、試し、反省しながら問題を形成していくことを、reflection-in-action、すなわち行為の中の省察として説明した（Schön, 1983）。ソフトウェアエンジニアリングにおいても、よい判断は、仕様を受け取って実装する前に終わっているわけではない。実装し、レビューし、運用し、利用者の反応を見て、問題の定義そのものを更新する中で鍛えられる。
では、ジュニア・ミドルエンジニアはどうやってこの技能を身につけるべきか。第一に、制約を明示的に言語化する訓練が必要である。設計レビューや技術選定では、「なぜこの案か」だけでなく、「どの制約を重く見たか」「捨てた選択肢は何か」「将来どの条件が変わったら判断を見直すか」を書く。これは意思決定を正当化するためだけでなく、自分の判断を後から学習可能にするためである。
第二に、現実の仕事の中で、熟練者の判断過程を見えるようにする。Collins、Brown、Newman の cognitive apprenticeship は、認知的な技能を徒弟制のように学ぶ方法を提案する。そこでは、熟練者が考え方をモデルとして示し、学習者に足場かけを行い、徐々に支援を減らし、学習者自身に説明や反省を求める（Collins et al., 1989）。ソフトウェアエンジニアリングでいえば、設計レビュー、障害対応のふりかえり、リリース判断、技術的負債の棚卸しは、単なる会議ではなく認知的徒弟制の場にできる。
第三に、学習を実践共同体への参加として設計する。Lave と Wenger は、学習を知識の受け渡しだけではなく、実践共同体への正統的周辺参加として捉えた（Lave & Wenger, 1991）。正統的周辺参加とは、初心者が周辺的でリスクの小さい役割から始めつつ、共同体の実践に正当に参加し、徐々に中心的な役割を担うようになる過程である。ジュニアエンジニアに対して、最初から重大な判断を丸投げする必要はない。しかし、判断から遠ざけすぎても学習は起きない。小さな設計判断、レビューコメントへの応答、運用改善の提案、影響範囲の整理など、周辺的だが本物の判断に参加させることが重要である。
第四に、意図的練習を設計する。Ericsson らは、熟達には漫然とした経験ではなく、弱点に焦点を当て、フィードバックを受け、難度を調整しながら繰り返す deliberate practice が重要だと論じた（Ericsson et al., 1993）。ソフトウェアエンジニアリングでは、過去の障害報告を読んで代替判断を考える、設計案を複数作って制約ごとに比較する、既存コードの変更容易性を予測してから実際に変更してみる、といった練習が考えられる。ポイントは、失敗するまで本番を待たないことである。判断の筋力は、現実に近い素材を使いながら、被害の小さい場で鍛える必要がある。
評価についても、同じ発想が必要である。意思決定能力を評価するなら、結果だけを見るのでは不十分である。よい判断でも、環境変化によって結果が悪くなることはある。逆に、悪い判断でも、偶然に助けられて問題が表面化しないことがある。したがって評価では、少なくとも三つを見るべきである。第一に、判断前に制約と仮定を言語化できているか。第二に、実行中に観測し、必要に応じて方針を更新できているか。第三に、結果から学び、次の判断に反映できているか。
Miller の評価ピラミッドは、医療教育の文脈で、知っている、やり方を知っている、やってみせられる、実際に行う、という段階を区別した（Miller, 1990）。この枠組みは、エンジニアの判断能力にも応用できる。制約充足としての方針決定を評価するなら、知識テストだけでは足りない。設計課題で説明できるか、レビューや障害対応の場でやってみせられるか、実際のプロジェクトで継続的に行えるかを見る必要がある。
この評価は、個人を減点するための監視であってはならない。むしろ、組織がどのような判断を価値ある技能として扱うかを明確にするための仕組みである。ジュニアには、制約を列挙し、レビューを受けながら小さな判断を行う機会を与える。ミドルには、複数案の比較、関係者間の制約調整、判断の事後検証を求める。シニアには、判断の質だけでなく、判断過程を他者が学べる形にする責任を求める。これにより、見えにくかった意思決定は、育成と評価の対象として扱えるようになる。
AI 支援によって局所的な実装案を生成し、試すコストが下がるほど、この技能は重要になる。Peng らの実験は、限定された実装タスクでは AI 支援が完了時間を短縮しうることを示している（Peng et al., 2023）。一方で DORA 2024 は、AI 利用の効果が個人の生産性だけでなく、チームや組織のデリバリ性能との関係でも検討されるべきことを示している（DORA, 2024）。DORA 2025 は AI を組織能力の増幅要因として捉え、DORA の 2026 年記事は、AI による速度向上が検証負荷、レビュー負荷、スキル形成上の課題を伴いうると整理している（DORA, 2025; DORA, 2026）。なぜなら、AI は実装案を増やすが、組織の制約、暗黙のリスク、長期的な保守性、関係者の納得、将来の変更余地を総合して「今どの方針を採るべきか」を自動的に保証しないからである。これからのソフトウェアエンジニアに必要なのは、AI より速くコードを書くことだけではない。AI を含む新しい環境の中で、制約を見つけ、秤にかけ、判断を観測可能にし、学習可能にすることである。
本稿では、ソフトウェアエンジニアリングを、要求をコードへ翻訳するだけの活動ではなく、変化する環境の中でシステムをあるべき状態へ導き続ける活動として捉えてきた。その中心にあるのは、あるべき状態を暫定的に置き、現在状態を観測し、差分を解釈し、変更を加え、結果から学ぶ reconciliation loop である。
ただし、ここでいう「あるべき状態」は、最初から完全に与えられるものではない。実装、運用、利用者との対話、組織内の調整を通じて、何を目指すべきか自体が更新される。したがって、ソフトウェアエンジニアリングは、既知の正解へ直線的に進む作業ではなく、問題と解決案を同時に形成していく経験的な設計である。
その過程で行われる方針決定は、制約充足的な探索として理解できる。性能、信頼性、保守性、開発速度、セキュリティ、コスト、説明責任、組織能力などは、同時に満たすべき条件として現れる。しかし実務では、制約は曖昧で、途中で変わり、関係者によって重みづけも異なる。重要なのは、理想的な評価関数を最大化することではなく、現実の中で破綻しない実行可能解を見つけ、観測を通じて制約そのものを見直すことである。
この見方は、コードを書くことの価値を小さくするものではない。むしろ、コードを書くことをより大きな営みの中に位置づける。コードは方針を現実に作用させる媒体であり、テストは方針と実装のずれを観測する装置であり、運用はシステムと環境の関係を学ぶ場である。ソフトウェアエンジニアリングの固有性は、判断をコード、テスト、自動化、運用設計といった実行可能な人工物へ変換できる点にある。
したがって、本稿の中心命題は次のようにまとめられる。ソフトウェアエンジニアリングとは、システムを reconciliation loop により導き、その方針決定を制約充足的な探索として経験的に進めることである。
この命題は、エンジニアの育成と評価にも含意を持つ。実装案を生成し、試すコストが下がるほど、どの案を採るか、どの制約を優先するか、どのリスクを観測可能にしてから進むかという判断が重要になる。その判断能力は、個人の勘だけに委ねるものではない。制約、仮定、代替案、判断理由、事後の結果を言語化し、レビューやふりかえりを通じて学習可能にすることで、組織として育てられる専門職技能になる。
よいソフトウェアエンジニアリングとは、最初から正解を知っているかのように振る舞うことではない。変化する現実の中で、どこへ導くべきかを問い続け、観測から学び、必要に応じて方針を更新し、その判断過程を他者が参加できる形にすること。それが、本稿で述べてきたソフトウェアエンジニアリングの中心である。
アクセス日は、特に断りのない限り2026年6月6日である。ウェブ記事の公開日・更新日は、公開ページで確認できる範囲を記す。