2016年夏、あるチームが解散となりました。そのチームのうち、社内に残ったエンジニアは一人。当時、彼は一人でプロジェクトをこなしていました。ステークホルダーから感謝されていたので一人で開発を続けていました。しかし、エンジニアとしての成長は殆どありませんでした。切っ掛けでとあるチームでエンジニアを募集していることを知りました。技術スタックもそれまでの事業領域も異なるところでやっていけるのだろうか？と彼は悩みました。そのチームにいるエンジニアと一緒に働きたいという想いからそのチームへ入ることにしました。あの時の彼の決断は正しかった、と今の私なら言えます。

このセッションは、RSGT2020で発表された「Team-Based TEAM - 会社を越えるチーム」に対するアンサーセッションです。RSGT2020当日に初めてこのセッションの内容を知りました。それでも「あぁ、わかる。これは自分たちだ。」と思える内容でした。このセッションでは、Team-basedチームの一員として得られたものが何かについてお話します。

Regional Scrum Gathering Tokyo 2020 で「田舎で14年スクラム - チームを導く現場の「ゲームモデル」づくり」というプロポーザルを出したら落ちたのと、当該カンファレンスで2つもゲームモデルの話があったので、田舎の未開度合いと、そこで発見した奇跡について話したいです。

鳥取に比べたら、世界中スクラムパラダイスやで！

前回「田舎で11年スクラム」との違い

• 1年経過しました
• 計算間違ってません
• 田舎のスクラムチームを取り巻く状況はさらに深刻に
• 田舎では、会社の中でスクラムチーム運営してますわーいだけでは先がありません
• Long-Stable-Teamを求めて、ちんもは自分が働いている土地とそこに住む人々について改めて考えることになりました

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

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

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

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

巨大ウォーターフォールプロジェクトの一員であった業務SEは、8か月後、重要なアジャイルプロジェクト（※）を任されるエンジニアになっていました。

「なぜ？」「どうやって？」。このセッションでは、チャレンジした本人（橋本）とそれを支える組織（岡島）それぞれの目線から、次の切り口で明らかにしていきます。

1. 価値：変化を抱擁する世界へのチャレンジと、それを支援するアジャイル組織の在り方
2. 原則：本気で取り組むための「ビジネスと学びの両立」「段階的動機付け」「組織能力化」
3. プラクティス：プログラミング未経験の業務SEが成長するために日々考え実行したこと

※ https://jbpress.ismedia.jp/articles/-/57937

実験場はどうして必要か？

企業の中で企業を変えようとしているスクラムマスターやアジャイルプラクティショナーの皆様。
コミュニティや本などで仕入れた新しいワークショップや、メトリクスがうまく働くかを会社で試してみたいと思いますよね。

でも、それ大丈夫ですか？
安全ですか？失敗しても大丈夫ですか？失敗しないようにがんばりますか？
でも、失敗ってしたほうがいいんですよね。

会社組織は良い実験場か？

そもそも会社組織の中で最初に実験するのってハイリスク・ハイリターンですよね？
失敗した場合ときには実験を止めたいと思いますが、下手に予算やOKRが決まってたりすると、とりあえず四半期ぐらいは引くに引けない状態になったりして、危険な状態になることがあります。

そうならないように、安全に実験できる場所を探しましょう！
そのためのサバイバルテクニックを考えましょう。

サバイバルテクニック

#1 趣味を増やそう！

単に趣味を増やすことに意味はありません。
社会性が得られる趣味であれば、それは立派に実験場として機能します。

#2 地域コミュニティに参加しよう！

PTAや自治会、地元神輿会など、地域コミュニティも立派な実験場です。

#3 家族を実験に

家族との信頼関係が利用できる場合は、実験目的を話して実験に協力してもらいましょう。
父親、母親、子息、伴侶それぞれ幅広い年齢層に対して実験できます。

我々は誰に"価値"を届けるのでしょうか？

