Today, most products and services organizations focus their collective attention overwhelmingly on delivering things right – on schedule, on budget, with complete scope and quality. Relatively little collective attention is paid to whether they are delivering the right things that solve their real problems. Gabrielle will talk about moving to an outcome delivery model; including case studies and how to get started.

Outcome Delivery uses Mobius double-loop learning , helping you to focus on what problem to address, how to detect if it’s the right problem to address, how to get and analyze feedback to decide whether to continue or change tracks.

Direct URL:

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

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

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

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

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

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

Direct URL:

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.

Direct URL:

Direct URL:

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

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

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

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

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

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

Direct URL:

Direct URL:

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

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

Direct URL:

Direct URL:

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

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

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

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

Direct URL:

Direct URL:

こんにちは。椎葉です。

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

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

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

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

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

Direct URL:

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

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

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

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

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

Direct URL:

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

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

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

Direct URL:

Direct URL:

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

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

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

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

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

Direct URL:

The best organizational changes in my career have happened as a result of emergencies. Support for the process of experimentation only seems to become enabled whenever the status quo has completely broken down. In those moments of crisis rebuilding with better has been possible, but why do we wait? In this talk I share our experiences with experimentation at Hunter and encourage you to develop a culture of continuous improvement and continuous experimentation that will get you to where you want to be without having to be in a crisis mode.

私にとっての過去最高の組織的変化は、緊急事態の結果、起こりました。ふつう、仕事上で実験できるのは、今のやり方がうまくいかないときです。危機的状況においては、抜本的な再建が可能です。しかし、指を加えて危機を待つ必要があるのでしょうか？本講演では、ハンター社が行った実験について話します。そして、継続的改善と継続的実験の文化を発展させて、危機的状況に陥ることなく、望ましい状態に進むことをお勧めします。

Today I am the director of a new software development department and we continue to utilize Mob Programming as well as many other practices. This presentation is about my journey through software development and specifically the experiences I have had with the process of software estimation. We are currently a department of 27 with 6 full time mobs; each team does not estimate software but instead practices pure Kanban and delivers vertical slices of software daily. Hunter is not the first place I had dropped the practice of software estimation for a project. Back in 2007 I was working in an Environmental Chemistry and Military Contracting organization that had a more traditional waterfall environment. During that time, we created a Gantt chart of how each project would go until one day there was an emergency that prompted us to do things slightly differently. I have come a long way and experienced many iterative steps through my software development journey. Let’s start with where we are today and work our way back discussing practices and insights we discovered on the way.

現在、私は新しいソフトウェア開発部門のディレクター(責任者)を務めています。私たちはモブプログラミングと他の多くのプラクティスを継続的に使っています。本講演では、ソフトウェア開発を通した私の旅、そして特にソフトウェア見積りのプロセスで経験したことについて話します。私たちの部署では、27人が6つのモブで終日作業しています。各チームはソフトウェアを見積もるのではなく、純粋なKanbanを実践し、ソフトウェアの垂直スライスを毎日提供しています。私がプロジェクトのソフトウェア見積もりを廃止したのは、ハンター社が初めてではありません。2007年にわたしがいた環境化学と民間軍事の組織は、もっと伝統的なウォーターフォールの現場でした。わたしたちがその時作ったのは、やり方を少し変えざるをえない事態が起きない限りはプロジェクトの先行きを見通せる、といったガントチャートでした。私はソフトウェア開発の長い旅を通じて、多くの実験を繰り返してきました。私たちの現在の状況からスタートし、どんなプラクティスを議論し、どんな発見をしてきたのかを話していきます。

Direct URL:

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

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

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

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

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

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

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

Direct URL:

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

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

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

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

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

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

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

Direct URL:

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

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

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

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

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

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

http://bit.ly/2OCzYA9

Direct URL:

Direct URL:

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

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

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

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

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

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

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

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

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

Direct URL:

Direct URL:

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

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

Direct URL:

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

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

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

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

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

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

Direct URL:

Direct URL:

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

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

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

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

Direct URL:

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

Direct URL:

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

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

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

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

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

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

Direct URL:

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

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

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

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

Direct URL:

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

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

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

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

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

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

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

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

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

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

ワークショップに関して

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

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

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

ワークショップ登壇者

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

参考サイト

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

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

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

Direct URL:

Direct URL:

株式会社エス・エム・エスキャリアの辻岡です。

弊社は人材紹介事業を主に、医療介護通じて働く人と日本を元気にする会社です。

私は社内の人材紹介エージェント（キャリアパートナー）が利用する業務システムの開発を主に担当しています。2年半前に弊社に転職しました。

入社当初配属された部署には以下の課題がありました。

• 現状の課題をあきらめがち
• 全員目の前の火消しや依頼に対応するのが精一杯
• 正社員が誰も実装してない。一切ソースコード見てない
• 開発計画の正否の考え方が短期目線なものばかり
• 社員数 << 他の会社から来てくれる人数。→人の管理者状態。
• リリースしてもトラブルがあっても殆どキャリアパートナーに連絡しない

etc…

YAMAZUMI(山積み)

ある日１つのチームを持つことになりました。

彼らにアジャイル手法を伝え続けてチームの輪が出来始めた頃。

私は一人で抱えたチームのリーダーシップを一度捨てました。

そしてそれをチームの輪の中に置きました。

リーダーシップを一度捨てることで全員がオーナーシップを持って課題を乗り越えていくチームができた事例を紹介したいと思います。

発表スライドはこちら

https://www.slideshare.net/AtsukoTsujioka/rsgt2019-127663850

Direct URL:

Direct URL:

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

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

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

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

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

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

私達は、

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

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

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

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

Direct URL:

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

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

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

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

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

Direct URL:

Direct URL:

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

"Stop running the relay race and take up rugby"

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

Direct URL:

Direct URL:

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

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

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

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

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

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

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

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

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

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

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

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

Direct URL:

Direct URL: