⑤個人開発で役立つシステム工学

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

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

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

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

中堅 ③ 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

中堅 ④ トレーサビリティで変更に強くする 「この機能、何のために作ったんだっけ？」に即答できる状態をつくる なぜ大事か 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

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

参照文献（一次情報・実務知見ベース） 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).「アーキテクチャ・デシジョン・レコードの勧め」 本資料は上記の一次情報・実務知見に基づき作成。用語や手法の詳細は各出典を直接ご確認ください。