Yahoo! JAPANトップページにおける KanbanとXPの運用と定量可視化 金田雅史 / ヤフー メディアグループメディア統括本部開発1本部 エンジニア

• 自己紹介 SIerや社内SE、ベンチャーを経て2012年Yahoo! JAPAN入社。 2013年よりトップページの開発を担当、2015年のトップページの刷新にも携わる。 管理職なども経験しながら主にKanbanを用いた開発組織やプロセスの改善を展開。 2017年にPivotal Labs社(現Vmware Tanzu Labs)にてXPのトレーニングを受けた後、 Yahoo! JAPANアプリやスマホブラウザ版のYahoo! JAPANトップページでKanbanとXPを組み合わせた 組織・プロセスの改善に従事。 現在はY!天気・防災にて改善を展開中。尊敬する人は大野耐一。

Smartｐhone向け Yahoo! JAPANトップページ Smartｐhone Web Yahoo! JAPAN App Android iOS

• トップページは様々なサービスの持つコンテンツを扱う • 多くの機能開発を並行して行うため、大規模な開発体制が必 要 • 対象となるビジネス領域や競合が幅広くならざるを得ず、環 境変化が非常に激しい • 検索も天気もニュースもタイムラインも同時に戦わなくてはな らない • 単機能のアプリより、競合や市場の動きに機敏に対応する必 要性が高い • 多くのユーザーに利用いただいている • 安心、安全を守るため、高い品質を維持し続けることが必要

• YJアプリ・SPwebトップで共通デザインを採用している • より便利で多くの機能を提供するため、アプリでの利用をお勧 めしている • 移行するにあたって、ユーザーの違和感を小さくしたい • 同一機能をプロダクト横断で開発することが多いので、プロダ クト毎でなく領域を単位にマネジメント体制を敷いている

かつて、プロダクト/領域毎に開発チームが担当していた • 領域ごとの優先順位で開発が行われる • プロダクト全体ではもっと先に世に出したいものがある • 個別最適になりがち • 状況変化により特定の領域で集中的に開発が必要になる • 他チームからヘルプに入る • ヘルプを出したチームは開発ができず休業状態 • 全体最適での優先順位判断に • 柔軟に優先順位の変更が可能な開発フロー • ヘルプを受け入れられる、スケールアウト可能な体制

カンバン方式導入 カンバン方式(Kanban) • トヨタ生産方式を源流とするプロセス管理手法 • 主なルールは2つ • 作業の仕掛り数を制限する • 仕掛りに空きが出たら、あらかじめ決められた優先順位に基づき次の作業をPULLする • スクラムも検討したが、状況変化が大きく、スプリント中の変更が不可避

開発体制・フロー

開発体制・フロー

• 領域を横断して、プロダクト全体で一つのBacklogを管理 • 優先順位を一意に決定する • 各領域の責任者が集まって説明・判断する場を毎日設定 • 未着手のものの優先順変更は毎日でも歓迎

• 職能横断型のスモールチーム • アプリ • iOS・Android・Backendの各エンジニアの参加するチーム • 1チームに各技術領域2〜3名、合計8名前後 • チームの判断にビジネス観点を取り入れるため企画職もオーナーとして帯同 • チーム横断での開発方針統一などのため、技術領域毎にTechLeadを設置 • SPweb • 基本的に全エンジニアがFrontendからServerSideまで対応可能 • 1チーム5名前後

• Pull型ワークフロー • 手の空いた開発チームが原則Backlogの上からPull

全体をカンバンで可視化 • 開発プロセスごとにステージを分割 • プロダクト全体を俯瞰するカンバンと、各チームの作業用カンバンの2段構成

