サイボウズ開発本部では、2022年5月に大規模な組織変更を実施し、職能ラインと人材マネージャーを整備した結果、新たにスクラムマスター職能が誕生しました。

組織のチームワークを最大化するためにスクラムマスター職能を作りました

私はこれまでサイボウズのスクラムマスター・アジャイルコーチとして活動していましたが、組織改編を機にスクラムマスター職能のマネージャーになりました。

一人のスクラムマスターとして、組織をチームワークであふれたアジャイルな姿にしたいという理想を持っています。スクラムマスターを職能とし、マネージャーとしてスクラムマスターたちを成功させることができれば、理想の実現に大きく近づくと信じています。

先達の活躍のおかげで、アジャイルは多くの現場に浸透し、最近はスクラムマスターを募集している企業も珍しくなくなりました。しかし、スクラムマスターを職能のひとつと位置づけ、組織的にスクラムマスターを支援・育成する例はほとんど聞いたことがなく、職能化はまさにゼロからの出発でした。

給与レンジの検討や1on1体制、予算承認といった最低限のピープルマネジメントをはじめ、組織としてどのような支援をすればスクラムマスターが花開くだろうかと考え、さまざまな試行錯誤をしています。一例を挙げると、成長支援のためのコーチング、外部研修、カンファレンス参加、社内外のコミュニティ活動、チーム作成ガイド公開、評価の透明化などに取り組んでいます。

本セッションでは、スクラムマスター職能のマネージャーとして、スクラムマスターの成長に向き合い、組織をチームワークであふれさせるための約2年の試行錯誤から得られた学びを共有したいと思います。

みなさんご存知の通り、スクラムの基本単位はスクラムチームという小さなチームです。

サイボウズという組織の内外でスクラムマスターとして約8年の試行錯誤を重ね、組織全体をアジャイルにするためには、組織の基本単位をスクラムチームのような自律的な小さなチームにすることが何よりも重要だと考えることになりました。

チームが重要であることはその通りですが、組織を見渡してみると、必ずしもすべてのチームがスクラムを実践しているわけではありません。スクラムを指導したいわけではなく、自律的に活動する小さなチームを作りたいのです。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報は存在しませんでした。

そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践しているチームでもそうでないチームでも参考にすることができる「開発チーム作成ガイド」を公開しました。

開発チーム作成ガイドを公開します - Cybozu Inside Out

本セッションでは、開発チーム作成ガイドにまとめた内容を紹介する形で、機能するチームとはどのようなものか、機能するチームを作るために整えるべき条件とは、条件を踏まえた機能するチームの基本の型などを解説します。

オレ、シャークレ、トークショーを開催するサメ！

すぐさめLikeするシャー

スクラムマスターを始めた人からよく、「ファシリテーションに苦労している」という声を聞きます。確かに、スクラムマスターとして活動を始めた際に、最初に直面する試練はスクラムイベントをはじめとした「チームの議論の場」をどう進行するかだと思います。自分自身も、初めてスクラムマスターとしてスクラムイベントを進行する立場になった時の不安な気持ちをよく思い出します。

スクラムイベントを効果的な場にするためには、参加者の主体的な参加が欠かせません。そのために、スクラムマスターはファシリテーションのスキルを活用してチームを支援することができます。

ファシリテーションはスクラムマスターの重要なスキルであり最初の壁とも呼べますが、体系的に学習するのが意外と難しいと感じます。書籍はたくさんありますし、Webページもたくさん見つかりますが、細かいテクニックの話が多く、理論や原則を学べる情報はあまり見つかりません。

本セッションでは、自分自身がファシリテーションを学ぶ上で参考になった情報を紹介しながら、スクラムマスターのファシリテーションスキルの学び方について掘り下げたいと思います。

組織の中でスクラムマスターが活躍できる環境を作るには、スクラムマスターをどうマネジメントするか検討する必要があります。スクラムを導入した企業から非常によく聞かれるのは、「スクラムマスターの評価はどうしているのか？」という質問です。

サイボウズでは、2022年5月に大きな組織変更を実施しました。詳細はこちらの記事をご覧ください。

マネージャー、いないと無理だったので、またつくりました - Cybozu Inside Out | サイボウズエンジニアのブログ
https://blog.cybozu.io/entry/2022/11/04/173000

