②個人開発×システム工学_違い編

研究に基づく AI活用シリーズ ｜ 別観点 個人開発の商用プロダクト × システム工学 ―違いを分けるアーキテクチャの現実 「一人で作ったツールが、なぜ育つほど重くなるのか」。 Harvard Business Schoolの実証研究とNASAシステム工学ハンドブックを手がかりに、 個人開発と組織的な工学的設計の「構造」の違いを読み解く。 うさうさ研修工房 ｜ うさうさ先生 出典：Harvard Business School / NASA Systems Engineering Handbook（詳細は巻末参照）

「動くコード」の裏で静かに増える設計上の負債 キーワード：テクニカル・デット（ technical debt）と「結合度（ coupling）」 テクニカル・デットとは何か Hierarchical（階層型） 依存関係が一方向に整理され、中心となる「循環参照の塊」が小さい。 変更の影響範囲が読みやすい。 「短期的に都合の良い設計判断」が、将来の保守・改修コストを増やす 現象。Harvard Business Schoolの研究では、この負債の大きな要因が 個々のコードの汚さではなく「システム構造（アーキテクチャ）」にあるこ とを実証している。 保守・改修コストはシステムの生涯コストの最大90%を占めるとされる （Brooks, 1975）。 個人開発の商用プロダクトも例外ではなく、「動けば良い」の積み重 ねが将来の身動きを取れなくする。 Core-Periphery（中心集中型） 多数のファイルが互いに依存し合う巨大な「コア」が存在。どこを触って も影響が広がりやすい。 出典：MacCormack, A. & Sturtevant, D. J. (2016). Technical Debt and System Architecture: The Impact of Coupling on Defect-Related Activity. Journal of Systems and Software, 120, 170–182. doi:10.1016/j.jss.2016.06.007 2

実証研究デザイン： 2つの実システムを比較 Harvard Business School（MacCormack & Sturtevant, 2016）｜ Design Structure Matrix分析 System H（階層型） System C（中心集中型） • ファイル数：20,270 • ファイル数：19,225 • コード行数：約 499万行 • コード行数：約 837万行 • コア規模：全体の 2.9% • コア規模：全体の 25.8% • 伝播コスト：2.2% • 伝播コスト：22.2% 両システムとも 10年以上運用された約 2万ファイル規模の実プロダクト。 3年間の不具合修正履歴（バグ追跡・バージョン管理ログ）を突合し、ファイル ごとの「結合度」と実際の保守コストの関係を統計的に検証した「マッチドペア」研究。 出典：MacCormack, A. & Sturtevant, D. J. (2016). Technical Debt and System Architecture: The Impact of Coupling on Defect-Related Activity. Journal of Systems and Software, 120, 170–182. doi:10.1016/j.jss.2016.06.007 3

結果①：不具合は「中心部」に集中する ファイル数の割合 vs 不具合修正作業（ Defect-Related Activity）の割合 System H（階層型）｜ Central分類 System C（中心集中型）｜ Core分類 System Cのファイルは、 System Hのファイルより不具合を経験する確率が約 3倍高い（16.9% 対 5.6%）。密結合のコアを持つ設計ほど、局所的な変更がシス テム全体に波及しやすい。 出典：MacCormack, A. & Sturtevant, D. J. (2016). Technical Debt and System Architecture: The Impact of Coupling on Defect-Related Activity. Journal of Systems and Software, 120, 170–182. doi:10.1016/j.jss.2016.06.007 4

結果②：構造の違いが年間保守コストを左右する コード 1行あたりの年間保守コスト（ Cost per LOC per Year） 中心部 vs 周辺部の格差はさらに大きい • System H：Central分類のコードは、Peripheral分類より15倍以上 のコストがかかる（$0.86 対 $0.05 / 行・年）。 • System C：Core分類のコードは、Peripheral分類の約3倍のコスト （$2.31 対 $0.71 / 行・年）。 つまり「どこに機能を置くか」の設計判断が、将来の保守費用を桁 違いに左右する。 → 中心集中型は階層型の約 3倍のコスト 出典：MacCormack, A. & Sturtevant, D. J. (2016). Technical Debt and System Architecture: The Impact of Coupling on Defect-Related Activity. Journal of Systems and Software, 120, 170–182. doi:10.1016/j.jss.2016.06.007 5

なぜ「一人」だと密結合になりやすいのか 組織構造とソフトウェア構造は「鏡写し」になる ―― ミラーリング仮説 MacCormack, Baldwin & Rusnak（2012, Research Policy）は、同機能・同規模のソフトウェアでも「開発した組織形態」によってアーキテクチャが変わる こ とを示した。疎結合なオープンソース・コミュニティは高いモジュール性を持つ一方、単独チーム（同一拠点の商用開発）で作られたシステムは密結合 になりやすい。個人開発はこの「単独チーム」の極限形であり、レビューや役割分担という外部制約が働きにくい。 「意図しなくても、制約がなければ開発者は密結合で保守困難な設計を作りがちだ」 ――同研究が示す一貫した知見。個人開発ほど、この傾向に無 自覚になりやすい。 出典：MacCormack, A., Baldwin, C., & Rusnak, J. (2012). Exploring the Duality between Product and Organizational Architectures: A Test of the ‘Mirroring’ Hypothesis. Research Policy, 41(8), 1309–1324. 6

