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

現在はグルメサービスが多く存在する中で、Rettyを指名利用する理由をユーザーさんに感じてもらえるよう、チーム一丸となり模索しております。

この発表では「どうすればユーザーさんにRettyを指名利用してもらえるか」を模索し、進めたプロダクトの再設計プロセスをお話ししようと思います。

経済産業省のDXレポート2でも提言されている通り、日本でDXを加速するためには、ユーザー企業だけでなくベンダー企業のアジャイル変革も必要です。昨今人材の流動性が高まっているとはいえ、欧米に比べ日本では多くのエンジニアがベンダーに所属しており、その潜在パワーは、デジタルを活用した抜本変革とそれに必要な組織アジリティの向上に向けた重要な役割を担うことができます。

私自身もベンダーの可能性と重要性を信じ、永和システムマネジメント Agile Studioでの組織運営を通じて様々な変革に取り組んできました。具体的には、以下の組織的な取り組みです。

• 内製化を支援する開発支援サービスの提供
• ノウハウの提供主体となるための新しい技術の獲得
• ユーザー企業に認知してもらい変革に巻き込むためのマーケティング

これらは、結果的にDXレポートにおける、ベンダーに求められる4つの変革方向性（①ユーザー企業の変革を共に推進するパートナー、②DXに必要な技術・ノウハウの提供主体、③協調領域を担う共通プラットフォーム提供主体、④新ビジネス・サービスの提供主体）の①と②をカバーしています。

現在、これらの取り組みを継続発展し、しなやかな変革による新たな価値創造を目指しています。ユーザー企業のアジャイルに対する理解が進むにつれ、様々な支援を提供するアジャイルなベンダーも増えています。私たちはまだ道半ばではありますが、このセッションでは、これまでのAgile Studioや自治体（兼業している福井県CDO補佐官）での取り組みでのポイントをご紹介させていただきつつ、参加者の皆さんと一緒にアジャイルベンダーの未来について考える機会にできれば幸いです。

田舎でスクラムシリーズ16年目

ちんもの勤める会社が突然のアジャイルフィーバーになって1年。

経営陣と組織職が全員アジャイル研修を受け、全社方針にも組織戦略にもアジャイルの推進なるものが組み込まれ、顧客から多くのアジャイル案件がやってくるという状況になった。

果たしてこれは、長らくちんもが夢に見てきた世界なのか、そして会社人生の多くをアジャイルの展開に投じてきたちんもには、いよいよお役御免の時が迫っているのだろうか...。

アジャイル時代にSIerが抱える新しい課題に果敢に切り込むちんもの無謀な挑戦、聞いてやってください！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Kudoカード

- パーソナルマップ

- デリゲーションボード

- バリューストーリー

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

- ビジネスギルド

- フィードバックラップ

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

- メリットマネー

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

- ハピネスドア

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

自分はこれまで4年ほど、OKRと向き合ってきた。

初めはムーンショットを追いかける好奇心や自身の成長につながりそうな期待で取り組むものの、チーム内でのコミュニケーションがうまくできているとは感じられなかった。
当時は評価制度と紐づいていたOKRだったが、年度末も自分が何を積み上げてきて何が評価されているのか、正直わからなかった。

こうして半分受け身で始まったOKR、今度は自分が社内に広める役割を少しずつ担っていくようになった。

漸進的に広まりが感じられるようになり、少しずつ自分達の共通言語になってきている手応えを感じていた。

はずだった。

実際には、現場では業務とのつながりを感じにくかったり、新しく参画された方にとっては未知なる取り組みだったりと、混乱の声が消えることはなかった。

5年目を迎えた今年、組織の判断としては「ツリー構造をやめよう。」と「ツリー構造じゃなければOKRではないいのでは？」の二つの声があったようで、ツリー構造をやめ、部門単位で取り組めることにフォーカスした目標設定を始めることとなった。

その矢先、OKRの取り組みに多大なる影響を与えて下さった小田中さん（下記リンク等参照）からOKRのお話を聞いたり相談する機会を得たことをきっかけに、このツリー構造、OKRの必須事項ではないことに気付かされた。

なんと、対話が必要な不完全なフレームワーク。これはまさに、スクラムと同じではないか。

ツールを使うことが目的となっていて、本来の目的を達成することを忘れてしまっていたことに気づいた自分は、過去にインプットした情報を再度洗い直し、Unlearnと現在の実態に適応するためのリビルドをすぐさま行うこととした。

