2020年に出版された『Clean Agile―基本に立ち戻れ―』では、著者のアンクルボブが、巷にはびこるアジャイルの「不正利用」を指摘しながら、本来の姿である「基本に立ち戻る」ことを呼びかけ、現在のアジャイルにバランスをもたらそうとしました。

それでは、スクラムにも「不正利用」はあるのでしょうか？ Jeff Sutherlandのブログによれば、平均的なチームであってもスクラムを中途半端にしか活用できておらず、結果として半数以上が導入に失敗しているそうです。ということは、自分ではスクラムをやっていると思っていても、それはスクラムの「不正利用」なのかもしれません。

そこで本講演では、巷にはびこるスクラムの「不正利用」を減らすべく、アンクルボブのように「基本に立ち戻る」ことで、現在のスクラムにバランスをもたらしたいと思います。基本に立ち戻れ、私の好きな言葉です。

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お題募集フォーム

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

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

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

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

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

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

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

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

※ インプロビゼーション(improvisation) = 略してインプロ、または即興演劇

相手と協力し、互いにインスパイアしながら作品を作り上げていくインプロビゼージョンの世界。
こちらを実際に体験できるワークショップを実施します。

インプロ（即興演劇）のワークショップを通して、
普段のお仕事やチームで仕事をする上で、どのように役立つかをみなさんと見つけていきたいです。

インプロビゼージョンの世界を私たちと一緒にのぞいてみませんか？

▼セッション詳細
このセッションはワークショップ型のため、ワーク参加の人数を制限させていただく予定です。
ワークに参加したいよ、という方は事前にお申し込みください。

僭越ながら、先着順とさせていただきます！
興味のある方はお早めにお申し込みください！

▼セッション参加について
ワーク参加可能人数：10名
参加確定方法：先着順
参加条件：
当日のセッションにビデオオン・音声オンで参加が可能であること
途中参加、途中退出なく90分参加できること

▼お申し込み方法
Discordのスクラムフェス大阪2022の「三河」チャンネルにお申し込みフォームへのリンクがあります！

▼見学枠もあります
当日はワークをビデオオフ・ミュートで見学できる【見学枠】を設けております。
お申し込みができなかった方・ワークへの参加に抵抗のある方は見学枠にてご参加ください！

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

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

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

最近よく耳にするようになったコーチング。

興味はあるけどなぜか一歩目が踏み出せない・・・
なんかうさんくさい・・・
なにから始めればいいかわからない・・・
こうやって、悩み続けてもなにもすすまない・・・
いや、だからこそ飛び込んでみてから考えよう！！

そんな想いでコーチングの世界に足を踏み入れた5人の勇者たち。

はじめた動機、バックグラウンド、学んでいるもの、進度は違えど、
実際に行動しはじめた5人だからこそ話したいことがここにある。

コーチングを学んでいるもの同士が、お互いに問うことでお互いの思考を探ります。

スクフェス大阪のオンサイトの端っこを借りて、現地からずっと配信し続けます。
こんな感じで・・・は出来ないかもだけど、iPad駆使して配信したいと思います。

品川アジャイルの人が雑談してたり、
オンサイトやオンラインにいる各地域のスクフェスオーガナイザーの人と雑談してたり、
近々行われたスクラムフェスや、これから行われるスクフェスの裏話や苦労話を聞いていたり、
セッションを見ながら雑談してたりできるといいなぁと思っています。

あとはDiscordとかのコメントを拾ったりできるといいなぁ。

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教育について語ってみましょう。

20年のアジャイルの体験と、10年の心身のカイゼンの体験の類似性は「有機的成長プロセス」でした。それらの体験を元に『「アジャイル式」健康カイゼンガイド』という書籍を共著で執筆しました。

この本には、アジャイルマニフェストや原則、自身の体験を参考にした健康カイゼンについての価値・原則や継続のポイントなどを記しています。

身体や心の漸進的変容について記した本書ですが、実はその内容は実際のアジャイルチームの意識やスキルアップなどの成長・変化にも応用できます。

本セッションでは、ソフトウェア開発と健康の類似性に言及した後に、健康カイゼンの価値・原則を、チームの成長に応用する利点、

