ビジネスの急速な変化に適応すべく、多くの企業でデザイン思考やスクラムの導入が進んでいます。
しかし、なかなか効果が出ないのが実際ではないでしょうか？
この原因の１つとして、組織マネージメントの方法やマインドセットが従来から変わっていない事が考えられます。
デザイン思考やアジャイルを導入しても従来通りの組織マネージメントとマインドセットでは、効果は薄れてしまいます。
このような問題の1つの解としてManagement3.0というマインドセットがあります。
本会では座学とワークショップを組み合わせ、Management3.0をベースに「変化に強い”自己組織化したチーム”の作り方」を、プラクティスを交えてお伝えします。
参加されるみなさんに「今日から」使える考え方と技を持ち帰って頂こうと思います。

スクラムの中では、とっつきやすいのがふりかえり。手が出しやすく、ふりかえりからスクラムを始めたという話もよく聞きます。ただ、どれだけスクラムの経験を積んだ人でも、ふりかえりは難しく、奥が深いイベントです。

一昔前に比べると、Web・勉強会・カンファレンスなどで、ふりかえりの情報は手に入りやすくなっています。ただ、それゆえに、選択肢が多く、「何が正解なの？」「結局どうすればいいの？」と悩んでしまった経験がある人もいることでしょう。

みなさん、胸に手を当てて考えてみてください。
「ふりかえりは、うまくいっていますか？」

• うまくいっていないんだけど、どこがわるいのか…
• なんとなくうまくいっている気が…する？
• うちのふりかえりは完璧だ！ふりかえり完全に理解した！
• そもそもうまくいくって何だよ

何かしらの引っ掛かりを感じたあなた。
その引っ掛かりはとても大切です。
このもやもやがある今だからこそ、自分のふりかえりをふりかえりましょう。

ふりかえりを始めたばかりの人も、ふりかえりを日常的にやっている人も、毎秒ふりかえりやってるよという人も。

ふりかえりをふりかえるためのふりかえりチェックシートを用意しました！
さぁ、みんなでふりかえってみましょう！

Rettyのエンジニア組織は、2017年頃崩壊の危機にあった時期があります。

明確な船頭、責任者がいない中で停滞感が広がりなにもできないまま徐々に退職者が増えていくというサイクルに陥っていました。

そこから数年をかけて小さな取り組みを徐々に広げ、改善をかさね今では離職率も大幅に下がり、エンジニア組織だけではなく開発組織全体にアジャイルな思想が広がりつつあります。その過程はもちろん簡単なものではなく、多くの失敗や無力感を感じたことも数え切れないほどあります。

この過程のなかで自分が感じたこと、考えていたこと、表には出せなかったことなどを赤裸々にお話できればと思います。

Management 3.0 考案者のヨーガン・アペロ氏の著書に「Managing for Happiness」がありますが、現在、日本語訳を進めており、（うまくいけば）6月あたりに出版する予定です。

このセッションでは、出版に先駆けて本に出てくるプラクティスを無理くり全部詰め込んでひととおり体験してしまえるようなワークショップを実施したいと思います。

本に出てくるプラクティスは、以下のとおり12個とたくさんあるのをぎゅうぎゅうに90分に詰め込むので、おそらくジェットコースター的なスピード感満載のワークになるかと思いますが、それすら楽しんでもらえるような形で参加してもらえると嬉しいです！

ひとりで進行する予定なので、ワークはフィッシュボウル（参加者を内側の円と外側の円で分けて、内側の円の方にワークに発言する役割として参加してもらい、外側の人はそれを見守る役割として参加してもらう形）的に3-5人に直接的に参加してもらい、後の方にはそれを見てチャットなどで間接的に参加してもらう形にする予定です。

体験できるプラクティス（予定）

- Kudoカード

- パーソナルマップ

- デリゲーションボード

- バリューストーリー

- エクスプロレーションデイズ

- ビジネスギルド

- フィードバックラップ

- スコアボードインデックス

- メリットマネー

- ムービングモチベーターズ

- ハピネスドア

- セレブレーショングリッド

「スクラムは、楽しいかね？」→「はい！」
「スプリントレビューは、楽しいかね？」→「はい！」
「スプリントレトロスペクティブは、楽しいかね？」→「はい！」
「リファインメントは楽しいかね？」→「うっ。。。」
最後の質問に私はギクリとした。

他のイベントは良い思い出があるが、リファインメントは。。。。

現在、私達のチームでは、リリースしたプロダクトの機能改善を行うため、プロダクトオーナーと共に、リファインメントを行っている。

