スクラム風チケット駆動開発で開発の見える化に取り組んでみた

おきまりのやつ

CYBIRDエンジニア Advent Calendar 2015 - Qiitaの5日目を担当します新卒入社4年目の@megadreams14です。
もう入社して4年も経つのかー・・・

さて昨日は今年新卒で入社した@kanachaさんの
「Cocos2d-x超入門 そもそも何からはじめればいいの？」でしたね！
社内で開催している、普段アプリを触っていないエンジニア向けのCocos2d-x勉強会でも、
新卒でありながらも講師として教える側に回っており、普段から凄く勉強させて頂いております。

開発の見える化について

みなさんプロジェクト管理や新規開発をどのように進めていますか？

弊社では最近スクラムをベースとした開発が主流となっており、
それぞれチームに合った手法やカスタマイズをした開発を行いながら
開発の見える化に取り組んでおります。

今回はこれまでいちエンジニアとして開発に取り組んできた自分が
初めて開発リーダーとして技術チームのマネジメントをするにあたり、
「開発の見える化」について取り組んでいることを簡単に紹介させて頂きます。

プロジェクトの背景と前提条件

まずは紹介するにあたって開発ツールや環境などの紹介をさせて頂きます。

開発支援ツール

• Redmine
  • 進捗管理やタスク管理は基本的にRedmineが標準
  • 技術だけでなくデザイナーやデバッガーの方々も利用
• Github
  • バージョン管理
  • WIPパターンによるPull Requestを利用した開発フロー
• チャットワーク
  • コミュニケーションツール
  • GithubへのPushやPull Request、CIの通知などにも利用
• ベースとなるゲームエンジンが既に存在している
  • 既にリリースしているゲームをベースに本プロジェクト用に修正や追加機能の開発を実施
  • Webとネイティブの機能を利用した、ハイブリッドアプリ

スクラム開発事例

今抱えているプロジェクトでのスクラム開発の方針が下記になります。

• タイムボックス
  • 1スプリント2週間
    • 金曜日の午前中に計画
    • 木曜日の午後にレビュー会
    • レビュー会後に企画、デザイン、技術全員でKPTの実施
• ストーリーポイント
  • 1ポイント2時間
    • 通常ポイントは開発規模の認識合わせのために用いるが弊社では時間が多い
• 稼働率
  • 1日80%の稼働
    • 朝会やその他MTGを考慮
    • コードレビューなどもチーム全員で回しているのでその時間も考慮

プロジェクト独自の指標

本プロジェクトでは、先ほどの基準値に基づいて「最低担保ライン」という指標設け、
「チームで最低はどれだけのパフォーマンスをだせるのか」を明確にしました。
このようにすることで、

• チーム内で詰まっている人がいれば進んでいる人がカバーする
• 見通しは最低担保ラインを基準に実施する

の２点を補えるような指標として設けました。

あくまでポイントは時間ベースなので時間で見積もっているのと変わりはないです。

開発の見える化でやったこと

そんな背景の中開発の見える化でやったことは大きく２つです！

やると分かればすぐに「細かくタスク化」と「工数見積」
各タスクが優先順位順に並んでいる状態を常に作る

アタリマエのことではありますが、
やるべきことが分かればとにかくタスク化し、関係者で工数を見積もる、
そしてこのタスクの優先度はどの位置なのかをPOと相談してタスクを並べ替えることで、
タスクボードを見れば常に優先度が高い順にタスクが並んでいる状態を作り、
スプリント開始時や人が追加された際には、上からタスクを取っていけば良い状態を作りました。

あれユーザーストーリーを作らないの？

常に上からタスクが並んでいる状態と記載しましたが、
本来であればユーザーストーリーが作成され
そのストーリーに対してポイントで規模感の認識合わせを行い、
その中で細かくタスク化して作業を進めていくのが普通だと思います。

実際に本プロジェクトでも最初はストーリーを作成して取り組んでいましたが、
関わる人やセクションが多くなった時に色々と問題が発生しました。

その要因としては

• Webとアプリのハイブリッドということで、サーバとフロント、ネイティブアプリと担当を分けている
  • 
• それぞれの機能は各担当ごとに連携して進める必要がある
• アサインされているメンバーのスキルも違う
  • 

これらの理由からストーリーで管理していた時には、

• クリティカルパスなどの影響でストーリーがいつまで経ってもDone出来ない
• ストーリーを分割したが結局タスク単位と変わらなかったことが多かった

という問題が発生し、この辺りがスクラムやアジャイル開発での
人数の限界と呼ばれる１つの理由なのかと感じました。
そのため、本プロジェクトでは基本的に細かいタスクベースでチケットを切って管理し
チケット駆動開発と組み合わせることで開発を進めることになりました。
（もちろんストーリーの切り方などもまだまだ検討の余地はあったと思います）

見える化してよかったこと

こちらも当たり前のことですが、
全てのやるべきことが見積もりがなされ優先度順に並んでいる状態があることで
時系列で見ると下記のようなメリットを個人的には感じました。

