SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2012】セッションレポート(AD)

【デブサミ2012】17-A-4 レポート
スクラム導入で組織はどう変わった? DeNAにおける実践・適用例

  • このエントリーをはてなブックマークに追加

 本稿では、「Developers Summit 2012」(デブサミ2012)において、2月17日に行われた株式会社ディー・エヌ・エー 貝瀬岳志氏によるセッション「Scrumで組織改革」の内容を紹介する。  アジャイル開発手法の一つであり、チーム全体の生産性向上を重視したプロダクト開発のフレームワークとして、ここ数年注目度の高まっている「スクラム」。本セッションでは、DeNAで2011年夏より自部門にスクラムを導入し、今日まで継続的にその適用範囲の拡大および改善に取り組んできた貝瀬岳志氏が、DeNAにおけるスクラム導入の目的や展開のプロセス、スクラム推進による組織自体の変化などについて紹介した。

  • このエントリーをはてなブックマークに追加
株式会社ディー・エヌ・エー プラットフォーム統括部
メディアシステムグループ グループリーダー /
ScrumAlliance 認定スクラムマスター 貝瀬岳志氏
株式会社ディー・エヌ・エー プラットフォーム統括部 メディアシステムグループ グループリーダー / ScrumAlliance 認定スクラムマスター 貝瀬岳志氏

経営陣と現場の課題解決のために、スクラムをトライアル導入

 貝瀬氏はまず、スクラム導入に至る背景として、「急成長するスマートフォン業界」と、そこでMobageを中心としたビジネスを展開していくために「急拡大する組織」があったと説明。こうした中で、よりスピーディな意思決定と施策の実施が求められるようになり、経営陣や現場のメンバーがそれぞれの立場で抱える課題が顕在化してきたという。

 例えば経営陣は、アウトプットや業務進行のクオリティおよびスピードが上がっていないこと、新しいアプローチやスケールする取り組みがないことなどを課題として認識。一方、現場にとっての課題としては、いつまでたっても「やるべきこと」が多くて終わらない、やっていることの背景や位置づけがよく分からない、といったことがあった。貝瀬氏らマネージャー層の課題は、こうした経営陣と現場の課題を解決することであり、「これらの課題を自分たちで解決できる“自己成長型”の組織にしたいという思いがあった」と語る。

 貝瀬氏は、このさまざまな課題の根本原因を「困難なスケジューリング」「不明確な責任範囲」「放置された問題・課題」の3つに集約。それぞれの解決のアプローチは、「適切に優先順位をつけられる仕組み」「役割の可視化とそれを果たすためのマインド形成」「課題の抽出や実行、評価を回し続ける一定のサイクル」であると考えた。そして、これらを実現できるフレームワークとして、スクラム導入に至ったのだという。

 続いて貝瀬氏は、DeNAにおけるスクラム導入・実践の取り組みを、大きく3つのフェーズに分けて説明。まずフェーズ1は、スマートフォン版Mobageのリニューアルプロジェクトへの導入だ。UI設計を海外のデザイン会社が行い、実装を日本で実施するという特殊なプロジェクトで、チームは海外と日本側を合わせ、最大で約20名の規模。もともとデザイン会社がスクラムを導入していたこともあり、DeNAでもトライアル導入することになった。

 なお、スクラムにおいてスプリント中に毎日10分ほど実施するデイリーStandUp(デイリースクラム)は「朝会」と呼ばれることが多いが、このフェーズ1では日本と海外の時差の関係で、デイリーStandUpを日本のメンバー全員による「朝会」と、海外メンバーと一部の日本メンバーが参加する「夜会」の2回に分けて実施。やはり時差の問題で十分なコミュニケーションが難しいことから、スプリントの最初に実施するスプリント計画(プランニング)の前に、優先順位決定の場として「プレプランニング」という会議も設定。ほか、スプリント後のスプリントレビュー、ふりかえりは、通常のスクラム同様に全員参加で実施した。

 ツールとしては、もともとデザイン会社が使っていたBasecampでプロダクトバックログを管理。日本では、Basecampのプロダクトバックログから切り出したスプリントバックログを、ホワイトボードと付箋を使って見える化した。また、実施した内容を蓄積するために、チケット管理ツールのJIRAにもまったく同じ情報を登録していた。

 「このフェーズ1のふりかえりをKPTでまとめたところ、Keep(続けたいこと)がほとんどなく、Problem(問題)とTry(改善したいこと)ばかりになってしまった」(貝瀬氏)

 例えば、経験不足による立ち上げのもたつき、海外とのコミュニケーションがとりづらいことによるストレス、人数が多すぎて朝会がまとまらなかったことなどが、問題として挙げられた。

 とはいえ、成果がなかったわけではない。導入のきっかけである3つの課題に対するふりかえりで、例えば「困難なスケジューリング」に関しては、スプリント単位で優先順位を合意できたので突発案件が減ったことや、「不明確な責任範囲」については、プロジェクト内部で責任の所在が明文化されたこと、「放置された問題・課題」についても、ふりかえりを使って問題提起・改善のサイクルが回り始めたことなどが挙がっている。

 「スクラムは問題の可視化、共有が可能なフレームワークであることを実感できたし、スプリントを繰り返すたびにチームが自己成長してきた。3つの課題を解決する可能性を感じることができた」(貝瀬氏)

