シェルパ・アンド・カンパニー株式会社でイネーブリングチームに所属する上野です。
フルスタックエンジニアで、クラウド・ネイティブな構成を積極的に採用しています。
要求分析には、ユースケース駆動開発を体系化したIvar Jacobsonの系譜（OOPSLAの Objectory / “Use-Case Driven”）を基盤に置き、実務レベルでの書き方や粒度調整は Alistair Cockburnに強く影響を受けています。
設計やリファクタリング、アーキテクチャ上の判断では、Martin Fowler（martinfowler.com）らの実践知やEric Evansのドメイン駆動設計（DDD）を参照しつつ、データモデルはEdgar F. Coddのリレーショナルモデルと正規化理論（BCNFなど）を基礎として、5NFにまで立脚して検討します。（ウィキペディア - 関係の正規化）
想定読者
本連載は、次のような方を主な対象として書いています。
- 要求や仕様を整理し、開発チームに伝える立場の方（PdM / PM / Biz / ドメインエキスパート）
- 要求を設計・モデル・アーキテクチャへ落とし込む立場の方（テックリード / アーキテクト / シニアエンジニア）
一方で、ソフトウェア開発の属人性や品質の揺れに課題を感じているエンジニア・マネージャーの方にも、問題の構造を捉えるための視点として役立つはずです。
前提
本連載で語るソフトウェア開発とは、主として長期運用（2年以上）・保守していくものを対象としています。研究開発領域で重要視されるPoCなどでは異なるアプローチが必要なので、企業がソフトウェアプロダクトを構築する際の一つの工学的アプローチとなります。
再現可能なアーキテクチャ入門：なぜ“工学”から始めるのか
ソフトウェア開発は、しばしば「個人のセンス」や「経験則」で語られがちです。
しかし、私は要求分析・設計・アーキテクチャ・データモデルに至るまで、一貫してソフトウェア工学に基づく再現可能な方法を好んでいます。
ソフトウェア工学とは、基礎科学に基づいて再現可能なソフトウェアの構造を探究し、構築し、維持・管理するプロセスです。これはまさに「工学」（エンジニアリング）という学問そのものと言えます。
このアプローチによって、属人性を最小化し、品質を最大化することができるからです。
この連載では、私が普段実践していること、例えば、
- 工学に基づく要求分析
- モデル駆動の設計
- アーキテクチャの整合性維持
- 述語論理に基づくリレーショナルモデル
といった話を、段階的に掘り下げていきたいと思っています。
ただし、これらすべてを一度にお伝えすることはできません。各テーマは非常に深く、一冊の分厚い書籍ができるほどの内容です。そのため、数回に分けてお届けします。
まずは第1回として、「再現可能なアーキテクチャとは何か」「なぜ工学が必要なのか」という導入部分から始めたいと思います。
1. “再現可能なアーキテクチャ”とは何か
ここで言う再現可能性（reproducibility）とは、ざっくり言えば次のような状態を指します。
誰がやっても、同じ前提と方法に従えば、同じ結論と設計に到達できる状態。 しかも、時間が経ってもそれが崩れにくい状態。
これは単なるスローガンではありません。再現可能性が高い開発は、次の性質を持っています。
- 決定理由が説明できる（Why が残る）
- 手順・ルールが明示されている（How が共有される）
- 仕様やモデルが一貫した原理に沿っている（What が変質しにくい）
逆に再現不能な状態は、次のような問題を引き起こします。
- 「”あの人” がいないと文章からも実装からも仕様が読み取れない」
- 「仕様の意図は口頭でしか存在しない」
- 「設計が途中でねじれて、誰も全体像を持てない」
- 「似た機能が増殖して、同じバグが形を変えて再発する」
これは“技術の問題”に見えますが、本質は工学（手続きを明文化し、検証可能な形で進む体系）を使っていないことによる問題だと考えています。
2. なぜ工学が必要なのか
多くのソフトウェア開発は、理想的な研究室や実験室ではなく「実験室の外」で起きます。現実の業務、現実の制約、現実の人間関係の中で進んでいくものです。そして、この現実は常に「ノイズ」として開発プロセスに混入してきます。
- 要求が曖昧
- 仕様が途中で変わる
- 言葉の定義を誤っている
- 関係者が増え、調整が複雑化する
- エンジニアの入れ替わりが起きる
- スケジュールが圧迫される
このようなノイズに対して、個人の能力や経験や勘だけに依存して対処するには限界があります。おそらく、あるべき姿を目指して努力し、苦い経験をしてきたシニア〜プリンシパルレベルのエンジニアほど、この無力感を痛感しているのではないでしょうか。
だからこそ、工学が必要になるのです。
工学とは、これらのノイズに振り回されず、壊れにくい開発の基盤を構築するための体系です。具体的には、
- 前提を定義する（定義）
- 手順を確立する（プロセス）
- 成果物を検証可能にする（検証）
- 知見を再利用可能な形で蓄積する（知識化）
という仕組みを提供します。
言い換えると、工学は、「組織で同じ品質を出し続けるための装置」だと言えるでしょう。
3. “センスの良い設計”がなぜ破綻するのか
よくある誤解に、次のようなものがあります。
- 優秀な人が設計すれば、自然と良いものになる
- ルールを決めなくても、人が賢ければ整合性は保たれる
- 「現場での柔軟な対応」の方が、ルールに縛られるより速い
短期的には、このアプローチが有効に見える場合もあるでしょう。しかし、中長期的な視点で見ると、この考え方に依存した多くのプロダクトが、やがて破綻していく現実があります。
理由は単純で、センスは共有できないからです。
- センスは言語化が難しい
- センスは人によって基準が異なる
- センスは大規模な開発では機能しない
- センスはその人とともに組織を去ってしまう
結果として属人性が高まり、プロダクトの保守性は低下し、寿命は縮んでいくのです。
一方、工学に基づいた設計は、
- 前提条件
- 判断基準
- 実施手順
- 機能仕様
- 概念モデル
これらを明確に言語化し、形式化して記録に残します。つまり、個人の「センス」に依存した設計を、再現可能な「手続き」に変換して組織の資産とすることが可能になるのです。
4. 再現可能性のための“最小セット”
ここから先の連載で細かく掘り下げていきますが、再現可能なアーキテクチャを実現するために、私が最低限必要だと考えている要素は次の4つです。
このうち一つでも欠けると、再現可能性は急速に損なわれてしまいます。
さらに重要なのは、これら全ての要素が工学的な裏付けを持ち、一次情報（原典や基本原理）に基づいて説明可能な状態にあるべきだということです。
中でも特に問題となりやすいのは、1. 用語と前提の定義と2. 要求の形式化が不十分なケースです。用語が曖昧なまま要求を解釈し、要求が曖昧なまま設計を始めてしまうと、その後の全ての工程が「推測ゲーム」と化してしまいます。
推測が増えれば増えるほど、再現性は低下し、属人性が高まり、システム全体が「雰囲気で作られた巨大な偶然の産物」になってしまう危険性があるのです。
5. じゃあ具体的に何が変わるのか？
再現可能性を意識して開発を行うチームでは、日々の業務に以下のような変化が現れます。
- 仕様の議論が「個人の好み」ではなく、「定義と原理」に基づいて行われる
- 設計レビューが 「感想」 ではなく、「前提との整合性」によって進められる
- データモデルが「現場の都合」ではなく、「意味論と制約」によって決定される
- 自由度はやや低下する代わりに、品質の下限が確実に向上する
- バグが「偶然の産物」ではなく、「検証可能な原因」として追及される
つまり、開発プロセス全体が、個人のカンや経験に依存した芸術的な作業から、「再現可能な実験」へとその性質を変えていくのです。
6. 次回予告：要求を“正しく読む”とはどういうことか
第1回となる今回は、再現可能なアーキテクチャを実現する上で、なぜ「工学」的アプローチが必要なのか、その基本理念についてご説明しました。
次回は、この考え方をさらに具体化し、開発プロセスの出発点である「要求」に焦点を当てます。以下のような問いを掘り下げていきます。
- 要求の読み違いは、なぜ繰り返し起こってしまうのか
- ユースケースとシナリオは、どのように区別し、使い分けるべきか
- 「完全形式」で要求を記述することに、どのような価値があるのか
- 要求定義の在り方が、その後の設計、モデリング、アーキテクチャにどう波及するのか
要求が常に変化し、揺れ動く現実の中で、いかにして「揺るがない設計」の礎を築くか。次回は、そのための「要求を読み解く技術」、すなわち“読み書きの工学”について詳しく解説します。
おわりに
ソフトウェアは本来「柔らかい」ものです。その柔軟性こそが強みである一方、放置すれば形は容易に崩れ、混沌へと向かいます。この本質的な柔らかさを支え、形を維持するためには、確固たる骨格＝工学的手続きが不可欠なのです。
再現可能なアーキテクチャとは、特定の個人のひらめきや能力に依存するものではありません。それは、平均的なスキルを持つメンバーが、標準的な手順を踏むことで、常に一定水準以上の品質を達成できる仕組みそのものなのです。
本連載は、この「仕組み」を一つひとつ解きほぐし、その構成要素を明らかにしていく試みです。引き続き、この重要なテーマについて掘り下げていきたいと思います。
参考（一次情報・基盤文献）
- Ivar Jacobsonらによるユースケース駆動開発の体系 (Use-Case Driven Approach / Objectory)
- Alistair Cockburn (2001)『ユースケース実践ガイド』
- Martin Fowlerによる設計・モデリング・リファクタリングの実践的知見
- 代表作：『UML Distilled』『Refactoring』
- martinfowler.com
- Edgar F. Codd(1970) 関係モデルの原典
- ボイス・コッド正規形 (BCNF)を含む関係の正規化理論
※一部は英語の一次文献ですが、GoogleのNotebookLMなどのツールを活用すれば、日本語による解説を得ながら、発案者の思想や原典に直接触れることも可能です。学問の基盤となる一次情報にぜひご自身でアクセスし、その本質を探求されることをお勧めします。
シェルパ・アンド・カンパニーでは一緒に働く仲間を募集しています。
