今回のRSGT2018、キーノートスピーカーのリチャード・シャリダンの著書『ジョイ・インク』の言葉を引用します

”働いているときも、休んでいるときも、子供の学校にも、教会のコミュニティにも、家族のあいだに、国家に、誰もが喜びを求めている。人間は自身を超えるものを目指し、お互いにつながろうとするように、生まれついている。だからこそ僕たちはチームに参加し、会社に属し、必死に努力を重ねて困難なゴールを共有し、立ち向かう”　

そうそう、あなたが、RSGT2018に来たのはこのためですよね？”喜びに”　向かいたいから、or　むかうために、仲間を求め、知見を求め、このカンファレンスならば得られるのではないかと思い、参加されたのだと思ってます。

誰もが自分の人生のリーダーです。
自分で自分を鼓舞しながら、ステージを変えてきた皆さんがどこまで役割を担う人生をえらぶのか、この場でみなさんで考える場になればと思ってます！

ある日本人ソフトウェアエンジニアが、アメリカ移籍後に体験したソフトウェア開発の変遷と学んだことをお話しします。

It has never been easy to change its development process for either an engineer or a team, because it is more than just a process. It is a change of culture, mindset, tools that the entire team, division or even the whole company needs to apply. I was in a fortunate position where I was able to observe and/or experience the big shift of software development processes happened within Microsoft in the past seven years. In this talk I am going to share my experiences as a software engineer in Microsoft, mainly focusing on 1) when I joined an agile team and 2) when a team transitioned from waterfall to agile.

Building a great software service needs to be customer-focused, data-driven, and fun-driven. This is culture that the management team is mainly responsible for. As software grows, it is more important to embrace collaboration rather than competition. But it does not mean that every team member can do the same things; it means everyone is different has different skill sets and the management team needs to direct them effectively.

There have been a number of learnings since I, a Japanese engineer moved to the U.S. regarding how to work as a software engineer. I am going to cover some of them which are highly related to the recent trend in Japan regarding working improvement.

Menlo Innovations CEO Rich Sheridan had an all consuming thought during a difficult mid-career in the chaotic technology industry ...

things can be better. Much better. He had to find a way. His search led him to books, authors and history, including recalling childhood visits to Greenfield Village every summer. The excitement of the Edison Menlo Park New Jersey Lab served as his siren call to create a workplace filled with camaraderie, human energy, creativity and productivity.

Ultimately, Rich and his co-founder James Goebel invented their own company in 2001 to "end human suffering in the world as it relate to technology" by returning joy to one of the most unique endeavors mankind has ever undertaken: the invention of software.

Their unique approach to custom software design, they named it High-tech Anthropology® has produced custom software that delights users rather than frustrating them. The programming team creates the software that works every day without the emergencies that are all too common in the tech industry. The process itself is so interesting that almost 4,000 people a year travel from around the world just to see how they do it. Many spend a week or more studying "The Menlo Way" being taught by the Menlonians who love to share their experience and knowledge.

In 2013, Rich and his publisher Penguin Random House took a chance that a business book with the words joy and love on the cover might have impact. They had no idea how the world yearned for such a message. His best selling book, Joy, Inc. - How We Built a Workplace People Love now has Rich traveling the world speaking about joy, creativity, and human energy in the workplace.

妨害リスト（Impediments List ) を会社全体で運用して見えてきた組織課題の解決の仕方について、お話したいと思います。

妨害リストを運用するからこそ、客観的に「問題vs私達」にフォーカスすることができます。Scrumで運用されている妨害リストですが、開発組織外でも運用することで会社全体でプロセスを阻害していることを解決することができた事例について紹介させて頂きたいと思います、

全社にカイゼン文化が浸透していて、それぞれの現場で独自のカイゼンが実践されています。

エンジニア、総務、広報・販促、データ作成、インフラ、新規ビジネスなど、あらゆる部門で日々カイゼンが繰り返されています。
総務や広報・販促のメンバーも「スプリント」「WIP」「レトロスペクティブ」など、アジャイル用語を日常的に使っており、コモンセンス化しています。

