アジャイルを明確に定義する

はじめに

先日、自分なりにTDDを定義した。-> 【TDDを明確に定義する - うさぎ組】
そのあと、アジャイルとはなにであり、アジャイルの基礎とはなにであるかに興味をもつようになりました。
アジャイルを卑下するとか崇めるとかじゃなくって、好奇心とか自分がどう接すればいいのか的な感じで。
以前の自分よりは少し視野が広くなったのもあって書けそうな気がします。

アジャイルの定義、基礎、実現方法を示すことで、アジャイルの全体像を把握しようと思います。
また、これらの定義の中では「時系列的経緯」について考慮していない部分があります。それらの詳細については後半に記します。

アジャイルの定義

アジャイルとは「ソフトウェア開発のスタイル」です。
アジャイルは「ソフトウェア開発プロセス」ではないのです。故にWFとの比較は非常に話がかみ合いません。WFは「ソフトウェア開発プロセス」の側面で話される事が非常に多いからです。
「ソフトウェア開発のスタイル」という言葉はあまり聞きなれないかもしれませんが、これは実に身近にあつかわれています。
他の例をあげてみます。

たとえば、「関数型とはなにか」というものがあります。
関数型とは「設計のスタイル」であり、そのスタイルをどのように実現するかによって「プログラミング言語」があります。その例がHaskellやOCamlです。
この設計はプログラミングと言い換えてもよいでしょう。「関数型プログラミングスタイル」において「これが出来ていなければ関数型とは言えない」という「明白な線引き」は難しくなります。ですが重要な要素というのはいくつかあります。参照透明性、高階関数などなど。
「関数型プログラミング」によってどのようなメリットがうまれるのかなどの話は範囲外なので割愛します。

設計のスタイルでいえば、同様にオブジェクト指向などもあげられます。

このようなものをスタイルと考えていて、同様にアジャイルは「ソフトウェア開発のスタイル」であると定義します。
つまりアジャイルにより忠実であるかどうかが尺度になります。
ここで気をつけたいのは2つあります。
1. アジャイルに忠実である事と完璧なソフトウェア開発を達成できる事は違う
完璧なソフトウェア開発をQCDが最大値であるような（極端にいえばあり得ないような）ソフトウェア開発の理想型だとします。
それを達成出来る事と、アジャイルに忠実であることは必ずしも一致しないという事です。

2. アジャイルがソフトウェア開発全般を指していないなら、アジャイルの適用を広げるのは馬鹿げている
「○○だからアジャイルは向いていない」というのは様々ありますが、アジャイルの基礎をに反対するメンバーがいるわけではない限り、それを馬鹿げているというのは言い過ぎだと思っています。
スタイルをより最適化させたり、新しい手法を探したりすることで以前より素晴らしいことを生み出せる可能性はたくさんあるわけです。
アジャイルの基礎に反対するメンバーがいない中でアジャイルの適用を諦めているのは、アジャイルに対する熱意が低いかアジャイルをパッケージ製品としてしか見ていないためです。

アジャイルの基礎

アジャイルという開発スタイルの礎になっているものが、アジャイルの基礎になります。先の関数型プログラミングでいうと、λ計算であったり、参照透明性や高階関数といったものが該当するでしょう。クラスベースオブジェクト指向でいえばカプセル化とポリモーフィズムなどでしょうか。(もちろんここにあげた以外にも種々あります。)

アジャイルソフトウェア開発スタイルの基礎は【アジャイルソフトウェア開発宣言】と【アジャイル宣言の背後にある原則】です。アジャイルソフトウェア開発宣言はスタイルの概念を表現し、アジャイル宣言の背後にある原則は概念を実現する際の原則、指針を表現しています。
※もちろんこれらの関係においてどちらが先であるかはあまり重要ではありません。御互いに影響しあうものだからです。

アジャイルソフトウェア開発スタイルは「アジャイルの基礎により忠実であるかがアジャイルである」ことになります。
そして「アジャイルの基礎により忠実であるかと優れたソフトウェア開発であるかは別」になります。

言い換えれば、より「関数型に忠実であること」と「より優れた言語であること」が異なる観点であるのと一緒でしょう。

アジャイルソフトウェア開発(=アジャイルソフトウェア開発スタイルの実現)

「アジャイルソフトウェア開発」は「アジャイルソフトウェア開発スタイルを実現したもの」とします。
「名前がつけられている」、広く知られている例としては次のものがあります。

XP
Scrum
Crystal
FDD
RUP
Lean

