あんまりプログラミングしないけどアジャイル

　アジャイル開発はいわゆる「方法論」ではなく「姿勢」や「問題意識」のようなものだと説明されたりする。その割にはこの「問題意識」がプログラミングすることへの奇妙なこだわりを持ち続けている点に、私は違和感を感じる。

　代表的なプラクティスとして「ペア･プログラミング」が採用されたことからもわかるように、もともとアジャイル開発はプログラミングの現場で提唱され発展したものだ。「アジャイルでのプログラミングはなんだか楽しそうだ」といった印象を持たれたりもしている。

　しかし、そこらへんの出自や印象についてはもう忘れていい。なぜなら、個別案件においてアジャイルであることを真摯に追求すれば「なるべくプログラミングせずに済ませるためには、どんな工夫ができるだろう」という認識に至るからだ。ゲームやＢ２Ｃやサービス系では事情は違うのかもしれないが、少なくとも私の専門である基幹システム（業務システム）の開発案件においてはそうだ。

　周知のように、アジャイル開発で供給され続けるべきは「状況や要件の変化」に追随したソフトウエアである。そのために多くのプログラミング作業が要るかもしれないし、要らないかもしれない。プログラミング量に関係なく、変化に応じたソフトウエアが供給され続けたのであれば、それを「アジャイル開発」と呼んで差し支えない。

　そして、アジャイル開発にともなうやり甲斐や喜びは「変化に応じたソフトウエアを供給し続けること」にもとづくものであって、プログラミングできるかどうかやプログラミングを楽しめるかどうかとは無関係である。要するに、プログラミング工数の多寡やスピードや楽しさは、アジャイルであることとは関係ない（直交している）。

　じっさいのところ、個別案件において直接編集されるコード（マークアップ言語を含む）の量が多ければ多いほど労働集約的になり、開発・保守効率が目に見えて悪化する。ゆえに、同等なシステムを扱った案件を比較した場合、そこらへんの量の少なさがアジャイルさの指標のひとつになるといっていい。

　プログラミングが重要でないと言っているのではない。まさにその逆だ。プログラミングという営みは「アジャイル開発を実践しやすくするための開発環境を整備する手段」として特別視されるべきだ。すなわち、強力な「アジャイル開発用プラットフォームの開発」のためにこそ、プログラマは召喚されるべきである。プログラマを侮ってはいけない。

　そして、最小限度のコードでシステムの振る舞いを変化させられる開発基盤がプログラミングされるべきだ。さらにその上で稼動する基幹ステムのライブラリが整備されるべきだ。そんなプラットフォームの上では、個別案件のアジャイル度は向上する。ライブラリの中から叩き台を選び、それをユーザといっしょに動作させつつカスタマイズすることで、要望に沿ったシステムが完成するからだ。状況が変化しても最小限度のコード修正で追随できる。

　そういったやり方に比べたら、個別案件でユーザと対話しつつプログラミング主体のイテレーションを繰り返すやり方は、当人たちがその手法を何と呼ぼうがアジャイル度は低い。まあ当初は革新的だったのだろうが、開発環境そのものが不断に変化・発展することを考えれば、今や「第一期アジャイル」と位置づけされるべきかもしれない。

　ただし、プログラミングを一切せずに一基の基幹システムを完成させられるなどとは私も思っていない。とくにある種の「ビジネスルール」は、プログラミング言語でしか記述できないほどに複雑精妙だ。

　にもかかわらず、「最小限度のプログラミング」や「なるべく少ないプログラミング」を是とするアジャイルはありだし、目標にされていい。必要とされたプログラミング作業がたまたま楽しければ、思わぬ僥倖として感謝すればいい。しかしそんな楽しみが皆無だとしても、顧客にとって価値のあるソフトウエアを俊敏に提供し続ける喜びがあれば満足しよう。「美しいコードよりも、コードを書かずに済ませるための工夫に価値を置きます」――そんな一文を「第二期アジャイル宣言」には加えたい。