もちろん、たった一人の人間の力だけでそんなソシキカイカクはできるわけありません。

でも、そのリテンションのコツやマンネリ化を打破する方法など、根底に流れる価値観や
私が実践する「たった一滴の魔法」を紹介します。

会社も身体もリーン体質になる魔法です。
お楽しみに。

Scrum is a set of well-defined rules that enable teams to work effectively to deliver valuable products. Scrum Guide is the rule book of Scrum. You are requested to follow the rules to get benefits of Scrum.

But why do you need to follow Scrum rules? Scrum says it is crucial to inspect and adapt. So why not inspect how Scrum rules work.

This session explores the history of Scrum with patterns. The first Scrum paper was published in a form of pattern language. By looking how these patterns have evolved, we hope to see how these Scrum rules are formed and have better understand why they are rules.

This session concludes with the update of ScrumPLoP.

This session can also be delivered in Japanese.

地獄のデイリースクラムやります！

スクラムの中でも、比較的とっつきやすいイベント『デイリースクラム』
しかし、現場ではこんな光景をよく見かけますね・・・？

• 毎日できていない
• 時間通りに始まらない
• 特定の人しかしゃべらない
• デイリースクラムがお通夜みたい…
• そもそもやっていない…

このワークショップでは、そんな悩みを解決いたします！

　　『どうやったらデイリースクラムが良くなるの？』
　　『スクラムマスターは何をしたら良いの？』

皆さんと楽しく体を動かしながら、一緒に体験していきたいと思います。

(名前は怖いですが、内容は恐くないですヨ！)

イベント終了後、私たちが知らなかったデイリースクラムの一面を発見出来るかもしれません。

セッションに採択されましたら、職場で手軽に地獄を味わえる、自作『~地獄のデイリースクラム~ 地獄カード』の配布や『地獄カードデータ』のダウンロードサービスなどを検討いたします！！

あと！RSGT2018を盛り上げるセッションになるようにがんばります！
しっかりがんばります！ちゃんとします！

～毎日のことだから ちょっとの工夫で大きな差！～

『地獄のデイリースクラム』とは？

地獄のデイリースクラムとは、2004年10月にデンバーのScrum GatheringでWilliam C. Wake氏によって行われたチームでデイリースクラムについて学ぶ ことができる「Daily Scrum From Hell」をもとにしたワークショップです。

When speaking about agile transformations or adopting agile, culture plays a fundamental role. Different cultures leads to different results, depending on the context itself.

We cannot consider the culture something that can be changed by design, or something that can be put into people's mind. This approach will lead to several and different antipatterns (dark scrum) that ends into a poor or very weak agile mindset.

In the past we had the Toyota way copied by Western companies, too much focused on practices instead principles, today we're making the same mistake again: Agile adoption is usually focused on practices instead principles (everybody copying the Spotify Model).

So how can we change this behaviours? Using rituals to shape organizations' mindset. Rituality is important and it is scientifically proven that rituals are able to change people's cognitive style giving them sense of purpose in a wider cultural context, in which a safe, genuine and pure Agile identity can set solid roots.

このセッションでは、アジャイルコーチとして様々な現場のふりかえりを観察、ファシリテートしてきた経験から得た“ふりかえり”の始め方と続け方をお話します。

”ふりかえり”の目的は大きくは以下の2つです。

1. 自分達の仕事のやり方をもっとうまくできるようにすること
2. (うまくできるやり方を考えるために)仕事の手を止めて立ち止まること

この目的を実現するために様々なことにファシリテートするスクラムマスターは意識することがあります(できれば参加者全員が)。

• どのようなデータを収集すればよいか？
• どういう話し合いのやり方をすればよいか？
• 継続的にうまくできるように気をつけることは何か？

また以下のような"ふりかえり"あるあるに出会うこともあります。

• ふりかえりといえばKPTとばかりに同じやり方をしてマンネリしてしまう
• うまくできるようにするアイデアが実行されない
• なんとなく続いているんだけど効果がわからない

このようなトピックをお話することで、みなさんのふりかえりをよくするヒントになればと思います。

ぼくがディレクターをつとめる、Mackerelというプロダクトの開発チームは、東京オフィス・京都オフィス・愛知にあるエンジニアの自宅の3拠点体制で、3年以上開発を続けています。

日常的にリモートチームで開発をしているのですが、リモートワークはメリットばかりではありません。

とてもとても、難しいのです。

このセッションでは、「リモートワークの難しさ」に焦点をあてます。

リモートワークの何が難しいのか。チーム開発においてどのような困難や問題点があるのか。

そしてそれでも僕たちがリモートワークを選択する理由やメリットは何なのか。

赤裸々にお話しようと思います。

モブプログラミングとはチーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピューターで行うことです。

日本においても、2017年に一気に話題となりました。
そのきっかけとなったモブプログラミングという働き方で紹介した楽天のモブ＝チームがその後どうなったのかについてお話します。

私達のモブでは、時間を決めてワークショップ形式で行うのではなく、朝来てから帰るまで働き方として実施しています。そのため、開発だけでなく資料作りや営業やモブプログラミングの体験会などすべてにおいてモブワークをしています。

• スクラムを中心としたアジャイル開発を精力的に行ってきたメンバーがモブプログラミングを通してどのように変化したのか
• 実際に仕事の成果が出せたのか
• モブとその外の関係性はどうなのか
• モブ＝チームのその後（※今後の活躍次第）

などについてお話したいと思います。

スクラムとモブプログラミングは、チーム全体のアプローチやチームビルディングという点で共通項も多い一方で、別の視点で仕事の本質やチームの本質について考えるきっかけになりました。

モブプログラミングに興味がある方はもちろん、そうでない方にとってもチームについて考えるきっかけを得られるようなセッションにしたいと思います。

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

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

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

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

2017.10.25 update Clarified session contents
2017.09.23 update 45min→20min
2017.09.25 update Translate title to English. But I will speak in only Japanese this program, sorry.

"Oyatsu Shrine" is the pattern that is published in Scrum PLoP.
Scrum PLoP → oyatsu-jinja

"Oyatsu Shrine" is being conducted at various GEMBA as a team communication tool. However, it is also a self-organizing activity base that teams can manage and improve on their own.

Listen to how everyone practices "Oyatsu Shrine" on the GEMBA and feel the pattern.

オヤツ神社とは、Scrum PLoPで挙げられているパターンです。

チームのコミュニケーションツールとして色々な現場で行われているお手軽な「オヤツ神社」ですが、チームが自分自身で管理・改善できる自己組織的な活動拠点でもある奥が深いものです。

また、オヤツ神社の運営は簡単ではありません。現場もいろいろあるので、神主がどのようにオヤツ神社を実践しているかを聞いて、パターンの一端を感じてもらいつつ、明日には現場で“上手くいく”オヤツ神社を設置できるようになる発表にする予定です。

最後にはみんなでオヤツ神社を建ててグランドフィナーレを迎えます。カッコいいオヤツ神社を建てられる技術はスクラムチームで働く我々にとっては必須スキルです。

モヤモヤ女子大生がプロダクトオーナーになったら！

＊

スクラムやアジャイルソフトウェア開発の関係で「サーバント・リーダーシップ」という言葉を良く耳にする人も多いかと思いますが、しかし実際具体的にサーバント・リーダーはどのような特性を持っていて、どのように行動しているか等について聞くチャンスはあまりないのではないでしょうか。

このセッションでは、サーバント・リーダーシップの詳しい定義、またサーバント・リーダーのスキルを向上させる方法について紹介します。尚、サーバント・リーダーシップに関して、日本のマネージャーのどのような面がこれに適しているのか、そしてどの側面に改善する余地があるのかについてもお話しします。

