はてなブログとチーム構成とスクラムのこの1年 #dmm_hatena

by polamjag

Slide 1

Slide 1 text

id:polamjag はてなブログとチーム構成とスクラムのこの1年 2022/6/14 【DMM x はてな】そぞのアジャイル開発の現場〜チームの中か外か〜 https://dmm.connpass.com/event/249486

Slide 2

Slide 2 text

$ whoami - id:polamjag (ポラムジャグ) / 安部悟 - https://polamjag.hatenablog.jp/ - 株式会社はてな Webアプリケーションエンジニア - 2018年の入社以来、はてなブログ関連のチームに所属 - Certified ScrumMaster® 2

Slide 3

Slide 3 text

$ whoami - id:polamjag (ポラムジャグ) / 安部悟 - https://polamjag.hatenablog.jp/ - 株式会社はてな Webアプリケーションエンジニア - 2018年の入社以来、はてなブログ関連のチームに所属 - Certified ScrumMaster® - はてなブログ全体の開発チーム・プロセスの改善に取組んでいます - 開発チームの構成を見直した - スクラムを導入してスクラムマスターをやった 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

はてなブログ - toC - はてなブログ - toB - はてなブログMedia — 企業メディア運営に - はてなブログBusiness — 小規模法人の情報発信に - はてなブログ for DevBlog — Businessと同一機能※をお得に使え、法人技術ブログ専用プラン - マルチテナントなアプリケーション - 単一のコードベース・単一のシステム (一つのモノリス + マイクロサービスの仲間たち) 5 ※ https://hatenablog.com/guide/corporation

Slide 6

Slide 6 text

マルチテナントな単一のシステムはてなブログ全体の開発チーム (2020年頃) 6 toB向け開発チーム ● プロダクトオーナー ● エンジニア ● デザイナー ● プランナー toC向け開発チーム ● プロダクトオーナー ● エンジニア ● デザイナー ● プランナー toC向け機能 toB向け機能インフラ・共通部分

Slide 7

Slide 7 text

⏪ 2020年頃 🤔 ⚡ 🏃 🍵 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

すべての始ま — 「DMM本」との出会い - 「DMM.comを支えデータ駆動戦略」 (マイナビ出版, 2020/9) - 今日のこのイベント※の司会・モデレーターであ石垣雅人さんが著者 - 出版さたこ、BigQueryでデータ基盤を構築すプロジェクトを進めていた - データドリブンになたいぜ……という気持ちで読んだけど、そだけじゃなかった - アジャイル開発、プロダクトマネジメント・プロジェクトマネジメントの導入と接続 - 全部話がつながってい - 社内で読書会を開催 9 2年弱前時系列スライダー ※ https://dmm.connpass.com/event/249486

Slide 10

Slide 10 text

すべての始ま — 「DMM本」との出会い - どうやったこうなのかという漠然とした課題感を持っていたが…… - 1年半ほど前にtoC向け開発チームのテックリードになったのをきっかけに本気で考えはじめた - 課題感をときほぐすための手札が増えていた 10 1年半前

Slide 11

Slide 11 text

⏪ 🤔 課題感の分解 ⚡ 🏃 🍵 11

Slide 12

Slide 12 text

🤔 - 一つのマルチテナントなシステムを、プロダクトの領域ごとに別た2チーム体制で一緒に開発していた - コードレビューや技術的な相談、インフラ寄のタスクなどは一緒にやっていた - 片方のチームで施策を実施したときに、もう片方のチームが担当すプロダクトに意図しない影響が発生し、手戻が発生してしまった 12 1年半前

Slide 13

Slide 13 text

🤔 チーム間のコラボレーションに課題がないか - 両チームのメンバーやステークホルダーを集めて、直近で起こった手戻を出発点にして “なぜなぜ分析” 的なアクティビティを実施 - ユーザーにとっての価値がプロダクト間で一致していない部分を、システム上で十分うまく表現できていないことがわかった 13 発生したこと (事実) か、理由や背景、文脈をどんどん辿っていく 1年半前

Slide 14

Slide 14 text

🤔 チーム間のコラボレーションに課題がないか - バリューストリームマップ (もどき) を描いてみた - 開発タスクが着手さまでの道の - 意思決定の主体 (人・場所・会議体)と、その内容が別の主体にどう流かを矢印で繋いでいく - 会議の場合は参加者と開催頻度を書く 14 1年半前

Slide 15

Slide 15 text

🤔 チーム間のコラボレーションに課題がないか - 描いてみてわかったこと - コミュニケーションパスが複雑 - 2週間に一度のミーティングを待たないと話が進まない…… - 分岐の条件が難しい…… - ものすごくたくさんの話題が流入して捌けていない点があ …… - 全貌を把握しづい - 開発タスクをアサインすルートが複数あ → カウボーイ開発にながち 15 1年半前

