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

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

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

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

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

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

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

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

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

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

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

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年。
いろんなチームでいろんなアジャイル開発、スクラムにチャレンジしてきました。

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

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

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

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

自分たちの組織をどうやって改善するのか

特にエンジニアは組織の話となると嫌厭しがちです。
わかります、自分もそうでした。

でも、身近な改善を続けると必ず組織の問題にぶつかります（ました）。
昨今話題のDevOpsやMicroserviceの話をとりあげてみても、組織とは切っても切り離せません。

そんな時にもちろん今とは違ういい組織を探すことも一つの選択肢です。
しかし、そんな都合がいい組織は果たしてあるのでしょうか。
仮にあったとして自分がそこに都合よく入れるのでしょうか。

そんなことを考えた1エンジニアが、組織を変えることを考えて「未来会議」というものをやってみた話をします。

自分たちのどうやって組織と向き合えばいいのか、どういう組織を目指すべきなのか一緒に考えませんか？

誰が一番アジャイルなのか？

アジャイル、スクラム、名前はなんだっていい。

俺達の目的を叶えるために、現場で日々繰り広げられる闘いの日々。
そこで培ったものこそがホンモノの証だ！！

教科書は読むのはもうやめだ。
俺たちには現場で鍛え上げた経験がある。

誰が一番アジャイルなのか、今こそ決めようじゃないか。

（セッションの詳しい内容は詳細を御覧ください）