« 敵は「スクラッチ開発」にあり | トップページ | 残高テーブルの設計と統計処理 »

2011.02.24

「動作確認済モデル」でアジャイル開発

 仕様書で動的にシステムを制御するための実装用プラットフォーム「XEAD Driver」の開発が佳境に入っている。このプロジェクトには、仕様翻訳エンジンであるXEAD Driverの他に、2つの大きなソフトウエアが関わっている。仕様書エディタ(XEAD Editor)と、このプラットフォーム上で稼動する実システム「CONCEPTWARE/販売管理」だ。

 売上・仕入・受払が統合されている販売管理システム程度を支えることができなければ、業務システム向けのプラットフォームとしてはお話にならない。それゆえに実システムの作りこみにこだわっている。そういうわけで、DriverとEditorを開発しながら、販売管理システムの仕様書をEditorで作成しつつDriverで動作を確認する、という曲芸のようなマネをやっている。

 相互に関連する大きなソフトウエアを3つ同時に開発するというのは、じっさいややこしい。Driverの仕様に関して改善案を思いつくと、たいていはEditorの仕様や「販売管理」の定義情報まで影響を受けて、3つのソフトウエア全体を大幅に修正するハメになる。そんな調子なので、当初の完成予定がだいぶ遅れてしまった。

 それでも、プラットフォーム(DriverとEditor)についてはほぼ完成した。あとはその上で稼動する「販売管理」のいくつかのサブシステムを仕上げれば、いよいよVerision1.0.0としてGitHubで公開する。現在開発中の「販売管理」はたまたま日本企業向けのパッケージシステムだが、プラットフォーム自体はすでに英語環境に対応しており、XEADが目指す市場は世界だ。

 さてようやく本題なのだが、実装する過程で「販売管理」の仕様がだいぶ変化した。実際の開発案件でもこういうことは起こる。丁寧に基本設計してユーザや同僚にレビューしてもらったとしても、動作させてみてようやく気づく修正点や改善点がどうしても残る。それはおもに私のような設計担当者の無能さによるものだが、ウォーターフォールかアジャイルかに関係なく、それが「スクラッチ開発」の限界ということでもある。

 ゼロからちまちまと設計したりコーディングしたりと、その様子は南国の楽園のように牧歌的で、工期をぜいたくに費消してしまう。短期で上げようと要員を増やしたりすれば確実に品質が低下する。かといって、かつてのように長期でのんびりとシステム開発をやっている余裕などない。そもそも「スクラッチ開発」であることがどうしようもなくリスキーなのだ。

 にもかかわらず、なぜ多くのプロジェクトがスクラッチでがんばるのかというと、前の記事でも説明したように、多くの開発者が「同業種であってもそれぞれの業務システムはそれぞれユニークである」という信念を持っているからだ。また、多くの技術者を抱える開発企業の営業方針としても、要員を多めに投入できるスクラッチ案件のほうが都合がよいからだ。

 そのような信念や事情がなくても、職場でモデルライブラリが整備されていないのであれば、スクラッチなやり方をとらざるを得ない。しかし、その整備は簡単な課題ではない。まず、自分のモデリングノウハウを同僚にタダで提供しようなんて奇特な技術者が少ない。いたとしても、現実の案件のモデルをそのままアップするだけでは、個別案件固有のノイズが含まれるためにライブラリとして使いにくい。広く公開するのであれば守秘義務の問題もある。それゆえにどうしても汎用化の手順が必要で、そのためには経験やセンスが求められる。

 インセンティブが用意され、高いスキルを投入してモデルを汎用的な形に整理できたとしても、問題は残る。汎用化しただけでは全体としての整合性やフィージビリティが保障されない。オリジナルに無理や不整合があれば、類似案件でそこから派生させるたびに問題が転写されてしまう。ゆえにモデルライブラリは「整合性が保障されているモデルの集まり」でなければならない。単純なシステムでは不要だろうが、業務システム程度に複雑なシステムのモデルにはなんらかの保障がほしい。

 「整合性が保障されているモデル」とは何か。大げさな話ではない。「実システムとしてゴキゲンに使えることが確認されているモデル」である。ようするに「実装して動作確認済のモデル」ということだ。しかし、汎用モデルの作成者にちまちまと実装することまで求めるのは現実的ではない。

 そんなとき、XEAD Driverのような「仕様書で動作させるための基盤」が役に立つ。仕様を汎用化しつつ、動作させながらモデルの整合性を確認すればよい。その結果、ただのモデルライブラリが「動作確認済みのモデルライブラリ」になる。こういうものが開発案件の叩き台として利用されるようになる。スクラッチ開発のスタイルが消えることはないにせよ、ライブラリが拡充されるにつれてその優位性は失われてゆく。

|

« 敵は「スクラッチ開発」にあり | トップページ | 残高テーブルの設計と統計処理 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「動作確認済モデル」でアジャイル開発:

« 敵は「スクラッチ開発」にあり | トップページ | 残高テーブルの設計と統計処理 »