ScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。

そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。
そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。

その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。

ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の１つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。 (Wikipediaより抜粋)

このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。

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

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

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

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

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

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

2018年、15年勤めた富士通、NRIというSIerを辞め、Leveragesというベンチャーのサービサーに移籍しました。

これまで、SIerやそのお客様先でSCRUMの導入を支援してきましたが、実際のWeb系のサービサーでのSCRUMはまったく毛色の違ったものでした。

でも、どちらもSCRUM！全部SCRUM！

規模や価値観やビジネスモデルによるSCRUMの取り入れ方の差を身体で感じ取った話しをします。

大企業の中でファーストケースとしてのアジャイルを生き延びさせるには？

起きてくる現場と社内との課題、その時マネージャーにできることは？

https://www.youtube.com/watch?v=7xhxIYYMmTc

チームがうまくいっていることはスクラムチームの大きな目標です。

いくつかのスクラムチームに関わってきた立場から、良いチームになるための1つの大きなアプローチを見つけました。私が関わってきたチームでは、最初から1DaySprintをやりつづけています。また、1 Hourのタイムボックスを持つチームもあります。またそれらはたった数日で成されます。

良いチーム、美しいチームとはスクラムという視点だけにはとどまりません。あるチームでは、15minSprint、1hourSprint、1DaySprint、1WeekSprint、1MonthSprintを構成したフラクタルなスクラムを実践しています。

数万年に渡る生物の美しさ、クリストファー・アレグザンダーが発見してきた美しさ、といった視点からスクラムやチーム、そして理想像を整理します。

職能型組織からメンバーが集められてプロダクトチームを作るような場合、それぞれの役割の間にあるグレーゾーンのタスクを誰が拾うのか、お互いのロールが何やっているのか見えづらい、などの問題が発生しがちかと思います。
私たちのチームでも大きく以下の役割ごとの組織から集められたチームでした。

• プランナー（プロダクトデザイン、企画、グロースを担う役割）
• デザイナー
• フロントエンドエンジニア
• サーバーサイドエンジニア
• QA(Quality Assurance)

また、プランナーとデザイナーは東京、エンジニアとQAは福岡と物理的にも離れた中作られているチームです。
もちろんそれぞれがいいプロダクトを作りたいという思いを持ってやっていたのですが、
プランナー側には以下のような不満があり、

• エンジニア側の見積もりが適切かわからない(必要以上にバッファー積んでないだろうか？)
• エンジニア側が十分に効率よく働けているかわからない(人を余らせているのではないだろうか？)
• エンジニアの売り上げに対するコミットメントが低いように感じる(締め切り守る気あるのだろうか？, オーバーエンジニアリングしてないだろうか？)
• 変更を柔軟に取り入れてデッドラインも守るようにしてほしい(差し込み開発入れたいこともあるけど、走ってる大きな機能追加のデッドラインはずらしたくない)

エンジニア側には以下のような不満がありました。

• 見積もり前にビジネス側で開発のスコープとデッドラインが決めないでほしい
• 開発する機能に関して背景や目的があまり納得できない
• 開発する機能の優先順位がわからない
• プランナー側が作成する要求や仕様が不正確だったり、不十分だったりするせいで、開発期間が延びていると感じているのに理解されていない気がする

​
そんな中、社内アジャイルコーチによるエンジニアチームでの振り返りワークショップをきっかけに、エンジニアが週1の改善 MTG を開始し、不満をためることをやめ、プランナー側へ歩み寄るという行動を始めました。
仕様が期待するものでないのは、エンジニア側からどんなものが欲しいのか伝えられてないからだということで、要求仕様の書き方の模範例を一緒に作る取り組みを始めたり、リモートランチなど直接的に仕事とは関係ないコミュニケーションの量を増やしたりしてお互いの理解を進めていく一方で、KanbanやScrumの社内研修をプランナーとエンジニアで一緒に受けてAgileな開発に関する共通認識を一緒に作っていきました。そして、Scrumからいいところを学ぼう、チーム改善のヒントを得ようとして開催された社内Scrum研修を受けた後、あれScrum導入してもいいんじゃない？とプランナー側、エンジニア側どちらともなく思ってScrumでの開発が始まりました。
以下のような制約がある中の導入でしたが、それらを受け入れながら、チームの自律的、協調的な動きはScrum導入後加速したように思います。

