＊本コラムは、技術評論社「Software Design」2020年12月号に寄稿したコラムを掲載しています。

コロナ禍におけるアジャイル開発の今

新型コロナウイルスの世界的な流行により、公共交通機関や職場での感染を避けるために、ソーシャルディスタンスの確保が求められています。緊急事態宣言が出されてから半年以上が経過し、自宅での作業が可能な職種のほとんどは、リモートワークができる環境への移行を終えたように見えます。とくに情報通信業においては、今年5月29日の調査時点で、従業員のリモートワーク実施率が63.9％と、全業種平均の 25.7％に比べてリモートワークの普及が進んでいることがわかります^注1。

当社においても、情報セキュリティ対策が済んだ職場から順にリモートワークへの移行が進んでおり、現在では毎日通勤しているエンジニアは皆無です。そして、それはアジャイルでのソフトウェア開発を行っている筆者らの部署においても同様です。
当初はリモートワークでのアジャイル開発は大半のチームが初めてで、チームが同じ拠点に集まって行っていたことを、テレビ会議システムやチャットツールを駆使してなんとかリモートで実現しようと試行錯誤していました。現在はリモートワークへの移行も落ち着き、今までのやり方をオンラインで代替できているアジャイル開発の現場がほとんどです。
しかし、一方で「なんとなくパフォーマンスが落ちた」という声がしだいに聞かれるようになりました。

それは、今までのやり方と比較するとリモートワークが非効率的である、と直感的に考えている人が多いからではないかと思いますが、ではなぜ非効率的なのか、どうすれば効率的にできるのか、このような問いに明確な答えを出せるでしょうか。それを知るためには、リモートワークを前提としてもう一度アジャイルの原則に立ち戻り、やり方を見直す必要があります。
本記事では、アジャイルの原則に沿って、リモートワークにおけるアジャイルのパフォーマンスを向上させるための工夫を紹介します。

アジャイル原則のおさらい

アジャイルソフトウェア開発宣言

アジャイルを実践している方は必ず一度は目にしたことがあるであろう「アジャイルソフトウェア開発宣言^注2」（以下アジャイル宣言）ですが、これにはアジャイルを実践するうえでの心構えや、とるべき行動が示されています。
アジャイル宣言の中でもリモートワークという特性をふまえたときに、焦点となる項目について考えてみましょう。アジャイル宣言には
“プロセスやツールよりも個人と対話を、”
とあります。また、アジャイル宣言に付随する「アジャイル宣言の背後にある原則^注3」には、
“情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。”
ともあります。
アジャイル開発ではコミュニケーションを重視していて、それはフェイス・トゥ・フェイスで行うことが求められているのがわかります。果たしてリモートワークでこれらのことを守りながら、開発を進めていくにはどういった工夫が必要なのでしょうか。

スクラム開発の概要

ここでスクラムの概念についても触れておきます。スクラムは不確定な要求や変化の激しいソフトウェア開発に対応するためのフレームワークです。技術的な要素は含まれず、チームで仕事を進める際に共通して適用できるものです。
最低限のルールセットとして、スクラム開発は下記の要素から構成されます。

スクラムについてはさまざまな書籍・記事がありますが、公式なドキュメントとしてはスクラムガイド^注4がありますので、まずはそちらをご覧ください。18ページ程度のドキュメントですが、スクラムのルールがすべて載っています。　流れを簡略化して説明すると、計画→開発→披露→振り返りを繰り返してプロダクトを改善し、より良い価値を生み出していくのがスクラムです（図1）。

図1　スクラムの手順^※

リモート×アジャイルを始めて気づいた課題

筆者らの周りでは、アジャイル開発手法の中でもよく知られている手法の 1つであるスクラム開発でプロダクトを開発しています。当時は意識すらしていませんでしたが、今まではチーム全員が同じ拠点で、対面での開発を進めていました。
リモートでスクラム開発を始めてから、気づけばすでに半年以上が経ちました。今でこそリモートワークに対して違和感はなくなりましたが、そこへ至るまでにはリモートワークならではの壁がありました。
これまでは、次のような環境でスクラム開発をしていました。

このような状況でリモートワークでのスクラム開発を始めると、すぐに次のようなコミュニケーションの課題が浮かび上がってきました。

今までは、スクラムチームが同じ拠点に集まってフェイス・トゥ・フェイスで仕事をしていたので自然とメンバー同士が話し合っていましたし、ランチタイムやオフィス内ですれ違うときなど、どこでも気軽にコミュニケーションをとっていました。どれもオフラインのときはあまり意識していなかったことです。

