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

2016年3月7日

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

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

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

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

fig

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

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

導入サポートについて。

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

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

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

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

fig

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

fig

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

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

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

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

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

fig

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

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

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

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

fig

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

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

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

fig

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

fig

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

fig

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

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

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

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

fig

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

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

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

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

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

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

fig

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

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

fig

そういった現状に対して、現在の取り組みとこれから取り組むものについて。

1つは社内でアジャイルコミュニティを立ち上げました。アジャイル開発に興味があるとか勉強する意欲があるとか、組織全体に対していい影響を及ぼしているメンバーがいると、その人をコミュニティに誘って一緒にアジャイル開発を推進しています。

fig

そしてメンバーと一緒に社内の情報収集やイベント、研修などをして、社内全体の底上げをする。

SCRUM説明会とか事例紹介とか、うまく行っているチームはどうやってるかとか。

ワークショップでは、体験型でものづくりをしながらSCRUMの原理原則や軽いルールなどを体験してもらっています。

また、いまは新卒が入社すると、SCRUMを用いた研修を必ず行っています。

fig

これから取り組もうと企画しているもの

これから取り組もうと企画しているもの。

1つはチーム評価アセスメントです。チーム自身がチームを評価する。私たちはそのお手伝いをする、という方向に向かっています。

そのために、分かりやすく可視化できるようなアセスメントを企画中です。例えば、チームは自律しているか、中長期の計画は見積もられているか、品質は随時見直されているか、など。

fig

もう1の計画つは、コンテンツ配信です。アジャイル開発のTIPSや、みんなが呼んでくれそうなマンガで分かる記事などです。

最後に

私たちの目指すところは、世の中にはいろんな開発手法があります。その中の1つとして、アジャイル開発の実践が求められたときに、すぐに選択し、実践できるような組織です。

fig

公開されているスライド。

現場から変えた“サービスの作り方” -何を作るのかではなくなぜ作るのか- #devsumi from Yahoo!デベロッパーネットワーク

Developers Summit 2016

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : アジャイル開発 , スクラム



≫次の記事
Docker、Apache Aurora開発者らのチームを買収。Swarmとの統合によるオーケストレーション機能の強化でMesosやKubernetesと競合する方向へ
≪前の記事
Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”(前編)。Developers Summit 2016

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


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



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus