Conference Time
Local Time

Day 1

Wed, Jan 5
Timezone: Asia/Tokyo (JST)
08:30

    Registration - 60 mins

09:30

    Welcome Note - 15 mins

09:45

    Sponsor Talk / Keynote Preparation - 15 mins

10:00
11:30

    Lunch Time (with 30 seconds pitch from anyone) - 90 mins

13:00
  • Added to My Schedule
    keyboard_arrow_down
    Yoh Nakamura

    Yoh Nakamura - 「いい感じのチーム」になるためにやること

    schedule  01:00 - 01:45 PM JST place 2F Main Hall WEST手前 (90) people 65 Interested star_halfRate

    成長しているプロダクトには"いい感じ"のチームが関わっていることが多くあります

    "いい感じ"のチームとなっていくには、それなりの時間が必要であり、その時間の中でどのようなマインドセットでどのような活動をしていくかによってその行く末は変わってきます
    もちろんチームの行く末によってプロダクトの成長にも影響が出てくることもあります

    2020年版のScrumGuideでは、スクラムチームの説明として以下のように記述があります

    スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究 開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、 自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続 可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上す る。

    では、"いい感じ"のチームになるにはどのような活動を行い、どのような関心を持てばいいのでしょうか?

    このセッションでは、「 "いい感じのチーム"に近づくヒント」を中心にチーム活動に関するいろいろなトピックについて、元ギルドワークスのアジャイルコーチとして70チーム以上を支援してきた自分なりの経験や考えをお話できればと思います

  • Added to My Schedule
    keyboard_arrow_down
    Shusuke Fujii

    Shusuke Fujii - 非ITの宿泊業なのに、なぜDXを推進できるのか?

    schedule  01:00 - 01:45 PM JST place 2F Main Hall EAST奥 (90) people 30 Interested star_halfRate

    宿泊業である星野リゾートは、従業員の多くは、接客中心の職場であるが、ITへの関りは少ない。

    そのようなITとの関りが少ないイメージの強い企業の星野リゾートはアジャイル開発を促進し、多くの成果を上げることで、DXを推進する企業として認知され始め、宿泊業界に厳しいコロナ禍でも躍進を続けている。

    非IT組織においてアジャイルを推進するのはも簡単ではないと思われるかも知れない。しかし、星野リゾートではアジャイル開発に向いている組織文化を長年続けており、そのエッセンスをうまく活用することで、アジャイル開発を実践し、DXを推進する企業としての成長を図ることができている。

    本セッションでは、アジャイル開発を下支えする組織文化とその取り組みについてお話します。

  • Added to My Schedule
    keyboard_arrow_down
    Yuichi Tsunematsu

    Yuichi Tsunematsu - アジャイルに向き合うソフトウェア開発の技術面 "ライトウィング" / Technical aspects of software development towards agile

    schedule  01:00 - 01:45 PM JST place 1F Room B (48) people 39 Interested star_halfRate

    アジャイル・スクラムに関するカンファレンスプロポーザルは『「気がついたこと」「心構え」「事例」に関する話が多い』と感じています。たまに見かける技術の話であっても「テスト駆動開発」「モブプログラミング」「DevOps」ぐらいのざっくり粒度、またはそれらを取り入れるときの心構え的なものではないでしょうか?

    アジャイルのゴールを実現するにはチーム環境だけでなく、開発環境も必要なはずです。もっと真正面から技術面のトピック・取り組みを取り上げ、もっと良い知見を広く探究していきませんか? Retty株式会社での事例を紹介することで、アジャイルなソフトウェア開発を支える技術面の取り組み水準を底上げしたいと思っております。

    ---

    In order to realize the goals of Agile, we need to enrich not only the team environment, but also the technical side. We would like to cover topics and initiatives on the technical side more head-on. By introducing case studies at Retty Inc., I hope to raise the level of technical efforts to support agile software development.

  • Added to My Schedule
    keyboard_arrow_down
    Makoto Wakimizu

    Makoto Wakimizu / Takahiro Hiasa - どうする?GOする!LeSS導入する!?

    schedule  01:00 - 01:45 PM JST place 1F Room C (72) people 22 Interested star_halfRate

    皆さんは、会社の成長に伴って、組織の不整合やチームの心理的安全性に問題を抱えている、または抱えていた経験はございますか?

    私達、株式会社Mobility Technologies (以下、MoT)は、JapanTaxi株式会社とDeNAのオートモーティブ事業の一部が統合して2020年4月に誕生しました。
    統合前は競合であった『JapanTaxi』『MOV』両アプリのそれぞれの強みを活かす形で、MoTとして最初の顔となるタクシーアプリ『GO』を統合からわずか5ヶ月でローンチしました。

    その後間髪入れずに、AIを活用した大型機能2つを2020年11月に同時リリースし、ダウンロード数No.1*の実績を誇るまで成長してきました。
    また会社としてもアジア太平洋の国・地域において最も調達額が多いテックススタートアップとして日本から唯一ピックアップされるなど、期待と注目度が非常に高い企業にスケールしてきました。

    順調なスタートをきれたMoTですが、その一方で会社が誕生したばかりで事業を急ぎ軌道にのせるために、タイトなスケジュールの連続、案件のスコープが大きくなり分割できずリリースサイクルが遅い、改善タスクが消化できない、案件ごとにチームメンバーが異なりコミュニケーションコストが高い、など様々な理由によりプロダクト開発メンバーの心理的安全性が下がったという課題が生じました。

    その課題解決のために、MoTの『GO』開発チームでは2021年5月からLeSSを導入しました。
    LeSSを導入したことで、ロードマップ上の案件と改善タスクを同時並行的に進められる組織体制に変革し、コミュニケーションが活性化して心理的安全性も改善されてきました。

    本セッションでは2つの異なる組織とプロダクトがどのような仕組みを用いて組織とプロダクトを1つにし、「進化」させているのかについて、POとEMの視点からお伝えしたいと思います。

    *App Annie調べ:タクシー配車アプリにおける日本国内ダウンロード数(iOS/Google Play合算値)調査期間:2020年10月1日~2021年9月30日

  • Added to My Schedule
    keyboard_arrow_down
    shuichi shimura

    shuichi shimura - KDDIで複数チームのスクラムを6年間やってみた

    schedule  01:00 - 01:20 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 15 Interested star_halfRate

    KDDIではスクラムによる開発がどんどん広がっております。

    私自身もパーソナル向けのアプリケーションの開発でKDDIで立ち上げから6年間、複数チームでのスクラムをやってきました。

    開発規模としては3チーム構成で全体で30人くらいという複数チームスクラムのプロジェクトの中で主にスクラムマスターとして業務をしてきました。

    • サービスインまでのドタバタした時期
    • 障害が発生している中でも機能をリリースしていかなくては行けなかったサービスイン後の時期
    • 徐々に安定していくと共にお客様の数も増えて開発以外の運用業務も増えていく時期

    などに発生した様々な課題やそれに対処した工夫がチームにありました。

    スケジュールの言い方や運用や保守などのプロセスの統一などチーム内で工夫したことについて時間が許す範囲でお伝えできたらと思います。

    自分自身のふりかえりも兼ねて気がついたことなどまとめて、皆さんの少しでも参考になれたら幸いです。

13:25
13:45

    Short Break - 15 mins

14:00
  • Added to My Schedule
    keyboard_arrow_down
    フーリー & カエリ―

    フーリー & カエリ― / Takahiro Kaneyama / Kazuki Mori - フリカエリ星人との邂逅 ~ふりかえりのお道具箱&お悩み相談~

    schedule  02:00 - 02:45 PM JST place 2F Main Hall WEST手前 (90) people 39 Interested star_halfRate

    セッションのやりとりはMiroを使うぞ!
    https://miro.com/app/board/uXjVOYf05MM=/

    よぉ人類!はじめまして。我々はフリカエリ星人である。

    我らが星では「ふりかえりエネルギー」が発展のために必要である。
    そんな中、遠く離れた星で「ふりかえりエネルギー」が近年増大しつつあるのをキャッチした。それが地球だ。私たちはふりかえりエネルギーの増加を図るために、地球へ向かっている。到着予定日は、地球で言う2022年1月5日―そう、RSGT2022だ。

    地球の同志とは、フリカエリ星との初邂逅となるこの喜ばしい日に、ふりかえりに関する話をみんなで情報共有したいと思っている。

    我々からは、地球の同志にふりかえりに関するTIPS集を紹介する
    ふりかえりをするとハマるポイント、新しい発見につながるヒント、オンラインでのコミュニケーション、手法。
    これらのTIPSは、我々フリカエリ星で複数の仲間たちから収集する、新鮮でかつ実体験に基づくものばかりだ。

    地球の同志からは、ふりかえりの悩みをその場で収集したい。その場で我々の知恵を授けたいと思う。地球人同士でDiscordやMiroなる機器を用いて情報を交換すれば、より大きな「ふりかえりエネルギー」が生まれるはずだ。

    それでは、同志に会える日を楽しみにしている。

    6390c8d9293a8d70.png

  • Added to My Schedule
    keyboard_arrow_down
    Kazutaka Matsusaki

    Kazutaka Matsusaki / Kunihiro Kuroda - アジャイル未経験の部署とどう取り組んだ? 〜新チームと部署の垣根を超えて取り組む銀行システム開発

    schedule  02:00 - 02:45 PM JST place 2F Main Hall EAST奥 (90) people 39 Interested star_halfRate

    銀行組織、どういったイメージでしょうか?

    古い、固い、つまらない、そういったイメージを持つ人が多いかと思います。
    何を隠そう、私もそうでした。

    実際に入社当初感じたのは、ザ・縦割り組織。

    初対面でまず確認。役職は?何年入社?
    出社したらまずは上席に挨拶。帰りももちろんご挨拶。
    Webで入力したのに、なぜか同じ内容を紙に手書きでもう一度。え?!
    堅実が一番!一番最初に挑戦?!いやいや、どこかに事例ができてからで…
    上げればキリがないくらい昔ながらの日本の組織。

    銀行の開発は?というと

    外注オンリー。
    大事なのは外注管理と、守りのIT。
    すごい額とすごい年数の開発がいたって普通。

    (ちょっと誇張気味ですが)さて、想像できるでしょうか?

    そんな組織に内製アジャイル開発チームが立ち上がって3年半。

    最初の2年くらいは、まずは自部署内での新規開発をメインに行っていました。
    (ここの話はリンクのスライドで。)
    そして、3年目に入ってから少し経った頃、これまで自部署メインで取り組んでいた開発を、

    いよいよ他部署と協働の活動に広げていくことに。

    さて、前述の通り、これまでの銀行開発。完全外注です。
    当然、今回一緒に活動する他部署のメンバーも内製開発の経験はありません。
    ましてや、アジャイル?!スクラム?!そんなものは完全に未知の世界。
    やりたいことも、将来的に既存の業務を置き換えよう!
    野望たっぷりな物語。
    既存業務にもバリバリからみそうな難易度高めの案件。
    さらに、開発チームも立ち上げたばかりの初々しいチーム。

    もはや困難しか思い浮かびませんでした。
    (これまではきっとこれを外注に出してとんでもない年月とお金をかけて実現しようとしたんでしょうね…)

    とはいえ、

    新しいことに挑戦!

    自分たちの活動が今後の新しい世界を切り開いていく!
    やりがいはたっぷりですよね。

    そんな困難とやりがいに満ちたプロダクト開発。

    これまでのスクラムマスター経験をどう活かし、どう取り組んだのか。

    特に、協働部署と上手くやっていくためにどういうことを行ったのか、スクラムマスター視点ではここを中心にお話したいと思います。

    さらに、社内・チームへの啓蒙活動も含め、今回は、開発メンバーを巻き込んでスクラムマスターと開発メンバーの2人でお伝えしたいと思います。

    初めてスクラムを体験した開発メンバーの視点、

    聞いてみたくありませんか?

    まだまだ成長段階で、すごい人達がすごいことをやったという話ではありませんが、
    レガシーの代表とも言えるような

    銀行が挑戦しているのだから、自分たちもできるはず!

    そういったことを感じてもらえるようなセッションにできればと思います。

  • schedule  02:00 - 02:45 PM JST place 1F Room B (48) people 18 Interested star_halfRate

    Last April, when Covid-19 began to rage, I became Head Of Engineering (VP). I didn’t know if I was accepted by everyone or not, if I was welcomed by everyone or not. There is a huge difference between moving from a physical environment where trust and relationships can emerge easily to a remote environment in which trust and relationships are more difficult to put in place. Moreover in a remote environment the cognitive effort to solve problems it’s even higher. In this session, we will talk about what we have learned managing an engineering organization in the last pandemic year, in a remote setting. We’ll explore the challenges and failures we faced and our path to improvement, as well as the development process and organizational development efforts with Matteo, who joined us as an Agile Coach. COVID was a very disruptive event that changed the worldwide way of working forever but thanks to company resilience and fast ability to adapt and change we were able to reduce the impact of some organizational issues. This is a story about how our company culture helped us to face difficulties, meanwhile our journey towards agile values, principles and practices is still proceeding.

    Covid-19が猛威を振るい始めた昨年4月、私はHead Of Engineering(VP)に就任しました。自分がみんなに受け入れられているかどうか、歓迎されているかどうかはわかりませんでした。

    信頼や関係が生まれやすい物理的な環境から、信頼や関係を築くのが難しいリモート環境に移るのは大きな違いです。さらに、リモート環境では、問題解決のための認知的な努力がさらに必要になります。このセッションでは、昨年のパンデミックの際に、リモート環境でのエンジニアリング組織の運営について学んだことをお話しします。

    アジャイルコーチとして参加してくれたMatteoとともに、直面した課題や失敗、改善への道のり、開発プロセスや組織開発の取り組みなどを紹介します。COVIDは、世界の働き方を一変させる非常に破壊的な出来事でしたが、会社の回復力と適応・変化するための迅速な能力のおかげで、いくつかの組織的な問題の影響を軽減することができました。

    これは、私たちの企業文化がいかにして困難に立ち向かうことを助けたかという物語であり、一方で、アジャイルの価値、原則、実践に向けた私たちの旅は今もなお続いています。

  • Added to My Schedule
    keyboard_arrow_down
    Daisuke Kasuya

    Daisuke Kasuya - [email protected]の理論と実装 - 組織をリファクタリングしながらスケールする

    schedule  02:00 - 02:45 PM JST place 1F Room C (72) people 54 Interested star_halfRate

    ぼくが所属している組織では、[email protected]を用いて大規模スクラムを運用しています。

    本セッションでは、実践を踏まえた[email protected]の解説と、実際の運用の工夫や導入手順などをお話できればと思います。

    [email protected] の取り組みは、2021年4月に2チームからスタートしました。その後2021年8月時点で3チームに拡張されています。
    数あるスケーリングスクラムの中からあえてこの手法を選んだのには、将来的な拡張の可能性という理由がありました。
    チーム初期の導入段階や、そこからチームが増えて拡張していく様子。MetaScrumなどで上位レイヤーをどのようにして巻き込んで整えていくか、など実際の運用の様子を紹介します。

    RSGTが開催される2022年1月の時点では、今よりさらに練度をあげているか、もしくは失敗して撤退しているか。いずれにせよ価値のある情報が提供できると思うので、うまくいっているにせよ、いっていないにせよ赤裸々にお話できればと思っています。

  • Added to My Schedule
    keyboard_arrow_down
    Atsushi Funahashi

    Atsushi Funahashi - 開発とQAが分かれたスクラムチームを解消する第一歩

    schedule  02:00 - 02:20 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 7 Interested star_halfRate

    ※株式会社SHIFTのスポンサーセッションです。

    私が所属するSHIFTでは、Scrumを実践する際に「QAがチームの中にいるイメージがわかない」といったお声をいただくことがあります。

    開発チームとQAチームが分かれていて何回かスプリントが終わった後に引き渡してテスト、リリースすることが多いようです。

    このような状態を見直し、One Teamとして行動するためのはじめの一歩となる準備や流れをお伝えしたいと思います。

14:25
  • Added to My Schedule
    keyboard_arrow_down
    Taku Fujii

    Taku Fujii / AYAKO YAJIMA - こたつテラスでわいわいお話しましょう!

    schedule  02:25 - 02:45 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 2 Interested star_halfRate

    オージス総研では、「この季節にゆっくりとお話すのはこたつがいいね」ということで、バーチャル空間oViceで様々トピックスについてお話をするためのこたつを用意しました。このスポンサーセッションでは、こたつテラスでお話するトピックスから「落語の登場人物に学ぶコミュニケーションと場づくり」と「Management 3.0モデル超入門」の2点を紹介します。ご紹介するトピックスの要旨は以下のとおりです。

    落語の登場人物に学ぶコミュニケーションと場づくり:
    コロナ禍において、コミュニケーションの取り方/受け方がボーダレスになった今、人の心への寄り添い方や雰囲気をつかみとることの意味が再度問われています。今回は自分が大好きな世界観で展開されている”落語”からそのヒントをもらいたいと思います。彼らのコミュニケーション、場づくりから得られる知見から、皆さんと“対話しながら”、対話や問いの立て方や共感性と話の進め方の理論から場の生成にポジティブに寄与している観点を見つけたいと思います。キーワード:対話、共感、アプリシエイティブインクワイアリ

    Management 3.0モデル超入門:
    ビジネス成果を上げるために、自己組織化しているチームにマネジメントはどのように関わればよいでしょうか?その答えを考えるヒントを提供するのがヨーガン・アペロさんが提案したアジャイルなマネジメント方法であるManagement 3.0です。本セッションでは、Management 3.0と従来のマネジメント方法との違いと、Management 3.0モデルの6つの視点を紹介します。

14:45

    Tea Time - 30 mins