• プランナー組織構造の都合上、1人のPOは選出しにくい
• QAを担当する独立した組織があり、社内にQAの責任者入るものの、実際の手動テストは外部委託
• 開発チームに共通の言語がない(チームメンバーは中国人、台湾人、日本人、アフガニスタン人で構成され、日本語を話せない外国人、英語を話せない日本人がいる)
  ​

私達は理想的なScrumを実践できている訳ではないかもしれませんが、継続的な改善とお互いの歩み寄りを積み上げ、またScrumのフレームワークの力を借りることで、確実に、よりアジャイルになっていると感じています。
​
この事例紹介を通して、組織間の不和に悩んでいる人、チームメンバーにもっとお互いを助け合って欲しいと思っているリーダーのような人に改善のヒントを共有できるといいと思っています。

みなさんは楽しくふりかえりをできていますか？

スクラムでは「レトロスペクティブ」というイベントとして、チームの活動の一環として定義されている「ふりかえり」。色々なチームの話を聞いていくなかで、ふりかえりがなかなかうまくいかない、というチームが多いという現状が見えてきました。

マンネリ化してしまったり、ふりかえりがスキップされてしまったり、アイデアがなかなか出てこなかったり。そんな状態から脱却するためには、まずは「場」を作ることが大事だと考えています。

場とは、心理的・物理的なさまざまな側面からなる流動的に変わっていく生き物のようなものです。この場を参加者全員の力でよい方向に形成することで、チームがより高く成長するためのアイデアが出やすくなります。

場とは何か。そして、場を作るためにどんなことをすればよいのか。また、ふりかえりを楽しくするためのやり方にもフォーカスを当てて、「ふりかえり」全般についてお話できたらいいな、と考えています。

以下のことを中心にお話いたします。

• ふりかえりの３つの目的と３ステップ
• ふりかえりにおける「場」とは
• 物理的・心理的に場を作るための方法
• ふりかえりをより楽しくするための方法
• ふりかえりのさまざまな手法

どのようにするとより良いチーム開発ができるのでしょうか。

いま、私たちのチームは自信を持ってチーム開発をしています。1週間スプリント中の1日スプリント、当たり前に行われるペア・モブプログラミング、チームの活動に合わせた工夫のあるタスクかんばん、多くのプラクティスを実践することで安定してチームの成果を出しています。

しかし、スクラム導入からしばらく、自信を持ってチーム開発をしているとは言えない状態でした。

メンバーの状態に左右されるベロシティ、レビューで発覚する未完了、再計画されないデイリースクラム、さまざまな課題がそこには存在していました。スクラムのことを良く分かっておらず、言われたことをやっているだけの状態だったため、改善のサイクルをうまく回せないことが続きました。チーム開発に対する不安が大きい時期です。

このような状態から大きく変わる転換点となってくれたのが、チーム全員で参加したRSGT2018でした。

本セッションでは私たちのチームがわかったRSGTの素晴らしさと、チーム開発のはじめの一歩を紹介します。

―――憶測や独断ではなく計測されたデータや事実に基づいて意思決定している者だけが石を投げなさい―――

多くのWebサービスがそうであるように、Quipper が運営する「スタディサプリ」においても長らく"負債"と呼ばれる機能を抱えてきました。

関係者曰く「なぜこんな機能を早く消してしまわないのか」…

