イノベーションを生み出し、生産性の高いチームを目指すのなら、マネージャーやスクラムマスターはどのように振る舞うかが鍵となります。そこで推薦したいのは「サーバント・リーダーシップ」です。

サーバント・リーダーシップを活かしている人は一方的に命令するのではなく、チームメンバーをどうやってサポートしてあげられるかに重点を置きます。チームメンバーをコントロールするのではなく、チームメンバーに仕えるという態度で接します。

このワークショップでは、サーバント・リーダーシップを効果的に実践するために必要な要素を紹介し、またそれを応用する方法もお教えしていきます。自分のリーダーシップを再考する絶好のチャンスになります。

12年前、最初のアジャイルスクラム案件に取り組みました。

この新しい世界を受け入れるには、最初からすべてを学び直す必要がありました。しかし、いくつかのプロジェクトを経験し、いくつかの困難に直面したため、アジャイル、プロジェクト管理、およびメトリクスが共存できることに気付きました。

無駄ゼロを目指したリーン思考により、非常に簡潔なプロセスを達成できました。

CI&Tリーン・アジャイルプロセスを適用してプロジェクトを管理している間に、私はいくつかのことを学び、リーダーシップに対する考え方を完全に変えるに至りました。

そして「Process ＆ People」は私の情熱であることに気付きました。

3年前、私はブラジルから東京に移り、このCI&Tリーン・アジャイルプロセスとCI&Tの企業文化を日本での事業に導入しました。

日本文化について学び、日本でも受け入れられるようにプロセスを調整することは、大きな挑戦でした。

私はこの困難に立ち向かいながら、数々のプロジェクトを経験しました。再び、私は多くのことを学び、そしてそれは自分自身をも変革してくれました。

この登壇では、アジャイル、プロジェクト管理、メトリクスに関する「学びの旅」と、これらが日本という地で如何に適用されているか皆さんに共有します。そして、これが再度自分を完全に変化させたことを。

私はとあるコミュニティの運営に数年携わっています。正直なところ運営の苦労なんてなるべく避け、楽しくやっていきたいものです。しかし、実際のところはいろいろありました。そこでみんなであれこれ実験してみたりカイゼンしたりと試行錯誤を重ねた結果、今現在ではなかなかいい感じなプロセスができあがった気がしてます。

そんなことを思い返していると、ふと気づいたことが。「これってチームの活動と似ているな」と。

そこで、コミュニティ運営というチームが直面した課題とそれに対しどのような取り組みを行ったか、そしてどのような成果を得られたか（あるいは得られなかったか）、これを続けた結果どのようにチームが成長していったかを整理しつつ、みなさんのチームや組織、コミュニティなどに活かせるヒントが得られるようなセッションをしたいと思っています。

※コミュニティについて、話の都合上簡単な紹介はすると思いますが宣伝するつもりはありません

あなたの組織はアジャイルな開発を志ざし、スクラム開発を取り入れ、素晴らしい結果を得ることができました！ おめでとうございます！

全社共通の人事制度では3ヶ月ごとに個人目標を設定し、メンバーから360度フィードバックを集め、成果を評価します。半年ごとに成果に応じた賞与があり、昇進の機会もあります。上司からアジャイル開発の推進者として信頼されているあなたは「スクラム開発での目標設定・フィードバック・評価はどうしたら良いのか」と相談を受けました。プロダクトの成功にばかり集中していてそのことをすっかり失念していたのです。

スクラム開発では全員が一丸となり同じ目標を追います。・・・でも個人ごとの目標を決めるルールです。メンバーのキャリア・成長はどう導いていきましょう? 誰が何の貢献をしたのかどう評価しますか?

アジャイルな開発を長く続けるために、たまにはマネージャーの悩みを一緒に考えてみませんか?

※Scrum Fest Osaka採択後、福岡セッション枠の45分で話すことになったため情報を更新しています。

伝えたいこと