15:15
  • Added to My Schedule
    keyboard_arrow_down
    Tomoharu Nagasawa

    Tomoharu Nagasawa - プロダクトゴールとは?あるいはプロダクトのゴールを設定するには何が必要か?

    schedule  03:15 - 03:35 PM JST place 2F Main Hall WEST手前 (90) people 77 Interested star_halfRate

    『スクラムガイド』2020年11月版より登場した「プロダクトゴール」。ガイドによれば、以下のように説明されています。


    プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットとなる。(中略)プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。(後略)


    ここでだけみても非常に重要なゴールであることがわかります。しかしながら、自分たちのプロダクトにとってのゴールを具体的に設定するには、考慮すべきパラメータが多いのではないかという印象をどうしても受けてしまいます。それでいてあらかじめ決められた目標や予算、期日にロックオンされ、有名無実なプロダクトゴールにならざるをえなく、建設的なプロダクトゴールを諦めてしまっていないでしょうか。はたまた硬直化したプロダクトゴールは経験主義と矛盾した概念や結果につながりかねず、従来思考の経営者やマネジメントへの誤解の元にもなるという議論も積み重ねてきました。

    このセッションでは、「プロダクトゴール」を解説しつつ、できるだけ具体的で成果につながるプロダクトゴールを設定するために、アジャイルコーチが支援先でも共に取り組んでいる「エビデンスベースドマネジメント」を用いたプロダクトゴールの設定と達成(あるいは放棄)についての考察を共有します。


    エビデンスベースドマネジメント(EBM)とは
    EBMは、組織が不確実な条件のもとで顧客の成果や、組織の能力、ビジネスの結果を継続的に改善するために役立つ経験的アプローチです。組織が価値を提供する能力を向上させ、戦略的ゴールに向けた道筋を模索するための経験主義に基づくフレームワークで、Scrum.orgによって考案されたものです。


    セッションの提案するために書いたポンチ絵:

    ProductGoalwithEBM.png

    ThePathToMoreEffectiveAgileFull2.png

    このセッションで取り扱わないこと:

    • 正解・正答(考察セッションです。正解は聞いていただき、実践の中で見つけてください)
    • プロダクトバックログの作り方
    • エビデンスベースマネジメント(EBM)の自体の詳細解説
  • Added to My Schedule
    keyboard_arrow_down
    Tomonori Sano

    Tomonori Sano - スクラムチームとアジャイル開発ガイドライン

    schedule  03:15 - 03:35 PM JST place 2F Main Hall EAST奥 (90) people 30 Interested star_halfRate

    【重要】ラグビーの話は一切しません。

    スクラムが組織内で広がる際に、アジャイル開発標準のようなルール作成を検討したことがある、もしくは作成したという組織は多いのではないでしょうか。

    個別のチームではスクラムガイド+αで十分だったものが、組織が大きくなるにつれ、標準化や効率化を目的としてルールを制定したくなります。その際に、アジャイル開発標準ガイドラインのようなドキュメントが作成されることになります。

    一方で、策定したルールをドキュメント化したものの、読まれない、更新されない、作って終わりのような残念な結果にもなりがちかと思います。

    本セッションでは、私が所属するKDDI DIGITAL GATEで作成し2年間運用され続けているルールを、ドキュメントをお見せしながら、何を書いて、何を書かないか、どのようなルールで書いているかをお伝えしたいと思います。

     

    大事な事なので、ラグビーの話は一切しません。

  • Added to My Schedule
    keyboard_arrow_down
    Yoshiki Iida

    Yoshiki Iida - 強くてニューゲームなプロダクト開発 〜制約ゼロから長期で進化し続けられるシステムを作るチャレンジ〜

    schedule  03:15 - 03:35 PM JST place 1F Room B (48) people 14 Interested star_halfRate

    「このシステムは負債が溜まっていて変更が難しいんですよね・・」

    色々な現場で進化させることが困難になってしまったシステムの話を聞きます。

    長く成長し続けてきたシステムを引き続き成長させていくことはとてつもなく難しい。 それでも価値があるから日々頭を悩ませながら向き合っているという人がほとんどではないかと思います。

    ここであることを思いつきます。

    その経験値をもってゼロからシステムを構築していいよと言われたらどうでしょうか?理想のシステムを作れるでしょうか?

    株式会社ログラスはそんな過去を踏まえて、強くてニューゲームでプロダクトを作ろうとしている人が集まっている組織です。

    プロダクトとしては経営管理SaaSという渋めの領域で会計などが絡む複雑な業務をシステム化しています。

    僕らはいくつかの実践的な取り組みを通して長期に渡って進化し続けられるシステムを目指しています。

    • 負債ではなく税金
    • テストとリファクタリングは資産であり文化
    • モデリング駆動の開発とそれを反映しやすいアーキテクチャ
    • 非連続なソフトウェアの進化を生むための社内プロポーザル

    レガシーシステムとたくさん付き合っていろいろな失敗を経験してきたメンバーがスタートアップという制約がないところで開発したらどうなるのか?長期的に進化し続けられるプロダクトを作れるのか?という疑問について多少技術的な詳細にも触れながら現時点の成果をお話しします。

  • schedule  03:15 - 03:35 PM JST place 1F Room C (72) people 37 Interested star_halfRate

    2001年にアジャイルソフトウェア開発宣言が世に出てから約20年の月日が経ちました。

    15th State of Agile Reportに寄ると、ソフトウェア開発チーム内でのアジャイルの採用が大幅に増加し、
2020年の37%から2021には86%にまで増加したそうです。マイノリティだったアジャイル開発は、ソフトウェア開発のスタンダードになりつつあります。実際にここ数年で企業から出ている求人を見ても、アジャイル開発やスクラムに由来する職種の名前をたくさん見かけるようになりました。

    ところで、
    5年後、10年後、20年後もアジャイル開発はアジャイル開発なのでしょうか。
    5年後、10年後、20年後も私たちはアジャイル開発に携わっているのでしょうか。

    もちろん目の前の仕事やプロダクトやチームのことを考えることも大切ですが、たまには少し未来のことを考えてみることも多角的な視点をもつという意味で大切なことです。

    私は、10年以上、企業内でエンジニアとしてチームの中でアジャイル開発を実践し続けてきました。その中でSilver Bullet Clubというチームを結成し、2019年にはチーム転職をして企業を越えていまもなおチームで活動を続けています。また、パラレルワークで、さまざまな組織やチームを支援するアジャイルコーチもしています。

    そんな自分が、さまざまな経験を経た現在アジャイル開発をどう捉えていて、アジャイル開発のミライをどう見ているのかについてお話してみます。

    未来が実際にどうなるかは誰にもわかりませんが、未来をソウゾウすることは誰にでもできます。
    アジャイル開発の未来がどうなるのか想像を膨らませながら、自分たちの未来をどのように創造していくのか一緒に考えてみませんか?

  • schedule  03:15 - 03:35 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 21 Interested star_halfRate

    コロナの間に始めた新たなジャーニー
    最初で最後の私のアジャイルの旅の話

    “さあ A列車で行こう
    それがだめなら走って行こう”

    “走ることは思想なのだ
    ロンジュモーの駅馬車からマラソンのランナーまであらゆるものは走りながら生まれ 走りながら死んだ
    休息するのに駅は必要だ だが どこにも駅はなかった
    「つまりあなたは こう訊きたいのですね 駅はどこだ、と」”

    ※本セッションは株式会社レッドジャーニーによるスポンサーセッションです

