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

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

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

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

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

2012年、新たな著作のタイトルが "The Battle" だと知った時、すごくがっかりしたのを覚えています。あれだけ分割しても理解できないと主張していたのに、システムA、システムBにように分断するのかと。

それから10年がたち、パタンランゲージとしてのスクラムも世に出すことができたところで、スクラム・アジャイルにとっての The Battle とは、何だったのか、何なのかを考えてみたくなりました。

Agile Manifesto が発表されてから、アジャイル・スクラムはずっと対立軸の片側として語られてきました。アジャイル開発が一般的に使われるようになり、スクラムが最も利用されるフレームワークとなったとき、The Battle は終わったのでしょうか？それとも、まだ別のシステムが存在するのでしょうか？

ここまでの状況をふりかえりながら、現在のアジャイル・スクラムの場所を確かめてみようとおもいます。

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

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

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

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

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

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

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

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

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

----

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

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

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.

プロダクトには価値はあり、だからこそ顧客は利用している。しかし同時に副作用も生んでいる。

 「最高のプロダクトを作ろう」とはじめたのに、いつのまにか「最高の利益を上げよう」という会社になっていた。顧客の悩みに寄り添っていた私たちが、今では顧客のサイフばかり気にしている。

最高のプロダクトを目指していたのにブルシットプロダクトになっちゃった!

この10年でUXデザインや、ユーザーストーリーマッピング、デザイン思考といった顧客理解の知識や技術が普及してきました。しかし、顧客を助けるふりをして、巧みにつけ込むようにみえるプロダクトはたくさんあります。

　パッケージや広告だとプロダクトはめちゃくちゃステキ。ところは実物が届いたらひどいものだった。コレジャナイ感がすごい。

　サービス加入は簡単なのに退会は困難を極める。入会はwebフォームから簡単にできるのに、退会するには迷路。くぐり抜けてやっと退会できるかと思ったら、電話をするほかなく、電話はいつかけても混雑中で先に進まない…。

　サービス契約前は大量の広告や案内が届くのに、サブスクリプション契約したら一切届かなくなり、契約自体を忘れてしまった。気づいたらお金は払い続けているのに全く利用せずに数年たっていた。

これらはあからさまなものです。しかし、ユーザーの立場でみてみると、プロダクトを利用する中で違和感を覚える場面はあふれています。スマホにアプリをダウンロードし、いくつかの入力を済ませ、いざ利用開始というタイミングで利用規約にサインをさせる…そんな不意打ちです。ユーザーの頭の中ではすでにサービスを利用している気になっているので、複雑な規約に向き合える気持ちにはなれないでしょう。

「顧客が本当に必要だったもの」の継続は難しい

　はじめは顧客に寄り添って「顧客が本当に必要なもの」を届けられていたのに、長く開発しているうちに寄り添わないことが起きはじめた。「顧客の○○さん」というように一人ひとり名前が付いていた顧客が、1人2人と単なる数字で管理するようになり、顧客の声が遠くなった。昔はクレームが届けば顧客の意見をヒアリングしにいったのに、今では一律定型文を返すようになっていた。いつのまにか黙らせることがうまくなっていた。

　プロダクトが顧客に受け入れられるにつれて売上は伸び、企業規模は大きくなる。規模が大きくなるにつれて、資金に余裕ができ、才能が集まりやすくなる。本当なら素晴らしいことがもっと成し遂げられるようになるはず。にもかかわらず、以前と比べて価値を生み出せなくなったように感じる。

素晴らしいプロダクトを生み出すのは難しいことですが、素晴らしさを続けていくことはもっと困難です。業務を効率化したり、企業の大規模化にともなって、「顧客が本当に必要だったもの」を生み出す力は少しずつ阻害されていきます。

あるプロダクトの急成長物語

顧客を助けようとする情熱からプロダクトが始まったとしましょう。顧客とヒアリングしたり、開発を続ける中で、チームは豊かな体験をします。プロダクトがリリースされ、顧客に「これが欲しかったんだ!」と熱烈に歓迎され、顧客が殺到します。プロダクトがヒットしたのです。