新しい健康概念に学ぶ、チームの成長の捉え方をご紹介します。

もちろん、個人の心身の健康にも役立ちます！

どのような利点があるのかをご紹介します。

2020年始め、新型コロナウィルスの拡大により、人と会って話すことに大きな制限が生まれました。
仕事だけでなく様々な場面で、人と会って話すことがどれだけ価値のあることなのかを改めて知ることとなりました。
もちろん勉強会においても、この制限はとてつもない衝撃となりました。
それまでは大多数がオンサイトで開催されていたので、開催中止や延期に追われ、いつ再開できるのかがわからないまま、今のような状況に入っていったと思います。

不幸中の幸いか、この2年間でオンラインコミュニケーションのツールが現れ、進歩していきました。
2020年より前と同じように、人と顔を合わせて話すことが会いに行かなくてもできるようになってきています。
通勤せずとも仕事ができるようになっていき、そこで得られたノウハウが徐々にオンラインで勉強会を開催できる自信へとつながっていったのだと思います。
オンライン開催に切り替わったことで、それ以前に比べて、熱量が上がっているように感じています。
これは、きっとオンライン開催での地理的な制約がなくなったので参加しやすくなったこと、また途中で抜けるのもまたやりやすくなったのでお試しで参加しやすくなったためではないかと思います。
また、開催する側においても、会場を探すなどのコストが下がり、開催頻度が安定したり、あるトピックを思いついたらすぐに開催できるようになったので熱量が高いまま開催に漕ぎ着けられるといったこともあるのだと思います。

そして、その要因の1つにテキストチャットがあるのではないかと考えています。
リモートから参加する人の多くは、家族がいるプライベートな空間にいます。そういった方々には、声を出して話がしづらい、もしくは出せないといった制限があります。そういった状況でも、テキストであれば会話に参加することができます。

またテキストチャットのもう1つの効果として、雰囲気を残しておけるということがあります。
テキストチャットに残されているテキストは、整然とまとめられたブログによる参加レポートと比べ、そのときの雰囲気が読み取り易いと思います。
テキストチャットでは、参加者の顔（アイコンかもしれないけど）が見え、その人がどのような言葉遣い、リアクションで使われるコミュニティ独自の絵文字など、様々な表現方法があります。
時間の問題でリアルタイムで参加できなかった人たち、もしくは途中で退出しなくてはならなかった人たちにとって、テキストテキストチャットに情報が残っていると、そこからどのようなことが起きていたのかを想像することができます。
何も残っていないと、そこで何も有益な会話がなされなかったのか、それとも単に残っていなかっただけなのかという区別がつきません。ですので、その時の雰囲気を残して置けるか、というのはコミュニティを運営する上で重要になるのではないかと思っています。

このセッションでは、そういったテキストチャットで勉強会を楽しくするためのTipsを共有できればと思っています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chatworkではここ数年社内でスクラムの実践が進んでいます。

そこで、社内のスクラム実践者を集めて、それぞれ5分ずつのLT大会を開催！
社内でそれぞれの所属チームでの取り組みやエピソードを、開発者、スクラムマスター、プロダクトオーナーなどさまざまな立場から一挙にご紹介しようと思います！！

特別ゲストとして、Chatworkをご支援いただいているアジャイルコーチの山根さんも参戦予定！！

みなさんのチームは価値を提供することに集中できてますか？

チームが価値創造に集中できるように、チームの役割を明確にし、コミュニケーションをデザインし、ボトルネックを見つけ出す。簡単に聞こえるけど、すごく難しいですよね？

コンウェイの法則や認知負荷など様々な要素が組織論にはあり、チームトポロジーはそれらを組み合わせ、組織を設計するためのパターンを教えてくれます。

もし、少しでも下記のような悩みがあるなら、ぜひこの機会に一緒に考えてみませんか？

• メンバーが、他のチームの作業を待ってるので、タスクが進まないとよく言ってる
• コンテキストスイッチが大変だとよく聞く、もしくは、自分が感じる
• 持ち物が多く依存関係が大きいので、常に影響調査をしてる
• MTGが多すぎる

