「ボトムアップでのアジャイルチームづくりは、どうしたらよいか？」
「アジャイルチームを作ったものの、なかなかその先に進まない」
「顧客要望やトップダウン指示で、アジャイルチームを早急に作り成果を求められているが何から始めたらよいか、わからない」
こうしたご質問を数多くいただくようになりました。日本企業の経営層から開発エンジニアまで、みんな悩んでいるみたいです。

みなさんご存じの通り、アジャイルにおけるマネジメントの基礎は、チームにあります。チームがなければ、ベロシティも測れないし、見積もりもできないし、デリバリーできません。しかし、いまだに、作るものが決まって、予算が取れてから人をかき集めるプロジェクトが後を絶ちません。どうやって調達・開発するのかが決まっていないのに、なぜか金額や期間は決まってしまう。

まあ日本人、子供のころからチームチーム刷り込まれてますし、集まれば仲良くやることには長けてます。なんとかしますよ。大人ですし。

「うちの会社にいる人間はまじめな奴が多いから、
　チームというのは勝手に集まればできるもので、
　まあ、よいチームを作るためにワークショップでもして、親睦を深めたらいい」
....などと、簡単に思っているマネージャーも結構多いのではないかと思います。

ち・がーーーーーーう。

そんな風にしたって、簡単にはうまくいかないこと、みんな体験してますよね？
小学校の掃除の班でケンカが絶えない。遠足のグループ活動が楽しくない。
あいつの言うことが納得できない。一人でやった方が仕事が早い。
特定の人が仕事のほとんどを背負って周りは動けてない。
うまくできない人がいるけど十分に教える余裕がない。

私たちのチーム作りは失敗の連続。
でも仕方ない。人間関係って難しいから。
私一人が我慢すればよいのだ。
...いつもそうやって、うまくいかないことに蓋をして、めんどくさいことを先送りしようとします。

じゃあ、どうやってチームを作るのか？
本セッションでは、ここに答えていこうと思います。

大企業から中小企業まで経験を持つ、アジャイルコーチ三人衆が、それぞれの経験から話をしていきます。
チーム作りの各段階で、どんなことを考えながら作っていくのか、参考になる話もならない話もあると思いますが、
参考になるところだけ持って帰っていただければと思います。

チーム作りのプロセス

1. 一人目の仲間を作る
2. 話し合いながらアウトプットする
3. ものの置き場を確保する
4. 成果をアピールする
5. やったことをふりかえる
6. 技術的負債を解消する

7月に漫画最終回を迎えた「ハイキュー!! がアジャイル方面のコミュニティでもじわじわと盛り上がってきています。チームの成長の物語であり、個人がチームや自分の実力・振る舞いとどのように対峙するかを丁寧に描く作品に、多くの人が共感と学びを感じています。バレーボールのルールを知らなくても大丈夫。6人で強い方が強い。ハイキュー!! の物語を通じて、チームで業績を上げる方法について考えてみましょう。

田原の出身なのですが高校は豊橋に通ってまして、バレーボール部の部員でした。といっても、大した運動能力もなくずっと補欠で楽しくやっていたのですが、先輩方から様々なことを学ばせていただいた気がします。出場選手6人だけでない周りを含めたチームの動き方は、そこで学んだんじゃないかと思います。そのあと、企業ITの道に進んだり、スクラムに出会ったりする中で、Production IG制作であるところのアニメ「ハイキュー!!」、そして原作の漫画に出会うわけです。

早く行きたければ、ひとりで行け。
遠くまで行きたければ、みんなで行け。

プロダクトをちゃんと作り、育てていくために必要なものは何でしょうか？
ビジョンや現実的なロードマップ、MVPや顧客仮設の検証はもちろんとして、プロダクトチームを育てていく必要があるんじゃないかと思います。
近くに行きたいなら一人で行け、遠くまで行きたいなら、みんなで行け。

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

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

発表者は、黒田樹さん(リクルートテクノロジーズ)、絹川達也さん(楽天)、横道稔さん(LINE)。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

息が止まるほど、熱い "モブ・リファクタリング" します!!

品川アジャイルでは、毎週水曜日に集まって勉強会をしています。
リモートモブでリファクタリング本の一章の写経を繰り返したり、
リファクタリングやテストツールをみんなで試したりしています。