すると、増えた顧客から顧客対応や新たな要望がどしどしよせられるようになります。チームはてんてこ舞いです。また手強い競合が参入し、競争が激化します。圧倒的な人手不足から採用に取り組み始めますが、これまでのチームの仕事は属人化し、またそれまでの経験がなければ分からなくなっていました。

ぐちゃぐちゃな仕事を整理して、分割して、分かりやすくします。新しく入ってきた人でも即戦力になれるようにするためです。手分けして仕事に当たれるようになりました。このようにして混乱した状況に秩序をもたらし、急成長の痛みを乗り越えたのです。

 「この仕事は何のためにあるのか分からないが、やることになっている」

即戦力でも活躍できるように、手分けができるように整理されてコンパクトになった仕事とはいったいどのようなものでしょう。プロダクトのほんの僅かな部分しか担当していないため、プロダクト全体のことはわかりません。プロダクトオーナーは何をしているのか、営業は顧客から何を言われているのか、広報はどのような狙いを持っているのか、おぼろげにしか見えません。これを細い経験と呼びましょう。

一方で、プロダクトを成長させたプロダクトオーナーやチームは、その貴重な経験を活かせるように、さらに重要な仕事に携わるようになります。これを太い経験と呼びましょう。

経験という側面から考えてみます。組織には、分担された仕事による細切れの経験の大勢の人と、稀少な経験を重ねるごく僅かな太い経験の人という分布の偏りが生じるということです。貴重な太い経験をもつ人は、売れっ子の新人女優のように次々と新たな役に恵まれて、さらに豊かな経験をします。細い経験の人はそうではありません。

さらにプロダクトは急成長したとしましょう。一度手分けされた仕事はさらに分けられ、もはや元々がどのような仕事だったのか分からない人もたくさんでてきます。どんどん細分化が進み、部門は管理しやすいように縦割りが進んでいきます。業務効率化が促されるようになり、サポートでは手早く顧客の問題を解決したことにするため定型文を返すようになる…かもしれません。

 「いざ改革」に乗り出すも…

このような状況で、危機を覚えた初期の優秀なチームは、顧客の声が遠くなったことや縦割りが進んでいることを理解しています。そこで部門を横串する「ユーザー中心チーム」や「○○経営組織」が発足し、改革を担うようになります。

さて、もう一度、体験の分布を考えてみましょう。僅かな太い体験と、大量の細い体験の二つがありました。「ユーザー中心チーム」や「○○経営組織」という改革の取組はどのような影響を与えるでしょう。是正するでしょうか、それとも強化してしまうでしょうか。

「顧客が本当に必要なもの」を追求しつづける

ユーザーから見て、ただひどいだけでなく、開発したり販売する人たち自身がプロダクトに価値がないと感じており、また買ってもらうことに罪悪感を感じるようなプロダクトやサービスをブルシットプロダクトと呼びましょう。

このセッションでは、ブルシットプロダクトとは何か、どのようにして生まれるのか、なにをすれば解消されるのか、顧客が「顧客が本当に必要だったもの」を実現しつづけるプロダクト組織に向けて、組織システムの成長の観点からお話しします。

目次
ブルシットプロダクトとは何か
・ブルシットプロダクト
・顧客につけ込むダークパターン

組織システムは何に自己組織化しようとしているのか
・分業の功罪
・太い経験と細い経験
・負の自己組織化
・官僚主義や大企業病は自己組織化の双子
・ブルシットプロダクトマネジメント
・負をマネジメントする

顧客を助けるプロダクト組織へ
・顧客を助ける
・顧客の能力を高める
・無知/無能/無関心から、知ってる/できる/当事者意識へ

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

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

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

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

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

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

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

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

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

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

