イノベーションを生み出し、生産性の高いチームを目指すのなら、マネージャーやスクラムマスターはどのように振る舞うかが鍵となります。そこで推薦したいのは「サーバント・リーダーシップ」です。

サーバント・リーダーシップを活かしている人は一方的に命令するのではなく、チームメンバーをどうやってサポートしてあげられるかに重点を置きます。チームメンバーをコントロールするのではなく、チームメンバーに仕えるという態度で接します。

このワークショップでは、サーバント・リーダーシップを効果的に実践するために必要な要素を紹介し、またそれを応用する方法もお教えしていきます。自分のリーダーシップを再考する絶好のチャンスになります。

2016年夏、あるチームが解散となりました。そのチームのうち、社内に残ったエンジニアは一人。当時、彼は一人でプロジェクトをこなしていました。ステークホルダーから感謝されていたので一人で開発を続けていました。しかし、エンジニアとしての成長は殆どありませんでした。切っ掛けでとあるチームでエンジニアを募集していることを知りました。技術スタックもそれまでの事業領域も異なるところでやっていけるのだろうか？と彼は悩みました。そのチームにいるエンジニアと一緒に働きたいという想いからそのチームへ入ることにしました。あの時の彼の決断は正しかった、と今の私なら言えます。

このセッションは、RSGT2020で発表された「Team-Based TEAM - 会社を越えるチーム」に対するアンサーセッションです。RSGT2020当日に初めてこのセッションの内容を知りました。それでも「あぁ、わかる。これは自分たちだ。」と思える内容でした。このセッションでは、Team-basedチームの一員として得られたものが何かについてお話します。

こんにちは！
私達はLED-Camp(※) で毎年スクラムを初心者向けに教えています。

ここでふりかえりを重点的に教えたのですが...LED-Camp が終わった後のアンケートに「ふりかえりは重要ではないと考えている」と答えた人がいました。
何故なのか？そもそもふりかえりは何故必要なのか、どういったときに必要なのか？
必要ってことは分かっている。分かっているんだけども...本当に必要なの！？

この疑問をなんとかして自分の納得する形にしたい！と思い、実践やイベントで様々な意見を交わしていきました。
その際に得た情報や、自分なりに出したふりかえりについてお話します。

この話を通じて、「ふりかえり」について、ふりかえるきっかけになってもらえたらと思います。

※ LED-Campは、組込みシステム開発の初学者や未経験者、また、興味のある方を対象とした合宿形式の勉強会です。若手の社会人や学生が一堂に会し、組込みソフトウェア開発の基礎を学びます。実習を通して、モデル駆動開発とスクラムを学び、チームで解決することを体験します。
詳しくはリンクを見てください！

伝えたいこと

スクラムの原理原則に背くとだいたい失敗するとよく言われます。「事情があってちょっとだけ自分たちのやり方に変えてみたいのですが、、」ともなれば、いずこかのスクラム有識者が「スクラムちゃうがな」と投げかけてくるかもしれません。しかし、それでもやってみてはどうでしょうか？

スクラムは3つの役割、3つの作成物、5つのイベントで構成される軽量で理解が容易なフレームワークです。ところがそれだけシンプルな仕組みであっても、実際に始めるとなるとそれほど容易ではありません。原則通りに始めようとすると、色々と疑問点がわいてきませんか？プロダクトオーナーやスクラムマスターは誰がやるのが良いでしょうか？プロダクトバックログはどうやって作るのでしょうか？スプリント計画はどうしますか？スプリントレビューは必要ですか？スクラムはいつ始められますか？

全ての条件を揃えてからスクラムを始めるのは容易ではありません。しかし、それでもやるしかないのです。なぜなら、正しいやり方を実践するだけの知識や実力や環境が私たちには無いからです。とりあえずやって、失敗して、少しでも原則どおりできるように変えていくのが現在の私たちのやり方です。

2019年4月に私がJOINしたチームはコテコテのウォーターフォールで開発していました。体制変更で突然大きく変化したチーム状態と過去に経験したことがない高難易度な開発テーマで課題が山積みの中、行き詰まりを感じてスクラムの原則を取り入れ始めました。とはいえ私たちはスクラムの経験が無いチームなので、プロダクトバックログも十分に作れない状態からとりあえずスプリントの開発サイクルに移行するなど、経験者から「それやったらアカンよ、たいてい失敗するから。」と言われるようなこともあえてやって、たいてい失敗しながら、従来の開発スタイルを少しずつ変えています。私たちの取り組みはまだスクラムをやっているとは言えないかもしれませんが、少しずつでもスクラムに近づこうと試行錯誤している方々にとっての1つの事例として、「こんなやり方でもできるよ」というストーリーをお話したいと思います。

スクラムと私

株式会社ラクス は中小企業向けのクラウドサービスを提供し、19期連続増収で事業拡大中の会社です。私は2011年に入社し、BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、主力サービスである楽楽精算の大阪開発チームをリーダーとして立ち上げ、2018年からスクラム開発に取り組みました。スクラム開発に取り組んだことで、過去の開発経験も含めてチームが不確実性と向き合い敏捷性を高めていくことの重要性を改めて実感しました。2019年4月からは10年以上続くメール配信サービスの開発チームに異動し、マネージャとして従来型の開発プロセスを少しずつ改善してチームのアジリティを高めていくことにチャレンジしています。

予告動画 : https://www.youtube.com/watch?v=ymZnqdUQ8DE&feature=youtu.be

数度目のアジャイル開発戦争が勃発。
内製開発企業と受託開発企業ではそれぞれのビジネスと命運をかけて防御壁を展開、エンジニア獲得の勢力図がうごいていた。

Scrumの加護をうけし組織となるために工作を展開する企業。
それに反発し自由と共同を求めてオープンなコミュニティをつくりあげるものたち。

終わりが見えない戦争に希望を見出すため、各組織では次世代の旗手をみつけ育成する作戦が遂行された。
そしてミレニアル世代が第一線に配属され、時代はひとつの転換を向かえようとしていた・・・

実験場はどうして必要か？

企業の中で企業を変えようとしているスクラムマスターやアジャイルプラクティショナーの皆様。
コミュニティや本などで仕入れた新しいワークショップや、メトリクスがうまく働くかを会社で試してみたいと思いますよね。

でも、それ大丈夫ですか？
安全ですか？失敗しても大丈夫ですか？失敗しないようにがんばりますか？
でも、失敗ってしたほうがいいんですよね。

会社組織は良い実験場か？

そもそも会社組織の中で最初に実験するのってハイリスク・ハイリターンですよね？
失敗した場合ときには実験を止めたいと思いますが、下手に予算やOKRが決まってたりすると、とりあえず四半期ぐらいは引くに引けない状態になったりして、危険な状態になることがあります。

そうならないように、安全に実験できる場所を探しましょう！
そのためのサバイバルテクニックを考えましょう。

サバイバルテクニック

#1 趣味を増やそう！

単に趣味を増やすことに意味はありません。
社会性が得られる趣味であれば、それは立派に実験場として機能します。

#2 地域コミュニティに参加しよう！

PTAや自治会、地元神輿会など、地域コミュニティも立派な実験場です。

#3 家族を実験に

家族との信頼関係が利用できる場合は、実験目的を話して実験に協力してもらいましょう。
父親、母親、子息、伴侶それぞれ幅広い年齢層に対して実験できます。

このワークショップは一言でエレベーターピッチの強力版です。

次のような悩みに効果的です。
・「良い商品なのに売れない、自社(自分)に強みがあるのにお客様に喜んでもらえない。」
・「日々、頑張っているものの報われないことも多く、意気消沈してしまう」

私は20代前半から新規事業に取り組み、自費でも数百万の借金をするなどして挑戦してきました。良い商品なんだけど売れない、強みがあるのに買ってもらえないとずっと悩み続け、どうしたらお客さんの喜びにつながるのだろうと考え続け、試行錯誤してきました。

そのうち徐々にうまくいくにつれて、お客さんから「弊社のこと、なんでそんなに知っているんですか? もしかして勤めていたことがあるんですか?」と驚かれたり、喜んで値引き無しに買ってもらえるようになりました。

その中で学んだ重要なポイントは開発だけでなく、顧客との付き合い方や売り方もアジャイルに適応してくことです。

今回は「顧客との付き合い方や、売り方もアジャイルに適応してく」ためのワークを行います。顧客と良い関係を結ぶためのヒントがえられるセッションにしたいと思います。

