技術情報

TechReport - テックレポート

SCRUMによる実践的アジャイル開発手法(寺本隆彦)

概要

 現状、適用する開発手法に関しては、各プロジェクトに任されているため、特定の開発手法を採用していないプロジェクトも多い。しかしながら、一定規模の開発をする場合、何かしらの開発手法を採用した方が良いのは自明である。担当プロジェクトにおいて近年注目されているSCRUMを適用して開発を行ったが、導入時に戸惑うことや疑問に思うことがあった。本稿では、実際にプロジェクトでSCRUMの手法を適用した際の具体的な方法、手順、独自の工夫などについて整理する。SCRUM開発を導入する際の一つのやり方として参考にしていただきたい。

目次

序論

社内ではデカグラフ戦略に伴い、新規プロジェクトが大量に立ち上がっている状況である。現状では、適用する開発手法に関しては、各プロジェクトに任されているため、特定の開発手法を採用していないプロジェクトも多い。しかしながら、新規開発などで、一定規模の開発をする場合、何かしらの開発手法を採用した方が良いのは自明である。担当プロジェクトにおいて近年注目されているSCRUMを適用して開発を行ったが、導入時に戸惑うことや疑問に思うことがあった。本稿では、実際にプロジェクトでSCRUMの手法を適用した際の具体的な方法、手順、独自の工夫などについて整理する。SCRUM開発を導入する際の一つのやり方として参考にしていただきたい。

内容

本開発手法を適用したサービス

担当サービスのアメブロフェイス、センスフルで本開発手法を適用した。

アメブロフェイス

  • http://face.ameba.jp
  • 開発期間:約8ヶ月(ミドルウェアプロダクト検証期間含む)
  • 開発人数:最大7名(プロデューサー1名、サーバー&フロントエンジニア2名、インフラエンジニア1名、マークアップ1名、デザイナー2名)

センスフル

  • http://senseful.jp
  • 開発期間:約4.5ヶ月
  • 開発人数:最大9名(プロジェクトマネージャー1名、プランナー1名、サーバーサイドエンジニア2名、フロントエンジニア1名、インフラエンジニア1名、マークアップ1名、デザイナー2名)

開発をはじめる

いつはじめるか

SCRUM開発は、ユーザーストーリーの抽出から始める。そのため、ユーザーストーリーの洗い出しができる状態になっていないといけない。

プロデューサーが画面ベースの仕様書を書き起こせるタイミングで開始する。

どうやってやるか

要件が7~8割固まった段階で、プロデューサーが仕様書を作成する。その間、エンジニアはスプリント0を実施する。

スプリント0

スプリント0では、以下2点を行う。
・開発環境の構築
・ゼロ機能リリース
  JenkinsなどのCIツールによる自動ビルド・自動リリースの仕組みを整備する。

  1. バージョン管理システムからチェックアウト
  2. ビルド
  3. 開発環境へのリリース

ユーザーストーリーを洗い出す

誰がやるか

  プロデューサー、エンジニア

どうやってやるか

画面項目定義書、ワイヤー、構成案、企画書、などの画面を定義している資料から機能を抽出する。図1に、例としてセンスフルの仕様書を抜粋する。

この例では、この仕様書から「ユーザーとして、ランキングを見ることができる」というユーザーストーリーを抽出した。

図1. センスフル仕様書抜粋

注意点としては、正しく機能を抽出するために、エンジニアを入れた方が良い。 アメブロフェイス、センスフルの場合、エンジニアがユーザーストーリー一覧を作成し、プロデューサー含めて他メンバーがチェックを行った。

ユーザーストーリーのフォーマット

ユーザーストーリーのフォーマットは以下の形式で統一した。
• フォーマット

  ○○として、△△することができる
  ○○:ロール(役割)
  △△:受け取ることのできる価値

• ユーザーストーリーの例

  • ユーザーとして、画像バトルを見ることができる
  • ユーザーとして、タイムラインで新着画像を見ることができる
  • ユーザーとして、ログインすることができる
  • ユーザーとして、チュートリアルを見ることができる
  • ユーザーとして、Facebookに画像を共有することができる
  • ユーザーとして、PCから画像を投稿することができる

ここで、「ユーザーストーリーは機能だけなのか?」という疑問が発生する。仮に機能だけがユーザーストーリーだとすると、プロジェクトの最後一ヶ月、負荷テスト、QA、監査とかやってる期間は、手法が適用出来ないことになる。また、 直接ユーザーに価値を提供しないが、複数のユーザーストーリーで横断的に必要となる共通機能や、管理ツールの扱いなどはどうすれば良いかという問題もある。

