実装スプリント1〜最初の機能を動かす

• 日程: Day 11 / セッション 2
• 時間: [10:00-12:20]（途中休憩11:00-11:10を含む）
• 形式: 実習
• ゴール: かんばんのタスクに従い、最初の機能（画面表示・データ登録等）を1つ以上動作させられる
• 学習形式: ハンズオン実習（AIペアプログラミング）

いよいよ最初のコードを書きます。今日のテーマは「小さく作って小さく動かす」です。

ここで考えてみてください。2時間後に「全機能の半分が書きかけ」の状態と、「機能1つだけ完全に動く」状態、どちらが良いでしょうか？

正解は後者です。書きかけのコードは動くかどうか分かりません。動く機能が1つあれば、それは確かな前進です。動いた1つ目は、2つ目以降の「型」にもなります。

雪だるま作りと同じです。最初に小さくても固い芯を作れば、あとは転がすだけで大きくなります。芯がゆるいと、大きくする途中で崩れます。

かんばんのTodoから、最初に着手するタスクを選びます。選び方の基準はこれです。

小さくて、他のタスクの土台になり、動いたことが目で確認できるもの。

たとえば「会員情報の一覧を画面に表示する」は良い最初のタスクです。画面・処理・データが一直線につながり、動けば目に見えるからです。一方「全画面の共通デザインを完成させる」は最初のタスクには向きません。どれだけ進んだか確認しにくく、機能が1つも動かないまま時間が溶けるからです。

「画面→処理→データ」を細い一本道でいいから貫通させる。これを薄い縦切り（垂直スライス）と呼びます。

• 最初の1時間で「何か1つが動く」状態を目指す
• データは本物でなくてよい。手で入れた仮データ1件で十分
• 着手したタスクはかんばんでDoingに動かしてから始める

「とにかくまず動く最小限を作る」という考え方は、ビジネスの世界ではMVP（Minimum Viable Product）と呼ばれます。有名なたとえに「車を作るとき、最初にタイヤだけ納品してはいけない。最初にスケートボードを納品せよ」というものがあります。タイヤ単体では誰も移動できませんが、スケートボードなら不格好でも「移動できる」という価値が最初から検証できるからです。皆さんの最初の機能も、立派なスケートボードを目指しましょう。

前のセッションで学んだ進め方を、実際の作業手順に落とします。どの言語・フレームワークでも手順は同じです。

1. 設計書を開く（画面仕様書・機能設計書・テーブル定義書の該当箇所）
2. AIに方針を相談する（コードを書く前に手順を言葉で固める）
3. 小さく書く（数行〜数十行）
4. すぐ動かす（書いたら即実行。まとめて実行しない）
5. エラーが出たら全文をAIに貼る
6. 動いたら、自分の言葉で説明できるか確認する
7. かんばんを更新して次へ

AIへの相談例です。自チームの言語・ツール名に置き換えて使ってください。

方針相談（書く前）

これから「○○の一覧を画面に表示する機能」を作ります。
使う技術: [チームで選んだ言語・ツール]
設計書の該当部分: [画面仕様書・テーブル定義の該当箇所を貼る]
まずコードを書かずに、実装手順を3〜5ステップで一緒に整理してください。
各ステップで「動作確認できること」も教えてください。

最初の一歩が分からないとき

[ツール名]で開発を始めたいのですが、最初に何を準備すればよいか分かりません。
「画面に固定の文字を1行表示する」最小の状態を作る手順を、
1つずつ確認しながら教えてください。1ステップずつ進めます。

エラーが出たとき（全文を貼る）

実行したら次のエラーが出ました。全文を貼ります。
[エラーメッセージ全文]
直前にやったこと: [例: ○○の行を追加して実行した]
該当するコード: [コードを貼る]
エラーの意味を先に説明してから、確認すべき箇所を教えてください。

エラーは出ないが期待と違うとき

エラーは出ませんが、期待した動きになりません。
期待: 一覧に3件表示される
実際: 1件も表示されない
コード: [貼る]
原因の切り分け方を、確認手順として教えてください。

• 「書く→動かす」のサイクルを数分単位で回す。30分動かしていなかったら危険信号
• AIの提案を採用する前に「この行は何をしている？」と必ず確認する
• 同じエラーで15分悩んだら、チームメンバーに声をかける。抱え込みは禁止

世界初のコンピュータ「バグ」は、1947年にハーバード大学の計算機から見つかった本物の蛾だと言われています。リレー（継電器）に蛾が挟まって誤動作し、技術者がその蛾をテープで作業日誌に貼り付けて「First actual case of bug being found（本物のバグが見つかった最初の事例）」と記録しました。この日誌は今もスミソニアン博物館に保存されています。つまりエラーの記録を丁寧に残す文化は、コンピュータ史の最初からあったのです。皆さんがエラー全文をAIに貼るのも、この伝統の正統な続きです。

実装を始める前に、不安な点をAIに相談しておきましょう。たとえば：

• 「[ツール名]で最小の動くものを作る手順を、初心者向けに教えて」
• 「垂直スライスでの実装って具体的にどう進めるの？　うちのテーマは○○です」
• 「動作確認って何をどこまで確認すればいいの？」

かんばんのタスクに従い、最初の機能を1つ以上動かしてください。

1. チームで「最初に動かす機能」を1つ決める（5分）

   • 画面表示・データ登録など、小さくて土台になるもの
   • 担当をかんばんに明記し、Doingへ動かす
2. 設計書の該当箇所を確認する（5分）

   • 画面仕様書・機能設計書・テーブル定義書のどこに対応するか、声に出して確認
3. AIと方針を固めてから実装する（〜90分）

   • 上の相談例を使い、手順を固める → 小さく書く → すぐ動かす
   • エラーは全文をAIに貼って相談する
   • 動いたらチームメンバーに見せて、次のタスクへ
4. 終了10分前に動作確認とかんばん整理（10分）

   • 動いた機能をチーム全員で1回操作する
   • Doingに残っている作業の状態をメモし、終会に備える

• 動作する最初の機能（1つ以上）
• 実態に合ったかんばん（Done/Doingの更新）

• 何から書けばいいか分からない → AIに「最小の動く状態を作る手順を1ステップずつ」と頼む。一気に全部聞かない
• エラーが出たら → 「[エラー全文]というエラーが出た。直前に○○をした」とAIに伝えると解決策を教えてもらえます
• データベースにつなぐ部分で詰まったら → 先に仮データ（固定値）で画面まで貫通させ、接続は次のタスクに分ける
• AIが長大なコードを出してきたら → 「もっと小さい単位に分けて。まず最初の1ステップだけ」と頼み直す
• チームで同じ箇所を同時に編集しない → 朝決めた分担を守る。重なりそうなら先に声をかける

今回学んだことを一言でまとめると「小さく作って小さく動かせば、最初の機能は必ず動く」です。

• 最初のタスクは「薄く貫通する」一本を選ぶ
• 書く→動かすを数分単位で回す
• エラーは全文をAIに貼る。15分悩んだらチームに相談

次のセッションは終会です。今日の進捗と「困っていること」をチームに持ち寄ります。

以下の問いに答えられるか確認してみましょう：

• 最初に着手するタスクの選び方の基準は何でしたか？
• エラーが出たとき、AIに何をどう伝えますか？
• 今日動かした機能は、設計書のどの部分に対応していますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: 自チームの外部設計書・内部設計書・かんばん
• 発展課題: 今日動かした機能について、AIに「このコードの改善点を初心者向けに1つだけ教えて」と聞いてみる

このセクションは、受講者が理解を深めることをサポートする参考情報です。