この発表では、僕がチームトポロジーから何を学び、楽天市場のデータプラットフォームというミッションに対し、学びを組織改善の中で活かした話をカジュアルにお話して、皆さんの気づきや、なにかのヒントになるといいなと思います。

• 中小企業の経営者はシステムの素人です。車を買うような感覚でシステムを発注することもあります。
• 経営者なので費用対効果には厳しいです、経営センスも持ち合わせておられます。
• そのような環境の中でお客様の要望に応えつつ、スクラムの良いところを取り入れてお仕事させて頂いてます。
• お手本にしたのは倉貫さんのSonicGardenのやり方です。
• 独立してからの10年間を振り返ってみたいと思います。

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

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

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

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

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

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

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

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

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

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

今年もオージス総研は、スクラムフェス大阪をスポンサーしています！

オージス総研と言ったら「モデリング」「オブジェクト指向」ですか？
弊社は、昔からソフトウェアエンジニアリングやオブジェクト指向、アジャイルなど、先端の開発手法を率先して調査・実践してやってきています。

んじゃ、実際、どんな活動しているん？と思った貴方に届けたい！オージス総研のスポンサーセッションでは、一部の有志メンバーが「個人的」に活動して「楽しんで」いる事を会社の広報とか営業とかそっちのけで話します。
（きっと、こういった個人の「好奇心」が会社としての尖り具合の素なんだと信じています）

今回は、オージス総研のビジネスイノベーションセンターの最近の取り組みを2本ご紹介。

1. 通常業務へのアジャイル適用
2. オージス総研が主催する学生コンテスト「OSCA」の紹介

真面目な話は「オブジェクトの広場」「技術・研究コラム WEBマガジン」で公開していますので、ぜひ、ご覧ください！（そして、仲間になりませんか

オブジェクトの広場：https://www.ogis-ri.co.jp/otc/hiroba/
技術・研究コラム WEBマガジン：https://www.ogis-ri.co.jp/rad/webmaga/

みなさん、パワポカラオケをご存知でしょうか？カラオケと言っても歌は歌いません。ランダムに表示される画像を元に即興でプレゼンをするという、瞬発力と発想力とプレゼン力が試される競技（ゲーム）です。

ITプレナーズでは、組織の力を高めるためにこれまでも公式&非公式に様々な取り組みを行なってきました。その取り組みの一つとして、先日パワポカラオケを行い、大盛況（大成功）でした。

発表者も観覧者も、手に汗握る緊張を味わい、次々と沸き起こる笑いの渦に巻き込まれ、発表の後にほっと一息つく。この感情のアップダウンの繰り返しは、まるでサウナのように参加者全員の気持ちを最終的には解きほぐし、整え、そして一致団結してくれます。

今回は、このパワポカラオケを実演します。みなさんのチームでも使えそうか、体感しながらお楽しみください。

※時間の都合から、聴講者の方にプレゼンテーションをしていただくことはありませんので、安心してご参加ください。

スクフェス大阪恒例となりましたこのランチセッション。

午前中のセッションはどこの地域トラックもすごかったですねー。

お昼の時間も含めて、自称チェンジエージェントとアジャイルコーチがただただワイワイしているランチ会です。

どなたでも参加OKです。飛び込み参加歓迎です。

※各トラックのZoomだと録画公開されちゃうので、今年はDiscordの三河のボイチャでやろうと思います。

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

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

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

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

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

——

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

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

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

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

銀行の内製システム開発組織に所属しています。

私たちのプロダクトチームは下記の3部門で構成されています。

• 業務改革(デジタル化)の文脈で協業することになった事務系の部署：ステークホルダー部署でありPO襲名メンバー所属。ベンダーとのウォーターフォールでの開発経験あり。
• 事務系の処理を含めRPA化していこうというITの部署：ウォーターフォール型開発
• 私たち内製システム開発の部署：スクラムチーム

上記の、3部門の協業によるプロダクトの顧客提供が開始されました。
そして、関係性も出来上がり、関連した次の案件への案件拡大に繋がりました。

なんだかこのチームと仕事していい感じに進んだねってなったので次の案件に繋がりました。

その間に私が
スクラムマスターとしてプロダクトチームのどこを見ていたのか、
より良いプロダクトチームになるためにどんな行動を取ったのか
をふりかえります。

この"プロジェクト"を通してのスクラムマスターとしての気づきや学びなどを共有します。

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

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

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

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

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

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

フルリモートでスクラムチームに所属し、丁度半年が経とうとしています。

スクラムは既存のチームと異なり、個人やチームの問題点が可視化されるフレームワークであるという言葉通り、様々な困難に直面してきました。

中でも一番の相違点として感じたことはビジネス面や技術面の問題点を浮き上がらせるだけでなく、チーミングの問題点までも浮き上がらせることです。

今回のセッションでは個人の最適化ではなくチームとして、はたまた組織としての全体最適となる先駆けとしてどのようにチームを運営していくか、

そしてそこに持続可能性をどのように見出していくかを所属しているチームに対しての取り組み事例を交えてお話しできればと思います！

よろしくお願いします！

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

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

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

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

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

- Kudoカード

- パーソナルマップ

- デリゲーションボード

- バリューストーリー

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

- ビジネスギルド

- フィードバックラップ

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

- メリットマネー

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

- ハピネスドア

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

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

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

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

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

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

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

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

新しくスクラムチームに放り込まれたエンジニアの皆さん。
どのように技術のキャッチアップをしていくかイメージはついていますか？

新メンバーがいち早く組織に溶け込み、フィーチャーチームで必要とされる技術領域やドメイン知識を獲得できるように、メンタリングやOJT・ペアプログラミングによる支援は多く行われているかと思います。

一方で、メンティーやトレーニーにあたる新メンバーも、ただ支援を受けるだけでなく、チームに対して自ら出来ることがあるのではないでしょうか。コミュニケーション方法やペアワークの活用方法などは、受け入れ側と新メンバーのどちらもが知っていることでよりスピーディにチーム開発へ参加できます。

このセッションでは、新卒から複数チームを渡り歩いて見つけた、フィーチャーチームのキャッチアップ方法についてお話しします。

オンボーディングをする人もされる人も、一緒にコミュニケーションを取りながら学習する方法を考えてみませんか?

混乱を極めたソフトウェア開発は、もう嫌になるくらいどうしようもなくなることがありますよね。

そんな中ではガントチャートは意味をなさず、マイルストーンは有って無いようなものになっちゃいます。

心の底から逃げ出したいと思った矢先に「カイゼンジャーニー」に出会いました。当時の私はそれがアジャイルのプラクティスだとは知らなかったけど、現状がよくなるのであればと紹介されている手法をなんとなーく試してみたところ、少しずつ現状が良くなってプロジェクトを完遂することが出来ました。

そんなこんなでこの経験をもとに転職活動したら、スクラムをうまいこと回す人員として転職までできまして。島根県の端っこから、フルリモートでアジャイル開発を行うことになりまして。

当セッションでは、現状をどうにかしたいなーって人の力になれるよう、私の経験をお話します。初心者向けのお話になるかなと思います。

近年ビジネスの変化のスピードが加速しユーザー企業においてもアジャイルは一般的になりつつあります。
弊社のお客様においてもデジタルや組織のトランスフォーメーションを推進される中で、
多くのお問合せをいただいております。

そんな中、今回初めてアジャイルへの一歩を踏み出されたお客様に寄り添うにあたり、
アジャイルの知見が浅いケースならではの提案から契約までの合意プロセスや、
受託開発でアジャイルを始める際に発生する課題に取り組んできました。

そして私たちの強みでもあるインドと日本のメンバーで構成するスクラムチーム。
相乗効果と化学反応を生み出すこの体制をハイブリッドモデルと呼んでいます。
チーム構築にいつも正解があるわけでは無いため様々な実験をしました。
まだ駆け出しのチームとプロジェクトですが、多くの気付きを得て学んできました。

当セッションでは、アジャイル未経験のお客様、分散スクラムチームの2つをキーワードに、
スクラムガイドをピックアップしながら
プロジェクト序盤で得られた学びと経験をお話しします。

不動産DX事業を展開されている株式会社ランドネット様と当社（メンバーズエッジ）が出会ったのは今から約1年半前。

