f:id:yosuke_tomita:20200601222837j:plain

エンジニアの @tmtysk です。皆さんの開発プロジェクトでは、どのようにミーティングを設計していますか？また、議事録はどのように残していますか？

開発プロジェクトの在り方や運用は、常にただ一つのマニュアルで成立させられるものではなく、プロダクトのフェーズやメンバー構成によってさまざまです。リモートワークやパートタイムによる参加など、働き方も多様化しているので、ミーティングの設計についても、プロジェクトごとにさまざまな運用がなされているのではないでしょうか。

弊社の場合、基本スタンスとして「コミュニケーションの中心はGitHubに置く」という考え方を置いています。そのうえで、「開発ミーティングのアジェンダや議事録はGitHub Issueに残す」というやり方をとることが多いです。*1

今回は、その背景と運用について書いてみたいと思います。開発チームのコミュニケーションや、ミーティング設計・運用に携わる方の参考になれば嬉しいです。

プロジェクト初期であっても、定例はやったほうが良い

新しい企画のプロジェクトが立ち上がる瞬間は、1,2名のチームからスタートすることも多く、メンバーのロールを整理したり、スプリントを設計したりというプロセスづくりが劣後になってしまうことは、よくあることのように思います。物事が随時ダイナミックに動くので、「必要なときに、随時ミーティングをやれば良い」という考えから、定例のミーティング設計がなされないケースもあるようです。

ですが、私は、以下のような理由から、メンバー構成やプロセスが固まっていない状況であっても、早期に定例の場を設けたほうが良いと考えています。

「いつ話せるのか/話して良いのかわからない」といった不安を軽減できる
「議論のテーブルに載せるべきかわからない」といった暗黙の課題を表面化できる
プロセスのリズムと進捗を意識していくきっかけになる

細かくはもっと挙げられるのですが、要は、プロジェクト内コミュニケーションに寄与する効果と、全体生産性に寄与する効果を期待できます。また、副次的な効果として、プロジェクトに新しく参加してくるメンバーに対する安心感やオンボーディングのやりやすさにも寄与するという効果もあると思います。

「定例の目的は何なのか」「決め事がない無駄な定例なら、やらずに生産活動に集中した方が良いのではないか」という声が聞こえてきそうです。しかし、誤解を恐れずに表現すれば、「短期的には無駄に見える機会の確保が、チームの全体最適に重要であることが多い」のです。*2 昨今のようなリモートワーク前提のチームであればなおさら。「どんな表情で話しているか」「どんな声色か」「困っていそうか」「手を差し伸べられる人は、どんなタイミングで発言するのか」「他者の発言に対して、どのような反応をしているか」こういったことは、非同期のテキストコミュニケーションだけでは、なかなか窺い知ることができません。

定例の機会を設けることは、ちょっとした認識共有と時間確保によって始められる、かんたんなアクションです。まだ定例の機会をもっていないチームは、まずは始めてみることをオススメします。無駄や改善ポイントがあれば随時見直していけば良いのです。

コミュニケーションツールは少ないほうが良い

コミュニケーションツールは、プロジェクトによってまちまちです。Slack, GitHubはメジャーなツールになってきていると思いますが、チャットワークであったり、BitBucketであったり、Backlog, Trello, Jiraなどもよく使われていますよね。ドキュメント共有も含めると、GoogleドライブやBox, Dropboxなども利用ツールに入ってくると思います。

適切なツールを適切なところに使うのが良い、というのは当然ですが、私の場合は、原則として「ツールは少ないほうが良い」という考えを持っています。ツールが増えると、管理すべきこと(権限や利用のルール)が増えてしまうからです。

このような調整ごとをメンバー間で取り決め、運用していくのは、オンボーディングの手間や習熟の期間が必要です。とはいえ、前項でも述べたように、プロセスやメンバーコミュニケーションが習熟していないフェーズであっても、定例の機会は確保しておいたほうが良いと思います。

そこで、弊社の場合は、多くのプロジェクトで標準的に利用しているGitHubのIssueに議事録をとるところから始めています。

GitHub Issueでの議事録とミーティング運用

ここからは、弊社での議事録とミーティング運用を、どのようにおこなっているのかについて紹介します。

前日までにアジェンダIssueをつくり、当日の進行を大まかに設計する

前日までに、以下のような内容でアジェンダIssueをつくります。Agenda Labelなどを付けるのも良いでしょう。このIssueには、各メンバーから当該週の活動や相談事項を、コメントとしてかんたんに記録してもらうようにします。

