« SQLを使わないでシステム開発 | トップページ | モデル駆動(MDA)から仕様書駆動(SDA)へ »

2013.02.04

システム開発のHowToではなくWhatを

 拙作の超高速開発ツールXEAD Driverの特徴のひとつは、「オープンパッケージ」と呼ばれる本格的な業務システムがバンドルされている点にある。現在は卸売業向け販売管理システムだけだが、私が組立型生産管理システムを開発している他に、ユーザ会でも企画が進行中だ。

 私たちがこれにこだわるのには理由がある。オープンパッケージそのものは無償提供されるが、カスタマイズ作業やそのために必要な分析設計作業や教育は有償サービスとして提供される。オープンパッケージはそんな支援型ビジネスのインフラである。これは、従来のSIのように人海戦術でなされる請負型ビジネスとは180度異なっている。

 このことに関係するのだが、私はアジャイルをはじめとする「いかに業務システムを作るべきか」をめぐる「HowTo論」にずっと違和感をもっている。断言するが、HowTo論をいくら熱く語りあってもほとんどのプロジェクトは救われない。なぜならそれではプロジェクトのボトルネックが解消されないからだ。もちろんHowTo論も必要な議論には違いない。しかし、それを適用することが的外れなレベルのプロジェクトがあまりに多いのが実状なのだ。

 どういうことか。私の実感では、ほとんどのプロジェクトにおけるボトルネックは「いかに業務システムを作るべきか」ではなく「どんな仕様の業務システムにすべきか」すなわち「What論」にある。「HowToがわかればWhatは自ずと明らかになる」などと期待してはいけない。それはまるで「設計図の描き方や建造過程での問題管理手法がしっかりしていれば、どんな飛行機を作るべきかは自ずと明らかになる」と期待するようなものだ。業務システムは飛行機と同様に、周到なモジュール構造をなす巨大で複雑な工学構築物である。そのHowToとWhatとの間は途方にくれるほど隔絶している。

 そんな対象について「小さなまとまりでのイテレーションを繰り返しつつ、的確なWhatを探るべきだ」とするHowTo論がある。まあ悪いアイデアではない。ただし、そのやり方でうまくいくためには、分析・設計の経験豊かな技術者の参画が求められる。彼が全体と部分とのバランスをはかりつつ内部構造をデザインできるからだ。彼の会計知識も生かされて、ユーザとの活発な対話を通じて満足のゆく仕様が生み出されるだろう。アジャイルもなかなかいいじゃないか、となるだろう。

 ところが、そんな頼りがいのある技術者が、管理者になるとか引退するなどして現場からあらかた姿を消してしまっている。この現実を前提とすれば、どんなやり方でもプロジェクトを成功させることは難しい。なぜなら、仕様策定のために参考にできる手がかりが、システム開発に関するプロではないユーザの意見だけだからだ。それはちょうど「旅行マニア」にヒアリングしながら飛行機を設計するようなものだ。出来上がる機体は、居住性に優れ見た目も麗しいものとなろう。しかしそれは飛ばないか、もっと悪いことに飛んでから墜落する。

 それではあんまりだてんで、別の手がかりが探られる。典型的なものが「現行システム」だ。全面刷新するために企画されたプロジェクトがしばしば、開発言語とL&Fが今風になっただけの「最新の建材で出来た竪穴式住居」を生み出すのはそれゆえだ。いまいましいほど使いにくい現行システムの仕様と、使いにくいなりにこれに馴染んだユーザの意見――この組み合わせを仕様策定の手がかりにするのだから、当然の結果である。

 ただしかつての現場に、分析・設計に関して頼れる技術者が潤沢にいたという話でもない。運よく分析・設計をじっくり経験できた技術者も、次から次に新しいプロジェクトにまわされる。ほとんどのITベンダーは、彼らの貴重な体験や業務知識を形式知化するという投資的試みをしなかった。せいぜい、出来上がったシステムをテキトーに流用して商用パッケージとして売り散らすことしか考えなかった。

 けっきょく今も昔も、What論が磐石なプロジェクトはごく少ない。ウォーターフォールかアジャイルかといったHowTo論が制約条件になっているような恵まれたプロジェクトは、じつは今も昔もごく少ないということだ。

 そういうわけでいまだに我々は、ウォーターフォールなりアジャイルなりで、"スクラッチ"での設計・開発をドキドキしながら繰り返している。その成功率は同じ名の宝くじと変わらない。一時は商用パッケージがWhat論を補助するのではないかとも期待されたが、コストパフォーマンスが悪すぎた。しかもカスタマイズする過程でたちまちブラックボックス化して、企業の変化・発展を阻害する不良資産となった。ユーザ企業が幸せになれる確率はこれまたドキドキの"スクラッチ"並みだ。

 このように嘆かわしい現状の原因を、ITベンダーの無定見や近視眼に帰すのは簡単である。しかしそれを指摘するだけでは何の解決にもならない。What論の根深い欠損感をじぶんの手で埋めるしかない。

 私たちの「オープンパッケージ」の開発は、そのための活動の一環だ。業種・業態毎の業務管理システムの雛形を「実際に動作するシステム」としてライブラリ化する。それは、データモデルや業務マニュアルといった基本設計情報が添付されていて、オープンソースで、カスタマイズが容易なものでなければならない。基本設計のレベルから丁寧にカスタマイズすることで、導入企業の独自性や強みが担保され、システムの保守性も維持されるからだ。

 ただし、こういった知的社会資本を整備するためには、意志だけでなく優れた道具立てが要る。的確な分析・設計方法論で裏打ちされたモデリングツール、それに超高速開発ツールだ。これらの得物が揃うことでようやく、個々人毎に不定形に蓄積されたWhat論を形式化・一般化するための準備が整う。

 繰り返そう。ほとんどのプロジェクトにおけるボトルネックは、ウォーターフォールかアジャイルかPMかホニャララかといったHowTo論ではない。「どんな仕様の業務システムにすべきか」すなわちWhat論である。これをレファレンスモデルやオープンパッケージ等のリソースで手当てしない限り、ほとんどのプロジェクトは救われない。

|

« SQLを使わないでシステム開発 | トップページ | モデル駆動(MDA)から仕様書駆動(SDA)へ »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: システム開発のHowToではなくWhatを:

« SQLを使わないでシステム開発 | トップページ | モデル駆動(MDA)から仕様書駆動(SDA)へ »