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

スクラムのようなアジャイル開発手法を採用して開発をうまく回している現場も、最初からうまくいっていたわけではありません。現場ごとに試行錯誤を重ね、よりよい方法を模索する中で少しずつ改善が進んできているはずです。

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

Ameba流 Scrumを浸透させていく方法

サイバーエージェントの大﨑浩祟です。アメーバ事業本部コミュニティ事業部というところで、現在は24Logのシステム責任者をしています。

今日は、AmebaにおいてScrumが浸透していく話と、そこで経験したTipsなどをお話したいと思います。

社内サイバーエージェントのアメーバ事業部では、2010年にエンジニアが257名でしたが、そこから約3年で1300人になりました。また社内のエンジニア比率も10％から45％に増加しています。（追記 6/3 14:00 この図はアメーバ事業部ではなく、2013年度の決算資料を基にした同社グループ全体の数字でした。訂正させていただきます）

人員急増で混乱、秩序が必要に

まだエンジニアが少数精鋭だった頃、黎明期について。

当時は僕の入社前なので語り継がれていたことをお話するのですが、システム品質のばらつきが大きく、全体に品質よりスピード重視の空気で。ところどころにハイレベルなエンジニアがいて、そのチームの品質は高い、という状況だったそうです。

当時は開発チームがまだ少なく、お互いの顔が見渡せるので情報共有のコストが低い状態でした。目の前の火消しに精一杯で、開発プロセスはあまり注目されていませんでした。

そこから混乱期へ入っていきます。

ここで何が起きたかというと、こんな記事がありました。

この時期はスマートフォンへの転換がはじまって、ビジネス拡大の総力戦のまっただ中でした。なので、人員を一気に増やし、急激にプロジェクト数が増加しました。

いままでは立ち上がってフロアを歩けばだいたい見渡せたのですが、そういうことができなくなってきました。あちらこちらで炎上みたいになって、回らないチームが出始めました。

そこで、どうにかしなければいけないと、いくつかのプロジェクトが動き始めました。

きちんと優先順位付け、計測して予測。強いチームが生まれてきた

どう動き始めたかというと、必要なのは秩序だと。

いっぱい人が集まって、えいや、で始めたことで組織が混乱してしまった。それを抑えるために必要なのは秩序ですよと。そこで何人かが自分のプロジェクトにスクラムを取り入れ始めます。

たとえば、計画における作業の優先順位が全部「高」になっていて困っていた、というところでは、きちんと優先順位付けしましょうと。

あるいは開発の終わりが見えない、いつまでもリリースが見えないという状況に対しては、ちゃんと計測して、いつ終わるのか、あるいは機能追加でどれだけリリースが遅れるのか、などを予測するプロジェクトが少しずつ出てきました。

それによって、「透明な進捗状況」「強いチーム」「自律的なコミュニケーション」が培われてきます。「なんであのチームはうまくいってるの？」と、うまくいっているチームのうわさがだんだん広まってきました。

そして普及期へ

2012年後半から普及期を迎えます。だんだんサービス開発のノウハウも増えてきて、リリースサイクルをもっと速くしてほしいという要求が上がってきました。

組織の課題としては、増え続けるサービスの品質を担保したい、そして中央集権的な管理から自律的なチームにすることで改善スピードをどんどん上げていきたい、ということがありました。

そこで出てきたのが、「スクラム」という言葉です。

この頃には役員陣も興味を持ち始めてくれるようになり、ブログで「ハッカーと画家」とか「アジャイルサムライ」といった本を読んだことを書いたりしていて、アジャイル開発を議論できる空気になってきました。

社内の勉強会も多く開催されるようになって、特に2012年8月に「アジャイルサムライ道場解説」という勉強会を始めて、アジャイル開発はどういうものかを全員に解説する機会があったので、アジャイル開発を導入するチームも増えてきました。

Amebaでのスクラムの普及は、混乱の中での小さな改善を、結果として組織全体が真似し始めたということになります。

アジャイル関連ツールの統一へ

そして2014年4月からの統一期です。

ボトムアップで各プロジェクトがアジャイル開発を試してきている中で、組織的課題として開発の統一化を少しずつしなければならないのではないかと考えるようになってきました。

というのも、プロジェクトごとにやり方が違ったり、ツールが違ったりすると、人材の流動性を考えたときにプロジェクト間を異動したときの学習コストが高くなるためです。

そこで開発支援ツールの統一を行うようにしました。

このために三日間をかけた説明会をやりました。エンジニア全員とプロデューサを一堂に集めてこれらの説明会を開催することで、アジャイル開発、スクラムの導入についての後押しをしました。

特に、いままでばらばらだったゲーム、ブログ、コミュニティといったさまざまなサービスごとにそれぞれでやっていた開発手法を、JIRA Agileなどを用いて改善中というのが現在のところです。

≫後編に続きます。後編では、アジャイルを組織に浸透させるためのTipsなどについて説明されています。