Slide 16

Slide 16 text

🤔 チーム間のコラボレーションに課題がないか - 2チーム体制になってか年月が経ってい - 徐々に互いのことを互いにあま把握できていない状態になってい？ - 互いのことを十分把握できていないと、把握できていないことにも気づきにくい - Unknown Unknowns的な状態 - いっそ開発チームを合体させてはどうか - 逆コンウェイ戦略……の逆? - チームの構造をシステムのアーキテクチャに寄せ - チームの構造のほうが変えやすかった 16 1年半前

Slide 17

Slide 17 text

🤔 そもそもどうしてこんなことを考えていたのか - もっといプロダクトを提供していきたい - 素早く価値を提供したい → 開発タスクにかか時間、リードタイムを短縮したい - 技術的に困難な課題も解決できうになたい 17 1年半前

Slide 18

Slide 18 text

Slide 19

Slide 19 text

🤔 そもそもどうしてこんなことを考えていたのか - もっといプロダクトを提供していきたい - 素早く価値を提供したい → 開発タスクにかか時間、リードタイムを短縮したい - 技術的に困難な課題も解決できうになたい - リードタイムを短くしていった、チーム全体の力を高めていくうなフィードバックループを回せ状態をまずは目指したい - ……こってスクラムってやつでは？ - ということを考えていたタイミングで、たまたま認定スクラムマスター研修を受けチャンスが社内で巡ってきた - 受けた - やっぱスクラムじゃん！ 19 1年前

Slide 20

Slide 20 text

⏪ 🤔 ⚡ 転機 🏃 🍵 20

Slide 21

Slide 21 text

⚡ 分かていた開発チームを統合してスクラムを導入 - 同時にやった (!) - 問題意識をマネージャーと共有 - トップダウンでいっぺんに変えてみぞ！ということに - 前述の諸々で共通の認識を作ていた - いままではこうだったけど、開発チームを一体化させとしたこうしたいですね、という理想のバリューストリームを描いてみて共有した 21 1年前

Slide 22

Slide 22 text

22 toB向け開発チーム ● プロダクトオーナー ● エンジニア ● デザイナー ● プランナー toC向け開発チーム ● プロダクトオーナー ● エンジニア ● デザイナー ● プランナー toC向け機能 toB向け機能インフラ・共通部分 Before マルチテナントな単一のシステム

Slide 23

Slide 23 text

マルチテナントな単一のシステム 23 統一開発チーム ● プロダクトオーナーチーム ● エンジニア ● デザイナー ● プランナー toC向け機能 toB向け機能インフラ・共通部分 After スクラムを導入

Slide 24

Slide 24 text

⏪ 🤔 ⚡ 🏃 スクラム試行錯誤 🍵 24

Slide 25

Slide 25 text

最初はスクラムイベントを回すだけで精一杯 - スプリント計画、デイリースクラム、スプリントレビュー、ふかえ …… - 教科書的なスクラム開発の経験が少ないメンバーもい状態かスタート - スクラム的なや方、あいはアジャイル開発を全然やってこなかったわけではない - 概念の説明かキックオフ - スクラムマスターなんてやったことなかった - スクラムマスター経験者もチームにいなかった - 全体をリードしつつ、元同じチームのプランナー+元もう片方のチームのエンジニアとに手伝ってもいなが 3人体制 25

Slide 26

Slide 26 text

最初はスクラムイベントを回すだけで精一杯、だったが…… - “チェックポイント” をきっかけに変化を起こし続けことができた - チームでやもの - スプリントふかえ - 個人的なもの + スクラムマスターとしてのチェックポイント - 3人のスクラムマスターズでの会談 - すくすく開発会 (アジャイル大好き横串組織) の定例 - (自分とメンターとの) 1on1 - 今もできてい - スクラムマスターとしてのチェックポイントがあったのがかった - チームのふかえで取入問いかけの視点を仕入た - 「スクラムマスターは孤独」とく言わが、孤独になにくかった。新米なのでなおさ 26

Slide 27

Slide 27 text

数スプリントやってみて - 当時進行中だったタスクやプロジェクトを新生プロダクトバックログにとあえず載せていった状態かスタート……して、 - どうなか 27

Slide 28

Slide 28 text

数スプリントやってみて - 当時進行中だったタスクやプロジェクトを新生プロダクトバックログにとあえず載せていった状態かスタート……して、 - どうなか → スプリントバックログが捌けきない - 最初はタスクの見積ももなかったので、全体でどくいの終わってなさなのかがわかない - デイリースクラムなどでチームの枠を超えて毎日会話できのは良いね、といった雰囲気はあった 28

Slide 29

Slide 29 text

バックログリファインメントの導入 - 既存のissueの見積もか始め、徐々に新たなタスクの分解・リファインメントや見積もに進んだ - 最初はめちゃくちゃ時間がかかっていた - ドメイン知識の分布に偏があ - タスクの説明文や完了の定義が不十分 29

Slide 30

Slide 30 text

バックログリファインメントの導入 - 既存のissueの見積もか始め、徐々に新たなタスクの分解・リファインメントや見積もに進んだ - 最初はめちゃくちゃ時間がかかっていた - ドメイン知識の分布に偏があ - タスクの説明文や完了の定義が不十分 - 見積もが進んだことで、スプリントバーンアップチャートを引けうに - スプリントバックログの溢具合が定量化+可視化さ - バーンアップチャート以外にもいいことがあった - 完了の定義を開発メンバー全員で練ことで、施策の実装着手後の手戻が激減。分かていたチームを統合したメリットも感じ 30

Slide 31

Slide 31 text

余白を生み出す - なぜ余白が必要なのか - 不慣な領域で見積もの予想が外ことが結構あった - 知識の相互伝授のためにもペアプロ・ペアオペを積極的に勧めたい - 障害対応など差し込みの対応が必要なタスクをゼロにできわけではない - 意識しないと余白が生まにくい構造だった - 複数プロダクトを単一のプロダクトバックログで管理 - 優先度・着手順の判断がとても難しい - スプリントゴールの規模や項目が増えがち - 余白のなさ・溢具合は可視化できうになっていた - スプリントゴールを思い切ってめちゃくちゃ絞と……達成に近づけ - が、絞のが難しい! 31

Slide 32

Slide 32 text

スプリントゴールを明確にすための議論を促す - スプリントプランニングのなかでスプリントゴールについて議論しやすくすために、POに以下のことをお願いした - スプリントゴールのwhy的な情報をなべく説明してもうこと - そぞのゴールの項目同士の優先度をなべく付けてもうこと - 議論をすことで、スプリントゴールを明確にしたかった - 明確なほうが量のイメージも湧きやすいはずで、結果的に適切なボリューム感のゴールを設定すことにもつながないか 32

Slide 33

Slide 33 text

スプリントゴールを明確にすための議論を促す……と - 「このタスクはゴールに含まますか？」 - 「入ってないとマズいのでゴールの表現を変えないとですね」 - 「このタスクA もプロジェクトBのほうが優先度が圧倒的に高いけど、Aもここまでだった次スプリントで進めないか」 - 「今気づいたんですがこもやないとスプリントゴール達成できないのでやます」 - スプリント中にこういう動きが生まうになった - スプリントゴールの達成に向かってチームで動けてい状態。最高 33

Slide 34

Slide 34 text

スプリントゴール達成 🎉 - 19回目のスプリントで初めてスプリントゴールを完全に達成 - ついこの前! - なにが良かったのか、あいはこまでと違ったことはなにか - スプリントゴールが十分明確になっていて、見通しも正確だった？ - スプリントゴールを十分絞ていた？ - 十分な余白を確保できていた？ - 当時着手していたプロジェクト (の技術な ) についての理解が深まっていた？ - POの認知負荷も下がったことで割込みタスクの優先度を判断しやすかった？ - まだ再現を積み重ねていない 34

Slide 35

Slide 35 text

⏪ 🤔 ⚡ 🏃 🍵 ふかえ 35

Slide 36

Slide 36 text

1年間をふかえって - 👍 日々の開発は以前もうまく回うになってい - Findy Teamsでいいトラッキング - スクラム導入後は変更のリードタイムが以前低い水準 (ざっく数分の一) で安定 - 👍 改善のサイクルが回うにもなってきてい - スプリントふかえの時間が足なくて困ってます…… - 💪 スクラムの型の意義を実感すタイミングが多い (個人の感想) - 💪 チームの構造を変えたかといって、直ちにそがシステムのアーキテクチャに反映さていくわけではない - Team Topologiesでいう“同形力" - 以前も全体像がく見えうになってい 36

Slide 37

Slide 37 text

おわに —— まとめ - ここ1年ではてなブログの開発チームの構成を見直し、スクラムを導入しました - 導入後もチームの改善を続けことができています - 現状を分析し、理想と、理想への近づき方を考え、実践していくうえで「DMM本」を起点に深堀していった知識がとても役に立ちました - ぼんやしていた課題感を分解すとこか辿ってきて今 - というか、そもそも課題感を植え付けたきっかけでもあ - タイミングもあ、この本と出会ってなかった絶対こうはななかった - いプロダクトをお届けできうにこかもやっていきます 37