15:40
  • Added to My Schedule
    keyboard_arrow_down
    KazuhideInano

    KazuhideInano - あなたのSprint Goalは、機能してますか?

    schedule  03:40 - 04:00 PM JST place 2F Main Hall WEST手前 (90) people 71 Interested star_halfRate

    スクラム実践者のみなさんこんにちは。
    唐突ですがタイトルのとおり、ひとつ質問です。

    「あなたのSprint Goalは、機能してますか?」

    さて、どんな答えが返ってくるのでしょう。「何それ?」「まだ活用できてないなぁ」「一応設定してるけどね」「当たり前じゃん」などなど、いろいろありそうです。

    そもそもですが、スプリントゴール自体は過去のスクラムガイドでも記述されており特に目新しいものではありません。ただスクラムガイドがアップデートされるに伴い、より強調されてきているように見えます。そしてスクラムガイド2020においては作成物に付随するものとしてではなく、「スプリントの価値・目的を表すステートメント」や「スプリントバックログの確約(コミットメント)」として明確な位置付けがされています。

    私は外部のアジャイルコーチとして今までいろんなスクラムチームに関わってきました。その経験の中で感じていることとして、スプリントゴールの扱いに苦慮しているチームが多かったということが挙げられます。みなさんはいかがですかね?

    そこで、このセッションでは今まで私が見て来たスプリントゴールをケーススタディとしつつ、意義や効果あるいは実際に活用するための勘所はどこかを整理・深堀りし、スクラムチームの活動により一層の効果をもたらす「機能するスプリントゴール」とはどのようなものかを探求してみます。

  • Added to My Schedule
    keyboard_arrow_down
    Yudai Moriya

    Yudai Moriya - 異動することでもはじめられるScrum

    schedule  03:40 - 04:00 PM JST place 2F Main Hall EAST奥 (90) people 6 Interested star_halfRate

    学生のころからScrumを実践する機会があり、RSGT2017でその事例をスピーカーとして話したことをきっかけにコミュニティ活動を始め、 就職後もScrumの勉強を続けてきました。

    その一方で、配属先で導入されていた"Scrum"は、それまでの経験が活かせるものではなく、自分が思う開発チームのイメージとのギャップがある状態がずっと続いていました。

    そのギャップを埋めるためには、これまでに経験してきたScrumの良さを伝えてチームを変えていくしかないと思い込んでいました。しかし、コミュニティでいろんな話を聞く中で、今いる組織だけが組織ではないと気づくことができました。

    そこで、業務上のつながりはないものの、社外のコミュニティで出会った同じ会社の人に相談してみようと思いました。結果的に社内異動の希望が通り、Scrumに組織的に取り組んでいる部署で働くことができるようになりました。

    異動後は実践的な学びを得ることができ、プロダクトもプロセスも楽しむことができています。

    本セッションでは、Scrumで開発をするために異動という選択肢をとった経験と、異動後に得られた気づきや喜びについてお話しします。

  • Added to My Schedule
    keyboard_arrow_down
    Yosuke Ota

    Yosuke Ota - レガシーシステムリプレースとアジャイル開発 (過去のリプレース失敗から何を学んだのか) / Legacy System Replacement and Agile Development (What have we learned from past replacement failures?)

    schedule  03:40 - 04:00 PM JST place 1F Room B (48) people 22 Interested star_halfRate

    English follows Japanese

    私たちが現在開発しているシステムの元となったものは、テストがなく、ドキュメントに乏しく、独自フレームワークで動いている、バス係数が1の、10年以上の歴史を持つwebサービスでした。いわゆるレガシーシステムであり、ビジネスの変化に対応するための柔軟な変更を行えない状態です。一つの変更がどこに影響を及ぼすのか分からず、テストもないので自信を持って開発を進めることができません。

    そんなレガシーシステムから脱却するために行ってきたことは、関係者と対話を頻繁に行うことで達成したいことと優先順位を決め、状況が変わったら柔軟に計画をしなおし、少しずつ動くソフトウェアを作り込んでいくことでした。

    今では、簡単な内容なら要望を受けてから40分未満で開発〜本番環境への反映が完了するまでになりました。自信を持って開発を進め、変更をリリースできています。

    このセッションではレガシーシステムからの脱却を進めている私たちが、どのようなことを気にしながらシステムリプレースをしているのか、お話します。

    私は10年以上の歴史があるwebサービスのシステムリプレースに、これまで2回関わってきました。初めて関わったシステムリプレースは「読書メーター」というwebサービスで、現在関わっているシステムリプレースは「ニコニコ漫画」というwebサービスです。読書メーターのシステムリプレースでは失敗したことも多くあり、そこから学んだ内容を現在行っているニコニコ漫画のシステムリプレースで活かしています。初回の失敗との差分を含めてお話できればと思います。

     

    The original system we are developing now was a web service with a history of more than 10 years, with no tests, poor documentation, running on a proprietary framework, and a bus factor of 1. It was a so-called legacy system that could not be flexibly changed to respond to business changes. We don't know where a single change will affect, and without testing, we can't proceed with development with confidence.

    What we did to get rid of such a legacy system was to have frequent dialogues with the people involved to determine what we wanted to achieve and what our priorities were, to flexibly re-plan when the situation changed, and to gradually build a working software.

    Now, we can complete development of simple content in less than 40 minutes from the time we receive the request to the time it is reflected in the production environment. We are able to proceed with development and release changes with confidence.

    In this session, I will talk about how we are moving away from legacy systems, and what we are paying attention to when we are replacing our systems.

    I have been involved in two system replacements for web services that have been around for more than 10 years. The first one I was involved in was a web service called "Reading Meter", and the one I'm currently working on is a web service called "Nico Nico Manga". There were a lot of mistakes in the replacement of the Reading Meter system, and I'm taking what I learned from those mistakes and applying it to the current replacement of the Nico Nico Manga system. I'd like to talk about the differences between the first failure and the current one.

    Translated with www.DeepL.com/Translator (free version)

  • Added to My Schedule
    keyboard_arrow_down
    Yosuke Matsuura

    Yosuke Matsuura - チームのエンゲージメントを高め成果に貢献する段取り術とワークショップ開催のコツ

    schedule  03:40 - 04:00 PM JST place 1F Room C (72) people 43 Interested star_halfRate

    オンライン環境が当たり前になってきて、チームのメンバー間の相互理解や共通認識を形成するニーズが高まっています。
    そのニーズに応えた社内ワークショップを開催後、口コミで依頼が急増しました。
    背景には、チームのエンゲージメント(共感して、自主的に行動する)を高め、成果に貢献する「段取り」が良かったと考察しています。

    本セッションでは、まずエンゲージメントとは何か、成果に貢献する段取りとは何かについて説明します。
    それに加えて、チームのエンゲージメントを高める3つの方法を事例交えて紹介します。
    そして、エンゲージメントを妨げるものやワークショップを成功させるための開催のコツも解説致します。

    チームのエンゲージメントを高め、成果につなげていく活動のヒントや材料にしていただければと思います。

  • Added to My Schedule
    keyboard_arrow_down
    Koichiro Takashima

    Koichiro Takashima - 3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話

    schedule  03:40 - 04:00 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 11 Interested star_halfRate

    私たちのQAチームは、楽天のコマーステックという部署で独立したテストチームとして活動していました。様々な開発部署からテストの依頼を受け、プロジェクト単位でテストをする部署です。

    そんな中、昨年大きな転機がありました。組織変更でQAチームがそれぞれの開発部署に移動することになったのです。私たちの移動先はECインキュベーション開発部(略してECID)。ECIDは、フリマアプリや中古車販売など、楽天の中でも比較的新しいサービスを多く持っており、スピード感と品質の両面が重視される組織です。また、スクラム開発を始めとして様々なことに挑戦している、挑戦風土のある組織でもあります。

    せっかくそのような開発組織に来たので、開発チームと近いところでテストチームが活動することのメリットを活かそうとしました。ただ、実際にやろうとするとQAと開発チームとの間で期待値にギャップがあったり、うまくいかないことが多々。

    そこで私たちが考えたのが開発チームとの関係性の見直しです。QAが開発チームの朝礼や開発者テストに参加することで継続的にコミュニケーションを取り、その中で何ができるのかを探っていきました。

    その結果、辿り着いたのが開発チーム・ビジネス・QAが協業するという、3 Amigosの考え方です。3 Amigosの考え方の下で、まずは開発チームとの連携を強めるために、これまで別々にやっていた不具合調査をQAと開発チームで一緒にやったり、開発者と一緒にテストをしたり、様々な活動をして、結果としてプロダクトの品質は大きく向上しました。

    取り組みが上手くいったので、この手法を広げるために3 Amigosを要素分解して横展開する仕組化にも挑戦しました。

    このセッションでは、独立したQA組織から、どのようにしてアジャイルなテストチームを作っていったのか。また、独立したテストチームと開発組織内のテストチーム、双方の良さを取りながらテストチームを運営していく上での私たちの工夫を、実体験を交えてお話しします。

     

16:00

    Short Break - 15 mins