今回の組織変更では、職能ラインとマネージャーを整備し、新たにスクラムマスター職能が誕生しました。現在、スクラムマスター職能には約15名のメンバーが所属し、私を含むアジャイルコーチ3名がマネジメントを担当しています。

スクラムマスターを職能として確立したことで、給与レンジやキャリアラダーを定義したり、成長支援のための1on1やコーチングといった、組織としてスクラムマスターを支援するための仕組みを日々検討しています。

本セッションでは、サイボウズのアジャイルコーチ3名がスクラムマスターのキャリア支援のために検討したことや、現在の取り組み・今後やりたいことなどを座談会形式で語り合います。

スクラムの生みの親であるジェフ・サザーランド博士らが2014年に出した論文 ”Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams” では、ハイパープロダクティブ（超生産的）チームを体系的に生み出すためのパタン・ランゲージとして、9つのパタンが紹介されています。

各パタンの概要はこちらの記事で紹介しました。
スクラムチームを超生産的にするためのパタン・ランゲージ｜天野 祐介 (ama_ch)｜note

筆者の所属するサイボウズでは、当時「フロントエンドリアーキテクチャプロジェクト（通称フロリア）」というフロントエンド刷新プロジェクトを立ち上げたところだったので、こちらのパタン・ランゲージを紹介し、各チームのスクラムマスターと協力してパタンを実践してみました。

プロジェクトの概要やチーム体制は下記の記事で解説しています。

• kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
• 30人が参加するプロジェクトで桁違いのパフォーマンスを発揮するためのチームデザイン - Cybozu Inside Out | サイボウズエンジニアのブログ

本セッションでは、9個のパタンを紹介した後、実践したチームのスクラムマスター達と対話し、複数チームで実践し得られた知見を共有したいと思います。

スクラムマスターの重要なスキルとして、「観察」がよく挙げられます。

観察が重要だという話は、一見すると特に疑問の余地がありません。しかし、下記のような観察の実態について語られる機会は少ないように思います。

• なぜ観察が重要なのか
• 効果的な観察とはどのようなものか
• どうやって観察するのか
• 観察のスキルを伸ばす方法

私自身も、スクラムマスターとして、観察が重要だという考えを持っています。本セッションでは、上記のような疑問について改めて考え、スクラムマスターの「観察」スキルを掘り下げてみたいと思います。そして、観察のスキルを伸ばし、タフな現場でも心身を健全に保つために役立つ心構え・テクニックをご紹介します。

みなさんはふりかえり現場のファシリテートで困った経験はありませんか？

同じように困っている方の参考になれば幸いです。

スクラムの基本単位は、小さいスクラムチームです。スクラムマスターとしてチームの有効性を高め、価値あるプロダクトを届けるためには、チームワークへの深い理解が欠かせません。

成功するチームと、大して成果をあげられないチームの違いはどこにあるのでしょうか。

J・リチャード・ハックマンの著書Leading Teams（邦題：ハーバードで学ぶ「デキるチーム」5つの条件）では、チームのパフォーマンスを高めるための5つの基本条件が紹介されています。

1. 真のチーム / Real Team
2. 魅力ある方向性 / Compelling Direction
3. チーム力が高まる構造 / Enabling Structure
4. メンバーを支援する環境 / Supportive Context
5. エキスパート・コーチング / Expert Coaching

本セッションでは、これらの5つの基本条件を紹介し、チームについてのよくある失敗や、良いチームを作るためのアプローチ方法を考えてみたいと思います。

アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではないでしょうか。

スクラムマスターとして、開発に限らず組織の全員が、アジャイル/スクラムの原則を理解して、実践できるよう支援することは重要な活動です。サイボウズでは、数年前から新卒の全社員（＋希望者は誰でも）向けの基礎研修としてアジャイル/スクラムの話をインプットしています。

こちらのセッションでは、サイボウズ社内で実施している研修（講義）を社外向けに再編成したものをお届けします。アジャイルやスクラムの考え方をベースに、エンジニアに限らず、チームワークを高め、成果を届ける仕事の進め方の基礎となる考え方・プラクティスを紹介します。

本セッションはサイボウズのスポンサーセッションです。

サイボウズでは「チームワークあふれる社会を創る」というミッションのもと、kintone/Garoon/Officeといったグループウェアプロダクトの開発や、チームワークメソッドの開発・普及を事業としておこなっています。

