最近よく耳にするようになったコーチング。

興味はあるけどなぜか一歩目が踏み出せない・・・
なんかうさんくさい・・・
なにから始めればいいかわからない・・・
こうやって、悩み続けてもなにもすすまない・・・
いや、だからこそ飛び込んでみてから考えよう！！

そんな想いでコーチングの世界に足を踏み入れた5人の勇者たち。

はじめた動機、バックグラウンド、学んでいるもの、進度は違えど、
実際に行動しはじめた5人だからこそ話したいことがここにある。

コーチングを学んでいるもの同士が、お互いに問うことでお互いの思考を探ります。

達人たちの推しの世界を覗いてみませんか

「あの人はこの問題に対してなんて答えるんだろう？」
「あの人はもしかして、あの偉人？あの概念？からこの答えに辿り着いたのだろうか？」
「あの人の頭の中身が見てみたい！！」
と思ったことはありませんか？

同じようなプラクティスや手法を用いていても、人／チームによってまったく違う結果になります。
つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

このセッションでは達人たちが見ている世界、推しに対する思いを覗いてみる実験をします。
ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

最近よく耳にするようになったコーチング。

興味はあるけどなぜか一歩目が踏み出せない・・・
なんかうさんくさい・・・
なにから始めればいいかわからない・・・
こうやって、悩み続けてもなにもすすまない・・・
いや、だからこそ飛び込んでみてから考えよう！！

そんな想いでコーチングの世界に足を踏み入れた5人の勇者たち。

はじめた動機、バックグラウンド、学んでいるもの、進度は違えど、
実際に行動しはじめた5人だからこそ話したいことがここにある。

コーチングを学んでいるもの同士が、お互いに問うことでお互いの思考を探ります。

みなさんのチームでは、ふりかえりをしていますか？

今日では、ふりかえりに関するさまざまなプラクティスや経験知が共有されるようになりました。
私たちにとってふりかえりはより身近なものになり、さまざまな場面でふりかえりを活用しやすくなりました。
ついにはこのカンファレンスのように、ふりかえりをテーマにしたカンファレンスが開かれるまでになりました。

その一方で、私たちのチーム「Silver Bullet Club」ではある時期からふりかえりをしなくなりました。
その当時は、モブプログラミング（常にコミュニケーション）しているので必要性が薄れたことと、長く続くチームにとって形式に則ってふりかえりをすることが窮屈になったことが原因だと自分たちで分析していました。

ところが、その後チームの活動を観察したり、他の長く続くチームとの共通点を分析する中で、あることに気が付きました。

ぼくらはふりかえりをやらなくなったわけじゃない、ふりかえりが習慣になったんだ

書籍「エクストリーム・プログラミング」には、次のように書かれています。

コードレビューがよいのであれば、いつでもコードレビューを行う（ペアプログラミング）
テストがよいのであれば、全員がいつでもテストをして（単体テスト）、顧客もテストを行う（機能テスト）
設計がよいのであれば、設計を全員の日常の仕事の一部にする（リファクタリング）

私たちのチームはふりかえりをやらなくなったわけではなくふりかえりが習慣になった、ということに気づきました。それは単に形式的なワークショップとしてのふりかえりを習慣化したのではなく、ふりかえりというふるまいを習慣にしていたのです。

今回は私たちのような長く続くチームがふりかえりをどう捉えているのか、ふりかえりが習慣になるとはどういうことかについてお話してみます。ふりかえりを点／線／面で捉えて、ふりかえりという活動をより深く理解してみましょう。

2001年にアジャイルソフトウェア開発宣言が世に出てから約20年の月日が経ちました。

15th State of Agile Reportに寄ると、ソフトウェア開発チーム内でのアジャイルの採用が大幅に増加し、
2020年の37%から2021には86%にまで増加したそうです。マイノリティだったアジャイル開発は、ソフトウェア開発のスタンダードになりつつあります。実際にここ数年で企業から出ている求人を見ても、アジャイル開発やスクラムに由来する職種の名前をたくさん見かけるようになりました。

ところで、
5年後、10年後、20年後もアジャイル開発はアジャイル開発なのでしょうか。
5年後、10年後、20年後も私たちはアジャイル開発に携わっているのでしょうか。

