この記事について

この記事は、株式会社アイスタイル Advent Calendar 2016 の 6 日目の記事です。

ウォーターフォール育ちのわたしが、アジャイル開発と出会い、開発期間8ヶ月・メンバー12人というそれなりの規模の新規開発プロジェクトにScrumを導入した経験について書いてみたいと思います。
「新規開発にいきなりアジャイルは向かないんじゃないか」「大規模開発にScrumってはまるのか」とお悩みの（昔のわたしのような）方へのヒントに少しでもなれば幸いです！

※2016年7月に入社したばかりのため、以下の経験談はアイスタイル社内のできごとではありません。あらかじめご了承くださいませ。。

経緯

アジャイル開発に目覚め、Scrumを導入することになったのは、2015年のはじめごろ。
それまで携わった開発プロジェクトはウォーターフォール型ばかりで、自分もほかに選択肢を思いつかないほど当たり前のプロセスでした。上流の要件定義・設計工程に多くの時間をかけて行うことが品質確保のための正義で、必要なものだけ作って後でリファクタリングするとか破綻しそうだし、納期までにシステムを仕上げるためのスケジュールとかマイルストーンは計画立てられなさそうだし、アジャイルやScrumの情報を目にしても「ある程度の規模の新規開発とか大規模プロジェクトじゃ無理だよねー」という感じで気にも留めていなかったのでした。

ところが、2014年の秋にシンガポールで3か月OJT研修する機会があり、そこで参加したScrumチームがすごかったのでした。だれも残業しない、それでいてスプリントごとにまとまった成果をちゃんと出す。品質も悪くない。各自がバックログから積極的に仕事を取っていき、スプリントの終わりにはどうすれば自分たちのやり方がもっと良くなるかについて真剣に話し合う。こんなすてきな働き方をする開発チームがあるのかと。。。

3か月ですっかりアジャイル信者に生まれ変わって帰国したわたしを待っていたのは、しかし、開発期間約8カ月・開発メンバー12人前後の、それなりの規模な新規開発プロジェクトへのアサインでした。当然のように、上司もプロジェクトマネージャーもアジャイルやScrumでやろうという発想はなく、普通にウォーターフォール型の開発を想定したプロジェクト計画が進められていました。
それはもうがっかり半端なくて、新しいプロジェクトになんの希望も持てない気分だったのですが、、、やっぱりあきらめきれない、せっかく学んだアジャイル開発が8か月以上も実践できないとか耐えられない、プロジェクトにとっても導入したほうがいいはず！と思って、Scrumプロセスを取り入れたプロジェクト計画案を自分でつくってプロジェクトマネージャーに提案し、ねじ込むことができました。

プロジェクトでの立ち位置

当時わたしはプロデューサーという立場で、直接の開発業務ではなく、要件定義やプロジェクト管理を主に担当していました。
新しいプロジェクトでScrumを導入するにあたり、最初は「プロダクトオーナー兼スクラムマスター」としての立場で動くことにしました。
プロダクトオーナーとスクラムマスターを兼任すべきではない、というのはScrumにおける有名すぎる非推奨事項なのですが、最初はほかにできる人がいないので仕方なく。。

（その後、無事にスクラムマスターも誕生して、分業に成功しました）

どんな計画を立てたのか

8ヶ月という開発期間を、

• 要件定義＆見積もり期間：1ヶ月
• 開発期間：1ヶ月スプリント×5回＝5ヶ月
• QA＆リリース準備期間：2ヶ月

のように区切りました。すべての期間をSprintとする案も検討しましたが、開発の計画（見通し）を立てやすくするため（それをプロジェクトマネージャーにわかってもらうため）、大枠としては既存のウォーターフォール開発における進め方に準拠しました。

開発期間の5ヶ月については、最初の1ヶ月で洗い出された要件を見積もった結果、必要な要件をすべて入れ込めなければリリース時期を再検討する前提としていましたが、実際はこの期間のとおりにリリースを行うことができました。

ひとつのスプリントの期間は、1ヶ月と決めました。

Scrumではスプリントの期間は「1週間〜最長で1ヶ月」と決められており、1ヶ月はもっとも長い期間になります。

この期間に決めた理由は、短期間のサイクルで行う開発に不慣れなメンバーが多かったことと、品質確保のために十分なレビューやテストを行う時間を確保するためでした。

QAについては、リリース前にまとめて1回の実施としました。スプリントごとに実施する案もあったのですが、部署が離れていたこともあり同期して動きづらいこと、また最終的なシステムテストとしての意味合いを重視させるため、まとめて1回になりました。

それまでのプロジェクトでのQAの場合、結合テストを兼ねた大量のテストが実施されていたのですが、結合テストはスプリントごとに実施するので、シナリオベースのテストを重視するようにしました。

実際どうやったのか

要件定義＆見積もり期間