・商品/サービス/強みについて考える
・顧客を考える
・競合を考える
・セールス/プレゼンテーションを考える
・ロールプレイしてみよう/セールスマップでユーザーにも決裁者にも響くアプローチを整理してみよう

「アジャイル開発の事例を聞いたけど、いざ自分ごとで考えるよく分からない…」
「このエピソードは、どこでも起きうる話なのだろうか？」
「自分の現場で起きている課題は、どのチームにも起こり得る課題なのだろうか？」

事例だけ聞いても分からない…一方で抽象化した理論だけ聞いてもよくわからない…みたいなこと、ありませんか？

レッドハットには、現場を支援しているアジャイルコーチが複数人います。このセッションでは、同じ会社だから話せる“場”のなかで、アジャイルコーチ同士で深く共有した事例を通し、チームの成長に伴い起きる課題について、実際に現場で起きた内容とどの現場でも共通でチームにみられる事象を紐づけて話せたらと思います。

今、現場で起きている課題の先に光があるのだろうか？そんなふうに心配している方々に進む勇気を持って頂ければという思いで話させて頂きます。

※本セッションは、「アジャイルチーム成長の過程ってどんな感じ？(20min)」と「アジャイル開発導入事例から分る組織・チーム・個人の課題(20min)」を１つにまとめて再構成するものになります。

※来場者へのアナウンス：このセッションは事前の参加チェックインが必要です。チェックイン方法は、参加者用 Discord の「品川タイムテーブル」チャンネルをご覧ください。

あなたのマネジャーはあなたより暇そうですか？
もし暇そうなら、ぜひ他のセッションに参加し、マネージャーに明日「いつも私にチャンスをくれてありがとう！」と伝えてあげてください :)

あなたのマネジャーはあなたより忙しそうですか？
もしそうだとしたら、そのマネージャーを助けたいと思いますか？
もし助けたいと思わないとしたら、あなたの成功の道も険しいかもしれません :/
あなたの成功の近道は、あなたのマネージャーを助ける事かもしれないのですから。

もし少しでも助けたいと思えているなら、この「お仕事解体ワークショップ」が使えるかもしれません。

世の中のマネージャーの中には、理由は様々あれどなかなかメンバーに仕事が渡せず、それが忙しさの悪循環を招き苦しんでいる人たちがいます。
そういったチームでは、マネージャーが休むと色々な事が回らなくなったり、マネージャーが仕事上のボトルネックとなることで仕事のリードタイムが長くなり、組織のパフォーマンスが制限されるでしょう。
それはマネージャーがマネージャーとして機能していないということかもしれませんが、メンバーからそれを助けることでチームとして一歩前にすすめることだってできます。

「お仕事解体ワークショップ」では、マネージャーとメンバーの対話を通して、マネージャーの仕事を解体、理解し、その仕事をチーム全体で担っていくための具体的なアクションを作ることができます。それは「マネジメント」という行為が、だれか特定の人に依存するのではなく、チームの中に溶けているようなチームを作る一手となるかもしれません。

忙しそうなマネージャーと働いている方、または周りにそういったマネージャーがいる方は、ぜひこのワークショップ体験にご参加ください。
実際にワークショップを組織に持ち帰って実施し、あなたのチームがよりよいチームになることを祈っています！ ;)

※「忙しい人」がマネージャーでなくてもこのワークショップは活用できます。（忙しい PO など）

こんにちは。楽天　ランキングサービスグループの室山です。

楽天市場のランキングサービスでプロダクトオーナーのチームリーダーをやっています。

少し前、トラブルが多発し、モチベーションも低下していたグループの中で、プロダクトオーナーたちはそれぞれが孤独に責任を負っていました。

そこでチームビルディングのやり直しを行って、助け合うプロダクトオーナー組織へと変わりました。
モチベーションも低く疲弊したチームから、心理的安全性の高いチームへ。

どうやって、心理的安全性の高いチームになったのか？

どうやって、メンバーは自走を始めたのか？

どうやって、メンバーは変化を受け入れてくれたのか？

私達が取り組んだチームビルディングと、そこから学んだことをお話します。

メンバーが「仕事が楽しい」って言ったとき、正直ちょっと泣きました。その後のお話も。

プロダクトオーナーだけでなく、チームをリードしている方々と、飲みながらでも語り合いたい！
課題共有の場になれば嬉しいです。