• 【過去】いつ何をしたかが明確になった
• 【現状】リカバリがやりやすくなった
• 【未来】見通しがたてやすくなった

【過去】いつ何をしたかが明確になった

スクラムに限らない話かもですが、
スプリント別やマイルストーン別でのバーンダウンチャートやバグ曲線といった実績値を可視化し、
さらにその時のチームの雰囲気やKPTの結果をレポートとして残すことで、
このプロジェクトの歴史や歩みを残すことが出来、
チーム内での振り返りや同じ失敗が繰り返されていないかなどを把握できるようになりました。

また、バーンダウンチャートなどの実績値から課題や問題点なども読み取ることが出来、
KPTなどで全員が課題認識を持って改善プロセスを回していくことで、
スプリント単位で問題点の改善を行えるように成りました。

【現状】リカバリがやりやすくなった

各担当者はチケットベースで作業を行っているので毎日チケットを更新することで
スプリント内でのバーンダウンを毎朝チャットに通知するようになり、
朝来た時にはチームの開発状況がどのようなステータスか分かる状態にしてみました。

また状態を顔文字などを表現することで視覚的にも進捗が分かる状態にしています。

また今のプロジェクトで特徴的なのは個人ベースでの進捗もチャットに通知しており、
誰が困っているかを早期に発見出来るようにし、

• 早い段階での原因の解決
• 進んでいる人が環境面などの改善にとりかかったり、チーム内で再度作業分担

などし、チームで開発をカバー出来るような環境を導入して進めることができています。

他にもチーム内では「ここにGithubのコミット数や編集行数を入れてみよっか」
などの意見も出ており楽しく開発出来るよう心がけています。

【未来】見通しがたてやすくなった

こちらは主にPMの方に行っていただいたのですが、
やるべきことがポイントとして既に積んであるため、
全体像や見通しが立てやすく今後発生するであろうリスクなども
常にチームメンバーに共有することが出来、
共通認識を持って開発が行えているのは凄く良い事だと感じています。

ポイントの見積もりや洗い出しが肝

ただこのような取り組みも、結局あたりまえの話ですが
見積もりを誤ると全く意味のないものになってしまうのでその点は注意して心がけました。

見積もりポイントの精度

こちら参考までに今のプロジェクトのα版の開発結果をベースにすると、
見積もったポイントに対する実績値の誤差を出してみたところ
+12.67%（見積もり:3,686[h] / 実績:3,219.15[h]）と
多めに見積もる傾向にあり見積もりに対して間に合いませんということは発生しませんでした。
これも細かくタスク分解できているからこそ見積もり精度もその分高くなっているのかなと思います。

やるべきことの洗い出し漏れ

α版での各スプリントの状況を見ていると当初の見積もりから約2.5~3倍程度膨らむ傾向にありました。
もちろんこれは全て洗い出せていない見積もれていないところにも問題はありますが、
途中での仕様変更やバグ対応なども含めた数値となっているので、
あくまで実績値を次のスプリントやマイルストーンに活かすという考え方で取り組んでいます。

そのため現状のマイルストーンの開発においても、初回見積もりの3倍くらいは膨れると想定し
見積もりや見通しが行えているので（現状それくらいの規模で落ち着いてきている！！）、
その辺りは見える化しているからこそ、実績値から学べることも多く
早めにリスクヘッジに取り掛かれているところは良いと感じています。

独自視点の「最低担保ライン」は達成しているの？

最初に指標として定めた「最低担保ライン」は過去14スプリント(7ヶ月)実施してきましたが、
チームとして全て達成できている状態であり、
色々問題は出ていながらもチーム全員でカバーし合いながら
巻き返しが出来ている証拠ではないかなと感じています。

• スプリント別チームのポイント達成率状況

まとめ

「やると分かればすぐに「細かくタスク化」と「工数見積」」
「各タスクが優先順位順に並んでいる状態を常に作る」
この２点をチームみんなで心がけながら開発を進めていくことで
今のプロジェクトでは、開発の見える化に取り組むことができています。

とはいえ、チームによって開発スタイルは様々であり
スクラムやチケット駆動はあくまで手段のひとつであるため、
自分たちがやりやすい方法をチーム内で話し合って、
自分たちにあった開発を進めて行くのが一番大事なのかなと思います。

終わりに

様々な開発スタイルがある中での１つの事例として参考になれば幸いです。
みなさまもどのような方法でプロジェクト進められているか、
是非共有して頂ければ自分自身凄く勉強になります！

さて、明日のCYBIRDエンジニア Advent Calendar 2015 - Qiita は、
弊社のデータベースのスペシャリスト（@Mr_Kim）さんからの投稿で
「オンプレミスDBとクラウドDBについて」です。
（@Mr_Kim）さんには、日頃からデータベースに関してお世話になりっぱなしで
頭が上がらない大先輩です！凄く楽しみデスね！