最初の1ヶ月は要件定義＆見積もり期間として、新しいシステムに必要な要件を洗い出してリスト化し、それをプロダクトバックログにストーリーとしてひとつひとつ入力していきました。
その一つ一つを概算見積もりして、スプリントの回数と開発メンバーの人数から概算される「1スプリントあたり消化可能な開発工数」にあてはめ、5回のスプリントにストーリーを割り振って大まかな開発計画としました。

見積もりにあたってはストーリーポイントを導入したいところでしたが、たくさんの新しい変化を一気に適用することはメンバーの負荷が大きいと考え、このプロジェクトでは従来どおりの人日単位での見積もりを採用しました。

この期間ではあわせて、アジャイル開発とScrumについてメンバーへの説明、スプリント中の開発の進め方やストーリーの完了の定義などのルールづくりを、メンバー全員と話し合いながら進めていきました。
ここはメンバーもわたし自身も手探り感がすごくて、1カ月をどのように過ごせばよいのか、品質を確保しながら開発できるのか、まとまった設計が必要な部分はどうするのか、など繰り返し議論を重ねました。

開発期間

1ヶ月の中で、詳細設計、実装、単体テスト、結合テスト、リグレッションテストを実施しました。

設計レビュー、テスト観点レビュー、コードレビューを期間内に行い、結合テストが完了して重要な不具合が解消されていることを完了の定義としました。（以前のプロジェクトで品質問題があった影響で、多くのレビューが必須となっていました）

段階的なレビューポイントを経ることで、1スプリントの中では結果的に「コンパクトなウォーターフォールプロセス」のようになっていきましたが、数回のスプリントを通してこの進め方が今のメンバーにあっているとわかりました。それに合わせたチーム内ルールも自然に生まれていきました。

プロダクトオーナーとしてのわたしの主な仕事は、そのスプリントの1ヶ月の間に、次のスプリントでやる予定のストーリーの詳細な要件定義と仕様化、受け入れテストケース定義までを行うことでした。
その結果によってストーリーが大きくなった場合、スプリントに入れる予定だったストーリーを調整したり、仕様を軽めに変更したり、場合によっては初回リリースから外す、などの調整を行っていきました。
スプリントレビューの結果や、開発中に生じた問題などによって生まれた新しいストーリーは、企画担当者と協議のうえプロダクトバックログに入れ込んでいきました。

QA＆リリース準備期間

ここは基本的に「来た球を打つ」フェーズです。

従来この期間に不具合が多発し、QA対応に追われていたのですが、事前に十分なテストができていたおかげで、かなり平和な時期となりました。

おかげで開発ドキュメントの整備や、次以降のリリースにむけての準備を余裕をもって進めることができました。いままでの開発ではなかなかできなかったことです。。。

結果

プロジェクト全体はとても安定して進みました。
当初のスケジュール通りにリリースを完了でき、その後も不具合が（それ以前のプロジェクトと比べて）非常に少ない状態で運用できています。
いままでなら開発期間の終盤～QA期間は連日の深夜残業、休日出勤待ったなしだったところ、期間全体にわたって残業は少なく休日出勤もありませんでした。

開発メンバーは最初こそ戸惑いが大きかったり、手探り状態で試行錯誤が多く苦労しましたが、慣れてくるとスムーズにスプリントがまわるようになり、ベロシティも上がっていきました。
話し合いが活発になり、状況をみてみずからタスクを取っていく流れも徐々に生まれていきました。

Scrumによる開発の進め方は、企画担当の方々にも思いのほか好評でした。毎月のスプリントレビューにより成果が確認できるため「待っていたらほんとにちゃんと出来上がるのか」という不安が軽減されたそうです。また開発メンバー自身がデモを行ってディスカッションすることで、いままで見えにくかった開発者の顔が見えるようになり、意思疎通がしやすくなりました。開発メンバー側にとっても企画の意図をくみ取ることができるようになり、仕様の齟齬がだいぶ軽減されるようになりました。

やってよかったこと

はじめてScrum導入を導入した開発プロジェクトは、想像以上にうまくいったと感じています。
開発メンバーがアジャイル開発やScrumを理解し、高いパフォーマンスを出したことがいちばん大きいのですが、Scrumによる開発の進め方にはいろいろな利点があると感じました。

調整しやすい

スプリントごとに「いまどれだけ出来ているか」を確認し、「このペースでいけばいつ頃開発が終わりそうか」を予測するタイミングが持てるため、進捗があぶないかどうかを早めに察知することができます。
開発フェーズ全体でこれを見ようとすると、開発フェーズの後半～終了間際にならないと危険を察知できず、そのころには仕様のドロップや優先順位変更などの調整が難しくなってきてしまいます。

逆に「予定外の要件を盛り込む」こともしやすくなりました。スプリントレビューで出た要望や、開発途中で必要にせまられた仕様変更が発生したとき、それが安全に追加できるかどうかが開発途中の時点で判断しやすかったです。またストーリーが基本的に「完全に動作する1つの機能」で構成されていたため、取捨選択もわかりやすくできました。

品質を管理しやすい

スプリントごとに結合テストまでを行い、「完全に動作する」ことを確認するため、機能の不具合をかなり早い段階で検知して修正することができます。
また、不具合が発生したときに「いつどこで発生したか」が該当スプリントのストーリーに限定されるため、原因を特定しやすいという効果もありました。

