もくもくプロダクトマネジメント( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについて黙々と

RSGT2019に行ってないけどレポートをする

久津(@Nunerm)です。

 

1/9から3日間Regional Scrum Gathering Tokyo 2019が行われました。

2019.scrumgatheringtokyo.org

 

参加してません(`・ω・´)

 

けどTwitterの"#RSGT2019"タグで流れてくるツイートが面白そうだったので、スライドやツイートを勝手に見てレポートします。もちろん全部は無理なので一部だけ。

 

Regional Scrum Gathering Tokyo 2019 - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた | ConfEngine - Conference Platform

 

 

 

EMFMファンにはおなじみのゆのんさん。

チーム人数が増えてきた時に「人数の割にはパフォーマンスが出ていない」という悩みはあるあるですね。"1+1<2"になりがちなのがチームというもの。そこで並行バージョン開発を導入してパフォーマンスを向上させたお話です。

f:id:swnws322:20190112172658p:plain

f:id:swnws322:20190112172713p:plain


うちの組織でも一回これと似たようなことを試してみたんですが、マネジメントが下手くそだったのでv.1.0.0チームとv.1.1.0チームのコミュニケーション量が減ってしまいました。例えばv.1.0.0が盛り上がってマネージャーがそっちにかかりっきりになってしまうと、v.1.0.0チームが放ったらかしにされてモチベーションが下がってしまったことがありました。

ゆのんさんのスライドのこのスプリントの組み立て方(つまりはLeSSっぽいスタイル)が有効なのかな。ここは詳しく聞いてみたい。

f:id:swnws322:20190112173627p:plain

f:id:swnws322:20190112173454p:plain



 

Regional Scrum Gathering Tokyo 2019 - ちゃんとやってるのになんかうまくいかないスクラムからの脱出 | ConfEngine - Conference Platform

 

 

とにかく絵が可愛い…

まだまだ自分はスクラム初心者で自分のチームも「なんちゃってスクラム」ですが、確実に最初はうまくいかないと思っています。うまくいくイメージが湧かないので。そんな時にこのスライドを参考にしたい。

f:id:swnws322:20190112175025p:plain

f:id:swnws322:20190112175046p:plain

この「コードレビューにかかる時間が読めない」のは自分のところも同じ。レビューイ・レビュアの組み合わせ、レビュー対象のコードの種類などでいつも時間がバラバラになるんですよね。そこへの打ち手として、全員の知識交換をして「チームとして納得するコードにする」というアプローチ。既にメンバー数人から「書き方がイケてないところがあるから書き直したい」と言われている現状では、この打ち手は有効かもしれない。

f:id:swnws322:20190112175716p:plain

スクラムを現実の上で回す」という表現は好きだな。決してチームのパフォーマンスを過大評価しているわけではないけど、スクラムに限らず開発のプロセスでは「想定」が入り込んでしまいがちです。現実を1つずつ可視化していって想定を排除していくことで、無駄やリスクの少ない開発ができますね。これは肝に命じておこう。ホワイトボードに貼っておこうかな。

 

Regional Scrum Gathering Tokyo 2019 - 行動分析学に基づくScrumの導入 | ConfEngine - Conference Platform

www.slideshare.net


これは面白い!けどスライドだけでは十分に理解できない…!

スクラムがうまく機能しないので何かの「行動」を改善したい時に、その行動が引き起こす後続事象に着目するというアプローチということですかね。

後続事象がその行動に対して「好子」なのか「嫌子」なのか、つまりその行動を繰り返したくなるのかやめたくなるのかを把握し、そこをデザインし直すことで行動自体を改善するということ。

f:id:swnws322:20190112181223p:plain

これは現場で聞きたかったなあ…

 

 

Regional Scrum Gathering Tokyo 2019 - プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー / Fact based decision making | ConfEngine - Conference Platform

 

これは刺さる内容だ…!

表面上の数字だけで機能を「負債」と定義してしまって、特に深掘りもせずに切り捨ててしまい、気づいたら売上やユーザー数などの指標が悪化しているパターン。ありがちですね。

このスライドの例で言えば、キャリア決済の存在と売上・CVとの間の因果関係がテーマになってますが、この因果関係をアクションログなどから求めることは、相当データ分析に秀でた人材がいない限り難しいと思います。

では因果関係を明らかにできない時にどうするか?ありがちなのは「思考停止」すること、つまり表面上の数字だけで「たぶんこういう結果になるだろう」という思い込んで意思決定してしまうことでしょう。そっちの方が圧倒的に楽なので。

それをこの発表の例ではしっかり労力をかけてA/Bテストで因果関係を明らかにしました。いやー素晴らしい。この姿勢は見習います!

f:id:swnws322:20190112184556p:plain

 

 

Regional Scrum Gathering Tokyo 2019 - そのときサーバントリーダーはどう振る舞うか | ConfEngine - Conference Platform

サーバントリーダー」って何と無くイメージは湧くものの、具体的に何をクリアできればサーバントリーダーなのかモヤモヤしてたので、このスライドはいいヒントになりそう。

特にこのページが刺さりました。

f:id:swnws322:20190112185621p:plain

メンバーが楽しく仕事をしてパフォーマンスが上がっていれば「ああ、俺良いサーバントリーダーだな」とか勘違いしてしまいがちなところで、改めてこの4つの観点で自問自答すると穴が見つかるはずです。特に「立場を超えた本音を聞けている気がしない」と「信頼されるだけのOutputを見せられているか不安」はまさに自分もそう思いました。

f:id:swnws322:20190112190046p:plain

「傾聴」「共感」「癒し」「納得」の観点で本当に自分がサーバーントリーダーに慣れているのかは常々自分を客観視します。

 

 

以上、「RSGT2019に行ってないけどレポート」でした。

もちろん実際に参加する方が学びは多いはずだけど、こうやってスライドだけで学ぼうとする作業も大変だけどその分頭をフル回転させる必要があるので、色々気づきがありました。

とは言え来年のRSGT2020は絶対参加します!

 

【スポンサーリンク】