« コードを仕様書にするために | トップページ | 語られないアーキテクチャの謎 »

2011.10.02

「アジャイルなスクラッチ開発」ではダメ

 他のソフトウエア分野についてはわからないが、売掛・買掛・在庫・原価といった会計要素を統合的に管理するためのしくみ(基幹システム)の開発については、はっきり言えることがある。ウォーターフォール手法(WF)に替わるやり方としてアジャイル手法を導入しても、それが「スクラッチ開発(いちいちゼロからシステムを作るやり方)」である限り、状況はたいして変わらない(もっと悲惨なことにならなければ幸運というものだ)。

 基幹システムの開発に関して、アジャイル手法に救いを求めようとする人たちの初歩的な勘違いが「WF元凶論」である。これまでの開発プロジェクトがなかなかうまくいかなかったのは、やり方が悪いからだ――そこまでの観察はおおむね正しい。しかし、そこからWFこそが元凶と断ずるのは短絡である。

 それは、今にも崩れそうな石橋を前にして「<石橋を叩いて壊す>ような慎重でおおげさな渡り方はやめて、軽やかにスキップしながら渡るべきだ」と主張するようなものだ。そのほうが楽しいのかもしれないが、けっきょく橋が崩れてデスマーチの淵に落っこちる点で違いはない。この場合の問題は「石橋の渡り方」ではなく「崩れそうな石橋」である。

 基幹システム開発のボトルネックは「WFかアジャイルか」あたりの方法論にあるのではない。「十年一日のスクラッチ開発」にある。なぜか。基幹システムというものは複雑膨大なソフトウエア群でありながら、業種・業態別に類型的な構造をとるものだからだ。ユーザをウンザリさせている現行システムの仕様と、ウンザリしながらもどうすればいいのかわからないユーザ――そういった手がかりだけでスクラッチ開発を続けても、WFでもアジャイルでも違いはない。「非効率なスクラッチ開発の派生形」という意味で、WFとアジャイルは同じ穴のムジナである。

 ただし、アジャイル開発を効果的に実施したいと本気で思うのなら、道はある。スクラッチ開発をやめればいい。すなわち、業種・業態別の設計情報(レファレンスモデル)や実行可能システム(モデルシステム)のようなリソースを整備し、それを起点に個々の企業に合わせてカスタマイズするやり方をとればいい。頭の固い上司を説得するまでもなく、最新のアジャイル本やアジャイルマスターの指導に頼るまでもなく、開発スタイルは自動的にアジャイル化する。じっさい私がレファレンスの整備を積極的に進めているのは、本気でアジャイル開発を実践したいからだ。

 換言すれば、基幹システム開発のボトルネックになっているものは「的確な仕様を生み出すための手がかりの少なさ」にある。ただでさえ乏しい手がかりを現行システムの中やユーザの思いの中で探しまわるだけでは、WFだろうがアジャイルだろうが、内製だろうが外部委託だろうが、DOAだろうがDDDだろうが、事態は変わらない。設計・実装に関する知識や経験則をまとめた業種・業態別のレファレンスがどうしても必要だ。それが「崩れない石橋」となってくれる。

 そして、ここが重要なのだが、そのようなリソースを整備できるのは開発専業会社だけであって、ユーザ企業ではない。多様な開発経験にもとづいて事例を汎用化できるのは、開発専業会社だけだからだ。そういうわけで、開発専業会社に所属する技術者がアジャイル開発を本気で望むのなら、なによりもまず、レファレンス・ライブラリを整備するための一歩を踏み出してほしい。

関連記事
"実行可能な仕様書のライブラリ"を知的社会資本に―@IT情報マネジメント

|

« コードを仕様書にするために | トップページ | 語られないアーキテクチャの謎 »

コメント

業種・業態別のレファレンスとパッケージソフトの違いはなんでしょうか。

投稿: hongcz | 2012.05.08 19:13

hongczさま

「レファレンスモデル」には、ERDやDFDや業務マニュアルといった基本設計情報が含まれます。それが業種・業態別に整備されたものが「レファレンスモデルライブラリ」で、そのライブラリのひとつにもとづいて実装した実システムをここでは「モデルシステム」と呼んでいます。

ご質問されているのは「モデルシステムとパッケージとの違い」ということになるでしょう。それらは「設計情報が添付されているかどうか」と「保守性」が大きく異なります。

パッケージには、もとになった基本設計も詳細設計も添付されていないのがふつうで、それゆえに第三者によるカスタマイズが困難です。ユーザ企業にとって重要なはずの設計情報が添付されない理由は2つあります。まず設計情報を添付すると、最新の実装技術でサクっと実装されてしまう恐れがあるからです。また、多くのパッケージはパラメータによるカスタマイズができるように独特なしくみが組み込まれるため、設計情報を公開してもけっきょくわかりにくいためです。「見せるのが恥ずかしいから」なんて理由もあるかもしれません。

また「モデルシステム」と呼べるからには、保守性の高いプラットフォーム上で実装されている必要があります。設計情報があったとしても、それにもとづいてJavaやRubyのコードをゴリゴリとカスタマイズするなんて保守性がいいとは言えません。その意味で、「実行可能な仕様書」を実現したXEAD Driverなどは、モデルシステムのプラットフォームとして都合がいいわけです。

投稿: わたなべ | 2012.05.09 08:36

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「アジャイルなスクラッチ開発」ではダメ:

« コードを仕様書にするために | トップページ | 語られないアーキテクチャの謎 »