16:15
  • Added to My Schedule
    keyboard_arrow_down
    Yukio Okajima

    Yukio Okajima - 機械学習をScrumで組織的に学習する

    schedule  04:15 - 05:00 PM JST place 2F Main Hall WEST手前 (90) people 12 Interested star_halfRate

    機械学習は、現在のITにおいて欠かせなくなりつつあるテーマの一つです。しかしながら、受託ソフトウェア会社は、顧客から求められない限り、投資のためのリソースが割き難いという現状があります。このような状況を打破すべく、2020年8月より、部門横断での技術獲得活動(所属部門を離れ、獲得したい技術を活用したプロダクトを作ることで学ぶ)を始めました。実際にモノづくりをしながら学んだメンバーが、近い将来、各部門で新しい価値を生み出してくれることを願って。

    未知の分野の探索は、アジャイル・Scrumの得意分野です。私たちはこの命題を信じて、一貫してアジャイルな活動を継続しています。さらに、年度をまたぎメンバーを入れ替えていく状況においては、組織的な知識の獲得・移転・拡大も大きなテーマとなりますが、その実現に向けては、野中先生のSECIモデルを大いに参考にしています。

    2021年10月より、2年目の活動が始まります。RSGT2022が開催されるころには、2年目の活動にも成果が見え始めるころでしょう。それも前提におきつつ、「機械学習とアジャイルの相性」「事業化を目的としないモノづくり活動におけるビジョン形成」「誰もわかってない分野での学習方法」「多様な価値観を持つ幅広い世代のメンバーでの合意形成」「学習成果の移転」などのトピックについて、1年半の活動で得られた知見をベースにお話できればと思います。

  • Added to My Schedule
    keyboard_arrow_down
    Yuichi Tokutomi

    Yuichi Tokutomi - その開発計画は最初から間違えている! - アジャイルにおける開発計画の考え方について

    schedule  04:15 - 05:00 PM JST place 2F Main Hall EAST奥 (90) people 70 Interested star_halfRate

    新しいプロジェクトへの参画が決まると、開発計画書を見せていただくことになります。私は、ファイルを開いてから、わずか 3 秒でそっと閉じ、溜息と共に瞑想に入ります。「ふぅー。いつも通り、間違った開発計画だな。さて、今回はどんな作戦で進めてゆこうか…。」

    さて、多くの開発プロジェクトの現場では、たいていのマネジャーが "プロジェクトが計画通りに進まない!" と嘆いています。そんな現場では、必ず "アジャイル用語を使った行き当たりばったり開発" で進められていて、しばらくして進捗が問題になり、増員して、残業して、段階的リースをすることになります。そして、開発メンバーが入れ替わり、ナレッジが失われたプロジェクトは、二次開発以降の開発コストが高騰する道を歩むことになります。"ここまでテンプレ" ってやつです。誰しも、既視感がありますよね?

    違う現場なのに、なぜ、みんなこうなるのか? その理由は簡単です。 "開発計画が間違っている" からです。順調に進まない開発プロジェクトは、開発計画の時点で、既に同じ間違いを犯しています。おもしろいほどに。

    このセッションは、開発計画がどう間違っているのか? なぜ間違えてしまうのか? の解説から始めさせていただき、どのような計画を立て、どう運用してゆくのが望ましいのか? まで、その考え方をお伝えしたいと思います。

    そうそう、 "アジャイルはスプリント分しか見積もりしないんでしょ?" とか "アジャイルは計画しないんでしょ?" といったような誤解も解けると思いますよ。 :-)

  • schedule  04:15 - 05:00 PM JST place 1F Room B (48) people 39 Interested star_halfRate

    In order to change an organization, leaders have to change first. Be one of them and turn your organization into a successful Agile organization.

    In today’s complex, fast-changing, and unpredictable world, radically agile organizations thrive when they combine strong local autonomy with deeply shared goals. Leadership is a key factor―individuals who welcome complexity and know how to leverage influence, culture, and organizational design to align widely distributed teams are integral to success.

    Let's hear a few stories from forming an agile organization. 

  • Added to My Schedule
    keyboard_arrow_down
    Yasunobu Kawaguchi

    Yasunobu Kawaguchi - スクラム the ORIGIN : Jeff Sutherland - Roots of Scrum (2005) を語るナラティブ

    schedule  04:15 - 05:00 PM JST place 1F Room C (72) people 47 Interested star_halfRate

    2011年、スクラムの父、Jeff Sutherland 博士を日本に初めて招いて「イノベーションスプリント2011」を行いました。そこで行われた講演が "Roots of Scrum" でした。残念ながら撮影まで手が回らず、ビデオが残っていません。スクラムはどこから来たのか、日本から何位を学んだのか、多くの示唆のある講演だったと記憶しています。

    スクラムは実践と学びを繰り返し、スクラムガイドが作られ、アップデートが繰り返されています。多くの実践者が書籍を出し、保管できなアイデアで貢献してきました。しかし、スクラムガイドでは語られない源流とストーリーがあります。

    2005年に行われたカンファレンスで、 "Roots of Scrum" のビデオが公開されています。現在見ても、多くの示唆がありますし、もしかしたら多くの人はまだこれを見ていないのかもしれない、と思うところがあります。

    そこで、この60分の講演ビデオの内容を、できるだけ多く、日本語で伝えなおしたいと思います。

    オリジナルサイトより
    https://www.infoq.com/presentations/The-Roots-of-Scrum/

    スクラムの生みの親であるジェフ・サザーランド博士は、60分のJAOO2005講演で、スクラムの創始から、ケン・シュウェーバーとともにスクラムを産業界に展開することに参加し、Easel、Fuji-Xerox、Honda、WildCard、Lexus、Googleに影響を与えたことまで、スクラムの歴史を説明しています。スクラムのタイプA、B、そして「一気に」タイプCについて考察し、XPを開発する際にケント・ベックがスクラムのプラクティスを「盗んだ」というユーモラスな噂を確認している。

17:00

    Day 1 is over --- 本編は以上で終了です --- - 30 mins

17:30

Day 2

Thu, Jan 6
08:30

    Registration - 60 mins

09:30

    Welcome Note - 15 mins

09:45

    Sponsor Talk / Keynote Preparation - 15 mins

10:00
  • Added to My Schedule
    keyboard_arrow_down
    Diana Larsen

    Diana Larsen - Leading Skilled Agile Teams: Investing in Team Outcomes with the Agile Fluency® Model

    schedule  10:00 - 11:30 AM JST place 2F Main Hall + 1F Room B, C people 126 Interested star_halfRate

    Approaches to leading software development rely on building trust in team skills. Reciprocal trust between leaders and teams contributes to employee engagement and higher performance. Both are key to business success. Skilled, collaborative teams assume responsibility for the results they produce. To engage teams, leaders communicate the strategic purpose and enable growth. Leaders have a role as coaches to ensure that team members fully align on the product or service "why". By unleashing the potential of skilled agile teams, leaders can accelerate learning loops, create customer-oriented missions, and provide increased value for their organizations. But first, leaders can only impact teams if they are open to change themselves. 

    In this keynote talk with Q&A, Leading Skilled Agile Teams, Diana Larsen will lead participants to examine the role of trust, team member engagement, and investing in team outcomes. Leaders will consider ways for communicating purpose and expectations for teams. Each leader will draft a brief plan for enabling better outcomes from skilled teams. And, we’ll include plenty of time for asking questions. 

     
