アジャイル開発とは、顧客にとって価値のあるプロダクトを素早く継続的に提供するための開発手法です。アジャイル開発がどのようにしてうまれたのか、アジャイル開発で用いられるフレームワークについてわたしたちの事例も交えてまとめてみたいと思います。
目次
ウォーターフォール開発とアジャイル開発の違い
ウォーターフォール開発とは
アジャイル開発とよく比較されるのがウォーターフォール開発です。ウォーターフォール開発は、仕様をすべて決めてから開発をスタートします。
それぞれの工程にそって開発を進めていくため、途中で前の工程には戻らないしくみとなっています。
私たちも受託開発ではウォーターフォール型で開発をしていました。顧客から発注をいただいて仕様を決める。仕様にそって設計、開発、テストを行い納品する、という流れです。
ウォーターフォール開発は開発の計画や予算の見積りがしやすいため、受託案件にマッチした開発手法です。しかし一方で次のような課題もありました。
課題１：最終的な受入テストになって顧客が求めていたものと開発したものが違っていることが判明した
ウォーターフォール開発では全工程が終わった後に動くソフトウェアを顧客が触ることになります。実際に動くものにふれてはじめて、意図していたものと違っていた、やりたいことが実現できないことがわかった、といったことが起きました。修正にかかる時間やコストが膨らんでしまうため、お互いの妥協点を探すことになります。
課題２：細かな仕様の調整により開発が遅れてしまう
ウォーターフォール開発は最初に仕様をすべて決めることが前提になります。しかしどうしても設計や開発をする中で仕様のもれに気づくことがあります。また、こまかな設計について顧客とやりとりするなかで、この仕様はこういう意図だった、と認識の違いが起きていたことが判明することもあります。このような理由により予定していた開発スケジュールに遅れが出ることがありました。
アジャイル開発とは
アジャイル開発は仕様を柔軟に変えられるよう、短い期間でテストと実装を繰り返していく開発手法です。ウォーターフォール開発に比べ、より速いスピードでプロダクトを提供できるメリットがあります。
ただ、最初に成果物の範囲やスケジュールを決めることが難しく、顧客の理解・積極的な参加も必要なため、案件やプロジェクトによって向き不向きがありそうです。
そんなアジャイル開発が広く知られるようになったきっかけは「アジャイルソフトウェア開発宣言」が出されたことでした。
アジャイルソフトウェア開発宣言
17名の著名なソフトウェア開発者が集まり、それぞれの主義や手法についての議論をおこない、2001年にアジャイルソフトウェア開発宣言が公開されました。
アジャイルソフトウェア開発宣言にはここにあげられた4つの価値、
- プロセスやツールよりも個人と対話を、
- 包括的なドキュメントよりも動くソフトウェアを、
- 契約交渉よりも顧客との協調を、
- 計画に従うことよりも変化への対応を、
とその背景にある12の原則が含まれます。
アジャイル宣言の背後にある12の原則
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
アジャイルを実践するためのさまざまなフレームワークもこの価値、原則に基づいています。アジャイルに迷ったり悩んだときには、なんどもここに立ち返ってくることになります。
この宣言の詳しい解説はIPAが出している「アジャイルソフトウェア開発宣言の読みとき方」が参考になります。アジャイルを成功させるためには開発者だけでなくビジネス側の人もアジャイルを理解しておく必要があることがわかります。
アジャイルの参考書
これからアジャイルを始めるときに参考になる本をいくつか紹介します。
アジャイルサムライ
アジャイルを導入するにあたっての具体的なノウハウが書かれています。アジャイル開発を導入する際には一度目を通しておくと、アジャイルの全体像がつかめるかと思います。
アジャイルプラクティス
アジャイルを導入したチームのエンジニア向けの実務的なレベルでの具体例が載っています。アジャイル開発をしていくなかで「こんなときはどうすればいいんだろう」といった疑問がうかんできます。そのタイミングで読むのがおすすめです。
アジャイル開発のフレームワーク
ここからはアジャイル開発によく用いられるフレームワークをいくつか取り上げます。ここにあげたもの以外にも、いろいろな視点でのアジャイルフレームワークがあります。
カンバン
カンバンとは、チームの状態を見える化し、その流れを継続的に改善する管理手法です。
カンバン方式の主な目的は、WIP（進行中の作業）の上限を管理できるようにすることです。
わたしたちがカンバンを導入したのは2015年になります。カンバンを導入するまでは、ひとりが複数のチケットを同時に進めていて、数日たってもどのチケットも完了していないということが起きていました。
現在は進行中のチケットはひとり1つまでと決めて運用しています。カンバンを見ることでそのルールが守られているかがひと目でわかります。
カンバンの課題
カンバンはスクラムと異なりサイクルを回すための期間は定められておらず、継続的なフローの中で改善を行っていくことになります。継続的に改善をしていけるチームであれば問題ありませんが、定期的に見直しが行われないと数週間経過しても進行中の作業が変わらないまま、ということも発生してしまいます。
スクラム
スクラムは「チームワーク」と「コミュニケーション」を重視し、チームで仕事を進めるための開発手法です。3つのロール、4つのイベント、3つの成果物が定義されています。
スクラムについては別のエントリーで詳しく説明しますので、ここではカンバンとの比較をしてみたいと思います。
| スクラム | カンバン | |
| ソース | ソフトウェア開発 | リーン生産 |
| 考え方 | 経験を通じて学び、自立的に取り組んで優先順位付けし、成功した点と失敗した点を振り返って、継続的に改善する | ビジュアルを利用して、進行中の作業を改善する |
| 期間 | 一定の固定長のスプリント (2 週間など) | 継続的なフロー |
| 実践 | スプリント計画、スプリント、デイリー スクラム、スプリント レビュー、スプリントの振り返り | 作業フローの可視化、進行中の作業の上限設定、フローの管理、フィードバック ループの組み込み |
| 役割 | プロダクトオーナー、スクラムマスター、開発チーム | 役割は不要 |
スクラムは役割をはじめとして一定のルールがありますが、カンバンは柔軟でなじみやすいのが特長です。プロセスを改善したいならカンバン、開発スピードを上げたいならスクラム、のように目的に合わせて手法を選ぶことで効果がでます。
まずはカンバンを導入することでプロセスの可視化と最適化をする、その上で一定のサイクルで成果を出せるようスクラムを導入するというのがおすすめです。わたしたちも2015年にカンバンを、2017年にスクラムを導入しています。カンバン導入からスクラム導入まで2年かけていますが、もう少し早くスクラムを導入してもよかったなと感じています。
エクストリームプログラミング（XP）
エクストリームプログラミング（XP）はスクラム同様に柔軟に計画を変更しながらシステム開発を進めるためのフレームワークです。ソフトウェア開発に固有のプラクティスが用意されているのが特長です。XPでは5つの価値と19のプラクティスが定義されています。
わたしたちのチームではXPを導入していませんが、プラクティスとして導入しているものがあるため触れてみたいと思います。
テスト駆動開発
テストを書いてから実装をする方法です。テストを先に書くことで求められる機能が明確になり、よりシンプルな設計ができるようになります。
まだ一部でしか導入できていませんが、データの整合性が重要となる箇所を中心にテストコードを書くようにしています。
ペアプログラミング
２人１組でプログラミングを行うことです。ひとりがコードを書き、もうひとりがそれを支援します。コードを書いている途中で出てくる細かな問題についてその場で確認しながら進めることができるため、エンジニアの成長による中長期的な生産性にもつながることが期待できます。
ペアプログラミングにはメリットとデメリットがあり判断が非常に難しいところですが、以下の理由から現時点では導入をしていません。
- 初心者同士のペアの場合にお互いを正しく支援することができない
- ペアを組む2人のレベルの差が大きいと、上級者側にとっては教えるだけの時間になってしまう
- コードを書いている途中に出てきた問題によってはプロダクトオーナーに確認を取らないと判断できないものも多く、2人だけで解決できない
これらの理由によりペアプログラミングは行っていませんが、コードレビューを手厚くすることでフォローしています。
リファクタリング
技術的負債は積極的に返していきたいという思いはありますが、ビジネス的な観点でリファクタリングの判断を行っています。リファクタリングすることで今後の機能開発や機能拡張のスピードが上がり、結果的にユーザーに新しい価値をもたらすという判断ができる場合にリファクタリングをしています。
ソースコードの共同所有
GitHubでソースコードを管理し、お互いにコードレビューをすることでコードの品質を保っています。
継続的インテグレーション
プルリクエストのマージ時に自動ビルドをしています。また1日1回静的解析を行っています。
YAGNI：You Aren’t Going to Need It（今必要なことだけ行う）
必要以上の機能を実装しないで必要最低限のことだけ行うルールです。
汎用的に使い回せるような設計・実装をしたくなりますが、そうするとどうしても開発工数が大きくなってしまいます。その機能が本当にユーザーに価値を提供するかリリースしてみるまでわからないことが多いため、開発時のルールとして以下のように定めています。
- 汎用性や拡張性を最初の段階で求めず必要なタイミングで必要な拡張を行う
- 他の機能との関係性を疎結合なつくりにする
大規模開発向けフレームワーク
Scaled Agile Framework® (SAFe®)やLarge Scale Scrum (LeSS) などに代表されるようにエンタープライズ規模の開発でもアジャイル開発が取り入れられるようになってきました。大規模開発でもスクラムをベースにしたものが多いようです。各フレームワークの概要は大規模アジャイルフレームワークの紹介やアジャイル開発の代表的なスケーリング方法まとめがわかりやすくておすすめです。
わたしたちのチームはまだ2枚のピザを分け合える人数ですが、これからメンバーが増えてきたらチームをわけて開発をしていくことになります。サーバーサイド、フロントエンド、スマホアプリ、インフラのように職能別にチームを分ける方法もありますが、今のところ機能別にチームを分けたいと考えています。
機能ごとのチームにすることで、顧客にどんな価値を届けるか考えて開発をおこない、その後のフィードバックをもとにした改善までチームの中で完結できるようになり、継続的に価値を提供できる体制をめざしていけるのではないかと考えています。
そこに向け、まずは1つのスクラムチームで成果を出せるようにしていきたいですね。
一緒に働く仲間を募集しています。
新卒採用・中途採用を問わず、年間を通して、さまざまな職種を募集しています。「すぐに仕事がしたい」「話を聞いてみたい」「オフィスを訪問してみたい」など、ご応募をお待ちしています。共に未来をカタチにする仲間を待っています。
