幡ヶ谷亭直吉ブログ

娘のここねと格闘するエンジニア。

Scrum Guide Expansion Pack 日本語訳 披露宴に参加しました

イベントの概要

2020年版スクラムガイドの包括的な副読本として作成された「スクラムガイド拡張パック」の日本語版が完成しました! https://scrumexpansion.org/ja/

現代の複雑なプロダクト環境において、スクラムの核となる原則をより深く理解し、実践するための戦略的な補足として位置づけられるこの資料について、訳者陣から直接詳しくご紹介します。

新しい知識をコミュニティで共有し、一緒に学びを深める披露宴を開催いたします。

現地参加の方には先着順で、この会場でしか手に入らない紙印刷版をプレゼントします。数に限りがありますので、手に入らないこともあります。あらかじめご容赦ください。

引用:

easg.connpass.com

イベント参加の背景

  • ExpansionPackについて人伝えのサマリだけしか知らず学ぶ必要性を感じていた。
  • スクラムに対する自身の見え方が変わってきた中、新しく求められる内容を知りたい。
  • 日本語翻訳を待ち望んでいたため現地参加!!

訳者陣による解説

メモ

スクラムガイド拡張パック
日本語でのダウンロードも可能。

scrumexpansion.org


・作成背景と目的
大きな2つの要因。
・フィーチャーファクトリー化:プロダクト領域の細分化による検査・適応の課題
・AI時代の新たな働き方

翻訳においては偏らず多くのコミュニティに届くように推進した。

・支援・補完している理論
複雑性、創発が章として新設された。
複雑性。
既知は間違っている可能性がある。未知は現れたり薄れたり重要性も変化する。
複雑性をクネビンフレームワークの4象限で説明。
不明を明瞭にしていくだけでなく、複雑さも交えて捉える。
複雑さに対し、スクラムアジャイルを活用し、創発を生む。

創発
複雑なシステムの相互作用から意味のあるパターンや行動が生じる。
拡張パックでは、創発を生むための戦略にも言及されている。
より優れたプロダクト開発のために創発を活用していく。

自己管理スクラムチーム。
創造的な問題解決と創発のために不可欠。
マネージャーが管理するのではなく、自己管理する。

プロフェッショナル。
常にやること、絶対にやらないことを持ち、説明責任を持つ。
技術的卓越性は必須。

・リーン思考
トヨタ生産方式
人々の敬意のうえにリーン原則は築かれている。
人の創造性を引き出すことや、働きやすさにフォーカスしている。
エンゲージメントをもとにしたチームワークを重視している。

経験主義。
実験から学びを得て次につなげる。フィードバックループ
要求はプロジェクト中で65%変わる。検査・適応が重要。
ステークホルダとチームの距離を検査・適応によって縮めることが重要。

ケイデンス
定点観測により改善をする。

透明性・検査・適応。
透明性を高め、360度から情報を吸収する。
結果からのフィードバックは定量・定性であるべき。
それが創発を生み、学習や副作用をもたらす。

スクラムの5つの価値基準。
集中、公開、確約、勇気、尊敬。
学習と効果的なチームワークに重要。

・さらなる支援/補完理論
プロダクト思考。
人が使うのはプロジェクトではなくプロダクト。
プロジェクト:期限のある取り組み
プロダクト:短期的な成果 * 長期的な視点
短期偏重による副作用には気をつける。
短期に重みをもちすぎると技術的負債や士気低下、アウトプット偏重を招く。

www.servantworks.co.jp


システム思考。
予測不能非線形なコンテキストに対する多角的な視点の重要性。
結果に基づくデータから学ぶ。前作業は次作業に作用するかを考える。
カンバンは価値とフローを最適化する。

kanbanguides.org


ディスカバリー
プロダクトを作る上での観察・探索。
スクラムとアラインしていくためにやるべきことがある。
結果からのフィードバックを重視する。ディスカバリーに偏重し過ぎない。
真実曲線を参考にする。

リーダーシップ。
隣の誰かに任せるのではなく、全員がリーダーシップを発揮できる状況を作ることが重要。
各人にどのようなリーダーシップを発揮して欲しいのかを考え、開示し、フィードバックする。
触媒的リーダーシップを獲得するために、リーダーシップのステージを刻む。

・第一原理思考
ファースト・プリンシプル。課題を根本的な真実に分解する。

人と変化。
フィーチャーファクトリーのように、第一原理思考になりきれていないチームがある。
スクラム適用の難しさを過小評価しない。
スクラムは問題を明らかにし、人が解決するためのフレームワーク

学び

