Yahoo! JAPANトップページにおけるKanbanとXPの運用と定量可視化

Yahoo! JAPANのスマートフォン向けの「トップページ」は、スマートフォンのWebページ版、Android向け、iOS向けのネイティブアプリを用意しており、これらは非常に似通ったUIです。 トップページ全体の特徴は、基本となる検索機能のほか、天気やニュースなど多彩な機能を搭載し、非常に幅広いサービスを同時に提供しています。

これら機能を同時かつ多並列で開発し続けるためには、非常に大規模な開発体制が必要です。もちろん対象となるビジネスの領域も幅広く、競合他社の動向や市場環境の変化を迅速に捉え、柔軟に対応することも求められます。

玄関口であるトップページは、日々たくさんのユーザーが訪問します。そのため、ユーザーの安心・安全を守る情報、例えば災害情報や地震速報などを素早く、正確に届ける必要があります。これも、トップページの特徴の1つです。

Webを使い慣れたユーザーにもアプリ版を違和感なく使ってもらえるように、デバイスを問わず共通したUIを用いています。

Kanbanとスモールチームでプル式ワークフローに

機能開発に取り組む際は、iOSアプリ向けやAndroidアプリ向けという区別を設けず、共通の機能として横断的な開発を行っています。ただそこに至るまでは、開発体制をWebチーム、ニュースチームのように領域ごとに分けていたので、個別最適化を前提とした優先順位をつけがちなど、さまざまな課題がありました。

例えば、○○チームでトップページ全体として最優先で出したい機能開発があったときに、XXの開発をいったんストップさせるといったこともたびたび起きていました。そのため、全体最適での優先順位の判断が行えるほか、市場環境の変化にも柔軟に対応できる開発フロー、そして突発的な開発案件への対応など、柔軟な組織体制の構築を目指す流れになりました。

その解決策として導入したのが、Kanban方式です。これはトヨタ生産方式を源流とするプロセス管理手法で、主なルールは2つしかありません。

1つ目のルールは、同時に取り掛かる仕事の数に上限を決めること。2つ目のルールは、前述の上限に対して空きが出てから新しい仕事をプルすること。プルする際は、その都度順番を決めるのではなく、あらかじめ優先順位を決めて順番に並べておくことが求められます。

開発体制やフローについて説明します。まず、ツールやタイムラインといった領域ごとにサービスマネージャーと呼ばれる責任者を立て、その中でプロダクトマネージャーや企画の担当者を決め、さまざまな改善の企画を検討します。

複数の領域で責任者が企画を出してきたら、それをプロダクト全体として1つのProduct Backlogで管理します。その際は領域を問わず1列に順番に並べ、優先順位を決めるために、毎日各領域の責任者、サービスマネージャーが集まって協議します。ここで並べた優先順位に関しては、チームが着手する前であれば、いつでも変更できるという柔軟性を持たせています。

一方、開発を実際に行うチームは、職能横断型のスモールチームとしています。アプリのチームだと、チーム内でiOS、Android、バックエンドのそれぞれのエンジニアが同時に在籍しています。1チームに各領域から2、3名を選出し、合計8名程度の人数です。ビジネス的な観点も判断の中に入れるために、エンジニアだけではなく企画職もオーナーとしてチームに在籍しています。また、チームごとに個別最適化しないように、チームを横断したTechLeadを配置しています。

スマートフォンのWebのチームであれば、フロントエンドからサーバーサイドまで全エンジニアが対応できる体制になっており、1チーム5名前後で構成されています。 これらのチームにプル型のワークフローを適用させ、1つのタスクが終わって手が空いたら次のタスクを上から順番に取ってくる方式にしました。 また、状況がどう動いているのかを全員がすぐに把握できるように、Kanbanで可視化を行っています。

Kanban方式の場合は、プロセスごとに細かくステージを分けたKanbanを用いることが多いです。下図はプロダクト全体としての横断的な全体Kanbanです。それに加え、各チームの中でより細かい作業の進捗を分解したチームKanbanの二弾構えでの構成となっています。

プロセスごとに細かく分けたステージについていくつか紹介します。

• 課題
  朝会などで改善のアイデアが出たときにメモを残します

• 新規追加
  新しく追加されたカードを決まった場所に置くことで、チーム全体に内容を説明・共有します

• 分割
  カードの粒度が大きすぎる場合に細分化を促します。

