- Top
- スクラムフェス大阪2025 に参加しました
スクラムフェス大阪2025 に参加しました
2025/08/12目次
参加目的
他社のスクラムの事例を学び、自分のチームのプロダクト開発に活かしつつ、新しい課題につながるきっかけを得ることを期待して参加しました。
また、オフラインならではのネットワーキングを通じて、学習機会を増やしたいと考えていました。
セッション別メモ
How much code did you throw away today?
- スクラムの原点にはなかった考え方が今のスクラムガイドには書かれている？
- 複雑な選択肢は少しずつ作って捨てる。
- 作ったものを捨てても、学びが残る。
- 開発者はコードを書くことが重要ではない。
特に、「複雑な選択肢は少しずつ作って捨てる」という考え方は納得感があるけど、実践するとなるとどう進めるといいのか難しいなと思いました。
ただ、コードのアウトプットだけが重要ではなく、コードを捨てることからも学びが得られるという視点はなるほどと思いました。
Outcome の設計と計測のやり方
- Activity: プログラミングなどの活動
- Output: 生み出された (中間) 生成物
- Outcome: 生成物を通して得られた成果 (変化)
- できなかったことができるようになっているか？もしくはなってないか？
- 効果がない、副作用があるのも Outcome の一種
- Impact: 成果の対価として得られたもの
じゃあこのサイクルの中にある Outcome をどう設計・計測する？
→ Outcome だけで考えずに Output, Impact を含めて全体で考える
→ それぞれに責務を持っている人たちで一緒に取り組む
→ 対話を通じて継続的に学んでいく
これらを実現するために加える日常の活動への変化
- Outcome をプロダクトのロードマップに設定する
- 考える際の観点
- ビジネスとしてどうなりたいか？
- そのために利用者がどんな体験ができるといいか？
- そのためにどんな機能、プロダクトになるといいか？
- ↑ この時に Outcome だけで考えずに Output, Impact を含めて全体で考える
- 考える際の観点
- Outcome をプロダクトのバックログに設定する
- 考える際の観点
- 誰の課題を解決する？
- 解決できているかを何で計測する？
- どうなっていたら解決できていると言える？
- ↑ 行動が変わるだけじゃなく「課題がどうなっているか？」が大事
- 考える際の観点
- プロダクトのデモ、レビューで Outcome を計測する
- デモで利用者に触ってもらって Output からどんな Outcome が生まれるのかを観察する
そもそも Outcome ってなんで重要？ってところはこの記事がわかりやすかったです。
バックログから始めるカイゼン生活
- チームのバックログを観察することで、課題の構造が見えてきた。
- この時に因果ループ図を用いていた
- バックログの扱い方を変えていきましょう
- ただその前にアレルギーチェックを行った。バックログの書き方を変えることへの抵抗を確かめる
- この書き方をしないと PdM は社内で評価されない？
- この書き方をしないとチーム外の承認プロセス等に不備が生じる？
- ただその前にアレルギーチェックを行った。バックログの書き方を変えることへの抵抗を確かめる
- バックログをチーム全体で考えるようにした
スクラムはハチドリに学べ！1DAY スプリントとゴール設定が生む驚きの推進力
-
スプリントゴール設定の効果
- 柔軟性、集中、一致団結をもたらす
-
書籍「スプリントゴールで価値を駆動しよう」では、ゴール中心に試行錯誤しながら進める「ハチドリ・スタイル」を推奨している
- 謙虚な計画を重視し、軽やかに適応しながら学び、調整し続けるスタイル。スプリントゴールを中心に試行錯誤しながら最適な解決策を見つける。
-
ただ、有効なゴール設定をできない課題があった
- 計画を立てられない
- 価値の言語化・構造化が難しい
- 対話がない
-
それぞれに対策をした
- 計画を立てられない
→ スプリント期間を 1 日に - 価値の言語化・構造化が難しい
→ ゴール設定のワークをチームで繰り返して練習 - 対話がない
→ 自己紹介など相手に興味を持つ時間を増やす
- 計画を立てられない
-
スプリントゴール設定のワーク
-
PBI を見て優先順位の高いものから、実施しそうなタスクを確認する
-
スプリント後のステークホルダーの状態を妄想する
スプリント後にステークホルダー毎の嬉しい点をみんなで記載して、注力する点を決める -
ゴールを文書化する (集中することと JOY)
これがわかりやすいとのこと- ゴール設定は、SMART, ALIVE, FOCUS を意識する
-
スプリントレビューをイメージアップ
-
スプリントゴールを達成できるバックログを選んでタスク詳細化
-
-
ゴールに向かうことが尊く、結果は成功でも未達でも OK という空気が大切
大阪の SaaS の会社、シナジーマーケティング 60 人のプロダクト組織変遷を全部お話しします！
- 組織において 3 つの壁があった
- オーナーシップの壁
- 専門性の壁
- 価値探索の壁
- それぞれの壁を乗り越えるために、以下のような取り組みをした
- オーナーシップの壁
- 職能横断チームからプロダクトチーム化。
- 「わかる」がオーナーシップを生んだ
- 専門性の壁
- イネーブリングを目的に専門性を持ったライン組織を構築
- 事業間シナジーの創出を得た
- 価値探索の壁
- 価値探索の時間を意図的に作る
- 役割を越境する
- オーナーシップの壁
- 壁は変化が必要なサイン
- 解決策は適切な Reteaming の選択
- 組織設計とは変化をデザインすること
マネジメントは怖くない？ 〜エンジニアが“チームリード”になるまでの葛藤と成長〜
Individual Contributor (IC) だった方がプロジェクトでマネジメント領域に挑戦する中での葛藤や成長が赤裸々に発表されていた。
マネジメントはエンジニアリングから離れる意識があり、マネジメントはしたくない
ただ、技術だけでは解決できない壁に遭遇した
-
信頼の壁
技術的に妥当で低コストのソリューションを提案したが、高コストだが信頼とサポート体制がある他社のソリューションが採用された -
チームとチームの壁
チームの間に落ちたボールやチーム間の協働が難しい -
開発とビジネスの壁
組織の拡大に伴って、間に立つ役割ができて細かくコミュニケーション取りづらくなった
これらの壁を経験し、プロダクトを成長させるためには技術だけでは片手落ちだと感じるようになった
ただ、これまでは自分が扱える範囲の変数に閉じていたが、マネジメントなどこれまで挑戦してなかった領域に挑戦してみると、扱える変数が増えて、ソフトウェア・プロダクト開発にさらなる手応えを感じた。また、ソフトウェア開発が楽しくなった。
また、「チームを良くする」「コラボレーションする」ことへの意識の変化も起きた。
人それぞれに変数と定数の領域があり、そこを観察することから始まるということ。
元々、自分は人をリードするタイプじゃないと思っていた。
チームや組織に火をくべるリードする人たちがそういう人だと思っていた
ただ、チームリードとして自分が火を作るんじゃなくて、誰かの火を大きくするためになら動けるかもしれないという気づきがあった。
具体的に以下のことに取り組んだ
- チームのスピードを緩めてしまうものを排除する
- チームが動きやすい場を整備する
- エンジニアと他職種とのハブになる
これらの取り組みを通して、以下のことを感じた。
- これまではプログラミングだけをしようとしていたのかもしれない
- 生産するソフトウェアだけに関心を払っていて、組織のことを考えられてなかった
- 「チームや組織を良くすること、PJ を前に進めるために枠にとらわれない活動全てがソフトウェアエンジニアリング」
今の認識では、マネジメントはソフトウェアエンジニアリングをうまくなるためのパズルのピースの 1 つに過ぎないのかもしれないと考えるようになった。
人はなぜ変われないのか？自分を変えるとは何か？どう在るべきなのか？
人が変わることを質的変化を指す「変容」と表現する
人が変わるとは何か?
- 人間は知覚できるものが他の生物よりかなり多様
- 同一種族内でも環世界が違う
生き物や一人一人の人間にとって、「知覚できる世界・働きかけられる世界」は異なる。この世界を「環世界」と呼ぶ。
自分の環世界を変えること ≒ 自己変容
能力・論理だけでは早さに追いついていない
- 技術的課題
- 既知の解決策や既存の専門知識で対処できる問題
- 適応課題
- 内面の価値観・信念が変化しないと解決できない問題
- 振る舞いや仕組みの裏側に存在するため、「認知が困難」
→ 適応課題には自己変容が必要になる
Why・What が問われるのが今
適応課題は、認知が難しい。技術では解決できず、複雑化するだけ
自己変容が大事。それを導けるリーダーシップが必要だし、そのリーダーシップには種類がいっぱい
能力と経験以上に、自己変容と人徳の獲得
- なぜ人と組織は変われないのか
- 変化が怖いんじゃなくて、変化した先の世界に無防備で放り出されることが怖い
- 免疫マップ: 変わりたくても変われないことを可視化する
免疫マップ
-
自分の中の許せない自分
- 許せない自分に対する対応は現実でもやってしまう
- 自分の一部として受け入れられた時に、本来の自分を取り戻すきっかけになる
-
心理的安全性とは「怖がらせない」こと「言ってはいけないこと」がないこと
- 心理的安全性は大事だけど、条件付き
- 相手の存在を否定しない
- 集団・個人を萎縮させない
- 利他的・学習的意図である
- 共通のゴール (成長・癒し・成果) の共有
- 万能ではないし、どのようなシチュエーションにも適用するのが正しいわけでもない
- 心理的安全性は大事だけど、条件付き
-
心理的安全性と自己変容はニコイチ
- 心理的安全性がないと自己変容は起きない
最高のステークホルダーになるために
- 「明確さを生み出すこと」がマネージャーの仕事の全て
- これがあったらチームは自走する
- ものづくりには複雑さ・不確実性が溢れている
- どうやって明確さを生み出すのか。
- 基本は意思決定
- 一人で決める方法
- 合議で決める方法
- 思っている以上に個人での意思決定は大事
- 何をどう決めたらいいかは Outcome を見ればいい
- 意思決定をしてコンテキストを絞り込む。明確さを生み出してチームを導く
- 基本は意思決定
- 「集中」する時間を作り出す
- チーミング
- もっと上手い仕事のやり方を考えだしながら、仕事を片付けてしまう方法。すなわち、実行と学習を同時に実現する方法
- 明示的なチーミング
- スクラムにおけるレトロスペクティブ
- チームビルディング
- 暗黙的なチーミング
- 日々の huddle 雑談
- slack でのチャットやリアクション
- times でのつぶやき
- チーミング
- ゆるやかな文化づくり
- 大切にしたい文化を言葉で示して行動に起こす
- ドキュメントを書くこと
- 振り返りをすること
- (意図的に)対話をすること
- 大切にしたい文化を言葉で示して行動に起こす
- 象さんから目を背けない
- アジャイル開発に適していないリリースチェックリスト
- 過度に詳細さを求められる提出必須なドキュメント
- などなど...
- 自分の仕事ではないのでは？と思うと、マネージングアップやチェンジマネジメント
- マネージングアップ
- できるだけ橋を渡って考えてみる
- リーダーシップ陣の置かれている立場をできるだけ理解する
- そのためにできるだけ相手のコンテキストを押さえておくと良い
- できるだけ橋を渡って考えてみる
- チェンジマネジメント
- 組織的対話の場を作る
- 幹部と現場が継続的に話す場を作る
- 続けていると、継続したボトムアップ活動はどこかのタイミングで flip することがある
- 非公式なインフルエンサーを大事にする
- 組織的対話の場を作る
- 相手の立場とゴールを徹底的に知る
- 何を、なぜ気にしているのか？を理解する
- 理解するために、どんな手段であれ会話の物量が確保できると良い
- ベースとしてのファシリテーションスキル
- 発散は非同期で
- 収束方法もざっくり決めておく (Vote で絞り込むのか、委譲するのか)
- 同じ画面を見て話す
- リモートなら、カメラなし+マイクのみ+メモなしは厳しい
- セルフマネジメント
- 燃え尽きない / 自分の身を守る・限界を知る
- 卑下しすぎない
- 常に立ち返る問い
- 自分は今、何を成し遂げたくて働いているのだろう？
- そこに (自らが共感する) 大義はあるだろうか？
まとめ
プロダクト開発から組織の話まで、幅広く知識を得ることができてよかったです。
今までの自分にはなかった視点も得ることができ、今後の業務に活かせそうです。
ryounasso