
Introduction
ビジネス環境の変化が激しい今日。プロダクト・ライフサイクルを意識し、市場のニーズに迅速に応えるための開発の効率化はソフトウェア開発の課題の一つといえます。その課題に対応する方法として主流となりつつあるのがアジャイル開発です。このコラムでは、アジャイル開発の概要や手法、メリットやデメリット、そしてアジャイル開発に適しているプロジェクトについてもご紹介します。
目次
アジャイル開発とは
アジャイル開発とは、システムやソフトウェア開発におけるプロジェクト開発手法の一つです。チームを組み、要件定義、設計、開発、テスト、リリースといった開発工程を、一つひとつの小さな機能単位で繰り返し行い、文字通り「アジャイル(Agile)」=「素早く」、ユーザーを巻き込みつつ、機能をブラッシュアップしながらプロダクトを完成させていく、軽量な開発手法のことをいいます。
アジャイル開発は、2000年代に開発手法として採用されるようになり、今日では主流の開発手法の一つとなりつつあります。例えば、当社が行った調査によると、調査対象のうちの74%が「アジャイル開発を導入済み」、あるいは「導入を検討中」、「導入予定あり」と回答していることからも、この傾向を理解することができます。
アジャイル開発の導入状況のほか、導入の目的や効果、開発対象としているシステムといったこともご紹介しています。下記ページから資料をダウンロードいただけますので、参考にしてみてください。
アジャイル開発白書

近年、市場の変化スピードやニーズに対応するために高速リリースの重要性が高まり、アジャイル開発を導入する企業が急速に増えています。そこで、SHIFTでは、アジャイル開発を検討中、導入済の企業に対し、課題や成果、プロジェクト体制などについての調査を行い、これから導入される企業様、既に導入されている企業様のプロジェクト成功にお役立ていただけるよう調査資料にまとめました。
近年、市場の変化スピードやニーズに対応するために高速リリースの重要性が高まり、アジャイル開発を導入する企業が急速に増えています。そこで、SHIFTでは、アジャイル開発を検討中、導入済の企業に対し、課題や成果、プロジェクト体制などについての調査を行い、これから導入される企業様、既に導入されている企業様のプロジェクト成功にお役立ていただけるよう調査資料にまとめました。
アジャイルソフトウェア開発宣言について
軽量のソフトウェア開発を実践、提唱していた17人の技術者やプログラマーが集まり、2001年に議論をして生まれたのが「アジャイルソフトウェア開発宣言」です。この宣言は、アジャイル開発とそれに基づく12の原則を定義していることもあり、アジャイル開発の公式文書として広く知られています。
例えば、この宣言の12の原則には、次のようなものが記されています。
「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」
「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」
この原則にもあきらかなように、アジャイルソフトウェア開発宣言には、アジャイル開発のポリシーとともに、この開発によってユーザー(顧客)にもたらされる「価値」が記されているともいえます。したがって、アジャイル開発を進めるプロジェクトの関係者は、この宣言に記されていることを念頭にして、プロジェクトを推進することが求められるといってもいいかもしれません。
ウォーターフォール型開発とアジャイル型開発との違い

あらかじめすべての開発工程の計画を立て、要件定義、設計、開発、テストという工程を順番に完了させ、最後にリリースするというウォーターフォール型の開発と異なり、アジャイル開発では、1週間から2週間程度のサイクルの中でこれらの一連の工程が完結するように機能を小分けにした開発を繰り返し、プロダクトを完成させるという特徴があります。なお、この小さな単位の開発はイテレーションやスプリントといわれます。決まったイテレーションサイクルの中で、チームのベロシティにあった複数のユーザーストーリーを順番にもしくは並列して実装します。
ウォーターフォール型の開発の場合、開発当初の要求に従って、開発の範囲や計画を定め、工程ごとのリソースを確保し、計画に従って工程を進めていき、プロダクトを完成させます。そのため、開発途中に要求の変更があった場合や、仕様変更が入った場合などには、追加の費用や開発期間が発生する可能性があります。
これに対して、アジャイル開発の場合は、まず大まかな計画を立て、チームを組み、機能単位での小さな開発サイクルを繰り返していきます。チームにアサインされるメンバーは、設計、開発、テストといった複数の工程を担います。プロダクトの完成までの工程では、仕様変更の確認や要求についてのフィードバックなどを臨機応変に受けながら進めるため、ベロシティの範囲内で最適解を求めながら開発を進めることができる手法だといえます。
関連サービスについて
アジャイル開発の流れ
続いて、アジャイル開発がどのような流れで進められるのかについて見ていきましょう。
リリース計画を立てる
まず始めに、いつまでにどの機能をリリースするかのおおよその計画を立てます。アジャイル開発の前提として、プロジェクトを進める中で設計や仕様の変更は発生するので、リリース計画はあくまでおおよその計画であり、状況に応じて継続的に修正を行う必要があります。
リリース計画を立てるにあたっては、以下の要素が必要となります。以下の要素を踏まえ、どの機能がいつまでにリリースするのかを計画に落とし込みます。
プロジェクトのゴール
このプロジェクトでは何を実現するのか、目標・ゴールを明確にします。
イテレーションの長さ
イテレーション(iteration)とは、「反復・繰り返し」という意味で、アジャイル開発においては、要件定義・設計・実装・テスト・リリースの1サイクルを指します。イテレーションの期間は1~4週間が一般的で、イテレーションごとに機能をリリースします。イテレーションの期間はプロジェクトによって異なります。
また、アジャイル開発の一つの手法であるスクラムにおいては、イテレーションではなくスプリントと呼ぶのが一般的です。
ベロシティの算出
ベロシティとは、1イテレーションにおいてチームがどのくらいの開発ができるかを数値化したものです。
ユーザーストーリーの優先順位と工数
ユーザーストーリーとは、ユーザーがどのような目的で、何を実現したいのかを文章で簡潔にまとめたものです。アジャイル開発では要件の代わりによく使われます。ユーザーストーリーに優先順位を付け、それぞれどれくらいの工数が必要となるのか見積ります。
イテレーション
リリース計画を立てたら、開発に移ります。アジャイル開発では、イテレーションと呼ばれる要件定義からリリースまでの短期間での開発サイクルを繰り返していきます。リリースした機能を確認し、顧客からのフィードバックや修正・不足事項は次のイテレーションに反映し、プロダクトを作り上げていきます。
アジャイル開発の手法
アジャイル開発の手法の代表的なものとしては、「スクラム」、「エクストリーム・プログラミング(XP)」、「ユーザー機能駆動開発(FDD)」といったものがあります。実際の開発現場では、これらの代表的な手法を部分的に併用して進めることになります。
ここでは、当社の調査のなかで、開発経験がある企業の約85%が開発手法として採用していると回答していた「スクラム」を中心に紹介します。
スクラム
スクラムとは、アジャイル開発のフレームワークの一つとして位置づけられるものです。プロダクトオーナー、スクラムマスター、開発者が10人以下のチームを組み、機能単位で「計画、設計、開発、テスト」、そしてリリースのサイクル(スプリント)を繰り返し、プロダクトを完成させます。
ユーザーを巻き込みながら開発することで、顧客の価値を最大化しつつ、素早く、動くプロダクトを完成させることが特徴といえます。
スクラムを行う上で参照されることの多い「スクラムガイド(日本語版)」には、スクラムのプロセスとして次の5つを挙げています。
ここでは、ガイドに従ってこの5つのプロセスについて紹介します。

1.スプリントプランニング(スプリント計画)
スプリント計画は、スプリントの起点として位置づけられるスプリントで実行する作業の計画を立てるプロセスです。スプリントの計画は、チーム全体の共同作業で作られます。
スクラムオーナーは、プロダクトのゴールとそのための手順などに基づいて、スプリントに関わるチームのメンバーが、そのスプリントで何を実現するのかを理解するよう促します。
チームのメンバーは、チーム全体でそのスプリントが実現することの意味を理解し、スプリントゴールを定義し、ゴールに至るまでに何をなし遂げるのかを決めます。
2.スプリント
スプリントは、計画に基づき、設計、開発、テストを行い、機能をリリースするプロセスです。スプリントの期間は1ヶ月を上限として定められています。スプリント期間中には、後述するようなデイリースクラム、スプリントレビュー、スプリントレトロスペクティブ(振り返り)を行いながら、プロダクトを完成させていきます。
なお、スプリントにおいては、ゴールの達成を危険にさらすような変更はしないことなどが原則として定められています。
3.デイリースクラム
デイリースクラムは、スプリントを円滑に進めるためのコミュニケーションのプロセスです。1回を15分程度のイベントとしています。無用な混乱を招かないように、定例朝会といったような形式で、スプリントの期間中、毎日、同じ時間・場所でやることが推奨されています。デイリースクラムでは、進捗状況や課題を共有することで現状を把握します。
4.スプリントレビュー
スプリントレビューは、スプリントの成果物を検査したり、評価したりする、いわゆるレビューのプロセスです。スクラムのチームだけではなく、ユーザーも参加することで行われます。
レビューによっては、プロダクトバックログの項目が追加、削除されたり、ゴールに向かう最適な手順への入れ替えが行われたりということもあります。いずれにしても、限られた時間やコストのなかでプロダクトの価値を最適化させることを目指して行われるのがこのプロセスです。
5.スプリントレトロスペクティブ(振り返り)
スプリントレトロスペクティブは、「品質と効果を高める方法を計画する」プロセスのことです。スクラムによってもたらされた効果(価値)や、プロダクトのゴールに向かうためのチームの品質(状態、コミュニケーションのあり方など)も含めた計画を行います。
スプリントレトロスペクティブは、スプリント終了時に行われます。ここでは、スプリントを振り返り、進捗に影響したものを特定し、原因を探求していきます。また、発生した問題、その解決方法を明確にするように話し合い、品質と効果を高める方法を明確化していきます。
***
なお、スクラムの成果物のうち、重要なものとしては、次の2つがあげられます。
プロダクトバックログ
プロダクトバックログは、機能や改善が必要なものについて優先順位をつけ、記述したものです。優先順位をつけることで、今回のスプリントで対応する機能、次回のスプリントで対応する必要がある機能といったことを明確にできます。また、プロダクトバックログは、ステークホルダーがプロダクトの状況を把握することにも用いられます。
スプリントバックログ
スプリントバックログは、プロダクトバックログから、スプリントのチームが対応する期間の分を選択、抽出したタスクのリストのようなものです。わかりやすくいえば、スプリントの開発計画ともいえます。
エクストリーム・プログラミング(XP)
エクストリーム・プログラミング(Extreme Programming:XP)とは、開発者を中心とした開発手法のことです。
機能単位で設計、開発、テストというイテレーション(反復)を繰り返すなかで、2人1組でコーディングとレビューを同時に進行させる「ペアプログラミング」を行ったり、チーム内で定める自己文章化を推進しコメントを減らす「コーディング規約」などに基づき開発を行ったりすることで、効率的な開発を行えるようにするところが特徴といえます。
また、仕様変更や追加を前提として位置付けていることが特徴ということもあり、ユーザーからの要求を、勇気をもって柔軟に受け入れ、開発することが重要な要素の一つともいえます。
ユーザー機能駆動開発(FDD)
ユーザー機能駆動開発(Feature Driven Development)とは、ユーザーにとっての機能価値(feature)というものを中心とした開発手法のことです。実際に動く機能のリリースを一定の間隔内で繰り返し、プロダクトを完成させていきます。
機能を開発する前提として、ユーザー側のビジネスモデルを理解し、ログイン機能、ユーザー登録機能といった機能単位で設計、開発、テストを行っていくことが特徴的です。
関連サービスについて
アジャイル開発のメリット・デメリット
アジャイル開発の概要や特徴、そして開発手法についてこれまでご紹介してきました。次に、アジャイル開発のメリット・デメリットについて触れていきたいと思います。
アジャイル開発のメリット
アジャイル開発の場合、機能単位で設計、開発、リリースを行うことができるので、スピーディーにプロダクトや機能をユーザーに提供できるというメリットがあります。
また、ユーザー側の要求を取り入れながら開発できるため、開発側にとってもユーザー側にとっても開発意図にかなった価値の高いプロダクトや機能をリリースできることもメリットといえます。
さらに、都度要求を確認しながら小さい単位で開発ができるため、手戻りが少なく、工期、コストを抑えた開発ができることもメリットです。
アジャイル開発のデメリット
アジャイル開発のデメリットとしては、柔軟性があることが影響して、開発の方向性がぶれてしまうということが考えられます。しかも、変更や追加を受け入れながら開発するため、かえって工期が長くなってしまったり、コストが予想よりも高くなってしまったりとうことも懸念点です。
また、小さな機能単位での開発に目が奪われてしまうことで、全体のスケジュール感が把握できなくなってしまうということも考えられます。
そのようなことにならないようにするためには、例えばプロダクトバックログを参照し、この機能は、「どのような価値をもたらすものか」、「何のためにあるのか」、「いつまでにリリースする必要があるのか」といったことに絶えず立ち返り、プロジェクト全体をコントロールしていくことが重要といえます。
アジャイル開発が向いているプロジェクト
アジャイル開発には、以上のようなメリットがあるといわれていますが、この開発手法がすべてのシステムに対応するとはいいがたいところもあります。
アジャイル開発が向いているものの代表例は、Webサービス(EC、SNSなど)、Webアプリやスマホのアプリ、ゲームなどのように、頻繁に新しいサービスが開発され、またプロダクトのライフサイクルが早いものだといえます。当社が行った調査でも、アジャイル開発を経験している企業の9割近くが、WebサービスやWebアプリの開発についてアジャイル開発を行っていることからも、これらのシステムがいかにアジャイル開発に向いているのかを理解することができます。
Webサービスやゲームなどの場合、開発中やリリース後にユーザーのニーズが変わってしまうことも多く、その変更に柔軟な対応が必要なことがあります。また、類似するサービスも多く存在するため、サービスのコモディティ化が起こりやすく、いかに迅速にサービスをリリースし、ユーザーの反応に応じながら迅速にシステムを改善していくかといったことが、サービスをマネタイズするうえで重要な要素といえます。
このような場合、計画をじっくり立て、それに合わせてリリースしていくといった開発手法よりも、変化を前提とした開発手法の方が向いているということができるでしょう。

アジャイル開発の導入状況のほか、導入の目的や効果、開発対象としているシステムといったこともご紹介しています。下記ページから資料をダウンロードいただけますので、参考にしてみてください。
まとめ
今日、アジャイル開発は、ソフトウェア開発の開発手法として認知され、多くの企業で採用されるようになりました。
アジャイル開発は、手法とともに、その思想が広がり、プロダクトの価値を最大化させるといったメリットを享受できている企業も増えてきていることかと思います。
一方で、当社の調査では、アジャイル開発を導入したものの、「組織・顧客との間での理解不足」「人材の確保や育成」といったことが課題となり、アジャイル開発について、満足できる結果を得られなかった企業も、少なくはないということが明らかになっています。
つまり、コスト削減や工期を短縮させたいという目的のもと、すべてのプロジェクトでアジャイル開発を採用したほうがよいというわけではないようです。重要なのは、自社が開発するシステムの特性に合わせて、適した開発手法を選択することなのかもしれません。