だいだいそんな感じ。

4年間現場を離れた元エンジニアが勘を取り戻す記録。

Regional Scrum Gathering Tokyo 2020に初参加してきた話[Day1]

Day1

RSGTに関しては、毎年なんとなくその存在を知ってて、アジャイル開発には昔から興味があるものの、スクラムも別にやっていないし、自分には関係無いよね、と思って食わず嫌い(?)だったのですが、去年の11月に Certified ScrumMasterの研修を受けて資格を得たのもあり、飛び込んでみようと思ってチケット争奪戦に参加し、今回初参戦を果たしました。(CSM研修の中身もブログ書こうと思って、ずっとサボっていたけど、ココで宣言しておけばそのうちまとめる…かな?)

結果として、いままで参加したどんなイベントよりも熱意があり、その「場」を楽しむことができたので、ブログとしてアウトプットしてみようと思ったんですが、一気に振り返ろうと思ったけど、1日目だけでもかなりの量になったので、3日間別記事として書くことにしました。

キーノート The Ten Bulls of the Scrum Patterns

最初のセッションは、A Scrum Book の発起人でもあるJim Coplien(コープ)さんのキーノート。 開始前にMCの川口さんが、コープさんは急遽来られなくなりました、の仕込みからの、浪人姿で現れ、「誰か、酒をくれませんか?」で本当に飲んでからスタートしてビックリw その姿が禅の十牛図の最終段階を体現するコスプレだったという凄い仕込みでした…。

f:id:daidai7:20200108102402j:plain
Do you have SAKE? なコープさん

禅における十牛図、以前にどこかで聞いた事あるな?と思ったんですが、Wikipediaから転記すると 悟りにいたる10段階を10枚の図と詩で表したもので、「真の自己」が牛の姿で表されているもので、牛を求めるの牧者は、仏の道を究めようとして迷いの世界に入りもがき苦しんでいる現在の自己のことを指すらしいです。 それぞれのステップは以下の通り。

  1. 尋牛 - 仏性の象徴である牛を見つけようと発心したが、牛は見つからないという状況。人には仏性が本来備わっているが、人はそれを忘れ、分別の世界に陥って仏性から遠ざかる
  2. 見跡 - 経や教えによって仏性を求めようとするが、分別の世界からはまだ逃れられない。
  3. 見牛 - 行においてその牛を身上に実地に見た境位。
  4. 得牛 - 牛を捉まえたとしても、それを飼いならすのは難しく、時には姿をくらます。
  5. 牧牛 - 本性を得たならばそこから真実の世界が広がるので、捉まえた牛を放さぬように押さえておくことが必要。慣れてくれば牛は素直に従うようにもなる。
  6. 騎牛帰家 - 心の平安が得られれば、牛飼いと牛は一体となり、牛を御する必要もない。
  7. 忘牛存人 - 家に戻ってくれば、牛を捉まえてきたことを忘れ、牛も忘れる。
  8. 人牛倶忘 - 牛を捉まえようとした理由を忘れ、捉まえた牛を忘れ、捉まえたことも忘れる。忘れるということもなくなる世界。
  9. 返本還源 - 何もない清浄無垢の世界からは、ありのままの世界が目に入る。
  10. 入鄽垂手 - 悟りを開いたとしても、そこに止まっていては無益。再び世俗の世界に入り、人々に安らぎを与え、悟りへ導く必要がある。

コープさんは、コレを、スクラムの道を探求する我々に例えて、みんなが悟りを開いている状態である、という話をされました。 十牛図のステップでいうと、「見跡」の段階で我々はスクラムに出会い、「得牛」の段階でいろんなパターンやモデルを学びつつもモヤり、「騎牛帰家」の段階で自分自身のモノとして得たパターンに誇りを持ち、「人牛倶忘」の段階でパターンなどなく、その場にあるものが真実だと悟り、「入鄽垂手」の段階で自分が高みになるのではなく場に降りて一緒につくっていくことだと気づくという感じ。 今みんないろんなステップにいる。迷っているとしても、いまいる位置をちゃんと理解することが重要で、迷ったらWhyを追求し、自分の真の姿に反映する「無名の質」を手にいれて、スクラムの心は特に意識せずとも使えるようになるべし。十牛図は改善の道。スクラム組織は生きもので、必ずの正解があるわけではなく、失敗を認め、それを現場環境に合わせて改善していくもの。「反省なくして改善なし」。といった感じでしょうか。

