この記事は GLOBIS Advent Calendar 2020 - Qiita の11日目です。
こんにちは、グロービスでエンジニアをしている @shifumin です。
コロナ禍以降、基本的にはチームメンバーが全員自宅から勤務、つまりほぼフルリモートに移行しました。
今日はリモートワーク下でもチームの開発生産性を上げるために、自分のチームでコロナ禍以降に新たに導入したスウォーミングに関する取り組みをご紹介します。
そもそもスウォーミングって何？
そもそもスウォーミングとは一体なんでしょうか？
スウォーミング(Swarming)とは、元々はハチやアリが群れること、転じてソフトウェア開発の文脈では一つの開発トピックやユーザーストーリーに対してチームメンバーができる限り協同して取り組むことを表します。
一度に複数のユーザーストーリーをチームメンバーがそれぞれ並行して取り組むのではなく、最優先のストーリーを全員で集中して取り組むということですね。
なぜスウォーミングを行うのでしょうか。理由は主に下記あたりになるかと思います。
- 1つに集中することによりユーザーストーリーの着手から完成までのリードタイムを短縮する
- 認識違いや想定外の事態への対応を素早く行い手戻りを減らす
- 共同して作業することによりチーム内の知識移転を促進させる
余談ですが、「何か便利な参考図ないかな〜」と思って"スウォーミング"でGoogle画像検索すると閲覧注意な画像一覧が表示されました。Google画像検索"スウォーミング"、ダメ、ゼッタイ。
以下は具体的に自分のチームがスウォーミングについて新たに導入した取り組みとなります。
ユーザーストーリーごとに作業用スレッドを1つ作る
僕たちのチームではプロダクトバックログをユーザーストーリー形式でGitHubのIssueで管理しています。また全社的にチャットツールはSlackを利用しています。
これは意識的に導入したというよりは自然とこうなったのですが、あるストーリーの対応着手時にSlackに作業用スレッドを1つ作り、そのストーリーに関係のあるやりとりの一切をそのスレッドで行うようにしています。Issueのコメントには作成したスレッドのリンクを貼っておきます。
意図としては、作業の可視化と共有や疑問点の即時解消するための場所の一元化があります。
スレッドには自分が今から着手すること(完了してからでは遅い)や確認すること、実装方針や疑問点などを息をするように書いていきます。
着手することや考えていることを息をするように書くの様子。
作業分担が容易になり、また優先度や仕様の認識の相違を早い段階で防ぐことができます。
スウォーミングとは少しずれますが、MTGやフレックスなどで途中参加や途中離脱がある場合の引継ぎもやりやすくなります。
スウォーミングによって疑問点がすぐに解消されている様子です(半年前に自分でやったことをど忘れしていた回)
Slackに作業スレッドを用意すること自体のメリットとしては下記を感じています。
- そのストーリーの対応状況が一目で分かる
- 途中で参加する際や別件などで抜ける際のキャッチアップや引き継ぎをしやすい
- GitHubのコメントでのやり取りよりはメンションに気付きやすく反応しやすい
- もちろん確定した仕様や決まり事は適宜GitHubのIssueにも反映・追記は行う
- 過去のユーザーストーリー対応時のログがまとまっている
- 上記と似ているのですが、「この対応時は何をやったんだっけ？」ということを振り返る際にまとまっていると嬉しい(人間は忘れやすい生き物なので)
ちなみに、障害発生時の調査対応も専用のスレッドを作成してそこにまとめる形で行なっています(これはやっているチームは多そう)
仕様決め・設計時には議論検討用ページの用意する
僕たちのチームはドキュメントサービスとしてNotionを利用しています。
仕様決めや設計時にそのアウトプットである仕様や設計ドキュメントとは別に議論用のページを作成しています。
- 〇〇の設計
- 〇〇の設計の議論・検討
設計時には上記2ページを作成しているということです。仕様決めや設計時にはこの議論・検討用ページの方で同時編集で論点観点出しや案出しを行っています。また、仕様アウトプットにはリンクを貼って参照できるようにしておきます。
元々は最終的な仕様アウトプットと同じドキュメントに議論・検討項目(スペース)を用意し適宜書いていき完了時によしなに削除や移動させていたのですが、「これ、最初からページを分けていた方が楽じゃね？ログも残せるし」ということで独立して検討用ページを用意するようになりました。
議論・検討用ページの例。
議論・検討用ページを独立して用意することのメリットは下記あたりかなと思っています。
- 同時編集機能を使うことにより検討項目や論点出しを複数人同時にあるいは非同期に行うことができる
- 最終的に決定した仕様とは別に議論・検討を行ったログが残る
- どのような論点を踏まえ仕様が決まったか、また棄却された案などが後から分かる
仕様決めや設計もモブでやる(いわゆるモブ設計)
この"モブ"はいわゆるペアプロ/モブプロの同じ"モブ"です。
実装時にペアプロ/モブプロすることも多いですが、僕たちのチームは設計や仕様決めもZoomやGoogle Meetを使って画面共有しながら複数人で同期的に行なっています。
これは、その対象にもよるかと思いますが実装タスクに比べて、仕様決めや設計は自由度が高くメンバーごとの認識のずれから手戻りが発生することが多かったため導入されました。
前もって予定を押えて同期的に行うというよりは常時開放されたモブ設計用のZoom部屋やMeet部屋を用意しておき、適宜入ったり抜けたりして行っています。
設計をモブで行うメリットとしては下記があると感じています。
- 設計初期からの認識のずれを取り除き手戻りを防ぐ
- 仕様の俗人化を防ぎやすい
- レビュー及び仕様共有の時間を削減できる
このモブ設計については、モブプロもそうですが、同期的に行うためチームで考えるとどうしても参加者人数 × 時間分拘束されるのですが、それを差し引いてもメリットの方が大きいと考え導入しています。
終わりに
この記事では自分のチームがリモートワークにおいてどのようにしてスウォーミングについて取り組んでいるかを紹介しました。
リモートワークにおいてチーム開発の生産性を高めるために何かの参考になれば幸いです。