実装の進め方〜設計書ドリブン開発とAIペアプログラミング

• 日程: Day 11 / セッション 1
• 時間: [9:30-10:00]
• 形式: 座学
• ゴール: 実装期間の日々の進め方（朝会10分→実装→終会20分）と、設計書に基づいた実装・AIペアプログラミングの進め方を説明できる
• 学習形式: 対話型解説、デモンストレーション

ついに実装フェーズが始まります。Day 10で作ったプロトタイプは「見た目の紙芝居」でした。今日からの7日間（Day 11-17）で、それを「本当に動く製品」に育てます。

ここで少し考えてみてください。設計書を9日間かけて作りましたが、実装が始まったら設計書はもう用済みでしょうか？

答えはノーです。むしろ逆で、実装期間こそ設計書が主役になります。設計書は地図、実装は実際の旅です。地図を見ずに歩き出すと、必ず迷子になります。

このセッションでは、実装期間を乗り切るための3つの約束ごとを学びます。

1. 日々のリズム（朝会→実装→終会）
2. 設計書ドリブン開発（設計書とコードを一致させ続ける）
3. AIペアプログラミング（AIに書かせるのではなく、AIと書く）

実装期間の毎日は、同じリズムで進みます。

• 朝会（10分）: かんばんを見ながら「今日やること」を1人1分で共有する
• 実装（2時間30分）: かんばんのタスクに従って作業する（途中休憩あり）
• 終会（20分）: 進捗・課題を報告し、かんばんをTodo/Doing/Doneの実態に合わせて更新する

これはマラソンの給水所のようなものです。走りっぱなしでは、ペースが乱れても気づけません。朝会と終会という「定点」があるから、ずれを毎日小さいうちに直せます。まさにPDCAを小さく沢山繰り返す、です。

朝会で共有するのは次の3点だけです。

• 昨日やったこと
• 今日やること
• 困っていること

「今日は頑張ります」は共有として成立しません。かんばんのどのタスクをやるのか、具体的に言えることが大事です。「会員登録画面の入力チェックを実装してDoneにします」なら、夕方に達成できたか誰でも判定できます。

• 朝会・終会は時間厳守。10分・20分を超えたら司会が打ち切る
• 「困っていること」を言うのは弱さではなくチームへの貢献。早く言うほど傷が浅い
• かんばんが実態とずれたまま放置されるのが一番危険。終会で必ず合わせる

朝会の原型はアジャイル開発の「デイリースクラム」です。スクラムという名前はラグビーのスクラムが由来で、「チーム全員で肩を組んで一歩ずつ前進する」イメージから名付けられました。海外では立ったまま行う「スタンドアップミーティング」と呼ばれます。なぜ立つのか？　座ると会議が長引くからです。「足が疲れてきたら会議が長すぎるサイン」という、人間の弱さを逆手に取った仕組みです。

実装期間の鉄則はこれです。

設計書とコードがずれたら、設計書を直す。

実装を進めると、必ず設計の不備に気づきます。「この画面、入力項目が足りない」「このテーブルにカラムを追加したい」。これは設計が下手だったのではなく、実装してみて初めて分かることがあるという自然な現象です。

問題は、そのときの行動です。

• コードだけ直して設計書を放置する → 設計書が「うそつき」になり、誰も信用しなくなります。これは悪い例です
• チームに報告して合意し、設計書を直してからコードを直す → 設計書が常に「正」であり続けます。これが正しい姿です

Day 1で決めたルールを思い出してください。「合意した内容に変更が生じる場合には事前に報告して調整する」。設計書はチームで合意した内容そのものです。勝手に変えるのはルール違反になります。

実装の拠り所になる設計書はこれまでに全部作ってあります。

• 何を作るか → 画面一覧・機能一覧
• 画面の見た目と動き → 画面仕様書・画面遷移図
• データの形 → テーブル定義書（またはファイル設計書）・ER図
• 処理の中身 → 機能設計書・CRUD図

「次に何を書けばいいか分からない」と感じたら、コードではなく設計書を開いてください。答えはたいていそこにあります。

• 設計書は「作って終わり」ではなく「実装中も育て続ける」もの
• 設計変更の手順: 気づく → チームに報告 → 合意 → 設計書を更新 → コードを直す
• 「設計書のどこに書いてある機能か」を言えない実装は、たいてい思いつきの実装

ソフトウェア業界には「ドキュメントとコードがずれたら、正しいのはコードの方」という皮肉な格言があります。多くの現場で設計書が更新されずに腐っていくからです。あるベテランエンジニアは、古い設計書のことを「考古学資料」と呼びました。発掘して当時の暮らしを推測する材料にはなるが、今の真実は書かれていない、という意味です。皆さんの設計書を考古学資料にしないでください。毎日更新されている設計書は、チームの最強の武器になります。

