アジャイルとは何か？言語化してみる｜改めて考えてみる

「アジャイルとは何ですか？」

このような問いはよくあります。

アジャイル開発の経験のある方でも、急に問われるとうまく言語化できずに困ってしまうかもしれません。

この問いは、人によって答える答えが異なります。

色々な意見があるというよりは、視点、視座、視野が異なっているからではと思います。

正解、不正解があるわけではない、と。それぞれの胸に、それぞれのアジャイルがあっていいとも思います。

ちなみに、アジャイル宣言の4つの価値はアジャイルの唯一の定義ではあります。

しかしながら、それはそうそうたる有識者の最大公約数的な共通項であり、それぞれが思う大切な価値観の一部が抜け落ちている不完全なもの（必要条件ではあるが十分条件ではない）、と考えています。

また、宣言の一節に「よりよい開発方法を見つけ出そうとしている」とありますとうり、みなが現状に満足しているものではなく、半永久的と思われる価値観や原理原則でさえ、環境に合わせて変えていく必要があるかもしれません。

加えて、アジャイルはソフトウェア開発から生まれたものですが、進化を続けた結果、ソフトウェア開発にとどまらず、あらゆる業務や組織にまで適用できるようになっています。

例えば、Bain & Companyの「Agile Innovation」でも、アジャイルはあらゆるビジネスのカイゼンに使えるとあります。

ソフトウェア（システム）開発のみでは領域が狭いですが、それがあらゆるビジネスということになりますと、解釈にも際限がありません。

と、このような背景があるため、ひとによって言うことが違う、アジャイルってよく分からない、ということになりがちです。

ただ、世の中に一気にアジャイルが広まったら、流行語大賞にノミネートされたり、「アジャイル」がタイトルに入ったアニメやドラマが生まれるかもしれません、と予言します。ワクワクしてきませんか。笑

そんな、よくわからないアジャイルを少しでも紐解きます。

いくつかの視点で「アジャイル」を言語化してみましたので見ていきましょう！

Agenda

1. アジャイルを4つの視点で見る
2. 社会・ビジネス視点のアジャイル
3. プロダクト開発（アジャイル開発）視点のアジャイル
4. マインドセットの視点からのアジャイル
5. チームの視点からのアジャイル

アジャイルを4つの視点で見る

上記の表のように、4つの視点に分けて言語化してみました。

アジャイルに触れたことがある方には、表の右列のワードの中でピンとくるものがいくつかあるはずです。

気になるワードがあった方は、続きを読み進めてみてください。笑

※他の視点も思いつきましたら追記、もしくは別記事にします。

社会・ビジネス視点のアジャイル

不確実性に向き合い（仮説検証型）、変化を捉えて価値を届け続ける

お仕事は社会のためにしているという理解をしています。

利潤を目的とした会社であればビジネスのために、とも言えます。（非営利団体も社会のために、は変わらないと思います。）

なぜアジャイルが求められているのか？という問いに対して、「ビジネスがアジャイルを求めているから」と答える方もいます。

現代はVUCAと呼ばれるように、不確実で変化の激しい時代となっています。

そのため、数年かけてようやくできたプロダクトが期待していた価値・効果を発揮できないことが往往にしてあります。釈迦に説法ではありますが、投資対効果がなければビジネスとしては成り立たないわけです。

そして、社会が成熟化していくことで人々の欲求のレベルが上がり、画一的（かくいつてき）だったユーザーが多種多様となります。

これを作れば多くのユーザーを満足させられるという答えが少なくなり、かつ、それぞれのニーズが小さく、そして変化するため捉えることがとても難しくなっています。

ニーズがバラバラ：複数ある答え
ニーズのサイズが小さい：見つけにくい答え
ニーズが変化する：変わる答え

学校で習う勉強の多くは、問いと答えが１対１となり、答えは普遍ですね。そのため、一度理解して覚えればいいわけです。つまり、正しく早く理解でき、処理でき、記憶力が高いひとが有利となります。

それに対して、答えは無数にあります、小さくて見つけにくいです、ひとによって解釈も千差万別です、複数の答えにバランスよく対応する必要があります、今日の答えが明日の不正解です、と言われてしまうと無理ゲーに感じます。

そんな無理ゲーに立ち向かおう！というのがアジャイルです。

どんなにアジャイルを極めたところで、「難しいものは難しい」ということがお分りいただけるかと思います。

