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

2016年3月7日

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

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

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

SCRUMを導入するときにサポートすること

私たちがアジャイル開発をサポートするときに気をつけたりしているポイントなどを紹介します。

私たちのサポートは、大きく分けて導入のサポートと実際に改善するときのサポートの2つです。

導入サポートについて。

まず、セミナーや勉強会など、SCRUMってなんですか、なにができるのですか、などを体験してもらったりします。

次にチーム設計で役割やル―ルなどを決め、スプリントを始める前に、中長期の計画を作ります。

そしてもっとも力を入れるのが、目指すチーム像の決定です。

理想のチームはどういうものか、理想のチームにあったゴールとはどういうものか。これを考えないと、チームの改善がどこへ向かっているのか分からなくなる。

また、メンバー同士はなにを期待しているのか、どういうスキルがあって、こういったことが貢献できますとか、私はこういう成長がしたいですとか、どういうマインドを大事にしているのか、といったことをすり合わせます。

ここですりあわせをしないと無理な期待がかかったり、無理な作業が発生したりするので、無理なく成長しゴールを迎えるチームになるために必要です。

これらがSCRUM実践前に私が行うサポートです。

SCRUM実践時にサポートすること

次が実践です。やってみましょうと言われても、最初は戸惑いますよね。

まず私がSCRUMマスターを代役でやって、基本的なルールや流れをチームに理解してもらいます。だいたい2から4スプリント、1～2カ月くらいです。

そのあとはそのチームのSCRUMマスターと定期的に1オン1をして、チームにどういう課題があって、どう取り組むのかといったことを中心にコーチングします。これがだいたい1スプリントに1度、30分から1時間くらいです。

私が大事にしているポイントは、とにかくストレスを軽減することです。

アジャイル開発を導入すると、開発プロセスががらりと変わります。働き方が変わることもあります。こういうのはすごくストレスがたまりやすくなる。

チームの中にも、アジャイル開発をやりたい人、やりたくない人、どっちでもいい人、いろいろあります。そういった感情にも配慮しながらサポートします。最初からがっちりとルールの中でやる、というのではありません。

アジャイル開発を改善していく

アジャイル開発を改善する際のサポートについて。

すでにアジャイル開発を実践しているチームでサポートする場合には、私の観点でのボトルネックや、チームの改善に向かうルールなどについて見ています。

そしてSCRUMマスターと1オン1で課題やチーム状況の確認、チームの成長の確認、理想のチーム像が変わってないか、ちゃんとアジャイル開発ができているのか、といったことを確認します。

依頼されれば、例えばMVPをどう決めていいのか分かりませんとか、チームの理想の姿が変わってきたので会議をしたい、といったときのファシリテートも行います。

ここでの実践中のチームに対する私のポイントは、正しいSCRUMを実践しているか、目指したい姿に向かっているか。こうしたことに向かって成長を促しています。

アジャイル開発を導入した頃は、不慣れなことが多いので改善するべきことが分かりやすく、よく目に付きます。ですので成長を実感しやすい。

しかし慣れてくると大きな改善がなくなってきてマンネリ化します。

すると、チームの成長が止まってきます。すると、ルールを守ることやSCRUMを実践することそのものが目的化してしまいます。

ですので私のポイントは、まず成長、そしてゴール、この再認識です。その目的を達成するためのテクニックだったり事例であったりします。

組織改善についての取り組み

ここからは、アジャイル開発に関する組織改善の取り組みについてです。

まず組織の課題ですが、ひとことで言うとアジャイル開発の形骸化です。

実戦経験者が48.3％もあると、きちんとやっているチームもあれば形骸化しはじめているチームもあります。

SCRUMの実践を目的とし、ルールを守ることにフォーカスしてしまい、本来解決すべき課題を許容してしまっている。目先の課題を解決するだけで本質的な課題を解決しない。

SCRUMマスターは割と先を見て欲しいのですが、開発チーム内で牽引していることも多く、短期的な課題を許容してしまうチームも散見します。

また、そもそもアジャイル開発を正しく実践しているかわからない、というところもあります。これが分からないと、サポートが必要なのに気付いてもらえないチームがあるかもしれませんし、このチームのアジャイルはこうだからといったオレオレアジャイルが蔓延して、正しくやっていないので効果を感じられず、アンチアジャイル開発になっていないかとか。