フェーズ1でのチームのふりかえり(スクラムに関するもののみ抜粋)をKPTで整理
フェーズ1でのチームのふりかえり(スクラムに関するもののみ抜粋)をKPTで整理

スクラム推進でマインド形成と自己組織化、生産性の可視化も実現

 フェーズ2では、さらに広い範囲でスクラムを展開。スマートフォン版Mobageを運用する企画・開発部門に導入した。チーム構成は、ミッションごとに構成された4つのチームで、各チームにプロダクトオーナー、スクラムマスターを1名ずつ配置。チームメンバーは、最大でも10名以内に抑えた。これは、フェーズ1で人数が多いために朝会が破綻してしまったことを踏まえての調整だ。

 ほかにも、フェーズ1の教訓を活かして、もともと別組織で席が離れていた企画者と開発者を組織にかかわらず近い席に集めたり、ツールを使い慣れたJIRAに集約してホワイトボードや付箋と同じ内容を登録する無駄を省く、といったことを行った。また、Sprint 0(ゼロ)として、スクラム実施前の準備期間を1~2週間設定。経験の浅いスクラムマスターをサポートするために、貝瀬氏がSprint 0で実施すべきことのテンプレートを作成して配布した。こうした取り組みにより、フェーズ2のふりかえりでは、3つの課題に対してさらに良い効果が得られたことが認められた。

 しかし一方で、バックログがなかなか増えなかったり、スクラムの各種会議に否定的なチームが出てくるなど、フェーズ1では挙がっていなかった新たな課題も発生。そこで貝瀬氏は、各チームのメンバーがスクラムの理解を深めること、これまで実施したスクラムをふりかえって今後の改善につなげることを目的とし「立て直し」のフェーズ(フェーズ2.5と表現)を実施。貝瀬氏自身もスクラムの仕組みを体系的に理解するために認定スクラムマスター研修に参加し、その内容をワークショップ形式で他のメンバーに伝えた。

 今後の改善につなげる取り組みとしては、フェーズ2のふりかえりで当時のデータ収集を行い、さまざまな問題を集めて、それぞれに対してどうすれば改善できるのかアイデア出しを実施。それらのアイデアから、次に何をすべきかを決定した。また、最後にこれらの取り組み自体をふりかえる「ふりかえりのふりかえり」も行った。

 「これにより、ふりかえり自体が有意義であることをメンバーも自分自身も実感できた」と、貝瀬氏は強調する。

 こうした経験を経て、社内でスクラムに対する理解が深まったこともあり、続くフェーズ3では各チームが主体的にスクラムをアレンジするようになったという。例えば、スクラムは基本的に突発案件をよしとしないが、それを受け入れるルールとしたり、組織や市場の変化・成長に対応するためにスプリントごとにチームを再構成するといったアレンジも行っている。なお、このフェーズでは自部門の開発にかかわる全組織にスクラムを導入。12のチーム、100人を超えるメンバーが対象となった。

 このようなスクラムへの取り組みを通じ、DeNAには「組織として確実に変化が起きている」と貝瀬氏は話す。まず挙げられるのが、「マインド」の変化だ。チーム内のみならず他部署との組織間のコミュニケーションが活性化したことで、意見交換などがスムーズに行えるようになった。また、自らやりたいことを生み出す風土と仕組みもできてきた。これにより、将来的にスケールすることが期待される取り組みや新たな製品の企画開発も続々と生まれている。そして、ふりかえりによる、自発的な改善サイクルも回るようになってきた。

 「自己組織化」も重要な変化として挙げられる。新規プロジェクトのスクラムがメンバーから自発的に立ち上がっていること、担当やチームの構成が変わっても生産性が落ちていないこと、プロダクトバックログが増えてきていることなどは、その成果といえるだろう。

 また、プロダクトバックログやスプリントバックログで、登録された課題、消化できたストーリーの数などを把握することで、生産性を可視化することもできるようになった。同様に、スプリントごとの見積もり精度なども可視化可能だ。

 「スクラムを回していくことで、これまで見えてこなかった課題や問題点が可視化され、将来やるべきこと・やりたいことも明確になる。非常に有用なフレームワークだと実感しているので、ご自分の組織で取り入れてみたいと感じた方は、ぜひトライしていただきたい。もし仮に半年ほど実践してみて、効果が得られないと思われたら……そのときはDeNAに来て私と一緒にスクラムをやりましょう!」

 最後に貝瀬氏は聴講者にそうエールを送り、セッションを終えた。

ふりかえりの風景:各メンバーが改善したいことを付箋に書き出し、認識を合わせて次に何をすべきか決定する
ふりかえりの風景:各メンバーが改善したいことを付箋に書き出し、認識を合わせて次に何をすべきか決定する
お問い合わせ

株式会社ディー・エヌ・エー

東京都渋谷区代々木4-30-3 新宿MIDWESTビル

http://dena.jp/

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/6441 2012/03/12 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング