RSGT2025 Day1 聴講記
株式会社Relic エンジニアの、エイミ/amixedcolorです!
RSGT2025 Day1の各セッションごとの聴講記です。
自分のために書いていて読み物としては読みにくいかもしれませんが、各セッションがどんな内容なのか少しなぞりたい人にはちょうど良いかと思います。
The Best Product Engineering Org in the World
生産性について
生産性は計測できない(複数の識者がそう結論づけている)
エンジニアリング組織で大切なこと
People
「最高」とは何かを定義した
組織文化を変えた
Internal Quality
価値創出に費やす時間が15%しかなかった
3つの問題がある
複雑さ
遅いフィードバックループ
延期されたメンテナンス
AIによってコードを「はやく」書き上げることはできるが、そのメンテナンスやコードの読解は難しい
改善する方法の評価
ビッグバンリライト:全てを破壊して書き直す
難易度が高く不適当
モジュラーリライト:部分部分を切って段階的に書き直す
ビッグバンに比べればマシだが最終的には複雑になり不適当
変更駆動リライト:機能追加やバグ修正の一環として書き直す
時間はかかるが、効果がある
Improve in Place
最適
コードが古くなればなるほど改善されていく
Lovability
愛され力というのは外部品質のこと
顧客が本当に必要なものに注力して構築する
90年代から今まで、多くは構築するものを決めてから構築する。呼び名をウォーターフォールからアジャイルに変えつつも、実態は変わっていない企業ばかり
MVPとは何を提供すれば良いのかの最も小さなテスト
多くの会社が「アジャイル開発をしている」というが、その多くが画像の2つを行なっていない
適応型ではなく予測型になってしまっている
人間中心ではなくプロセス中心になってしまっている
Visibility
透明性を設けても、「全ての人を満足させる」ことは不可能
ステークホルダーはスケジュールの見通しを求めているが、話者は行わない
CTOやCEOが適応型のアプローチをよく理解しているから
Agility
あまりにも1チームの人数が多い場合は分割する
スクラム「だけ」を正しくやろうとして価値あるプロダクトになるかな?
スクラムをやっているがうまく行かないという人向け
スクラムは意図的に不完全なもの
語られていないこと
利用者にとって役立っているかをどう考えるか
利用者にとって役立っているかをどう計測するか
チームの外の人たちとどのように協働するか
スクラムガイドにあることをやるだけではなく、自分たちで必要なものを見つけよう
スクラムを補完するアイデア
どう役に立つのか?を話す
プロダクトバックログアイテムにこんなことを足して会話してみる
誰がどのように嬉しいのか
なぜそれが嬉しいのか
どうやって確認するのか
どんな行動が増えているのか
スプリントレビューでこんなふうにしてみる
実際に使っている様子を観察する
役に立つプロダクトづくりについて話す
こんなメリットがある
ステークホルダーごとの異なる視点がある
チームが気づかない視点を持ち込んでくれる
まとめ
スクラムのやり方にこだわりすぎず、利用者に役立つものを提供し続ける方法を 探し続けよう
アジャイルコーチが事業会社を立ち上げたけど、事業環境が生んでみた視点が広がる
事業会社について
介護業界の事業会社
介護業界の現状
今年から戦後ベビーブームの世代が後期高齢者で需要が増大
人手不足のうえ、低賃金と言われ成り手不足
紙やFAXなどアナログな部分が多く書類業務負荷が高い
→質の維持をしつつ効率化するという社会的圧力が高まっている
CareFranは何をするのか
SaaSではなく、介護事業そのものを高効率で提供する仕組みを作る
介護事業者の賃金問題と業務負荷の問題を両方解決
CareFranの現状
スタートアップのステージは、シードからアーリーに入ったところ
この年末年始で、初めて本業で売上が立つ見込みがたった
知った気になっていること
スクラムマスターやアジャイルコーチがよく言うし、知った気になっていること
事業環境を理解する
ユーザーに向き合う
価値を届け、事業に貢献するプロダクトをつくる
失敗を許容する
ドメイン理解が沼 - 事業環境を理解する
ケアマネージャーが不足している自治体で設立した
しかし利用者の紹介は来ない
→知っているところ、知っている人でないと安心して紹介できない
→地元でネットワークのあるメンバーを採用合理的に正しければ課題解決できるわけではない
手元の課題が解決したとして、1段階、2段階さらに掘り下げられないか?
われわれは空気を吸うようにITスキルを行使している - ユーザーに向き合う
われわれは世界の果てからきた
そしてオープンなコミュニケーションをしようとか怖いことを言っている
「怖い」「壊しそう」と言う不安を払拭するには対面でのトレーニングが必要
マニュアルを用意したが全然使われない
自動保存が怖がられたりする
価値を主張する前に「その価値の価値」を共有
「これには価値がある」の理由となることまで話す
使い方より新しい働き方に慣れる方が大切
使いこなせばすごいことができる…!? - 価値を届け、事業に貢献するプロダクトをつくる
プロダクトは覚えればすごく便利、ではなく、はじめから楽じゃないとダメ
元々の仕事があって忙しい中で新しく苦労して覚える余裕なんてない
特に、使い始めから「覚えれば便利」は話にならない
既存のプロセスに馴染ませながら変えていく必要がある
プロダクトを使う仕事をさせない。プロダクトに仕事をさせる
はじめは最小限のスコープでいいし、オズの魔法使いでもいい
価値を感じてもらう
われわれは全然わかっていない - 失敗を許容する
どこまでがスコープなのか決めたくなるが、わかっていないことはわかっていた
プロダクトの名前を決めたいが材料がない
とりあえずOKRの番号
LINE公式アカウントはOKRの2番目だった→Niban
介護従事者用システムはOKRの3番目だった→Sanban
はじめから決めうちにしない。でも名前はつける
失敗を許容する、というより、変化の余地を作る
まとめ
ニーズを外形的に捉えるだけでわかった気になっていないか?
意思決定の仕組みまで入り込める手を打てているか
われわれは世界の果てからいきなり現れて怖いことを言っている
やるべきことを主張する前に、なぜそれに価値があるか共感を作る
使いこなせばすごいプロダクトは使えない
スコープは狭くていいので初めから楽にする
「われわれはここまでわかっている」は、多分わかっていない
やってみてわかることが必ずある。変化に柔軟にしておく
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢について
FASTとは
OSTから着想を得ている
開発者が自律的に動くことでファシリテーションを不要とし、人数が増えても機能する
代わりに、開発者の主体性は必要
チーム開発の変遷
2020年から5年をかけて、1チームから3チームのスクラム、さらにチーム間の連携が必要になりスケーリングを検討
マネージャー視点の課題
認知負荷を下げるために機能領域ごとにチームを分けたが、町域横断の開発も増え、コラボレーションの調整コストがある
新規採用における組織成長によって従来の体制ではやりづらさがある
自己組織化への思い込み
個々のスクラムチームがうまく自己組織化していけば大抵の問題は解決できるだろうと考えていたが、実際は独自のチーム文化が発達して連携しにくくなった
アジャイルコーチ視点の課題
行きすぎたサイロ化がある
PRの出し方の順序語りがい、摩擦やコンフリクトが発生
1エピックごとに合同キックオフや連携方法の調整というコストが発生
チームの分け方が、ユーザージャーニーを輪切りにするようなもので、開発者が1チーム内でユーザーの一連の体験を俯瞰できない
真のプロダクト理解が阻害
トータルてみたときの品質の作り込みができない
スケーリングの検討とFASTの導入
スケーリングへの理解を深めるため、複数のフレームワークを勉強会形式で比較
FAST採択からの移行プロジェクトは現場メンバー中心にチーム横断で実施
FASTにチャレンジできた背景
Update Normalという組織のマインド
しんどくても「アブノマ」と唱えて進めた
FASTによって得られたもの
チーム間の差分によるコミュニケーションコストは解消した
機能領域を超えた活動が加速され、ナレッジの流動化が進み、ドメイン知識やシステムの知識を得やすくなった
個別最適ではなく全体最適でのプロセス・カルチャーの情勢に全員で向き合える状態ができた
チームの枠にとらわれない自己組織的な連携に慣れることができた
プロダクトマネジメントとエンジニアリングの距離が近くなり、エンジニア全員がプロダクト全体のスコープで考えてPdMと議論できるようになった
まだまだなところ
真のプロダクト理解は、認知負荷が上がったこともありまだ遠い
コレクティブの結束力もまだまだ
アジャイルコーチのぶっちゃけ
当初はフレームワーク不要と思っていた
スケーリングの知識のない人向けにフレームワークを「こう言った型もある」という紹介をしようとしていた
FASTが選択されたことに驚いたが、今振り返ればいい選択だったと思う
流動的なチームの考え方について
拠り所にしたもの
エイミー・エドモンソンの「チーミング」の研究
即興で作ったチームでもパフォーマンスを発揮することがあるのはなぜか?
ここで発見されたファクターの1つが心理的安全性
「あの人たちが協力的ならうまくいくのに!権限もないから進められない!」トレードオフの連続制御を通して、対立を協力に変えるプロダクトマネジメントチームを実現するぞ
一生ついてまわる「あの人がもっと協力してくれれば」という話について
分割と分業と対立構造
問題の分割をする
→複雑な問題を分割することで簡単になりタスクが明確化される
→問題の分割による分業と無知の拡大
→協力の難易度が高くなるが、これは危険
重要なのは、分割前の問題が解けているか
企業の目標達成の行動は、分割された目標のための行動が相互作用し、簡単に対立構造になってしまう
分業化された組織での権限の働き方
タスクが多すぎる時、多くの場合全体から見てやるべきことからではなく、すぐにやれることから各個人は仕事を始める
権限があると仕事を優先させることができる
→仕事が優先的に終わると成果になる
→権限を奪い合うことになる
車内の大部分は権限がないため、「あの人が協力してくれないから」と思うようになる
このような状況が慢性化するとどうなるか?
権限のない人が目標達成できるようにはどうするか?
自己完結目標の追求をせざるをえなくなる
不完全な解決と協力
問題を分割して一部の問題を解くだけでは、価値が未成立
→やがて組織の機能不全をもたらす
本当に実現したいことは価値のあるプロダクトを届けること
不完全な解決を探すことで協力するべき点を見つけられる
適切な権限の使い方
NO
権限を振りかざす
いいから言われたことをやれ
顧客に見せるまで価値を検証できない
↑こうなったときの浪費は激しい
YES
説明する
早い段階で価値の検証をする
トレードオフをどう解決するか
問題を分割した時、一方を達成しようとすると他方が達成できないことがあり、これがトレードオフ
コンビニオーナーのトレードオフ解決例
おにぎりをいくつ仕入れるのか
売り上げを上げる:おにぎりの在庫を増やす
↑売れるものが増えるからコストを減らす:おにぎりの在庫を減らす
↑売れ残りが減るから
結果をそのまま受け取って在庫を調整すると、在庫が増減するのをいったりきたり
すると疲弊し、売れ残りのコストは痛いので保守的になり、売り切れ側に倒す
するとコンビニではよく売り切れていて、顧客体験が悪くなる
トレードオフを循環的・部分的に解決することは仕事をしたつもりになるだけで、一瞬うまくいったと続けてしまう
結果指標もオペレーションの質も向上していない時は循環トレードオフに注意
では何をすべきか?
現場を理解する
おにぎりの在庫の減り方は食事時という時間帯による
おにぎりの在庫が少なくてもいい深夜帯がある
トレードオフは問題を変換する
トレードオフの解決に別の部門を巻き込む
↑おにぎりの仕入れタイミングの工夫は配送部門にとっては配送回数が増えてよくないかもしれない
配送部門に提案すればうまくいくかもしれないが、提案は大変なので個人の問題としてトレードオフになる
リスクの少ないテストプロジェクトを開始する
馴染みの配送担当者にまずは相談してみる
→1店舗だけ、おにぎりの配送を3ヶ月間検証できることがわかった
しかも配送部門でも流通量を増やす目標があった
本当に効果があるかを部分的なシステムで試す
この場合でも全体と部分のトレードオフがある
↑「スピード導入」と「安全な導入」
トレードオフの解決は異なるトレードオフ
トレードオフは問題にもなるし解決策にもなる
難問だが、質の高い意思決定と捉えることができる
プロダクト開発自体、何かしらの顧客のトレードオフを解決することである
↑例えば、「高くて高性能」と「安くて低性能」
3段階でトレードオフを解消する
分業化された組織におけるもの
自分の責任範囲内のトレードオフ
より複雑な問題を含めたトレードオフ
立ち向かう時の自分自身のトレードオフ
分業化された顧客の組織におけるもの
顧客担当者の責任範囲内のトレードオフ
顧客のより複雑なシステムを含めたトレードオフ
立ち向かう顧客自信のトレードオフ
より複雑な問題のトレードオフの解決は、いずれ社会課題のトレードオフの解決につながり、それこそが社会実装なのではないか
自分たちの価値を左右するトレードオフは何か?
逆を言えば、「私がもっと協力すれば」ではないか?
私たちは少なくとも同じ組織であれば同じ大きな問題に立ち向かっているはず
おわりに
ここまでお読みいただいた方ありがとうございます!
明日ものんびりと書くつもりです。
それでは、またこんど!
追記:Day2の聴講記はこちら
Day2の聴講セッション一覧
フレームワークを生み出すメタフレームワークという考え方 -適応型から生成型へ-
新人マネージャーサバイバルガイド - 使いやすい便利なマネージャーになろう
ペインポイント洗い出しワークショップ ~課題を深掘りして価値ある解決策を見つけよう~
プロダクトマネージャーこそがリーダーだった!? リーダーシップ論から見るPdMとスクラムのいびつな関係