実装期間のAIとの付き合い方を確認します。結論から言います。

AIにコードを丸投げしない。AIと対話しながら、自分が理解して書く。

なぜでしょうか？　ここで考えてみてください。AIが書いた1,000行のコードが動かなくなったとき、中身を理解していない自分に直せるでしょうか？

AIペアプログラミングは、カーナビ付きのドライブに似ています。運転するのはあくまで自分。カーナビ（AI）は道を提案し、間違えたらリルートしてくれますが、ハンドルを渡してはいけません。ハンドルを渡した瞬間、それはドライブではなく「ただの乗客」です。

良い使い方と悪い使い方を対比します。

「会員登録機能を全部作って」は悪い使い方です。動いても自分の理解が残らず、壊れたとき直せません。一方「会員登録の処理の流れを設計したい。入力チェック→重複確認→保存、という順番で考えているけど、抜けている観点はある？」は良い使い方です。考えているのは自分で、AIは壁打ち相手だからです。

具体的なプロンプト例を場面別に示します。

場面1: 実装方針を相談する

「会員情報を登録する機能」を実装します。
設計書には以下の仕様があります。
- 入力項目: 名前（必須）、メールアドレス（必須・重複不可）
- 登録成功後は一覧画面に遷移する
処理の流れをステップに分けて一緒に考えてください。
いきなりコードは書かず、まず手順の確認からお願いします。

場面2: 書いたコードを理解しているか確かめる

以下は自分で書いたコードです。
この処理の流れを私が正しく理解できているか、
私の説明を聞いてチェックしてください。
私の理解:「まず入力値を受け取り、空チェックをして…」
[コードを貼る]

場面3: エラーが出た（最重要）

次のエラーが出ました。エラーメッセージの全文を貼ります。
[エラーメッセージ全文をそのまま貼り付け]
このとき実行したのは以下のコードです。
[該当コード]
エラーの意味を解説してから、原因の調べ方を教えてください。

エラーのときの鉄則は「全文を貼る」です。「なんかエラーが出ました」では、AIも人間の先輩も助けられません。エラーメッセージは犯行現場に残された指紋のようなもので、省略した瞬間に手がかりが消えます。

場面4: AIの提案を採用する前に

このコードを提案してくれましたが、採用する前に確認させてください。
- この行は何をしていますか？
- なぜこの書き方を選びましたか？　他の書き方との違いは？
私が人に説明できるようになるまで付き合ってください。

• 「動いたけど理解していないコード」はチームの借金。レビューも修正もできない
• エラーは全文をそのまま貼る。要約・省略をしない
• AIの提案コードは「自分の言葉で説明できたら採用」をマイルールにする

ペアプログラミングはもともと人間同士の手法で、2人で1台のPCに向かい、書く人（ドライバー）と指示する人（ナビゲーター）が交代しながら開発します。「2人で1つの作業なんて効率が半分では？」と昔から議論されてきましたが、研究ではバグの少なさや知識共有の効果が確認されています。面白いことに「ラバーダック・デバッグ」という派生手法もあります。ゴム製のアヒルに向かってコードを1行ずつ説明すると、説明している途中で自分でバグに気づく、というものです。アヒルは一言も話しません。それでも効果があるのです。AIは「返事をしてくれるアヒル」だと思うと、丸投げがいかにもったいないか分かりますね。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「設計書ドリブン開発のメリットを、設計書なしで作った場合と対比して説明して」
• 「朝会で報告することが思いつかないとき、どう準備すればいい？」
• 「AIペアプログラミングで、初心者がやりがちな失敗パターンを教えて」

今回学んだことを一言でまとめると「実装は、リズム（朝会・終会）と地図（設計書）と相棒（AI）で進める」です。

• 毎日のリズム: 朝会10分 → 実装2時間30分 → 終会20分
• 設計書ドリブン: ずれたら報告・合意のうえ設計書を直す
• AIペアプロ: 丸投げせず対話する。エラーは全文を貼る

次のセッションはいよいよ実装スプリント1。最初の機能を動かします。

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

• 朝会で共有する3点は何ですか？
• 実装中に設計の不備に気づいたとき、最初にやることは何ですか？
• エラーが出たとき、AIへの相談で守るべき鉄則は何ですか？
• 「AIにコードを丸投げしない」のはなぜですか？

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

• 参考リンク: 自チームのかんばん（Day 9作成）、外部設計書（Day 6完成）、内部設計書（Day 8完成）
• 発展課題: 「ラバーダック・デバッグ」をAIに解説してもらい、今日の実装で1回実践してみる

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