「アジャイルかどうかは、どうすればわかる？」

先日「アジャイル入門」的な内容でお話しする機会があったのだけど、その中で「アジャイルかどうかは、どうすればわかる？」ということに悩んでいる方が多く、「難しいな〜」と思いながら以下のリストを（一つの提案として）ひねり出した。

毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？
毎日、学んだことを計画に反映し、最善の計画に更新しているか？
計画変更のコストは、ゼロ（に限りなく近い）か？
1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？）

「これが正しい指標だ」と言うつもりはまったくなく*1、あくまで僕がこれまで学習や実践を重ねてきた中で、「このへんちゃうかな〜」と考えた提案であり、試案だ。

あくまで、「取り組んでみているけど、手応えがない」とか、「アジャイルできてる気はするけど、本当にそうなのか知りたい」といった悩みに対して、一つの手掛かりになれば、というレベルのアイデアだ。

とはいえ、案外いい線いってるんじゃないかな、というちょっとした自信のようなものもある。
この記事では、そのあたりを少ししっかり目に言語化してみようと思う。

1. 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？

これは、アジャイル宣言の背後にある原則に示されている「価値のあるソフトウェアを早く継続的に提供」や「動くソフトウェアこそが進捗の最も重要な尺度」といった価値観を表現している。

ちなみに、原則の中には「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」というものもあるが、これは現代の（少なくともWebサービス開発の）環境では長すぎて、競争力にはつながらないと感じる。すでに世の中には「毎日、何度も」リリースできていて、そのことから利益を得ているチームが数多くあるのだから、そこを目指すのが妥当だろう。

また、これはアジャイルソフトウェア開発宣言に示されている「包括的なドキュメントよりも動くソフトウェアを」の直接的な表現でもあるし、「契約交渉よりも顧客との協調を」や「計画に従うことよりも変化への対応を」を実現するための方法でもある。

というのも、最終受益者（≒顧客）に価値を届け続けることによってこそ、顧客との協調は最大化される。そして、本番環境に動くソフトウェアをリリースすることこそが、「変化への対応」をも超えて、より積極的に「より高い価値への変化（≒フィードバック）」を生み出していく最良の手段でもあるからだ。

2. 毎日、学んだことを計画に反映し、最善の計画に更新しているか？

1つめの項目に「変化を生み出す」という意味があるとすれば、この2つめは「変化に適応する」ことを表現している。

アジャイルソフトウェア開発宣言で言えば、ずばり「計画に従うことよりも変化への対応」と直結しているし、「契約交渉よりも顧客との協調」という点でも、最初の契約（約束）を守る、守らないといったこと（交渉）よりも、常に最良の計画に更新し続けることで、顧客との協調を実現しようとしている。

原則で言えば、「変化を味方につけることによって、お客様の競争力を引き上げます」であったり、「シンプルさ（ムダなく作れる量を最大限にすること）が本質」といった価値観が表現されている。

最初に考えたすべてを作ることが、価値につながるとは限らない。というより、つながらない可能性が高い。それがアジャイルが前提としている世界観だ。
常に計画を見直し続ける。価値の高いものから作る。価値の低いものはあえて作らず、より価値の高いものを探し続ける。それこそが「シンプルさ（ムダなく作れる量を最大限にすること）が本質」を体現する行動だ。

3. 計画変更のコストは、ゼロ（に限りなく近い）か？

これは、2つめの項目を実現するための重要な前提だ。
2つ目のサブ要素なので、リストからは省いてもよかったかもしれないが、アジャイルから遠い状態のチームからするとやや想像しにくく、重要な前提であると気づきにくい要素でもあるのではないかと思い、あえてリストアップした。

アジャイル宣言の背後にある原則の中でも、「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」であったり、「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します」、「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」、そして「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」といった原則に忠実であれば、これが実現できる可能性が高い。
逆に言えば、計画変更のコストが高いとすれば、これらのいずれかがおろそかになっている可能性が高い、と考えると課題を発見しやすくなるのではないかと思う。

4. 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？）

1〜3は（決して不可能ではないが）なかなか高い要求だと思う。
おそらく、1〜3のすべてが実現できているチームは、「アジャイルかどうかは、どうすればわかる？」というメタ的な疑問で悩むことはなく、よりアジャイルになることを目指しながらも、具体的な価値提供に集中しているだろう。

だからこそ、この4つめの項目もとても重要だ。

アジャイルソフトウェア開発宣言の冒頭では、「よりよい開発方法を見つけだそうとしている*2」と宣言されている。
また、アジャイル宣言の背後にある原則の最後には「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」という項目がある。

よりアジャイルになろうとする態度や行動それ自体が、アジャイルであるための条件の一つでもあるのだ。

技術の重要性

ここまで、4つの項目がどのようにアジャイルの価値基準や原則を表現しているかを説明してきた。

ここで一言、技術の重要性に触れておきたい。
というのも、ここまで説明してきて、技術の重要性に直接言及していないことに気づいたからだ。

これらのリストが実現されている状態の背景には、もちろん、「技術的卓越性と優れた設計に対する不断の注意」が必要になる。アジャイル宣言の背後にある原則の9つめだ。

特にリストの1つめである「毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？」は、自動テスト、リファクタリング、継続的デリバリーに投資し、また習熟していなければ、実現できるはずもない。逆に言えば、それらにしっかり投資し、習熟すれば、十分実現可能な目標でもある。