もちろん目の前の仕事やプロダクトやチームのことを考えることも大切ですが、たまには少し未来のことを考えてみることも多角的な視点をもつという意味で大切なことです。

私は、10年以上、企業内でエンジニアとしてチームの中でアジャイル開発を実践し続けてきました。その中でSilver Bullet Clubというチームを結成し、2019年にはチーム転職をして企業を越えていまもなおチームで活動を続けています。また、パラレルワークで、さまざまな組織やチームを支援するアジャイルコーチもしています。

そんな自分が、さまざまな経験を経た現在アジャイル開発をどう捉えていて、アジャイル開発のミライをどう見ているのかについてお話してみます。

未来が実際にどうなるかは誰にもわかりませんが、未来をソウゾウすることは誰にでもできます。
アジャイル開発の未来がどうなるのか想像を膨らませながら、自分たちの未来をどのように創造していくのか一緒に考えてみませんか？

アジャイル開発をはじめるときにどのプラクティスからはじめますか？

この問いに、「ふりかえり」と答える実践者の方はとても多いです。
企業活動では一定期間を区切って評価する習慣があるため、プロジェクトのふりかえりや個人のフィードバック面談のようにふりかえりと似た活動を既に経験している方が多いです。そのため、ふりかえりというプラクティスをはじめる理由を説明しやすく、受け入れる方も必要性が理解しやすいため、ふりかえりからはじめることは比較的容易です。最近では、ふりかえりの実践についてさまざまな書籍や情報が手に入るようになったことも後押しをして、既に実践している方も多いでしょう。

一方で同じような現場で同じようにふりかえりをはじめてても、誰がやるのかによって効果が大きく異なるのもふりかえりです。
つまり、ふりかえりは方法や形式ではないところに成果を左右する大きな理由があるように感じています。

はじめてふりかえりをすることになったがどうやって場をつくればよいかわからない
ふりかえりを続けてはいるんだけど、ただ続けているだけになっている気がする
一部の人が中心になって進めているだけで、チームの全体感が生まれていない
リーダー（ファシリテーター）への報告会になってしまっている

こういった悩みにどうやって立ち向かっていけばいいのか。
必要とされているのは、チームの状況に合わせてふりかえりのゴールをどのように設定するのか、そのときに最適な方法はなんなのか、ふりかえりの中で起こる問題をどのように解釈してどうやって解決するのか、などの実践知ではないでしょうか。

チームや組織の中でさまざまなふりかえりを実践し続けてきた経験と、アジャイルコーチとしてチームの外からふりかえりを支援してきた経験を合わせて、今の自分に見えているふりかえりという世界についてお話してみます。

いまこそ俺たちの本当のふりかえりをはじめましょう！

達人たちが見ている世界を覗いてみませんか

「あの人はこの問題に対してなんて答えるんだろう？」
「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう？」
「あの人の頭の中身が見てみたい！！」
と思ったことはありませんか？

同じようなプラクティスや手法を用いていても、人／チームによってまったく違う結果になります。
つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

このセッションでは達人たちが見ている世界を覗いてみる実験をします。
ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

仕事をしているとたくさんの「わからない」と出会います。

• スクラムがわからない
• 自分たちの取り組みがこのままでいいのかわからない
• このプロダクトが売れるかどうかわからない
• スケジュール通り開発できるかどうかわからない

「わからない」という状態は不安です。不安な中で取り組んでいることが思うような結果が出ないと、うまくいかなかった！とすぐに結論づけたくなってしまいがちです。

「わからない」はふつうだ

スクラムガイドの中で、スクラムの定義はこのように書かれています。

スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

実際に私たちの仕事をふりかえっても、わかりやすい結果を得られることはほんのわずかで「わからない」ことがとても多いです。つまり「わからない」というのはふつうのことで、「わからない」だらけの中でも前に進み続けることが私たちの仕事です。

同じようなコンテキスト下で同じようにスクラムに取り組んでいるのになぜうまくいくチームとうまくいかないチームに分かれてしまうのか、という疑問と長年向き合い続けてきましたが、この「わからない」と共存することがうまくいくチームの条件であるように思います。