機能以外のユーザーストーリー

本稿では、これらの問題に対して、以下のような対応を推奨する。
• ロールを、ユーザー以外にも用意する

ユーザー
システム管理者
開発者

• 機能以外のものでも、ロールが価値を受けるタスクは全てユーザーストーリーにする

機能以外のユーザーストーリーの例

  • 開発者として、汎用的なタイムライン機能を利用できる
  • ユーザーとして、サービスの機能を本番環境で使うことができる
  • ユーザーとして、負荷テスト済みアプリを使うことができる
  • ユーザーとして、QA対応済みアプリを使うことができる
  • ユーザーとして、監査対応済みアプリを使うことができる
  • システム管理者として、GoogleAnalyticsで分析結果を見ることができる
  • システム管理者として、分析ツールででPVを見ることができる
  • システム管理者として、セキュリティログを見ることができる
  • システム管理者として、管理ツールから画像を削除できる

本来、ソフトウェア開発上の全ての活動は、上記で示したようなロールにとっての価値に換言することができるはずである。そうでなければ、その活動は恐らく無駄なものである。このようにすることで、進捗上影響があるが、プロジェクト上管理されていないという活動を無くすことができ、プロジェクト開始からリリースまでの間一貫して同一の手法で管理することができる。

見積もりをする

誰がやるか

  エンジニア

どうやってやるか

  見積もりポーカー

見積もりポーカー

見積もりポーカーでは、ユーザーストーリーの規模を『相対的な数字』で見積もる。

×:○日、△人日
○:3、5

絶対的な見積もり(○日)は、誰がやるか、何人でやるか、によって変わってしまう。そのため「誰が」「何人で」に影響を受けないように相対値で見積もることが肝要である。

見積もりポーカーは、全員の認識の相違を明らかにして、擦り合わせることで、より精度の高い見積もりになる。
アメブロフェイス、センスフルでは、およそ半日~1日程の時間をかけて実施した。図2に、実際の見積もりポーカーの様子を示す。


図2. 見積もりポーカーの様子

センスフルのやり方

アメブロフェイス、センスフルでは、以下のように実施した。

  • 全てのストーリーを最長でも2週間以内に終わるくらいの大きさにする
  • 最小のストーリー、最大のストーリーを選ぶ
  • 最小のストーリーを1、最大のストーリーを13とする
  • 残りのストーリーを相対的に見積もっていく
  • 見積もりに使うポイント数はフィボナッチ数(1、2、3、5、8、13)

優先順位をつける

誰がやるか

  プロジェクトマネージャー、プロデューサー、エンジニア

どうやってやるか

  ユーザーストーリー一覧の各ユーザーストーリーを、上から優先度が高い順に並べ替える。図3に優先度順に並んだユーザーストーリー一覧の例を示す。


図3. 優先順位付けされたユーザーストーリー一覧

優先度の判断方法

優先度は2軸で判断する。

  1. ユーザーにとっての価値が高いもの
  2. リスクが高いもの

本稿では、リスクをプロジェクトを失敗に追い込む潜在的な問題と定義する。

例えば、以下のようなものがリスクである

リスクの例

  • メインの画面でパフォーマンスが出るか分からない
  • まだ実績が少なく、メンバーも経験のない新しいプロダクトを採用する
  • 仕様が複雑/技術的な難易度が高く、正しく設計・実装できるか不安
  • 作ってみたら面白くなくて、仕様を大幅に変更しなくてはいけないかも

優先順位付けのポイント

優先順位付けには、以下がポイントとなる。

  • 適切な優先順位付けのためには、技術的リスクが高いストーリーがどれかを把握する必要がある。また、ストーリーに依存関係がある場合もある。そのため、優先順位付けには、必ずエンジニアも入れる。
  • ユーザー価値が高いもの、リスク高いのを優先度高く。要は大事なものと、不安なものを先にやる。

スプリントを開始する

誰がやるか

  全員

いつやるか

  スプリントの開始日

どうやってやるか

スプリント計画MTG

スプリント開始日に、スプリント計画MTGを実施する
スプリント計画MTGでは、そのイテレーションで実施するユーザーストーリーを優先順位の上から順番に選定する

•タスクにブレイクダウン
  ユーザーストーリーごとに、必要なタスクを付箋に書き出す

図4にユーザーストーリーとタスクへのブレイクダウンの例を示す。


図4. ユーザーストーリーからタスクへのブレイクダウン

スプリントを実施する

誰がやるか

  全員

