こんにちは、開発部の椿です。
飲食店ドットコムやモビマルなどのサービス開発・運用保守を担当する「会員企画開発チーム」のチームのリーダーを務めています。
今回は、チーム内で実践している「問題・課題をチーム全体で解決していく」という運用方法についてご紹介します。
運用を始めた経緯
最初のきっかけ
私たちのチームでは毎月バグの振り返り会を開催し、バグ抑制のための対策立案とその振り返りを行っています。 この過程で、技術不足に起因するバグを抑えるため、問題のあるコードをメモし、チームのコーディング規約としてまとめていく方針を立てました。
発展
まず、Slackに問題のあるコードをメモしていく運用を開始しました。弊社は開発部のチャンネルは dev という接頭辞をつけるルールがあり、「会員企画開発チーム」なので kaiin （ローマ字読みがダサいですが…）という言葉を使って「#dev_kaiin_review_notes」というチャンネルを作成しました。
当初は気軽に書き込めて良いという意見がある一方で、気になるコードがあってもまだ書き込んでいなかったり、個人用のチャンネル（times チャンネル）に書いてしまったりという意見もありました。
そこで、より気軽に投稿できるよう「#dev_kaiin_notes」にチャンネル名を変更し、投稿内容の制限をなくしました。
その結果、問題のあるコードだけでなく、サービス仕様の落とし穴や開発方針の相談など、さまざまな内容の投稿がされるようになりました。
壁の出現
多様な内容が書き込まれるようになり、1日に1件以上のペースで投稿が増えました。 すると今度は、確認する時間が足りなくなってしまいました。
開発の方針に関わる重要な相談をしたくても、投稿順に確認していくため、なかなか順番が回ってこない…という状況が発生しました。
毎日の朝会で確認していましたが、時間が足りず、確認のためのミーティングを増やすべきかという議論まで出るほどでした。
最終的な形
最終的に、各投稿には重要度の違いがあるはずで、重要度の高い投稿から確認していくべきだという結論に至りました。 重要度の低い投稿は、後回しになっても構わないという考えです。
緊急で話したい投稿には特定のリアクション（「会員企画相談」）をつけ、優先的に確認します。
その後、リアクションのついていないものを順に確認していく運用に落ち着きました。
#dev_kaiin_notes の運用方法
現在の具体的な運用方法をご紹介します。
チャンネルへの書き込み
現在の #dev_kaiin_notes チャンネルは「ちょっと気になったこと、共有したいこと、何でも良いのでメモとして残す場所」と定義しています。 例えば、以下のような内容が投稿されています。
- コード上の問題点
- リファクタリング案
- チーム内への共有事項
- 便利なツールの紹介
- 相談事項
- やりたいことの提案
意識しているのはとにかく気軽に投稿するということです。 「ここのインデントがずれている」くらいの些細なことも歓迎しています。 その結果、先月は1か月で48件、営業日数で割ると1日あたり2.5件の投稿がありました。
投稿の確認
毎朝開催しているチームの朝会で、全員で投稿を確認しています。 どんな些細な投稿でも議題に上げ、投稿者に内容を共有してもらいます。
朝会では #dev_kaiin_notes の確認以外にも議題があるため、通常は最後の余り時間で確認します。 ただし、「会員企画相談」のリアクションがついた投稿は、他の内容よりも優先して確認することで、重要な案件の確認が遅れないよう対策しています。
ここで意識しているのは全員で全ての投稿を確認することです。 投稿内容を全員で共有し、誰もが平等に意見を言える場を目指しています。
確認後
確認後は必ず「次にやること」を決めます。 些細な問題点で優先度が低くなることはあっても、タスクとして切り出し、手が空いた時に改善できるようにしています。 （もちろん、単純な共有など、確認だけで完結するものもあります。）
この運用で改善できたこと
当初の目的であった技術力向上については、#dev_kaiin_notes をきっかけにコーディング規約が充実し、全員がある程度のクオリティのコードを書けるようになってきました。 また、全員で確認することで各自が問題点を意識できるようになり、技術力の底上げにつながっています。
副次的な効果もいくつか現れました。 誰でも気軽に投稿でき、全員で確認して話し合うことを日常的に行うことで、チーム内の心理的安全性が高まり、活発な議論が生まれるようになりました。 さらに、気軽な共有を通じて、個人が持っていた暗黙知をチーム全体の形式知に広げられています。
弊社開発部は2020年のコロナ禍を機にフルリモート勤務となり、それ以前よりもコミュニケーションが取りづらくなっていました。 しかし今では、#dev_kaiin_notes をきっかけに、チーム内で活発なコミュニケーションが取れるようになったと実感しています。
おまけ
弊社ではドキュメントツールとして esa.io を利用しており、朝会の議事録は esa に残しています。 しかし、投稿は Slack で行うため、投稿と議論を結びつけることが難しくなっていました。
そこで、esa の内容を Slack に転記するスクリプトを作成し、esa のコメント webhook から AWS Lambda function でスクリプトを実行する仕組みを構築しました。 これにより、Slack だけで過去の議題と結論を確認できるようになりました。
まとめ
#dev_kaiin_notes という、誰でも気軽に書き込める Slack チャンネルを活用して問題点の吸い上げや知見の共有が促進され、活発なコミュニケーションを通じて継続的に改善を図るチームを形成できました。
繰り返しになりますが、大事なことは以下の3点です。
- 何でも良いのでとにかく気軽に書き込める場所にすること
- チーム全員が参加する場で確認すること
- 優先度をつけて確認ができるようにしておくこと
この取り組みはサービス開発を行う他のチームにも展開され、各チームで独自の notes チャンネルを作って運用しています。
