アジャイル手法について知っておくべき3つのこと

アジャイル手法は、絶えず変化する市場のニーズに素早く対応したいと考える技術系企業に適した手法であり、近年、規模を問わず様々なソフトウェア開発に活用されています。
アジャイル開発を採用することで、開発チームは迅速な反復サイクルで製品を作り、テクノロジー業界の変化に容易に適応することができます。

VersionOne 社のState of Agile Report 2018年版によれば、「何らかの形でアジャイル手法を実践している」と回答した組織はアンケート対象の97%にのぼりました。 しかし、アジャイル手法が広く受け入れられる一方で、アジャイルの概念については間違った解釈をされることも少なくありません。そもそも「アジャイル」とは、手法やプロセスを指すものではなく、アジャイルによってもたらされる価値や実践すべき原則を示したものです。

1. アジャイルの歴史

Photo by İrfan Simsar on Unsplash

1970年代から2000年頃までの間に、従来の製品開発プロセスがソフトウェア開発においては機能しないことが明らかになりました。 ソフトウェアプロジェクトが完了する頃にはビジネスニーズがすでに変化していた、ということが頻発し、いわゆる「アプリケーション開発の危機」あるいは「アプリケーションの完成までのずれ」などと言われました。プロジェクトが途中でキャンセルされり変更を求められることが続き、開発者たちはもっと良いやり方を探す必要に迫られました。

その後、業界が市場に適応できないことに不満を抱いた17人の思想的リーダーが集まり、ソフトウェアを開発するより良い方法について議論し、2001年に「アジャイルマニフェスト」をまとめました。彼らの定義した以下の4つの価値と12の原則は、多くのソフトウェアチームに採用され、製品を常に最新の需要にキャッチアップさせるために役立っています。以下に引用しましょう。

4つの価値

  • プロセスやツールよりも個人と対話を、
  • 包括的なドキュメントよりも動くソフトウェアを、
  • 契約交渉よりも顧客との協調を、
  • 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

12 の原則

  • 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
  • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
  • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
  • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
  • 動くソフトウェアこそが進捗の最も重要な尺度です。
  • アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
  • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  • シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

© 2001 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

この理論を実践することにより、開発チームは常にニーズにキャッチアップした状態であり続けることができます。 顧客と頻繁に連絡を取ることで、顧客のターゲットが変化したとしても、その新しいターゲットに合わせて開発を続けることができるためです。また、 新しい状況に合わせて開発のプロセスや実践方法を簡単に変更することができ、開発の成果を小さな単位でスピーディーに顧客へ提供することができます。 これにより、コスト増のリスクが大幅に軽減されます。

よく「アジャイル手法」とよく言われますが、先にも述べたように、実はアジャイルの概念は特に手法を定義していません。 理想的には、各組織が4つの価値と12の原則を用いて、独自の作業プロセスを構築するのが望ましいと言えますが、実際には過去に構築された手法のうちのいくつかが普及しており、アジャイルの価値や原則よりも広く知られています。以下で紹介しましょう。

2. アジャイル手法の例

現在最も広く使用されているアジャイル手法はスクラム(Scrum) です。スクラムを一言でいえば、「明確に定義された目標に向けてチームワーク、アカウンタビリティ、反復的な進捗、を強調するプロジェクト管理フレームワーク」です。これは、アジャイルの12の原則をプロジェクト管理に適用するために一般的に使用されている「ベストプラクティス」と言えます。

スクラムチームは、「プロダクトバックログ(Product Backlog)」と呼ばれるTo Doリストから作業します。プロダクトバックログには、市場の要求に応じて動的に変化する機能、要件、バグ修正などが含まれており、プロダクトオーナーによってタスクの優先順位づけや整理が行われます。開発は2から4週間程度の「スプリント(Sprint)」という期間でおこなわれます。スプリントには目標や、その期間でリリースされる製品(機能) が設定されます。一日の初めにチームで「デイリースダンドアップ(Daily Stand-up)」と呼ばれる短いミーティングを行い、ここで各自が現在取り組んでいることと、なにか作業の障害になっているものがないか確認します。各スプリントの最後に、チームは「スプリントレビュー(Sprint Review)」と「レトロスペクティブ(Retrospective: 振り返り)」を行い、完了した作業の確認と、次のスプリントに向けての改善方法を議論します。

カンバン(Kanban)もよく知られています。カンバンでは、スクラムと同じようにチームのTo Doリストを使いますが、より柔軟な管理手法といえます。カンバンボードは、すべてのタスクが視覚的に配置された実際のボードまたは仮想ボードであり、To-do、In Progress、Doneのステータスに基づいて列毎にまとめられます。チームメンバーは、未解決のタスクとそれぞれの優先順位を簡単に確認できます。タスクの割り当ては、リーダーが行うこともあれば、各チームメンバーが自ら選択することもあります。チームメンバーが自走できることが、カンバンフレームワークの主要な利点の1つと言えるでしょう。またプロセスが簡単であるため、アジャイルに移行するのが不安な組織にも向いています。

他にも、Extreme Programming(XP)、Crystal、Dynamic Systems Development Method (DSDM)、および機能駆動開発(Future Driven Development: FDD)などのアジャイルフレームワークがあります。

3. アジャイル手法をいつ採用するか

アジャイルの原則とここまでに紹介したフレームワークは、製品要件が頻繁に変化しがちなチームに特に役立ちます。アジャイルはあらゆる段階で利害関係者からのフィードバックを簡単かつ迅速に実装するために役立ちます。

逆に言うと、アジャイルの原則は、要件が非常に明確であったり、類似製品の再開発だったり、変更に承認等手続きが要るような安定・確立された開発環境では、あまり活用できないかもしれません。

もしあなたのチームが前者であれば、ぜひアジャイル手法の導入を検討してみてください。