どうやってやるか

  スプリントは2週間単位で実施した。全員の作業を一目で把握するために、タスク看板を導入し、スプリント期間中は、毎朝、朝会を行った。

タスク看板

タスクの実施状況は、タスク看板で管理する。

図5にセンスフルで使用したタスク看板を示す。

図5. タスク看板

タスク看板は、大きく3つの領域に区切られている。

  1. TODO
  2. DOING
  3. DONE

タスクの進捗状況に応じて、付箋をTODO→DOING→DONEに移動させる。

アメブロフェイス、センスフルでは、進捗状況が皆に一目瞭然となるように、バーンダウンチャート、ユーザーストーリー一覧などもタスク看板に貼っていた。

朝会

毎朝、プロジェクトメンバー全員を集めて、朝会を行った。

全員立った状態で円を組み、昨日やったこと、今日やること、困っていることを一人ずつ順番に話す形式とした。
全体で5分~15分程度で終わるように調整し、それ以上かかるようなら朝会後に、必要な人だけで議論するようにした。

図6に実際の朝会の様子を示す。


図6. センスフルでの朝会の様子

スプリントを終了する

誰がやるか

  全員

いつやるか

  スプリントの最終日

どうやってやるか

スプリント完了レビュー

スプリントの終わりに、大体半日~一日程度のスプリント完了レビューを行った。

プロデューサーが、そのスプリントで実装予定だったストーリが正しく出来ているか実機で確認し、未実装や、不備が有れば指摘して修正してもらう方式とした。

プロデューサーは、入力チェックなども含めて正しく実装されているか確認し、不備を指摘された側はその場で修正し、基本的に次のスプリントに持ち越してはいけない。

図7に、スプリント完了レビューの様子を示す。


図7. スプリント完了レビューの様子

進捗状況を可視化する

誰がやるか

  プロジェクトマネージャー

どうやってやるか

  バーンダウンチャート

バーンダウンチャート

  2週間に一度Excelで更新。毎日更新はしない
※アメブロフェイスの例

図8に、アメブロフェイスのバーンダウンチャートの例を示す。


図8. アメブロフェイスのバーンダウンチャート

期日(リリース日)を決める

誰がやるか

  プロジェクトマネージャー

いつやるか

  基本的に、期日にコミットするのは、スプリントを回して、大きなリスクがなくなってからが良い。現実的なリリース日を算出するために、事前に実施するスプリントは最低でも3~4回は欲しい。

どうやってやるか

  とりあえず三ヶ月後、は絶対にしてはいけない。期日にコミットするタイミングが遅ければ遅い程、現実的なリリース日を決めることができる。

  仮に早い段階でリリース日にコミットしなければいけない場合、スコープの決め方を工夫しなければならない。

  リリース日の決定は、必ず次章で説明するスコープの検討とセットで行う。

スコープを決める

誰がやるか

  プロジェクトマネージャー

どうやってやるか

  リリース日を決定する際には、必ずリリース時点のスコープも検討する必要がある。

  具体的には、優先順に並んだユーザーストーリーの、上からどこまでをリリース時に実装するかを決める。

なぜSCRUMで期日が守れるのか

ここで、なぜSCRUMで開発すると期日が守れるのかという説明をする。

・QCDSという概念がある(荒ぶる四天王)
    Quality(品質)
    Cost(費用≒投入する人数)
    Delivery(期日・リリース日)
    Scope(実装するユーザーストーリの範囲)

QCDSの面積は決まっている。

例えば、期日で無理をして早いリリースをしようとすると、品質、費用、スコープのいずれか1つ以上が犠牲になる。

図9 にQCDSの関係として、このプロジェクト制約の概念を示す


図9. QCDSの関係

全てのプロジェクトはこの制約の中で成功させなければならない。

ここで、QCDSの全てを同時達成するのは非常に困難であるが、いずれか三つを達成するのは比較的容易でであるという事実がある。SCRUMでは、これを利用して、期日を守るためにスコープの調整を行う。つまり、「なぜSCRUMで開発すると期日が守れるのか?」の答えは、「スコープにコミットしないので、期日を守ることができる」である。

例えば、FACE BOOKの開発期間を見積もることは難しいが、ログインといいねだけできるアプリだったら期日までに100%出すことが出来る。SCRUMで期日が守れる理由は、この一点につきる。そのため、決してスコープに不用意にコミットしてはならない。

なお、ここでは品質、費用は固定として考えている。通常品質を犠牲にできることはないが、費用を増やして開発人数を多くするのは別の選択肢として考慮すべきである。

期日の守れる理想の開発方法