11:30
12:00
12:45
13:00
  • Added to My Schedule
    keyboard_arrow_down
    Ryutaro YOSHIBA (Ryuzee)

    Ryutaro YOSHIBA (Ryuzee) - プロダクトバックログ Deep Dive

    schedule  01:00 - 01:45 PM JST place 2F Main Hall WEST手前 (90) people 106 Interested star_halfRate

    プロダクトバックログのすべてを完全解説!!

    スクラムにおいて、プロダクトバックログは肝となる要素の1つです。プロダクトバックログがなければスプリントは始められないですし、単に要件を切り刻んで並べたようなプロダクトバックログでは変化にも対応できません。

    スクラムガイドを見ると、プロダクトバックログの作り方、書き方、維持や管理の仕方については、多くは触れられておらず、多くの人は実践で試行錯誤しながらより良いプロダクトバックログを目指して改善を続けられているのではないかと思います(それはそれで素晴らしい)。

    一方でプロダクトバックログを誤解しているのもよく見かけます。すべてをユーザーストーリー形式で書く必要もないですし、全部を同じ具体性にする意味もありません。すべてのプロダクトバックログアイテムをプロダクトオーナーが作らなければいけないわけでもないですし、すべてのプロダクトバックログアイテムを実装しなければいけないわけでもありません。Webアプリケーションでログイン機能がプロダクトバックログの上位に必ず来るわけでもありません。

    本セッションでは、プロダクトバックログをうまく使えるようになるための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

     

  • Added to My Schedule
    keyboard_arrow_down
    Atsushi Nagata

    Atsushi Nagata - シン・モブ・プログラミング 第三形態

    schedule  01:00 - 01:45 PM JST place 2F Main Hall EAST奥 (90) people 13 Interested star_halfRate

    サイボウズでは2018年に、kintoneの開発部隊からモブが部分的に始まり、それが、チームの拡大とともにkintoneの開発チーム全体に広がった。そのモブは、高い心理的安全性をベースに、チームにおける認知活動が行われていた。チームメンバー同士の多様性による創発と、高いレビュー効果があいまって、モブ・プログラミングの効果を出していた。その後、Hunterにも訪問し、そこで、ここでのモブは、変異を遂げていることに気が付いた。導入による開発の変容を第一形態とすれば、これは第二形態といえる。

    独自のモブのメンタリティは開発チームだけでなく、全社に広がった。プログラミングだけでなく、2人以上で集まった思考活動をモブというようになった。

    とそこで、最近、モブに対する反発の行動が一部にでてきた。以前もあった一過性のものと思っていたが、今回は思いのほか深く、あるチームの運用にも影響を与えることがあった。HunterのChrisにも意見を聞き、我々はそれに今向き合い、新たな形を模索しながら、今でもモブの活動は行われている。

    これは、第三形態への新たな変容なのだろうか。ここで起こったことは、もしかしたらモブをやられている他社でも起こるかもしれない。

    皆さんと共有しながら、次の形態への変容を考えてみたい

  • schedule  01:00 - 02:40 PM JST place 1F Room B (48) people 27 Interested star_halfRate

    チームの中にある個々人をそれぞれコーチングすることと、チーム全体の関係性をコーチングすることには大きな違いがあります。
    個々に1on1したり対話するわけではなく、そのメンバを全体性として扱う方法をシステムコーチングというやり方を通して学び、感じてみたいと思います。

     

    ※本セッションは現地会場のみの参加型セッションとして開催します。参加人数には限りがあります。
    オンライン参加の方や人数制限で参加できなかったりした方で、興味をもたれたり、独自に開催して欲しいなどのご要望などあれば相談できるかもしれないので、諦めずにお気軽に一度ご連絡ください。

    ---

    本セッションは参加者のみなさん自身が システムコーチング® を実施・提供できるようにトレーニングすること目的とするものではありません。体験セッションを通じてよりシステムコーチング®に馴染みを持ってもらうことを目的としています。
    トレーニングを受けたい方は CRR Global Japan へどうぞ !!


     

    以下のものは、CRR Global Japan 合同会社の登録商標です。 http://www.crrglobaljapan.com
    システムコーチング®
    関係性システム™

     

  • Added to My Schedule
    keyboard_arrow_down
    kyon _mm

    kyon _mm / neno neno - Extreme Small Patterns -チームを100倍理解する方法-

    schedule  01:00 - 01:45 PM JST place 1F Room C (72) people 32 Interested star_halfRate

    みなさんの周りに「生き生きとした繰り返しあらわれる構造」はありますか?

    RSGTをはじめとするカンファレンス、書籍、ブログ、Wiki、コミュニティ、チーム、会社、学校。様々な場所でおたがいの知見が共有され議論され、モチベーションをあげて現場にむきあうということをしてきました。そのなかでいくつもの工夫、プラクティス、パタンを発見し、共有し、教えてもらい、試してみて、試されてみてということの連続で徐々に自分達の実力があがっていることを実感し、またエンゲージメントの高い状態を保てていることにも気付きました。

    そこからアジャイルコーチをして気付いたことがあります。あまりにも形式知と現場での導入にギャップがあることです。それゆえにアジャイルコーチとして仕事があるわけですが、これはアジャイルコーチによるアジャイル実践知の独占ではないでしょうか。。。パタンはデザインの民主化であり、アジャイルはプログラマーの復権という側面がありました。ですが、現在のスクラム界隈、アジャイル界隈は元の理念から遠い場所にいるのではないだろうか。。。そんなことを思うようになりました。

    そして、47機関はパタンランゲージとむきあうようになりました。アジャイルコーチとして活躍している自分を、アジャイルチームとして活躍している自分達を、一度リセットするためにです。いまこそソフトウェア工学を、コンサルティングを、コーチングを、ナレッジ共有を変えたいと。

    その一端として、パタンランゲージの解像度を極限にまで高くすることにしました。わたしたちのパタンは数百を超え、非常に繊細で柔軟で美しくその形を表してくれるようになりました。パタンにはヒエラルキーがあり、その大きさは様々です。

    アジャイル開発で共有されているパタンやプラクティスのおおくは10分から60分程度の活動をまとめたものがおおくみられます。47機関ではその大きさだけではなく、6秒単位までのパタンを発見し、自分たちの振舞いを、チームをデザインし、実践するようになりました。600秒単位でしかアドバイス、共有、フィードバックできなかった私達は6秒単位で自分たちについて考えられるようになりました。

    このような取り組みをへたことで、アレグザンダーが提唱している空間に無数に存在する生命構造を、調和するということを徐々に理解でき、私達がさまざまなものとつながっていることを理解し、実践できるようになりました。

    みなさんの周りに「生き生きとした繰り返しあらわれる構造」はありますか?

    アジャイル開発はその一部にすぎません。47機関がチームを100倍理解できるようになったその経緯、事例、そしてみなさんにオススメのはじめかたを紹介しようとおもいます。

  • schedule  01:00 - 01:20 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 7 Interested star_halfRate

    ※本セッションはソフトバンク株式会社によるスポンサーセッションです

    デジタルネイティブ (1990~)、ネオ・デジタルネイティブ (2000~)、クラウドネイティブ (2010~)、AIネイティブ (2020?~) など世代を表す俗語として「~ネイティブ」という言葉が用いられます。
    しばしば依存度が高いという皮肉にも用いられてはいますが、その言葉には以下の

    • 対象に幼いころより慣れ親しんでいること
    • 対象への理解が深いこと

    といったポジティブなイメージがあります。つまり物事は早くに触れるに越したことがないのです。

    アジャイルもきっと同じです。できる限り早く触れた方が良いはずです。
    いっそのこと新人研修から携われたら、それはもう「アジャイルネイティブ」と言っても過言ではないはず。。

    ソフトバンク株式会社 IT本部では2020年度より新人研修の一環として4週間強にわたるアジャイル開発研修を行っています。さらに新人研修で最も評価の高いプロダクトを作成したチームはそのまま1年間継続してプロダクトを開発する権利が与えられます。

    本講演では幸運にも継続開発を勝ち取ることができ、約半年間スクラム開発を経験をしてきた
    「アジャイルネイティブ」な私達のチームに関して以下の項目を報告いたします。

    • 新人研修にアジャイルを取り入れると魅力的な新人が育ちますという話
      • プロダクトを開発出来て
      • 最新の開発手法に理解があって
      • チームビルディングが得意
    •  5ヵ月のスクラム開発を通して学んだ3つのこと
      • 会議時間の短縮と効率化
      • モブプロからペアプロに移行していくと
        • 技術レベルが平滑化ができる
        • アーキテクチャの共有もできる
      • 「後でテストを書く、リファクタする」は結局しません。

    本講演が皆様にとって
    これからアジャイルに取り組む方の道しるべになったり、
    新人研修の内容を考えるきっかけになったり、
    私達がアジャイルのみの経験で行き詰ったところから、皆様の他の開発手法の経験が実は今に活きていることを実感したり、
    はたまた初期のスクラムチームのありがちな問題を見ながら昔を思いうかべたりと
    とにかく楽しく有意義な時間になればと思っています!

13:25
  • Added to My Schedule
    keyboard_arrow_down
    Yoshihiro Yunomae

    Yoshihiro Yunomae - モバイルゲームの運用の安定化のためにプロセスマネジメントをチームで取り組んでみた

    schedule  01:25 - 01:45 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 9 Interested star_halfRate

    モバイルゲームはリリースして終わりではありません。むしろリリースしてから、何年にも渡る長い運用が始まります。アカツキの運用しているとあるゲームタイトルで、様々な課題が表出化してきました。それらの課題を表面的に解決することは出来ましたが、根深い問題がいくつも残っていて、到底一人・二人で解決できるレベルではありませんでした。そこで、根本的に課題解決していくためにプロセスマネジメントチームを結成し、チームで課題発見・解決にあたりました。本発表では、プロセスマネジメントチームをどのように作り、どのような課題解決を行ったのか、そしてどのような結論が得られたのかを共有すると共に、今後の展望についてお話します。
    特に、元々バラバラの業務をしていたメンバーがチームとして成果を最大化できるよう、実施した様々な工夫についてお話しします。

13:45

    Short Break - 15 mins