それぞれの現場で活躍するメンバー（アジャイルコーチ、エンジニア、HRメンバーetc）が集まり雑談会を開催します。MiroやDiscordを使いながら参加者のみなさんとインタラクティブに進行したいと思います。

サイボウズの事業や活動について興味がある方、サイボウズのメンバーと雑談したい方はぜひご参加ください。

スクラムを成功させるためには、スクラムマスターの活躍が欠かせません。自身がサーバントリーダーとしてチームを支援する立場でありながら、スクラムマスターも日々の実践を通じて成長することが求められます。

キーノートスピーカーのZuzana 'Zuzi' Šochováが著書「The Great ScrumMaster（日本語版: SCRUMMASTER THE BOOK）」の中で提唱している #ScrumMasterWay は、スクラムマスターの成長過程の理解の助けになる概念です。

本セッションでは #ScrumMasterWay の各レベルを参照しながら、実際に私がスクラムマスターとして取り組んできた活動をふりかえり、スクラムマスターの成長について考えたいと思います。

みなさんの現場ではすでにスクラムを導入済みでしょうか。

最初は仕事が終わらない、品質が低い、改善が進まないといった問題が沢山出ていたチームも、スクラムを始めると少しずつ安定して開発ができるようになってきます。ある程度のベロシティが出て、不具合の数もそれほど多くなく、割り込みタスクも大きい問題にはならなくなるでしょう。しかし、チームは魅力的で顧客の問題を解決する本当に強いプロダクトを作ることができているでしょうか。

本当に強いプロダクトを作るためには、プロダクトオーナーの支援が欠かせません。プロダクトオーナーが不確実性と向き合い、素早い仮説検証を繰り返して、価値の高いアイデアを見つけられるようになる必要があります。開発チームはプロダクトオーナーの活動に参加・協力し、スクラムマスターはその取り組みを様々な方法で支援することができます。

このセッションでは、自分がスクラムマスター/アジャイルコーチとして複数の現場で取り組んできたプロダクトオーナー支援の活動と、そこから学んだことについて紹介したいと思います。

サイボウズの人事部採用チームは、
採用計画の立案から面接の実施、合否連絡、内定者のフォロー、イベントの出展、説明会の実施といった業務を日々行っています。
採用チームに異動してきて2年目の始めに、リーダーを引き継ぐことになりました。
これまで経験豊富なリーダー中心に業務を進めてきた状態だったので、経験の浅い自分がリーダーになることに不安を感じていました。
自分個人がエースの抜けた穴を埋めるのではなく、チームの皆でカバーできるような進め方をしたいと悩んでいたところ、
開発チームで導入が進んでいたスクラムが目に止まりました。
スクラムが人事の業務改善にも役立つと感じ、導入を決意し、2年ほどスクラムをベースにした業務改善を進めてきました。
プランニングやふりかえりで地道な改善を重ねた結果、モブ作業やカンバンを活用が進み、メンバーの残業が減り、チームのベロシティも向上しました。
現在はチームでタスクがコントロールでき、理想のチームに向かう良い状態が作れています。

改善の過程で起きた問題やそこから学んだこと、チームに起きた変化を紹介したいと思います。

スクラムを学び実践するみなさん、特にRSGTに参加して情報交換をしようという学習意欲の高いみなさんは、きっと海外カンファレンスにも興味があると思います。私も日本で学びを続ける過程で、「日本のアジャイル事情は少しずつ分かってきたけど、海外ではどうなんだろう？」という疑問を持ち続けていました。

一般的に海外カンファレンスに行くには費用・言語・稟議など多くの問題があり、実際に行くには高いハードルがあると思います。そもそも高い費用をかけて行くほどの価値があるのか？という疑問もあるでしょう。

価値があるかどうか判断するために、まずは飛び込んで情報を増やしましょうということで、私は1年でなるべく沢山の海外カンファレンスに参加するという実験を行ないました。直近約1年では下記のカンファレンスに参加しました。

• Agile Conference 2019
• LeSS Conference 2019
• Global Scrum Gathering Vienna 2019(執筆時予定)
• Agile Vietnam 2018/2019(執筆時予定)

このセッションでは、実験の過程で学んだ海外カンファレンスの歩き方から、参加すべき人とその理由などを共有します。