リモート×アジャイルならではの改善とは

ホントに伝わってる？チームの共通理解を深めよう

●会議は会話とチャットの併用で

スプリントプランニングでは、そのスプリントで実現すべきプロダクトバックログを決め、やるべきことをタスクに分解してスプリントバックログを作成し、それをカンバンなどで見える化します。

筆者らのプロジェクトではプロダクトバックログは JIRAで管理していますので、プランニングのときはプロダクトバックログのチケットを皆で見ながら内容と受け入れ基準を再確認します。そして、ホワイトボードを使ってシーケンス図やクラス図を書きながらアーキテクチャを明確化→やるべきことをタスク化→タスクの完了条件を決める→時間を見積もり、スプリントバックログに落とし込む、という作業を行っていました。タスクを洗い出してスプリントバックログにするまでに4～5時間、長いときは1日かかっています。その時間のほとんどはディスカッションに費やされます。

リモートワークになってからも同様で、基本的に Web会議でJIRAのチケットを見ながら進めていました。しかしWeb会議だとオフラインでプランニングをやっていたころと比べ、議論が少なくなった気がします。前述したように、このタスクを分解する作業には結構な時間を割いているのですが、時間が進むにつれ、段々と発言する人が特定の人に限られていき、発言しない人が同意しているのか、それとも何か意見があっても言えていないのかがわからずに議論が進んでしまうことがありました。これでは皆で同じゴールに向かってプロダクトを作るのが困難になってしまいます。

このような課題に対して、皆が意見を持っていないのが原因なわけではなく、ほかの人の状況が把握しづらく発言するタイミングが難しいのが原因ではないかと考え、SlackによるチャットコミュニケーションをWeb会議と併用しました。誰かの発言中は、それに対して「こういうケースは？」「こっちのほうがいいんじゃない？」といった意見はいったんSlackにポストしてもらって、発言者の区切りのいいタイミングでSlackを見返して、ひとつひとつ拾いながら議論していきました。これによって発言する順番も明確になりましたし、各メンバーの意見を拾うことができるようになりました。プランニングだけに限ったことではありませんが、チームの全員から意見を出してもらう工夫がオフラインのとき以上に必要になってきます。

●アイデアはオンラインホワイトボードで共有

会話だけでなく時にはホワイトボードを使って、マインドマップやブレインストーミングなどを行い、メンバー間で意識合わせをすることもあると思います。筆者らのプロジェクトでも、皆でああでもないこうでもないとホワイトボードに書きながらアイデアを共有しています。
リモートワークになってからは、miro^注5を活用しています。miroはオンラインで共同作業ができるホワイトボードツールですが、マインドマップやブレインストーミングのほか、カスタマージャーニーマップやプロダクトロードマップ、フローチャートなど、50以上のテンプレートが使える便利なツールでもあります（図2）。

図2　miroを使用したディスカッション

オンラインホワイトボードは慣れるまでが大変ですが、アナログのボードと違って、書き直しや整理が楽だったり各種アプリと連携ができたりと、効率面でもメリットがあります。

スクラムイベントに欠かせない小道具をオンラインで使う

●カードがなくてもプランニングはできる

筆者らのプロジェクトではスプリントプランニングの際、プランニングポーカー^注6でストーリーポイント^注7を見積もり、実現するプロダクトバックログを決めていました。しかしリモートワークではそういったツールは物理的に使えません。
そこで、オンラインのプランニングポーカーを使うことにしました。オンラインツールにもOSSですとHatjitsu^注8やFire Poker^注9などがありますが、単にカード代わりとして使うならシンプルで簡単な Hatjitsuが良いでしょう。
また、planningpoker.com^注10を使えば、JIRAで作成したストーリーを読み込んで見積もりを行い（図3）、見積もったポイントをJIRAのストーリーに対して反映するといったこともできます。筆者らのプロジェクトではバックログをJIRAで管理していますので、planningpoker.comのほうを採用しています。
いずれのツールを選ぶにしろ、Webでのプランニングポーカーとなるとほかのメンバーの顔色をうかがうこともできないので、オフラインで行うよりも正直な見積もりができそうです。

図3　planningpoker.comを使ったプランニングポーカー

●ホワイトボードもふせんも