本セッションは、2019年4月にDevLove関西「プロダクトオーナーの現場」でご紹介した
「トラブルだらけの現場から仕事が「楽しい」現場に変わった、6か月間の話」と、その後日談に関連した内容となります。
https://www.slideshare.net/cowappa/ss-141300729
ぜひこちらも合わせてご覧ください。（Slidesの項目に記載したスライドと同じです）

Mackerelというプロダクトはローンチから5年が経ちました。ぼくはそのほぼすべての期間、このチームに在籍していて、うち3年間はマネージャーとしてチームを運営しています。5年間運用されたチームではさまざまなことが起こりますが、いくつか事例をご紹介しながら、長く安定的に続くチームづくりについて考えていきたいと思います。

株式会社i-plugにて自社サービスのOfferboxの開発をしている小西と申します。

Offerboxというプラットフォームの質的改善を加速するために、2019年秋からグロースに特化したチームを組成するというの話が上がり私がチームリーダーとして指揮を執ることになりました。
2019年4月よりスクラム開発をしており、ものを正しく作っていく部分はできるようになってきていたものの正しいものを作る部分は経験がありませんでした。

その状態から価値あるプロダクトを提供できるように他職種(デザイナーやデータアナリスト)の方と協力しながらこれまでデュアルトラックアジャイルのような開発プロセスを構築してきました。
データアナリストとともにABテストをしたりデザイナーとともにユーザーテストをしたり、その結果を踏まえて仕様を磨いたり廃案にしたり提供価値にこだわった意思決定をしています。
また、職種をまたいで連携することで1つ1つの工程のクオリティを高めることにもこだわっています。

そのような現場で具体的にどのようにプロダクト開発を行っているのかという状況であったりそれを実現するまでの過程であったりをご紹介できればと思っています。

IT企業から、大手ユーザー企業のマネージャーに転職して３年間で取り組んだ、プロジェクトマネジメントと組織マネジメントのプラクティスについて良かったことや反省点をお話させていただきます。

始めは1チームのスクラムマスターでした。

外部のアジャイルコーチについてもらい、学びながら、組織的なスクラムの浸透に関わるようになって、組織内でのコーチ業務もするようになっていきました。

気づいたら、スクラムマスターをしながらコーチ業務もするという状態になっていました。

・見るチームが多くて、どこもちゃんと見きれていない。
・コーチとしても動いているけど、スクラムマスターでもある状態で、優先するチームはどこなのか？
・専任スクラムマスターとして複数チームを見るのと、スクラムマスターとコーチを兼任することでは発生する難しさが違う。。
・コーチとしても動けるようになるには何を変えるべきなのか？
・スクラムマスターとコーチで必要な行動、マインドセットは違うのか？

そんな直面した課題や、気づいたこと感じたこと学んだことをお話しします。

システムへの機能追加・変更を安全にするため、味方につけたい自動テストを伴うコーディング。

いざ実践しようと思ったが、既存システムのテスタビリティが低くて難しい。

そんな状況をサポートするテスティングテクニックをライブコーディングで実践していきます。
実際に現場である、テストを入れづらいコードに対してテストコードを追加していきます。

アイデア元 "書籍：レガシーコード改善ガイド"

スクラムショーワークショップは、スクラムの説明をショー（寸劇）形式で行うワークショップです。
このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。

スクラムショーワークショップは、yycr2019（アジャイルコーチとスクラムマスターの宴、通称：よなよなコーチングリトリート）で
生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。

最小100分間のワークショップで、スクラムの動きを身に着けられるほか、
皆さん自身で、スクラムショーワークショップを実践できるようになります。

紹介動画はこちらから！

詳細はこちらの記事をご参照ください。

Imagine you are a Mad Agile Scientist and have a diabolical experiment to conduct - what would happen if you exchanged the brains of a Product Owner and Scrum Master? Mwuhahahaha!!! How would the body of a Product Owner with the brain of a Scrum Master act? And vice versa?

Perhaps the Scrum Master would now treat the team like a backlog? This Scrum Master would be focused on value and maintaining a coaching backlog of team and person improvements. This Scrum Master is refining the team, crafting a group that delivers value.

And perhaps the Product Owner might treat the backlog like a team? Rather than backlog refining, they coach the backlog. They would be focused on nurturing, protecting, and empowering the backlog. The backlog might transform from an irritation into a labor of love.

