---
title: ②個人開発×システム工学_違い編
tags:  #システム工学  
author: [Yukiko](https://www.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/L73W6R8D75.jpg?width=480
description: ②個人開発×システム工学_違い編 by Yukiko
published: July 03, 26
canonical: https://www.docswell.com/s/yukiko_it/ZQ22VX-2026-07-03-181504
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/L73W6R8D75.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/87DKVYM2JG.jpg)

「動くコード」の裏で静かに増える設計上の負債
キーワード：テクニカル・デット（ 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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VJPKV6RLE8.jpg)

実証研究デザイン： 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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/2EVVZ3R6EQ.jpg)

結果①：不具合は「中心部」に集中する
ファイル数の割合 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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/57GL43M2EL.jpg)

結果②：構造の違いが年間保守コストを左右する
コード 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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4EQYG5R9JP.jpg)

なぜ「一人」だと密結合になりやすいのか
組織構造とソフトウェア構造は「鏡写し」になる ―― ミラーリング仮説
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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/KJ4W59QR71.jpg)

システム工学が課す「外部制約」という処方箋
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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LE1YWKPV7G.jpg)

個人開発とシステム工学：判断基準の違い
どちらが正しいかではなく、「今どちらの制約下にいるか」を自覚することが重要
観点
個人開発（商用プロダクト）
システム工学（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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GEWG6D23J2.jpg)

個人開発者が今日から使える軽量プラクティス
システム工学の「本気の型」を、一人開発向けに縮小適用する
コア機能を早めに「隔離」する
全体から呼ばれる中心機能ほど改修コストが跳ね上がる。頻繁に触る核となる
ロジックは、早い段階で薄いインターフェースの奥に切り出す。
変更履歴を追跡可能にする
コミットメッセージに「なぜ」を残す、バージョンごとに変更点を記録するなど、簡易
的な構成管理を習慣化する。
自分用の「簡易マイルストーン」
正式なレビューがなくても、機能追加前に「この変更はどこまで影響するか」を一
言メモに残すだけで、密結合化のブレーキになる。
「動けば良い」を期限つきにする
速度優先の判断（技術的負債）は悪ではないが、放置すると複利で効いてくる。
次のリファクタリング時期をあらかじめ決めておく。
出典：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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/47ZLYGDGJ3.jpg)

参照文献（ 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