救いにならないアジャイル、救いになるアジャイル

渡辺幸三さんのブログ記事「仕様書プログラミング」とその運命が興味深いです。概ね同意ですが、アジャイル開発を実践されている方と同じ価値観だという印象を持ちました。

「仕様書プログラミング」とその運命のアジャイル開発に関する部分を要約すると

• コンピュータが人々の仕事を奪い続けてきたことは広く知られた事実である。
• 機械的で退屈なプログラミングがコンピュータによる自動処理に置き換えられ、良くも悪くも創造性が求められるプログラミングしか残らなくなる。
• 仕様書プログラミングには仕様書の不備の補完という創造性があるが、多すぎる不備へのイライラ感か、厳密すぎる事に対するウンザリ感しかない
• しかし、アジャイル開発は救いにならない。仕様書をはじめとする包括的ドキュメントは決定的に重要だからだ

アジャイルソフトウェア開発宣言

たしかにアジャイルソフトウェア開発宣言には

「包括的なドキュメントよりも動くソフトウェアを」

とあります。しかし、その下には、

「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。」

とされていて、包括的ドキュメントの価値を認めるもののコードはもっと大切だよね。と言っています。

• 標準プロセスや契約にあるからと、必要以上のドキュメントを書いてはいけない
• ドキュメントに縛られて、動く使えるソフトウェアが提供できなくては意味がない

という意味だと思います。実際、アジャイル開発をされている方でも必要なドキュメントは書かれますし、システム間連携などで開発に必要ならプログラミングの前に書かれます。

つまり、包括的なドキュメントがすべて必要なドキュメントなら、ドキュメントは否定されないということです。

問題は従来法にもアジャイル開発にも極端な人がいて、現実的でないことを強制や主張する事ではないでしょうか？

プロセスのムダ取りをしないプロセス改善はありえませんし、コミュニケーションの手段として必要な文書を否定するアジャイル開発もあり得ないでしょう。

救いになるアジャイル

アジャイル開発が救いになるのは、その仕組みで創造性を強化する場合です。つまり、アジャイルソフトウェア宣言にあるように

• メンバーとの継続的なコミュニケーションが必要
• 確認しながら開発を繰り返さないといけない
• 顧客やメンバーなどの継続的なコミュニケーションが必要
• 変化が激しい

つまり、全てをあらかじめ決めるよりも、部分的にでも動く事で顧客あるいは仕様決定に役に立つ場合です。「アジャイルと規律」のように対象のシステムによっていずれか、あるいは切り分けて用いるものだと思います。

仕様書駆動の向いている基幹系システムや組み込み系はこれからも必要ですし、アジャイル開発に向いているサービス系システムもこれからドンドン増えるでしょう。

これらは独立している場合もあるでしょうし、組合せられることも増えるでしょう。それぞれの良さを学んで、良いプロセスを実現していきたいと思います。

仕様書はモデル

渡辺さんのアジャイル開発に対する批判は、仕様書駆動＝ウォーターフォールというステレオタイプな視点で見ると、誤解してしまうかもしれません。

渡邊さんの記事の主張は「プログラミングによる合理化は止まらない」から、コードに引きずられないで、モデルで創造性を発揮しなさい(「データモデルなきアジャイル」の危うさ)、という事だと思います。

渡邊さんは「仕様書で「動的制御」される業務システム」の開発環境XEAD Driverを公開されています。DOAで有名なジェームス・マーチンのInformation Engineeringや後のRapid Application Developmentの流れを汲むもので、データモデルからプログラムを生成すると理解しています。若い人にはMDA(モデル駆動型アーキテクチャ)からの説明(「モデル」としての仕様書:渡辺さんのブログ)が理解し易いかもしれません。

渡邊さんの言われている仕様書はXEAD Driverの入力となるモデル(「モデル」としての仕様書:渡辺さんのブログ)だと思います。管理や配布の目的のために体裁を整えられる事はあると思いますが、読まれる事のないムダな情報を先に書けという事ではないと思います。

モデルという開発言語

モデルを書いて実行できるなら、それは開発言語です。実装優先時の考慮点 その3 - 言語と環境の選択 -で書いた言語と環境の選択肢の一つです。

コンパイラやインタプリタを作るとき、構文解析/字句解析にyacc/lexを使います。この際にyaccやlexの入力はBNFに相当する言語仕様と処理のプログラムです。この入力はXEAD Driverの様に図的ではありませんが、仕組みとしては良く似ています。

現在ほどフレームワークが普及していないころ、プログラム量を減らそうと、yacc/lexやシェルスクリプトを活用していました。XEAD Driverを見ていると、いつの間にか紺屋の白袴のように開発を効率化するためのプログラミングが少なくなっている事に気付きます。

渡邊さんの言われるように、これからは開発者に創造性の発揮が求められます。開発環境の整備はもちろんのこと、DevOpsの視点でツールの利用や構築も創造性を発揮する方法の一つではないでしょうか？

おわりに

対立をあおって書いても面白かったかもしれませんが、10年以上経つのに違いばかりを議論しても発展しないと思い、「同じことを言ってませんか？」という問いかけをしてみました。

みんなムダな事はしたくないし、開発を効率化したい。渡辺さんが書かれているように（ アジャイル手法は分野毎に違っていい）、色々な技術がある中で状況に合わせてどのような開発を行うべきか、プロセスを選択的なタスクの集合として洗練していきたいと思います。