これらは「アジャイルの基礎を実現し、更に拡張や追加をしたもの」になります。
そして面白いのは、それぞれ「アジャイルマニフェストの特定箇所を重要視している」というのがあり、個性があることです。
つまり、平坦にどれをも同量に実現している「アジャイル開発」は上記にはないと思われます。
これらのアジャイルソフトウェア開発を導入するのがGetting Startとしてはよいでしょう。

スクラムガイドとはなにか

例としてScrumをあげます。
Scrum Guideが果たしている役割はScrumの定義ともとれますが、どちらかというと「Scrumの推奨スタイル」になります。
プログラミングで言えば「標準コーディング規約」のようなものです。PythonのPEPといえばよいのでしょうか。

Scrumの定義なくして、Scrumは成立しうるのでしょうか。
Scrumが世に出て来たのは論文や発表になりますが、それが定義、仕様であるかはまた別の話だと僕は考えています。

つまり、Scrum Guideに従っていないからといってScrumではないということは出来ないのです。
ですが、「Scrumらしさ」を追求するのであれば「Scrum Guide」に従うのがよいのでしょう。それが本当に優れたScrumであるかは別の話です。
コーディング規約もそうですが、「非常にドメインを表した書き方」もあれば「多くの人に受け入れてもらうための書き方」もあるわけです。
なので「Scrum Guide」が「卓越したScrumer」のためであるかどうかはScrum Guideを定義している方やScrumエキスパートコミュニティにご意見を伺う必要があるでしょう。

アジャイルソフトウェア開発スタイルのリファレンスモデル

厳密に「基礎のみに従っていて名前のついている事例」というのは聞いた事がないので、リファレンスモデルのようなものを名前としてあげることはしにくいです。
ただ、「アジャイルXX」のような書籍で語られているものがリファレンスモデルである可能性が高いのですが、私には判別がつきませんでした。
もしあれば示して頂けるとうれしいです。

アジャイルのこれからをどうしたいか

これはかなり個人の主張になります。
アジャイルソフトウェア開発を進化させたい。というコミュニティは存在するのでしょうか？
僕はもし(現在の業務的な意味で)自分に許されるのであれば進化させてみたいです。させるであれば、アジャイルの基礎からアジャイルソフトウェア開発スタイルやプラクティスをどのようにつくるかが重要なのではないでしょうか。
アジャイルソフトウェア開発を試してみて、アジャイルから離れる事は簡単です。たしかに業務的には正しいのかもしれませんが、それはある意味で野心的であり、ある意味で平凡です。
アジャイルソフトウェア開発を進めていくためには、アジャイルの基礎を土台にアジャイルの可能性を探る事は非常に重要だと思うのですが。

あなたの開発スタイルは？

「よい開発ができていればよい」ということは簡単ですが、本当にそれでよいとは僕は思っていません。
僕がこの記事を書くまでたくさんの先人の知識を授かったように、僕もまた誰かのためにソフトウェア開発スタイルをある程度でも体系立てて残すべきだと、ソフトウェア開発を進化させるためには必要なのではないかと思っています。
規律ある開発はたしかに難しいのですが、なにが規律で何が属人的プロセスで、何が文化なのか。考える事は様々ですが、ソフトウェア開発スタイルを探すことは非常にエキサイティングだと思います。

まとめ

アジャイルは「ソフトウェア開発のスタイル」である。
「アジャイルソフトウェア開発スタイル」の基礎は「アジャイル開発宣言」と「アジャイルソフトウェアの12の原則」である。
XPやScrumといったものは「アジャイルソフトウェア開発」であり「アジャイルソフトウェア開発スタイル」のいくつかを実用的に実装したものである。

この結論による僕自身の効果は「アジャイルはソフトウェア開発スタイルである」とすることによって「アジャイルに拘るな！」と「純粋関数型に拘るな！」は似たようなものであると出来るようになったことです。
ただし、スタイルを追求してみることは有益ですし、近年の関数型プログラミングの流行はまさにそれを象徴していると思います。
自身が置かれている状況によってどの程度追求してみるかは変化しますし、どのように追求したいかという欲求ベースで状況を変化させるのもよいのではないでしょうか。

書いていて悩んだこととか

比喩とか、置き換えた例とかどれくらい出してどれくらい出さないかに悩みました。
アジャイルでの具体例を出す事は容易いのですが、具体例はやはりコンテキストが重要になります。かといってわかりやすいと思われる比喩的な置き換えは筆者の実力によって逆効果になることもあります。
例えば、アジャイルをスポーツのチームの場合で例を出す事もできますが、ソフトウェア開発とスポーツではあまりにも違います。サイクルも使う能力も。一見似ている部分があるからといって違うものに共通的なものを見いだすのは個人的には好きではないというか「年収を50倍にする方法」とかの書籍に近いようなうさんくささを感じます。