スクラムの生みの親であるジェフ・サザーランド博士らが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年の活動をふりかえり、スクラムが本当の意味で機能し始めたチームに起きた質的な変化、スケーリングの取り組み、私自身に起きたスクラムマスターの役割の変化などについて、一緒に推進してきた社外スクラムマスターと一緒に考察したいと思います。

作るものに納得感がない、いつも納期に遅れる、改善ができない…

このような問題を解決してチームワークを発揮するために、サイボウズでは2016年10月から私が所属するkintone開発チームでスクラムを導入しました。

チーム全員が未経験の状態でスクラムマスターになり、沢山の壁にぶつかりながら試行錯誤を繰り返してきました。このセッションではサイボウズでのスクラム導入で取り組んだ活動をふり返りながら、開発プロセスや品質・チームの文化に起きた変化をご紹介します。

さらに他チームや他部署のみならず総務や営業の現場にまで及んだマインドセットの変化・アジャイルプラクティスの導入についてもお話します。アジャイルの考え方は開発以外の現場でも活用できることを実感し、現場改善や組織変革のヒントにしていただければと思います。