しかしA/Bテスト・統計的手法・エンジニアリングを組み合わせ、「その機能がどれだけ売上に貢献しているのか」という価値を定量化した結果、"負債"と呼ぶのは相応しくないと認識を改めることになりました。

本セッションではその事例をご紹介しつつ以下の内容についてお話できればと思います。

• Quipper が実践しているA/Bテスト
• 定量データに基づく意思決定
• 価値の定量化が開発体験やチームにどのような影響を及ぼしたか

Jeff Sutherland氏とKen Schwaber氏がスクラムを作る際に参考にした『The New New Product Development Game』には以下のように書かれています。

"Stop running the relay race and take up rugby"

2019年という日本でラグビーワールドカップが開催される記念すべき年、スクラム実践者の皆様とラグビーという別の角度からスクラム開発を見つめ直したいと思います。

チームの中で、なにか事件が起きたとき、誰がどういう反応をするかでチームの底力が垣間見えます。「心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。

「心理的安全性ゲーム」はカードゲームですが、勝敗はありません。マズい状況を発見して報告してくれた「平和を破壊する役」に対して、各メンバーは手札から「発言」を選んで反応します。10分ていどで遊べる簡単なゲームになります。

このゲームは文字通り、心理的な効果を体験できます。たとえゲームと分かっていても、「教えてほしい」と頼んでいるのに「舌打ちをして」「自分でやれ」と言われるとちょっと傷つきます。言ったほうも、あとで心苦しくなったりします(あるいは、スカッとするかもしれません)。そうしたやりとりを目の当たりにしたチームと一緒に、よいコミュニケーションについて話をするきっかけを作るゲームです。

4-5人のグループでゲームをやり、そこでの気づきやよりよいコミュニケーションの在り方について議論をしたり、共有したりします。さらにどんな改善が見られるか、再度ゲームをやって試してみましょう。

みなさん、仕事上で理不尽な思いをしたり、仕事でなんだか不完全燃焼していませんか？

自分ではなくても前は仕事をバリバリと精力的に活動していたのに、今は元気がないなぁって人がまわりにいませんか？

社会人生活や人生において、ロジカルには解決できない問題がたくさんあります。

そのような問題を解決・解消するひとつの方法として、皆さんに「対話」を紹介し、少しでも健やかに日々を過ごしていただきたいというのが、このプロポーザルを出した理由です。

本セッションでは、プロコーチ、組織コンサルタント加藤 雅則さんの著作『自分を立てなおす対話』で紹介されている『智慧の車座』をやってみたいと思います。

https://www.amazon.co.jp/dp/453231707X

智慧の車座は、問題を抱えたテーマオーナー(相談者)と、複数の支援者の対話を通して、「問題をほぐし」「智慧を出し合い」解決方法を模索する対話法です。

このワークショップ参加後に、以下のような状態になればよいなあと考えています。

1. 「自分を立てなおす対話」とは何かを知る
2. 「自分を立て直す対話」を(なんとなく)できるようになる

人生に迷っているあなた、このワークショップに参加して、暗闇の荒野に進むべき道を切り開いてみませんか？

興味を持たれた方はぜひ、投票をお願いいたします。

「対話こそ、金より輝かしく光よりいのちあるもの」（ゲーテ）

プロダクトオーナーの育成、支援はスクラムマスターの役割であり、難しさである、という事は巷でよく聞く課題です。

確かに、私も過去に現場でそのような状況に直面することがあり、プロダクトオーナーの立ち位置やチームとの関わり方、支援の方法について悩むことがありました。

一方で、私たちClova関連チームのプロダクトオーナーは、POという役割も、スクラム開発も初めてという状態での抜擢。

未経験による悩みだけでなく、ソフトウェア開発とのギャップを感じていました。

このような状況で、私たちはプロダクトオーナーが抱える悩みや問題は、開発チームの課題として一緒に解消する事にしました。

本セッションでは、Clova関連チームのプロダクトオーナーと共に登壇します。

