« システム開発ライブのお知らせ | トップページ | 超高速開発とアジャイルの違い »

2018.03.01

DB開発とアプリ開発を分離せよ

 システム開発の過程はふつう、「企画→設計→製造→運用・保守」のようにフェーズ分けされる。それぞれ毎に要員や契約形態に関わる特性が違っているためだ。しかし私は以前から、「企画→DB開発→アプリ開発→運用・保守」に分けたほうがより合理的と考え、実際に効果をあげている。なぜうまくいくかを説明しよう。

 <A方式(従来型)>
 1.企画 → 2.設計 → 3.製造 → 4.運用・保守

 <B方式(現代型)>
 1.企画 → 2.DB開発 → 3.アプリ開発 → 4.運用・保守

 A方式とB方式を比べると、両端の第1、第4フェーズは同じで、それらに挟まれた第2、第3フェーズが違っている。B方式の第2フェーズ(DB開発)においては、DBの設計、実装、およびデータ移行がなされ、第3フェーズ(アプリ開発)ではアプリの設計、実装、テスト、導入がなされる。

 B方式の第2フェーズ(DB開発)がイメージしにくいかもしれないが、これこそ私が「プロトタイピング」と呼んでいるフェーズである。システム要件にもとづいてデータモデリングして、DBを実装する。さらに、必要なアプリ群をプロトタイピングしてDB構造の妥当性を確認する。それが終わったら現行DBからのデータ移行までを行う。続く第3フェーズ(アプリ開発)では、「本番アプリ」が設計・製造されることになる。

 2つの方式の違いは、各フェーズが扱う開発対象の範囲、およびユーザにとっての成果物のわかりやすさにある(次図)。従来のA方式では、「システム全体」に対して「設計」と「製造」とでフェーズ分けしていたが、これでは一度に扱う対象として大き過ぎる。しかも、第2フェーズ(設計)が完了した時点で「動くもの」がないので、ユーザは仕様の妥当性がわかりにくい。いっぽうB方式では、第2フェーズ(DB開発)の真っ最中から、DBとその上で動作するプロトタイプが出来ているので、それを実際に動作させながら仕様を検証できる。