サイボウズの人事部採用チームは、
採用計画の立案から面接の実施、合否連絡、内定者のフォロー、イベントの出展、説明会の実施といった業務を日々行っています。
採用チームに異動してきて2年目の始めに、リーダーを引き継ぐことになりました。
これまで経験豊富なリーダー中心に業務を進めてきた状態だったので、経験の浅い自分がリーダーになることに不安を感じていました。
自分個人がエースの抜けた穴を埋めるのではなく、チームの皆でカバーできるような進め方をしたいと悩んでいたところ、
開発チームで導入が進んでいたスクラムが目に止まりました。
スクラムが人事の業務改善にも役立つと感じ、導入を決意し、2年ほどスクラムをベースにした業務改善を進めてきました。
プランニングやふりかえりで地道な改善を重ねた結果、モブ作業やカンバンを活用が進み、メンバーの残業が減り、チームのベロシティも向上しました。
現在はチームでタスクがコントロールでき、理想のチームに向かう良い状態が作れています。

改善の過程で起きた問題やそこから学んだこと、チームに起きた変化を紹介したいと思います。

突然ですが、スクラムマスターのキャリア設計って難しいと思いませんか？
アジャイル開発が普及するにつれてスクラムを導入するチームも増えている一方で、まだまだスクラムマスターというロールは一般的ではなく、多くのスクラムマスターは元々の役割と兼務しています。スクラムマスターとして価値を高め、今後キャリアを伸ばしていくためにはどうしたら良いでしょうか。

現在私は週3日サイボウズで正社員として働きながら、週2日は個人事業主として社外のチームをお手伝いするというちょっと変わった働き方（複業）をしています。
このセッションでは、エンジニアからスクラムマスターになり、アジャイルコーチとして複数チーム・組織を支援する立場になった事例を紹介したいと思います。スクラムマスターのキャリアの選択肢のひとつとして参考になれば嬉しいです。

スクラムマスターはプロセスにリーダーシップを発揮します。
では、プロダクトのリーダーシップは誰が発揮するべきでしょうか？
プロダクトオーナーです。
皆さんの現場で、開発チームとプロダクトオーナーの間に距離を感じることはないでしょうか。

より良いプロダクトを作るには、開発チームとプロダクトオーナーの相互の対話が欠かせません。
サイボウズの社内で複数のスクラムチームを支援する中で、開発チームだけでなくプロダクトオーナーを支援する必要があるということを学びました。
ここでは、スクラムマスターとしてスクラムのセレモニーをプロダクトオーナーにとっても欠かせない場にしていった経験を共有したいと思います。

• プロダクトオーナーの抱える問題
  • プロダクトバックログアイテムの分割
  • セレモニーの時間が取れない
  • 開発の見通しが立たない
• プロダクトオーナーを支援する取り組み
  • プロダクトバックログリファインメントの質を高める
  • スパイクの活用
  • スプリントゴールの設定
  • スプリントレビューで未来を語る
  • スプリントレトロスペクティブでメトリクスを活用する

私(@ama_ch)が所属するサイボウズでは、「チームワークあふれる社会を創る」というビジョンを掲げてグループウェアを開発しています。

自分たち自身のチームワークを高めるために、2016年にスクラムを導入しました。私の所属するkintone開発チームでは、スクラム導入から1年以上が経過し、新たに下記のような問題に直面していました。

「スクラムを導入したは良いけど、まだ加速しきれていない気がする」
「チームが壊れないようスケールさせるにはどうすれば？」

これらの問題を解消し、最高のプロダクトを目指すチームを作るために社外のスクラムマスター(@toshiotm)を巻き込んで、より良いスクラムの実践を探求してきました。

1年間の実践を通じて、私たちのチームには以下のような特徴が現れました。
- 複数拠点をまたぐリモートモブ中心の開発
- 新卒エンジニアが1週間で活躍し始める
- スプリントごとにチーム構成が変わる
- 仮説検証マインドにもとづく高速な改善
- スクラムマスターが不要になる

この1年の活動をふりかえり、スクラムが本当の意味で機能し始めたチームに起きた質的な変化、スケーリングの取り組み、私自身に起きたスクラムマスターの役割の変化などについて、一緒に推進してきた社外スクラムマスターと一緒に考察したいと思います。