アバナードのアジャイルコーチ・高橋直樹氏が明かす 「リモート環境下で立ち上げたスクラムチームの苦労話」(前編)

イベント
新型コロナウイルス感染症の対策として、多くの企業がリモートワークを導入している。アバナードでも全員が在宅勤務へと変更になった。リモートワーク環境下でアジャイル開発経験のないメンバーを集め、スクラムチームをどう立ち上げ、うまく軌道に乗せていったのか。その「苦労話」と手法をアバナードでアジャイルコーチを務める高橋直樹氏が語った。
アバナードのアジャイルコーチ・高橋直樹氏が明かす 「リモート環境下で立ち上げたスクラムチームの苦労話」(前編)

動画アーカイブ

●登壇者プロフィール

アバナード1

アバナード株式会社 アジャイルコーチ 髙橋 直樹氏
「社内の誰よりも速く確実にデリバリーする」と豪語する元バイク便のエンジニア。独立系SIerにて主に金融、政令指定都市などのシステム開発に従事したのち、エッジデバイスからSaaSまでのワンストップサービスを提供するベンチャー企業にてプロダクトマネジメントや研究開発に従事。アバナード入社後はデジタル関連案件の開拓に取り組む傍ら技術系セミナーや勉強会への登壇等、情報発信に励む。

スクラムはリモートワークでも十分できる

新型コロナウイルスにより、私たちの生活は一変した。仕事はどうなるのか、日用品の買い出し以外は外出できないなど、毎日が不安の日々。もともと人類の歴史はパンデミックとの闘いだ。そこで考えるのはこの生活はもとに戻れるのか、もしくはどう変化していくのかということ。

マイクロソフト創業者のビル・ゲイツ氏も2015年のTED Talksで「最も多くの死者を出す恐れのあるモノは戦争ではなく、感染症のパンデミックだ」と言っている。

自粛生活が始まった当初は「今は我慢の時」という心境が、だんだん自粛疲れや将来の不安が大きくなってきた。やがて新たな日常に適応していく中で、「これはむしろチャンスなのではないか」と思えるようになったと髙橋氏は振り返る。

「これまでの発想を変えることにしたのです。働き方改革と言われていますが、そもそも改革とは従来基盤を維持した内部変革のこと。プロセスそのものを変えなければ仕事の量は変わりません。つまり、改革ではなくて、今をどう進化させていくかという考え方が重要だということに気づきました」

髙橋氏は、この数カ月間、フルリモートで仕事をしてわかったことがあるという。

「私たちはこれまでも在宅勤務が推奨されていましたが、この自粛期間中は全員がフルリモートで仕事をすることになりました。これまでの中途半端なリモートより、全員がリモートになったことが功を奏したのです。全員の条件が揃うことで、みんなでやろうという意識が向上。また知識や情報が一部の人たちで断片化しないために工夫する意識も自然と発生しました」(髙橋氏)

スクラム開発をしていく上で、今まで通り立ち上がりで苦労するところはあったが、リモートだから特別困った、ということは増えていないと語る髙橋氏。

これまではチームは1カ所に集まるべきだという定説があった。しかし、フルリモートでも、十分やれているし、スクラムはリモートワークを効率化させる。むしろリモートだからこそスクラムなのだと強調する。

リモートワークに関する一般的な懸念として、一体感の低下、コミュニケーション不足などチームワークがうまく働かない、部下がサボっていないか心配、働き過ぎるなどが挙げられる。だが、これらの懸念は、スクラムの3つの柱(透明性、検査、適応)と5つのバリュー(確約・勇気・集中・公開・尊敬)を意識していると解消できる。

例えば、ウォーターフォールとスクラムでは、メンバーの意識と責任感が徹底的に異なる。一般的なウォーターフォール開発の場合、プロジェクトマネジャーが見積もりしてWBSを出す。それに基づき、メンバーをアサインする。アサインされた人はやらされている感があったり、自分で見積もっていないのでこんな期間ではできないなど、不平不満が溜まったりもする。

一方、スクラムの場合は開発チーム全員が見積もり、それに基づいたタスクを自分たちで選択する。つまり自発的に行動するので、失敗に対しても自分たちの責任という当事者感もあるし、一体感も生まれる。

アバナード5

メンバー全員がスクラムやアジャイル開発未経験

では、チームをどう立ち上げていったのか。

「最初の悩みはスクラムやアジャイルの実戦経験がないメンバーが集まったこと。仕事なので、トレーニングしている余裕もありませんし、オンラインでトレーニングしたところでどこまで伝わるか不安もありました。もう一つの悩みは働く環境(ツールやクラウド環境など)をどうするかということです」(髙橋氏)

そもそもスクラムは経験主義。つまり「習うより慣れろ」。いきなりスプリントを1週間にして、やらせることにした。1週間にするメリットの第一は、仕事のリズムを覚えやすいこと。短いスパンでイベントが来るので、どのタイミングで何をしなければいけないかが、曜日感覚でつかめるのでわかりやすい。

習うより

またスプリントを短い間隔で振り返れば、改善までのスパンも短くなる。そのため、非常に効果を生みやすく、自分たちの成長を感じやすいこともメリットだ。

一方のデメリットは、PBIの大きさ次第ではスコープの調整が難しいこと。実際、取り扱うものの性質によっては、1週間ではうまくいかないこともある。1週間しかないので、結果上がってくるインクリメントが少なく、スプリントレビューもあまり見せるものがないなど、もの足りない状況になることがある。さらに、最初は慣れるまでがとにかく忙しいなどのデメリットもある。