今回は、その中で一番楽しい、リモートモブリファクタリングを
皆さんを交えて体験していきます。

TDDのワークショップと違い、機能の追加をせず、現状のコードを
「グリーンを維持したままで」手直ししていきます。
もしレッドになったら、息を止めてグリーンに戻します。
(「イキトメ」メソッド)

前半は、Codespaces を使ったモブプログラミング & リファクタリングの演舞。
後半は、飛び入り参加の方を交えて一緒に体験するワークショップとなります。

モブでやりますので、ドライバーは周りの指示を受けて入力するだけ。
プログラミングに自信がなくても、キーボードが打てればご参加可能です。
コードを継続的にメンテナンス可能にする、リファクタリングの世界へようこそ！

※VSCode と Live Share Extention Packコンポーネントを事前にインストールしておいていただけるとスムーズです。

コロナウィルス問題に伴う社会情勢により、残念ながら開催できなかったDevOpsDays Tokyo2020ですが、私たちは来年4月の開催に向けて既に動き始めています。
今回はこのスクラムフェス大阪の場を使って、2021年の開催に向けてのKick Offミーティングを公開でおこないます。

開催に向けてのスケジュール的なことから、キーノートスピーカーの選定、金銭面のことまで、包み隠さず公開で議論を致します。
カンファレンス運営の裏側が気になる方にとっては、またとない機会になることかと思います。

議論にぜひ参加したいという方も大歓迎です。
気軽な気持ちでぜひ覗いてみてください。
2021年に向けての最高のKick Offの瞬間を皆様と迎えられることを楽しみにしております！

DevOpsDays Tokyoとは…
DevOpsDays Tokyoは毎年4月に、日本語と海外スピーカーによる英語の2トラックで開催される、日本国内で参加ができる国際カンファレンスです。
DevOpsDaysは東京以外にも世界中の60以上の都市で自発的に開催されています。
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスします。​

IT技術を駆使して変化に強いビジネスインフラを実現するスキルを身に着けるために、国内外の最先端の事例とプラクティスを結集します。
海外から第一人者を直接招き、ここでしか手に入らない最新情報をリアルタイムで入手出来ます。​

最先端のテクノロジの活用法はもちろん、先進企業で必要とされてきた背景までも理解し、正しく組織内に展開するための洗練された知見を得られます。

このイベントが日本のみならず、世界のDevOpsプラクティスを共有できる、意義のあるイベントになれるよう、願っております。

ドイツのポツダムで毎年開催されるAgile Tesing Days 2019に参加してきましたので、フィードバック会として参加者たちのパネルディスカッションを行いたいです。

海外カンファレンスの「フェス感」が伝えられることを最大のゴールにしてます！

技術を学ぶ時、何をしますか？
本を読んだり講演を聞いたりしても読んだり聞いたりした話では実感が湧きません。

「チームの成長」とは簡単にはいかないもの。
でも、チーム内でちょっとしたスキル差から師匠と弟子として一緒に作業すればコトバ以上に伝わるものがあります。

今回、そのような学びの場を『リファクタリング第2版』を写経で得たエッセンスを、オンラインのモブプログラミングでリファクタリングで実演します。

新型コロナによるこのオンライン環境で、チームの活動方法に困っている方、モブプログラミングする方法を知りたい方、チーム力を上げたい方など、わたしたちのモブプログラミングからそのコツを学び取ってください。

実践概要

• Visual Studio Codespacesによるコードの共同編集
• モブプログラミング
• リファクタリング第2版を写経して学んだ技術の実践
• コードを破壊せず、テストがグリーンのまま行うコード改善方法

たのしいでっせ

なかなか東京だと実現できない実行委員やスタッフや参加者の方のふりかえりを通じて、東京のRSGTで何が起こっていて、どう思って運営していて、これまでどんな事件があったか、みたいなのを話し合ってみたいです。

なかなか東京だと実現できない実行委員やスタッフや参加者の方のふりかえりを通じて、東京のRSGTで何が起こっていて、どう思って運営していて、これまでどんな事件があったか、みたいなのを話し合ってみたいです。

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.