社会、世の中が不確実であることを受け入れる
無理だと諦めずに、分かる情報（事実）とアイデア、多様性から仮説を立てる
仮説を検証して、分かることを増やす
分かったことをベースにモノ（プロダクト）をつくって世に出す
世に出したものを検証して、さらに分かることを増やす
さらに分かったことをベースにつくる

これを反復的に持続的に繰り返して価値を届け続けることがアジャイルです。

さて、ここまでアジャイル開発手法の話しをしていませんね。

もしかすると、アジャイル型のシステム開発を知らない経営者が「アジャイルを推進」しようとしている場合、ビジネスの視点でモノを見ているのかもしれません。

また、組織構造についても同様に、意思決定のスピードが遅かったり、従業員が働きにくいルールや環境になっていると、社会の変化に付いていけずに、利益が減ったり、コストが増加したり、チャンスを逃してしまったり、能力ある人が離脱してしまったりするわけです。

利益が減る：プロダクトのニーズが変化して売れなくなるため
コストが増加：組織が抱えている固定的な資産（人含む）がニーズとアンマッチとなるため
チャンスを逃す：チャンス（もしくは重大なリスク）に気づいても、意思決定のスピードが遅く、身動きが取れない
人が離脱：価値ある業務とひとの紐付けができない

ダーウィンも生き延びるのは強い者でも賢い者でもなく、変化できる者、と言っています。

人も組織も変化を求められる時代です。。大変です。。

特に、大きな災害、恐慌、パンデミックなどが起きてしまうと、需要と供給のバランスが大きく崩れます。

その大きな変化にすぐに対応ができないと、大きく損失を被ったり、事業の継続ができなくなったりします。

そのため、アジリティ（アジャイルの名詞形）のある組織にしよう、という流れになっています。

思い込みではなく、事実（FACT）に基づいたユーザーリサーチ、データ分析、マーケティングをする
いまとすこし先でパフォーマンスを出せるように人材（全ての階層）を育成する
階層構造を浅くする（経営と現場の距離を近くする）、電子承認による簡易化（判断の低コスト化）
ひとのアサインを全体最適化する（せまい組織の中だけで判断しない）
組織の単位を小さくして機動的にする
意思決定を現場に寄せる

しかしながら、新しいことをしようとしたり、変化させようとすると、反対勢力、反対意見が生まれます。

それを押し切れたら良いかもしれませんが、特に古い組織の場合には一筋縄ではいきません。

過去の成功体験に囚われていたり、既得権益のために変わりたくないひとたちがいるのです。

そもそも、全員が変わりたいと思っているのであれば、とっくに変わっているはずです。

（強い制約や法的ルール、何らか地理的な事情等から人以外に原因がある場合もあります。）

今のままで変わらないということは、変わりたくない人がいるものです。

そのための手段のひとつとして、「イノベーション」や「DX」という冠をつけた組織をつくって特区としたり、子会社を作っているところが増えています。

ただ、新しい組織に入る人と入らない人とで「二項対立」が生まれます。

※「二項対立」とは互いの評価を著しく下げあい、歩み寄らない様子です。

新しい組織が価値を生み出せるようになるためには時間がかかりますし、失敗に終わる可能性も高いです。そのため、重箱の隅をつつくことも、穴を見つけることもできるため、批判はいくらでもできます。

一方で、変わらなければ滅ぶことは確実（100%）であるため、難しく、リスク高く、失敗する可能性が高くともゼロではないため、チャレンジするしかない、とも思います。

どれだけのコストを変革の費用に充てられるかどうかは、組織ごとのリスク許容度によります。

経営層が強い危機感を持ち、率先して組織を変革できればよいですが、そのようにできるほうが少数かと思います。

さて、その場合にどこから、誰が変えれればよいのでしょうか。

答えのひとつは「必要性に気づいた人がひとりから始める」です。

ひとりが勝手にカイゼンし始め、他の人を巻き込み、チームを巻き込み、カイゼンが目に見える様になれば、味方が増えます。そうすると、コストをかけても変革する価値があると多くの人が思えてきます。ここまで来れば組織を動かすことができるはずです。

新しいことをいきなり提案しても、なかなか通りません。前例がないため、承認者も判断できず、分からないからです。

そのため、事前に承認を得るのではなく、あとで許しを得る、という手段が有効です。

ここは、あとで大きく怒られない様に慎重に丁寧に進める必要があります。難しいですね。

ポイントはなるべく敵をつくらないように、味方、理解者、黙認者を増やしていくことです。

プロダクト開発（アジャイル開発）視点のアジャイル

反復的、漸進的、持続的につくる

ウォーターフォール開発とアジャイル開発では何が違うのでしょうか。大きく3つの要素があると考えています。

