はじめに
この記事では、弊社のAndroid版バスNAVITIMEを開発しているバス事業Android開発チームが2018年4月からの約1年間で取り組んだチーム運用の改善についてご紹介いたします。
読者の皆様のチーム運用の参考になれば嬉しいなと思うと同時に、まだ私たち自身も試行錯誤を続けている最中ですので「うちではこうやっています」などのコメントもいただけると幸いです。
チームについて
チームの特徴
私たちのチームは下記のような特徴を持っています。
- メンバー構成
- 3人
- ベテラン・中堅・若手が1人ずつ
- 仕事の仕方
- 開発は並行開発
- 多部署との調整もそれぞれで行う
- 情報共有は朝会とドキュメントで行う
- その他
- 席が離れており同フロアにいるがすぐに話しかけらない
- 3人とも黙々と作業する性格
チームの課題
このチームで運用を続けて行く中で、下記のような課題が見えてきました。
- 過去の運用方法をそのままにしていて改善がされていない
- それぞれが持つ案件の進捗状況を把握できず、フォローに入るタイミングが遅れてしまう
- 技術レベルがまばらなので、ベテラン・中堅が取り入れた技術要素を若手が使いこなせず属人化してしまう
次の項目からは、上記の課題を解決するために取り組んだアプローチをご紹介します。
課題解決に向けたアプローチ
定期的な振り返りの実施
過去の運用方法をそのままにしていて改善がされていない
この課題を解決するためにまず始めたことは定期的な振り返りです。
私たちのプロダクトは、このチーム構成になる前から運用されていました。
これまでの運用方法は面倒で課題には感じていましたが、前からやっているからと改善に踏み出せずにいました。
こういった運用面での課題を改善したいと考え、振り返りによって何を課題に感じ何を改善していくのかを改めて整理するようにしました。
振り返りの頻度や手法をいくつか試しましたが、私たちは現在毎週金曜日にその1週間の振り返りをする運用に落ち着きました。
2週間だと長くて出来事を忘れてしまう、1週間より短いと業務時間を圧迫するというのが理由です。
振り返りの流れについても少しご紹介したいと思います。
振り返りの流れ
アイスブレイク
振り返りを開始する前にGood & Newというレクリエーションを行いました。
その週にあった良かったことと新しいことを1人2分で発表していきます。
普段距離が離れていてあまり会話ができないメンバー同士のアイスブレイクとともに、振り返り前に必ず言葉を発することで発言することに慣れさせることも兼ねています。
また、振り返りが反省会のようなネガティブな雰囲気にならないようにポジティブな意識・雰囲気を作ってから振り返りを始めたいという意図もあります。
普段から近くにいてコミュニケーションが活発なチームには、もしかすると不要なフェーズかもしれません。
メンバーの考えを洗い出す
事実/感情 Good/Badという手法を用いてその週にあった「良かった事実」「良かった感情」「悪かった事実」「悪かった感情」を洗い出します。
馴染み深い振り返り手法であるKPTで言うところのKeepとProblemに似ている部分ではありますが、KPTでは具体的な行動に対する良し悪しを振り返るのに対しこちらの手法では感情という部分にもフォーカスしていることが特徴です。感情にフォーカスすることで、KPTでは拾えない感情面に影響する課題を見つけ出すことが可能になります。
具体的な行動に落とし込む
事実/感情 Good/Badで洗い出された内容を改善、もしくはもっと良くするための具体的な行動を考えていきます。
私たちはここでStar fishという手法を用いました。
これは「新たに始める行動(Start)」「もっと量・機会を増やす行動(More)」「今のまま続ける行動(Keep)」「もっと量・機会を減らす行動(Less)」「やめる行動(Stop)」という5つの項目について考える手法です。
ここでもKPTを例に取るとこのフェーズで考える行動というのはKPTで言うところのTryに当たる部分です。Tryでは新しく改善していくことに重きを置きがちになりますがこの手法では減らすことも視野に入れて議論ができるため、より改善の幅を広げることが可能になります。
議事録を写真で残す
振り返りの内容を文字に起こす作業が発生すると議事録担当の負担がとんでもないことになって振り返りがネガティブなものになってしまいます。
そのため、議事録は必ず写真だけで残すようにしています。
振り返りの効果
振り返りを行うことでチーム運用に関する課題点を洗い出すことができ、1つ1つに対して具体的なアプローチをしていくことができました。
それだけではなく、メンバーそれぞれが抱えている個人的な課題も見えてきたことが大きな効果だと感じています。
反面、具体的な行動に落とし込めずに心掛けのような状態で議論が止まってしまうこともあり、改善の余地はまだまだありそうです。
また、個人的な課題が見えてきたことは良かったですが振り返りのように人数が多い場だと個人の課題に対するアプローチはなかなか深掘りできませんでした。
したがって、個人の課題に対するアプローチは1on1のような対面の方が見つけやすいのではないかと感じています。
Slackにチームのtimesチャンネルを作成
それぞれが持つ案件の進捗状況を把握できず、フォローに入るタイミングが遅れてしまう
まず、この課題の根本的な問題としてメンバー同士のコミュニケーション不足がありました。
物理的に距離が離れているため、どうしても対面でのコミュニケーションが取りづらい環境でした。
そこでこの課題を解決するために、チーム用のtimesチャンネルを作成しました。
timesチャンネルとはいわゆる「分報」と呼ばれるものです。
日報や朝会などによる進捗報告や知見の共有では満たせないスピード感を得られるもので、弊社では主に個人単位で作ることが多いチャンネルです。
今回はこのtimesチャンネルをチーム単位で作成して、チームの進捗報告・知見の共有の場として活用しました。
物理的に集まれないならSlack上で集まればいいじゃない、という考えです。
進捗報告・知見の共有の場とは言ったものの、投稿内容は制限しておらず担当案件の話から個人的な取り組みの話まで基本的になんでもOKにしています。
timesチャンネルの効果
やっていることを逐次timesチャンネルに投稿するようになったため、遅れが把握しやすくなりメンバー間でのフォローが早くなりました。（つまづいている部分がある場合はその内容を共有することで、解決策を知っているメンバーが手助けに入ったりします。）
また副次的な効果として、ラバーダッキングやベアプログラミングなどの手法と同様に誰かに話しかけることで自分の考えが整理されて解決策を導きやすくなるという効果もありました。
さらに、課題を発見したけど週末の振り返りまで持ち越すと忘れてしまいそうと思った際にこのチャンネルに投稿しておくことで、振り返りを待たずに早いサイクルで課題に対するアプローチに入れるというメリットもありました。
実際にあったやりとりを例として添付します。
モブプログラミングの導入
技術レベルがまばらなので、ベテラン・中堅が取り入れた技術要素を若手が使いこなせず属人化してしまう
私たちのチームでは新しい技術をキャッチアップしていこうとするあまり、導入が先行してしまいその後の運用がうまく回らないケースが何度かありました。
導入した技術を全員が使いこなせるようになるにはどうすればいいか考えた結果、私たちはモブプログラミング(以下モブプロ)を解決策として選択しました。
モブプロとは、これまで行われてきた「メンバーそれぞれが別々の課題に取り組む働き方」とは違い、「チーム全員で1つの課題に取り組む働き方」です。メンバー間の情報格差をなくすことが可能になったり情報共有による同期コストを削減できたりといったメリットがあり、最近では弊社でも活発に行われるようになってきています。
私たちのチームではこれまで、導入を1人に任せその後各メンバーへ共有という流れを汲んでいましたが、導入のタイミングから全員で取り組むことで属人化を防げるのではないかと考えました。
これまでの働き方を全てモブプロに置き換えることは難しかったため、新規で技術要素を導入する場合に限ってモブプロを行う運用にしてみました。
モブプログラミングの効果
一番大きい効果としては、新規で技術要素を導入した後に各メンバーへ共有するという作業がなくなったことが大きいと感じています。
この作業がなくなることで、導入フェーズから運用フェーズへとスムーズに入れるのでとても効率的になりました。
1つ注意点としては、モブプロはチームの課題全てを解決できるわけではないと感じました。
具体的な例でいうと、コード規約や運用上の暗黙的なルールを全員で共有したりするのはモブプロには向かないと感じました。
メンバー全員のコストをそこに割くには勿体無いというのが1つと、そういったルールは人の手を煩わせることなく自然に導入できる環境を作る方が健全であるという私の考えが1つです。(例えば、コード規約であればCIで自動フォーマットする仕組みを作るとか運用上の暗黙的なルールであれば自動化してルールを意識する必要をなくすなど。)
モブプロは流行りではありますが、チームの課題を解決する1つの手段として始めるのがいいのではないかと思っています。
おわりに
さて、いかがだったでしょうか。
チーム毎に特徴も違い正解はないとは思いますが、皆様のチーム運用の参考になれば幸いです。