2014.05.09

アジャイル開発手法 (スクラム、XP) の導入事例

はじめまして、次世代システム研究室の A.F. です。

今回のエントリーでは私たちが日々の業務で取り組んでいる『アジャイル開発手法 (スクラム、XP)』の導入事例について紹介させて頂きます。次世代システム研究室の重要なミッションは『GMO インターネットグループの重要なプロジェクトの成功を技術面でサポートする』ことですが、そのため自ずと携わるプロジェクトは多岐にわたります。例えば EC やソーシャルゲーム、広告技術と各プロジェクトで目的も規模もユーザーも異なりますが、Web サービスとして共通しているのはいずれも『変化が激しい』『不確実な要素が多い』という点です。

開発側のスケジュールやリソースといったものから技術的な実現可能性、対象となるユーザーやマーケット、はたまたそれを取り巻く環境など様々な不確実要素を抱えながら開発を行うわけですが、その中で最初から全ての要件を定義することは難しいですし、例え定義できたとしてもそれがその後全く変化しないということは通常ありえません。

そこでアジャイル開発手法では『要件(ユーザーにとっての価値)は変化する』こと『不確実性は存在すること』を前提に、リスクを低減しながら顧客価値を最大化するための様々な知見を原則やプラクティスとして提供しています。変化への素早い対応を求められる次世代システム研究室の業務においてもこれは非常に重要な考え方だと捉えており、各プロジェクトでの導入を進めています。

導入事例

それでは次世代システム研究室とGMOコマース社とで協働した ECショップ様向けツール開発プロジェクト におけるスクラム導入事例についてご紹介します。

開発体制

このプロジェクトでは比較的スタンダードな LAMP 構成のシステムを開発しました。アプリケーションのフレームワークとしては CakePHP を採用しています。開発期間は4ヶ月程度、開発メンバーは7人で、役割は以下の通りです。
  • プロダクトオーナー:1名
  • スクラムマスター:1名(私)
  • 開発チーム(二社からの混合チーム):5名
参加メンバーは最初からスクラムを知っていた訳ではなく逐一勉強しながら手探りでの実践という感じでしたが、結局最初から最後まで 1 スプリント 1 週間で行いました。

各スクラムイベントのスケジュールを図にすると以下のようになります。

20140430_unity.001

本来は各スプリントの最初に行う事が多いスプリント計画ミーティングですが、本プロジェクトではスプリントの最後に次スプリントの計画を行うようにしました。また当初は月曜日開始、金曜日終了でスプリントを回していたのですが、スプリント計画の後に週末を挟んでしまうと色々と忘れてしまい、月曜の朝一からスムーズに開発に着手できないという問題があったため、プロセスの改善を行って金曜日始まりの木曜日終わりにしています。

各種ツール

続いて本プロジェクトで使用した各種ツールについてご説明します。

1. プロジェクト管理ツール

元々、次世代システム研究室ではプロジェクト管理に Redmine を使っており、スクラム導入にあたって新たに Backlogs プラグインを入れました。
Backlogs プラグインを導入すると、主に以下の機能が利用可能になります。
  • プロダクトバックログ
  • スプリントバックログ
  • カンバン
  • バーンダウンチャート
たとえば、バーンダウンチャートを表示すると下図のようになります。ベロシティの変化もわかりやすくなり、なかなかベロシティが安定しないときや負荷が終盤に集中してしまうように感じるときなどにストーリーやタスクの切り方を考え直すのに役立ちました。

agile_2.png

本プロジェクトでは紙のカンバンは使わずに各スクラムイベントでは常に Redmine を確認していましたが、それもこれらのプラグインのおかげで実現できたことでした。

2. 継続的インテグレーション (CI) のためのツール

今回スクラム開発を行うにあたって常に品質の高いプロダクトを提供し続けるために Jenkins に下記のプラグインを導入して継続的インテグレーションを実践しました。
  • PHPUnit, Selenium + Cloverプラグイン
    • テスト実行結果の表示
    • カバレッジレポートの集計
  • phpcpd + DRYプラグイン
    • 重複コードのチェック
  • PHP_CodeSniffer + Checkstyleプラグイン
    • コーディング規約のチェック
    • CakePHP用のコーディング規約を使用
これらのプラグインを入れることで、下図のようにコピペの発生やコーディング規約違反、またテストケースのカバレッジ状況などの最新の情報が Jenkins を一目見るだけでわかるようになります。

agile_3.png

今回はユニットテストのカバレッジの目安として大体 80% 程度を目指しましたが、特に無理をすることなく達成することができました。ここでカバレッジの数字にこだわって闇雲にテストを増やしても本末転倒ですので、カバーされている箇所の可視化を通してどのコードに重点的なテストケースを充てるべきかについて精査することを意識しました。

3. コンフィグレーション管理ツール

コンフィグレーション管理ツールとしては Chef Soloを使いました。冪等性を保証するため原則としてサーバ環境の手動設定(sshでログインしてvi等で編集)を禁止にし、各自の Vagrant や OpenStack 環境でレシピの動作確認を十分に行なった上で本番サーバへ適用するようにしています。
また、構成管理テスト用に serverspec もややお試しではありますが導入しています。

4. オーケストレーションツール

誰でも統一的な手順でデプロイ(やロールバック)を行えるようにするため、オーケストレーションツールとして Capistrano を採用しました。本プロジェクトではバージョン管理システムとして Git を利用していたので、Git と Capistranoで連携してデプロイ処理を行うようにしています。

5. バージョン管理システム

バージョン管理システムには前述の通り Git を使い、GitHub クローンである GitLab を使ってブランチの可視化や Merge Requests を活用したレビュープロセスの導入を行いました。また、運用モデルとして A successful Git Branching model を採用しており、ユーザーストーリーに紐づける形で feature ブランチを切るようにするなどブランチの切り方やマージのプロセスにも一定のルールを設けました。

6. IDE/統合開発環境

IDE としては、今回は PHP による開発がメインであったことも手伝って多くの開発者が PhpStorm を利用して開発を行いました。CakePHP コーディング規約に沿うようにクラス名や変数などの命名規則を PHPStorm の設定に落とし込み、それを開発者が共有することで意識せずともコーディング規約に準拠できるようになりました。特に PHPStorm の『Reformat Code』機能で機械的に規約チェックと修正が行えるのは IDE を使うメリットの一つであると考えています。

ふりかえり ∼アジャイル開発手法を導入してみて∼

それでは最後にアジャイルプロジェクトらしく、KPT の形式で導入事例のふりかえりを書いてみようと思います。

Keep (今後も続けたいこと)
  • 朝会で長々と議論しないなど、常に時間を意識して効率良いミーティングを心がける事ができた。
  • スプリント計画の2部でストーリーポイントだけでなく、想定される全タスクの洗い出しと時間見積もりまで行うように改善した結果、それぞれが機能横断的にタスクを考えるようになり自己組織化が促進され、バーンダウンチャートの精度も向上した。
  • Git の develop ブランチの更新、テスト通過のタイミングでレビュー用環境へ自動でデプロイするようにした結果、フィードバックのサイクルが早まった。
  • KPT は模造紙に付箋紙を貼る形式で行っていたが新たに TODO 用の枠を追加し、次回のスプリントでチャレンジする Try をピックアップして移動することにより、Problem に対するアクションが明確になった。
  • 各種ツール導入の効果が明らかだった。
  • ある程度スプリントが進んだ段階で、アジャイルコーチの木村様にプロジェクトを見て頂き、間違った進め方をしていないか確認する事ができた。
Problem (問題だったこと)
  • スクラムマスター(私)の経験、スキル不足。
  • エンジニア側でプロダクトオーナー (PO) を立ててしまっていたが、本当の意味での PO は別にいた。
  • 開発チームが2社(2拠点)の混合チームで地理的に分散してしまっていたため、コミュニケーション不足や開発環境の差異が発生してしまった。
  • 全てのメンバーが他のプロジェクトの掛け持ちをしていた。
  • プロダクトバックログアイテムの洗い出し不足があったり、プロダクトバックログリファインメントを適切に行えていなかったりした。
  • スプリント中でもユーザーストーリーの優先度が変わり、スプリントが中止された事があった。
  • ユーザーストーリーの完了の定義が曖昧で、完了したつもりになってしまっていた事があった。
  • Jenkins を毎日回すようにしていた一方でテストの失敗に気付け無い事があった。
Try (今後改善していきたいところ)
  • Chef Solo + Vagrant を使った開発環境を本格運用までもっていきたい。
  • Selenium, serverspec はお試し程度でしか活用できなかったので、本格運用までもっていきたい。
  • スクラムをオフショア開発にも適用してみたい。
  • 継続的なプロセス改善に対する意識改革を行いたい。
  • テストコードはしっかりと書けたので、次はテスト駆動開発も実施したい。
  • ペアプログラミングも試してみた程度だったので、実際の開発プロセスに組み込みたい。
Problem に書いた通り、今回のプロジェクトでは私を含めて誰もアジャイルな開発手法に精通していませんでした。そのような状況に大変危機感を覚え、Scrum AllianceCSPO 研修や CSM 研修を受講したり、アジャイル開発関連のコミュニティに積極的に参加するなどして知識を深め、その後のプロジェクトでも継続的にスクラムや XP、リーン開発等の手法を積極的に導入してきた結果、次世代システム研究室でも少しずつアジャイル開発手法への理解が浸透してきたと思います(下図は別プロジェクトにリーンカンバンを適用している例です)。

agile_4.png

今後もさらに開発プロセスの改善を行ってより良いプロダクトをお客様に届けられるよう、次世代システム研究室ではアジャイル開発の導入を一緒に推進してくれる方を募集しています。アジャイル開発経験者の方、また経験は無いけどぜひやってみたいと考えていて次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたらぜひ 募集職種一覧 からご応募をお願いいたします。

皆様からのたくさんのご応募、お待ちしてます!

  • Twitter
  • Facebook
  • はてなブックマークに追加

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

 
  • AI研究開発室
  • 大阪研究開発グループ

関連記事