ホワイトボードとふせん紙を使ってカンバンでタスク管理を行ったり、ホワイトボードにシーケンス図やクラス図を描いてアーキテクチャを検討したりと、割とアナログなツールを使ってスクラム開発をしている方も多いと思います。筆者らのプロジェクトでもスプリントバックログを作成する際、以前はホワイトボードを使ってシーケンス図やクラス図を描いてアーキテクチャを明確化していました。また、レトロスペクティブはホワイトボードとふせん紙を使い、 KPT（Keep、Problem、Try）のフレームワークに沿って振り返りを行っていました。
オンラインホワイトボードのmiroの活用については前述したとおりですが、ちょっとした絵を交えて描きたいときは、Google Jamboardがシンプルで操作も直感的ですので、そちらも活用しています（図4）。

図4　Google Jamboardを使ったレトロスペクティブ

●ペアプロだって平常運転

筆者らのプロジェクトでは、ペアプロ（ペアプログラミング）もリモートワーク以前から変わらず実施しています。それに欠かせないのがTandem^注11というバーチャルオフィスツールです。Zoomは会議ごとに接続をつなぎ直す手間がかかりますが、Tandemはアプリを立ち上げておけばすぐに会話をするルームに入れますし、オンライン中のメンバーが今どんなアプリを操作しているのかが確認可能で、「〇〇さん、今Zoomがアクティブだ。会議中かな、あとにしよう」という具合に、相手の都合に合わせやすいです。また、 Slackと連携していれば相手にワンクリックでSlack通知を送信でき、思い立ったときにすぐ会話に移行できます。Tandemでペアプログラミングをする利点は、共有している側のカーソルだけでなく、共有されている側のカーソルも表示されるところです。ソースコード内の指摘したい部分を指しながら、「ここのclassは……」といったように、視覚的に説明することができます（図5）。当然ビデオ通話も可能ですし、Tandemを使用していないときはとてもコンパクトなウインドウですので作業の邪魔になることもありません。

図5　Tandemを使ったペアプログラミング

今何してる？チームから孤立したメンバーを助けたい

チャットを活用してメンバー同士の透明性を高める

“デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。”
と、スクラムガイドには記載されています。デイリースクラムはスクラムイベントの中でも唯一、毎日実施するものです。互いの状況を共有することで、スクラムチームの現状を把握する重要なコミュニケーションの場となります。
筆者らのプロジェクトでは、毎朝自席周辺でJIRAのカンバンとバーンダウンチャートを見ながら行っており、リモートワークになってからは各自が自宅からZoomで実施するように変わりました。同じ拠点にいれば、メンバー間の対話や、デイリースクラムでの表情や話し方を見てメンバーの状況を察することができていました。

しかし、Web会議でのデイリースクラムは、タスクの状況は把握できてもメンバー自身の状況は互いに把握しにくくなります。筆者らのプロジェクトでは、知らぬ間に疲弊しているメンバーがいたり、問題を抱え込んでいるメンバーがいたりと、これまで起こらなかった個々の孤立が見えないところで起きており、問題に挙がることが多くなりました。当初は、ZoomのカメラをONのまま1日中つなげっぱなしにして改善を試みましたが、状況は改善しません。従来のように自然とメンバー同士の対話が生まれることを期待しましたが、必要なときに必要な会話しか生まれず、むしろメンバーにとっては1日中つなげっぱなしという状況がストレスになってしまっていました。

それから試行錯誤していく中で少しずつチームのコミュニケーションの形は変化していき、新しい文化が生まれました。それは、業務連絡がメインだったチャットの使い方を変え、雑談や独り言をメインにしたことです。気軽に全員がなんでもつぶやくので、対話から生まれていたアイデアや問題解決などが、チャットからも生まれるようになりました。お互いの独り言にメンバーが絡んでいき、その中で「ちょっと話します？」と気軽に、しかし必要なときに通話をすることが発生します（図6）。
「必要なときに必要なことしか会話しなくなる」から、「必要なときに必要な会話で済む」ととらえ方が変わり、コミュニケーション負担の軽減につながりました。フェイス・トゥ・フェイスは、「同じ拠点での働き方」において最も効果的で効率的な手段だっただけで、リモートワークで働くうえではフェイス・トゥ・フェイスに近い手段でなくても良いのです。

図6　Slackで雑談ベースのコミュニケーション

朝夕に分けてデイリースクラムを実施してみる

筆者らのプロジェクトではデイリースクラムを分割して実施しています。
通勤や移動もなく1日中自宅で作業していると、ついつい遅くまで仕事をしてしまうメンバーも多かったので、デイリースクラムを朝と夕方の2回実施することにして、朝は「今日やること」を、夕方は「今日やったこと」を共有する場にしました。「おはよう」と「おつかれさま」の挨拶を兼ねることで、業務の開始と終了を意識するとともにチームで働いていることも意識できます。

なんでもリモートのせい？そんなことはない！