エンドユーザー？自動車メーカー？事業部長？？

大企業はPOからエンドユーザーまでが遠すぎます。

そして、POと開発チームの間にも距離感を感じている方もいるのではないでしょうか？

では、"価値"とはなんでしょうか？

ユーザーの求める価値＝ステークホルダーの求める価値でしょうか？

ステークホルダーの求める価値＝POの考える価値でしょうか？

そして、POの考える価値＝開発チームの考える価値でしょうか？？

また、"価値"とはどうやったら生まれるのでしょうか？？

失敗に成功した！

私のチームはとあるWebアプリ開発をスクラムで取り組みました。

結論を言うと、プロジェクトは予定通りリリースできました。が、その道のりは失敗の連続でした。

このセッションでは、とあるプロジェクトを通して私たちが経験した失敗談をお届けします。

しかし、結果的にこの失敗のおかげで私たちはアジャイルの原則に立ち返ることができ、開発チーム、PO、ステークホルダー、プロジェクトに関わった全員が大きく成長できました。そう、私たちは失敗に成功したのです！

皆さまには、プロジェクトの中で価値を生み出し続けるための明日から使える具体的な提案と、愛という"価値"をお届けするセッションになればと思います。

こんにちは。楽天　ランキングサービスグループの室山です。

楽天市場のランキングサービスでプロダクトオーナーのチームリーダーをやっています。

少し前、トラブルが多発し、モチベーションも低下していたグループの中で、プロダクトオーナーたちはそれぞれが孤独に責任を負っていました。

そこでチームビルディングのやり直しを行って、助け合うプロダクトオーナー組織へと変わりました。
モチベーションも低く疲弊したチームから、心理的安全性の高いチームへ。

どうやって、心理的安全性の高いチームになったのか？

どうやって、メンバーは自走を始めたのか？

どうやって、メンバーは変化を受け入れてくれたのか？

私達が取り組んだチームビルディングと、そこから学んだことをお話します。

メンバーが「仕事が楽しい」って言ったとき、正直ちょっと泣きました。その後のお話も。

プロダクトオーナーだけでなく、チームをリードしている方々と、飲みながらでも語り合いたい！
課題共有の場になれば嬉しいです。

本セッションは、2019年4月にDevLove関西「プロダクトオーナーの現場」でご紹介した
「トラブルだらけの現場から仕事が「楽しい」現場に変わった、6か月間の話」と、その後日談に関連した内容となります。
https://www.slideshare.net/cowappa/ss-141300729
ぜひこちらも合わせてご覧ください。（Slidesの項目に記載したスライドと同じです）

3年前に自己組織化したチームを目指して独学でスクラムを学び、アジャイル開発もどきをスタートさせました。

そこからアジャイルコーチに支援してもらいながら徐々に独り立ちを目指し、SMはCSMを、POはCSPOを、Dev(自分)はCSDを取得しチームの練度を高め、アジャイルな活動を広げてきた結果、チームを離れることになってしまった話です。

チームと僕の未来はどうなっていくのでしょう。

Mackerelというプロダクトはローンチから5年が経ちました。ぼくはそのほぼすべての期間、このチームに在籍していて、うち3年間はマネージャーとしてチームを運営しています。5年間運用されたチームではさまざまなことが起こりますが、いくつか事例をご紹介しながら、長く安定的に続くチームづくりについて考えていきたいと思います。

株式会社i-plugにて自社サービスのOfferboxの開発をしている小西と申します。

Offerboxというプラットフォームの質的改善を加速するために、2019年秋からグロースに特化したチームを組成するというの話が上がり私がチームリーダーとして指揮を執ることになりました。
2019年4月よりスクラム開発をしており、ものを正しく作っていく部分はできるようになってきていたものの正しいものを作る部分は経験がありませんでした。