14:00
  • Added to My Schedule
    keyboard_arrow_down
    Kaori Tokiwa

    Kaori Tokiwa / Naoki Kojima / Yasuharu Nishi / やすよ おおの - QAなんなん?~みんなが納得できるQAのスタイルを見つけよう~

    schedule  02:00 - 02:45 PM JST place 2F Main Hall WEST手前 (90) people 22 Interested star_halfRate

    スクラムチームが「うちのQAなんなん?」と思っている状況は意外に多いと思います。その原因の一つは、QAのスタイルがチームや組織に合っていないことにあります。今回は、チームや組織にアジャストできるようQAのスタイルを診断する「QAスタイルファインダー」というツールを紹介します。またSIGSQA-jpのメンバによる、アジャストできている組織やそうでない組織のリアルエピソードを交えながらのトークタイムを楽しんで聞いて頂ければと思います。

  • Added to My Schedule
    keyboard_arrow_down
    Satoshi Harada

    Satoshi Harada - これからの「スクラムマスターのキャリアプラン」の話をしよう。スクラムマスターの前に広がる世界

    schedule  02:00 - 02:20 PM JST place 2F Main Hall EAST奥 (90) people 60 Interested star_halfRate

    「スクラムマスターのキャリアプラン」について、スクラムマスターのロールを担当している人なら一度は考えたことがあるのではないでしょうか?

    そんなあなたはきっと以下のような漠然とした不安を抱えているのではないかと思います。

    • スクラムマスターって、開発タスクを持たないので開発者ではないし、開発リーダーをやるわけでもないし、プロジェクトマネジメントをするわけでもないし、メンバーの評価をするわけでもない。。。
    • でも、スクラムマスターとしてチームを陰ながら支えて、チームメンバーが成長したりチームが大きな成果を出せるくらいまでに成熟していくのを見るのは楽しいしやりがいを感じる。。。
    • 今後もスクラムマスターをやっていきたいが、今後5年・10年・20年もスクラムマスターで居続けることはできるのだろうか。。。
    • 裏方になったことで開発の最前線から一歩引いたが、今後のキャリアプランをどう考えればよいか。。。
    • スクラムマスターの市場価値はあるのだろうか。転職のときにスクラムマスターの経験は評価されるのか。。。

     

    その一方で、エンジニアのキャリアモデルは大きな変化の波に晒されています。

    ほんの数年前まで、PG(プログラマー)からキャリアを開始した若手は、SE(システムエンジニア)やPjM(プロジェクトマネージャー)を経て、コンサルタントや部門責任者(ライン職・人材管理)になるキャリアプランが一般的だったと思います。

    しかし、近年の変化の速いビジネス環境や開発スピードに合わせて、エンジニアのキャリアモデルも大幅に変化してきています。開発から一歩引いて設計やプロジェクトマネジメントのみを行うロールは減りつつあり、代わりに以下のようなロールが現れました。

    • 技術をリードする「テックリード」
    • チーム開発の仕組みやマインドを改善する「SM(スクラムマスター)」
    • 開発組織をより良い方向に向ける「EM(エンジニアリングマネージャー)」
    • プロダクトの戦略や開発優先順を考える「PdM(プロダクトマネージャー)、もしくはPO(プロダクトオーナー)」

    スクラムマスターは大変やりがいのある仕事で、今後もチームの成長に寄与し続けたいと思っているスクラムマスターが多いと思います。

    その一方で、「限られたスクラムマスターの席に自分が座り続けているのは良くない・しかし自分はどこへ向かえばよいのだろうか。。。」という悩み・葛藤を抱えている人もまた多いのではないでしょうか。

    このセッションでは、PG→SE→PjM→SMというあるあるなキャリアモデルを辿っていた私が、上記のような悩みや葛藤を抱えつつも今後のキャリアプランをどのように整理し、SMの次に来るキャリアを決めたのかをご紹介します。

    スクラムマスターのキャリアプランに唯一の正解は無いと思っていますが、同じ悩みを持っている人のヒントになるセッションにしたいと思います。

  • Added to My Schedule
    keyboard_arrow_down
    Ryo Tanaka

    Ryo Tanaka / Takao Utsumi - インプロヴィゼーション:ふりかえりの新世界

    schedule  02:00 - 02:45 PM JST place 1F Room C (72) people 39 Interested star_halfRate

    ※ インプロヴィゼーション(improvisation) = インプロ、または即興演劇

     

    私はアジャイルコーチとして数々の現場・チームを見ていく中で、ふりかえりに対してマンネリ感を覚えるようになりました。

    スクラムにおけるレトロスペクティブをはじめ、ふりかえりの時間は確保されるようになってきたと感じる一方、多くのふりかえりでは次に向けたアクションアイテムが近視眼的なものになり、長期的な行動変容を中々起こすことができていないように感じました。

    そんな時、インプロに出会い、インプロバイザーの方々と話をする機会が訪れました。そして、インプロがもたらす、行動変容に対する強力な刺激・数々のプラクティスが生み出す高い熱量に触れ、大きな驚きと感動を覚えました。
    そして、インプロの実践やアジャイルのコラボレーションを重ねていく中で、これまで感じていた頭打ち感を振り払うようなふりかえりが生まれていきました。

    一方、インプロを実践するインプロバイザーも、アジャイルやシステム・シンキングの考え方に感動を覚えていました。インプロにおけるふりかえりにアジャイルやシステム・シンキングの考え方を取り入れ、インプロにも変化が生まれていきました。

    本セッションでは、アジャイルとインプロのコラボレーションの様子を実際に見ていただき、コラボレーションの結果生まれた誰もが予想したことのないようなふりかえりの話を紹介したいと思います。

     

    インプロバイザー:内海隆雄より

    「計画に従うことよりも変化への対応を」――アジャイルの考え方に出会って僕が思ったのは「これはインプロのことか!」でした。インプロは即興を意味するImprovisationの略です。そしてImprovisationの語源はIm(しない)+pro(前もって)+visation(見ること)すなわち「前もって見ることをしない」ことを意味します。

    先の分からない世界でいかに振る舞うかについて、インプロは愉快に教えてくれます。このセッションではその一端と、アジャイルやシステム・シンキングとの出会いによる変化についてもお話できればと思います。

    ----

    このプロポーザルは aki.m さん協力のもと作成されました。ありがとう!

  • schedule  02:00 - 02:20 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 6 Interested star_halfRate

    僕たち株式会社アンチパターンは「日本のソフトウェアエンジニアを憧れの職業へ」という理念を掲げ様々なサービスを提供しています。

    そんな中、これからソフトウェアでビジネスを起こそうとしている企業や、これからソフトウェア開発にチャレンジするエンジニアの学生などと接触する機会が多くなってきました。

    僕は2014年にエンジニアになり、2016年頃からスクラムに触れており、知識はそれなりに有しているつもりで、アジャイルやスクラムを説明することにも慣れていると思っていました。

    しかし、最近、何かモヤモヤする。

    それは僕らが対峙する人たちが「ウォーターフォール」を知らないからでした。

    僕の説明コンテンツは過去の流れから説明しているが、それは本当にいいのか?

    本セッションでは「スクラムをウォーターフォールとの比較ではなく説明しようとする」ことによって改めてスクラムと向き合ってみる、というものです。

14:25
  • Added to My Schedule
    keyboard_arrow_down
    aki matsuno

    aki matsuno - (スクラムやアジャイルを)よく学びよく試行錯誤する~継続して学び現場に持ち帰るために~

    schedule  02:25 - 02:45 PM JST place 2F Main Hall EAST奥 (90) people 55 Interested star_halfRate

    スクラムの実践を通して叶えたい未来を実現することは、場合によっては途方もない道のりに思えるかもしれません。
    特に、経験がなくて支援者や経験者が少ない状態でスクラムを学ぶというのは、中々ハードルが高いのかもしれないと個人的には思っています。

    自分の場合は、プロダクトやチームをより良い方向に進めたいという想いからスクラムを始めましたが、何も分からない状態で闇雲に学び始めたこともあり、多数の悩みにぶち当たることになりました。(本に書いてあることがなかなか実践できない、自分のやりたいことを強引に押し付けをしているだけな気がする、コミュニティやカンファレンスに参加するもどこか遠い世界のように感じられて今一つ学びがない気がする...)

    そんな中、今の自分にできることを探し、500回近くのコミュニティに参加したり、400本近い本数のセッションをカンファレンスで聴いたり、読書をしたりして少しずつ学び、学んだことを現場や自身の日常で実践し、社内外問わず多数の皆さんに支えてもらいながら日々試行錯誤をしていきました。

    そうして少しずつ歩みを進めてきた結果、チームの空気やデリバリーまでのプロセス、顧客との関係性...が確実に変化していきました。
    また、自分自身少し不思議な感じがしますが、自分が大事にしたかったものが徐々に思い出されるような感覚を持つようになりました。

    本セッションでは、自分がスクラム/アジャイルを中心に1年間学びを加速し続けられたのはなぜか、コミュニティやカンファレンスといった学びの場をどのような過程を経て現場に適用していったのか、といった話をすることで、現場をより良くしていくために試行錯誤している方々に向けた話をしようと思います。

    スクラムを実践して良いプロダクトを届けよう、現場を改善しよう...簡単な道のりではないことが分かりつつも、新しいことにチャレンジしている(あるいはチャレンジしようとしている)素敵な皆さんを少しでも後押ししたり、小さな変化が起こるきっかけになるようなセッションにしたいと思います。

  • Added to My Schedule
    keyboard_arrow_down
    Taiga Hisamune

    Taiga Hisamune / Yusuke Amano - リーダーがいない混沌としたチームをなんとかしたくて3年間取り組んだ話

    schedule  02:25 - 02:45 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 17 Interested star_halfRate
    本セッションはサイボウズのスポンサーセッションです。

     

    サイボウズでは「チームワークあふれる社会を創る」というミッションのもと、
    kintone/Garoon/Officeといったグループウェアプロダクトの開発や、チームワークメソッドの開発・普及を事業としておこなっています。

     

    開発本部コネクト支援チームはエンジニア文化を大切にした長期的な関係性づくりを行うチームです。
    社内の技術情報発信の支援やイベント/コミュニティ活動の支援などを行っています。

     

    私が所属していたコネクト支援チームが機能していくまでの道のりを、フェーズ毎に簡単に紹介しながら、私とコーチで振り返りたいと思います。

     

    サイボウズの中の一つのチームが機能するまでの取り組みの一例に興味がある方はぜひご参加ください。
14:45

    Tea Time - 30 mins

