チーム定例を改善するために行った3つのこと

この記事は、 NTT Communications Advent Calendar 2022 13日目の記事です。

はじめに

こんにちは。SDPFクラウド/サーバー仮想サーバーチームの宮岸(@daiking1756)です。

普段はOpenStackを使ってIaaSを裏側からお世話する仕事をしています。

この記事では先日開催された第6回 NTT Agile MeetupのLightning Talkで話した「チーム定例の議事録を工夫した話」を元に、当日は時間の関係で話せなかったチーム定例を改善するために行った3つのことを紹介していきます。

3行まとめ

最初に3行まとめです。チームの定例のBefore Afterを書いておきます。

Before	After
全ての議題を話し切るまで時間を定例を後ろに延長していた	後ろに予定を入れることで時間厳守
定例開始後に議題を決めることもあった	開始前に「議題の整理」を行うことで、短時間で濃い議論になった
各議題の完成の定義が曖昧であり、次回議事録を見た際に継続議論が必要なのかの判断が必要だった	各議題のステータスを管理することで話すべき議題の判断が容易になった

なぜ定例にフォーカスしたのか

パレートの法則（別名: 80:20の法則）という有名な法則があります。文字通り、全体の数値の大部分は、全体を構成するうちの一部の要素が生み出しているという法則です。プログラミングの文脈では「プログラムの処理にかかる時間の8割は、コード全体の2割の部分が占める」という話でよく用いられます。つまり、コード全体の2割の部分は何度も繰り返し実行されることで（ループ処理や頻繁に呼ばれる関数など）、全体の実行時間の大部分を占めているということになります。¹ ここから、全体のパフォーマンスを改善させる1つの方針として、繰り返し実行される部分に着目することが大事ということが分かりますね。

そして「定例 = 繰り返し 行われる会議」なのです。つまり、定例を改善することが、チームのパフォーマンス改善に大きく影響するのではないか？と思い、フォーカスすることにしました。

そもそもどんな定例をやっているのか

現在私のチームで行っている定例は大きく下記の3つです。

スクラムイベント（デイリースクラム、スプリントプランニング/レビュー/レトロスペクティブ）²
企画チーム / 運用チーム / ベンダーとの定例
サブチーム（チーム内で担当領域ごとに結成されているチーム）定例

このうち、影響範囲が少なく小さく始められる & 私の中で問題点が見えていた「サブチーム定例」を手始めに改善の対象としました。

定例がズルズル延長してしまう問題

サブチーム定例では、困っているタスクについて状況を確認したり、同期コミュニケーションの力でみんなの悩みを解決することを目的で行っています。

まず問題だと感じていたのは、定例がズルズル後ろに延長していたことです。

サブチームでの話題は参加者も少なく、議題のコンテキストも深く共有していることが多いため、深く長い議論になりがちです。それ自体は全く問題ないのですが、時にはスコープ外の議論へ発展することもあり、設定した時間内で全ての議題を話し切ることができていませんでした。

他の定例の前に開催時間を変更

そこで、サブチーム定例をデイリースクラムの直前に行うようにしました。これにより、デイリースクラムの時間になったら強制的にサブチーム定例を終了することになり、結果としてサブチーム定例がズルズル延長することは無くなりました。

※ スクラムイベントは比較的時間通りに開始・終了できていたため、全体が遅延することもありません。

続けていると徐々にですが、参加者全員が時間制限を意識した定例を行うことが少しずつできるようになってきて、意識するだけでかなり変わるもんだなぁ（小並感）と思いました。

とはいえ、意識だけでは解決できない問題もありまして・・・。

話すべき内容が時間内に話しきれない

当たり前ですが、時間が短くなったことで、話すべき内容を時間内に話し切れないことが増えました。また、その中には、優先度を上げて対応するべき内容が含まれていることもあり、このままではチームのアジリティが落ちてしまうと感じていました。

そこで、短時間の定例で効果的に優先度の高い議題をカバーするために、「議題の整理」をしっかりすることにしました。

どんな風に「議題を整理」したのか

今までも事前に議題を議事録ページ³に書くことはありましたが、優先度やその議題のステータスが不明確なために、どの議題から話すべきかを決めるのに時間がかかっていました。（それ故に、とりあえず上から話していき、時間が足りなくなっていました）

