アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（後編）。QCon Tokyo 2014

4月30日に都内で開催されたイベント「QCon Tokyo 2014」では、サイバーエージェントのアメーバ事業部が混乱の中からどうやってスクラムを導入してきたのか、その経験とそこで得られた知見が語られています。セッションの内容をダイジェストで紹介しましょう。

（本記事は「アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（前編）。QCon Tokyo 2014」の続きです）

アジャイルを組織に浸透させるTips

ここまでの経験で、アジャイルを組織に浸透させる上でのTipsを紹介したいと思います。

まず、組織を丸ごと変えてやる、と気張ってしまうとやはりだめです。

無理矢理「君たち全員アジャイル開発を始めよ」と言って始めるのは、そもそも自律的な組織ではありません。アジャイル開発をするには自律的な組織にならないといけなくて、自分たちで改善案などを出していかなければなりません。そのためにはアジャイルをやれ、とは言えない、という禅問答のようになってしまうのをどうにかしなければいけません。

どうすればいいかというと、真似されることによってアジャイル開発の自律的な浸透を促すと。結局のところ、いいものを取り入れようという気持ちがそれぞれのプロジェクトにはあるので、それを実現できるような組織や環境を作る。これいいよね、ということがどんどん言えるような環境にする。そうすることで真似しやすく、自然と自律的に浸透していくことを促す、というのがいいのではないかと思います。

それから、組織の目標とアジャイル開発が競合するという課題もありますね。一方でアジャイル開発をしましょうというときに、それが数値目標に対してどれだけ貢献するかは説明しにくい。

エンジニア目線では、自律的な改善を促せますと言えても、それでプロジェクトが成功するとは言えません。

そこで成果を最大限にするための優先事項との折り合いがやはり必要です。どう折り合うか、いろんなパターンを1つずつ試すのがいいかなと思います。

1つ目のパターンは自動化です。Jenkinsを使った自動ビルドや自動デプロイ。サイバーエージェントではほとんどのプロジェクトで導入済みです。これは組織的にもエンジニア的にも評価しやすいものでしょう。

次はチーム内での分割です。1つのチーム全体でスクラムによる管理がうまくいかない場合があったりします。人数が多すぎたりする場合があるためです。そこでチームを分けて、たとえばデザイナーやイラストレータの作業はカンバンで管理する、エンジニアはスクラムで管理して、あいだに人が入ることで全体のスケジュール管理を行うこともあります。

あとはタスクの粒度とWIP（Work in Progress：仕掛かり）の制限という方法もあります。これはスクラムでストーリーを並べてスプリントを開始したあとの話になるのですが、優先度が高いものからやっていくときいに、進行中のタスクの生存期間を1日に設定して、1日で終わらせることができる粒度にしましょうと。

そうすることで、翌日の朝会でそれが終わっていなければ何らかの問題があることがすぐに分かります。そうしたらその場で粒度について議論したり、問題の改善について議論してプロジェクトに反映させたりします。

ストーリーの直列化というのもあります。普通だとストーリーを用意したらこれを完了に持って行くために作業をするわけですが、そのストーリーの並列着手をやめるというチームがありました。

具体的にはチーム全体でみんなの役割を決めて1つのストーリーに着手し、終わったら次のストーリーに移る、というものです。不安や悩みはその場で相談、解決したり、ペアプログラミングを導入するなどをしています。一人だけ終わらなかったら、その人だけ残って他の人は次のストーリーに移るというパターンが有効だったチームもありました。

もっといろんなパターンがあると思いますが、それぞれチームになじむもの、なじまないものが絶対にあります。あちらのチームでうまくいったので、こちらでも取り入れましょうというときに、メンバーやプロジェクトの温度感や経験値だったり、いろんなものが複雑に絡み合ってうまくいかないパターンもでてきます。

そこで無理してなじませるのではなく、有効なものは取り入れて、そうでないものはきちんと捨てていきましょう。

成果目線で最適な方法を取り入れる

まとめです。

Amebaのスクラムの歴史はカオスから始まりました。

スクラムの採用が始まったのは、人数が増えてあちこちでうまくいかなくなり、その対策として。それを別のチームが真似することによって、スクラムやアジャイル開発が組織に浸透しはじめました。

成果目線で、各チームが最適な開発の方法を取り入れていき、改善をしています。

会場との質疑応答

質問　真似をしてスクラムが浸透するときに、各プラクティスを我流で真似てしまって効果が生まれなかったり、自律的でなかったりして失敗例になるリスクがうちの会社で起き始めているのですが、どのように最低限守るべきものを守ってよりよく広めていく方法があれば、ぜひ共有してほしい。

回答　プロジェクトが成功したかどうかという成果主義で判断されるので、ちゃんとしたスクラムをやろうというよりも成果が出ているかどうか、そこさえ守れていれば大丈夫ではないかと感じています。もちろん、スクラムのことがよく分からなくてうまくいかない、という場合には経験を持つ人が声をかけたりミーティングに参加したりして形にしているのが現状です。

質問　スクラムマスター的なひとは何人くらいいるのですか？

回答　厳密にスクラムマスターを定義していないので、SEだったりディレクターだったりと、チームの中で問題意識を抱えている人がなっています。

質問　自律的なチームとは、外部から見てどう判断できるのですか？

回答　自分たちでサービスを良くしようという動きができているかどうか、だと思います。弊社ではさまざまな改善案を出す仕組みがもともとあって、よく弊社のブログであがっているのは、各プロデューサーが1つのサービスに対して案を持ち寄って、それに社長が点数をつけて競うというような仕組みがあったりと、そういうのが会社の文化としてありました。

それをプロジェクトに落とし込んだとき、メンバーが、ここをこうした方がいいという改善案を言えることを求めているので、それができているのが自律的なチームと言えるのではないかと思います。

質問　ツールの選定の基準は？

回答　自分はツールの選定に直接関わってはいなかったのですが、いままでRedmineだったりホワイトボードだったりExcelだったりと、さまざまな管理ツールが使われていたのを、まずアカウントを統合したいということと、ホワイトボードなどはプロジェクトが終わると資産として残らないので、残せるようにデジタル化しないといけないという観点で世の中にあるツールを触った結果、JiraだとConfulenceやHipChatとも連係するので、それに決まったと聞いています。

質問　1つのストーリーに対してみんなで着手するというのがありましたが、そうすると競合する可能性が高まると思っていたのですが、逆に効率上がったのはなぜでしょう？

回答　自分の経験では、ストーリーとそれにまつわるタスクの切り方でどうにでもなるのではないかと思います。やってみてうまくいかなければ検討する、というのを繰り返しながら、最初の頃はうまくいかなくても、1カ月くらいするとだんだんメンバーの意思疎通もできてきて、うまくいくようになったと聞いています。

ただしこれでうまくいったチームも半々くらいです。どのパターンも、100％どのチームもうまくいくというのはほとんどなくて、自動化はほぼ100％でしたが、それ以外は、たとえばガントチャートのほうがうまくまわるところもあるくらいで、そこはもうチームごとに試すしかないと思っています。

公開されているスライド「Ameba流 scrumを浸透させていく方法」