• 追跡
  ほかの部署の作業を待っている際はこのステージにカードを置いて、現状を報告するとともに、定期的に状況を確認できるようにします。

• リリース後作業
  リリース後にやらなければならないタスクを忘れてしまわないように設けています

コロナ禍以前は付箋を用いて、壁一面を埋め尽くすほど巨大なKanbanを作っていました。アナログなKanbanは、パッと見てどこに何があるか分かりますし、Kanbanの前でチケットを見ながら考えていると声がかかって、そこから議論が生まれるような情報発散性と呼ばれる効果もありました。

しかし、どのカードがいつ動いて、いつ終わったか、平均のタイムはどのぐらいだったのか、ということを計算するのは手動では難しいという課題がありました。それを解決するために、アナログのKanbanをそっくりそのままデジタルツインとして複製したデジタルKanbanを裏で運用していました。

そんな中、コロナ禍となり、ヤフーでは基本的に出社をしない方針になりました。これをきっかけに、裏で運用していたデジタルKanbanをメインに切り替え、働き方が変わってもスムーズに開発体制が維持できました。

XPのプラクティスを用いて開発のスピードと品質の維持を両立

冒頭でもお話した通り、Yahoo! JAPANトップページには非常に高い品質を求められるのと同時に、競合他社と闘えるほどのスピード感も要求されます。この2つを両立するために、私たちはXP（エクストリームプログラミング）を導入しています。

エクストリームプログラミングには非常にたくさんのプラクティスがありますが、その中でも代表的なプラクティスは「ペアプログラミング」です。

私たちの場合は、プロダクションにリリースするコードは必ずペアで書かなければならないというルールを設けました。また、属ペア化を避けるという意味で、チームの中でペアは毎日ローテーションするというルールで運用しています。

継続的インテグレーション（CI）も非常に有名なプラクティスです。これは毎日コードをマージするというものです。毎日ペアをローテーションするためには、前日のペアで書いたコードを必ず他の人に共有しなければならないので、毎日コミット、プッシュが行われ、必然的にCIも行われます。

また、品質を維持する上で非常に強力なのが、テスト駆動開発です。まずは失敗するユニットテストを書き、そのテストを通る最小限の実装を書いてグリーンにする。そのグリーンを維持したまま、リファクタリングまで行う流れです。しばしば、実装やテストが終わってリリースまで完了した後に、リファクタリングをやろうとするケースが見られますが、実際にはこなせない場合も少なくありません。そのため、小さく早く繰り返していく開発サイクルを採用しています。

Kanbanのカードを分類し、実績のデータからメトリクスを自動算出

開発のフローの中で起きたメトリクスは、さまざまな場面で利用しています。

例えば、デジタルKanbanの上でカードの分類をしています。その上で、どのカードがどう動いたかというログをデータとして蓄積し、BIツールを用いて自動で集計する仕組みを構築しています。ツールとしては、現在はGitHubプロジェクトやTrelloなどを用いています。そこからAPIでデータを抽出して、MySQLなどのデータベースに格納をしています。そして、登録されたデータに対して、TableauやApache SupersetなどのBIツールを使って分析や可視化を行っています。

カードの分類について、2つ例を紹介します。

1つ目は、ビジネス、技術改善、保守運用、事故・不具合・失敗の4つに分類した「案件分類」です。

• ビジネス
  ユーザーに直接価値を提供するものです。

• 技術改善
  ユーザーへの価値提供に間接的に働くものです。現状の開発をプラスにするもの、例えばリファクタリングなど、私たち自身がよりたくさんの価値を提供するためにプラスとなるものを技術改善と呼んでいます。

• 保守運用
  怠ってしまうと将来的に価値提供が毀損する、またはサービスが維持できないといったことを避けるためのものです。

• 事故・不具合・失敗
  価値提供の毀損が起きてしまったときに、失ってしまった価値を回復するものというイメージです。

2つ目の分類は「Tシャツサイズ見積り」です。これは、社内で「規模感」や「超概算」と呼んでおり、見積が全体として二段階になっています。

最初に企画を検討している段階で出すものが、Tシャツサイズ見積りです。これはあくまでそもそもその企画を進めて良いのか、進めるとしたらどの順番でやるのかという、全体としての優先順位を判断するためだけに使うものです。