整理すると期日の守れる理想の開発方法は以下のようになる。

  1. 優先順位に従って実装し
  2. いつでもリリースできる状態をキープして
  3. 期日が来た時にリリース

つまり絶対に期日を守るためには、「スコープを決めずに期日までに出来たところで出したい」というのが本音である。

一方で、ログインといいねだけできるアプリは、確実にK点超えてないので事業判断としてリリースされることはない。
結局、何らかの形でスコープにもコミットしなくてはならないというジレンマを抱える。

2種類のスコープを用意

本開発手法では、このジレンマを解決するために、以下の2種類のスコープを用意した。

 コミットメントスコープ
  • 必達目標。期日までに死んでもやりきると約束    
  • 相対的に優先度の低いストーリーを極力排除( 相当堅めに見積もる)
  • 最低限のループ、おもしろさを担保できるユーザーストーリーだけにする
  • 同時に、K点を超えられるだけのストーリーのセット
 ターゲットスコープ
  • 努力目標。リリース時点で、なるべく揃えておきたいストーリーのセット。
  • プロジェクトメンバーは、あくまでもこちらの達成を目指す
2種類のスコープ

図10にユーザーストーリー一覧上で、2種類のスコープを示す


図10. 2種類のスコープ

スコープに対するコミットの仕方

実際には、コミットメントスコープと、ターゲットスコープ、2つの間のどこかでリリースになることを、関係者に説明して了解を得ておくことが重要

進捗管理方法

 進捗管理については、バーンダウンチャート上で、コミットメントスコープ、ターゲットスコープの両方をトラッキングする形で行った。

 特に、コミットメントスコープについては、開発初期から終盤までを通じて、一度も遅延が起こらないように注意深く管理した。図11にセンスフルのバーンダウンチャートを示す。

図11. バーンダウンチャートによる進捗管理

スケジュールをメンテナンスする

誰がやるか

  プロジェクトマネージャー

いつやるか

  バーンダウンチャートの線が理想線と乖離した時

どうやってやるか

  予定よりベロシティが出た場合、目標を上方修正する
    ・期日を前倒し
    ・スコープを広げる
  予定よりベロシティが出ない場合、必要な対策を打つ
    ・人を増やしてもらう
    ・期日を伸ばしてもらう
    ・スコープを減らす
  ポイント
    ・スケジュールはメンテナンスするものである
    ・バーンダウンチャートを書いて、見ているだけでは意味が無い
    ・遅延に気づいたら出来るだけ早く声をあげる

スコープ調整の例

センスフルでは、当初の想定よりもベロシティが出たので、途中で目標を上方修正してスコープを広げた。図12にスコープ調整の例を示す


図12. センスフルでのスコープ調整

キーパーソンとMTGをする

誰がやるか

  プロジェクトマネージャー、プロデューサー、デザイナー、エンジニア

いつやるか

  随時

どうやってやるか

 上司や決裁者など、キーパーソンとのミーティングのやり方について説明する。 

  • 肝の部分について、ストーリーの優先順位をあげて実装する。
  • 重要なストーリーをなるべく早く実装して、MTGに持っていく。
  • 実機で触って確認してもらうことが大事。
  • 不安な部分程、絶対に隠してはいけない。
  • 指摘をもらうなら早いうち。

仕様の変更に対処する

誰がやるか

  プロジェクトマネージャー、プロデューサー

どうやってやるか

弊社では仕様の変更は当たり前である。未着手のストーリーに関しては、変更してもらって構わないが、完了済みのストーリーに変更が発生する場合が厄介である。
基本的には、プロジェクトマネージャー、プロデューサーは、仕様変更をしていいのは極力ストーリーの着手前までという意識を持つべきである。
しかし、現実には完了済みのストーリーに関する仕様変更は必ず発生する。

仕様変更用のユーザーストーリー

本稿では、予め仕様変更用のユーザーストーリーを作成しておくことを推奨する。プロジェクトマネージャー、プロデューサーは、仕様変更の量を仕様変更ストーリーのポイント数内に収められるかどうかが勝負となる。
 例:ユーザーとして、仕様変更済のサービスを使うことができる

アジャイルなチームを作る

誰がやるか

  プロジェクトマネージャー

どうやってやるか

  アジャイルなチームは相互に助け合う。そのようなチーム作りを促進する仕組みを考えるべきであるし、逆に助け合わないチームになってしまう仕組みを取り入れてはいけない。

ペアプロタイム

相互に助けあうチームを作るうえで、有効だったのがペアプロタイムである。一日二時間だけペアプログラミングを実施し(毎日一時間ずつ相手のタスクに取り組む)、ペアは毎日ローテーションすることを原則とした。

