リモートワークでスクラムを効果的に運営する方法

スクラムは、最も人気のあるアジャイルソフトウェア開発手法です。 Coding Sansが2019年に実施したソフトウェア開発の状態に関するレポートでは、回答者の60.58%がスクラムを使用し、35.4%がカンバンを使用し、19.71%がアジャイルモデリングを使用していると回答しました。 スクラムの人気が高まっているのと同時に、リモートで作業する開発者の数も急増しています。OWLLabsによる2019年のリモート作業の現状についてのレポートによると、米国の労働者のほぼ3分の2が少なくとも一度はリモートで働いたことがあり、ほぼ半分が週に一度以上リモートで働いています。 TecLAのリサーチでは、世界でリモート勤務する職業トップ5の中にソフトウェア開発者が入っていることが報告されています。 また、ソフトウェア開発者の仕事に従事する人は2026年までに24%増加すると見込まれています。

スクラムは本来物理的に一カ所に集まるチームのために作られた開発手法であり、毎日スタンドアップ・ミーティングを開いたり、スプリントレトロスペクティブ(振り返り)という情報共有の機会が含まれています。そのため、リモートで働くソフトウェア開発者がスクラムを使って開発するには、スクラムの方法を変えなければなりません。

ソフトウェア開発においてスクラムを導入すると、以下のような利点が得られるでしょう

  • 製品リリースを加速させる
  • 製品の品質とチームの生産性を向上させる
  • コストを削減させる
  • チームの士気を向上させる
  • 顧客満足度を向上させる
  • 複雑なタスクの実行を可能にする
  • 関係者により透明性を提供する

リモートワークには多くの利点がありますが、リモートチームがスクラムを行う場合、スクラムにおける各種イベントや情報伝達を効果的に実行し、リモートチームであることで生じる課題を克服するという新しいチャレンジがあります。

私たちスリークは、数カ国に分散したチームを持つソフトウェア開発企業として、リモートのスクラムチームが直面する問題を過去に経験しました。 以下に、リモートであることによって悪化しがちな問題とそれに対するアイディアをいくつか挙げていきます。

Photo by Sincerely Media on Unsplash

スクラムを妨げるリモート作業の5つの困難

1.フィードバックの遅れ

例えば米国の開発チームがアジアにいる開発者に何か質問をする場合、現地が朝になるまで返事を待たなければならないことがあります。 返事の遅れは、開発プロセスの遅れを引き起こします。5分のチャットで済むはずの同僚とのチャットが、現地が週末に入ってしまったために週明けまで3日待たなければならないということも起こりえます。

2.困難なスケジュール調整

各開発者が時差のある場所で勤務している場合、全員が同時に参加できる会議を開くことができる時間帯は限られます。時には片方のチームが他の開発者に合わせて、通常の勤務時間外に作業をせざるを得ないこともあるかもしれません。3つ以上のタイムゾーンがある場合、スケジューリングはさらに大きな課題となるでしょう。 リモートチームとの間に時差がない場合でも、同じオフィスにいれば数分で済むような会話をするためにスケジュール調整をしなければならないこともあります。

3.プロセス統一のためのマニュアル作成

作業プロセスを記録したマニュアルの作成は、多くのチームが苦労する課題です。 しかし、リモートチームの場合には、自分が担当した作業を他のチームに引き継いだり、他のチームから引き継いだりする際に、作業プロセスを記録したマニュアルが必須です。ドキュメントが不十分であったりコミュニケーションが不足していれば、チームが作業を進めるのは難しいでしょう。マニュアルの作成は退屈で時間がかかるのに加えて効果も見えにくいため、担当者には面倒な作業と思われがちです。

4.ツールの不備

リモートチームと一緒に仕事をするためには、さまざまなツールを活用すべきです。テレビ会議や電話、メール、コラボレーション・ツールなどは、リモートチームとのコミュニケーションと作業プロセスを容易にしてくれます。 このようなツールを使うには、堅牢なインターネット接続とそれに必要なハードウェアとソフトウェア、および利用者のためのトレーニングなど、環境を整える必要があります。さらに、チームが特定のツールを使用するにあたって、それに関係するガバナンスルールまたは社内標準を決めておく必要があります。

5.言語・文化的障壁

世界の別の場所にいるチームと作業する場合、言語や文化の違いにも配慮する必要があります。コミュニケーションが不十分であるために、マナーや言葉選びなどの些細なことが大きな誤解に発展する可能性があります。 東ヨーロッパ、アジア、インドなど英語が主要言語ではない場所で開発者を雇用する場合、彼らのコミュニケーション能力や採用する側のコミュニケーションギャップに対する管理・処理能力が、採用方法や働き方に影響を与えるでしょう。 

困難を取り除くための4つのアイディア

1.テレビ会議の活用

短時間で済む内容であれば、わざわざ会議をスケジュールする代わりに、オープンな双方向ビデオフィードを常時接続することをお勧めします。これにより、チームメンバーは自分のオフィスからテレビ会議システムを通していつでも別のオフィスのメンバーに質問ができます。スリークではそれ専用にコンピューターと画面を使用し、ビデオ・オーディオを生配信することで、画面を通して物理的に近くにいるのと同じ感覚でいつでも会話ができるようにしています。

2.情報共有にボットを活用

開発チームが毎朝定例会議をする場合、基本的にはチームのいる場所で行うでしょう。一カ所に集まって会議するのが理想的ですが、リモートのエンジニアやマネージャーが別の場所から参加せざるを得ない場合もあります。 また、毎日の定例会議では議事録を残すことはほとんどなく、後で困ることがあります。

これらの問題を解決する方法として、私達は毎日の定例会議を容易にするSlackチャットボットを開発しました。ボットはSlack上で各チームメンバーの設定した時間帯にいくつかの質問を行い、その回答を記録し、他のチームメンバーにも共有します。この機能を使うことで、各チームメンバーは前日までの作業内容を振り返ることができるだけでなく、作業内容をチームに共有することができます。

3.データ統合ツール

多くのソフトウェア開発チームは、生産性、効率性、利便性を追求して複数のツールを利用しています。 しかしこれらをうまく使いこなすことは難しく、ツールの数は増え続け、真に重要な事が各ツールからバラバラに送られてくるデータに埋もれてしまいがちです。

Sleeekはそのような悩みを解決するために開発されました。Sleeekは、Jira、GitHub、BitBucket、Slackなど、開発チームが日常的に使用する多くのツールから集めた情報を一カ所に集約し、すべてのデータを分析し、プロジェクトの現状理解に役立つダッシュボードを提供します 。

4.コードの品質

コードの品質は、すべてのリモート開発チームのマネージャーの関心事です。特にエンジニアが固定されておらず、人員の出入りが比較的多い分散型チームの場合、フォローアップして効果的なレビューを行い品質の向上に繋げるのは簡単ではありません。物理的、時間的隔たりにより、コードレビューの待ち時間が長くなりがちです。分散チームにおいてもコードレビューのサイクルを上げるためには、Sider のような自動ソースコードレビューの導入を検討してみてください。些細なフォーマットエラーや、チームでよく発生する指摘に関しては、24時間・365日、Sider が対応可能です。貴重な人間のレビュワーの時間は、より本質的なロジックの精査に使うことができます。

上記のリモート・スクラムを円滑にするアイディアは私たちのチームで使われているものですが、他にも良い方法はあるでしょう。ぜひ以下のコメント欄であなたのアイディアをシェアしてください!