形骸化したイベントにメスを

リモートワークに移行して出てきたコミュニケーションやツールの課題は前述のとおり改善しましたが、新たな課題も出てきました。たとえば、オンラインで振り返り（レトロスペクティブ）を行う際の課題が挙げられます。
次のスプリントでの試みや改善について決めるとき、オフラインのときは、ホワイトボードとふせん紙を使い、おもにKPTで振り返っていました。リモートワークになってからは、Google Jamboardを使って実施していました。しかし、Problemはリモートワークに関することばかりで、チーム活動に関する本質的な課題や改善策が挙がらなくなってしまいました。

そこで、Random Retrospectives^注12というサイトを活用しました。これは22個の振り返りの手法を、ルーレット式でランダムに選び出すツールです。決定した手法の進め方も表示されるので、初めて見る手法でも戸惑うことはありません。狙いとしてはKPTで形骸化しかけているところに新しい視点を取り入れることで、振り返りの観点をあらためて再確認してもらうことです。毎回新しい手法でやることがメンバー間で現状を確認しあうきっかけになるので、コミュニケーションが不足しがちなリモートワークにおいては良い効果が得られると思います。

今こそ組織を巻き込んだ変革が必要なとき

リモートワークになって自宅で作業をしていると、「Web会議中に相手の声が聞こえない」という不満や、あるいは「自分の声が届いていなかったり、タイムラグがあったりする」といった通信環境的な不満が出てきます。また、コミュニケーションを改善するためにリモートならではのいろいろなツールを駆使していると「モニターが1つでは効率が悪い」といった不満も聞かれます。

通信環境やデスク、モニターなどは人によってまちまちですし、いろいろと制約もあるでしょう。開発効率にも関係してきますので解決すべき課題ではありますが、予算なども絡むところですのでチームだけでは解決が難しい場合もあるかもしれません。今後コロナ禍の影響がどこまで及ぶかは予測できませんが、リモートワークという働き方がある程度定着していくことを考えると、組織全体として取り組んでいかなければいけない課題といえます。

まとめ

アジャイル宣言の背後にある原則にも、
“情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。”
とあるように、アジャイルでは直接対話することが大切です。ですので、最初はフェイス・トゥ・フェイスの雰囲気をリモートワークで再現することにこだわっていました。Web会議ツールを常時つなぎっぱなしにしてカメラをONにしておけば、よりリアルな環境に近づき、コミュニケーションは円滑になるだろうと思っていました。

しかし筆者らのプロジェクトにおいてその効果は現れず、むしろコミュニケーションに負担がかかってしまっていました。筆者らのチームの場合、チャットをベースに必要なときに会話をするくらいが最適でした。要は、問題が発生したらすばやくチームで共有して解決できる環境にさえなっていればよかったわけです。どういったコミュニケーションが最適かはチームの文化・制約によって異なりますし、抱えている課題も違うでしょう。ですので、メンバーに負担とならず、効率の良いコミュニケーション方法を考えるのがよいのではないかと思います。

また、各スクラムイベントなどを通してチームの様子をうかがい、コミュニケーション不全になってないかをチェックして随時改善していくことも必要です。
リモートワークへの移行は、アジャイル開発の手段を見つめ直すいい機会になりました。常日頃からチームが100％の力を発揮できる状況にするにはどうすれば良いのかを考えてきましたが、「自分たちのベストなパフォーマンスが出せているか？」「いいプロダクト作りができているか？」そういったことを考え続け、アクションを起こし続けるのはリモートワークでも変わりません。状況が変われば手段も変わるのは、当たり前と言えば当たり前なのかもしれません。むしろリモートワークでの働き方が不安かつ不安定だからこそ、働き方に対して疑問を持って改善していくことができ、アジャイルのマインドを実践できたように思えます。筆者らのチームの場合、リモートワークであることを前提としたコミュニケーション環境を築くことで、同じ拠点で働いているときと同等のパフォーマンスを出せるようになりました。

スクラムは透明性・検査・適応の3本柱に支えられています。チームの現状や問題点を見える化して透明性を高め、作成物やスプリントのゴールを繰り返し検査することで問題点を見つけ、状況に適応するために改善策を考える。この3ステップこそが、リモートワーク下でのソフトウェア開発においてはより必要とされるのではないでしょうか。
　リモートワークでは働く場所がばらばらなため必然的に「透明性」が求められ、働き方自体を「検査」し、最大の能力が発揮できるよう「適応」していかなければなりません。そう考えるとアジャイルこそが、この時代の働き方に適応していく手段となり得るのではないでしょうか。