キーノートからグサグサ刺さる内容だったのでRGSTすげーな、と思うスタートでした。 めちゃイイ内容だったのですが、スライド公開されるもの、と思っていたので断片的にしかスライドを写真に収められていなくて残念…。どなたか、最後の「入鄽垂手」のスライド写真、分けてくださいw

A Srcum Bookはこちら。日本語化される予定はあるんでしょうか…??

アジャイルコーチ活用術

Ryuzeeさんこと、アトラクタの吉羽 龍太郎さんによる、外部のアジャイルコーチを使ってみたい?と思ったときに考えることのセッション。

ここでいうアジャイルコーチの役割は、ティーチング・コーチングを駆使して、「他人から押しつけられるアジャイルの行動規範に依存しない、自分たちで考えることのできる、生産的なアジャイルチームを育てる」こと。 1on1の勉強会とかでも良く出てくる、ティーチングとコーチングに関しては、前者が「(だいたい)一方通行の指導活動」に対して、後者は「双方向の育成活動」。どちらかが正解というわけではなく、現場の状況に応じて使い分けることが必要。

アジャイルコーチは銀の弾丸ではなく、自分達がコーチを依頼するときに、「何を」「どのように」依頼するか、導入する組織の中で意識と優先順序を揃えて「期待値」を設定することが大事。 予算ありきで導入しようとすると、短期間な導入になったり、薄っぺらい内容になったりで、中途半端な成果しか得られないことが考えられ、いわゆるプラクティスだけを実践していると、いざ自分達で考えて動こうとしても動けなくなるだというとのこと。 単価が安かったり、フルタイム稼働を提唱するコーチ、コーチ自らが他の現場や、学びの場を巡っていたりなどのインプットを怠っているコーチに関しては、要注意とのこと。

コーチは、チームのキャパシティを増やすのではなく、ケイパビリティを拡げてくれる存在であるべし、と。また、評価に関しても定量的には測れず、チームの状態を定性的に見て測ることが必要で、解決したい課題や、導入したいチームとコーチのスキルやキャラクターの愛称も大事なので、何人かと会ってみては?と。 ウチの現場では、スクラムはもとよりアジャイルな考え方がぜんぜん浸透していないので、本格的になにかをはじめるときはアジャイルコーチが必要だな、と感じていたのでとてもタメになるセッションでした。

スライド資料はこちら。 slide.meguro.ryuzee.com

みなさんのプロタクトバックログアイテムはOutcomeを生み出していますか?

ギルドワークスの中村 洋さんのセッション。 プロダクトバックログアイテム(PBI)に対する、OutputとOutcomeとは違う。たとえば、Outputは「作った機能」、Outcomeは「利用者がどう変わったか、幸せになったか?」というもの。ただ、それらは対立構造ではなく、両方ともフォーカスすることが必要で、片側だけ意識しても無意味。ただ、実際の現場では、Outputのみを評価される状況があったりもするので、ビジネスの価値を計るという意味でOutcomeにもフォーカスを当てるということが大事ですよ、というお話でした。

実際の事例では、まさにOutput偏重に場で、Outputの量やコストについて議論していてイマイチうまく行っていない現場が、Outputからの脱却ということで、PBIの価値としてダイヤという概念を付け加えて、よりOutcomeを出せるようなPBIにすることで、仮にOutputの量が減ったとしても、Outcomeが増えるのであれば、むしろそちらのほうが価値は高い、と言う考え方の話がありました。このダイヤとストーリーポイントがわかることで、それぞれのPBIにおけるROIが判りやすくなり、より納得感のあるPBIの優先順位付けができるようになったとのこと。その時の詳細に関してはこちらで詳しく書かれているようです。

計測の価値として、インパクトトラッカーを作ってみるというのもあり。非常にわかりやすい指標だと思いました。

  1. 名称:何と呼ぼう
  2. 利益:どんな価値を届けよう
  3. 計測:計測の単位を決めよう
  4. 方法:どうやって計測するのか
  5. ベースライン:どこからはじめるのか(基準値)
  6. ターゲット:どこまでの改善を望むのか
  7. 結果:それらが与えるインパクトはどのようなものか

スライド資料はこちら。 speakerdeck.com

見積もりしないスクラム