週次ミーティングでは、各人の進捗共有や討議、Issueの棚卸しなどをおこないます。各人の進捗や討議事項は、こちらのIssueにX/X XX:XXまでにコメントしておいてください。

日時

XXXX/XX/XX XX:XX-XX:XX

参加者(敬称略)

@daredare, @naninani

議事

進捗共有

討議

全体共有

ふりかえり

次のアクションの確認

GitHub Wikiにテンプレートをつくっておいたり、タイマーでIssueを自動作成したりするのも良い考えです。メンバーの活動共有として、特定のIssueやPRがあれば、Issue番号でリンクしてもらうようにすれば、共有や当日の協議もかんたんです。

定例は、まずは週1回の設定で、長くとも1時間程度で終われるようにします。最初は30分くらいにしておきつつ、様子を見ながら増減していけば良いと思います。後述しますが、予定時間は事前にしっかり決めておきましょう。

各人からの事前共有の内容次第では、ミーティングの進行予定を調整しておく必要が出てくるかもしれません。進行役になる人は、メンバーからどのようなコメントが投稿されるのかを気にしておき、「この相談事は、定例を待たずに、いま協議しよう」「これは、この定例の場ではなく別途時間を確保しよう」などといったことを検討しておけると良いと思います。

全体共有よりも、メンバーの共有を優先する

この定例は、メンバーの活動共有の場でもあり、ふりかえりの機会でもありますので、全体的な動きよりも個々の進捗の共有を優先します。進行役が、コメントの順に、メンバーからの共有を促します。

プロジェクトにはいろんなメンバーが参加しますので、「ここに書いたとおりです」で報告を終わらせるひともいれば、他者の報告をあまり聞いていなかったり、ミーティング中に別のタスクをやっていたりというひとも居るでしょう。

いろいろな人がいて、いろいろな事情があったとしても、進行役は、常に好奇心と想像力をもって、一つひとつの共有に向き合いましょう。あっさりした共有には質問で掘り下げたり、他の参加者へ意見を求めたりするなど、各人のミーティング発言時間がある程度揃うように調整していくのが、全体的には良い方向に向かうのではないかと思います。

時間を守る

ミーティング時間を守ることは、めちゃくちゃ重要です。全員を同期コミュニケーションの場に拘束するコストは非常に高い。進行役は、開始時刻はもちろん、常にタイムリミットに気を配り、予定していた議事が終わらなかったとしても、別途ミーティング時間を確保し、基本的には予定時刻でミーティングを打ち切りましょう。

予定通り始まらない/終わらないミーティングが定常化すると、ミーティングに限らず、時間の使い方に対する感覚の緩さが、チーム内で蔓延していってしまいます。書くは易し、私もなかなかうまくやれていないのですが、自戒の念もこめて、改めて書きました。

強いきもちをもってミーティングを終了し、参加者に感謝する

上記の時間厳守にも関連する話です。

なんだか精神論な見出しになっちゃいましたが、ミーティングの現場は、常にハッピーで明るい雰囲気になっているとは限りません。状況によっては、まだメンバー同士が打ち解けきれていなかったり、あるいはいろんな事情でチームがヒリヒリした感覚になっていたりで、静けさがミーティングを支配してしまうことがあります。「定刻だから終わらなければ。でも、このまま終わって良いんだろうか」という感覚になることもあるでしょう。とくにオンラインミーティングでは、ミーティング後の対面での雑談機会もとれませんので、モヤモヤする瞬間でもあります。

これは正直、私も誰かから良いアイデアをいただきたい。私が心がけていることは、

「何か言い残したことがある人はいませんか？」と呼びかけ、反応の間をしっかりとる
強いきもちを持って「終わります」を宣言し、ミーティングを終わる
終わるときには参加者に「お時間確保ありがとうございました」の感謝を伝える

この3点です。もちろん、以降でフォローが必要なこともあるでしょうが、それはそれで、よしなにやるとして。

まとめ

というわけで、「定例をやってなかったら、いますぐ始めましょう」「議事録はGitHub Issueで書くようにしたら、とっかかりはかんたんだよ」といったことを書きました。

プロジェクトが進み、プロセスができるにつれて、定例の場でやっていることは、スプリントレビューやデイリースクラムに置き換えていけるかもしれません。また、定例の同期コミュニケーションの場に甘えず、非同期で済ませられることは非同期で完結できるように、ツールやチームコミュニケーションを整えていくことも重要です。

ミーティングそのものは、何も生産できていないのですが、完全に不要にできるかというとそうもいかないのが実態ですよね。ここまで書いておきながらアレですが、以下は真理だとも思っています。