お題と回答の例その2
お題「私はスクラムマスターです。ステークホルダーと期日の約束をしてしまったチームがいます。チームが期日を守れなさそうなんですがどうしたらいいでしょうか」参考
回答1「そもそも期日を決めてよかったんでしょうか？」参考
回答2「期日を約束するの？ 予測される数字であり、ずれるリスク込みで扱うもので、そのリスクはチームが負うものではないのでは」参考
回答3「POどこいったの？」参考

回答者には、安井力（yattom）さん、大谷和紀（katzchang）さんを迎えます！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

English follows Japanese.

私は2013年から、自社サービスを展開する事業会社で、社内アジャイルコーチとして活動してきました。

チームビルディングから、開発生産性向上のための（テスト自動化・DevOpsなどの）技術支援、新規プロダクトの共創、さらには経営層を巻き込んだ組織改革と、活動範囲は多岐に渡りました。そして、多くの失敗と、いくつかの成功とを重ねてきました。

この度、社内アジャイルコーチを辞めるにあたり、改めてこれまでの活動結果およびそれらの自分なりの分析結果とを整理し、社内／外のアジャイルコーチ、および同世代／次代のアジャイル実践者へ提供することが、自分を育ててくれたアジャイルコミュニティへの貢献になるのでは？との考えに至りました。

そこで当セッションでは、特に事業会社の社内アジャイルコーチというコンテキストで、自身が悩み、試し、伝える価値があると判断したものを、特にチーム・技術・組織の3点から整理してお話しします。

I had worked as an internal Agile Coach in several internet service companies since 2013.

I had done a wide variety of activities such as team building, implementing technical foundations for enhancing developer productivity, founding totally new products, and leading organizational changes with the management. There were lots of failures, and some successes.

I convince that sharing ideas and knowledge earned through the experience of those my internal Agile coaching activities will contribute to the Agile community.

In this session, I will talk ideas and knowledge earned through my internal Agile coaching activities from 3 aspects like 1) team, 2) technology, and 3) organization.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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を開発する際にケント・ベックがスクラムのプラクティスを「盗んだ」というユーモラスな噂を確認している。

Agile seems to be a good approach while delivering your projects and in order to making your organization lean. However, this approach could go wrong if Agile is just the buzzword for your organization transformation and if the change in work culture is not accepted sincerely.

With companies wanting to be Agile and not adhering to its values and principles, Cargo Cult Agile is what we experience.

In this presentation, I shall run you through the common pitfalls that organizations fall into while undergoing Agile transformation, sharing you my own experiences and stories so far.

Why it doesn't go well?

　私たちは、いつも失敗を経験しています。ベストプラクティスを探しても、あるいはすでにCritical Thinkingを活用するなど色々な努力を重ねていても、失敗を目撃することが多々あります。何が問題なのでしょうか。

私たちは何かを判断するとき、自分の論理ベースを作ります。私は、恐らくその時使用する物事のモデリングに、いくつかのインプットが足りてないことが原因だと考えています。Critical Thinkingという概念を理解していても、活用方法が十分身についていなければ、私たちはまた失敗につながるミスを犯してしまうでしょう。

Hello OODA

　ここで適切なCritical Thinkingのためのフレームワークとして、OODAが登場します。

OODAは第二次世界大戦の空中戦で数多くの勝利を遂げたJohn Boyd氏によって初めて語られたフィードバックのループです。RSGT2021で野中先生のキーノートでも言及され、日本のアジャイルフィールドで新たに注目を得ています。

Critical Thinking based on OODA

　OODAは、観察・判断・決断・行動の4つのステップからなっていますが、言葉そのものの意味を理解することに留まらず、より具体的にどのように実践するかを考えなければなりません。各段階のキーポイント・キークエスチョンをきちんと理解した上で新しく論理ベースを作ってからこそ、より精度の高いCritical Thinkingが可能になります。

Happy 2022 with Better Critical Thinking

　RSGT2020, 2021に続くシリーズとなるこの45分間のセッションで、皆さんの新しい1年間がより明るくなるような道筋を案内します。