そこで、各議題について下記の項目を整理した状態で、定例開始までに議事録ページに記載しておくようにしました。項目は、よくあるMTGのベストプラクティスや、チームの状況を踏まえて、無理のない範囲で始められそうなものをえいやで選びました。

詳細はNTT Comが公開しているリモートワークハンドブックをご参考下さい。

これらを議事録ページに反映させると下記の画像のようなイメージになります。特に優先度とステータスの項目は、視覚的に分かりやすく色や絵文字をで表現しています。

チームの共通認識を作る

上記の「議題の整理」の効果を高めるために、定例を運用する中で下記のルールをチームの共通認識として持つことにしました。

議題を記載する際は優先度順に記載する
優先度:高以上の議題のステータスが定例中に✅へ遷移せず残ってしまった場合は、別途チーム内で話す時間を作り最速で✅へ遷移させる

読んでみると1つ1つは当たり前のことが書かれているのですが、一度書き起こして、ぶれない共通認識としておくことで、スムーズで効果的な定例が行われるになりました。

細かい話

繰り返し発生する定例の議事録は大きく2つの取り方があります。新規と追記です。自明ですが、一度書いておきます。

新規: 毎回新しい議事録ページを作成する
追記: 1つのページにどんどん追記していく

サブチーム定例で多いのは新規と追記のハイブリッド型です。基本的には追記していき、四半期に1回ほどのペースで新規ページにリニューアルしています。

また、サブチームでも四半期に一度は、立ち止まって仕事っぷりを振り返る時間を取っており、振り返りの場で次の四半期にやることや目標を立てます。この目標を定例ページの議事録の先頭に書いておくことで、チームや個人が目標を意識できるような効果も狙っています。このあたりはまだまだ実験中の取り組みですが、いろいろ試しながら改善を続けています。

やってみての感想

手始めに自分が参加しているサブチーム定例について、いろいろ試行錯誤しながら改善活動を行っていきました。すると隣のサブチームから「いい定例やってんね」「その議事録良さそうね」と声が掛かり、気づかないうちに他の定例にも布教されていることがありました。

また、たまに隣の定例を覗いてみると、そのチーム独自の文化やアレンジがされていることもあり、発見や学びが多くあります。ドキュメント化されていないTipsや文化などの中にも重要なものは多いですが、その当事者たちの内側では当たり前になっていてその重要さや特殊さに気づかないことがありますよね。内側で気づければよいのですが、これらを見出すのはその外側にいる人たちの役割なのかもしれませんね。

「越境はいいぞ」的な話は聞いたことがありましたが、今回の経験を通して越境の重要性を肌で感じることができました。今後も積極的に越境していきます。

そして、ここまで読んでいて感じた方もいると思いますが、この記事中には定量的な話がほぼ出てきません。定性的な話がメインでした。それでもチームメンバーからのフィードバックにより、この取り組みに一定の効果があったことは確信しています。しかし、定量的なデータも合わせて用意できていれば、更にこの取り組みの効果を多角的に分析できていたことでしょう。また、そこから新たな改善ネタが見つかることもあるでしょう。 「問題の定量化と改善の計測」 大事。

特にこのようなブログ記事などで取り組みを紹介する際には、問題の定量化と改善の計測ができたら更に良かったと思っています。計算機ではなく人間が絡む領域だと全てを定量化するのは難しくなりますが、今後はこの点も意識した改善活動を行っていきます。

おわりに

いかがでしたでしょうか。今回紹介した取り組みは私のチームではたまたまうまく機能していますが、決してベストプラクティスのようなものではありません。もう少し厳格なルールや仕組みを作ったほうがいいチームもあれば、その逆もあるでしょう。それを見極めるためには、チームをよく観察し、小さく試して小さな成功を積み上げていくことが大事だと思います。（私もまだまだ全然できていないですが）

この記事の内容が少しでも皆さんのより良い定例ライフに繋がれば幸いです。

さて、NTT Comでは現在、現場受け入れ型インターンシップを募集しております。なんと申し込み期限は12月14日（水）13:00迄まで！残り時間僅かです。

様々なポジションで募集しておりますが、ぜひ仮想サーバーチームのインターンシップもチェックしてみて下さい。

engineers.ntt.com

information.nttdocomo-fresh.jp

それでは、明日の投稿もお楽しみに。