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

2022-06-14 【DMM x はてな】それぞれのアジャイル開発の現場 〜 チームの中から外から 〜 での発表資料です

https://dmm.connpass.com/event/249486

ライブ配信のアーカイブ: https://youtu.be/1GnnJMzL3eE?t=1766

Transcript

1. id:polamjag はてなブログとチーム構成と スクラムのこの1年 2022/6/14 【DMM x はてな】 そ ぞ のアジャイル開発の現場 〜 チームの中か 外か 〜 https://dmm.connpass.com/event/249486
2. $ whoami - id:polamjag (ポラムジャグ) / 安部 悟 - https://polamjag.hatenablog.jp/ - 株式会社はてな Webアプリケーションエンジニア - 2018年の入社以来、はてなブログ関連のチームに所属 - Certified ScrumMaster® 2
3. $ whoami - id:polamjag (ポラムジャグ) / 安部 悟 - https://polamjag.hatenablog.jp/ - 株式会社はてな Webアプリケーションエンジニア - 2018年の入社以来、はてなブログ関連のチームに所属 - Certified ScrumMaster® - はてなブログ全体の開発チーム・プロセスの改善に取 組んでいます - 開発チームの構成を見直した - スクラムを導入してスクラムマスターをやった 3
4. $ whoami - id:polamjag (ポラムジャグ) / 安部 悟 - https://polamjag.hatenablog.jp/ - 株式会社はてな Webアプリケーションエンジニア - 2018年の入社以来、はてなブログ関連のチームに所属 - Certified ScrumMaster® - はてなブログ全体の開発チーム・プロセスの改善に取 組んでいます - 開発チームの構成を見直した - スクラムを導入してスクラムマスターをやった 4
5. はてなブログ - toC - はてなブログ - toB - はてなブログMedia — 企業メディア運営に - はてなブログBusiness — 小規模法人の情報発信に - はてなブログ for DevBlog — Businessと同一機能※をお得に使え 、法人技術ブログ専用プラン - マルチテナントなアプリケーション - 単一のコードベース・単一のシステム (一つのモノリス + マイクロサービスの仲間たち) 5 ※ https://hatenablog.com/guide/corporation
6. マルチテナントな 単一のシステム はてなブログ全体の開発チーム (2020年頃) 6 toB向け開発チーム • プロダクトオーナー • エンジニア • デザイナー • プランナー toC向け開発チーム • プロダクトオーナー • エンジニア • デザイナー • プランナー toC向け機能 toB向け機能 インフラ・共通部分
7. ⏪ 2020年頃 🤔 ⚡ 🏃 🍵 7
9. すべての始ま — 「DMM本」との出会い - 「DMM.comを支え データ駆動戦略」 (マイナビ出版, 2020/9) - 今日のこのイベント※の司会・モデレーターであ 石垣雅人さんが著者 - 出版さ たこ 、BigQueryでデータ基盤を構築す プロジェクトを進めていた - データドリブンにな たいぜ……という気持ちで読んだけど、そ だけじゃな かった - アジャイル開発、プロダクトマネジメント・プロジェクトマネジメントの導入と接続 - 全部話がつながってい - 社内で読書会を開催 9 2年弱前 時系列スライダー ※ https://dmm.connpass.com/event/249486
10. すべての始ま — 「DMM本」との出会い - どうやった こうな のかという漠然とした課題感を持っていたが…… - 1年半ほど前にtoC向け開発チームのテックリードになったのをきっかけに本気 で考えはじめた - 課題感をときほぐすための手札が増えていた 10 1年半前
11. ⏪ 🤔 課題感の分解 ⚡ 🏃 🍵 11
12. 🤔 - 一つのマルチテナントなシステムを、プロダクトの領域ごとに別 た2チー ム体制で一緒に開発していた - コードレビューや技術的な相談、インフラ寄 のタスクなどは一緒にやっていた - 片方のチームで施策を実施したときに、もう片方のチームが担当す プロ ダクトに意図しない影響が発生し、手戻 が発生してしまった 12 1年半前
13. 🤔 チーム間のコラボレーションに課題がないか - 両チームのメンバーやステークホルダーを集めて、直近で起こった手戻 を 出発点にして “なぜなぜ分析” 的なアクティビティを実施 - ユーザーにとっての価値がプロダクト間で一致していない部分を、システム上で十分うまく 表現できていないことがわかった 13 発生したこと (事実) か 、理由や背景、文脈をど んどん辿っていく 1年半前
14. 🤔 チーム間のコラボレーションに課題がないか - バリューストリームマップ (もどき) を描いてみた - 開発タスクが着手さ までの道の - 意思決定の主体 (人・場所・会議体)と、 その内容が別の主体にどう流 かを 矢印で繋いでいく - 会議の場合は参加者と開催頻度を書く 14 1年半前
15. 🤔 チーム間のコラボレーションに課題がないか - 描いてみてわかったこと - コミュニケーションパスが複雑 - 2週間に一度のミーティングを待 たないと話が進まない…… - 分岐の条件が難しい…… - ものすごくたくさんの話題が流入 して捌けていない点があ …… - 全貌を把握しづ い - 開発タスクをアサインす ルートが複数 あ → カウボーイ開発にな がち 15 1年半前
16. 🤔 チーム間のコラボレーションに課題がないか - 2チーム体制になってか 年月が経ってい - 徐々に互いのことを互いにあま 把握できていない状態になってい ？ - 互いのことを十分把握できていないと、把握できていないことにも気づきにくい - Unknown Unknowns的な状態 - いっそ開発チームを合体させてはどうか - 逆コンウェイ戦略……の逆? - チームの構造をシステムのアーキテクチャに寄せ - チームの構造のほうが変えやすかった 16 1年半前
17. 🤔 そもそもどうしてこんなことを考えていたのか - もっと いプロダクトを提供していきたい - 素早く価値を提供したい → 開発タスクにかか 時間、リードタイムを短縮したい - 技術的に 困難な課題も解決でき うにな たい 17 1年半前
18. 🤔 そもそもどうしてこんなことを考えていたのか - もっと いプロダクトを提供していきたい - 素早く価値を提供したい → 開発タスクにかか 時間、リードタイムを短縮したい - 技術的に 困難な課題も解決でき うにな たい - リードタイムを短くしていった 、チーム全体の力を高めていく うな フィードバックループを回せ 状態をまずは目指したい 18 1年半前
19. 🤔 そもそもどうしてこんなことを考えていたのか - もっと いプロダクトを提供していきたい - 素早く価値を提供したい → 開発タスクにかか 時間、リードタイムを短縮したい - 技術的に 困難な課題も解決でき うにな たい - リードタイムを短くしていった 、チーム全体の力を高めていく うな フィードバックループを回せ 状態をまずは目指したい - ……こ ってスクラムってやつでは？ - ということを考えていたタイミングで、たまたま認定スクラムマスター研修を受 け チャンスが社内で巡ってきた - 受けた - やっぱ スクラムじゃん！ 19 1年前
20. ⏪ 🤔 ⚡ 転機 🏃 🍵 20
21. ⚡ 分か ていた開発チームを統合してスクラムを導入 - 同時にやった (!) - 問題意識をマネージャーと共有 - トップダウンでいっぺんに変えてみ ぞ！ということに - 前述の諸々で共通の認識を作 ていた - いままではこうだったけど、開発チームを一体化させ とした こうしたいです ね、 という理想のバリューストリームを描いてみて共有した 21 1年前
22. 22 toB向け開発チーム • プロダクトオーナー • エンジニア • デザイナー • プランナー toC向け開発チーム • プロダクトオーナー • エンジニア • デザイナー • プランナー toC向け機能 toB向け機能 インフラ・共通部分 Before マルチテナントな 単一のシステム
23. マルチテナントな 単一のシステム 23 統一開発チーム • プロダクトオーナーチーム • エンジニア • デザイナー • プランナー toC向け機能 toB向け機能 インフラ・共通部分 After スクラムを導入
24. ⏪ 🤔 ⚡ 🏃 スクラム試行錯誤 🍵 24
25. 最初はスクラムイベントを回すだけで精一杯 - スプリント計画、デイリースクラム、スプリントレビュー、ふ かえ …… - 教科書的なスクラム開発の経験が少ないメンバーもい 状態か スタート - スクラム的なや 方、あ いはアジャイル開発を全然やってこなかったわけではない - 概念の説明か キックオフ - スクラムマスターなんてやったことなかった - スクラムマスター経験者もチームにいなかった - 全体をリードしつつ、元同じチームのプランナー+元もう片方のチームのエンジニアとに手伝って も いなが 3人体制 25
26. 最初はスクラムイベントを回すだけで精一杯、だったが…… - “チェックポイント” をきっかけに変化を起こし続け ことができた - チームでや もの - スプリントふ かえ - 個人的なもの + スクラムマスターとしてのチェックポイント - 3人のスクラムマスターズでの会談 - すくすく開発会 (アジャイル大好き横串組織) の定例 - (自分とメンターとの) 1on1 - 今もできてい - スクラムマスターとしてのチェックポイントがあったのが かった - チームのふ かえ で取 入 問いかけの視点を仕入 た - 「スクラムマスターは孤独」と く言わ が、孤独にな にくかった。新米なのでなおさ 26
27. 数スプリントやってみて - 当時進行中だったタスクやプロジェクトを新生プロダクトバックログにと あえ ず載せていった状態か スタート……して、 - どうな か 27
28. 数スプリントやってみて - 当時進行中だったタスクやプロジェクトを新生プロダクトバックログにと あえ ず載せていった状態か スタート……して、 - どうな か → スプリントバックログが捌けき ない - 最初はタスクの見積も もなかったので、全体でど く いの終わってなさなのかがわか ない - デイリースクラムなどでチームの枠を超えて毎日会話でき のは良い ね、と いった雰囲気はあった 28
29. バックログリファインメントの導入 - 既存のissueの見積も か 始め、徐々に新たなタスクの分解・リファインメント や見積も に進んだ - 最初はめちゃくちゃ時間がかかっていた - ドメイン知識の分布に偏 があ - タスクの説明文や完了の定義が不十分 29
30. バックログリファインメントの導入 - 既存のissueの見積も か 始め、徐々に新たなタスクの分解・リファインメント や見積も に進んだ - 最初はめちゃくちゃ時間がかかっていた - ドメイン知識の分布に偏 があ - タスクの説明文や完了の定義が不十分 - 見積も が進んだことで、スプリントバーンアップチャートを引け うに - スプリントバックログの溢 具合が定量化+可視化さ - バーンアップチャート以外にもいいことがあった - 完了の定義を開発メンバー全員で練 ことで、施策の実装着手後の手戻 が激減。 分か ていたチームを統合したメリットも感じ 30
31. 余白を生み出す - なぜ余白が必要なのか - 不慣 な領域で見積も の予想が外 ことが結構あった - 知識の相互伝授のためにもペアプロ・ペアオペを積極的に勧めたい - 障害対応など差し込みの対応が必要なタスクをゼロにでき わけではない - 意識しないと余白が生ま にくい構造だった - 複数プロダクトを単一のプロダクトバックログで管理 - 優先度・着手順の判断がとても難しい - スプリントゴールの規模や項目が増えがち - 余白のなさ・溢 具合は可視化でき うになっていた - スプリントゴールを思い切ってめちゃくちゃ絞 と……達成に近づけ - が、絞 のが難しい! 31
32. スプリントゴールを明確にす ための議論を促す - スプリントプランニングのなかでスプリントゴールについて議論しやすくす た めに、POに以下のことをお願いした - スプリントゴールのwhy的な情報をな べく説明しても うこと - そ ぞ のゴールの項目同士の優先度をな べく付けても うこと - 議論をす ことで、スプリントゴールを明確にしたかった - 明確なほうが量のイメージも湧きやすいはずで、結果的に適切なボリューム感のゴールを設定す ことにもつなが ないか 32
33. スプリントゴールを明確にす ための議論を促す……と - 「このタスクはゴールに含ま ますか？」 - 「入ってないとマズいのでゴールの表現を変えないとですね」 - 「このタスクA もプロジェクトBのほうが優先度が圧倒的に高いけど、Aもこ こまでだった 次スプリントで進め ないか」 - 「今気づいたんですがこ もや ないとスプリントゴール達成できないのでや ます」 - スプリント中にこういう動きが生ま うになった - スプリントゴールの達成に向かってチームで動けてい 状態。最高 33
34. スプリントゴール達成 🎉 - 19回目のスプリントで初めてスプリントゴールを完全に達成 - ついこの前! - なにが良かったのか、あ いはこ までと違ったことはなにか - スプリントゴールが十分明確になっていて、見通しも正確だった？ - スプリントゴールを十分絞 ていた？ - 十分な余白を確保できていた？ - 当時着手していたプロジェクト (の技術な ) についての理解が深まっていた？ - POの認知負荷も下がったことで割 込みタスクの優先度を判断しやすかった？ - まだ再現を積み重ね ていない 34
35. ⏪ 🤔 ⚡ 🏃 🍵 ふ かえ 35
36. 1年間をふ かえって - 👍 日々の開発は以前 もうまく回 うになってい - Findy Teamsでい い トラッキング - スクラム導入後は変更のリードタイムが以前 低い水準 (ざっく 数分の一) で安定 - 👍 改善のサイクルが回 うにもなってきてい - スプリントふ かえ の時間が足 なくて困ってます…… - 💪 スクラムの型の意義を実感す タイミングが多い (個人の感想) - 💪 チームの構造を変えたか といって、直ちにそ がシステムのアーキテクチャ に反映さ ていくわけではない - Team Topologiesでいう“同形力" - 以前 も全体像が く見え うになってい 36
37. おわ に —— まとめ - ここ1年ではてなブログの開発チームの構成を見直し、スクラムを導入しました - 導入後もチームの改善を続け ことができています - 現状を分析し、理想と、理想への近づき方を考え、実践していくうえで 「DMM本」を起点に深堀 していった知識がとても役に立ちました - ぼんや していた課題感を分解す とこ か 辿ってきて今 - というか、そもそも課題感を植え付け たきっかけでもあ - タイミングもあ 、この本と出会ってなかった 絶対こうはな なかった - いプロダクトをお届けでき うにこ か もやっていきます 37