• ステージ例 ՝୊ ேձͰ࿩୊ʹ্͕ͬͨվળ఺ͳͲΛϝϞͱͯ͠࢒͢ #BDLMPH ৽ن௥Ճ ৽͘͠௥Ճ͞ΕͨΧʔυɻேձͳͲͰ಺༰Λڞ༗্ͨ͠Ͱಈ͔͢ 5P%P ௚ۙணख͢΂͖Χʔυɻ্͔Β༏ઌॱҐॱ ෼ׂ ࡞ۀத νʔϜ͕1VMMͨ͠Χʔυͷ෼ׂΛߦ͏ ௥੻ νʔϜ֎ͷཁҼͰ଴ͪͱͳ͍ͬͯΔΧʔυஔ͖৔ɺఆظతʹঢ়گͷ࠶֬ೝΛߦ͏ 3FBEZ ෼ׂݩ Χʔυ෼ׂલͷ਌Χʔυ ෼ׂޙ Χʔυ෼ׂΛߦͳͬͨࢠΧʔυ ࣮૷ ࡞ۀத νʔϜ͕࣮૷ʹணख͍ͯ͠Δ΋ͷ ௥੻ ׬ྃ ࣍ͷεςʔδʹ1VMM͞ΕΔͷΛ଴͍ͬͯΔঢ়ଶͷ΋ͷ ݁߹ࢼݧ ରԠத ݁߹ࢼݧ࣮ࢪதͷ΋ͷ ׬ྃ ϦϦʔε ࡞ۀத ϦϦʔεલͷ࡞ۀʹೖͬͨ΋ͷ ׬ྃ ϦϦʔε͕׬ྃͨ͠΋ͷ ϦϦʔεޙ࡞ۀ υΩϡϝϯτ൓өͳͲͷ࡞ۀ͕࢒͍ͬͯΔ΋ͷ ׬ྃ શͯͷλεΫ͕׬ྃͨ͠΋ͷ

コロナ以前は付箋を使ったアナログ • 壁面を埋め尽くす巨大なもの • 一覧性や情報発散性が非常に高い • カンバン前で考えていると会話が生まれたり • メトリクス集計の自動化のためデジタルカンバンもデジタルツインとして並行運用 • コロナ後 • デジタルカンバンをメインに切り替え、大きな混乱なく移行できた

XPの導入 • 開発スピードと品質を両立するため、Pivotal Labsにて習得したエクストリームプロ グラミング(eXtreme Programming:XP)を導入 • 代表的なプラクティス • ペアプログラミング • Productionにリリースされるコードはペアプログラミング必須 • チーム内でペアは原則毎日ローテーション • 継続的インテグレーション(Continuous Integration:CI) • ペア交代のため、コードは必然的に毎日コミット・Push • テスト駆動開発(Test Driven Development:TDD) • まず失敗するユニットテストを書く(RED) • ユニットテストをパスする最小限の実装を書く(GREEN) • GREENを維持したままリファクタリングを行う • この3サイクルを小さく速く繰り返していく

メトリクスの利用 カンバン上のカードを分類した上で、カードの動きのログデータを蓄積し、BIツールを用 いて自動で集計。様々な判断に用いている • ツール • 入力：Github Project、Trelloなどでカンバン構築 • 変換：APIからデータを抽出しMySQLなどRDBへ登録 • 分析：Tableau、SupersetなどのBIツールで可視化

カードの分類 分析する上でカードをいくつかの種類に分類している • ビジネス • ユーザーに直接価値を提供するもの • 技術改善 • 価値提供に間接的にプラスに貢献する。受益者は主に社内。現状からプラスにする • 保守運用 • やらないことで起こる将来的な価値提供の毀損を回避する。現状を維持する • 事故/不具合/失敗 • 既に起きている価値提供の毀損を回復するもの。マイナスを回復する

Tシャツサイズ見積 見積は2段階 • Tシャツサイズ見積 • あくまで着手可否・優先順位判断のためだけのもの • 正確さより簡便さ・迅速さ優先のため、これをもってのスケジュール策定などは禁止 • 着手できるかわからない案件にエンジニアのリソースが割かれるのを避ける • 詳細見積 • 開発チームがPull後に詳細を詰めて、スケジューリングなどを行う • Tシャツサイズ見積 • S： 1人週以下、1ポイント • M： 1〜2人週程度、2ポイント • L： 3〜4人週程度、4ポイント • XL： 1人月以上、8ポイント XL以上のものはL以下へ分解推奨

