こんにちは。Gaiax 技術開発部の菊池です。 この記事は、Gaiax Advent Calendar 2016 - Qiitaの15日目の記事です。
はじめに
今回は自分がスクラムマスターとして活動しているプロジェクトでのスクラムについて紹介をしたいと思います。 スクラムマスターとしては3つ目のプロジェクトです。初めてスクラムを知った時から、2年ほど経過しようとしていて、その間にCSM（認定スクラムマスター）とCSPO（認定スクラムプロダクトオーナー）の研修を受講し、認定を受けています。 現在のプロジェクトでは、スクラムの形がほぼ出来上がってきたと感じていて、今の所のスクラムへの取り組みの答えなのかなと感じています。そんなプロジェクトを紹介したいと思います。
開発しているプロダクト
開発しているプロダクトはTRUST DOCKという本人確認のサービスです。
身分証をアップロードし、その身分証に不正がないか確認したり、本人のものかなど包括的に確認を行うサービスです。個人の信用が重要となるWEBサービスにおいて、広く展開をさせていきたいと考えています。
チームの構成
チームの構成は開発者が二人、プロダクトオーナーが1名、スクラムマスターが1人の4人体制です。 開発チームは経験豊富なエンジニアと2年目の若手エンジニアです。プロダクトオーナーは開発の経験があり、開発者と技術的な会話もすることができるプロダクトオーナーです。 そしてスクラムマスターが自分です。自分の役割としては、スクラムマスター以外に、サービスのUXを設計したり、開発の経験を通して開発チームの相談役などもしています。 スクラムマスターとの兼務は、できれば避けたいところではありますが、帽子をうまくかぶりわけ活動しています。
開発で利用しているツール
開発の中で使っているツールは次の2つです。開発で利用しているテストなどのサービスなどもありますが、スクラムのお話なので今回は割愛します。
GitHub
みなさんご存知、ソース管理はGitHubで行っています。スクラムにおけるストーリーも、trustdock-issuesというレポジトリを単独で作成し、こちらで管理しています。
Slack
チーム内のチャットでのコミュニケーションにはSlackを利用しています。共有、相談などのチャンネルのほか、フィードバックの通知チャンネルや、アラートなどの通知もSlackに流れるようになっています。 対面で話せるような座席に配置しているので、何か課題があった場合などは、すぐ後ろを振り返ってその時々解決しています。チャットツールを介して議論を行うとエビデンスとして残るメリットもありますが、そういう内容の場合は、対面ですぐさま解決しつつ、必要があればissueに記載するようにしています。
スクラムイベントとそのサイクル
スクラムで実施しているイベント（タイムボックス）は次の通りです。
スプリント：1週間
開発のひと回しです。プランニングから始まり、実装、レビュー、振り返りまでを指します。
スプリントプランニング（計画）：2時間
スプリントの計画を行います。水曜日の午前中に実施しています。
朝会（デイリースクラム）：15分
毎朝10:00に実施しています。「昨日実施した内容」「今日の実施予定」「スプリントゴールに向かって障害になること」「ニコカレの顔確認」「レトロスペクティブの内容再確認」を実施しています。
プロダクトオーナーレビュー：1時間
プロダクトオーナーへデモを実施し、受け入れ条件をクリアしているか確認します。
スプリントレトロスペクティブ：1時間
スプリントの振り返りを実施しています。振り返りの内容を次スプリントへ活かしています。
プロダクトバックログリファインメント：1時間
優先度順に並べられたストーリーに対して、開発チームとプロダクトオーナーが完了条件などの合意をとり、さらに優先順位が正しいか確認します。
相対見積もり会：1時間
開発により実施されています。リファインメントでプロダクトオーナーと完了条件の合意が取れたもののうち、見積もりされていないストーリーに対して相対見積もりがされます。
スクラム以外で実施していること
インセプションデッキ
事業としてのチーム内での合意形成にはインセプションデッキを利用しています。合意のとれたインセプションデッキは印刷していつでもチームが確認できるよう貼り出しています。変更などがあった場合はメンテナンスを実施します。
がんばった会
何かを成し遂げた、しんどくなった時はみんなで夕ご飯を食べに行き元気を出します。
イベントごとの様子や工夫
それではもう少し詳しく各イベント毎の状況や工夫を紹介します。スプリントは現在28（28週）まできています。
スプリントプランニング：2時間（水曜午前中）
スプリントプランニングでは、これから始まるスプリトでどこまで実装できるか検討します。今回のプロジェクトでは、ストーリーの見積もりを相対的に見積もっています。相対見積もりとは、実時間での見積もりではなく、実装の大きさを基準となるストーリーからどれくらい差があるかという観点で見積もりをします。
前スプリントで実装できた相対見積もりのポイント数（実績）から、今回のスプリントでどのストーリーまで実装できるかプロダクトバックログからおおまかに割り出します。
その後、ストーリーを実装のタスクレベルまで落とし込み、実時間見積もりをおおよそでしています。このとき、どうしても発生してしまうプロジェクト外のタスク（例えばこういう記事の執筆や、勉強会など）も同時に洗い出し、スプリントの計画をたてます。洗い出された開発タスクはGitGubのissueで管理されているストーリーの詳細に転記し、実装もれなどないようチェックリストとして機能します。
この時プロダクトオーナーも参加して、内容の確認を行いながらチームでの合意を取ります。
朝会：15分程度（毎朝）
朝会では、「昨日実施した内容」「今日の実施予定」「スプリントゴールに向かって障害になること」「ニコニコカレンダーの顔確認」「レトロスペクティブの内容再確認」を実施しています。
完結に共有相談できるよう、各自が事前に考え「真剣に参加する」よう促しています。スクラムのTipsにある、障害になることは別に時間を切り出して、関係者だけで議論することはしていません。小さなチームですので、課題があればその場で解決しています。タスクの実装は基本的に個人で行いますが、成果はチームとして出す意識を持ち、遅延などあれば積極的にフォローしあいます。
ニコニコカレンダーも取り入れていて、各自の今日の体調や気持ちの表情シールをスプリントバーンダウンチャートに貼り付けています。チーム内の雰囲気も把握できますし、お互いフォローもし合えるのでよい取り組みです。
また、レトロスプクティブであげたトライすることもできる限り確認しています。
最後に「今日も１日、宜しくお願いします！」と声をだし（オフィス内なので大声はだせません）メリハリをつけて１日のスタートを切っています。
プロダクトオーナーレビュー：1時間（火曜午後）
スプリントで実装されたストーリーが完了条件を満たしているか、開発からプロダクトオーナーに対してデモがされます。開発は円滑なデモができるよう、デモを想定したデータ作成やデモの順番などを事前に準備しています。スクラムマスターは進行だけを行い開発がメインで実施します。 完了条件を満たしたものはDoneとし、万一足りなかった場合は差し戻し、追加の要素が出てきた場合は、別のストーリーとして切り出し、プロダクトバックログに追加されます。 Doneにできた時は、チーム全員で喜び小さい音でですが拍手をし、達成感をしっかり感じるようにしています。 Doneできなかった時は、後のレトロスペクティブで原因などを考え対策を検討します。
スプリントレトロスペクティブ：1時間（火曜午後）
スプリントの振り返りです。KPT法を用いて実施しています。
Keepではスプリントないで良かったことや、継続して続けていきたいことを考え付箋に記載し貼り出して行きます。続けて発生した課題をProblemとして貼りだします。このProblemから特に解決したいことをピックアップし解決策をチーム全員で検討します。次回のレトロスペクティブの冒頭で、このTryとしてあげた解決策が実施され、課題が解決されているか確認を行います。
レトロスペクティブの時間は、チームに向き合うとともに、自分へも矢印を向け振り返りを行います。自分の課題を他のメンバーの前で発表する事はとても勇気が必要なことですが、しっかり共有されています。これはとても素晴らしいことだとチーム全員が感じていて、チームでアイデアをだしたり課題解決に向けて活動をします。
スクラムの自己組織化と振り返りを通じた自分たちの活動の最適化のコアになる活動であり、とても重要なイベントです。
ただ、形骸化もしやすいのもあり、おやつや飲み物を用意して雰囲気をコントールしたり、振り返りすることの意味を改めて考えるなどして活動を続けています。
プロダクトバックログリファインメント：1時間（月曜午前中）
プロダクトバックログ（PBL）のメンテナンスをする時間です。PBLは実装するストーリーが一意の優先度順に並べられたものです。この順番に変更が無いかと、完了条件の合意が取れていないストーリーについて、プロダクトオーナーから説明をうけ、チームで完了条件を作り合意して行きます。 おおよそ3スプリント先くらいまで分のストーリーをストックできるよう、リファインメントを実施しています。余裕がある際は、優先度に変更がない時に限りスキップもしています。 プロダクトオーナーから提示された内容を鵜呑みにするのではなく、当事者意識をもちチーム全員で整合性などを検討します。
相対見積もり会
リファインメントで完了条件の合意が取れたストーリーに対して相対見積もりを行います。相対見積もりする際にチーム内で意見をすり合わせ、だいたいの実装方針がきめられます。この時、お互いフォローできるような体制が出来上がります。プランニングポーカーを用いて実施しています。この見積もりに時間をかけすぎるのも好ましくないので、時間を気にしながら実施しています。
まとめ
現在のこの形は、プロジェクトのチームがスクラムを通して改善してきた積み重ねの結果です。紆余曲折ありながらも、真摯に向き合った結果、今があると考えています。 開発チームも、サービスを自分たちのものと捉え積極的に活動しますし、チャレンジや改善活動を重ね、技術的にもエンジニア的にも成長を続けています。プロダクトオーナーも、初めはプロダクトオーナーの役割がわからず勉強してもらい、多くのディスカッションを重ねてきました。いろいろなスクラムの事例を見ていますが、今の所自分の中では最強のプロダクトオーナーだと感じています。 ただ、まだ改善できる余地はあると思うので、ダッシュして息切れしない程度に走り続けたいと思います。スクラムという手法に関していうと、数ある開発手法の1つだとは思っていて、課題もあるとは感じますが、よい仕組みだと感じていますし、これまからも続けていきたいと思います。スクラムについてなど、何かお話したいことがあればお気軽に声をかけていただければと思います。
サービスがより多くの人に利用していただき、世の中に価値を届けられるよう引き続きチームで頑張っていきたいと思います。 それではみなさま、良いお年を。