「このようにデメリットもありますが、実際にトレーニングしながら仕事をうまく回していくためには、スプリントを1週間にするのがお勧めです。慣れてきたら、スプリントを倍の長さにすればいいのです」(髙橋氏)

続いては、働く環境のツールの整備について。リモートワークにより、顔を見ながら会議や、みんなの壁、ホワイトボードを失った。しかし、これらはすべてデジタルに置き換えが可能だ。

アバナード6

「当社ではTeams、Azure DevOps、MS Whiteboardに置き換えました。Teamsで環境にとらわれないコラボレーション・情報共有が可能になり、Azure DevOpsは開発ライフサイクルをサポートしてくれます。MS Whiteboardは単なるホワイトボード機能だけではなく、ブレーンストーミング、振り返りなど用途に応じたテンプレートも多数提供しており、リモートワーク環境でも効率的なコラボレーションが可能になるというツールです」(髙橋氏)

Teamsを活用する際は、落ち着いて相手の話を最後まで聞くことや、発言を遮らないように挙手の機能を活用すること。それでも伝わらないときはホワイトボードを使ったり、個人間でのやりとりはなるべく避けることなどがポイントだという。

Azure DevOpsを活用するポイントは、タスクの更新漏れがないようにすること。また、スクラムはプロマネがいないので、定期的に他人の進捗を気にしてすることも大事です(停滞している場合はみんなでフォローする)。

実績については、良くも悪くも正直に報告すること。実績を過小報告すると自分たちの実力が測れず、今後の予測が立てられなくなるからです。さらにディスカッションの内容はチケットに残すこと。書きながら会話するのがベストでしょう」(髙橋氏)

活用のポイント

ホワイトボードの活用ポイントは常にスタンバイしておくこと。これは頭の整理にもなる。

では、1週間のスプリントでどのような問題が起こり改善していったのか。イベントごとにその具体策を紹介された。

「まずはスプリントの準備をします。みんなでビジョンを共有し、最初のプロダクトバックログを作成します。準備完了の定義や完成の定義を行い、環境整備をする。準備はきりがないので深追いしないことが大事です」(髙橋氏)

初めてバックログを準備する際の問題点と改善案

未経験者が初めてバックログを準備する際、第一の問題点は、機能一覧になってしまうこと。この改善策としては、ユーザーにとって価値あるストーリーを考えること(ユースケースでもよい)や、ストーリーマップを使って全体を把握することが挙げられる。

第二の問題点は、PBIが大きすぎること(抽象的すぎる)。この改善策としては、リリース可能な最小単位に分割することがポイント。ここでも機能一覧的に考えがちなので注意が必要だ。

第三の問題点は、優先度の間違い。作り手の思いで何から作るかではなく、どんな価値から届けるべきか?事業にとってROIを最大化するにはどうすべきか?を考えることが重要になる。

だが、価値が高いモノが必ず正義というわけではない。技術上やむを得ないものや依存関係を考慮する必要がある。優先度を変えるためには、開発チームとプロダクトオーナーが話し合うことが必要になる。

第四の問題点はアーキテクチャーを固めたがること。最良のアーキテクチャーが最良の価値を提供するとは限らない。アーキテクチャースライスという考えを使って実装し、リファクタリングを繰り返すことがお勧めだという。

アバナード

スプリントプランニングに関する問題

スプリントプランニングには、時間がかかりすぎる、調査してみないと見積もれない、計画通りに進まないという問題がある。ではどうすればスプリントプランニングをスムーズに行えるか。

まずはPBIをなるべく小さくすること。次にバックログリファイメントを必ず行うこと。チームのキャパシティの最大10%程度までを確保し、必要に応じて技術的スパイクを行う。そして、直近対象となりそうなPBIをReadyにしておく。

「そのための準備完了の定義も忘れないことです。またReadyになっていないPBIは選んではいけません。スプリント内に不確定要素が入ることで、計画が狂うからです。

最低でも次のスプリント分はReadyにしておくこと。あまりに先までやり過ぎても、その頃には状況が変わっていたりするので、2スプリント分ぐらいがちょうどよいでしょう」(髙橋氏)

アバナード

日々のコミュニケーション問題

プロジェクトオーナー(PO)と開発チームのイメージがずれたり、メンバー間の認識のずれ、会話がかみ合わないなど、日々のコミュニケーション問題も発生する。

「一般的にFace to Faceのコミュニケーションが一番良いと言われていますが、本当にそうでしょうか。アリスター・コーバーンさんによると、コミュニケーションには温度があり、最も効果も温度も高いのは二人がホワイトボードを介して会話することだと言っています」(髙橋氏)

F2F

一番、温度も効果が低いのは資料だけを送りつけること。しかしながら、顔を合わせて会話してもうまくいかないこともある。

「そうした場合、私は『書きなさい』と言っています。アジャイルはドキュメントを書かないという誤解がありますが、これは価値の重きをどこに置くかという考え方の話で、ドキュメントに価値がないとは言っていません。つまり、何を書いて何を書かないかを考えることが重要なのです」(髙橋氏)

そのポイントとしては、誰が必要なドキュメントで、いつ、どのくらい(量、質)ほしいのかなどを書くこと。リモートであれば、なおのこと書くことは重要になると強調する髙橋氏。

「そこでお勧めなのがデジタルツールを活用すること。私たちはTeamsからMicrosoft Whiteboardを連携。液晶タブレットとデジタルペンを使うことで、会話の空中戦を防いでいます。デジタルのペンを使えないときは、紙に手書きしてカメラで映してもらいます。こうすることで、意思の疎通が図りやすくなります」(髙橋氏)

アバナード

⇒「リモート環境下で立ち上げたスクラムチームの苦労話」(後編)に続く

関連するイベント

おすすめのコラム