The agile software approach is becoming a de facto way of software development.  Agile Principle #10 states, “Continuous attention to technical excellence and good design enhances agility”. 
In the fast-changing technology landscape, What Continuous attention are we providing to technical excellence and good design? How is that resulting in agility?

Some of the key concepts that are already in practice are
•    Loosely coupled components to help improve adapting to change
•    Automate steps that might slow down in build & deployment process through CI/CD
•    Improve agility through inverted design leveraging Test-Driven Development
•    Improving development efficiency and quality through Pair Programming

What other problem statement that we face in today’s environment is hindering agility and what more can we do to help improve engineering agility? 

•    Is there something we can do to improve flexibility in system collaboration, especially on API development?
•    How can we improve agility to bring data together faster and help data scientists to analyse the decision-making models faster?
•     How can we bring agility in environments preparation and infrastructure provisioning?
•    Changes to user interfaces are quite common and anything to be done on improving agility?

We will discuss the possible problems impacting agility in two of the key areas API development and Data Science. 
Also, will be discussing some of the ways and means to address these problems from real-world examples.

あなたの現場では、こんなことがおきていませんか？

「ペアプロを導入したいけど、上司が…」
「Daily Scrumで何も話題が出てこない…」
「本やブログで書いてあったやり方をやってみたけど…」

同じような問題でも、現場によって有効な解決策やアプローチは違ってきます。
簡単にいうと銀の弾丸はありません。

そこで！

実際に皆さんの現場で起きている問題や悩みを出してもらい、とにかく前向きな6名が通用するかどうか分からない鉛玉を大量に提供したいと思います！

色んな現場で実際に試して
失敗したアイデア、成功したアイデア、
社内のチェンジエージェントの観点、社外のアジャイルコーチの観点、
あの現場での話、この現場での話…
数ある鉛玉から自分の現場に合いそうな輝く弾丸を持ち帰ってください。

例えばスクラムフェス三河2021ではこんな質問が！

Q 会議が多くて腰が死にそうなのですが、どうすればいいですか？

• 会議を強制的に30分で終了させましょう！
• 良い椅子を買いましょう！
• ふりかえりで「最近腰痛いんだよね〜」と話してみましょう！

Q アジャイル開発チーム×30チームのマネジメントって何をやるべきですか？計測して評価とか標準化とかやりすぎてもチームの自律を損ねる気がしてます。

• 「最低限ここだけ！」というところだけは決めて、チーム横断で良い取り組み・失敗をシェアし合える時間を設けてみましょう！
• スクラムマスターのコミュニティを作ってみましょう！
• 何を管理したいかを確認して、あとは権限移譲をしてみては？

Q スクラムイベントを形だけまねるようなゾンビスクラムに直面したときにどういったアクションをとりますか？

• 直接ユーザーと話をしましょう！それが難しければ、CSや営業などの人ともっと一緒に話をしてみましょう！
• スクラムガイドをみんなで読んでみて、スクラムに対する解像度を上げてみては？
• スクラムを一旦やめてみてもいいかも！
• 形だけでもできてるならいいんじゃない？

セッション中は

みなさんも無責任に「自分だったらこうするかなぁ」「こんなことしたら上手くいったよ！」という鉛玉をじゃんじゃん放流してくださいね！

みんなでわいわいしましょー。

プロダクトオーナーの仕事は意思決定であると言っても過言ではないかもしれません。
しかし、その意思決定についての体系的な知識や方法論については注目度が低いように感じています。
より良い意思決定ができるのであれば、より良い価値をユーザに届けることもできるのではないでしょうか？

本セッションでは、そんな意思決定の方法論、特に「ディシジョンマネジメント」をプロダクトオーナー支援に活用した事例をご紹介します。

案件選定やプロダクトの戦略を考える際にはもちろん、プロジェクトのリスクの洗い出しにも、開発プロセスにだって意思決定は必要です。
意思決定とは何か、その意思決定という武器をどう現場で使うのかをお伝えできればと思います。