こんにちは、kintone 開発チームに所属している xiao （@x1a0q1）です。
元々エンジニアとして活動していましたが、約 2 年前のフロントエンドリアーキテクチャプロジェクト（通称フロリア）に参加することをきっかけに、チームをサポートする役割を担うようになり、スクラムマスターを兼務することとなりました。
さて、サイボウズではスクラムマスターのことをより多くの人に知ってもらう啓蒙活動の一環としてリレーブログ企画を開催しており、本記事はそのリレーブログの一つです。
また、この記事は現在絶賛開催中の CYBOZU SUMMER BLOG FES '24 (Agile/Scrum Stage) DAY 1 の記事でもあります。
背景
サイボウズは 2022 年に New Business Division という本部を新設しました。経緯についてご興味がある方は、@ymmt2005 が書いた記事をご一読ください。
New Business Division では、新事業の立ち上げに向けて幾つかの PoC プロジェクトが発足しています。その中でスクラムを導入してみたいが、スクラムマスターとして振る舞うメンバーがいないという問題を抱えているチームがあり、自分が支援することになりました。
もとよりサイボウズではアジャイル開発が比較的盛んで、チームに入ると既にスクラムを回していたり、スクラムを経験したメンバーがいたりすることが多く、スクラムをゼロから実装する機会はそう多くありません。そのような状況の中、私が支援に入るチームでは、スクラムを自ら運用した経験のあるメンバーがほとんどおらず、チームにおけるスクラムの土台を整えることから支援を始めました。
この記事では、自分にとっての振り返りを兼ねて、支援活動を始めてから約 5 ヶ月間に行ってきたことなどを整理しながらお話ししていきたいと思います。また、この記事の内容が、これからスクラムマスターとしてスクラムをゼロから実装しようとする方々にとって、少しでも参考になれば幸いです。
これまでやってきたこと
1. 「3 - 5 - 3」という「型」の中でスクラムをとりあえず回してみる
アジャイル開発を経験したことのないチームにスクラムを導入する際、皆さんが最初に行うことは何でしょうか？恐らく理論から入るパターンが一般的かと思います――『スクラムガイド』をチームに紹介したり、定番となる本をみんなで読んで勉強したり――そういった入り方がまさしく無難で自分も現場で何度も経験しました。
今回私が支援に入るチームは少し特殊で、私が参加する前に既に PO が頑張ってスクラムに必要最低限なイベントやロールなどの「型」を実装していました。しかし、その中に明らかに『スクラムガイド』に則ってないモノがあったり、そもそもスクラムにはない要素が混ざったりして、「型」自体が少し歪な形になっていました。
したがって、理論に入る前に、まずこの「型」を『スクラムガイド』に沿った適切な形に整えることが、私の最初の仕事でした。
主にやったことは：
- 「3 - 5 - 3」構造に基づいて、スクラムを回すための必要最低限な基本要素のみ導入
- 3 つのロールの定義と役割の明文化
- 5 つのイベントに明確なタイムボックスを設けて、必要に応じてファシリテーションを行う
- 3 つの成果物とそれぞれに結びつくコミットメントの定義
- しばらく考えることを諦めて上記の「型」の中でスクラムを回してみる
の 5 点でした。
このいきなり「型」からスクラムを実装するアプローチは、思っていたより効果がありました。もとより、スクラム自体が経験主義に基づくモノであり、「実践」からの入る方法がむしろ自然だと以前から思っていました。このような「とりあえず教科書通りにやってみよう」という勢いでスクラムを回していくうちに、スクラムの基礎となる部分がいつの間にかチームに定着し、チーム内では「なぜこれをやらなければならないのか？」というような疑問が生じ、「理論」を自ら求めるようになりました。
ここまで書くと、スクラムは剣道の素振りとも似ているのではないかと思うようになりました。
剣道を始めたばかりの初心者に、いきなり理論から教えることはおそらくほとんどないかと思います。まず剣道の基本要素が数多く詰まっている素振りをさせ、基本に集中させることで、自らの「是非」を反復の中で見つけ出して一つずつ解消していく――まさにスクラムです。
ちなみに、筆者は生まれてから一度も剣道をやったことがありません。
2. ミートアップで「何を作るか」という問いへの解答を探る
次の仕事は、チームメンバーからの要請を受けて、全員が集まるミートアップを開催することでした。
前述の通り、私が支援するプロジェクトは新事業に向けた PoC プロジェクトなので、プロダクトのバリューポジションは可変的なモノでした。私が支援に入るタイミングで、ちょうどプロダクトのバリューをチームで見直し、認識を揃えようという動きが出てきたところでした。それをきっかけに、全員がオフィスに集まって議論する場としてのミートアップを開催することにしました。
集まる目的を：
- プロダクトのビジョンなどについて議論し、全員に共通の認識を持たせる
- お互いのことをよく理解し合い、より強固なチームワークを築く
と設定した上で、各々の目的に合わせて（もはや定番とも言える）「インセプションデッキ」と「ドラッカー風エクササイズ」を二日間に渡って行っていました。
ミートアップ開催時の様子です：
これまで何度も「インセプションデッキ」&「ドラッカー風エクササイズ」のセットのワークショップをやってきましたが、今回はとりわけ得がたい経験を得ることができました。
というのも、写真からお察しの通り、チームメンバーの構成が多国籍で、普段のやり取りも基本英語で行なっていました。テキストベースのコミュニケーションであれば特段に問題ないが、リアルタイムの会話になると、どうしても情報の伝達ロスがネックになります。その問題を回避するために、社内の通訳チームにサポートを要請し、通訳を行いながらワークショップを実施することになりました。
元々「インセプションデッキ」だけの作成でも、数日から 2 週間程度かかると言われています。となると、通訳を挟む情報伝達に必要な時間が通常のワークショップより倍以上になることを考慮して、さすがに 2 日間で全てのコンテンツを消化しきれないと判断し必要な質問 4 つだけピックアップして「インセプションデッキ」の作成に取り掛かりました。
しかし、それでも時間が足りなくて、一部の議論については持ち帰ることとなりました。とは言いつつ、メンバーからの反響が予想以上に良かったです。ミートアップを通じて、普段あまり行えていなかったプロダクトやチームメンバー自身に関する「対話」が活発に行われるようになったことが大きな成果でした。
今後もこのようなイベントを定期的に開催し、「インセプションデッキ」をアップデートしながら良い製品を作ろうという声をメンバーから聞き、アジャイルソフトウェア開発宣言に掲げている「プロセスやツールよりも個人と対話を」という理念が、まさにここで実感できた貴重な経験でした。
3. 「スクラム」の理論知識をチームに紹介
ここにきてようやく「理論」のご登場です。
約 2 ヶ月間をかけて、チームに「型」の中でどのようにスクラムを行うか（How）を経験してもらい、ミートアップで何を作る（What）質問にも回答してもらえました。
チームメンバーがそろそろ「なぜスクラムをやってるのか」、「なぜスクラムはこうでないとダメなのか」、「イベントやロール、成果物の設定に何の意味があるのか」などの疑問（Why）を考え始めているのではないかといったタイミングで、スクラムの土台となる基礎理論を教える「座学」を行いました。
スクラムの「理論」を学ぶには、『スクラムガイド』以上に適したコンテンツはないでしょう。しかし、スクラムに関する「すべて」が凝縮されて記述されている故に、情報密度が高く、初めての人にとっては決して簡単に読み解けるコンテンツではありません。
そのため、私は『スクラムガイド』の構成を参考にしながら、必要な用語とその定義を抽出し、Scrum Inc. の用語集などと組み合わせて、初めての人にでも読みやすいようにアレンジした「教科書コンテンツ」を用意しました。
用意した「教科書コンテンツ」の一部です：
「座学」が行われた後、（私の観測では）チームに起きた最も大きな変化は、レトロスペクティブなどの振り返りの場で、スクラムに関する話題がより頻繁に取り上げられるようになったことでした。
「私たちのプランニング、スクラムガイドに記載されている形とはかなり乖離していない？」や、「完了の定義がまだできてないじゃん？」などの会話がチーム内で飛び交うようになりました。
「理論」を導入したことでチームが自律的に「改善」を求めるようになる、というのが私にとっての学びでした。
4. あてずっぽうの奥義（ストーリーポイント）の導入
『スクラムガイド』を読み終えた人がよく思い浮かべる疑問の一つは、「見積もり（ストーリーポイント）に関する記載が一切ない」という点です。
しかし、実際に現場に入ると、ほとんどのスクラムチームがストーリーポイントなどの単位を用いて見積もりを行っています。ストーリーポイントがないと、チームのベロシティを測定できず、適切なプランニングやプロジェクトに対する（ある程度の）見通しを立てることが難しくなってしまうからです。
ただし、『スクラムガイド』のような「マニュアル」として明確な記載がないためか、今までの経験上、ストーリーポイントに関する問題がスクラムを回していると頻繁に発生します。
私たちのチームも例外なく、運用して間もなくいろんな問題に遭遇しました。そのため、ストーリーポイントに関する「虎の巻」のようなドキュメントを作成して、チーム内で共有することにしました。
以下はその一部抜粋です：
- 見積もりは「約束」ではなく、（ある程度の）見通しを立てるためのツールに過ぎない
- 見積もりに過度な精度を求めない
- ストーリーポイントを稼働日などの日数と紐付けて考えてはいけない
- ベロシティをチームの生産性を評価する指標として使ってはいけない
- ベロシティを増やすことを目指さない。かわりに安定させることに注目する
- ベロシティを「チーム」のために使おう：
- 問題点や障害の発見に
- プランニングの材料になど…
このように予め明文化しておくことで、今後起こりうる問題を未然に防ぐ効果を得られるのではないかと期待しています。
現在取り込んでいること：スクラムポリシーの作成
土台作りをひと通り終えたタイミングで、私は「スクラムポリシー」と題したドキュメントの作成に取り掛かりました。このドキュメントを作成するのは、将来チームが自律的にスクラムを回せるようにするためです。
スクラムを運用していくなかで
- 「昨日の天気（ベロシティ）ってどうやって計算するんだっけ？」
- 「ディリースクラムのやり方これで大丈夫かな？」
- 「直近 3 スプリントでゴール未達だけどどうしたらいい？」
のような問題にぶち当たる時に、まずここを参考したら大体の解決策を見つけられるといった位置付けのドキュメントを目指しています。
まだ構成などを練り上げている最中ですが、少なくとも以下のトピックを取り入れる予定です：
- 基本編（チームのための「スクラムガイド」）
- スクラムの「三本柱」と価値基準
- スクラムにおける基本的な開発フロー
- 3 - 5 - 3（3つのロール、5 つのイベント、3 つの成果物）に対する定義
- 各イベントの進め方
- 応用編（困った時はここを見る）
- スクラムボード（GitHub Projects）の運用ルール
- チームにおける完了の定義
- キャパシティと割り込みを考慮したベロシティの計算方法
- 楽しくレトロスペクティブを行うためのテクニック
- 役に立つパターン・ランゲージ集
- ワーキングアグリーメント（チームの約束事）
この「スクラムポリシー」を、将来的にも継続的にアップデートされる「生きたドキュメント」にしたいと考えています。これはチームのためのドキュメントなので、チームに何か変化があった際に柔軟に対応できるように運用し、最終的には全てのチームメンバーに編集権限を与え、OSS のような形にしたいと考えています。
「スクラムマスターって何をするの？」に対する私なりの答え
ここまでは、私が初めてアジャイル開発を行うチームでどのようにスクラムの土台を作るのかについてご紹介しました。
さて、このリレーブログ企画では、「スクラムマスターって何をするの？」という問いに対する自分なりの答えを記事の最後に記載するという「受け入れ条件」があります。
これ対して
スクラムマスターの役割は、チーム内の 「スクラムやっている感」を無くすこと
というのが、私なりの答えでした。
原点に立ち返ってみれば、アジャイル開発が目指していること自体は非常にシンプルであることが分かります。『Clean Agile』という本の冒頭に、次のような記載があります：
アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。
複雑な問題を細かい単位に分解し、小さな開発サイクルの中で軌道修正を行いながら、価値を最大化したプロダクトを顧客に届けること、これがアジャイル開発の目的です。そこに「スプリント」も「ストーリーポイント」もありません。
では、なぜスクラムが世の中のチームに必要とされるのでしょうか？それは、「組織」というスケールだと、どんなに簡単なことでも指数的に複雑さが増すからです――タスクをどの程度まで分解すれば「細かい」と言えるのか？小さなサイクルとは具体的に何営業日にすれば良いのか？軌道修正はどのように行うのか？――こうした疑問は、明確な「ガイドライン」がない限り、チーム内から次々と生じてくるでしょう。
そのため、チームを「スクラム」という「型」の中に置くことで、アジャイル開発を段取りよく進めることができるのです。しかし、価値のあるソフトウェアを作るという「ゴール」に到達するためには、いずれその「型」の存在を忘れなければなりません。
以前読んだ本*1に、初めてスノーボードに挑戦する初心者の話がありました。
その初心者に対し、「膝を曲げて、視線を下に向けてその先にある丘を見るんだ。そして重心を下げる、けど背中をまっすぐに保とう。最後に体を前に傾けて進んでいけばいい」と、コーチが教えます。
「これだけのことを同時に覚えながら滑るなんてムリですよー」と、初心者が少し怯えた様子で言いました。
「覚えるんじゃない、忘れるんだ」とコーチが続く「個々の動作を確実にマスターする必要はあるが、最終的に繋げてやらないと意味がない。繋げるためには、分解された動作を無意識に行えるレベルまで上達しろ。そしたらキミの意識が身体の動きから解放され、滑ることに集中できるようになるんだ」。
よく考えたら、スクラムも同じではないかと思います。
『スクラムガイド』の中で定義されたロールやイベントは、すべて「価値のあるソフトウェアを顧客に届ける」ために存在しています。それを実現するために、スクラムの「個々の動作」をチームに浸透させ、スクラムを「型」から「フロー」へと変換し、チームをその流れに乗せるのがスクラムマスターとしての役割です。
つまり、外部から見て、「このチームは模範的なスクラム回せているなぁ」ではなく、「このチーム、毎回痒い所に手が届く高品質な機能を安定したペースでリリースできて、本当にすごいなぁ」と思われるようなチームを組織内で量産することが、スクラムマスターの価値の所在ではないかと思います。
ちなみにお察しの通り、筆者は生まれてから一度もスノボをやったことがありません。
おわりに
この記事を最後まで読んでくださってありがとうございました。
私たちのチームでは一緒に働いてくれる仲間を随時に募集しています。変化を楽しむ、チーム作りや新製品開発に挑戦したい方のご応募お待ちしております！
*1:出典は『本を読む本』という本です。だいぶ昔に読んだので、具体的な箇所はもう覚えていませんが、第一部に書かれている内容だと思います。