Although this experiment sounds terrible, this change of perspective might be what you need to reanimate your dead team or backlog.

Join the fun and come learn what horrifying results await!

大事な活動である「ふりかえり」。だが、難しい活動でもある。

スクラムの重要なイベントの一つである「スプリントレトロスペクティブ／ふりかえり」。
チームを自己組織化へと導く大事なステップでもあり、スクラムの中でも一番「チームによるチームのための活動」だと言えると考えています。

スクラムを始めたとき、多くの人が直面するのは、「ふりかえりがうまく機能しない」ということです。
ふりかえりが反省会のようなムードになってしまう。
チームのためのアクションが出ず、なかなかチームがまとまらない。
アクションは出たものの、なかなかカイゼンされているように思えない。
こういった悩みを持つ多くの現場を見てきました。

ふりかえりは、難しい活動の一つとして考えられがちです。
時間対費用効果が出ているのか、なかなか計測がしづらいですし、効果がすぐに現れない場合もあります。
他のイベントと違い、ふりかえりがうまくいかなかったときに、「この活動は価値がないものだ」と感じ取られてしまいがちなのです。
そのまま、ふりかえりが行われなくなってしまうのは、とても悲しいことです。

ふりかえりとファシリテーション

ですが、ふりかえりにはチームが成長するために大事な要素がたくさん詰まっています。
そのうちの一つが「ファシリテーション」という考え方です。

進行役としての「ファシリテーション」ではなく、促す者としてのファシリテーション。
スクラムマスター一人がファシリテーターなのではなく、チーム全員がファシリテーター。
チームが「ファシリテーション」を意識したとき、あなたたちのふりかえりはきっと良い方向へと変わります。

ファシリテーションというものをあなたがどうとらえるか。
そのとらえかたが変わると、きっと新しく見えてくるものがあるでしょう。

このセッションについて

このセッションでは、あなたがふりかえりの中で行うファシリテーションを考えるときの気付きを提供します。
チームの形成、そしてチームの成長・混乱・成熟、そしてチームの解散。タックマンモデルのチームの推移に合わせて、どのようなファシリテーションを検討するとよいのか、といういくつかの事例を示します。

また、私がふりかえりを突き詰めた結果見つけた「8つの型」についてお話します。
「ふりかえりの守破離」を通じて、ふりかえりを導入・成長・拡張していく流れについて、お話させていただきます。

「自分のチームでは今どんなことを意識しながらファシリテーションしているだろうか」
「自分のチームのふりかえりの現状はどんなものか」をイメージしながら、セッションに参加していただければ幸いです。

Reginal Scrum Gathering Tokyo 2020 にて講演させていただいた内容の再講になります。
一部変更やプラスαして話させていただければと思います。

ふくおかフィナンシャルグループ（FFG）では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。

• アジャイル組織の変遷
• 現行ルールのしがらみとの闘い
• アジャイル開発を少しずつ組織に浸透させていく方法
• 組織を拡大していくための対内・対外的な取り組み
• 拡大していく組織で発生した問題
• 成果を出し続けていくための組織やチームの意識改革

私たちは困ったときに相談をしています。毎日、一日の中で何度も相談を持ちかけたり相談を受けたりします。

相談とは「問題解決のために人と話し合ったり、他人の意見を聞いたりすること」です。
「問題解決を協働で取り組む短時間多頻度活動」とも表現できます。

相談は意思決定でもありますから、相談がうまくいけばスムーズに仕事が流れますが、相談がうまくいかないと仕事が止まってしまう原因にもなります。「現場のチーム」や「部署間の相談」「経営者の相談」「お客様との相談」などなど、あらゆるところで何千、何万回も相談は行われています。

もし組織の中で行われる相談という共同活動が劇的な改善をしたら、組織はどのようによくなるでしょうか?

これからも何千、何万回も行われていく相談の質が大きく高めることができたら、非常に大きな効果があると思いませんか?

このセッションでは「相談」がチームや組織に与える影響を整理し、またすぐにできる質の高い相談をする方法を共有したいと思います。チーム内での相談の質を高めること加えて、とくにチームの開発力が高まってきて他の部署との連携や、お客様との打ち合わせが増えてきた方にお薦めです。

※このセッションは2017年に行われた日本TOC(制約理論)推進協議会主催のTOCシンポジウム2017での発表を大幅に加筆修正したものです。スライド参照。