番外編(おまけの Day 8)
Webアプリができるまで
7日間で学んだ言葉は、本物のソフトウェア開発でどこまで通用するのか。 番外編では、1本のWebアプリが設計から実装、検証、デプロイ準備まで作られていく様子を、 実際のセッション記録で見せます。 題材はこの教材の付属アプリ「ループ日誌」。 リプレイの中で作られているのは、いまあなたのブラウザで実際に動く本物です。
番外編のゴール
- 設計→実装→検証→デプロイ準備という開発の全体像を、1本通して見る
- 開発の記録の中に、7日間の概念(完了条件・観測・記憶・輪の上)を見つける
- 完成したアプリ「ループ日誌」を、自分の半自動ループの記録に使い始める
フェーズ1: 設計(発注から作らない決断まで)
開発は、コードを書くところからではなく、曖昧な発注を検証できる形に翻訳するところから始まります。 発注は1行。それがどう要件・担当範囲・完了条件に変換されるかを見てください。
注目してほしいのは「保存はブラウザ内だけ」「新しい道具は足さない」という作らない決断です。 機能を足すほど、Day4で見た事故の面積は広がります。 小さく作って確実に完了条件を満たすのは、ループの設計とまったく同じ原則です。
フェーズ2: 実装と検証(発見は観測から生まれる)
いよいよ実装です。ここで見てほしいのは、書く時間より確かめる時間の使い方です。 このフェーズでは、要件のどこにも書かれていなかった問題が1つ見つかります。
「件数の欄が前回の値のまま残る」という問題は、機能の一覧をいくら眺めても出てきません。 2件目を記録しようとした人の手の動きをなぞったときにだけ現れます。 Day1から言い続けてきた「観測」の価値が、開発ではここに出ます。 テストとは、決められた項目の消化ではなく、使う人の流れをなぞって世界の反応を確かめることです。
フェーズ3: デプロイ準備(最後のボタンは人間)
完成したアプリを世界に公開する仕組みがデプロイです。 このサイトの場合、記録簿(git)を配信サービスへ送り出せば、あとは自動で配られます。 では、その送り出しボタンは誰が押すのか。
開発の場面を、7日間の言葉に翻訳する
エンジニアの世界には専門用語がたくさんありますが、構造はこの7日間で学んだものと同じです。
| 開発の場面 | 7日間の言葉でいうと |
|---|---|
| 要件定義 | 完了条件を検証できる形に書くこと(Day4) |
| 設計 | 作業環境の整備。できることを増やし、同時に絞る(Day2) |
| テスト | 観測。使う人の流れをなぞって世界の反応を確かめる(Day1) |
| コードレビュー | 検証役。作った本人ではない目で点検する(Day3) |
| git(バージョン管理) | 記憶。会話の外に残る記録簿(Day3) |
| デプロイ | 公開という停止条件。最後の承認は輪の上の人間(Day4・5) |
逆もまた真です。あなたがDay7で書いたループ契約書は、エンジニアの世界では 要件定義書と運用設計書の親戚として、そのまま通じます。 7日間の言葉は、エンジニアと非エンジニアの共通語になりうる。それがこの番外編の結論です。
番外編のまとめ
- 開発は「曖昧な発注を検証できる完了条件に翻訳する」ところから始まる
- 要件に書かれていない問題は、使う人の流れをなぞる観測だけが見つける
- デプロイの仕組みは自動化できるが、公開の判断は輪の上の人間に残る
- 記憶は置くだけでは足りない。その場で、理由まで書いて初めて次に活きる
記録には、書くタイミングと理由が要る
「記憶」は部品として置くだけでは足りません。いつ・何を書くかで質が変わります。 記録は回したその場で書いてください。あとでまとめて思い出しながら書くと、うまくいった記憶ばかりが残り、 AIに渡す手順書も、その都合のよい過去から作られてしまいます。 そして、何が起きたかだけでなく、なぜそう判断したかを一言そえる。 「差し戻した」だけの記録は数えられても、「金額は合うが領収書の宛名が違うので差し戻した」は次の判断に効きます。理由のない記録は、次に活かせません。
おまけの課題
- ループ日誌を開いて、あなたの半自動ループの最初の1周を記録してください。 そのとき、処理した件数だけでなく、迷った案件をどう判断したか、その理由も一言そえてください。 リプレイで作られていた道具を、そのまま自分のループの「記憶」部品として使い始める。それがこの番外編の修了です。