定期的にリファインメントを実施するも、プロダクトバックログの中身以前に、そもそもリファインメントで何をするのか？今日のリファインメントのゴールは？の認識があっていないことが多いことに気付く。お互いの目指すところが異なり、リファインメントがギスギス、殺伐、発散に次ぐ発散。その結果、優先度の並び替え、着手可能なバックログをReady(準備完了)するまでに時間を要していた。

それがリファインメント の苦い思いで、そして楽しめない要因に。。。何とかしたい。

このセッションでは、現在進行形で直面しているリファインメントに対しての、私達チームの課題や悩み、
その解決に向けた取り組みについて、お話します。
「リファインメントがうまくいかない」「リファインメントが楽しめない」という方々のご参考になれば幸いです。

私は Chatwork 株式会社にて、エンジニア・バックグラウンドで組織開発に携わっています。

Chatwork は今年で 11 周年を迎える息の長い SaaS となるのですが、社会の DX が加速することに伴って求められるプロダクト成長を実現するために、開発組織の構造変革や技術的負債へと向き合う必要がでています。

そのための組織開発は、不確定要素を持ちながらもスピードが求められるため、Chatwork においてはエンジニアと人事を一同に介した "DevHR" というチームを作り、スクラムを応用して PDCA を回しています。

本セッションでは、Chatwork における DevHR の活動を紐解くことで、組織開発や人事領域へのスクラムの応用可能性を考察します。

私が所属するチーム、その名も"momoten"。

このセッションでは、このスクラムチームがどのように開発を進めているのかを"できる限り細かく"紹介します！

他所の会社の他所のチームがどんなふうにスクラムを実践しているか、事例や会社の紹介で部分的に切り取って見ることはあっても、細かく観察できる機会はなかなかありません。

そこで今回は、あるスプリントを切り取って、実際の現場で使われているプラクティス、ツールはもちろん、チームの開発の進め方やコミュニケーションの取り方、各イベントの進め方まで、お見せできるギリギリまで詰め込んでお届けします。

あまり知ることができないリアルな情報を持ち帰れるお得なセッションになる予定です！

逆に「もっとこうしたらよくなりそうじゃん！」みたいなフィードバックをもらえたら私もお得でWin -Winです！

宿泊業界は新型コロナウィルスの影響で大打撃を受けましたが、そんな中でも星野リゾートの内製化は止まりません。むしろ事前に内製化していたからこそコロナ禍でも成長する会社を支えることができました。

そして会社の成長に比例して増えていくプロダクト、より重要になってくる関係部署との協働、7年前は4人しかいなかった情報システムグループも今や50人と急成長。そんな星野リゾートが「スクラムマスターが足りない」とのことで、昨年の秋にスクラムマスターとしてジョインしました。

組織文化が重要であると説く書籍『ユニコーン企業のひみつ』では、「エンタープライズ企業になるとスタートアップの頃のような小回りの利く筋肉を上手に柔らかく動かす方法を忘れてしまう」と書かれてあります。星野リゾートの情報システムグループも3年前はスタートアップのようなもの。今まさにスタートアップからエンタープライズ組織へと急拡大する中で、いかにしてスタートアップの良さを維持しながら規模の経済性を獲得するのか？そういう問題意識を持ちつつチームと一緒に歩んだスクラムマスターが半年間で学んだことをお話させていただきます。

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

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

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

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

スクラムを勉強する方法はたくさんありますが、その中でも特に短期間でスキルアップしやすいのが各種研修への参加です。無認定のままアジャイルコーチとして数年やってきたkyon_mmがついにScrum Allianceの研修をうけてみました。また、実践者であるbleis-tift、アジャイルコーチであるoshige、ビギナーであるyamajiも各種研修をうけてきています。そこでたくさんのことを学び、研修の善し悪しについて考える機会もふえました。

今回はScrum Allianceの研修をうけてみた感想と、Scrum Allianceが策定している「この研修ではこれ学べるから期待しておけよリスト」に本当に研修が合致しているのかの検証結果をご紹介します。みなさんが研修をうけるさいの参考になれば幸いです。

SmartHRでは主にスクラムで開発を進めています。

開発に関わるメンバーがスクラムの理解を深め、スクラムマスターとしての振る舞いを学び、スクラムマスターとして活躍していくための取り組みをご紹介します。

なんちゃってスクラム、なんちゃってスクラムマスターで終わらないぞ！という意気込みで発表します。

野中郁二郎氏は言いました「知的体育会系になれ」と。

では、どの体育(スポーツ)を選考すればいいのでしょうか？