「わからない」と共存するチーム

私たちのチームも「わからない」ことがないわけではなく、「わからない」だらけの中で活動を続けています。私たちのチームが「わからない」をコントロールするために行っている取り組みやチームの特性について、また新たに取り組み始めたことについて、事例を元にお話します。

「わからない」を受け入れ、もっとチーム開発をうまくなりたいという想いをもったみなさんの参考になればと思っています。

Scrum Fest Mikawa初開催おめでとうございます。
今回の会場である三河、そして豊橋は実は私のルーツ（故郷）です。この地でキーノートをさせてもらえることが本当に嬉しいです。イェイイェイ！
※今回のイベントは参加者の皆さんはオンラインでの参加です

さて、自分にも皆さんにもそれぞれのこのイベントに参加するまでにたどってきたスクラムのルーツがあります。

• なぜスクラムにたどりついたのか

• いまスクラムと携わっているのはなぜなのか

• そして、これから先スクラムとどう向き合っていくのか

このキーノートではそれぞれのルーツをたどりながら、スクラムに真正面から向き合ってみる時間にしましょう。

チーム、組織、会社、役割、契約、業種・・・
私たちの仕事にはいろんな状況があるので、つい、
「It depends（ケースバイケースだね）」
と言いたくなってしまうときがあります。

しかし、私たちがアジャイル開発やスクラムからヒントを得て成し遂げようとしているのは、そのいろんな状況の中で「It depends」ではない答えを出すことです。

こんにちは！

こんにちは、及部です。

私は、2009年に楽天に新卒入社し、アプリケーションエンジニアとしてプロダクト開発の仕事に携わってきました。その中でもっとよいプロダクトをよいチームで作りたいと思い、スクラムやモブプログラミングを学んで、実践してきました。そして2019年には、チームFA宣言からのチーム転職をして現職であるデンソーでエンジニアとして働いています。

組織上の役割やプロダクトのドメインや会社が変わっても、「よいプロダクトをよいチームで作りたい」という想いは変わりませんでした。コードを書くだけではなく、チームにもプロダクトにも言い訳をしない自分を、そしてチームを目指して試行錯誤してきました。

伝えたいこと

教科書にあるスクラムとは違うかもしれないけれど、プロダクト開発のいろんな状況において言い訳をしないために、どのように考えてどのようにチームを実装してきたのかお伝えしたいと思います。

つい言い訳したくなってしまう人やスクラムをやっていても「これでいいんだっけ？」と悩んでいる人に、少しでも勇気と元気を与えて、行動のヒントを与えられるような時間にしたいです。

それでは、スクラムフェス札幌大会でお会いしましょう。アディオス！

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

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

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

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

DevOpsという言葉の世界はますます拡がり、様々な○○Opsが生まれました。DevOpsDays Tokyoに集まったプロポーザルを見ても、たくさんのDevOpsがあることがわかります。定義を1つに統一する必要はないですが、自分の中のDevOpsを更新し続けることは大切だと思います。

そこで今回の朝まで生DevOpsは「結局DevOpsとはなんだったのか」をテーマに、定義の話を超えてDevOpsから我々は何を学ぶべきなのかについて考えていきたいと思います。

パネラーは随時追加していく予定です。
また、このパネルディスカッションは飛び込み参加可能なオープンパネルディスカッションです。

このセッションのプレゼンテーターの二人は、過去に同じ開発プロジェクトにおいて、アジャイル開発を経験しました。ひとりはアジャイルコーチ、スクラムマスターとして参加し、ひとりはエンジニアとして参加しました。

そのプロジェクトは1000人を超える開発組織の中で初の「アジャイル開発を導入する」とうたったプロジェクトでした。もちろん途中、困難はありましたが、無事にプロダクトはリリースされました。

プロジェクトが終わり、ふたりは異なる環境でスクラムマスターやアジャイルコーチの経験を積んでいきます。

共に歩んだアジャイルプロジェクトから10年。それぞれの経験をふりかえりながら学びを確認し、今後の10年を考えるセッションです。

あなたのチームはいつ死にますか？