スプリントを計画するために必要な「スプリントに収まるサイズにストーリーを分割する」という作業も、品質管理には良い影響があったと感じています。大きな1つの機能ではなく、小さく分割して実装・テストを行うことで、個々の機能について設計の見通しもよくなりました。

コンスタントに成果を出せる

プロジェクトの成果を待っている顧客（今回の場合は企画担当）に対して、こまめに「実際に動く機能を見せられる」というのは、大きな安心感につながります。長い開発期間を報告だけ聞いて待っていて、仕上がってきたものが予想と異なる、、、という不幸な事態も、こまめに確認タイミングをとることで予防できます。

開発メンバーにとっても、成果を目に見える形で顧客に伝えられること、また顧客からすぐにフィードバックを受けられることで、納得感の高い開発ができるようになり、「顧客が望むもの」を目指して開発する意識が高まったと思います。

残業が減った

スプリントごとに「このスプリントでは誰がどれだけ動けるか？」を見積もって計画を立てるため、あるメンバーがほかの案件対応で稼働低めになる、あるメンバーが休暇をとる、大型連休がある、といった状況の変化にあわせた無理のすくない計画にすることができます。
スプリントの中で短期的にがんばる残業は時折ありましたが、全体としてはかなり残業時間が減り、健全な開発ライフを送ることができたと思います。

健全なシステムは健全なプロジェクトに宿ります。

課題

もちろん、進めていくうちにいろいろな課題もありました。いくつかの課題とその対策を記しておきます。

メンバーの出入りやプロジェクト兼務

「いったん結成されたScrumチームはメンバーの入れ替えをしない」というのが大原則なんですが、、、まあ、なかなかそういうわけにもいかないんですよね。契約形態や期間ももさまざまだったり、他のプロジェクトに持っていかれたり、かといってストーリーを大きく減らすのは難しいし（まとまったリリースを予定するプロジェクトであればとくに）

また、複数のプロジェクト掛け持ちや突発のタスクも、できるだけ排除したいところですが、キーパーソンになるほどそうもいかない。

対策として、途中から合流するメンバーのために、アジャイル開発やScrumの説明、チームのプロセスやルールをまとめた資料をつくり、合流時に説明会を設けるようにしました。
掛け持ちについては、ほかのプロジェクトのほうが多忙になる時期を確認・調整し、スプリント計画時に消化可能なベロシティの見込みを少なくとるようにしました。

ステークホルダーの理解

今回の顧客となった企画担当の方は、別の運用案件でScrum開発に触れていたため、プロジェクトをScrumで進めることも比較的すんなりと理解してくれました。
が、多くのケースでアジャイル開発やScrumの導入障壁となるのはだいたいここではないかと思います。。。
（顧客だけでなく、上司やプロジェクトマネージャーも不安に感じるところ）
ここは上手に説得するほかないのですが、

• 開発を進めながら、精度の高い進捗の把握や予測ができる
• （間に合わなくなって要件を削るだけではなくて）途中で必要になった要件を柔軟に入れ込むことができる

といった、顧客にとってのメリットを伝えて理解してもらうことが必要かなと思います。

次にやることがない

最初のリリースでは最初にまとまった見積もり期間を設けましたが、それ以降のリリースでは「要件を出しながら、見積もりしながら開発していく」というスタイルに移行しました。
そのとき困ったのが、次のスプリントで対応予定のストーリーが足りない、見積もりを行うには要件の精査が不十分、、、という状況になることでした。

これを改善するため、1～2週に1回「次のスプリントの話をする時間」を設けました。
この時間でバックログを確認し、次のスプリントで対応しそうなストーリーの見積もりや、見積もりのために必要な調査項目の洗い出しを行い、スプリントの空き時間で対応する流れにしました。

振り返って

かけだしスクラムマスターなのに、いきなり大きめの案件に導入を試みるのはすごく冒険的でしたが、それまでのウォーターフォール型開発で抱えていた課題の数々がクリアできて、思い切って導入してよかったなと心から思いました。
提案を受け入れてくれた当時の上司やプロジェクトマネージャー、プロセスに理解を示してくれた企画担当の方々、なにより新しい取り組みに賛同してくれて高いモチベーションとパフォーマンスを発揮してくれたScrumチームのメンバーには感謝が尽きません。

ちなみに現在アイスタイルでも、わりと大きな案件をScrumで開発しています！
この記事の事例とはスタイルがまた全然違い、1週間スプリントで、ストーリーの粒度もずっと細かい感じで進めています。
それぞれのスタイルでの良い点、改善点をもとに、よりうまい開発スタイルを模索していきたいな、と思っています。

というわけで、迷ってるみなさま、大規模案件でも意外とアジャイル開発できちゃうので、思い切ってはじめてみるのが一番かと思います！
開発プロセスを選択する立場にない方も、やってみたいと思ったら、自分から提案してねじこんじゃいましょう〜〜