コロナの影響でお客様とのオンラインでの取引需要が高まってきたことをきっかけに、新規開発をアジャイル開発で取り組んでみたいという動きが高まり、アジャイル開発を中核にしたプロダクトグロース支援を得意とするメンバーズエッジに声を掛けていただきました。

ビジネス×開発一体型チームでアジャイルなカルチャーを作る足掛かりとして、まずは to C向けサービス「お客様Myページ」の開発に着手。プロダクトの目的とゴールを全員で理解一致させ、MVPの方向性を定めた上で、スピーディーなリリースと継続的な改善が出来る開発チームを構築していき、3ヶ月で初期リリースすることに成功しました。

その後も、チームや組織を一段高いレベルに引き上げるべく、UXデザイナーの参画や、代表や事業部門長らが認定スクラムプロダクトオーナーの認定を受けるなど、さまざまな取り組みを行いましたが、やはりそう簡単に従来のやり方を変えることはできません…。

本セッションでは、開発に携わった個性豊かな6名がパネルディスカッション形式で当時をふりかえりつつ、現在地や今後の展望について語り合います。

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

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

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

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

私は、株式会社フィードフォースで、アジャイル推進室という活動をやっています。
アジャイル推進室では、社内の様々なチームに対してアジャイルのワークやスクラムの知識を伝えて社内のチームをちょっと良くするという活動をしています。

今回は、開発リーダーが育休で半年間おやすみすることになったチームの話です。
この半年間は、開発リーダーとずっとやってきたエンジニア1人と、直近3ヶ月で入ってきたエンジニア3人の合計4人チームになりました。

社歴が浅い方が多いし、まだお互いの関係構築が十分にできていない中で今まで開発を引っ張ってきたリーダーが不在になる。
こんな状況でどうパフォーマンスを落とさずにチームビルディングしていったか？

そのきっかけは、チームで掲げた「ありたい姿」と「ふりかえり」でした。

このセッションを聞いて、チームビルディングで心がけたことや実際に行ったふりかえりについて紹介し、皆さんのチームでも試してみたいなと思っていただけると幸いです。

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

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

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

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

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

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

開発すればするほど製品やサービスは複雑で多くなり、依存関係があったり、制約があったり、負債が多く大きすぎたり、様々な対応を行わなければならず開発スピードは落ち、バグも増えていくことになります。

そんな製品開発の組織での QA・テスト の関わりを紹介したいと思います。

SI企業の非開発部門である経営戦略部（戦略企画、広報、秘書機能など多種多様な役割を持つ部門）にてスクラムをやってみて１年6か月

「Agileって開発の人がなんかやってるやつだよね・・・」
「スクラムって何？」
「忙しすぎてそんなのに取組めるの？」

そんな状態から、Agile スクラムの学習と準備を経て

「スクラムいいかも！取り組んでみよう！」

とスタートした2021年2月

2か月後突然の人事異動によりPOの交代と新メンバーの参入があり早々にチームの危機を迎えます。
そして、チームが安定してきた矢先の2022年4月組織変更によりチームの解散と再立ち上げ

いくつもの壁にぶちあたりながらもチーム全員で解決方法を模索し進めてきた事
非開発部門で多種多様な業務をもつ私たちのチームがどのようにスクラムを進めてきたか
スクラムをやってみる前と今とのメンバーの気持ちについてお話させていただきます。

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

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

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

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

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

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

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

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

スクラムチームに対してのエンジニアリングマネージャの役割って難しいですよね。

現在、私はスクラムで開発している３プロダクトの開発チームのマネージャを担当しています。

マネージャになってから２年弱、スクラムチームに対してマネージャとしてできることに向き合ってきました。

マネジメント範囲が３プロダクトになってくると中々１つ１つのチームに多くの時間をかけることは難しくなっています。

そんな中でどのように悩み、組織課題を解決するために取り組んできたかを紹介します。

「どうしてXXXやってるんですか？」
「え？(これ当たり前じゃないの？)」

新しいメンバーと一緒に仕事をする時や自分の取り組みををチーム外で話した時に、こんなやりとりが生まれることがあります。
そして、いざ「当たり前」を説明しようとしても、意外と言語化できてないことに気づきます。