何かを変えようと思っている。勉強会を開いてみたい。学んでみたい。

そんな事を考えるスタッフは社内にいると思いますが、「言って怒られたらどうしよう」「勉強会を開くのは、ちょっと怖い」などが頭をよぎり、一歩踏み出せない状況にいるスタッフがいるかもしれません。

本セッションでは、周りを巻き込み継続し次につなげれるような心理的安全性を確保する活動の、想い、経過、時期に応じた対応に関してお話できればと思います。

私達のチームは2016年までメトリクスの活用、スプリント期間の短縮、くじ引きで決めるPOやSM、などのプラクティスを通して改善を繰り返してきました。スクラムガイドもどんどん破りました。

このチームはScrumが難しいなんて思っていませんし、誰でも出来ると信じています。

チームが開発する製品は大きく変わりましたがScrumが難しいなんてことはありませんでしたし、

なによりこのチームのエッセンスを大学生40名に導入したところなんと1週間で1日スプリントをモノにしました。Scrumが難しいのは幻想だったのかもしれません。

我々のチームはこういったことを通して2017年にいくつかのプラクティスを確立しました。スプリント期間は1時間へ、チーム内ボトルネックへの対応時間は25分以内を保証、人的リソース活用の損益分岐点を常に意識できる開発プロセスです。

結果、1週間でレビューを35回以上、振り返りを30回以上行っています。1週間で改善した項目は最大で20アイテムにおよび、それらのムダ取りによって6ヶ月間で最大2倍の成果を生み出しています。

チームのパフォーマンスを最大化するために私達の計画的な学び方、偶発的事象からの学び方などをScrumの文脈でご紹介します。

「人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。」(三宅芳雄・三宅なほみ 教育心理学概論 第一章 P.13-14)

多くの人がスクラムを利用して開発するものは、たぶんなんらかのソフトウェアサービスで、その先には利用者がいると思います。アジャイル開発やDevOpsでどれだけ技術的に研ぎ澄まし、円滑にリリースができるようになったとして、ターゲットとしている利用者像が間違っていれば、成果に繋がらず、投資や予算が尽きた時点で終わりです。

過去のソフトウェア開発は、作ってすぐには顧客に届けることなんてできない前提で作られてきました。そのために、じっくりとテストを重ね、ビジネスインパクトを計算し、エンドユーザーに届くときには「絶対に使い物になる」ものを作ろうとしました。しかし現代、作ってすぐユーザーに届けることは当然の事になりました。そのために、テストの自動化、クラウド、DevOps、A/Bテスト、カナリアリリース、マイクロサービスなどのプラクティスが普及してきたのです。

プロダクトオーナーシップは汎用化が非常に難しい分野です。うまくいく方法は一つではないし、売れるということはすなわちユニークな優位性があるということであり、すなわちコピーできない。できたら簡単に優位性は失われるからです。しかし、その考え方まで理解を深めれば、取り入れられる部分が出てきます。

本セッションでは、大手企業の中で、新規の事業開発を手がけられてきたパネリストの皆さんが、どのように予算をとり、新しいエンドユーザーの仮説を検証し、マーケットにアプローチして、小さな成功を掴み取ってきたか、話し合ってみたいと思います。

パネリスト
　山崎 篤 氏 (コクヨ株式会社)
　黒田 樹 氏 (リクルートテクノロジーズ)
　太田 敦士 氏 (NTT西日本)

本セッションプロポーザルに対してコメントにて質問をいただければ検討いたします。

Every time we did our 5 day Certified Scrum Developer class, it's a rich learning experience for both us and the clients. After doing it for 6 years and also practicing what we teach, I've summarised the topics into three rhythmic steps, which I "dance" over not only during my CSD classes but also in other technical coaching situations, again and again. I call these steps Re-spec, Re-design and Re-entry.