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

2016年3月7日

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

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

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

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

fig

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

fig

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

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

fig

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

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

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

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

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

fig

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

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

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

fig

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

fig

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

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

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

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

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

fig

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

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

fig

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

開発サイクルが速くなる

続いて2つ目の変化。

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

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

fig

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

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

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

fig

無駄をそぎ落とすことによって、いびつな開発サイクルがきれいなサイクルになり、リズムをつかみ始めて開発サイクルが速くなる。これが2つ目の変化です。

チームが自律する

続いて3つ目の変化です。

チームの状態を可視化し、無駄をそぎ落としたあとの変化では、チームが自律します。

自律したチームとは、チーム自身が課題を見つけてチーム自身が改善し、チームの成長にチームが責任を持つ。これが自律したチームだと私たちは呼んでいます。

fig

開発サイクルが安定すると余裕が出てきて、それまでは個人の改善だったのが全体に目が行くようになり、視線が全体に広がると、チーム全体の改善に向かいます。

そうするとチームのスキルや生産性向上、プロダクトの品質といったことに目が行くようになります。

チームがプロダクトマネージメントをする

最後の、4つ目の変化です。

これはプロダクトマネージメントです。

プロダクトオーナーは、ユーザーが誰か、ユーザーの抱える課題とはなにか、そして課題を解決することによる価値を話します。

そしてスプリントごとに、ユーザーの課題を解決しているか、価値を満たしているか、といったことをレビューします。

fig

これを繰り返すことで、開発チームはプロダクトオーナーの映画居ているビジョンを共有するようになり、じゃあこうしたらいいのではと、開発チームもアイデアを出すようになり、プロダクトオーナー視点でものづくりをするようになります。

fig

すると、ただ要件を満たすのではなく、ユーザーの課題を解決し、価値を高めるにはどうすべきかを考えてものづくりをするようになります。

これがチームがプロダクトマネージメントをするということです。

アジャイル開発を進めていくと、最後はこのようになります。

≫続く後編では、アジャイル開発を実践している中でどのように改善していくかについて紹介しています。

Developers Summit 2016

あわせて読みたい

DevOps アジャイル開発 スクラム Yahoo!




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本