開発テーマの実装仕上げ

• 日程: Day 4 / セッション 4
• 時間: [13:00-14:00]
• 形式: 実習
• ゴール: 開発テーマに沿って機能を拡張し、主要ユースケース1本（一覧→詳細→登録 等）を通しで動作させられる。ソースコード一式を Git でコミットし GitHub のリポジトリへ push できる
• 学習形式: ハンズオン実習（AIペアプログラミング）

午前中に「一覧表示」と「登録」が動きました。部品は揃っています。ここからは仕上げです。

ここで少し考えてみてください。仕上げと聞くと「機能を増やすこと」を想像しがちですが、今日の合格基準は違います。ユースケース1本が通しで動くこと、そして分離が保たれていること。機能が10個あって分離が崩れたコードより、機能3個で分離が美しいコードのほうが、この研修では高評価です。

なぜか。分離が保たれたコードは、明日からいくらでも機能を足せるからです。崩れたコードは、足すたびに壊れます。完成度より分離の維持。この1時間の合言葉です。

拡張の鉄則は「一度に1つだけ変えて、すぐ確かめる」です。PDCA を小さく速く回します。

• Plan: 追加する機能を1つだけ選ぶ（例: 詳細表示）
• Do: 最小の変更で実装する（api.js に1関数、app.js に1関数）
• Check: ブラウザで動作確認。壊れていたら直前の変更だけを疑う
• Act: 動いたらコミット。次の1つへ

これは料理に似ています。味見をせずに調味料を5種類入れると、まずくなったとき何が原因かわかりません。1つ入れては味見。これが一番速い。

逆のアンチパターンは「全部書いてから最後にまとめて動かす」です。エラーが5個重なると、切り分けに実装の何倍も時間がかかります。動かない時間が長いほど、心も折れます。

拡張メニューの例です（家計簿システム）。上から順に難易度が上がります。

JSON Server はクエリパラメータでの絞り込みを最初からサポートしています。

curl "http://localhost:3000/expenses?categoryId=1"

• 「一覧→詳細→登録」のようなユースケース1本の流れを、ペルソナになりきって最初から最後まで操作してみる。途中で途切れたらそこが今日の残作業
• 詰まったら15分ルール。15分自力で進まなければ、状況とコードを AI に貼って相談する

「動くソフトウェアこそが進捗の主要な尺度である」。これはアジャイルソフトウェア開発宣言（2001年）の背後にある12原則の一つです。17人の技術者がユタ州のスキーリゾートに集まって書いたこの宣言は、たった4つの価値と12の原則しかありません。分厚い進捗報告書より、動くデモ。今日のあなたの進捗管理も「今、動くか？」の一点です。

拡張のたびに、この4つを自分に問います。

1. この情報は情報定義書（Day 1）にあるか？　なければ先に定義書へ追加する
2. この API は設計書（Day 3）にあるか？　なければ先に設計書へ1行足す
3. URL や HTTP の知識が app.js に漏れていないか？（通信は api.js だけ）
4. 業務ルール（判定・計算）が UI に漏れていないか？

3と4が「プレゼンテーションと機能の分離」、1と2が「情報の設計とシステムの設計の分離」に対応します。つまりこのチェックリストは、研修全体の2大テーマをコードの上で守る仕組みです。

ここで少し考えてみてください。「予算を超えたら金額を赤字で表示する」を実装するとき、どこに何を書くべきでしょうか？

• 「予算を超えたか」の判定 → 機能側の関心事。本来は API が返すべき情報（モックなら db.json の budgets と突き合わせる関数を api.js 側に寄せる）
• 「赤字で表示する」 → プレゼンテーションの関心事。app.js（またはCSS）の仕事

一つの要求文の中に、機能とプレゼンテーションが同居している。これを切り分けられれば、この研修の到達目標 No.4 と No.5 は合格です。

• 迷ったら「この処理は、UI をスマホアプリに置き換えても必要か？」と問う。必要なら機能側、不要ならプレゼンテーション側
• 分離チェックは実装後ではなく、書く直前に行うと手戻りがない

「技術的負債」という言葉は、Wiki の発明者ウォード・カニンガムが1992年に作った金融メタファーです。「急いで書いた雑なコードは借金と同じ。返済（書き直し）しない限り利子（余計な作業時間）を払い続ける」。彼は借金自体を悪とは言っていません。事業を加速する借金もある、ただし利子は必ず取られると自覚せよ、と。今日あなたが「とりあえず app.js に書いちゃえ」と思った瞬間が、まさに借入の瞬間です。

成果物の提出先は GitHub です。バージョン管理は Day 3 で学んだとおり、開発手法を支える土台でもあります。