とある仕事の中で無意識のうちにやっていた考え方・行動が、自分の想像以上に興味を引くものだとコメントを貰いました。
それを受けて、自分の取り組みを社内で発表することになり、無意識にやっていた「当たり前」にどんないいことがあるのか・誰でも実践できるものなのかなど言語化を試みました。
その「当たり前」を説明するための言語化に手ごたえを感じつつも、なぜか心のどこかで受け入れられない感覚がありました。

「自分が実践し始めたのはそんな理由だったのか？もっと自分の感情から生まれたものだった気がする......」

自分の中で「当たり前」になる前の何かに重要なヒントを感じつつ、答えが見えないまま時間が過ぎていき、時には自分の行動に自信を持てなくなりました。
それでも諦めず、深掘りと揺さぶりの問いを駆使して「当たり前」と向き合い、試行錯誤する中で見えてきたものについてお話しします。

名古屋からこんにちは。

私たちは約3年間、開発ベンダーの立場でありながらあえてアジャイル・スクラムを取り組んできました。

何故なら、そのアジャイル・スクラムのマインドに共感し、お客様のビジネス拡大に貢献し続けるにはスクラムが適していると感じたからです。

そして昨年のスクフェス大阪2021で開発ベンダーとして、スクラムチャレンジをしているといった内容を話しました。

あれから1年、改めて開発ベンダーの立場でお客様に寄り添いながらスクラムを行う難しさを実感しつつ、同時に手応えも感じています。

そこで、開発ベンダーでスクラムという特殊な前提にはなりますが、実際の現場で起きた出来事から、組織運営やスクラムチームのアンチパターン、私たちがとったより良くする工夫を紹介し、いろいろな方々へのヒントになればと思います。

基本的にマインド中心の話になります。マインドが無ければプロセスだけ行っても全く意味がないと思っていますので、ここではプロセスの話はほとんどしない予定です。

ここ数年のRettyはアジャイル関連・技術関連のカンファレンスに複数人の登壇者を輩出できています。業務を通じて学んだことを社外でアウトプットし、更なる学びを業務に取り入れることが当たり前の文化がつくれていますが、最初からできていたわけではありません。

基本的なことを地道に実践しているだけではありますが、工夫している取り組み・その背景にある考えを整理して共有することでコミュニティ・カンファレンスのさらなる活性化に繋がればと思っております。

RSGT/スクラムフェス大阪・三河・札幌に計9名、14回の登壇。

• スクラムフェス大阪2020
  • スクラム開発におけるマネジメント、目標設定・フィードバック・評価
  • 教えて！あなたの一歩を後押しした本！『旅するAgile本箱LT』 #ハッカーライフラボ
• スクラムフェス三河2020
  • リモートワーク × カンバン - Rettyのカンバンお見せします！ -
  • 新卒3ヶ月目でスクラムマスターをやった話
• スクラムフェス札幌2020
  • もりあがるスプリントレビューをしよう
• Regional Scrum Gathering Tokyo 2021
  • 「全社で大規模スクラム(LeSS)移行して1年間」Retty執行役員が全て答えます
• スクラムフェス大阪2021
  • "これから学ぶ" システム思考
  • 効果的なスプリントプランニングのトライ
• スクラムフェス三河2021
  • 「守破離の守！」スクラムガイドをみんなで読んでみた。
  • チームがLeSSにJoinして1年半経ったので振り返ってみた
  • みんなでやればいいじゃん！チームの力を高めるモブワークを始めよう！
  • チーム開発を怖がっていた私がスクラムマスターになって壁を乗り越えた話
  • スクラムマスターの育て方
• Regional Scrum Gathering Tokyo 2022
  • アジャイルに向き合うソフトウェア開発の技術面 "ライトウィング"

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

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

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

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

はずだった。

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

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

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

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

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

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

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

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

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

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

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

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

スクラムが浸透して安定した開発ができているチームでも、メンバー一人ひとりはどのくらいスクラムやアジャイルについて腹落ちしているのでしょうか？スクラムマスターなら、気になるポイントですよね。

私たちのチームではこの疑問を解消するために毎週30分の時間を使ってアジャイル開発について、ディスカッションするようにしています。例えば、「私たちは何でスクラムで開発をしているのか？効果はあるのか？」「開発する中で感じる通信不確実性は何がある？」など、私たちの開発を０から立ち返って、意見交換しています。