それぞれの翻訳者の方たちが扱うテーマから、改めてスクラムで実現する価値に対する魅力を感じました。
特にプロダクト志向の文脈は、自分の主な関心事にもなっているため、スクラムでどのように実現していくかについて興味深くなりました。
トヨタ生産方式』は吉羽さんがご紹介されていたのを聞いて以来積んでしまっているので、改めて読まねばと意識しました。

参加型学習

学習テーブル:ジグソー法で深く理解

ni-coref.or.jp

エキスパート活動

私の座ったテーブルでは拡張パックにおけるスクラムの役割について読み合わせをしました。
基本的には以下がメインの関心事となりました。

  • AI登場
  • ステークホルダー、サポーターなど開発外の人間が登場
  • 開発者がプロダクト開発者に
  • 各役割が人であるべきかの注記
  • 各役割に求められる具体的な行動に対する言及
  • Ken Schwaberの不在

開発外の人間の登場からはフィーチャー・ファクトリーに偏らないための関心が詰め込まれたのではと気付きました。
また、今まで抽象的なガイドだったことにより、具体的な方法がそれぞれ適用したチームの置かれたコンテキストに依存することで、フィーチャー・ファクトリーに陥りがちだったところを、具体的な行動指針を示すことで軌道修正を図ろうとしたのかとも思えました。

ジグソー活動

スクラム活動、スクラムイベントの内容について共有頂きました。

  • スクラム活動
    その場その場で求められる要求に対応ができる集中力が重要。
    プロダクトゴール、スプリントゴールに対する確約。
    受け入れ基準は柔軟に調整すべき。
  • スクラムイベント
    今までと目立った差分はなく常に集中が求められる。

異なるテーブルでスクラムの役割について話した方からはスポンサーというひとつの領域に詰め込まれたものに対する苦言が興味深かったです。
また、一番印象的だったのは全体的にディスカバリーについて書かれている内容が弱いという言及でした。
創発などがテーマとしてあがりつつも、デリバリーに偏重しているといった意見からの学びが多かったです。

クロストーク

元のテーブルに戻り、それぞれのテーブルでの内容の共有をしました。
印象的だったのは以下の点でした。

  • 集中に対する言及の多さ
  • プロダクトゴール、スプリントゴールと確約について
  • スプリントとイベントとして扱われていること
  • リファインメントがアクティビティで登場
  • 各所に登場するtodoの多さ

個人的には、スクラムは言われた通りにやっても本質的な効果を得られないからこそ難しいと思っているため、拡張パックは実務での迷いを減らすHOWを増やしている。
一方で私は、HOWが増えるほど“守破離”の破や離が遅れるリスクも感じました。

イベントを通した学び

今回コミュニケーションさせて頂いたそれぞれの方が、自らのコンテキストに立ってスクラムガイドを評価していることが興味深く感じました。
そうした意味でも、今までの抽象度の高いガイダンスの効果なのかもしれないと思いました。
また、今回ネガティブな意見もありましたが、実際に自分の目を通して理解に至っていないため、しっかり自分で理解し考えたいとも思いました。
いずれにせよ、肯定するにしろ、批判するにしろ、新しい指針が生まれることで思考が拡張されることを楽しくも感じました。
また、スクラムガイドはアウトカムを着目し、それを扱う人はディスカバリーを期待する。それを知れただけでも学びがありました。
私のチームはスクラムで開発をしているため、チームでも自分たちのスクラムを定義するために読み合わせたいです。

追記

Newbee動画

イベント後に気になっていたNewbeeの動画も観ました。
改めて、今回の拡張版は聖典とせず、参考のひとつにすべきものと至りました。
ただ、やっぱり原典の人が書いていることで、これさえやってればスクラムできてるというフィーチャー・ファクトリー的チームが増えそうな気もしています。
また、それを気にするのは自分が準委任の開発者だからなのかもとも思いました。難しい。

www.youtube.com

アジャイルカフェ動画

アジャイルカフェも観ました。
前半とそれ以降での資料のあり方の違いや、今までのガイドブックというあり方に対してのプレイブックという捉え方が興味深かったです。
書かれたことをそのままなぞるのでは、という文脈はどこも一緒。

youtu.be

吉羽さんツイート

そう言えば当時吉羽さんも何かツイートされていた気が、と思ったら同じようなこと仰ってた。

アジャイルラジオ

配信当時一度聞いていた気がしつつ再聴しました。
今回の拡張版のアウトカムに対する言及とコンテキスト次第で難易度が変わりそうという話が興味深かったことを思い出しました。

agileradio.github.io