メトリクスの分析・利用 メトリクスを分析し、以下のようなものを利用している 例 • 案件分類比率 • 着手/完了/仕掛りのカード数・ポイント数 • 中長期見通し • マイルストン見込み

案件分類比率 • 完了したカードの案件分類ごとの比率 • 前期実績や今期経過を比較 • ビジネスに偏っていないか、技術改善が行えているか • 保守運用が肥大化していないか • 事故/不具合/失敗が増えていないか

着手/完了/仕掛りのカード数・ポイント数 週毎や日毎の新たなカードの着手数、完了数、仕掛り数、およ びポイント数 • 着手は多いが完了が少なく、仕掛りが増加 • PullよりPushになっていないか？ • 完了が多いが着手が少なく、仕掛りは減少 • 着手可能な案件が減っていないか？ • 着手・完了ともに安定しているが、仕掛りも多い • 並行稼働が常態化してリードタイムが延びていないか？ • 着手・完了ともに多く、仕掛りは安定して少ない • これを目指したい

中長期見通し • 前期や先月の完了・追加ポイント数より計算 • 達成率:一定期間での完了ポイント数を営業 日数で割ったもの • 追加率:一定期間での追加カードのポイント 数を営業日数で割ったもの • 今期どのぐらいの案件をこなせそうかの目安 計算 • ビジネス目標や必須の保守運用の戦略的な 優先順位判断 • 着手される見込みの無い案件への計画コス トを避ける

マイルストン見込み • Tシャツサイズ毎の平均リードタイムと、チームが同時に持てるカード数から試算 • チームの稼働に無理は無いか • どの案件がいつ頃終わりそうか • 平均値を元にしているので、大きく前後する可能性がある • あくまで目安なので、これを元にスケジュールを組むのは禁止 • 案件の期限を満たせそうか • 期限を満たすための着手順 • 差し込みでこれをやったら、何ができなくなるか

まとめ • カンバンと、スモールチームでのPull式ワークフローにより、優先順位の変更やチー ムのスケールアウトなど、変化に迅速・柔軟に対応できる体制を構築している • XPのプラクティスにより、開発のスピードと品質維持を両立している • カンバンのカードを分類し実績データからメトリクスを自動算出することで、プロセス の健全性やチームの状況、リソースの配分、着手時期の予測などを可視化し、客観 的な情報を元にプロダクトの判断を行うことができる

参考文献(英語) • Lean from the Trenches ~Managing Large-Scale Projects with Kanban~ • https://pragprog.com/titles/hklean/lean-from-the-trenches/ • Kanban in Action • https://www.manning.com/books/kanban-in-action • Agile Project Management with Kanban • https://www.microsoftpressstore.com/store/agile-project-management-with-kanban- 9780735698956 • Extreme Programming Explained: Embrace Change, 2nd edition • https://www.pearson.com/store/p/extreme-programming-explained-embrace- change/P200000000118/9780321278654 • Planning Extreme Programming • https://martinfowler.com/books/pxp.html • Kanban and Scrum - Making the Most of Both • https://www.infoq.com/minibooks/kanban-scrum-minibook/ • Scrum and XP from the Trenches - 2nd Edition • https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2/

参考文献(日本語) • リーン開発の現場 カンバンによる大規模プロジェクトの運営 • https://ebookjapan.yahoo.co.jp/books/470113/ • カンバン仕事術 • https://shopping.yahoo.co.jp/products/a94a22f8e0 • 今すぐ実践！ カンバンによるアジャイルプロジェクトマネジメント • https://ebookjapan.yahoo.co.jp/books/372241/ • エクストリームプログラミング • https://ebookjapan.yahoo.co.jp/books/443834/ • ・XPエクストリーム・プログラミング実行計画 (The XP Series) • https://www.amazon.co.jp/dp/4894713411 • かんばんとスクラム 両者のよさを最大限ひきだす • https://www.infoq.com/jp/minibooks/kanban-scrum-minibook/ • 塹壕より Scrum と XP • https://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches/