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

2014年6月3日

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

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

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

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

fig

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

fig

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

fig

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

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

fig

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

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

fig

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

fig

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

fig

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

fig

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

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

fig

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

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

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

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

fig

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

fig

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

fig

そして普及期へ

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

fig

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

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

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

fig

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

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

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

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

fig

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

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

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

fig

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

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

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

あわせて読みたい

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




タグクラウド

クラウド
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本