チームで「カレーの寓話」を題材に通信不確実性を話し合ったときにとても盛り上がり、その勢いでスクラムチームでカレー作りに挑戦した取り組みもご紹介できればと思います。【アジャイルカレークッキング】というイベントにして、チームで楽しくアジャイルを学ぶことができています。

このセッションでは、話し合いを続ける中で得られたチームの成長や学び、実際にどのような場を設計して、ファシリしているのかご紹介できればと思います。

自分が所属するUnipos株式会社では、「感情報酬を社会基盤に」というミッションを掲げてUniposというソフトウェアを開発しています。

1年半前、みんながもっと楽しく開発できるように、従来型の開発プロセスを変えようとトップの人に直談判を試みたのですがうまくいきませんでした。その後、強い理想と変えられないことにもやもやする事が増えていきました。その時から自分には強いストレスを感じる問題が起き始めます。

• 学習して知識を身につければつけるほど、現状の問題がはっきりしてくるので変えたくなるができないストレス
• 相手に問題を説明しても共感してもらえないストレス
• イケてないと感じたトップダウンの施策を見聞きするだけでストレス
• 会社内に共感してくれる相談相手がいないストレス
• 自分がうまくやれていないと感じるストレス

スクラムマスターは人にアプローチを行います。人は新しいアイデアを受け入れるのに時間がかかるので、スクラムマスターにとって忍耐が大切なメタスキルになります。

ですが、これらのストレスを受けながら単に我慢し続けると疲弊してしまいます。

つまり、ストレスマネジメントしながら忍耐の心で安定して活動を継続してくことが求められます。

自分は1年以上チームと組織の変革を探求してきました。今も組織から受ける印象は変わりませんが、自分のストレスは以前より少し楽になっています。

このセッションでは自分の1年間の活動をふりかえり、チームや組織の変革を行うときのストレスへの対処の仕方を考察します。

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

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

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

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

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

こちらはatama plus社のスポンサーセッションとなります。

atama plusは2017年4月に創業し、今年で6年目に入ります。

創業当時からアジャイル開発、Lean Start Up、デュアルトラックアジャイルなどへ取り組んできました。

たくさんの失敗をしながら今日まで取り組んでおり、僕たちのプロダクト作りの旅もまだまだ続きます。

今回はそんなatama plusが成長する中で、どういう取り組みをしてきたか、当時社内で流行っていたキーワードと共に、ダイジェストでご紹介していこうと思います。

超高速で改善を回していくプロダクト作り、組織が拡大する中でアジャイルをどうスケールさせるかへのチャレンジ、事業フェーズが変わる中でプロダクト作りの変化など、できるだけ生々しさを感じ取っていただければと思います。

SmartHR におけるスクラム開発の歴史と変遷を、僕が入社した 2018 年 8 月から現在まで時系列順に追っていきます。

僕は転職活動を行う際に「アジャイルな開発ができる環境」というのを大きな軸として転職先を探していました。その中で業績絶好調な SaaS プロダクトを抱え「スクラム開発をしている」と公言している SmartHR に出会います。

そして縁あって SmartHR に入社することとなるのですが、では 2018 年当時の SmartHR におけるスクラムとはどのようなものだったのでしょうか？

また、それから 4 年を経て 2022 年の SmartHR のスクラムはどのように変わったのでしょうか？

なるべく飾らず、等身大の SmartHR におけるスクラム開発の歴史と変遷をお話しします。

組織にスクラムを導入し、そしてよりよくしていく活動をされている皆さんが、なにかしらヒントを得られたり、または勇気づけられるようなセッションになれば幸いです。

弊社はここ何年か全社員の1割以上の人数を新卒の採用を行っている。そのため組織のピラミッドは上が小さく底の裾野が大きく広がる歪な形を取っている。

そんな中、一社員である私はひょんなことからManagement3.0に出会い有償のワークショップに参加することになる。

それから何年かしたある日、会社のエグゼクティブ全員を前にしてワークショップを行っている自分が居た。（前日の夜は一睡もできなかった）

そんな自分が何を考え、何を行いワークショップにたどり着いたかをお話します。