毎回エッジの効いたセッションでタメになる陶山 育男さんの衝撃作。

「見積もりをしない」と聞くとなんじゃそりゃ?なりますが、見積もりそのものが無駄ということではなく、そのやり方を工夫しましょうという話。私自身、何でも工数を出すことに拘るやり方に辟易しているので、ものすごく共感できる内容でした。

なぜ見積もりをすることをやめたのか?の理由と背景がきちんと説明されていて、そしてそれは恐らくどこの現場でも普通に起きていること。そもそも作るものが明確になっていなかったり、Doneの定義がすり合っていない状況での見積もりは、非常にブレがおおきく、ココに時間を掛けて数値化する意味ってないよね?というお話です。

見積もりに対して、数値化を迫ることにより、コミット圧力の「ムリ」、仕事量の最大化の「ムダ」、正確であるという錯覚の「ムラ」の3M問題が発生してしまう問題があるが、そもそもスクラムガイドに出てくる「見積もり」に関して、「数値化しろ」と書かれてはおらず、ここでは、見積もりの負の側面を最小まで回避しつつ、C3Dで測定しつつ優先順序付けをして、見積もりの価値を高めようと言うやり方で進めていきます。そこの精度を上げていくために、モブプロを使うと良いよ、ということとその実践についても語られました。

スライド資料はこちら。 speakerdeck.com

モブプログラミングx行動分析学x教育

土肥 拓生さんの教育現場で学生がプログラミングの予習をしてこない件、モブプロをすれば、周りに対して恥ずかしいと思って予習してくるのでは?という仮説とその検証を行ってみた話。

行動分析学におけるABC分析の話はおもしろかった。先行事象(Antecedent)→行動(Behavior)→後続事象(ConSeqence)という流れで、人の行動に対して整理をして、状況を改善するための仮説を立て、後続事象における好子と嫌子にわけて、好子を増やして、嫌子を減らして行動を促してみてはどうか?と言う話。 注意点として、なんでもかんでも独りよがりに介入するのは良くないですよ、とのこと。

状況を改善するためにキッチリと人の行動を分析するとよいが、良かれと思って自分勝手に動きすぎるのも良くないっていう話は、日常の周囲の環境改善にも通ずる話だなぁと思いました。

スライド資料はこちら。

www.slideshare.net

リーン・チェンジ・マネジメント ー チーム・組織に変化を起こす!オリジナルのチェンジ・フレームワークを構築する方法

Stefan Nüsperlingさん / 鹿嶋 康由さん

個人的にManagement3.0の考えの延長にあると思っている、Lean Change Managementの考え方に関するワークショップ。 なにかを変革することに対してなぜ失敗することがあるのか。人は変化に抵抗するのではなく、変化させられることに抵抗するのであり、みんなで変化することが、Lean Changeにおいて大切な考え方である。その変化に関しても、状況をしっかりと洞察し、打ち手の選択肢を考え、小さく実験する、その繰り返しによって達成できるはず!という。その際に、Lean Change Canvasを作って、チームで議論していこうというワークショップでした。

M3.0に関しては、ちょうど一年ほど前にみっちりと2Dayのワークショップをうけて、いまの自分のマネジメントの考え方の源泉になっていたりするので、このセッションは外せないな、と思った次第。 以前別の機会に同じような体感型のLCMワークショップは受けていたものの、実際のグループワークのときにモヤモヤがと消化不良が残っていたので、その時の復習も兼ねて…のつもりでしたが、そこはRSGT参加者だけあって、非常にハイコンテキストな状況においても、一瞬で課題に対するミッションを把握し、グループワークで具体的なアクションプランを出すところまで持っていくことができるという、良い意味で裏切られたひとときでした。

f:id:daidai7:20200108165737j:plain
うちのテーブルで作成したリーンチェンジキャンバスの例

当日はサラっと流されましたが、チェンジエージェントが仲間を見つける動画は必見なので貼っておきますw

www.youtube.com

ネットワーキングパーティ

初日にネットワーキングの時間がしっかりと取られているのも、このイベントがいわゆる Conference ではなく Gathering である所以ではないかな、と。 ついつい狭い話に終始してしまって、もっと大局的に使えなかったのが心残りではあります。この時間をもっと有効に使えるようになることが来年の課題かなぁ…。

f:id:daidai7:20200108170722j:plain
オードブルもなかなか素敵な感じ。美味しかった!