ペアプロタイムのメリット
(1)知識と技術を共有できる

経験の浅いメンバーが、 スキルのあるエンジニアのコーディングを間近で見て教えてもらうやり方は、エンジニアとして成長する上で間違いなく有効な方法である。経験を積んだメンバー同士でも、他のエンジニアのコーディングを見ていることで、新しい気づきがあり、自分の知らなかったショートカットキーの使い方や、デザインパターン、イディオムなどを、学ぶことができる。ペアをローテーションしていくため、メンバー全員が自分の担当サービス全体を把握しているという理想の状態に近づく。

(2) 設計・コードの品質が向上する

二人で相談しながら作業していくので、設計・コーディングの質が向上する。あるペアで解決できなかった課題が、別のペアで解決できることもある。コードレビューのように、他のメンバーが書き上げたコードに対して意見をするのは抵抗があるものだが、ペアプロであれば、書き途中のコードに対しての指摘なので、気軽に意見することができる。そこから議論していくことで、より良い設計やコードになっていくことが何度もあった。

(3)コードの共同所有意識が醸成される

広範のコードに自分が関与していくため、コードを共同所有している意識が高まる。他の人が書いた箇所は、自分の責任範囲外と感じてしまうのを防ぎ、積極的にリファクタリングしていく動機付けになる。

(4)一人で悩む時間が短縮する

ペアプロタイムを導入すると、助けを求めるタイミングが、必ず一日一回やってくる。ある程度経験を積んだメンバーの場合、プライドや遠慮から、周囲に助けを求めるタイミングが遅くなったりすることもあるが、一人で解決できない問題を抱えこんだまま時間を無駄にすることはできない。チーム全員で、問題解決にあたるようになり、ペアプロタイム以外の場面でも、気軽に相談することができるようになる。

センスフルチームでは、これらのメリットが相乗的に作用して、結果的に相互に助け合うチーム作りに大きな効果があった。

図13に、実際のペアプロの様子を示す。


図13. センスフルでのペアプロの様子

やってはいけないこと

  以下に、アジャイルなチームを作り上げる上で、筆者がやってはいけないと考える主な行為を2点挙げる。

先に全てのタスクを個人に割り当てる

  タスクを先に個人に割り当てると、必ず負荷の高い人、低い人が出てくる。自分のタスクが終わったら暇したくなるし、自分のタスクを手伝ってもらうのは気が引ける。要は相互に助け合いづらく、必ず誰かがボトルネックになってしまう。そのため、タスクは常にチーム全員のものという意識付けが重要である。あくまでも、タスクはチェックアウト方式で、その時やれる人がやる形が良い。

個人のポイント消化スピードを測って、競わせる

  個人の生産性を単純に数字で計測し始めると、そのチームは相互に助け合わなくなる。あくまでもチームの全体のベロシティが大事である。メンバーには困っている人がいれば積極的に助けあうように意識を持ってもらうことが重要である。

まとめ

最後に、筆者が実際にSCRUMによる開発を行って感じたメリットについて述べる。

サービスにとっては、以下のようなメリットがある。

  • クリティカルなフィードバックを早期に得ることができるため、良いサービスを最短で作り上げることができる

作り手側にとっては、以下のようなメリットがある。総じて言うと、作り手にとっては自分達の仕事環境を良くする仕組みである。 

  • 開発期間を通して、動いているものが常にある絶対的な安心感がある。
  • 不安を先に先に潰して行く手法であるため、精神衛生上良い。
  • 長い開発期間中でもメリハリがあるのでモチベーションを保ちやすい。

マネジメント側にとっては、以下のようなメリットがある。

  • 現実のチームのベロシティを基にすることで、現実的なスケジュールを引くことができる。
  • スコープを調整することで、期日を守ることができる
  • 正確な進捗状況を把握できるのでプロジェクト状況に応じた対応を早期に打てる

本手法を用いて開発したセンスフルでは、継続的に発生し続ける仕様変更などもうまく織り込みながら、実際に対外的に告知したリリース日を遵守することができた。本稿で述べた手法が、現場において役に立ち、SCRUMによる開発が少しでも広まれば幸いである。

参考文献

[1]Mike Cohn(著) 安井力(翻訳) 角谷信太郎(翻訳), アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~, 毎日コミュニケーションズ, 2009

[2]Jonathan Rasmusson (著) 西村 直人 (翻訳) 角谷 信太郎 (翻訳) 近藤 修平 (翻訳) 角掛 拓未 (翻訳), アジャイルサムライ-達人開発者への道-, オーム社, 2011

TOP