Part 1 オリエンテーション・動画
第4章 チームに情報を渡す
動画台本ナレーション全文
Slide 01. チームに情報を渡す
Chapter 4では、チームで仕事を進めるための情報の渡し方を扱います。実務では、コードを書くことに加えて、詰まった状況を相談する、変更の背景を説明する、レビューコメントに返信する、判断を短く残す、という場面が何度もあります。ここでは、相手が次の行動を取りやすくなる文章の型を練習します。
Slide 02. この章で身につけること
この章の中心は、相手が判断できる材料をそろえることです。扱う文章は、技術相談文、変更説明メモ、レビュー返信の3つです。加えて、同じ時間に集まらずに共有するときの書き方と、短いドキュメントで判断を残す考え方も扱います。文章をきれいにすることだけを目標にしません。
Slide 03. 仕事は頭の中だけでは進まない
個人作業では、自分の頭の中に前提や判断理由があれば進められることがあります。チーム開発では、その前提を相手に渡す必要があります。相談、変更説明、レビュー返信、ドキュメントは、チームで仕事を前に進めるための大事な記録です。
Slide 04. 前の章の成果をつなぐ
第1章では、困ったときに相談する姿勢を扱いました。第2章では、目的や制約を意思決定メモにしました。第3章では、AI利用と検証をログに残しました。第4章では、これらをチームに伝える材料として使います。自分だけのメモを、相手に伝わる形に整えます。
Slide 05. 良い相談の型
技術相談では、まず何をしようとしているかを書きます。次に、期待した結果、実際に起きたこと、試したことを分けます。最後に、何を判断してほしいかを書きます。急ぎ度、期限、影響範囲がある場合も添えます。相談では、答えだけをお願いするのではなく、どこまで調べたかを伝えます。
Slide 06. 情報が足りない相談と良い相談
情報が足りない相談は、進捗一覧がうまく表示されません、で止まります。これだと、相手は何を再現すればよいか分かりません。良い相談では、期待、実際、確認したこと、判断してほしいことを分けます。未提出者だけを出したいのに提出済みの人も残る。提出日時と画面更新は見たので、次に見る場所を判断してほしい、と書きます。
Slide 07. 相談前に確認すること
相談する前に、全部を解決する必要はありません。ただし、どこまで見たかは書けるようにします。エラー文、再現手順、入力データ、期待結果、最近変えた箇所を確認します。AIに相談文の整理を頼むのは有効です。ただし、ログや実行結果は自分で確認します。
Slide 08. 変更説明メモの型
変更説明メモは、後でPR、つまりレビューに出すときの説明にも使えます。書くのは、背景、変更内容、今回やらないこと、確認方法、リスク、レビューしてほしい点です。コードの差分だけでは、なぜ変えたのか、どこを見てほしいのかが伝わりません。レビュアーが見始められる状態に整える文章です。
Slide 09. 変更内容だけでは足りない
進捗一覧を追加しました、だけでは、レビュアーには背景も確認方法も分かりません。良い変更説明では、背景として、詰まっている受講者に早く気づくため、と書きます。変更内容として、担当受講者の一覧、最終ログ日時、未提出者フィルタを書く。最後に、CSVや自動アラートは初回では入れない、と範囲も書きます。
Slide 10. レビューしてほしい点を書く
レビュー依頼では、見てください、だけで終わらせず、見てほしい観点を書きます。例えば、初回リリース範囲は大きすぎないか。メンターだけが見られる権限になっているか。未提出者の絞り込みは、画面側ではなくサーバー側で行うべきか。観点があると、レビュアーは時間を使う場所を選びやすくなります。
Slide 11. レビュー返信の型
レビューコメントを受けたら、まず理解したことを返します。次に、修正するなら何をどう直すかを書く。確認したいなら、どこが分からないかを書く。反映しない場合も、代替案や理由を短く残します。レビュー対応は、指摘に従うだけの作業ではなく、よりよい形にするために考えを合わせる作業です。
Slide 12. 修正、質問、見送りに分ける
レビューコメントは、すべて同じ返し方にしません。サーバー側で処理したほうがよさそう、という指摘には、修正方針と追加テストを返します。表データとして書き出すCSVも今回入れたい、という提案には、初回では見送る理由を書きます。閲覧範囲が心配、というコメントには、誰に何を確認するかを返します。
Slide 13. 非同期では待ち時間を減らす
チーム開発では、相手がすぐ隣にいるとは限りません。非同期、つまり同じ時間に集まらず、チャットやメモで進める共有では、何の話か、誰に何をしてほしいか、いつまでに必要かを書きます。返信がない場合にどう進めるかも決めておくと、待ち時間を減らせます。
Slide 14. 小さなドキュメントで残す
すべてを大きな設計書にする必要はありません。決めたこと、判断理由、見送った案、未解決事項、確認した事実、次のアクションを短く残すだけでも価値があります。第2章の意思決定メモと第3章のAI利用ログは、採用したこと、見送ったこと、まだ確かめていないことを共有する材料になります。
Slide 15. AIは文章の下書きに使える
AIは、相談文、変更説明メモ、レビュー返信の下書きに使えます。長いメモから要点を抜き出すことも得意です。ただし、入力前に秘密情報や個人情報がないか確認します。丁寧な文章でも、事実が違えば使えません。未確認を確認済みと書かない。実際にはないログや、実行していないテスト結果を書かない。ここを守ります。
Slide 16. 個人開発にもつながる
この章の型は、個人開発や最終発表でも使います。詰まったら技術相談文で相談する。変更説明メモで、何を作り、なぜそう判断し、何を確認したかを説明する。AI利用では、何を任せ、どこを確かめたかも残します。レビュー返信では、指摘への対応を残します。自分だけに閉じないことが、実務に近づく練習になります。
Slide 17. 演習1 技術相談文
最初の演習では、未提出者だけを表示するフィルタの不具合を題材に、技術相談文を書きます。期待結果は、未提出の受講者だけが表示されること。実際の結果は、提出済みの受講者も残ること。確認したことと、メンターに判断してほしいことを分けて、technical-question.md にまとめます。
Slide 18. 演習2 変更説明メモ
次の演習では、変更説明メモを書きます。第2章の意思決定メモと、第3章のAI利用ログを読みます。背景、変更内容、今回やらないこと、確認方法、リスク、レビューしてほしい点を整理します。成果物は change-description.md です。後の章では、この考え方をレビューに出す説明文へつなげます。
Slide 19. 演習3 レビュー返信
3つ目の演習では、レビューコメントに返信します。サーバー側で処理したほうがよい、CSVも今回入れたい、閲覧範囲を確認したい、という3つのコメントを読みます。修正する、確認する、見送るに分け、理解、対応方針、確認事項を書きます。成果物は review-replies.md です。
Slide 20. 次は開発環境へ
ここまでで、学習の進め方、価値の見方、AI利用の検証、チームへの情報共有を扱いました。次の章からは、手元の開発環境に入ります。CLI、つまり文字で操作する入口、エディタ、ファイル、ローカル実行など、実際に作業する入口を整えます。実行したコマンドやログを残し、詰まったらこの章の相談の型で共有します。