The New New Product Development Gameではラグビーチームのように、とは書かれています。

ですが、サッカーではいけない理由は書かれていません。どうせ一緒でしょ？と思われているアメフトではダメなのでしょうか。競技人口が多い野球やクリケットは。。。。

本セッションでは、野球/サッカー/アメフトなどいくつかのスポーツを比較しながら、そのゲーム自体の構造からアジャイル実践者の方々に特にラグビーの観戦をお勧めする理由を説明したいと思います。

長期間にわたり、保守・開発を続けていると、メンバーの間にいつの間にか上下関係ができてしまい、うまく行っていたスクラムチームがいまいちな状態になったことはないでしょうか？
私たちにもそのような時期がありました。そのようなチームに突如訪れたメンバー交代、そして入ってきたのは、アジャイルをやったこともなければ、エンジニア経験も浅いメンバーたち。
そのようなメンバーを中心として、チームを再構成する中で、アジャイル開発を体験したメンバーがどのように成長を遂げ、新しい形でチームを作り上げていったのかお話します。

チームを作るのに、何かとらわれのようなものを持っていないでしょうか？
チームとは何か、チームとして達成したいものは何か、私たちは何度も話し合い、自分たちにあった形で変えてきました。
アジャイルどころか、システム開発自体も知らなかったメンバーもいるなかで、スクラムを中心に取り組むこと、諦めることを先入観なしに行うことで、チームの雰囲気も変わり、大きく成長をすることができました。

チームビルディングに悩んでいる方のご参考になればと思います。

何かを学びたいと思った時の方法の一つとして、「読書」があると思います。
集約された賢人の知恵をもらうことが数千円の投資でできる読書は、物事を学ぶのに非常に投資対効果の高い方法であるはずです。

しかし、現実を見てみると、読書が思うようなペースで進められなかったり、読みたかったはずの本なのに読んでいる途中で苦しくなって挫折したり、読んだのに何も行動変容が起きなかったりと、読書を通して自分が思っているような姿になれず、悩まれている方も多くいらっしゃると思います。

本プレゼンテーションでは、ここ1年半で316冊の本を読む過程で自分が行ってきた、試行錯誤の結果(153個の読書方法を実践)の中から50個をピックアップして紹介する(※)ことで、読書の仕方に悩まれている方の一助になることを目指していこうと思います。

※ハイピッチで50個の読書方法を紹介しきるか、参加者の皆さんが気になる読書方法を幾つかピックアップしてゆっくり紹介するかは、当日に参加者の皆さんにアンケートを取って決めたいと考えています。

みなさん、ユーザーさんの生の声を聞いてプロダクト作りに活かせていますか？
市場の変化に伴い、ニーズも変化していく中でユーザーさんの声を継続的に聞き続けることで良いプロダクト作りをしていけると思います。

このセッションでは、Rettyで飲食店インタビューを立ち上げた時の背景、立ち上げ時の難しかった点、押さえておくべき勘所などをお話しします。

「ユーザーインタビューを導入を検討したいけどどうやってやれば、、、」という方や、「中々ユーザーインタビューの立ち上げに苦労している」という方のご参考になればと思います

プロダクトの成長を加速させるため、チームをスケールさせるという選択肢を取ることになったとき、プロダクトオーナーは最もスケールが難しい役割の一つでしょう。

このセッションでは、POと開発者の分業、プロダクトマネージャーを含むPOチームの組織化、アジリティを高める組織デザインへの挑戦と私が実際に体験し試行錯誤した内容と得た知見を発表します。

前提としてSaaSのToB、専門性の高いドメインを扱っているプロダクトであり、LeSSのプロセスを採用しています。

皆さんはチャーシュー好きですか？

自分はチャーシューや豚の角煮が好きでよく作っていたんですが、ある日奥さんに作って出したところ
「これはチャーシューじゃなくて煮豚だよ」
と言われてしまいました。

料理教室の講師である奥さんから本物のチャーシューの作り方を教わったところ、自分のチャーシューの出来が劇的に変わり、求めていた味と食感が出せるようになりました。

そして最近、スクラムマスター業務でも同じ経験をしました。

先に本セッションの結論を伝えますと

「少しでも自信がなかったり疑問があるスクラムマスターは、スクラムマスター研修を受けた方が良い」

ということです。

私はスクラムマスター経験は半年ほどで、同僚のスクラムマスター陣からアドバイスを受けつつ、アジャイル/スクラム本を読みながらスクラムマスター業務を進めていました。

