アジャイル

アジャイルとアジャイル開発の違い|ソフトウェア開発に展開

agile_agile_development. アジャイル
この記事は約7分で読めます。

アジャイル(Agile)とは俊敏性を持つための価値観(マインドセット)です。

アジャイル開発はアジャイルの価値観をソフトウェア(IT)開発に適用した方法論の総称です。例えば下記のような方法論があります。

  1. XP(エクストリームプログラミング):ペアプロ、TDD、ユーザーストーリー等のプラクティス群
  2. スクラム(Scrum):様々な方法論を取り入れられる軽量なマネジメントフレームワーク
  3. LeSS(Large-Scale Scrum):大規模スクラム
  4. SAFe(Scaled Agile Framework):大規模アジャイルフレームワーク(組織にも適用)
  5. FDD(Feature Driven Development:顧客にとっての機能価値(feature)という観点で駆動

その他にも色々とあり、私が学んだPivotal流(Pivotal way)も方法論のひとつです。

日本ではスクラムをベースとして、XPからいくつかのプラクティスを取り入れているケースが多いようです。

アジャイル(Agile)と一言で言うと、「価値観」を指す場合と、「各方法論を使ったソフトウェア開発手法」を指す場合があるため、ややこしく、文脈から読み解くことになります。

私のブログでは「アジャイル」と「アジャイル開発」は区別して使っていきます。

アジャイルソフトウェア開発宣言の4つの価値観は様々な方法論の有識者が集まって辿り着いた、共通項の価値観であるため、しっかりとその共通項の価値観の本質を理解すると、全てのアジャイル開発方法論に生かすことができます。

そのため、アジャイリスト(アジャイルの実践者)同士では、アジャイルの価値観を共通言語として会話することができます。

ただ、方法論の中でもそれぞれの原理原則を持っている場合があります。流派ごとの違いがあり、それぞれ何を特に大事にするかが違っていたりするため、方法論同士で仲が悪いケースもあるようです。同じ「スクラム」の中でも流派があります。

例えば、方法論のひとつとして「スクラム」の場合には下記の原理原則があります。

  • スクラムの柱:透明性、検査、適応
  • 価値基準:確約(commitment)勇気(courage)集中(focus)公開(openness)尊敬(respect)

これらは、スクラム以外のアジャイル開発の方法論を実践している方には、話しが通じない場合がありますので、お気をつけください。

また、XP(エクストリームプログラミング)にも「5つの価値」があります。

  • コミュニケーション
  • シンプル
  • フィードバック
  • 勇気
  • 尊重

ちなみに「インセプションデッキ」というプラクティスを聞いたことはありますでしょうか。

それは、ThoughtWorks社のRobin Gibson氏によって考案され、「アジャイルサムライ」の著者 Jonathan Rasmusson氏 によって広く認知されるようになっています。つまり、スクラムでもXPでも他の有名な方法論から生まれたものではないものも、アジャイルのプラクティスとされています。

ご参考として「インセプションデッキ」の構成をご紹介します。下記の質問に答えることで開発チームの存在意義、進むべき方向を定義します。

  1. 我々はなぜここにいるのか
  2. エレベーターピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. プロジェクトコミュニティ
  6. 技術的な解決策の概要
  7. 夜も眠れなくなる問題
  8. 期間を見極める
  9. トレードオフスライダー
  10. なにがどれだけ必要か

これらを開発チームで作成することで自分たちの目的・目標の意識合わせを行い、周りのステークホルダーに対しても公開し、開発チームを理解し、守っていただくことに役立ちます。

どのタイミングで作成してもよいですが、チームの立ち上げ期に作成すると最も効果的です。いきなり10個全部作成するのは難しいため、特に重要なものに絞ると効率的です。私のおすすめは下記です。

  • 我々はなぜここにいるのか:開発チームの存在意義を明らかにすることがモチベーションに繋がります。
  • やらないことリスト:いつでもやるべきことはやれることより多いです。内外にやらないことを示します。
  • プロジェクトコミュニティ:プロジェクトのステークホルダー洗い出しです。
  • 夜も眠れなくなる問題:それぞれがリスクと感じていることの洗い出しです。
  • トレードオフスライダー:個人の価値観からチームの価値観を醸成するのに役立ちます。

このブログを読んでくださっているみなさんも、自身がアジャイルに実践していることを公開することで、いつかプラクティスとして認知されるかも知れません。


さて、「ウォーターフォール開発」から「アジャイル開発」に急に切り替えようとすると、下記のような問題にぶち当たりがちで、二の足を踏んでしまうケースがあまたあります。

  • 開発対象のソフトウェアがアジャイル開発に適しているか否かの議論になり進まない
  • ソフトウェア開発工程の変更をすることが契約上も難しい
  • アジャイル開発に対する周囲の理解や協力が得られない
  • アジャイル開発が実践できるメンバーのアサインが十分にできない

一方で「アジャイルになる」、「アジャイルをする」ことの本質はマインドセットであるため、誰でもどこでも始めることができます。

また、実は「ウォーターフォール開発」の中には「アジャイル」のマインドセットだけでなく、「アジャイル開発」のプラクティスの多くを導入することができます。そもそも、「アジャイル開発」は従来型の開発をしている中で、よりより開発方法を生み出そうとして至ったものです。

※「従来型の開発」という表現は「ウォーターフォール開発」を指すケースが多いですが、それに限りません。そして、「ウォーターフォール開発」を卑下したり、否定しているわけでもありません。

例えば、「やらないことリスト」を作って開発チームの内外に示して合意を得る、ということは「ウォーターフォール開発」どころかどんな業務にでも有効です。他にも、プロジェクトを通して顧客と一緒に仕事をする(コロケーション)、ペアプログラミング、テスト駆動開発、CI/CD環境構築を取り入れることができます。

もっと言いますと、「ウォーターフォール開発」であっても勝手にスクラムチーム(自称)を作っても良いと考えています。例えば下記のようなことです。

  • 2pizzaチームを作る
  • 要件定義、基本設計等の設計工程も1週間単位のスプリントにする
  • 設計も優先順位の高いものから始めて、1週間単位で顧客レビューを受ける
  • 朝会、ふりかえりをリズムを持って行う
  • プロジェクトの大きなリスクから検証する
  • プロジェクト関係者を可能な限り同じ場所に集める
  • 顔を合わせての対話を重視する

ソフトウェア開発を実践されている方は、自身のプロジェクトのふりかえりをしたり、他プロジェクトの成功事例、失敗事例を見聞きすることがあると思います。

その中で「こうしたらうまくいった」「こうすればよかった」「つぎはこうしたい」というものに、アジャイルで大切とされているものが多くあることに気づくでしょう。

ぜひ、プロジェクトのふりかえり資料、プロジェクト事例の資料を見返してみてください。

いかがでしたでしょうか。

アジャイルは価値観、アジャイル開発はアジャイルの価値観をソフトウェア開発の方法論に適用したもの、です。

アジャイルの価値観を大切にすることはいつでも始めることができ、アジャイル開発の方法論の一部も今の環境でテーラリングが必要ですが、導入できるはずです。

ただ、私が一番気をつけたいと思っているのは、本番リリース時の「当たり前品質」は妥協してはいけないということです。アジャイル開発では「製造品質」より「価値品質」が重視される傾向があります。それであっても、世に公開され、ユーザーに使われるものであれば、ソフトウェアというモノ・サービスとして、当たり前とされる品質は確保しなければなりません。

これまでのやり方で品質を確保、担保していたとして、そのやり方を変える、止めることでアジリティを出すということがあります。その際に、これまでと同様、もしくはそれ以上の品質を確保できるかという視点で判断する必要があります。そして、そこで求められる品質を一概には決められないのですが、社会的な影響度が指標になると考えています。

例えば、新規のサービス・プロダクトの開発で、ニーズがあるかどうかも分からないものである場合には、いくらバグがあっても、その価値を確かめられればいいのです。

一方で、社会的に影響の大きい、人命、お金、社会インフラ、機微な情報、といったキーワードを持つソフトウェアの場合には、当然のように非常に高い製造品質が求められます。利用するユーザーからはどのような方法で開発されているかは関係ないのです。