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

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

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

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

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

The concept of antifragile (things that gain from disorder according to Taleb's definition) is crucial if you want to coach a resilient team. In other words, a resilient team is able to survive uncertainty, volatility, stress and variability by changing adaptively rather than always remaining the same. We will see how this can be possible in some contexts, working on the boundary conditions that allow resilience to emerge as a bottom-up property of a work group, through experimentation and continuous learning on the field. I will also explain how in Vodafone (actually involved in one of the biggest agile transformation on scale) we conceived a framework to promote resilience and scrum teams agility on scale.

「スクラム」のフレームワークは、もともとソフトウェア開発に用いられてきました。しかし「スクラム」の経験主義の原則は、短いイテレーションの中で、検査と適用を繰り返すことでプロセスのカイゼンを加速させる事ができます。また透明性の原則によって、ステークホルダーへの説明責任、今何が問題になっているのかを見える化させることができます。

その「アジャイル」フレームワークを「エンジニア採用活動」に適用してみた内容について、発表させていただきたいと考えています。
トラディッショナルな採用活動は秘密主義に根ざしており、独自な文化が根強く残っています。その中で透明性をもったプロジェクト運営をすることで、「採用活動の変化」「ステークホルダーの意識の変化」、検査と適用を繰り返すことでプロセスのカイゼン速度が向上した。

開発部門以外にも適用した事例について、お話させていただきたいと思います。

私(@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のフレームワークの力を借りることで、確実に、よりアジャイルになっていると感じています。
​
この事例紹介を通して、組織間の不和に悩んでいる人、チームメンバーにもっとお互いを助け合って欲しいと思っているリーダーのような人に改善のヒントを共有できるといいと思っています。

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

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

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

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

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

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

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

Pairsを運用する株式会社エウレカでは2018年4月から、それまでの目的別スクラムチーム組織を変更し事業部全体でリアルカンバンを用いたプロダクトバックログの優先順位を忠実に消化できるチーム体制へ変更しました。

このセッションでは4月から今までのリアルカンバン運用の軌跡についてお話しながら、つらみやうまく行ったこと、今後の展望などをご紹介したいと思います。

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

いま、私たちのチームは自信を持ってチーム開発をしています。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人のグループでゲームをやり、そこでの気づきやよりよいコミュニケーションの在り方について議論をしたり、共有したりします。さらにどんな改善が見られるか、再度ゲームをやって試してみましょう。

チームとして、良い『開発プロセス』を設計することは重要です。
ROIを高めながら、どうやってプロダクトを『最速』でリリースし、仮説検証を『高速』で繰り返せるかを常に考える必要があります。
そこで、重要なポイントとして気づいたのは、EBM(Evidence-Based Management) の概念におけるT2Mの部分『プロセスの見える化』と『ムダからの解放』です。
今回は、理想の開発プロセス(EBM(Evidence-Based Management) to 『Lean x Scrum』)から、VSM x SIPOC分析による『プロセスの見える化』の実現から分析プロセス。
そして、見える化することでわかる『ムダ』の解放をどのような工夫で行ってきたかをお話できればとおもいます。

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

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

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

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

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

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

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

こんにちは。椎葉です。

僕は楽天でWebアプリケーションエンジニアとして働いています。数年前に「エンジニアとして色んなチームを内側からサポートしたい！」と考えて「改善グループ」というグループを立ち上げました。そして、様々なチームの中に入っていって、一緒にコードを書いたり、テストを書いたりして楽しんでいます。

そんな風にエンジニアとして動くことを中心にしてはいるのですが、実は毎回最初にやるのはチームの開発プロセスを一緒に改善することなんです。というのも、エンジニアとして動くための土台としての開発プロセスが、とても重要だからです。

僕の所属しているECインキュベーション開発部では、どのチームもスクラムで開発をしているのですが、この活動の中でよく聞いたのは「スクラムをやってはいるのだけど、何かうまくいかない」ということです。

このセッションでは「スクラムが何かうまくいかない」と感じているチームに実際にどのような課題があったのか、その原因は何だったのか、そしてそれをどのように改善したのか、を失敗談も交えながらお伝えしたいなと思います。

同じような課題を感じている方が一歩踏み出すきっかけになるといいなと思います。そして、セッションの後にはみなさんと「うちもこういうことがあるよー・あったよー」みたいな話をできたら嬉しいです！

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

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

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

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

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

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

http://bit.ly/2OCzYA9