そんな中で、自信がなく曖昧な返答をチームにしたり、中々上手く回すことができない場面がありました。
例えば

• 各スクラムイベントの責任は誰にあるのか
• スクラムマスターとしての立ち回りとして、どこまで意思決定をして良いのか
• チームから上がってくる声やアジャイル/スクラムに対する反発をどのように捉えれば良いのか

といったものがあります。

同僚の認定スクラムマスターに相談したり、コミュニティに参加してご意見を頂いたりしてこれら疑問や他の日々のモヤモヤを少しでも解消しながら業務を行っておりました。

しばらく経ってやはりしっかりスクラムマスターを学びたいと思い、Scrum Allianceが提供する研修を受けて認定スクラムマスターの資格を取得しました。

そこから自分のスクラムマスター業務における変化が色々あると共に、今までよりも更にスクラムマスターとしての自信を持って業務を行うことができております。

本セッションでは、認定スクラムマスター研修を受ける前後で変化した自らの動きとチームの変化についてお伝えさせて頂きます。

少しでもスクラムマスター業務で悩んでいる方や、研修/資格を受けるかで悩んでいる方の参考になれば幸いです。

フルリモートに負けるな！チームの一体感を醸成し、同じ目標に向かって爆速前進するために行っている取り組みや想いをお話します。

取り組みの一例：wevoxやmiroを活用した相互理解ワーク、チームメイトを巻き込んだロードマップの作成、ほぼ月のわいわいチームイベント

聞いた人に一歩進む勇気が出る、栄養ドリンクのような発表を目指します！

「自分は将来的にSMになりたいです！」
以前はやらされ感が強く漂い多くの問題を抱えていたチームでしたが、今ではメンバーの一人からこんな言葉も出てきた、サインアップの力で変わりつつあるチームの物語です。

アジャイル開発を支える重要な要素の1つに、チームの各メンバーが主体的に仕事に取り組む自己組織的な状態が挙げられると思います。
チームの当事者意識が高まり主体的な働き方が出来るようになるために何が必要なのか、多くのアジャイル実践者の方々の頭を悩ませる話なのではないでしょうか。

私たちのチームでは、約2年前にスクラムを取り入れたチーム開発に移行しました。
PO、SM含め全員が新卒からずっと同じ会社でスクラム未経験、社外の有識者の力を借りることもできないハードモードからのスタート。
当然様々な問題に直面し、その中の1つにメンバーがどこか受け身な姿勢というものがありました。

そんな状況をカイゼンすべく提案したのが、スクラムイベントのファシリテーターをSM固定からサインアップ制への変更です。
最初は他にサインアップする人はおらず自分だけがファシリテーターを担う日々が続きましたが、各スクラムイベントの目的を達成しようと全力でやり方を工夫しているとプロジェクトの全体の解像度が以前に増して上がり、意図せず私自身の当事者意識が高まるのを感じました。

そんな自分の変化に驚きながらもしばらく続けていると、別のメンバーがサインアップしてくれるようになりました。
そしてしばらくするとなんと、そのメンバーもプロジェクト全体を意識しているような発言が増えてきたのです！
もしかして私と同じような変化が起きたのではないか、試しに聞いてみると……
さらに2人目のフォロワーが現れ……

複数人に再現性があった鍵は何なのか、チームでふりかえってみるとその鍵は「プロジェクトの全体の解像度の高まり」にありました。

当事者意識に大きな変化があったのはまだチームの半分程度とまだまだ道半ばですが、変化があったメンバーからはこんな発言が出てくるほどになりました。
個人がプロジェクトの全体像をより強く意識するようになったためプロジェクト全体のリスクへの意識へと広がり、受け入れ条件の工夫など様々なところにも効果が波及しています。

こんな一人のスクラム実践者が現場で泥臭くもがいているまだまだ道半ばの話ですが、同じようにもがいている方々に少しでもヒントに、そして勇気になれば幸いです。

現在、Chatworkでは大規模なマイグレーションを行っています。

システム開発にスクラムを導入する目的は、『要求に対して仮説検証を行いながら不確実性に適応するため』ですが、作り直しであるマイグレーションでは極論を言ってしまうと『要求に対する仮説検証』は発生しません。

それであれば、対象資産と移行手法を最初に確定させることによってウォーターフォールで進めることも可能に思えますが、実際には以下のような不確実性が発生します。

• 現新の環境差異によって発生する不確実性
• 他チームの活動による影響によって発生する不確実性

このような不確実性に対して、開発者出身の非PdMのPOとしてどのように取り組んでいるかについてお話します。