Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”（前編）。Developers Summit 2016

2016年3月7日

変化の速いビジネス環境に対応するために、多くの企業がアジャイル開発の採用を進めています。

本記事では、2月18日に行われたDevelopers Summit 2016のセッション「現場から変えた”サービスの作り方” ～何を作るのかではなくなぜ作るのか～」で紹介された、Yahoo! Japanにおけるアジャイル開発の導入と実践、そして改善がどのように行われたのかについての内容を記事にしました。

現場から変えた“サービスの作り方”

ヤフー株式会社システム統括本部技術支援本部　荒瀬中人（あらせなかと）氏。

ヤフーでは、アジャイル開発実践中の開発チームの大多数がSCRUMを採用しています。SCRUMはフレームワークが明確なので、未経験者でも導入しやすく、効果が出やすいのです。

また、組織体制の特性もあります。

ヤフーは職種に関係なく1プロダクト単位で少人数のチームを構成しています。そのプロダクトチームは、プロダクトの立案から開発、運用まで行います。その権限や裁量もすべて持っています。

こうしたスモールチームであることも、SCRUMに適応しやすい理由です。

ここでのアジャイル開発の話は、SCRUMを利用した開発だと思ってください。

SCRUMの普及活動は落ち着き、改善活動に

ヤフーでは、ものづくりにたずさわるメンバーの48.3％がアジャイル開発を経験しています。

これはちょうどレイトマジョリティにさしかかっていて、普及活動はいったん落ち着き、現在は改善活動に取り組んでいます。

こういった背景を踏まえて今日お話しするのは、われわれが現場に入ってアジャイル開発の普及や支援活動をしていた頃の話と、それを改善していく現在とこれからの取り組みについてです。

まずは、アジャイル開発チームの変化について。

アジャイル開発を導入する前は、プロダクトマネージャーと開発チームは分かれていました。プロダクトマネージャーが開発を依頼し、開発チームが作るという関係でした。

アジャイル開発では、同じチームとして、なにを作るか、どう作るかを一緒に考えます。すると、なぜそのプロダクトを作るのか、プロダクトの価値まで考えるように変化します。するとチームでプロダクトマネージメントをするようになります。

アジャイル開発でチームが変化する

この変化がどのようなステップを経て起こるのか、実際に私が現場でサポートしたチームの事例をお話したいと思います。

変化は4段階のステップがありました。

1つ目の変化は、チーム状態の可視化です。

アジャイル開発を導入する前は、担当者ごと、または職種ごとに担当が固定されていました。このような体制では、チームメンバーは自分のコンポーネントに関する進捗や作業だけを気にし、全体の進捗はそれほど気にしません。

しかしアジャイル開発では全員がすべてを把握するクロスファンクショナルチームとなります。優先順位の高い要件にメンバー全員で取り組みます。

すると、いままでここの作業として可視化されていなかったことを、どんどん可視化するようになります。

全体の作業の進捗や結果も可視化されます。これが最初の変化です。

開発サイクルが速くなる

続いて2つ目の変化。

可視化の次に現れるのは、開発サイクルの安定です。

SCRUMでは、開発サイクルの期間を固定します。私がサポートしているチームは、だいたい1スプリントあたり1週間から2週間のサイクルが採用されています。

このスプリントを採用することでチームは開発スタイルを模索するようになります。

それは、前と比べてどんな無駄があるか、まず無駄が目立つようになります。そしてそれをそぎ落とそうとします。

無駄とは、例えば営業や広報といったステークホルダーとのミーティングが行われたりしますが、こうしたミーティングの調整には手間が掛かるので、じゃあレビューは決められた日時に行っているので、そのときにみんな呼んでしまおうとか、依存タスクで誰かの仕事を待っているのとをなくそうとか、あるいは見積もりをやりすぎるので粒度を見直すとか、そういった改善をするようになります。