---
title: ⑤個人開発で役立つシステム工学
tags:  #システム工学  
author: [Yukiko](https://www.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/47QYG549EP.jpg?width=480
description: ⑤個人開発で役立つシステム工学 by Yukiko
published: July 03, 26
canonical: https://www.docswell.com/s/yukiko_it/K4NNXL-2026-07-03-181822
---
# Page. 1

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

実践知識ダイジェスト ｜ SYSTEMS ENGINEERING FOR INDIE DEVS（Vol.3）
個人開発で役立つシステム工学
初心者〜中堅、レベル別 Why・What・How
なぜ大事か（Why）→ それは何か（What）→ どう使うか（How）。ひとりで作るときこそ効く、考え方のフレームワーク
要求と要件
スコープ管理
ADR(決定記録)
面白きこともなき世を面白く ── うさうさ研修工房
トレーサビリティ
2026


# Page. 2

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

ひとりで作るからこそ、要る視点がある
チーム開発の「お作法」に見えるシステム工学の考え方は、実は一人称の開発ほど効果を発揮します。レベル別に 4つ選びました
① 要求と要件を分ける
初心者
「なんとなく欲しい」を、作れる形の言葉に変換する
③ ADRで判断を残す
中堅
「なぜこの技術を選んだか」を1年後の自分に伝える
うさうさ研修工房 ｜ Systems Engineering for Indie Devs（システム工学最新動向 Vol.3）
② スコープを決める
初心者
「やること」と同じくらい「やらないこと」を先に決める
④ トレーサビリティ
中堅
要求→設計→実装→テストのつながりを見える化する
2


# Page. 3

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

初心者
① 要求と要件を分ける
「なんとなく欲しい」で作り始めると、完成の基準がなく終わらない
なぜ大事か
Why
「使いやすくしたい」のような要求のまま作ると、完成の判断基準が人によって
ブレる。手戻りの9割はここが原因。
要望
「使いやすくしたい」
↓
要求
何をするか
What
「要求」＝叶えたい思い・目的。「要件」＝検証可能な仕様。要求を、
YES/NOで
判定できる言葉に変換する作業。
「ログインを簡単にしたい」
↓
要件
どうやるか
How
「3タップ以内でログイン完了」
「〜したい」を書いたら、「それは何をもって完了？」を自問し、数値・条件・手順
に言い換えて記録する。
下にいくほど「具体的・検証可能」になる
出典: Beekle「要求とは？要件との違いを3軸で判別」／株式会社一創ほか要求工学の基本文献
うさうさ研修工房 ｜ Systems Engineering for Indie Devs（システム工学最新動向 Vol.3）
3


# Page. 4

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

初心者
② スコープを決める：「やらないこと」を先に書く
スコープクリープ＝「ちょっとだけ」の追加が積み重なり、いつまでも完成しなくなる現象
なぜ大事か
Why
今回やること（スコープ内）
「ついでにこれも」は善意から起きるため、自分ひとりでも歯止めが効きにく
い。積もると当初計画が別物になる。
ログイン機能
投稿の作成・編集
何をするか
What
一覧表示
どうやるか
やらないこと（次回以降）
コメント機能
多言語対応
着手前に「今回のリリースでやること」と「あえてやらないこと」を両方リストに
して書き出しておくこと。
How
思いついた追加案は消さずに「次回リスト」へ退避。今回の期限・完了条件
を先に決めてから着手する。
デザインテーマ切替
出典: Asana「スコープクリープとは？意味・7つの原因・対策」／note 五十嵐学「スコープクリープ対策5選」
うさうさ研修工房 ｜ Systems Engineering for Indie Devs（システム工学最新動向 Vol.3）
4


# Page. 5

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

中堅
③ ADRで「なぜ」を記録する
Architecture Decision Record：技術選定の理由を残す軽量ドキュメント（ Michael Nygard, 2011）
なぜ大事か
Why
ADR-001
半年後の自分は他人。「なぜこのDBを選んだか」を覚えていない。判断の記憶
が消える＝アーキテクチャ知識の蒸発。
DBにSQLiteを採用
承認済み
↓
What
何をするか
ADR-002
「タイトル／状況（Context）／決定（Decision）／結果（Consequences）」の4項目
だけの短いMarkdownメモ。
認証にJWTを採用
承認済み
↓
どうやるか
How
リポジトリに docs/adr/ フォルダを作り、連番ファイルで保存。大きな技術選定
のたびに1枚、数分で書く。
ADR-003
DBをPostgreSQLへ変更
ADR-001を置き換え
出典: Martin Fowler, bliki「Architecture Decision Record」／Michael Nygard, “Documenting Architecture Decisions”(2011)
うさうさ研修工房 ｜ Systems Engineering for Indie Devs（システム工学最新動向 Vol.3）
5


# Page. 6

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

中堅
④ トレーサビリティで変更に強くする
「この機能、何のために作ったんだっけ？」に即答できる状態をつくる
なぜ大事か
Why
→
→
機能が増えるほど「これ消していい？」の判断が難しくなる。つながりが見え
ないと不要な機能を残し続けてしまう。
→
要求
設計
実装
テスト
REQ-01
DES-01
commit a1b2
TEST-01
何をするか
What
「要求→設計→実装→テスト」を同じID・キーワードで結び付け、たどれる状
態にしておくこと。
矢印をたどれば「なぜこのコードがあるか」に必ず戻れる
個人開発の最小実践：コミットメッセージや Issue番号に「REQ-01」のようなIDを
一言添えるだけで OK
どうやるか
How
要求に REQ-01 のような番号を振り、対応するIssue・コミット・テストコードに
も同じ番号を書き添える。
出典: 要求工学における「トレーサビリティ」の基本概念（INCOSE要求管理ガイド等に基づく一般的知見）
うさうさ研修工房 ｜ Systems Engineering for Indie Devs（システム工学最新動向 Vol.3）
6


# Page. 7

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

まとめ：レベル別・実践チェックリスト
レベル
習慣
最初の一歩
初心者
要求→要件の言い換え
「〜したい」を書いたら「完了の条件」も1行添える
初心者
スコープの明文化
着手前に「やらないことリスト」を先に作る
中堅
ADRで判断を記録
技術選定のたびに4行（状況・決定・結果・状態）を書く
中堅
トレーサビリティ確保
コミットメッセージに要求IDを一言添える
要するに：システム工学の考え方は「チームのための厳格なルール」ではなく、「未来の自分に説明する手間を減らす」ための道具です。ひと
りだからこそ効きます。
うさうさ研修工房 ｜ Systems Engineering for Indie Devs（システム工学最新動向 Vol.3）
7


# Page. 8

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

参照文献（一次情報・実務知見ベース）
01
02
03
04
05
06
07
08
Beekle (2026).「要求とは？要件との違いを3軸で判別｜発注前に混同を防ぐチェックリスト」
Asana (2026).「スコープクリープとは？意味・7つの原因・対策を徹底解説」
note／五十嵐学 (2026).「スコープクリープ対策5選｜要件定義で『しないこと』を決める重要性」
Fowler, M. “bliki: Architecture Decision Record.” martinfowler.com
Nygard, M. (2011). “Documenting Architecture Decisions.”（ADRの原典）
株式会社一創 (2025).「エンジニアなら知っておきたいADR（アーキテクチャ決定記録）とは何か？」
Wantedly Engineering Handbook.「アーキテクチャディシジョンレコード(ADR)」
豆蔵デベロッパーサイト(2022).「アーキテクチャ・デシジョン・レコードの勧め」
本資料は上記の一次情報・実務知見に基づき作成。用語や手法の詳細は各出典を直接ご確認ください。