アジャイルを始めて10年。ようやくアジャイル開発の目的がわかるようになってきた

ここ数年、ソフトウェア開発ではアジャイルやスクラムといった開発手法が採用されることが増えてきています。

「このプロダクト、チームにはアジャイルが合っている」と判断して取り組んでいる人はもちろん、「アジャイル開発がいろいろな問題を解決してくれそう」「スクラムがはやっているからやってみたい」と思ってはじめた人、「アジャイル開発にすれば開発スピードがもっと上がるんじゃないの？」「スクラムでやればすぐに成果が出るんでしょ？」と言われるがままに導入したという人、いろいろいるかと思います。

また「うちのチームもこれからやってみようかな」という人もいるのではないでしょうか。

今から10年前、わたしたちも当時かかえていた問題を解決したいという思いからアジャイル開発を導入しました。しかし、アジャイル開発の目的を正しく理解しないまま導入しても、残念ながらすぐには成果につながりませんでした。アジャイルで開発しているはずなのに1年たってもリリースされない。せっかくリリースしたのに誰にも使われない。そんなしくじりを通してアジャイルの理解を深め、ようやく成果が出てきはじめたところです。

遠回りした今だからこそ、アジャイル開発の目的をよく理解することが、アジャイルを成功させるためのいちばんの近道だったと感じています。

TOWNにおけるアジャイル開発

創業〜 ウォーターフォール型の受託案件

創業から9年間はウォーターフォール型の受託案件が中心でした。

仕様書、Excelによるスケジュールを提出し、要件定義→設計→開発→テスト→納品までを決められた納期までに完了する開発スタイルでした。開発期間としては数ヶ月から半年ほどの案件が多かったと記憶しています。

当時はタスク管理をRedmineでおこない、納品までに残りチケットが0になればよいため、バーンダウンチャートを見て開発の進み具合を確認していました。

2011年〜 自社製品の開発（アジャイル前夜）

じつは創業時から自社製品の開発をしていました。自社製品も開発しつつ、受託案件で利益を上げる体制です。それまではパッケージ版とカスタマイズ案件を中心に自社製品の開発をしていましたが、2011年にSaaS化しました。

しかしSaaS化したとはいえ受託案件のころと同じ開発の進め方をしていたため、次のような課題が出てきました。

このときのしくじり

• やることが山のようにあるため、Redmineに粒度の異なるチケットを山のように登録していた。（「スマホアプリを開発する」「〇〇の文言を変更する」が並んでいる状態）
• いつまでにどこまでを目指したいのか明確にできていなかった。
• チケットのスコープが甘いため見積もりも当然甘くなり、4時間の予定のチケットが4日たっても終わらないことが発生していた。
• そして工数を大きくオーバーしていることに気づいていなかった。
• チケットのステータスや分類、サブタスクによる細分化をして改善を試みたが、フローが複雑になっただけだった。

受託案件と異なり納期がなくなったため、成果物がいつまでたってもできあがらない状況になっていました。

2012年〜アジャイル開発の導入（フェーズ1）

私たちがアジャイルと出会ったのは2012年のことでした。アジャイルの定義を「実用最低限製品を短い周期で顧客へ公開し続けること」と定め、次のルールを決めました。

• プロジェクトマネージャー、チケット発行者などの役割
• チケットの粒度（1チケット4時間以内）
• チケットのステータス、分類の簡素化、サブタスクの廃止
• チケットの優先順
• チケットアサイン時のルール（1人で複数チケットを同時に担当しない）
• リリース周期と担当者

成果物がいつまでたってもできあがらない状況を改善するため、チケットの粒度とリリース周期を決めることで解決をはかりました。アジャイルの導入により一定のサイクルでリリースを行うことができるようになりました。

当時のチケット（イメージ）

条件に応じたチケットだけを表示できるようにカスタムクエリを用意して、チケット一覧画面で確認するようにしていました。

こなせるチケットが増えてくると新たに次のような課題が出てきました。

このときのしくじり

• チケット一覧表示だとプロジェクト全体の把握が難しい

2015年〜カンバンの導入（フェーズ2）

プロジェクト全体を見通しやすくするため、RedmineのAgileプラグインによるカンバンを導入しました。チケットの状況がひと目で分かるようになりました。

作業中、レビュー待ち、リリース待ちのチケットを同時に確認できるようになり、チケット同士の関連がわかりやすくなりました。作業中のチケットと着手可能なチケットの残り状況が把握しやすくなり、次の設計をはじめるタイミングがつかめるようになりました。

当時のカンバン（イメージ）

できたものからリリースしていくという点でようやくアジャイルっぽくなってきましたが、新たに次のような課題が出てきました。

このときのしくじり

• チーム全体で、どのくらいの力があって、どこに進んでいるかを把握しづらい
• 開発が進むときとそうでないときの波がある
• 時間単位での工数管理だとオーバースペックになっている
• 予定よりも時間がかかっているチケットを定期的に見直すタイミングがない
• リリース周期に合わせて、間に合うチケットを優先的にやってしまっていた
• タスクの目的を共有せずに、タスクをこなすだけになっていた

2017年〜スクラムの導入（フェーズ3）

「チームワーク」と「コミュニケーション」を重視し、チームで仕事を進めるための枠組みとしてスクラム開発を取り入れました。ルールとして次のように決めています。

• プロダクトへの要望を優先順位ごとに並べかえ、その順に機能を作る
• 1週間の単位で開発を区切り（スプリント）、その中で計画を立てる
• プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認しあう
• KPTを利用してふりかえりを行う
• チケットには1,3,5のいずれかのストーリーポイントを割り振る

1週間のスプリントでサイクルを回すようになり、開発に一定のリズムが生まれるようになりました。チケットの粒度を2日以内で完了するようにしたことで、スプリントごとのベロシティが安定し、小回りのきくチームになりました。

スプリントごとにアウトプットを継続して出せるようになり、スクラム最高！と思っていました。しかしこのとき私たちはまた新たな課題に直面します。

このときのしくじり

• 顧客のニーズに合わないものをつくり続けていた

2020年〜MVPアプローチの導入（フェーズ4）

1年かけて作った機能がほとんど利用されなかった経験から、アウトプットがアウトカムにつながるように改善をしました。

• 顧客からの要望を集計して開発優先度を決める
• 設計の段階でリリースノートを作成して社内に展開する
• 開発前にアンケートやヒアリングを実施してニーズの深掘りを行う（定性分析）
• 利用状況を測定してニーズを予測する（定量分析）
• 1ヶ月以内でMVP（Minimum Viable Product）を作成してフィードバックを得る

早く小さく失敗し、フィードバックで素早く軌道修正する体制を徹底しています。そして今もまだ継続的な改善の途中です！

アジャイルを始めてから10年、ようやく身に染みてわかったのです。

アジャイル開発の本当の効果を引き出すためには、アジャイル開発の目的を正しく理解することが重要だということに。

アジャイル開発の目的

アジャイル開発の最終的な目的は、顧客にとってのアウトカム、つまり成果を最大化することです。

ビジネスをとりまく環境は、年々その変化のスピードをあげています。激しく変化するニーズに対応するためには、ソフトウェアをいち早く開発し提供することが求められます。そのような背景からうまれたのがアジャイル開発です。

アジャイル開発とは、顧客にとって価値のあるプロダクトを素早く継続的に提供するための開発手法です。

誰にも使われない機能を素早く継続的に提供し続けていてもそれはアジャイル開発とは言えません。アジャイル開発に取り組む際には目的と手段の関係をつねに意識しておくことが大事になります。

アジャイルの基本的な考え方はシンプルでわかりやすいものの、実践するのは難しく、手法をまねするところから入りがちです。わたしたちはアジャイルをスクラムやカンバンと並ぶ開発方法の一つとしてとらえてしまったことでしくじりました。

今は考え方をアップデートして、顧客にとってのアウトカム（成果）を最大化するという目的のために継続的に改善を続けていくマインドセットこそがアジャイル開発の本質ととらえています。