そのため、正確さよりは簡便さや迅速さを優先させており、後で変わる可能性も高いものなので、この数値を基にスケジュール策定をするのは控えるよう社内には周知しています。通常の詳細見積では、開発チームがプルした後にチーム間で詳細を詰め、そこで初めてスケジューリングなどを行います。

Tシャツサイズ見積りは、例えばSだと大体1～2人週以下、Mだと1～2人週程度、Lだと半月から1人月ぐらい、XLだと1人月以上のものという分類を使います。メトリクスの計算の際は、これらのサイズをそれぞれポイントに換算しています。例えば、Sを1とするとMはSが2つ分、LはMが2つ分、XLはLが2つ分といった具合です。XL以上のものは、スコープを刻みフェーズを分解できないかという調整を、前述の「分割」のステージで行います。

こういった分類を用いて、多角的にメトリクスの分析を行い、さまざまな判断に役に立てています。いくつか例を紹介します。

案件分類の比率

完了したカードのそれぞれの分類ごとの合計値を計算します。それが完了したカード全体の中でどのぐらいの比率なのかを計算して、前期と今期、あるいは先月と今月などで比較をして、どんな変化が起きているかを監視しています。

「ビジネス」に偏ってしまって「技術改善」を行えていない場合には、保守性に問題が発生することがあります。あるいは「保守運用」が非常に増えている場合には、技術選定として何か問題があるのかもしれません。

特に特に気をつけるべきは「事故・不具合・失敗」で、これは直接的に私たちの品質が低下しているアラートになるので、定期的に変化をレポーティングしています。

着手・完了・仕掛かりのカード数やポイント数

例えば、着手は多いが完了が少なく、その結果として仕掛かり数も増えている場合は、案件が終わっていないのに新たな案件をどんどんチームが取っているということで、プル型のワークフローではなくプッシュ型になってしまっていると予想されます。あるいは、どんどん完了しているが着手の数は少ない、仕掛かりもどんどん減っている場合には、実際に開発着手できるような企画がないという予想が立てられます。

着手も完了も安定しているけれど仕掛かりが多い場合には、いろいろな仕掛かりに着手する「つまみ食い」のようなスタイルが定着して、平均リードタイムが延びてしまっていないかと懸念があります。

こういったものが、プロセスの健全性として数値から読み取ることができます。最終的には着手も完了も多く、仕掛かりは安定して少ない状態を目指して、さまざまな改善を行っていきます。

中長期見通し

もう少し大きな視点、長い視点で中長期の見通しも定期的に算出しています。これは前期全体、あるいは先月全体といった一定の期間で、どのぐらいのカードのポイントが完了できているかという数字を計算します。その数字を営業日数で割ったものが、営業日数当たりの完了できるポイント数になり、達成率として算出できます。どのぐらいのカードが追加されるのかを営業日数で割ったものが追加率と呼ばれる数字です。

この2つの数字から、特定の期間にどのぐらいのカードが追加されてどのぐらいのカードが完了になっているか、その結果、予定されていたリストの中のどこまで終わりそうかといった、おおまかな見込みを立てることができます。それによってさまざまな判断をすることが可能になります。例えば、リストの下部にある着手の見込みがなさそうなカードは企画や実装準備のコストは取らないという判断にもつなげることも可能です。

マイルストーン見込み

短中期的なマイルストーンの見込みを作る場合もあります。Tシャツサイズごとに、Sならどのぐらいの平均リードタイムで終わっているかを都度計算し、その平均リードタイムとチームが同時に持っているカードの仕掛かり数の平均値から、どの案件がいつ頃終わりそうか試算を出すことができます。それによって、案件の期日を満たすのとチームの稼働状況を並立させるための試算を行っています。

まとめ

Yahoo! JAPANトップページでは、Kanbanとスモールチームでのプル式ワークフローによって、優先順位の変更やチームのスケールアウトなど、変化に対して迅速かつ柔軟に対応できる開発体制を構築しています。

また、XPのプラクティスを用いることで、開発のスピードと品質の維持を両立しています。

さらにKanbanのカードを分類し、実績のデータからメトリクスを自動算出して、そこからプロセスの健全性やチームの状況、リソースの配分、着手時期の予測などを可視化し、客観的な情報を基にプロダクトとしての判断を行えるような基盤を構築しています。

参考にしていただけたら幸いです。

アーカイブ動画

Apache®, Apache Superset ™及びSupersetのロゴは、米国および/またはその他の国におけるApache Software Foundationの商標または登録商標です。