こんにちは。kamocです。 今回はフルリモートの開発チームでスクラム開発を実践した際に、どんな問題が発生したか、それらをどう改善したかについて紹介しようと思います。
こんにちは。kamocです。 今回はフルリモートの開発チームでスクラム開発を実践した際に、どんな問題が発生したか、それらをどう改善したかについて紹介しようと思います。
スクラム開発に限らず、ソフトウェアを開発していると日々様々な問題に直面します。
その問題に対処すべく、チーム内では活発なコミュニケーションが行われているのですが、コミュニケーションがうまく噛み合わず開発スピードを落としてしまったり、メンバーが「なんだかうまく行かないな」と感じていることがありました。
本記事では開発チーム内でのコミュニケーションをより良くするために心がけたこと、実践したことを5つ紹介します。 心がけ自体は当たり前のことですが、それを再確認することによって開発がうまくいったというお話です。
開発チームについて
Android , iOS のネイティブアプリを開発しているチームで、メンバーは以下６名です。
- プロダクトオーナー兼デザイナー（※プロダクトオーナー: プロダクトの最終責任者)
- スクラムマスター兼テスター(※スクラムマスター: スクラム開発の推進者)
- バックエンドエンジニア
- Androidエンジニア
- iOSエンジニア
- スクラムマスター補佐（筆者）
プロジェクト開始当初、スクラムマスター補佐は居ませんでしたが、今回はスクラム開発に不慣れなメンバーが多かったため、筆者がスクラムマスター補佐として途中参加することになりました。 ちなみに、しくみ製作所はフルリモートワークであるため、チームメンバーは各々自宅などで作業しています。
そのため、仕事上のコミュニケーションは Slack チャットと、 Google Hangout の音声通話を用いて行っています。
どんよりとした雰囲気
筆者がスクラムマスター補佐としてプロジェクトに加入して気づいたことは、スクラム開発における成果物の見える化が十分に行われていないことと、コミュニケーションがちぐはぐになってしまっていることです。
前者は本記事では割愛して、後者に焦点を当てて話を進めていきます。 具体的な事象を以下に記載します。
- 朝会(デイリースクラム)の二次会が長い(長い時は1h以上かかっていることも)
- スクラムイベント外のやりとりが多発しており、1回が長い
- 話し合いがごちゃごちゃしている
といった感じで、チームの開発のスピード感も伸び悩んでいました。
スプリントの振り返り会議で話し合い、コミュニケーションのとりかたを改善していくことによって、スプリントを重ねる度に開発スピードが上がっていくようになりました。
ここからは開発スピードを上げていくために心がけた5つのことを紹介していきます。
不具合報告はIssueテンプレに則って書こう
開発の成果物はすぐにベータ配布されて、みんなが触れるようになります。すると、触ってくれた人が不具合の報告をどんどん挙げてくれます。
しかし、せっかく挙げてくれた不具合報告には、開発者が問題を解決するために十分な情報が含まれておらず、報告者と開発者の間で何度もやりとりをするシーンがありました。
私たちのチームではこの問題を GitHub の Issue テンプレートを使用することによって解決することにしました。
Issue テンプレートを用意することによって、何を書くべきか明確になり情報不足になることが格段に減りました。 実際にチームで利用した Issue テンプレートは以下の通りです。
- 再現端末
- 発生バージョン★ ※ API の場合は発生時
- 前提条件
- 再現手順★
- 発生する現象★
- 期待する動作
- 再現率
- 備考
★は必須事項で、残りはわかる範囲で書いてもらうようにしました。
また、不要な記述は端折ってOKとしています。
例えば、発生する現象が『アプリが落ちる』に対して、期待する動作が『アプリが落ちないこと』のような自明なことを書いても仕方がありませんよね。
また、起票者が期待する動作をハッキリとわからない場合は『プロダクトオーナーで判断をお願いします』といった感じで記載することもあります。
きれいな Issue を書くことが目的ではなく、起きた現象を素早く・正確に伝えることが目的なので、このような運用にしています。
なお、上記テンプレートを ‘ISSUE_TEMPLATE.md’ というファイル名にして GitHub のリポジトリルートに設置しておくと、新規 Issue を発行する際に自動的にフォーマットが記載された状態になり便利です。 Issue テンプレート機能の詳細については以下をご覧ください。
システムについてはモノベースで話そう
実機やシミュレータの画面など、実際の成果物をを見ながらやりとりすることを、私たちのチームでは「モノベースでやりとりする」と呼んでいます。
チーム内のやりとりを観察していると、「A画面の右下のボタンが △△△ な状態の時の表示について相談なんですけど・・・」といった相談に対し、相談を受けた人が対象箇所をイメージができず時間がかかっているシーンが多くありました。
画面を見せながら「ここ」の一言で片付いてしまうのに、時間がもったいないですよね。
このような時間のロスを避けるために、私たちのチームではモノベースで話すことを心がけるようにしました。
Google Hangout で会話する時は、シミュレーターの画面や実機の画面を画面共有して話すようにしています。
実機の画面共有には、 Android では Vysor というツールを、iOS では Quick Time Player を使って画面共有をしています。 具体的な手順については以下をご覧ください。
ミーティングの参加者は“参加しないと困る人”に絞ろう
更にミーティングについて感じたこととして、参加している人数が多すぎることがありました。
例えば iOS の仕様確認の話に対して、プロダクトオーナーをはじめ、API に関連する話になるかもしれないから A さんも。 Android にも影響するかもしれないから B さんも。。。
というように、“参加した方が良い人”を集めることによってミーティングが大規模化してしまうのです。
そこで、私たちのチームでは、ミーティングに参加する人を “参加したほうが良い人” ではなく、 “参加しないと困る人” に絞ることを心がけるようにしました。
参加人数を絞ることによって、話し合い自体もスムーズに進むようになりました。
ミーティングメモを共有しよう
前項の参加者が多くなる問題に関連するのですが、聞き専メンバーに聞いてみたところ、「一応話を聞いておかないと情報をキャッチしそびれそう」という話がありました。
確かに、話し合い中で決まったことの共有が十分になされていないという場面が多くありました。
この現象に対しては、話し合いが終わったら「決まったこと」と「やること」のメモを Slack で共有することによって解決することにしました。
議事録と呼べるほどしっかりしたものでなく、簡単なメモ書きで十分です。 具体的な会議メモは以下のようになります。
- 決まったこと △△認証エラーが発生した場合の挙動はダイアログを表示してログイン画面に遷移させる
- やること ダイアログのレイアウト・文言を作成する(Aさん) iOS アプリを修正する(Bさん) Android アプリを修正する(Cさん)
この会議メモは、ミーティング参加者が内容を再確認することと、参加していない人にも結果を共有することが目的です。
聞き専で参加しなくても会議メモを見ることによって情報をキャッチアップできるようになります。
問題の階層の認識を合わせながら話そう
最後に、一番難しかった現象です。ミーティングをしたが、問題に対しての打ち手が的外れである、打ち手が延々と決まらない、というシーンがありました。
問題の難易度が高い時ほど頻繁に発生します。
解決策として、問題の階層の認識を合わせながら話し合いを進めるように意識するようにしました。 問題の階層とは以下の4つです。
- 事象: 何が起こっているのかを正確に把握する
- 問題: それによって誰がどう困るのかを確認する
- 原因: なぜそれが発生してしまうのかを検討する
- 解決策: 以上を踏まえてどういった施策を行うか決定する
議論がうまく噛み合わなくなってしまうのは、たいてい事象や問題の認識がズレた状態で解決策を決めようとしている時でした。
階層2の問題を話し合うことによって、実は気にする必要が無かった（そもそも問題ではなかった）というケースも多くありました。参加者一人ひとりがこれを意識することによって、ちぐはぐな話し合いを減らすことができました。
まとめ
本記事ではフルリモートでスクラム開発を実践している中で発生したコミュニケーション問題と、それに対する心がけについて紹介しました。
書いてある内容については目新しいものではなく、当たり前のことかもしれません。
しかし、チームメンバー全員がこれらを心がけることによって、チームの雰囲気も良くなり、開発自体もスピーディーに進むようになりました。
一人ひとりが当たり前のことをちゃんとやることが自己組織化したチームに近づけるために大切なのではないかと思います。