ドイツのポツダムで毎年開催されるAgile Tesing Days 2019に参加してきましたので、フィードバック会として参加者たちのパネルディスカッションを行いたいです。

海外カンファレンスの「フェス感」が伝えられることを最大のゴールにしてます！

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

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

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.

Retrospective で Problem -> Solution をだすという KAIZEN のやりかたが、日本ではとても普及している。アリスターコバーンのアイデアに基づくKPT(Keep/Problem/Try)フォーマットは、日本ではデファクトと言っていい。みんな改善が大好きで、改善点が出ないようなふりかえりは意味がないとすら思っている人もいるくらい。

アジャイルコーチたちはスクラムマスターからこんな相談をよく受ける。「ふりかえりでの悩みがあります。改善点がでないんです。」「でてきた改善点がちっとも解決されないんです」「改善しないのでふりかえりをやめてしまいました」

日本での長いコーチングの経験に基づき、私たちは改善を中心にしたふりかえりには問題がいくつかあることを発見した。
1. 暗くなること
2. 改善点は仮説であり、実現可能かどうかはわからないこと
3. だから、いくらでもアイデアを出せるし議論ができてしまうこと
4. 同じような課題や改善点が残り続けることで、人々がポジティブになれなくなっていくこと

これらの問題によって、ふりかえりが長時間になってしまったり、疲れてもうやりたくないと思ったり、楽しくない、と思うようになってしまうことが、よくあるのだ。チーム自身がふりかえりを行うので、ミーティングが長くなれば、作業にかけられる時間が減ってしまう。楽しくもないし改善もしないようなふりかえりなら、やめてしまうのが解決策なのだ！

Linda Rising の Positive Retrospective というアイデアを発見した。LindaはProject Retrospective の第一原則を参照し、まずこれまでやってきたことを肯定することからはじめ、その上で代替案を出していこう、ということだった。

そう、私たちはまず、チームがこれまでになにができたかを確認するセレモニーをやらなければならないのだ。Fearless Change における Small Successes パターンのように。Scrumがいうベロシティが意味するチームの能力、現在位置を確認し、完了／実験と成長と学びを喜ぶセレモニーが必要なのだ。チームメンバーがそれぞれ成し遂げたことを確認し、何に喜び、何を学びと感じたのかを共有しあう。

私たちはこのふりかえりにあたって、壁に貼る、一つのフォーマットを考えた。Fun! Done! Learn! である。このフォーマットの特徴はベン図になっていることだ。複数の要因にかかる要素を示すことができる。例えば楽しく新しいやり方を覚えたのなら、Learn!かつFun!とすることができる。

多くの場合、学びは喜びだ。チームは継続的な学びを繰り返してどんどんよくなっていく。そしてそれは喜びにも繋がる。喜びはチームの燃料になる。チームはまた、より多くのDoneを生み出していく。

当初私たちはDoneではなく、Deliveryという言葉を使おうとした。ただリズムがよりよいDoneを使おうという話になった。Regional Scrum Gathering Tokyo で Hunter Industries の Chris Lucian が実験について講演した。そうだ、実験だ。私たちは Done の中に実験も含めるべきだと気づいた。

このフォーマットについて Tsutomu Yasui がブログに書いたところ、数週間のうちに日本中で Fun! Done! Learn! が行われるようになった。ブログやfacebookで毎週のように「やってみたよ！」という報告が届いている。Regional Scrum Gathering Tokyo でも Kazuki Mori が Fun! Done! Learn! のボードを作ったところ、貼りきれないほどのポストイットが壁を埋め尽くした。

私たちはなぜここまで Fun! Done! Learn! が人々にポジティブな効果をあたえるのか、科学的なエビデンスをまだもっていない。しかし、このムーブメントになにか重要な発見があるのではないか？とすら思うようになった。

DevOps Days Tokyoの場で Fun! Done! Learn! をやることで、この現象が様々な現場でどのような結果に繋がるのかを実験したい。ぜひ、皆さんの職場に持ち帰って実験してほしいと考えている。実験はDone!でありFun!であり、Learn!につながる。まさにアジャイルなマインドセットを Fun! Done! Learn! が呼び起こし、見える化するのではないかと考えている。

この最新のレトロスペクティブについて皆さんに共有し、フィードバックをいただければと考えている。