打ち合わせの議事録
打ち合わせの内容もIssueに記録するようにしています。リポジトリの設定にもよりますが、Issueに記載した内容は後から編集できます。
しかしIssueは複数人数で同時に更新するとコンフリクトが起こるため、ノートのように打ち合わせ中にどんどん書き換えるという用途には向いていません。必要に応じて使うIssueのみを1人で編集するか、他のツールと組み合わせる方法を使い分けましょう。
私たちは参加者が多い場合、Google ドキュメントをよく利用します。Google ドキュメントでは同時に複数の人が1つのドキュメントを更新でき、コンフリクトを避けられるからです。また議事録を1人だけで書く場合、書く人の担当箇所や理解の強弱で記述内容に偏りや抜けが発生しますが、参加者全員で編集すればそれらの問題を回避できます。
実際の打ち合わせの流れは次の通りです。
- 打ち合わせを始める前に議事録係やファシリテーターがドキュメントを作成する。
- 参加者に編集可能な設定で共有する。
- 主担当が議事録を書いていく。
- 誤りや抜けは参加者が適宜加筆修正する。
- Google ドキュメントのURLと重要なことはIssueにコピー＆ペーストする。
Google ドキュメントには文章以外にもスプレッドシート（表計算）や図形描画などもあるため、議題に応じて組み合わせて使うといいでしょう。
重要な話はリポジトリのファイルにする
Issue上で議論が行われ、話が長くなると、最終的に何が仕様なのかわかりにくくなります。多少仕様がブレてもプロダクトとして問題が無いなら些末なことですが、クリティカルなものについては別途リポジトリのMarkdownファイルやテキストファイルにまとめるようにします。こうしておくと最終的にまとまったものが明確になるため、チーム内の認識の齟齬を減らすことができます。
また、それ以降の仕様変更の際に、そのファイルをgit blameすれば、必ず変更に関係するPRが見つかるため、誰が何の意図でそれを変更したかを追うこともできます。
キャッチアップの仕方
個々のメンバーがIssueやPRを更新するため、その中には自分に関係があるものと無いものの両方が含まれています。全てのIssueやPRについて更新の有無を調べるのは無理ですし、時間の無駄です。
GitHubにはNotificationsという機能があり、これを使うと情報のキャッチアップが捗ります。自分が参加しているIssueやPRの更新があると、Notificationsに通知されます。IssueやPRの参加者（participants）になっていれば通知されるため、自分を追加するといいでしょう。
Wantedly独自の文化ですが、この方法として気になるIssueやPRに対して、下図のように:eyes:（目の絵文字）のみのコメントを行い、参加者になると同時に「見てるよ」という意思表示を行います。