# 0. 事前準備（初回のみ）: GitHub でアカウントを作り、空のリポジトリ kakeibo を作成しておく

# 1. プロジェクトのルートで Git リポジトリを初期化する
cd kakeibo
git init

# 2. 除外設定を作る（node_modules 等を追跡しない）
echo "node_modules/" > .gitignore

# 3. 変更をステージしてコミットする
git add .
git commit -m "家計簿システム: モックAPIとUI一式（一覧・登録・詳細）"

# 4. GitHub のリポジトリを接続先として登録し push する
git remote add origin https://github.com/あなたのID/kakeibo.git
git branch -M main
git push -u origin main

push が成功したら、ブラウザで自分のリポジトリを開き、api/db.json と ui/ が見えることを確認します。README.md に「情報の設計（db.json）」「プレゼンテーション（ui/）」の構成説明を3行書いておくと、発表資料の素材にもなります。

• コミットは PDCA の Act のたびに小さく行う。「動いたらコミット」を習慣にすると、壊れても直前に戻れる
• 認証エラー（push 時のパスワード拒否）が出たら、GitHub は現在パスワードでの push を廃止している。Personal Access Token か SSH 鍵の設定を AI に手順を聞きながら行う

GitHub のマスコット「Octocat（オクトキャット）」は、猫の頭にタコの足を持つ謎の生き物です。原案はデザイナーのサイモン・オクスリーがストックイラストとして描いた1枚で、GitHub 創業者が数十ドルで購入しました。実は Twitter の青い鳥も同じ人のストックイラスト出身。世界的ロゴ2つを生んだ彼は、当時それを知らなかったそうです。ちなみに Git 自体は、リーナス・トーバルズが既存ツールへの不満から約2週間で原型を書き上げたもの。「git」は英国俗語で「嫌なやつ」の意で、リーナスは「自分にちなんで名付けた」とジョークを飛ばしています。

• 「私のユースケース『一覧→詳細→登録』のうち詳細表示が未実装。今の api.js と app.js（貼り付ける）に最小の変更で足す差分を提案して。ただし通信は api.js、描画は app.js の分離は崩さないで」
• 「git push で認証エラーが出た（エラー全文を貼る）。Personal Access Token での解決手順を順番に教えて」
• 「『予算超過なら赤字表示』を実装したい。機能とプレゼンテーションのどちらに何を書くべきか、私の構成を前提に議論して」

1. ユースケースを1本通す（25分）

   • 「一覧→詳細→登録」など、ペルソナの主要ユースケースを1本選ぶ
   • 足りない機能を PDCA 1周＝機能1つで追加する（動いたらコミット）
   • 最後に通しで操作し、途切れないことを確認する
2. 分離チェック（5分）

   • 本編のチェックリスト4項目を自分のコードに適用し、違反があれば直すか、直さない理由をメモする
3. GitHub へ push する（10分）

   • git init から push までを実行し、ブラウザでリポジトリを確認する
   • README.md に構成説明を3行以上書く

• 主要ユースケース1本が通しで動くソースコード一式（GitHub 上で閲覧できる状態）
• コミット履歴（小さなコミット3つ以上が望ましい）
• 分離チェックのメモ

• 時間が足りないと感じたら、拡張メニューの上（簡単なもの）から選ぶ。詳細表示は一覧の流用で作れる
• AI にコードを書いてもらったときこそ、貼り付ける前に分離チェックリストを通す。AI は速いが、あなたの構成の番人はあなた
• コミットメッセージは「何をしたか」を日本語で一言。未来の自分への伝言

今回学んだことを一言でまとめると「小さく変えて、確かめて、コミットする。分離を守ったまま積み上げれば、ソフトウェアは壊れずに育つ」です。

• PDCA を機能1つ単位で回し、動く状態を保った
• 分離チェックリストで2大テーマをコードの上で守った
• 成果は GitHub に push し、提出できる形になった

次のセッションでは、この成果を発表資料にまとめ、AI を聴衆にしてデモ付きで発表します。4日間の学びを言葉にする時間です。

• 「完成度より分離の維持」の理由を一文で言えますか？
• 分離チェックリストの4項目を、見ずに3つ以上挙げられますか？
• git init から push までのコマンドを順番に言えますか？

• 参考リンク: GitHub Docs「リポジトリの作成」「リモートリポジトリについて」、Pro Git（無料公開書籍）第1〜2章
• 発展課題: WIP PR の練習として、次に作りたい機能をブランチ（git switch -c feature/削除機能）で作り始め、GitHub 上で Pull Request を下書き（Draft）で開いてみる