CodeZine(コードジン)

特集ページ一覧

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

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2012/03/12 14:00

 本稿では、「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で整理

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

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

バックナンバー

連載:【デブサミ2012】セッションレポート

もっと読む

All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5