本セッションでは、このUnlearnとリビルドした社内の目標設定に関するエピソードと、それに関連する仕組みづくりに奔走している経験を語り尽くします。

「アジャイル開発やってるぜ！」っていうみなさん、設計してますか？

スプリントプランニングでやることを決めて、タスクをサインアップしたら、早くコードを書いてテスト通してプルリク出してレビューしてマージしないと、次のスプリントレビューがすぐやって来る。のんびりと設計なんてやっている暇はないよ！
という感じの開発チームはありませんか？
はい、私たちのチームも割とそんな感じです。

「アジャイル開発に設計は不要です、は誤解」というのは最近では広く理解されてききましたが、では具体的に「設計で何をすればいいの？」と聞かれると、端的に答えるのは難しいのではないでしょうか。

私自身は大企業型ソフト開発（ウォーターフォールのこと）で育ち、かなり長い間設計に携わっていたのですが、アジャイルの世界に飛び込んでみると、設計というものに対してこれまでとは違った景色が見えてきたように感じています。

このセッションでは、アジャイル開発をやっていく中で再発見した「設計とは？」について再整理し、モダン開発における価値ある設計という活動に関する考察を行ってみたいと思います。

DevOpsの世界において、テストはどのような位置づけにあるのか？

テスターはどのように適応すればよいか？

DevOpsでは、開発チームと運用チームが一緒に仕事をすることが奨励されています。これにより、製品を提供するために協力する人々のネットワークが広がり、テストの境界が拡大し、テストの性質が進化する機会が生まれます。

開発チームが運用で利用可能なスキル、プラクティス、ツールを理解すると、テストは生産に向けて右肩上がりになる。例えば、本番同様の環境でテストを行うことができるオンデマンドインフラ、顧客指標から得られるA/Bテスト実験からのフィードバック、顧客からのフィードバックを迅速に提供するベータテストグループなどがあります。

DevOpsによって納品ペースが上がると、新機能のテスト戦略にも課題が生じます。開発チームは、リリースを過度に妨げることなく、どのように新機能を調査すればよいのでしょうか。テストの自動化、モニタリングとアラート、迅速な自動デプロイとロールバックなどのツールの賢い利用を含めて、テストアプローチを適応させることができます。

このセッションでは、Katrinaが彼女の著書「A Practical Guide to Testing in DevOps」からいくつかの考えを紹介します。また、DevOpsを紹介し、開発中、本番稼働中、インフラに対するテストのための一般的なDevOpsプラクティスをいくつか紹介し、DevOpsがどのように、そしてなぜテスト戦略を変えるかも説明します。

F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1新潟グランプリの勝者となり、1年間、その栄誉が讃えられます。

お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか？」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか？」
回答2「ベロシティは顧客価値につながる指標なんでしょうか？」
回答3「デプロイメント頻度は計測できていますか？」

お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは？」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか？」
回答3「プロダクトオーナーを説得する役割の人はいないのですか？」

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー(*)：よた（yota）、てやまぐ（teyamagu）、やっとむ（yattom）、かっちゃん（katzchang）
ゲストドライバー(*)：角征典さん（kdmsnr）
*ドライバー＝回答者

お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
Google Form: F1大阪GP'22お題募集フォーム

大日本印刷株式会社でアジャイルの推進活動を始めて7年目、社内の推進グループのリーダーになって丸1年になります。
最初は6名だった推進者も、50名を超える規模まで大きくすることができました。
暗中模索・手探りで進んできた推進活動も、最近少し余裕ができ周りが見えてきて、見える世界も変わってきた感じがあります。

大日本印刷は、純粋なベンダー企業でもなく、とはいってもユーザ企業でもありません。
企画・営業職の力が強く、開発者の数も力も存在感も不十分です。

そんな組織の中でどのようにアジャイル文化を浸透させてきたか、何と戦ってきたのか、どんな変化があったのか、
そして自分はこれから何と戦っていくのか、をお話ししたいと思います。

同じような境遇の方に聞いていただき、共感していただけると幸いです。

チーム月面着陸は2021年度enPiT準拠テーマを受講しました！ PBLで提示されたお題はJavaScriptによるビジュアルなプログラムの開発でした。

私たちは、教員から教わるというよりも、自分たちで考え、選択し、行動してきました。スプリントの単位としては1weekスプリント、うち授業として与えられた時間は、6時間でした。 スプリントを1week単位で行うことで、3か月という短い開発期間中に計6回のレビューを実施します。 そのため、短いスパンで何度も改善することを、フィードバックを活かしながらすることができました。

授業としての活動は2022年1月で終わりましたが、その後も私たちは活動を続けました。その期間で、少しずつ開発も進め、アジャイルPBL祭りにおいて発表をしました。さらにその後も歩み続け、少しずつやっていることがあります。

本発表では私たちのチームである「チーム月面着陸」の学びと成長について、いくつかのトピックを取り上げて、視聴者参加型クイズ形式インタビューでお話しします！

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

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

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

複数人で１つのプログラムを作るチーム開発のテクニックとしてモブプログラミングという手法があります。これをプログラミング以外の作業もみんなでやろう、という発想にしたのがモブワークです。

私のチームではモブワークを基本としつつも状況次第であえて1人（ソロ）での作業を混ぜることで、チームの開発を安定させつつタスク完了までのリードタイムを短くする状態を実現しています。

モブとソロを織り交ぜた開発のメリットについて、実践で工夫しているポイントや実現までに苦労したことなどを通じてお話しします。
「チーム開発って結局何をすればいいんだろう」とお悩みの方へ事例の１つとして参考になれば幸いです。

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

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

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

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

Scrum Fest 大阪 2022が開催される期間とほぼ重複するように、2022/06/15(Wed)-17(Fri)の期間にインテックス大阪で「EDIX(教育 総合展) 関西」が開催されます。その名の通り、主に教育に特化したソリューションが展示され、具体的には

• 第5回【関西】教育ITソリューション EXPO
• 第5回【関西】[学校]施設・サービス EXPO
• 第3回【関西】STEAM 教育 EXPO
• 第2回【関西】保育・幼稚園ICT化 EXPO
• 第2回【関西】人材育成・研修 EXPO

という複数の展示会が並列開催されたものを総称して「教育 総合展 (EDIX)」と呼びます。ちなみに5月には「教育 総合展 (EDIX) 東京」というイベントもあるので、関東でIT教育に興味がある人はこちらの方がおススメです。

筆者は2020年から文部科学省が段階的に小中高校に義務化・導入した「プログラミング教育」に強い興味を持ち、都市部と比べてIT人材の乏しいであろう地方で何か自分が力になれないか、という思いから、故郷である長野県飯田市近辺に約20年ぶりに戻りました。とはいえ、直近は故郷に戻ったばかりで具体的な活動は何もできておらず、市場調査や技術調査に終始しています。

筆者は今回の「EDIX(教育 総合展) 関西」も市場調査の一環で参加する予定ですが (どっちがついでなのかはさておき) その足でScrum Fest大阪 2022にも現地参加するつもりでいます。せっかくなので、筆者が直前でインテックス大阪で見てきたものをアッツアツの状態で (＝※意訳：ろくに分析もしきれてない状態だけど、筆者がとりあえずなにかしら面白いと思ったものをそのままマルっと) 皆さんにご紹介し、色々ディスカッションする機会にできたらいいなと考えています。

もしかしたらスクラムもアジャイルもまるで関係ない内容になってしまうかもしれませんが、この日この場所だからこそできる話題で皆さんと盛り上がれたらいいなと思います。門外漢かどうかは一旦横に置いておいて、自分たちなりに一緒に日本の未来のIT教育について語ってみましょう。

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

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

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

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

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

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

新人研修やインターン研修でやっているリモートでのスクラム研修のお話をします。

コロナ以前、弊社では新人さん向けにLEGO®を使ったスクラム研修を実施していました。

2020年、コロナの影響でフルリモート勤務となったことに伴い研修内容もリモート版にアップデートし、現在では新人さんのみならず「スクラムって何？」「聞いたことはあるけどどういうもの？」といったインターン生にも実施する定番コンテンツとなっています。

これまでの過程において、主催者側の自分たちも手探りである中で、我々や参加者側がスクラム研修を通して何を学んだか。どのような改善を次につなげることができたかをお話しします。

研修参加者のアンケートやフィードバックも踏まえながら、今後より良い体験や価値を届けるには何を改善していくかもお話しします。

——

★こちらのセッションは事前収録を行い、当日は動画を放映する形となります。
★ご質問などはセッション中でもDiscordに記載いただければ、その場ですぐに回答させていただきます。

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

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

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

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

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

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