反復的：イテレーティブに要求〜設計〜開発〜テストのサイクルを繰り返しながら、つくる
漸進的：インクリメンタルにすこしづつ、つくる
持続的：サスティナブルペースで、つくる

「反復的」はアジャイル開発の大きな大きな特徴のひとつです。

ウォーターフォール開発ではひとつのプロジェクトで設計、開発、テストの工程は基本的には1回ずつです。

※実際にはプロジェクトの途中で要件や仕様の追加が入り、工程が複数回現れることがあります。

アジャイル開発ではイテレーション（スクラムではスプリント）と呼ばれるタイムボックス（1〜4weekの固定期間）を反復的に繰り返します。

なぜ、反復的にするかと言いますと、学習を早めて蓄積するため（分かることを増やす）、早く価値を届ける（利益を得る）ため、プロジェクトの継続可否を早く判断するため、です。

プロジェクトを始める前につくるものが決まっており、それをつくれば費用対効果的に確実に成果が出るということが分かっていれば、ウォーターフォール開発で一直線につくってしまうのが、一番効率的ですね。

一方で、それをつくっても成果が出るかわからない、技術的にどのようにつくるのがよいのか確立されていない、要求や要件が曖昧、という状態で一気にモノを作り始めてしまうのはリスクが高すぎます。

例えば、「10」つくるつもりで、その中で最も価値の高いと思われる「2」の機能をつくり、世に出してみる。最も自信のある「2」を世に出して鳴かず飛ばずであったなら、止めるか方向転換（ピボット）します。そして、世に受け入れられたら、そこから価値を発揮できるため、費用の回収ができるようになります。そして、そのMVP（価値を出せる最小限のプロダクト）に対して自信を持つことができ、より大きくすることができます。

また、リリース直前の最後の工程（テストや受入など）まで進めることで多くのリスクを検証することができます。すこしの機能をつくりこむだけで、大きな技術的課題にあたった際に、それを早期に解決する、もしくはそれを避けるという判断をすることができます。ウォーターフォール開発では全てをつくりきってからテスト工程で下記のような問題が発生し、手戻りが発生してしまうことがあります。

顧客が想像していたものと違うものがつくられている
外部システムとの連携でインターフェースの認識齟齬が発生する
致命的な性能問題が発生する
要件や仕様を変更せざるを得ないセキュリティの問題が発生する
開発全体が遅延し、必須で重要な機能がつくりきれていない

反復的な開発にすると、上記の課題に早く気づくことができます。

「漸進的」はインクリメンタルにすこしずつ、つくりながら前に進むということです。

少しずつつくることで無駄なく、細かく方向を調整しながら進めることができます。

反復的と組み合わせて、少しずつ、繰り返し繰り返しつくる、ということになります。

ちなみに、「つくる」というのは中間成果物をたくさんつくるのではありません。中間成果物は価値があるものかどうかの判断ができない状態のため、それをたくさんつくるということは、リスクを積み上げていることになります。そのため、実際にリリースする、もしくはリリース可能な状態までつくりあげる、ということが大事になります。

実際のユーザーに使ってもらうことが一番ですが、それが難しい場合にはせめて、顧客・プロダクオーナー・ステークホルダーに使ってもらい受け入れてもらうことになります。スクラムではスプリントレビューというイベントがあり、それが受け入れタイミングになります。

「持続的」は今の時代に合った概念だと思っています。

ウォーターフォール開発では、要件定義と呼ばれる何をつくるかを決める工程で長引いたり、要件が増えるということがよくおきます。プロジェクト開始当初にすべてを見通すことはとても難しいからです。そのため、検討に時間がかかり、関係者の意識を合わせることにも時間がかかります。設計→開発→テストとまっすぐに進むのがウォーターフォール開発ですが、そのように完璧にできることは稀です。

全体のスケジュール・リリースのタイミングが決まっているため、設計が長引くと開発と並行します、開発が遅延するとテストと並行します、最悪は設計・開発・テストの全てが並行します。

どれだけ残業しても終わらなくなり、人を追加投入し、さらに混乱し、デスマーチと呼ばれる状態となります。そうすると、高稼働になるだけでなく、責任も追求されて高ストレス状態となり、病んでしまう人も出てきます。

働き方改革の時代となり、残業時間の抑制も厳しくなっています。ただ、目の前にたくさんの仕事が残っているために、管理職であったり、立場の弱い会社にそのしわ寄せがきてしまいます。

誰も望まない姿ですね。

