Let's mingle and create "Ba" together!
In this time slot, the organizers of Regional Scrum Gathering Tokyo will do a brief workshop to create "Ba" for Agile practitioners. You can meet new people, make new friends, connect with Agile community members from a lot of countries.

なんやて！このセッションおもろそうやな〜。

だから大阪好っきゃねん。

2019年に訪問した海外の現場の話を報告します！

Agile Testing Days で学んできた、DevOpsパイプラインゲームをやってみます！

In this talk, the speaker will present a brand new retrospective format which quickly became popular in Japan. This method is heavily influenced by Japanese culture, but it may work great in other cultural contexts. We are looking for your feedback.

Someone said Agile does not work in Asian Culture: https://www.infoq.com/news/2016/06/agile-asia/

We totally agree with this topic.
One of the difficulties comes from retrospectives.

We found that a positive retrospective format better fits our culture: Fun! Done! Learn! After we published the method in a blog in Japanese, many teams in Japan started using this format. We did not teach neither facilitated directly; people just adopted and started using it. We would like to share this retrospective method as well as how teams in Japan embraced it. We are eager to hear from you whether this would work with your teams or not and why.

大企業で新規事業を始めるために必要なものはなんだと思いますか？予算ですか？社内政治ですか？そう！違う！そう！

プロダクトオーナーやリーンスタートアップの本を読んでも、なかなか教えてもらえないのが「日本企業におけるカネと政治」。エンジニア出身の方も、マーケティング出身の方も、プロダクトデザインやUXの方も、等しく苦労するポイントであろうと思います。

プロダクト開発はうまくできても、それ以外のところで泥沼にハマってしまいがちな大企業の皆様に、うまくサヴァイヴして人生をときめくためのヒントをお伝えできればと考えております。そのために、実際に大企業で新規ビジネス開発の仕組みづくりに携わるみなさんから、戦略やヒントやマサカリをいただきます。もしかしたらちょっと心に棘が刺さるかもしれませんので、しっかりと心のご準備をお願いいたします。

発表者は、絹川達也さん(楽天)、太田敦士さん(NTT西日本)、そして楽天技術研究所や楽天テクノロジーカンファレンスを設立から育ててこられた森正弥さん。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

In this talk, the speaker will present a brand new retrospective format quickly becoming popular in Japan. This method is heavily influenced by Japanese culture, but it may work great in other cultural contexts. We are looking for your feedback.

Someone said Agile is not work in Asian Culture ( https://www.infoq.com/news/2016/06/agile-asia/ ).
One of the difficulties is from retrospectives.

We found a positive retrospective format better fit for our culture: Fun! Done! Learn!
After we published the method in a blog in Japanese, many teams in Japan started using the method. We've not taught or facilitated directly; people just accepted and started using it.
We'd like to share the method as well as how the teams accepted the technique in Japan.
We are eager to hear from you whether this works for your team or not and why.

アジャイルやっていますか？スクラム組んでますか？「スクラム」のもっとも重要なポイントは、チームみずから課題を明らかにし、一つ一つ解決していくところにあります。簡単なゲームを通じて、スクラムのプロセスを通じたチームの課題解決を体験してみましょう。このワークショップはBall Point Gameといって、スクラムでは定番のワークショップの一つです。ぜひ持って帰って自社でやってみてください。

過去２回のDevOpsDays Tokyoは、2017年1月末のシアトル訪問から始まりました。
Microsoftを訪問し、いくつかの多様性のある開発現場を見せていただき、英語での闊達な議論もしてきました。

今年のキーノートの Chap Alex さんもそこで出会った一人です。
彼はもともとテストの自動化の役職にいたわけではありません。
スカンクワークスで数年、チームになって３年くらい、今は30人のチームになったといっていました。

別のチームの人は、TFSというプロダクトを作っていましたが、
「ほら社内でこんなに使われるようになったんだよ」
と言っていました。計画経済のようにトップを説得して全体に使わせるなんてことはやっていませんでした。

さらに、そのチームは部屋を工夫し、チーム全員が一部屋に集まり、それでいてほかのチームとは共有しない部屋を作っていました。徐々にほかのプロダクトに広がっていると言っていました。

日本人エンジニアの河野通宗さんが言っていました。
「上司もエンジニアなので意思決定が速いです」
意思決定が速いと何がうれしいのですか？
「クラウドは常にどこかが壊れている。なのですぐに検知して直さなきゃいけない」

世の中がガラリと変わってしまう音が聞こえました。

もう開発者もデザイナーもマネジメントも経営陣も関係なく、リアルタイムに動き続ける世界を相手にして動かないといけない。途中の誰かがわからないから通訳してくれといえば、そこでリアルタイムから弾き出される。

テスト自動化だけ、チームビルディングだけ、上手なデリバリーだけ、得意ななにかをひたすら追いかけて、エンジニアのキャリアパスだけ考えて、残りはほかの人のせいにしておけばよい時代は終わってしまった。全体としていい仕組みを作った企業が生き残る。誰も安住できないグローバル競争をしたたかに生き残って時価総額を伸ばし続けるエンタープライズがシアトルに一つありました。競争している企業もいくつもあります。

私たちの DevOpsDays Tokyo そこから始まりました。

それから一年ちょっとがたちました。

世の中の何が変わったのか、そして、心境はどう変わったのか、ここからどうなっていくのか。

話し合ってみたいと思います。

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

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

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

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

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

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

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

DevOps(継続的デリバリー)によって、プロダクト開発は、より短いピッチで仮説検証することが可能になりました。仮説を効率的に実装につなげ、素早くデリバリーして、部分リリースでメトリクスをとって検証する。リーンスタートアップが、大企業でも積極的に採用されるようになった、ともいえます。こうした時代に、プロダクトマネージャーに求められるスピード感や役割そのものが変化しています。おそらく正解もないので、パネルディスカッションを用意することにしました。ぜひ皆さんで議論しましょう。

本セッションでは、「めんどうくさいので、やめてみた」についてみなさんの経験を共有していただき、参加者のみなさんが、もっと「めんどうくさい」を発見できる方法について考えます。そして、時間があれば、なにかを始めたり作ったりする際に、めんどうくさくてもやらなければならないことのリストを作ってみましょう。めんどうくさいけど、練習は大事です。

実は、本セッション自体がめんどうくさいのですが、なんとなく必要そうだなと思いまして、まあ、やってみないと価値があるかどうかもわからないので、プロポーザルとして置いておきます。あわせて、代わりにやっていただける方も募集いたします。