設計者の発言

　業務システムをいかにアジャイルに開発するか。それが私の長年の研究テーマだった。最終的にたどりついた答は「モデルシステム（設計図が添付されている動くシステム）をカスタマイズして導入する」というものだった(*1)。

　それは「プログラミング・ファースト」でも「テスティング・ファースト」でもなく「ユージング(using)・ファースト」とでも呼べそうな、きわめてフロントローディングな開発スタイルである。業種・業態別のモデルシステム・ライブラリの第二弾「XEAD生産管理システム」は、OSSとして２０１３年８月に公開される。

　モデルシステムのように大げさなリソースがなくてもアジャイルに開発可能なソフトウエアもあるだろう。しかし、こと生産管理システムのような「複雑なデータベース構造を核とする大規模ソフトウエア」に限れば、データベース構造が確立されたモデルシステムをカスタマイズするやり方が理にかなっている。

　そもそも、どんなソフトウエアであっても一律に適用可能な開発手法が存在すると考えるほうがおかしい。それはまるで「文学作品だろうと科学論文だろうと、この手順で執筆を進めることで素晴らしい成果を得られる。なぜならどちらも文字の集まりとして完成するものだからだ」と主張すようなものだ。最終的に文字の集まりとしてまとまるにせよ、作成過程での課題は分野毎に完全に異なる。一律な執筆手法など想定できるものではない。

　同様に、WEBサービスと生産管理システムと組込ソフトとゲームソフトとが「この手順で開発を進めることで素晴らしい成果が得られる。なぜならいずれもコードの集まりとして完成するものだからだ」とは言えない。

　では、ソフトウエア分野毎に有効なアジャイル手法はどのように決定されるのか。それは、適用分野毎の開発課題を瑣末な要素と重大な要素とに分別したうえで、それぞれの取り扱い方針を考慮した結果として定まるであろう。

　たとえば、ある種の分野では「高品質なコードユニットをいかに手早くものにするか」や「いかに使いやすいUIを提供するか」が重大であったりするだろう。いっぽう生産管理システムあたりでは、「いかに的確なデータベース構造を確立するか」が相対的によほど重大である。この課題をおろそかにすれば、アジャイル本にあるような手順をいくら誠実に繰り返してもまともなシステムは手に入らない。

　ソフトウエアを「コードの集まりとして完成するゆえに、どれも似たようなもの」と考えるべきではない。それは今や、それぞれの適用分野毎に固有な専門性を帯びている。ゆえにアジャイル手法の実践は、まずは適用分野毎の特性を理解し、さらに必要な専門性を地道に習得することから始まる。「プログラミングの腕さえ磨けばアジャイル開発がやれるようになる」なんてあまりにアマい考えだ。

*1.これは「パッケージ」を用いる従来型のやり方とどう違うのだろう。多くのパッケージはテーラリング（パラメータ調整することで仕様を変化させること）ができるようになっている。これはこれで便利なのだが、そのために設計図が第三者には理解しにくいものになっている（たいていはチンプンカンプンだ）。これゆえパッケージのカスタマイズには想像以上のコストがかかる。いっぽう「モデルシステム」は、テーラリングが想定されていないために設計図が明解であると同時に、カスタマイズしやすいような実装基盤上で開発される。両者の導入過程はまったく異なって見えるだろう。