スクラムの原理原則に背くとだいたい失敗するとよく言われます。「事情があってちょっとだけ自分たちのやり方に変えてみたいのですが、、」ともなれば、いずこかのスクラム有識者が「スクラムちゃうがな」と投げかけてくるかもしれません。しかし、それでもやってみてはどうでしょうか？

スクラムは3つの役割、3つの作成物、5つのイベントで構成される軽量で理解が容易なフレームワークです。ところがそれだけシンプルな仕組みであっても、実際に始めるとなるとそれほど容易ではありません。原則通りに始めようとすると、色々と疑問点がわいてきませんか？プロダクトオーナーやスクラムマスターは誰がやるのが良いでしょうか？プロダクトバックログはどうやって作るのでしょうか？スプリント計画はどうしますか？スプリントレビューは必要ですか？スクラムはいつ始められますか？

全ての条件を揃えてからスクラムを始めるのは容易ではありません。しかし、それでもやるしかないのです。なぜなら、正しいやり方を実践するだけの知識や実力や環境が私たちには無いからです。とりあえずやって、失敗して、少しでも原則どおりできるように変えていくのが現在の私たちのやり方です。

2019年4月に私がJOINしたチームはコテコテのウォーターフォールで開発していました。体制変更で突然大きく変化したチーム状態と過去に経験したことがない高難易度な開発テーマで課題が山積みの中、行き詰まりを感じてスクラムの原則を取り入れ始めました。とはいえ私たちはスクラムの経験が無いチームなので、プロダクトバックログも十分に作れない状態からとりあえずスプリントの開発サイクルに移行するなど、経験者から「それやったらアカンよ、たいてい失敗するから。」と言われるようなこともあえてやって、たいてい失敗しながら、従来の開発スタイルを少しずつ変えています。私たちの取り組みはまだスクラムをやっているとは言えないかもしれませんが、少しずつでもスクラムに近づこうと試行錯誤している方々にとっての1つの事例として、「こんなやり方でもできるよ」というストーリーをお話したいと思います。

スクラムと私

株式会社ラクス は中小企業向けのクラウドサービスを提供し、19期連続増収で事業拡大中の会社です。私は2011年に入社し、BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、主力サービスである楽楽精算の大阪開発チームをリーダーとして立ち上げ、2018年からスクラム開発に取り組みました。スクラム開発に取り組んだことで、過去の開発経験も含めてチームが不確実性と向き合い敏捷性を高めていくことの重要性を改めて実感しました。2019年4月からは10年以上続くメール配信サービスの開発チームに異動し、マネージャとして従来型の開発プロセスを少しずつ改善してチームのアジリティを高めていくことにチャレンジしています。

会社の文化（カルチャー）変革の7年間の軌跡。

2013年ごろ、色々な問題が噴出し、会社としても個人（経営者）としてもどん底の状態でした。
そこから、色々な取り組みを行い、少しづつ会社の状態がよくなり素晴らしいメンバーにも恵まれ、会社の良い文化（カルチャー）が形成されるようになりました。

その過程のなかで2017年8月「Joy,Inc.」に出会いました。
「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
この本に共感しぼくらもこんな会社に成りたい！と決意。それまでの会社の文化を良くするための取り組みを更に推進していきました。

会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

今回は、Developer Summit 2020 での講演（45分）のロングバージョンとしてもう少し詳しく、それぞれの取組みについてお話したいと思っています。（Developer Summit 2020ではベストスピーカー賞を受賞しました。https://codezine.jp/article/detail/12140 ）

https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11835/joyinc3

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

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

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

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

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

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

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

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

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

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

サバイバルテクニック

#1 趣味を増やそう！

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

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

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

#3 家族を実験に

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

このワークショップは一言でエレベーターピッチの強力版です。

次のような悩みに効果的です。
・「良い商品なのに売れない、自社(自分)に強みがあるのにお客様に喜んでもらえない。」
・「日々、頑張っているものの報われないことも多く、意気消沈してしまう」

私は20代前半から新規事業に取り組み、自費でも数百万の借金をするなどして挑戦してきました。良い商品なんだけど売れない、強みがあるのに買ってもらえないとずっと悩み続け、どうしたらお客さんの喜びにつながるのだろうと考え続け、試行錯誤してきました。

そのうち徐々にうまくいくにつれて、お客さんから「弊社のこと、なんでそんなに知っているんですか? もしかして勤めていたことがあるんですか?」と驚かれたり、喜んで値引き無しに買ってもらえるようになりました。

その中で学んだ重要なポイントは開発だけでなく、顧客との付き合い方や売り方もアジャイルに適応してくことです。

今回は「顧客との付き合い方や、売り方もアジャイルに適応してく」ためのワークを行います。顧客と良い関係を結ぶためのヒントがえられるセッションにしたいと思います。

・商品/サービス/強みについて考える
・顧客を考える
・競合を考える
・セールス/プレゼンテーションを考える
・ロールプレイしてみよう/セールスマップでユーザーにも決裁者にも響くアプローチを整理してみよう

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

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

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

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

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

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

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

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

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

失敗に成功した！

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

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

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

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

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

※来場者へのアナウンス：このセッションは事前の参加チェックインが必要です。チェックイン方法は、参加者用 Discord の「品川タイムテーブル」チャンネルをご覧ください。

あなたのマネジャーはあなたより暇そうですか？
もし暇そうなら、ぜひ他のセッションに参加し、マネージャーに明日「いつも私にチャンスをくれてありがとう！」と伝えてあげてください :)

あなたのマネジャーはあなたより忙しそうですか？
もしそうだとしたら、そのマネージャーを助けたいと思いますか？
もし助けたいと思わないとしたら、あなたの成功の道も険しいかもしれません :/
あなたの成功の近道は、あなたのマネージャーを助ける事かもしれないのですから。

もし少しでも助けたいと思えているなら、この「お仕事解体ワークショップ」が使えるかもしれません。

世の中のマネージャーの中には、理由は様々あれどなかなかメンバーに仕事が渡せず、それが忙しさの悪循環を招き苦しんでいる人たちがいます。
そういったチームでは、マネージャーが休むと色々な事が回らなくなったり、マネージャーが仕事上のボトルネックとなることで仕事のリードタイムが長くなり、組織のパフォーマンスが制限されるでしょう。
それはマネージャーがマネージャーとして機能していないということかもしれませんが、メンバーからそれを助けることでチームとして一歩前にすすめることだってできます。

「お仕事解体ワークショップ」では、マネージャーとメンバーの対話を通して、マネージャーの仕事を解体、理解し、その仕事をチーム全体で担っていくための具体的なアクションを作ることができます。それは「マネジメント」という行為が、だれか特定の人に依存するのではなく、チームの中に溶けているようなチームを作る一手となるかもしれません。

忙しそうなマネージャーと働いている方、または周りにそういったマネージャーがいる方は、ぜひこのワークショップ体験にご参加ください。
実際にワークショップを組織に持ち帰って実施し、あなたのチームがよりよいチームになることを祈っています！ ;)

※「忙しい人」がマネージャーでなくてもこのワークショップは活用できます。（忙しい PO など）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IT企業から、大手ユーザー企業のマネージャーに転職して３年間で取り組んだ、プロジェクトマネジメントと組織マネジメントのプラクティスについて良かったことや反省点をお話させていただきます。

2019年2月に開設したマネーフォワード 京都開発拠点にて拠点の立ち上げとスクラムマスターをやっているumisoraと申します。

同時に出しているプロポーザルもぜひ御覧ください。

「マネーフォワード京都のスクラムセレモニーを完全かつ詳細にご紹介します」

私は新卒3年目くらいから金融系SI会社の中でスクラムに出会っています。出会ってから早8年は経ったでしょうか。スクラムに出会ってからというもの、その魅力は全ての課題を解決するのではないかと夢を抱くほどにパワフルで、合理的で、魅力的だと感じてきました。

そんなスクラム信者とも呼べる私ですが、過去３回自分自身がオーナーシップを持ってチームにスクラム導入のチャレンジしていました。しかし結果は惨憺たるもので、スクラム本の様にはチームは自走しないし、ベロシティは測れないし、ただ形だけのスクラムを行う事しか出来ませんでした。

「これは欲していた形ではない」

と同時に

「スクラムとはこんなにも難しいものか…」

と感じてきたのでした。

このセッションでは、

まるで本に書かれているかの様な成果によってチームの輝く姿を得るに至った、４度目のチャレンジであるマネーフォワード京都開発拠点でのサクセスストーリーをお話します。

2019年2月にオープンしたマネーフォワード京都開発拠点は2名からはじまり、10ヶ月で16名となりました。そのうち10名程度がWebサービス開発に直接的に関わって開発を行っています。

2019年後期から(自社としては)大きめの案件の開発が始まり、東京も含めて同時に10名~15名程度が稼働するプロジェクトとなりました。

毎月の様にドメイン知識もないメンバーが増える中で数カ月間ハレーションもなく、活躍できない人もない状況を作り上げました。新メンバーが増えても2週目からは以前からいる人達と同じパフォーマンスを上げ始めるチームです。

Reginal Scrum Gathering Tokyo 2020 にて講演させていただいた内容の再講になります。
一部変更やプラスαして話させていただければと思います。

ふくおかフィナンシャルグループ（FFG）では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。

• アジャイル組織の変遷
• 現行ルールのしがらみとの闘い
• アジャイル開発を少しずつ組織に浸透させていく方法
• 組織を拡大していくための対内・対外的な取り組み
• 拡大していく組織で発生した問題
• 成果を出し続けていくための組織やチームの意識改革

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

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

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

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

続きは会場で。

IKIGAI - the formula for satisfaction

The fifth principle of the agile manifesto says: Build projects around motivated individuals...". But is it okay to just expect, that everyone is highly motivated all the time?

And if the answer is "no", can you motivate people by doing something?

In that session, Veit Richter (Emendare Karlsruhe) will bring in some ideas and inspiration, with which you can reflect your own working environment and how to confront yourself and others with the topic of motivation.
Also, he is happy to get some feedback from the land of ikigai itself on a topic, numerous people in Germany are grateful about.

多くの組織において、アジャイル開発の導入は簡単なことではありません。しかし、それぞれの組織が、どのような目的でアジャイル開発導入に取り組み、どのような課題が生まれ、それがなぜ起きるのか、特徴的な事例を知ることによって、恐怖を乗り越えてその先にたどり着くヒントが得られるかもしれません。

このセッションではアジャイル開発を導入しようとした組織に起きた課題の中で、どの組織にでも起こり得る特徴的なものを取り上げ、組織・チーム・個人の課題を3つのケースを通じてお話します。

・Case 1: アジャイル開発を導入しても、すべてのメンバーがチームとしての成果を出すためのチームワークができるようになるとは限りません。Case 1 では、これまで、個人にタスクが割り当てられ、個人の責任の範囲で仕事をしてきたメンバーが、アジャイル開発のチームとして招集された結果、チームワークによって成果を出すことができないという課題に直面した事例についてご紹介します。

・Case 2: チームとしてアジャイル開発の基本ができるようになっても、チームの外側にいるステークホルダーとの協働がうまくできなければ、アジャイル開発の価値を十分に発揮することはできません。Case 2 では、マネジャーがアジャイル開発を理解せずに従来の方法で管理しようとした結果、チームが機能せず成果を出せないという課題に直面した事例をご紹介します。

・Case3: チームが順調に成長し、ステークホルダーがアジャイル開発を理解し協力することができても、他の部門や組織がアジャイル開発を理解していないと、組織として成果を十分に利用することができないことがあります。Case 3 では、サイロ化した部門の制約によってプロダクトの ROI を最大化できないという課題に直面した事例についてご紹介します。

3つの事例は、私がアジャイルコーチとしてアジャイル開発の導入を支援したチームの事例をもとに構成しています。

これからアジャイル開発を導入しようとしているか方はもちろん、現在アジャイル開発をしている方にとっても参考になればと考えています。