システム工学が課す「外部制約」という処方箋 NASAシステム工学ハンドブック（NASA/SP-2016-6105 Rev 2）が定める規律 階層的な要求分解 システム全体を機能ごとに階層分割し、依存の方向をあ らかじめ設計する（PBS：Product Breakdown Structure）。 リスク管理プロセス 「リスク・トリプレット」など体系的な手法でリスクを識別・ 評価し、継続的に監視する。 技術ベースラインの管理 設計が確定するたびに「ベースライン」として凍結し、変 更管理プロセスを通してのみ更新する。 ソフトウェアピアレビュー 要求・設計・コード・試験手順を、利害関係のない同僚が レビューし、個人の知識への依存を減らす（SWE-087）。 段階的な技術レビュー SRR・PDR・CDRなど、節目ごとに第三者が設計を評価す るマイルストーンレビューを課す。 構成管理（CM） 誰が・いつ・何を変更したかを追跡し、変更の影響範囲を 常に可視化する。 出典：NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2. NASA Office of the Chief Engineer, 2016. ／ NASA Software Engineering Handbook (SWEHB), SWE-087: Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures. NASA Office of the Chief Engineer. 7

個人開発とシステム工学：判断基準の違い どちらが正しいかではなく、「今どちらの制約下にいるか」を自覚することが重要 観点 個人開発（商用プロダクト） システム工学（NASA型） 意思決定の速さ 即断即決、その場で設計変更 レビュー・承認ゲートを経て変更 初期の生産性 非常に高い（数週間でMVP） 立ち上げに時間がかかる 生まれやすい構造 Core-Periphery型（密結合）になりがち Hierarchical型（疎結合）に近づけやすい 外部制約 ほぼなし（自己規律のみ） ピアレビュー・CM・マイルストーン 長期保守コスト スケールすると急増しやすい 初期投資は重いが増加が緩やか 適する場面 検証段階・小規模ツール・単独運用 長期運用・高信頼性・複数人開発 出典：MacCormack, A. & Sturtevant, D. J. (2016). Technical Debt and System Architecture: The Impact of Coupling on Defect-Related Activity. Journal of Systems and Software, 120, 170–182. doi:10.1016/j.jss.2016.06.007 ／ MacCormack, A., Baldwin, C., & Rusnak, J. (2012). Exploring the Duality between Product and Organizational Architectures: A Test of the ‘Mirroring’ Hypothesis. Research Policy, 41(8), 1309–1324. ／ NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2. NASA Office of the Chief Engineer, 2016. 8

個人開発者が今日から使える軽量プラクティス システム工学の「本気の型」を、一人開発向けに縮小適用する コア機能を早めに「隔離」する 全体から呼ばれる中心機能ほど改修コストが跳ね上がる。頻繁に触る核となる ロジックは、早い段階で薄いインターフェースの奥に切り出す。 変更履歴を追跡可能にする コミットメッセージに「なぜ」を残す、バージョンごとに変更点を記録するなど、簡易 的な構成管理を習慣化する。 自分用の「簡易マイルストーン」 正式なレビューがなくても、機能追加前に「この変更はどこまで影響するか」を一 言メモに残すだけで、密結合化のブレーキになる。 「動けば良い」を期限つきにする 速度優先の判断（技術的負債）は悪ではないが、放置すると複利で効いてくる。 次のリファクタリング時期をあらかじめ決めておく。 出典：MacCormack, A. & Sturtevant, D. J. (2016). Technical Debt and System Architecture: The Impact of Coupling on Defect-Related Activity. Journal of Systems and Software, 120, 170–182. doi:10.1016/j.jss.2016.06.007 ／ MacCormack, A., Baldwin, C., & Rusnak, J. (2012). Exploring the Duality between Product and Organizational Architectures: A Test of the ‘Mirroring’ Hypothesis. Research Policy, 41(8), 1309–1324. ／ NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2. NASA Office of the Chief Engineer, 2016. 9

参照文献（ References） Harvard Business School MacCormack, A. & Sturtevant, D. J. (2016). Technical Debt and System Architecture: The Impact of Coupling on Defect-Related Activity. Journal of Systems and Software, 120, 170–182. doi:10.1016/j.jss.2016.06.007 MacCormack, A., Baldwin, C., & Rusnak, J. (2012). Exploring the Duality between Product and Organizational Architectures: A Test of the ‘Mirroring’ Hypothesis. Research Policy, 41(8), 1309–1324. NASA NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2. NASA Office of the Chief Engineer, 2016. NASA Software Engineering Handbook (SWEHB), SWE-087: Software Peer Reviews and Inspections for Requirements, Plans, Design, Code, and Test Procedures. NASA Office of the Chief Engineer. 本資料の統計値・引用はすべて上記一次資料に基づく。数値の再利用時は出典明記のうえご活用ください。 うさうさ研修工房 10