15:15
  • Added to My Schedule
    keyboard_arrow_down
    Saiko Nakai

    Saiko Nakai - LeSS もスクラム。プロダクトオーナーがスクラムマスターとともに取り組んだ LeSS チームの合体から融合まで

    schedule  03:15 - 04:00 PM JST place 2F Main Hall WEST手前 (90) people 60 Interested star_halfRate

    ヤフーにはたくさんの社内プラットフォームがあります。
    私もそのうちの1つを担当していましたが、そのプロダクトはある別のプロダクトの後継となることが決まっていました。

    後継であるということは、旧プロダクトで求められていたことを新プロダクトでも求められますし、逆に旧プロダクトでの課題が新プロダクトで解決されていることも望まれています。この期待に応えられるプロダクト開発をおこなうため、新旧プロダクトを担当していた2つのチームは、戦略として1つのLeSSチームで2つのプロダクトを担当することを選択しました。

     

    新プロダクトを作りはじめたチームと、旧プロダクトを運用しているチームは、それぞれにスクラムをおこなっていましたが、その雰囲気は対照的でした。

    • 一方は、かろうじてスクラムの枠組みには沿っているが、完成の定義なども決める前段階の緩くインクリメンタルな開発を行おうとするチーム
    • もう一方は、3チームによる LeSS をおこない、プロダクトを安定運用するための様々なルールに沿って開発運用を行うチーム


    2つの異なるスクラムチームが一つになることは、簡単ではありませんでした。
    特にそれぞれが対照的な雰囲気のチームだったことや、それぞれが今までと変わらずなプロダクト運用も求められる中でのチームの合体だったため、課題も多かったからです。

    いざ一緒になることが決まり、プロダクトオーナーになることが決まった私は、旧プロダクトの LeSS を見て複数の違和感を持ちました。

    • ルールに縛られた軍隊チックなチーム体制
    • プロダクトについての議論がされ、ルールばかりが追加される振り返り
    • 誰に何を届けたいのかがわからないスプリントレビュー
    • プロダクトオーナー以外、誰も優先順を認識していないバックログ
    • 判断がプロダクトオーナーに一任されるコミュニケーション

    一方で新プロダクトのチームには別の課題がありました。

    • 全員がスクラム経験者ではあるものの、人数が増えて LeSS をおこなうことへの漠然とした抵抗感
    • 完成の定義などの決めごとがほとんどなく、チームの変化に弱いプロダクト品質
    • チームの人数が少ないことで担保されていた共通認識や前提知識が成り立たなくなる課題

     

    私自身にとっても LeSS ははじめてだったため、旧プロダクトの現状を見て単純に LeSS についての知識が足りていないから違和感を持つのではないか?と思ったり、新プロダクトのメンバー同様に漠然とした不安をもったりしていましたが、その違和感や課題、不安を整理していくと、そこに見えてきたのは「スクラム」でした。

     

    LeSS も スクラム である。

     

    「スクラム」であるならばと、スクラムマスターとの会話を重ね、それぞれのチームが元々抱えていた課題や目指したいスクラム像のすり合わせをおこないながら、1年半かけてチームに対してアプローチをおこなってきました。

    まだまだ荒削りで道半ばではありますが、双方のチームが壁を感じながら合体しただけの状態から、1つのスクラムチームとして融合し次のステップに進めるようになるまでの LeSS の歩みを、実際におこなったアプローチや私自身が感じたこととともに紹介します。

     

    「うちも LeSS やっているけれど、なかなかうまくいかなくて・・・」
    「LeSS って人数も多いし、なんだか難しくて大変><」
    「同じ LeSS チームなのに、チーム内で対立構造ができてしまって困っている」

    などの悩みを抱える方にとって、それぞれのチームが抱える課題は違っていても、よくしていくための一歩を踏み出せるきっかけになれば、と思っています。

  • Added to My Schedule
    keyboard_arrow_down
    Kotoe Ishige

    Kotoe Ishige - マネージャーが、スクラムチームとともに良い未来をつくるためにできること

    schedule  03:15 - 03:35 PM JST place 2F Main Hall EAST奥 (90) people 46 Interested star_halfRate

    私は、株式会社アカツキでエンジニアリングマネージャーをしています。

    アカツキのとあるゲーム事業では、大規模スクラムLeSSを導入しており、導入から現時点で9ヶ月ほど、RSGT2022が開催される頃には1年になります。

    エンジニアリングマネージャーとして、導入までと導入直後はチームと直接的な関わりが多かったのですが

    現在開発チームは3チームあり、SMも3名おり、チームが自分たちの力で成長していくのを少し遠くから見守りながら、

    よりスクラムチームが良い感じになれるよう、マネージャーとしてできることを陰ながらサポートする役割に変化していきました。

     

    当セッションでは、マネージャーがスクラムチームにどのように関わることで、より良いチームになっていけるのか、自分なりの経験や考えをお話できればと思います。

  • schedule  03:15 - 03:35 PM JST place 1F Room B (48) people 12 Interested star_halfRate

    Agile transformation is gaining momentum more than ever as the world is geared up towards embracing the digital world. It’s a great opportunity for agile practitioners to help their organisations with transformation initiatives.

    You have been selected to lead the transformation initiatives. It’s good news but at the same time, you will be anxious with so many questions.  How do I get started with it? Being in the organisation for so long, knowing the pros and cons of my management, how can I manage their expectations? How can I get my supporters and detractors to align with the goal?

    The above questions are the tip of the iceberg and there will be a lot more along the way. Having led several transformations, I will share my both good and bad experiences in leading agile transformation both objectively and humanistically.

  • Added to My Schedule
    keyboard_arrow_down
    izumi ito

    izumi ito / Atsushi Suzuki / Kohei Shoda / Noriyuki Nemoto - アジャイル札幌のひみつ

    schedule  03:15 - 03:35 PM JST place 1F Room C (72) people 14 Interested star_halfRate

    みなさんこんにちは、寒い北の大地のアツいコミュニティ「アジャイル札幌」です!
    実はアジャイル札幌は2021/6月で結成10周年を迎えました。
    この良きタイミングで10年を思い起こしてみましたがふりかえってみていろんなことがあったなぁと思います。

    初代代表スズキの海外勤務、現代表nemorineの仙台転勤をはじめ会社の事情によるメンバーの不在期間や、会社や家族との関わりが変わる中で思うように活動できなかったりした時期もありましたが、そんな脆い時期を新しいメンバー達が支えてくれたおかげで形を変えながら今日まで継続してくることができました。

    初期メンバーがコミュニティを立ち上げ、
    Joinしてくれたメンバーがバトンをつなぎ、
    アジャイル札幌の雰囲気が大好きといって共に盛り上げてくださる参加者のみなさんがいて、
    今のアジャイル札幌があります。

    そこで感謝の気持を込めて、「アジャイル札幌のひみつ」というタイトルでアジャイル札幌のメンバーが10年をふりかえりつつコミュニティ運営に対するそれぞれの想いと大切にしていることをパネルディスカッション形式で語ります。

    今回はお菓子ではない”北海道ギフト”を、アジャイル札幌からお届けします。
    今コミュニティを運営している人達のヒントや、コミュニティを立ち上げようとしている人を後押しできるような時間となれば幸いです。

    当日は初代代表スズキアツシがアメリカのテキサスから海を越えて参加します!

    (なお、タイトルはアジャイル札幌立ち上げメンバーの1人である島田浩二さんが共著者の『ユニコーン企業のひみつ』のオマージュです)

  • Added to My Schedule
    keyboard_arrow_down
    Muneyuki Okamoto

    Muneyuki Okamoto / KazuhideInano / Makoto Takaesu - ほっともっと・やよい軒の会社で始まるアジャイルジャーニー

    schedule  03:15 - 03:35 PM JST place [Sponsor sessions] 2F Terrace Room (18) people 11 Interested star_halfRate

    「はじめに消費者ありき」の創業精神を掲げ、国内外で3,000店舗を超える飲食店を運営する株式会社プレナス。

    そのプレナスで2021年より新しい体制で始動したDX本部。

    DX本部が自社のコーポレートトランスフォーメーション(CX)を実現し、消費者により良い商品とサービスを届けるためにも、従来の物事の進め方やテクノロジーの利活用の仕方などに様々な課題を抱えていました。

    まずはDX本部のメンバー全員のチームビルディングを兼ねたフェニックスプロジェクトシミュレーション研修、そして共通言語を獲得し同じ目線で目標に向かって進んでいくためにアジャイル/スクラムの基礎を学びました。

    スピーカーに今回の取り組みの推進役である株式会社プレナス DX本部 の漆さんを迎え、DX本部が仕掛けるコーポレートトランスフォーメーションの軌跡の序章を人材育成という切り口で語ります。

    また、今回の人材育成フェーズに講師という立場で関わったITプレナーズ認定講師である稲野さん・高江洲さんらを迎え、研修の取り組みやこれからの展望についてもディスカッションいたします。

15:40
  • schedule  03:40 - 04:00 PM JST place 2F Main Hall EAST奥 (90) people 48 Interested star_halfRate

    「アジャイルとデザインは絶対にうまくいかない。」アジャイルに関するなスタートアップに入社する前、私はこう考えていました。それまでのエージェンシーやプロダクトデザインの経験とは全く異なるものだったからです。

    yamanecoで働いた3年間で、革新的なアイデアを実現するためには、デザインにとってアジャイルの助けは必要だと学びました。アジャイルもまた、ビジネス上の必要性に留まらず、ユーザーのニーズに合った製品を作るためにデザインの助けがいることを学びました。私の成功、失敗、そして学びを皆さんと共有したいと思います。

    “Agile and design will never get along.” This is what I thought before I joined an agile startup, completely outside of my previous agency and product design experience. In the three years working at yamaneco, I have learned that design needs help from agile to make innovative ideas real and agile needs help from design to make products that fit a user need, not only a business want. Let me share my successes, failures and learnings with you.