その状態から価値あるプロダクトを提供できるように他職種(デザイナーやデータアナリスト)の方と協力しながらこれまでデュアルトラックアジャイルのような開発プロセスを構築してきました。
データアナリストとともにABテストをしたりデザイナーとともにユーザーテストをしたり、その結果を踏まえて仕様を磨いたり廃案にしたり提供価値にこだわった意思決定をしています。
また、職種をまたいで連携することで1つ1つの工程のクオリティを高めることにもこだわっています。

そのような現場で具体的にどのようにプロダクト開発を行っているのかという状況であったりそれを実現するまでの過程であったりをご紹介できればと思っています。

Regional Scrum Gathering Tokyo 2019、Regional Scrum Gathering Tokyo 2020では、行動分析学という視点から見たScrumチームについての考えをお話させて頂きました。そして、この話を聞いて、行動分析学に興味を持ったよと言ってくださった方もいらっしゃました。

一方で、行動分析学的な観点でScrumチームの課題を自分で分析しようとした場合には、どのように分析をし、どのような点に注意をすればよいかのご質問も頂きました。

そこで、本セッションでは、参加者の皆様と一緒に具体的なケースを想定し、一緒に分析をし、その行動の改善につなげるための介入の施策を検討してみたいと思います。

駒場
「最近、うちのおかんがシステム開発に興味を持っててなぁ。名前は忘れたんやけど、その開発手法には "プロダクトオーナー" ってゆー役割があるってゆーてたんやわぁ。」

内海
「そんなもん、スクラムやないのぉ〜。 プロダクトオーナーゆーたら、スクラムの三つのロールの一つやないのぉ〜。スクラムに決まりやがなぁ〜。」

駒場
「オレも最初スクラムやと思っててんけどな、話しを聞いてみるとなんかちょっと違うねんなぁ〜。」

内海
「違うことあれへんがなぁ〜。何が違うねんなぁ〜。」

続きは会場で。

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

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

アジャイルやスクラムなどについて悩んでいる時、みなさんはどうしますか？
インターネットなどで似たような悩みを解決した話がないか調べてみたり、SNSでつぶやいてみたり、同僚に相談したりする人もいます。

みなさんの現場にアジャイルコーチがいるなら話してみるのもいいかもしれません。多くのアジャイルコーチはアジャイルなマインドセットや幅広い知見を持っています。しかしそんなアジャイルコーチがすべての現場にいるわけではありません。

先日のRegional Scrum Gathering Tokyo 2020では Coaches Clinic という、アジャイルコーチに(基本)1対1で相談できる場がありました。

この時間では、その Coaches Clinic の紹介をし、実際にどのような感じで行われるのかを見ていただこうと思います。このセッションを終わった後には、ScrumFestOsakaでも Coaches Clinic の場ができるといいと考えています。

※Workshop(90分)を選択していますが、30〜45分の想定です。

後の講演を楽しめるようにするために場を暖めます。

たのしいでっせ

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

はじめて組織にアジャイル開発が採用された時、そのチームはどのように成長していくのだろうか？またそれに伴って、組織にどのような変化が起きやすいのだろうか？事例はたくさん聞いたけどどう取り入れればいいか。。。そんな事例の迷路にはまっていませんか？

もちろん、事例から学べることはたくさんあるのですが、このこのセッションではアジャイルコーチとして現場をみてきた経験を元に、おおよそ共通してみられる以下の２点についてお話いたします。

• どの現場でも起きるであろうチームが成長する過程
• アジャイルチームの成長に伴い組織に与える影響とその対策
  
  

デザインは、要件定義から開発への流れを支える重要な工程です。

要件定義で交わした内容がデザインに反映されていない、
出されたデザインの実装コストが大きく開発部門を圧迫する…

UIや見た目の良し悪しとは別の問題として、デザインを取り巻くワークフローの問題は
概ね「コミュニケーションする」で解決されがちです。

本セッションでは、デザインを要件定義から開発へのフローを橋渡しするステップ捉え、
「伝わるデザイン」のありかたと、デザインを通じたワークフロー設計を考えてみます。