人も時間も有限です。その前提に立って、「人数×時間」の範囲内で生産性を高めて開発をすること持続可能にするポイントになります。

アジャイル開発では、「品質」「スケジュール」「コスト」を固定にし、「スコープ」を可変にします。

持続的なペースで開発できる量にスコープを調整すればよい、ということになります。

また、DevOps（デブオプス）という考え方があります。「Development（開発）」と「Operation（運用）」を掛け合わせた造語です。これに「Business（ビジネス）」を加えて、BizDevOps（ビズデブオプス）と呼ばれることもあります。

つまり、これまでは大規模に開発したら、そのあとは運用のみ、となることが多かったのですが、前段で書いています通りに、世の中が常に変化するため、それに適応するためにプロダクトも変化させる必要があります。

そのため、終わりがないため、ずっと高稼働にしていたらビジネスを継続することができなくなります。よって、持続的なペースを保つ必要があります。

マインドセットの視点からのアジャイル

透明性（見える化）を持ち、カイゼンし続けている状態

私がアジャイル学びたての頃は、「アジャイルはマインドセットです」とよく言っていました。笑

「アジャイルってただの開発手法でしょ？」という意見に反論したかったのです。笑

ただ、マインドセットというだけではどんなマインドなのかわかりませんね。アジャイルで大切だと言われている価値観や原則はたくさんあり、それらを並べてもよくわからなくなります。

「アジャイル」という英語を訳すと、「機敏な」という形容詞となります。

あえて、機敏とか俊敏とかの言葉を省いてみました。

機敏に動くためにはまわりがよく見えていないといけないわけです。まわりが透けるほどよく見えていたら、次に何をすべきなのか瞬時にわかります。

たとえば、下記が透明になっているといいですね。

プロダクト、組織、チームのビジョンやミッション
チームで立てた仮説と検証した結果
中長期的な計画、スケジュール
バックログの一覧
直近の詳細なタスクとタスクごとの状態
課題やリスクの一覧とその状態
チーム、ステークホルダーの体制、役割
プロダクトとチームメンバーの状態

これらを常に見ることができ、常に最新の状態に保たれていたら、誰でも次に何をすればよいのか瞬時にわかります。何の加工もせずにそのままでわかるレベルにしておくことがポイントです。

ちなみに、「透明性」はスクラムガイドのスクラムの柱（原則）から言葉をもらっています。

真っ暗闇で何が正しいかわからない状態ではゴールに向かうことができません。曇っていたら北極星を目指すことはできないわけです。よって、見える化して視界良好な状態を保つことが大事になります。

そして、「カイゼン」がアジャイルには非常に重要です。世の中が常に変化しているため、現状維持では退化も同然であるため、進化しつづける必要があります。

そのための手段のひとつとして「レトロスペクティブ（ふりかえり）」があります。

ふりかえりの仕方はいろいろありますが、「KPT（ケプト）」と呼ばれるフレームワークを使うこともあります。

これは、Keep（続けたいこと）、Problem（問題だと捉えられること）、Try（トライしたいこと）の頭文字です。

これを心理的安全性が保たれた中でチームで定期的にディスカッションします。

よいことは継続するということを認識合わせし、問題やトライについては全てをやろうとしても難しいため、優先順位を決めて、チームでやると合意したものをアクションアイテムとして扱います。

これを繰り返すことによってチームの活動を継続的にカイゼンすることができます。

また、心理的安全性が維持されていればふりかえりのタイミングを待たずとも、タイムリーに親切に率直にフィードバックをし合うことができるはずです。

チームの視点からのアジャイル

目的・目標に向かい、明確な役割（区別）を持たずに自己組織的に共につくる

まずは、チームとグループの違いを考えることから始めます。

「グループ」は外から見た場合のまとまりです。グループ内の個々はそれぞれが独立していて、基本的には影響しあいません。グループは人だけでなく、モノにもよく使います。小学生のころに、形、色などでグルーピングする問題をよく解いていたかと思います。そのモノたちは互いのことは何ら意識せず、外からわかりやすく把握するために、ある意味勝手にグルーピングされます。

一方、「チーム」はどうでしょうか。私は下記のように考えています。

共通の目的・目標を持ち、相互に支援し合うグループ

チームもグループの一種ですが、個々が独立しているのではなく、共通の目標を持っていること、そして、その達成のために協力し合うというマインドが付加されているのです。

アジャイルはチームという概念が最上位にあります。それはプロダクトをつくり、価値を発揮するのがチームだからです。

そして、アジャイルチームはさらに下記のマインドが付加されます。