はじめに
EXNOA プロダクト本部の小峰です。今回は、自身のアジャイルチームビルディングおよびプロダクト開発の経験から、他チームへのスクラム支援を行った経験についてお話します。経験とはいってもまだ支援中の状況であるため、スタートからこれまでと、これからどうしていくか、といった辺りを書いています。
スクラムで時間経過と共に重視すべき領域の変化といった背景や、支援の必要性と具体例などを記載したことで少し文章量が長くなってしまいました。しかし現在すでに組織の課題やチーム組成に立ち向かっている方や、組織づくりやチームビルディング、チームマネジメントの経験を活かす場を探している方にとって、少しでも参考になるように心がけて書いたつもりですので、ぜひ最後までお読みいただけると嬉しいです。
自分は何者か
EXNOAで運営してるDMM GAMESのプラットフォーム開発に携わる部署に所属し、Managerを務めています。また、グローバルサービス開発に携わる部署を兼務しています。
2019年10月に入社し、以後一貫してディレクターとして立ち回っています。ある日、新しいサービス開発決定に伴いチームが編成され、そこにアサインされました。
厳しいスケジュールが求められたプロジェクトですが、随時スコープを調整しスケジュールを担保するために、それまでは中途半端だったスクラム開発をきちんと取り入れようと決め、スクラムマスターとしても活動するようになり、その結果、無事リリースまでたどり着くことができました。この辺りのお話については過去に「DevLead by DMM Group #2 を開催しました！〜アジャイル開発編〜」でもお話させていただいたことがありますので、ご参考までに。
チームメンバーはもちろんのこと、多くの関係者のご協力のおかげで達成することができましたが、スクラム開発が比較的有効に作用した部分もたくさんあったプロジェクトだったかなと思います。
そんな経験を踏まえ、現在は所属部署のManagerを担当しつつ、プロダクト開発としてはプロダクトオーナーも担当しています。
そして最近はそれらに加え他チームのスクラム支援に携わっています。
なぜ支援が必要なのか
アジャイル開発手法のひとつであるスクラムではスクラムマスターというロールがあります。他のロールであるプロダクトオーナー、開発者も重要なロールですが、チームがスタートした段階ではスクラムマスターが最も重要です。
ここで、スクラムマスターについて記述されているスクラムガイドから一部を引用してみましょう。
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。
スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。
スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。
引用元：https://scrumguides.org/ - Download the official Scrum Guide - Japanese (November 2020)
記載の通りスクラムチームの有効性に責任を持つ必要があります。さらに、より大きな組織に奉仕する真のリーダーである、とも書かれています。スクラムマスターはこの大きなプレッシャーに晒されることになります。
スクラムはとりあえずやってみるだけであれば比較的容易です。とてもシンプルなフレームワークであり、そこが良いところなのですが、その反面チームの置かれた環境に最適化をし続けなければならないという大変さも抱えています。
答えが明確に得られない領域で、プロダクト、ユーザー、ステークホルダー、他チーム、自チーム……といった相互関係性の中で試行錯誤をし続けること、それをチームを促していくことというのは簡単ではありません。
これはスクラムおよびスクラムマスターに限った話ではありません。「何らかの改善をしなければマズイ！」と思う状況は多々あると思います。書籍「チーム・ジャーニー」にも似た記載がありますが、そういった状況下において問題を先延ばしても状況に変化が見られないのであれば今ここにいる人たちで対処するしかありません。ある日突然、誰かがやってきて変えてくれるということもありません。状況を変えられるのはその必要性を感じている人だけです。
ただし、そういった人々は孤独になりがちです。多くの人々は程度の差はありますしケースバイケースですが変化を恐れます。答えのない中で変化を恐れる人々を促していくということは心が折れるポイントだらけです。
どうにかしなければならないという火がせっかく付いたにも関わらず、様々な障害によって消えてしまうことも多々あります。それはもったいないですよね。もしかすると、これを読んでくださっている皆さまの中にも類するご経験をお持ちの方がいらっしゃるかもしれません。
そうならないためにも、気軽に相談できる相手や支援者が必要です。
支援に携わることになったきっかけ
人事へ「他のチームでも絶対アジャイル開発について色々悩みがあるはずなので、そういった支援にも今後取り組んでいってみたい」とお伝えしたことがスタートでした。
社内で出張スクラムマスターとして活動されているVPoE室のメンバが支援予定のチームがあるということで、一緒に参加させていただくことになりました（参考：【開催レポート】DMM × はてな「それぞれのアジャイル開発の現場 〜 チームの中から外から 〜」を開催しました！）。
対象チームは私も所属するプロダクト本部内ですので、より近い視点から支援ができるのでは？ と考えました。プロダクト本部は2022年3月から新しい体制になったばかりで、組織内で試行錯誤が日々繰り広げられている状況です。
相談した結果、このような取り組みに繋げられたことはまさに渡りに船でした。
色々ヒアリングしてみた
本部長や部長、Manager、ディレクター等にヒアリングを行ってみました。その結果としては、
- 開発スピードや効率
- ディレクター、デザイナ、バックエンドエンジニア、フロントエンドエンジニアといった職能間の関係性
- チームや部署間の関係性
といった辺りに課題が数多くありそうな印象で、特にコミュニケーションの課題であることが多そうです。当然ながら1つのチームが独力で果たせる仕事というのはそう多くありません。DMMグループ内でもEXNOAはゲーム事業に特化しているとはいえ、それだけでも大きな組織ですので、多種多様なメンバーとの協力が不可欠です。
新しくなった組織の中で、多くのチーム内でも開発効率をどうすれば上げられるかを、日々悩んでいる状況です。大きな組織の中身を全てまるっと解決することはそう容易なことではありません。
時間経過と共に変化する重視すべき4つの領域
私はスクラムガイドもよく読みますが、LeSS（Large-Scale Scrum）と呼ばれるフレームワークも参考にしています。
ここでスクラムマスターが重視すべき4つの領域が紹介されています。
- チーム
- プロダクトオーナー
- 組織
- 開発のプラクティス
この4つの重点領域は、時間の経過とともに、どこに重点を置くか変化していくものです。下図はその典型的な例を挙げたものです。
図1. Scrum Master focus over time（引用元：https://less.works/case-studies/sys）
LeSSもスクラムの一種です。スクラムをきちんと導入するためには最初に構造的な変更が必要となります。したがって、最初は基本的な構造を整える必要があります。
今回の支援対象のチームは3つあるうちの1つの開発チームでした。スクラムを浸透させる上で重要なのは「小さくはじめて、大きく育む」ことが肝要です。そういった意味では、組織としての基本的な構造は整っていました。いずれ「大きく育む」必要性が徐々に高まり、スクラムガイドで言うところの「より大きな組織へ貢献する」重要度が高まっていきます。
改めてタイムラインの初期に注目してみると、そのタイミングで注力するべき領域は「プロダクトオーナー」と「チーム」になります。
プロダクトオーナーについては、プロダクトバックログの効率的な使い方、優先順を決めるための支援、チームとのやり取りの効率化、レトロスペクティブ支援などがあります。
- プロダクトオーナーと顧客
- プロダクトオーナーと上級管理職
- プロダクトオーナーとチーム
これらの関係性をより良くしていく必要があります。
チームについては、一言で言えば「チームの自己管理化」を促すことになります。スクラムマスターはチームの有効性に責任を持ちます。チームが自ら責任を引き受けて能動的に立ち回るようになるために様々な取り組みをしていく必要があります。
現在所属している部署で私もアジャイルチームビルディングを率先して行っていた結果から、他部署や他チーム、上層部といった組織内での関係性に多くの課題が生じることは目に見えています。しかし上記の図にもあるように、まずはチーム内でしっかりとチームメンバーそれぞれが今の環境やどういう活動をしなければならないかという納得感を得ることが望ましいでしょう。
どんなことをやっているのか
まずは観察と妨害リストの作成
最初にどのように現在の開発プロセスが回っているのか、各種会議体に参加させていただきました。この中で様々な気づきが得られました。
妨害リストとは大雑把に言えば「スクラムを推進する上で妨害となりそうな要素を一覧化したもの」です。チームの活動を妨げている事象・物事・ルール・習慣を支援者視点で洗い出し、その考察と改善アイデアを書き出しました。
例えばですが、
- デイリースクラムで状況の確認だけではなく議論が発生している
- スプリントレビューが進捗報告になりがちで、チームが何を得て、今後何をすべきか、といった話が薄い
- レトロスペクティブで声の大きい人だけの意見に集中しがち
- ベロシティの向上を目標化してしまっている
等々、よくあるアンチパターンとして見受けられるものもありました。
妨害という名の通り「ここが悪いんじゃないか」「これはスクラムに反しているのではないか」といった要素がズラッと並ぶので、当事者からすると「ウッ」とプレッシャーを感じやすいものです。ですがこれらは当然ながらチームの皆さんを否定するものではありません。何か悪いことがあるとすれば、チームがそうせざるを得なかった何らかの「要因」です。
属人的な犯人探しはしません。その「要因」を事実としてきちんと捉え、チームにとって最重要視すべきは何かを考え、ひとつひとつ、少しずつ改善をしていくことが重要です。
最初に登る山を決めるワークショップ
将来的に高い山を目指すとしても、いきなり目指すことは難しいです。そのため、まずどの辺りを目指すのか？ という最初にチャレンジする小さな山をチーム内で議論するためのワークショップが実施されました。
この会では私はチームメンバー（開発者）としてのロールの帽子を被って参加しました……やはりこれは難しく、本質的にチームメンバー（開発者）ではもちろんありませんし、支援者視点で見てしまいます。なるべく支援者としての発言や提言は避けるように努めたつもりですが、目指す姿として「一番早いチーム」というわかり易すぎるものを提示してしまいました。
その他多くのメンバーの意見を踏まえて、最終的に「協力し合えるいちばん早いチーム」を目指すことになりました。
「一番早いチーム」という指標は、我ながら最初に思いついて目指すステップとしてそこそこわかりやすく良いものだとは思います。その過程でより具体的ないし別の方向性が見えてきてそちらを目標化した方がいいことも生じるかもしれませんが、それはそれです。
できればチームが自ら気づいたものが目標となることが望ましいため、これはちょっと失敗しました。この反省を元に、その後は何らかのワークショップに参加するときも基本的に観察者に徹するようにしています。
チームビルディングバックログの作成
支援者による観察や提案、チーム自らの気付きや元々あった課題感など様々な話が入り乱れるようになってきました。各メンバーも業務をこなしつつの改善施策ですので、なかなかに大変です。
そこで、チームをより良い方向に向かうことができるための要素に絞ったバックログが作成されました。
例えば、
表1.チームビルディングバックログからの一部抜粋
| Whatを達成したい | それはWhyだからだ |
| 目的がわからずに会議に参加することを極力受けないようにしたい。 | それはファシリテーター以外のメンバーの頭を悩ませ、議論以外の時間がかかり、当初の会議目的を達成できず、追加会議が必要になるからだ。 |
といったものが挙げられていました。察するに会議の事前準備や周知が上手く行っておらず、時間内に収まらない状況が多いのではないか、という想像ができます。また、「ファシリテーター以外のメンバーの頭を悩ませ、」という文章には「ファシリ以外のメンバーは基本聞くだけにしたい」という思惑があるのかもしれません。この文章をそのまま受け取ると、アジャイルマニフェストの個人との対話を重視するという原理原則に反していますので、注意が必要かもしれません。ただし、これはもちろん個々の会議の性質にもよります。情報共有を主目的とした場合は聞くことが主体で適宜質疑応答で良いでしょう。しかし議論が必要な仕様検討の場であったり、数多くのアイデアが必要なブレストであったりした場合は参加者の活発な発言が必要です。
こういったものを洗い出し、事実として何が起こっていて、何が課題なのかを整理し、優先度を決めて、対処を進めています。まさにバックログです。
余談：CSPO®で用いられたバックログ
以前、株式会社Odd-e Japanのスクラム認定トレーニング「Certified Scrum Product Owner® (CSPO®)」を受講しました。ここでもトレーニング用のタスクが並べられたバックログが用いられていました。
図2. CSPO®受講時に利用されたバックログの例
合計5日間のトレーニング期間中、1日をスプリント期間とし、このトレーニングで得たいことのリストを作成、コーチ側で用意していたものマージしバックログ化を行い、毎日トレーニングの冒頭で、Doingとなっていたチケットをそのまま続けるか？ バックログに戻すか？ 優先度を変えるか？ 完了とするか？ といった確認を進めていました。
明確な答えは無いが何らかの改善に取り組みたい、といった場合、こういったバッグログの運用はとても有効だと思います。
スクラム支援デイリーミーティング
主に一部のチームメンバー3名と支援者2名で毎日15分コミュニケーションを取っています。
この中ではスクラム支援用バックログに基づき、スクラムチームの効果的な確立・改善のために必要そうな対応について順次確認や相談がなされています。これらは全て「いつまでに」「なぜやるのか」「なにをやるのか」「どうやるのか」といった内容が書き出されています。
チームの皆さんで優先順を決めていただき、その解決に向けてのサポートを行っています。
これまでと、これから
チームの成長と支援はまだ始まったばかりです。チームの皆さんがチームをより良くするために自ら考え動くということに少しずつ慣れてきたのかな、と思います。今後多くの失敗を積むことになりますが、その中からひとつひとつ成功体験を積むことがチームの成長に繋がり、スクラムで言うところの自己管理型のチームとなっていきます。そして上手くいけば、ゆくゆくはこの成功体験を糧に組織課題にも取り組んでいけるようになるでしょう。
私自身としてはメインの業務をこなしつつの支援であるためどうしても時間配分は少なくならざるを得ず、結果的にコミュニケーション不足を感じている、という課題があります。スクラム支援デイリーミーティングに参加する時間を設けてはいるものの、日々の業務に追われてしまっている面もあり、支援者としては対象チームにもっと密に寄り添う形を取れるようにしないといけないかもしれません。現在はSlackによる非同期的なコミュニケーションを意識して取り組むようにする等、支援者としても日々試行錯誤を続けています。
翻って、私自身が所属するチームもまだまだ課題の多い状態です。無くなることはありません。少ない人数でスピードを求められる環境で、チームの皆さんのご協力のおかげで日々課題解決をし続けています。それを繰り返してきたことで少しずつ成長し結果に繋がってきました。
私の所属するチームでのプロジェクト発足から2年、他部署がチームビルディングの参考にしていただいている側面も出てきました。今回のスクラム支援もその一例です。
チームの成長はじわじわと周囲に影響が及びます。今回の支援によって成長したチームにも、ぜひ影響力を持った取り組みができるようになっていただきたいなと思いつつ、今日もまたスクラム支援デイリーミーティングへ参加してきます。
EXNOAでは、DMM GAMESプラットフォームを開発するチームを牽引するリーダー候補の方を募集しております。チームパフォーマンスを最大化する事に興味のある方はぜひご応募ください。
