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