20180228a

 私には実感としてあるのだが、「DB」とその上で動作する「アプリ群」とは、同じソフトウエアであっても異質な構築物で、扱う専門性が違っている。たとえばよく言われることだが、DB構造さえ的確であれば、業務システム開発は8割がた成功したといっていい。それが的確でないなら、どんなに優秀なプログラマを集めてもロクなものが出来上がらない。それほどにDB設計はクリティカルかつ難度の高い課題である。

 いっぽう、プロトタイプだろうが本番モジュールだろうが、アプリ開発は楽になるいっぽうだ。これは、業務システム向けのDSP(ドメイン特化プラットフォーム)が登場しているおかげなのだが、我々の得意技であるはずの「IT」が我々自身の仕事に影響を与えているということに他ならない。「Excel仕様書を見ながらプログラミングする」といった仕事は、遅かれ早かれ「DSLで様式化された仕様書にもとづいて動作するコンピュータ」に置き換えられる。プログラミングの専任要員は要らない。

 じっさいのところ、DB設計は今でも難しいうえに、その出来不出来の影響がとにかくデカい。良く出来たDBは顧客の事業活動に貢献し続け、出来の悪いDBは足を引っ張り続ける。なぜなら、いったん出来上がったDBの構造は、おいそれと変えられないからだ。いっぽう、DB上で動作するアプリ群を新技術で作り変えることは、DB設計がまともであれば容易である。それゆえに、良く出来たDBは企業にとっての「資産」となり、出来の悪いDBは「負債」となる。そしてその上で動作するアプリ群は、様々な手段を用いて「費用」をかけて適宜に更新されてゆく泡沫(うたかた)のようなものでしかない。企業にとっての価値という意味でも、DBとその上で動作するアプリ群とは異質である。

 DB開発とアプリ開発を分離するB方式は、業務システム開発に求められる本来の専門性を明らかにする。すなわち第2フェーズ(DB開発)では、「良くできたDB」という"資産"を手にすることが一義的な目的となる。そのために求められるDB設計スキルは稀少なので、事前のオーディションでその有無がチェックされなければいけない。とくに、その場で初めて聞いたシステム要件にもとづいてその場でデータモデリングさせるといった実技審査は欠かせない。簿記などの業務知識の有無もその過程でバレる。あの手この手で値踏みされて採用された後も、プロトタイプやデータ移行用アプリまで作らねばならないので、半端なスキルではごまかせない。

 ところが従来手法では、要員が「業務知識に裏打ちされたDB設計スキル」を行使したかどうかが、第3フェーズ(システム全体の製造)が終わるまでわからない。じっさいのところ、要員数がものすごく多い割に肝心のスキルが確保されていないプロジェクトが少なくない。「音痴でもたくさん集めれば、お金を取れるハーモニーを生み出せるだろう」と信じて作った合唱団のようなものだ。四部合唱の曲なので少数精鋭4人で賄えるはずなのに、100人以上がステージ上でなにやらシャウトしている。そのような演奏を聴かされる方はつらいが、歌う方も面白くないし、自分が音痴であることさえ気づけずに馬齢を重ねてしまう。これは互いにたいへん不幸な話なのだが、100人の素人を送り込んだ手配師のオヤジだけが儲かって喜んでいたりする。

 いや、この喩えは適切ではない。稚拙な演奏なら観客は席を立って帰るか、聴きにいかなければいい。ところが業務システムのユーザ企業は、それがどんなに使いにくく、保守しにくく、金食い虫であっても、事業を継続するためにそれを使い続けなければならない。これはもう拷問のようなものだが、それがイヤなら業者を訴えるくらいしか手がない。従来手法では、成果に対して取り得る選択肢があまりに少ない。

 B方式ではどうだろう。頻度は多くないだろうが、第2フェーズ(DB開発)の成果に顧客が満足できないことはあるだろう。その際にはそこでいったん契約が終わるので、別の技術者を探してやり直せばいい。従来方式では「まるごと全体が失敗するか成功するか」のバクチであったが、B方式では「DB刷新に失敗するか成功するか」と、「刷新済DBの上で動作するアプリの開発に失敗するか成功するか」にリスクを段階化できる。損害賠償が何十億円なんて話を聞くと、いかにも「まるごと全体が失敗するか成功するか」にこだわった結果なんだろうと切なくなる。

 第3フェーズ(アプリ開発)も進めやすい。先行フェーズでアプリのプロトタイプがすでに出来上がっているからだ。要員についてはあらためて合見積りをとって選定してもいいが、実際には先行フェーズを成功させた少数精鋭チームがそのまま担うことが多いだろうし、顧客もそれを望むだろう。これはけっきょく「スキル要件にかなう少数精鋭だけがシステム開発に関われる」ということで、スキルの有無を問わず人海戦術で進められてきた従来方式と比べて、厳しくはあってもよほど健全である。

 業務システム開発に失敗する原因の多くが、業者に求められる専門性の軽視にあると私はにらんでいる。ユーザ企業はこの単純かつ深刻な問題に賢く対処しなければいけない。そのために、DB開発とアプリ開発の分離、および要員選出のためのオーディションを敢行してほしい。"有名企業で働いています"なんて釣り書きだけで結婚してはいけない。「結婚を前提としたおつきあい」という名のオーディションを通じて、お互いをシビアに値踏みしよう。

|

« システム開発ライブのお知らせ | トップページ | 超高速開発とアジャイルの違い »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: DB開発とアプリ開発を分離せよ:

« システム開発ライブのお知らせ | トップページ | 超高速開発とアジャイルの違い »