スクラムはチームワークのためのフレームワークです。スクラムでは、安定したチームが成功するための前提条件として紹介されることが多いです。実際に「STABLE TEAM（安定したチーム）」はScrum Patternsの1つになっています。

安定したチームは本当によいチームなのでしょうか？

私たちのチームは、スクラムやモブプログラミングを通して自己組織的なチームになりました。Unlearnを自分たちの活動に組み込んで、学習するチームになりました。スタートアップしたプロダクトも成長軌道に乗せることが出来ました。そしてそのチームは、プロダクトの終焉を乗り越え、さらには会社をも越えました。

• チーム転職できました #チームFA宣言 #完結編 #アフターストーリー

私たちのチームは、Project-BasedでもProduct-Basedでもなく、Team-Based TEAMだったのです。私たちのチームにとってはプロダクトの終焉も転職もチームの死にはつながりませんでした。私たちの考える「STABLE TEAM（安定したチーム）」はSAME TEAM（同じチーム）ではなく、生物のように変化し続けることができるチームです。私たちは会社を越えた後も、変化と向き合い生物的チームを目指して活動を続けています。

あなたのチームはいつ死にますか？

このタフクエスチョンの答えはどの教科書にも載っていません。しかし、チームの死を考えることで、どう生きるかが定まり、どうチーミングすればよいのかが見えてきます。一緒にチームのライフサイクルについて考えてみましょう。

N/A

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

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

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

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

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

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

私達は、

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

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

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

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

2018年4月・・・

鶴の一声で、とあるWeb企業に入社したビジネス採用の新卒は全員プログラミング研修を受けることになりました。

プログラミング未経験の彼らは、最初は黒い画面（ターミナル）すら怖がっていましたが、数カ月後には研修メンター陣からのインプットを頼りに、

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

などをまわしながら、3週間でプロダクトを作れるようになっていました。

さて皆さん、なにか質問ありますか？
※この話はノンフィクションです

その道のプロフェッショナル達がエクストリームだと思うこと／どうはじめるか困っていることを平気で突破していった彼らから学ばせていただきたいなと思い、今私はプロポーザルを書いています。

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

このセッションは、そろそろ言い訳するのはやめてもっとうまくなるためにはどうすればいいのかを真剣に考えます。経験でもないスキルでもない我々に不足しているかもしれない何かを、彼らから学ばせていただきましょう。

このセッションでは実際に研修を受けた新卒の彼らに、彼らの言葉で話をしてもらいます。

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

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

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

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

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

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

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

 巷で噂のDevOps。

ところが、

• DevOpsってなんだろう？
• ぶっちゃけそんなにみんなやってるのかな？

などいまさら聞けないDevOpsが皆さんの中にきっとあるはずです。
今回はDevOpsをテーマに熱いパネラーと共に朝まで徹底生討論をします。

このセッションは参加型パネルディスカッションです。
実践できている人もまだできていない人も現場の話をしにきませんか？

パネラーは随時追加していく予定です。パネラーとして参加されたい方もご連絡下さい。
もちろん当日の飛び込み討論も歓迎です。もしかしたらあのDevOps有名人も！？

DevOps Days Tokyo2017に参加しようか迷っているそこのあなた！
あまり詳しくなくても実践できていなくても、興味さえあればきっと大丈夫なので、このセッションをきっかけに一緒にDevOps Days Tokyo2017に参加してみませんか？

アジャイル開発、スクラムに出会って6年。
いろんなチームでいろんなアジャイル開発、スクラムにチャレンジしてきました。

最近たまたまアウトソースやオフショアに携わる機会があり、そこでチームビルディングを行い、実践していく中で改めてアジャイル開発やスクラムについて考えました。

• 制約が多い
• やりたくない
• やらないほうがいい
• 興味ない
• 大事なことは変わらないでしょ

そりゃそうなんだろうけど、経験したからこそ伝えられることもあると思います。

経験があるかどうか・これからするかどうかに関係なく、知っておきたいなって思う方はぜひ聞きに来て下さい。自分のアジャイル開発やスクラムを見直すきっかけになるような話ができればいいなって思ってます。