複数の立場から、開発チームとの関わり方やプロダクトオーナーが躓きやすいポイントを紐解きながら紹介できたら幸いです。

「チームのメンバーで喧嘩できてますか？」

自分が言いたいことが相手の意見と対立しそうで、伝えなかった…。
言ってもわかってもらえないと思ったので言わなかった…。
このチームでは余計なことをすると指摘されそうで面倒臭いのでやらなかった…。
そんな体験はないでしょうか？

自分の伝えたい考えをきちんと伝える。相手が伝えたい考えときちんと向き合う。
これはチーム内での会話の仕方でもありますが、チームの空気感というか文化からも影響を受けると考えます。

「喧嘩できる」というのは対立構造ということではなく「喧嘩ができる」チームの空気感があるというある意味「健全なコミュニケーション」が行える状態についてお伝えしたいと思います。

その改善として、このワークでは組織や文化の理論もお話ししながら、学びと体験をお届けします。

2018/10/19
同ワークショップを企業で実施した時の記事が公開されました。

http://bit.ly/2OCzYA9

Scrum / Agileは非常に人間的なアプローチです。

そして、それが大きな魅力である一方で、これまで、プロセスで縛ることにより開発を実践してきた人にとっては、理解できない、導入できない原因ともなっています。

アジャイルの実践者に現場の課題を相談した際に、よく返ってくる返事の一つが、「It depends(状況による)」です。

この言葉はまさしくそうなのですが、アジャイルコーチが入っているような現場ではなく、あまり経験のない人にとっては、自分たちの状況を見てもどうしたらよいか分からなく、手当たり次第に思いつきを実施してみたり、原理主義のようにプラクティスを遵守しようとしたりしてしまう原因となっています。

本セッションでは、心理学の一分野である行動分析学に基づき、Scrumの課題を見付け、その課題を解決する方法を見つける科学的な方法を提案したいと思います。

本セッションの内容により、改善を促したいプロジェクト/チームをどのようにScrumがうまく機能する体制にし、文化として根付かせるかの汎用的な手法を知ることができます。

アジャイルコーチだった私は、昨年のRSGT2018のすぐあと企業に就職しました。EC/製造販売業を営む企業で、内製システムの開発とECサービス/生産管理および社内IT資産のすべてを運用管理するIT部門の部門長を務めてます。

外部コーチから転身して圧倒的当事者として直面したのは、巨大なレガシーコードとシステムトラブルの山、洪水のような運用アラート、疲弊したエンジニア、諦め…私がやるべきことは、チームコーチングや仕組みづくりよりも、本当に必要なシステムとサービスを提供することです。

そんなIT部が、この一年間(応募現在で9ヵ月)でいくつかの功績を産み出すことに成功し、社内での信頼を取り戻しつつあります。その道のりをチームと共に工夫してきたことを、プロダクトバックログを管理するという立場から整理してみたいと思います。

• 部長、知らないでは済まされませんよ
• システムアラートが止まらない
• 事業部長連絡会にプロダクトバックログを持ち込む
• 小さなAwesome
• 何かを減らさなければ
• 半分の時間と倍の効果とプロダクトバックログ
• マインドやない、マネーの話やで

コメントいただければ、それを踏まえて構成して行きたいと思います。ぜひコメントください。

チームがうまくなるために、「学習」と向き合うことはとても大切です。
私がこれまで関わってきたチームでも、アジャイル開発を通してチームがうまくなることに取り組み続けてきました。

ところが、最近新卒向けの研修に携わった際に衝撃を受けました。

ビジネス採用として入社したためプログラミング未経験だった新卒の彼らは、当初は黒い画面（ターミナル）すら怖がっていましたが、数カ月後にはメンター陣からのインプットを頼りに、

• 1 day timebox
• 1 hour timebox
• モブプログラミング
• プロトタイピング
• ユーザーインタビュー

などをまわしながら、3週間でプロダクトを作れるようになっていました。
その道のプロフェッショナル達がエクストリームだと思うこと／どうはじめたらいいのか悩んでいることを平気で突破してしまったのです。

もちろん彼らはプロダクトを本番リリースしたわけではありません。
もちろん彼らは運用しながらお金を稼いでいるわけではありません。
でも彼らはプロダクトづくりの経験をもっていませんでした。
でも彼らはプログラミング経験ももっていませんでした。

私達は、

• 学習し続けていく中で固定観念に囚われてしまうことがあること
• 学習をしていないことが圧倒的成長スピードを生むことがあること

という事実に向き合う必要があります。

学習を積み重ねていくことで成長スピードが落ちてしまうのではなく、学習を積み重ねていっても成長スピードを落とさないチームをどうつくるか。そのためにはUnlearn（学びをリセット）がキーになります。

このセッションでは、そろそろ言い訳するのはやめてもっとうまくなるためにはどうすればいいのかを真剣に考えます。もっとうまくなるための学習する／Unlearnするチームについて一緒に考える時間にしましょう。

皆さん、開発をエンジョイしてますか？
開発を行っていると楽しいこともありますが、様々な問題が発生してツラいこともあると思います…

そんな問題に直面したとき、皆さんはどう対応していますか？
Try & Errorを繰り返しながら、困難な問題と闘い続けているのではないでしょうか？

そんな皆様、お喜びください！

このセッションは、Scrum Patternsを使った問題解決の紹介するだけでなく、実際にそれを体感できるワークショップを開催させてもらおうと思います！
多くの現場で有効なパターンを学ぶことで、明日の現場に役立つ方法を持ち帰ることができます。

パターンとは既に実証済みの解決策

パターンは建築家アレグザンダーの提唱した『パタン・ランゲージ』で挙げられており、パターンの構造は以下のようになっています。

❝ある「文脈」で繰り返し起こる「問題」の「解決」する方法。その方法にはいくつかの「制約」が課せられているかもしれない -- 結城浩

私たちはそのパターンを通して、先人たちの知恵を学ぶことができます。
パターンは時に知っていると思い込んでいる事に関しても新しい視点を与えてくれたり、改めて解決方法の目的の真意を思い起こさせたりします。

そんなパターンを中心にみんなで問題を議論し、よりよい解決方法を見出したいと思っています。

皆さんがお持ちの悩み、既にパターンに書いてあるかも？

ワークショップに関して

ワークショップを開催するのは、アジャイルコーチやスクラムマスターを中心とした、パターン大好きメンバーが集まったグループ "Scrum Patterns Tokyo (通称SPaT)" です。
パターンを知らない人や、アジャイル開発初心者でも楽しめる場を提供したいと思います。

１組４、５人で４組を想定しており、各チームに１人SPaTメンバーがフォローに入ります。

みんなでパターンランゲージを楽しみましょう！

ワークショップ登壇者

• 天野 祐介
• 原田 厳
• 稲野 和秀
• 木村 卓央
• 川口 恭伸
• 小坂 淳貴
• 笹 健太

参考サイト

Scrum Patternsに関してはScrum PLoPのサイトがあります(英語)
http://www.scrumplop.org

※本セッションではSPaTが日本語訳したパターンカード(仮)を使用します。

英語が苦手な方でも問題ありませんのでご安心下さい。

サーバントリーダーシップを実践するにあたって様々な場面で振る舞いを考えさせられることがあります。

上司への向き合い方、配下リーダー陣への向き合い方、はたまた彼らのメンバーに向けてもこれまでとは違う振る舞いをすることが多いです。

本セッションではRochelle Koppさんと一緒に具体的なシチュエーションを題材にしながら旧来のマネジメントとサーバントリーダーシップの振る舞いの違いについて実例を挙げながらお話したいと思います。

これによりこのマネジメント手法がより身近なものに感じて頂ければ嬉しいです。