« 内製の前に「自社保守」を目指そう | トップページ | UML版在庫データモデルの問題 »

2018.03.28

業務システムを「牢獄」にしないために

■「移行容易性」を確保せよ

 ツール活用型開発に対して、「ツールベンダーがつぶれたらどうするんですか?」という批判を聞くことがある。ツールベンダーの多くは小規模かつ無名で、いつ倒産するかわかりませんよ。そんな会社を御社の業務システム開発に関わらせるべきではありません――もちろんこの主張は、それを言う大手業者からの「我々はつぶれる心配がないので安心しておまかせください」のアピールとセットになっている。

 たしかにツールベンダーがいきなりつぶれたら困るが、業務システムについて優先的に心配すべきことは他にある。「使えなくなる」ことよりも、使いにくいとか金食い虫とかいった理由から「棄てたくなる」ことだ。現実にそんな事例があきれるほど多い。ベンダーがつぶれるよりもずっと高い確率でそれは起きている。

 「ベンダーがつぶれたから使えない」にせよ「使いにくいからもう棄てたい」にせよ、いろいろな理由からシステムを刷新したくなったときに、別の基盤に簡単に移れるかどうか。すなわち「移行容易性」は、あまり取り沙汰されないが業務システムの重要な評価指標である。「いざとなれば他の基盤に簡単に乗り換えられる安心感」と言い換えてもいい。

 たとえば、今でもホストコンピュータやCOBOLシステムを使い続けている企業があるが、彼らの多くは「移行容易性」の欠如ゆえにそれを使い続けている。これこそがベンダーロックイン、正確に言えば「基盤ロックイン」の実相である。他に、ERPパッケージを大枚をはたいてカスタマイズしたような場合にも、基盤ロックインは起こる。そういうケースでは、移行が難しいだけでなく「これだけお金をかけたのだから、今さら他の基盤に移るのはモッタイナイ」といった事情(埋没費用)も作用する。ともあれ、住み心地が良かろうが悪かろうが、いざという時に素早く逃げ出せないならそこは「牢獄」である。

■DB設計については手を抜かないこと

 では、移行容易性をどのように確保すればよいのだろう。2つの原則を挙げよう。まず、「DB設計については手を抜かないこと」だ。システムの使いにくさや保守性の悪さの根本原因は、DB設計の稚拙さであることがきわめて多いからだ。DB設計が的確であれば「棄てたくなる」ことも減るし、他の基盤でアプリだけを作り直すこともずっと容易である。

 じっさい、DB設計の出来不出来は、開発環境の選定や使い方にも影響を受ける。たとえばRailsのように主キーがすべて「id」であることを強制するような基盤を使えば、DB設計が珍妙化して、異なる基盤への移行が無駄に難しくなる。また、個々のRDBMSが提供する固有機能を安易に活用しても同じ問題を生じる。他のRDBMSに移る際に同じことがやれるとは限らないからだ。ロックインの罠はDBまわりでもいろいろと仕掛けられている。不慣れな技術者に決してそこらへんをまかせてはいけない。

■アプリ開発については手を抜くこと

 移行容易性を確保するための2つ目の原則は、「アプリ開発については(DB設計と比べて)手を抜くこと」である。業務システムの一義的な目的は、DBに格納されるデータの整合性を維持することで、アプリはそのための手段でしかない。DBはゆっくりとしか変化できないが、アプリはどんどん生まれては消えてゆく泡沫(うたかた)のようなものだ。JavaやRubyといった汎用プログラミング言語を使う「コードベース開発」においてアプリは丁寧に手作りされるので、それらをゴッソリ棄てるのはさすがにモッタイナイ。しかしそれが「牢獄化」の始まりだ。

 我田引水でも何でもなく、この点についてはツール活用型開発に軍配が上がる。ここで言う「ツール」のおおまかな定義は「様式化された仕様情報を、そのままアプリとして動作させるための基盤」である。すなわち、仕様書を書くことが強制されてドメイン特化言語(Domain Specific Language,DSL)として様式化され、そのままコンピュータにとっての「動作指示書」になる。DSLは特定分野の特性に沿って設計されるので、基盤そのものについても適用分野が限定される。「ドメイン特化基盤(Domain Specific Platform,DSP)」と呼ばれるのはそのためだ。DSP上ではアプリをどんどん書けるので、それを棄てることに抵抗を感じようがない。

 では、DSP上で書かれたアプリ群を他の基盤に移植するにはどうしたらいいのだろう。移行先が他のDSPであれば、DSL様式を変換するための移行プログラムを用意することで一挙に移行できると思われるかもしれない。しかしDSL間の違いは想像以上に大きいので、バッチ処理的に移行できるアプリは一部だけと考えたほうがいい。そうだとしても、DSP上のアプリが移行の起点であることの意義は大きい。DSP上で仕様書を眺めながら、他の基盤(必ずしもDSPである必要はない)上のアプリを書けばよいからだ。

■コードベース開発の極小化

 いっぽうDSPを使わないコードベース開発において、移行元のアプリ群はJavaやRubyのコードの塊である。仕様書があるとしても「Excel方眼紙」だったりするので、けっきょくコードを調べないとシステムのあり方がわからない。膨大なExcel方眼紙と膨大なコードを手書きするので、開発や保守に膨大な要員と工数が要る。それだけでなく、他の基盤に移行するにも手間がかかる。これほど手間のかかるコードベース開発がいまだに主流なのはなぜか。多くの業者は人月商売を基礎としていて、開発に手間がかかるほど儲かるからだ。

 なお、コードベース開発にこだわる業者からは、「DSPではきめ細かい要望に対応できない」といった批判もよく聞かれる。たしかにきめ細かい仕様が求められるアプリは存在するが、そういうものは全体の1割以下に留めたほうがいい。その比率が増えるほど、管理すべきコードの量が増えるとともに、移行容易性が低下してシステムが牢獄化するからだ。ちなみにその種のアプリはしばしば、旧システムに慣れ切ったユーザが自己のエンプロイアビリティ(雇用意義)を保全・強化するために要求される。開発業者はそのことを知っているのだが、なにしろ工数が増えるので「ユーザのきめ細かい要望」を必要以上に重要視する。

 まとめよう。ユーザ企業は、まずは的確な構造を持つDBを実現することを優先させなければいけない。それを確保できたなら、一部の重要な機能については業者にコードベースで手作りしてもらえばよい。それ以外の「泡沫アプリ」についてはDSPを使って自分たちでサクッと作ってしまおう。アプリを重要性に従って序列化し、予算の使い方にメリハリをつけるためだ。そしてもし運悪くDSPのベンダーがつぶれたなら、「そのまま動く仕様書」を見ながら、別のDSPでサクッと作り直せばよい。アプリなんかに振り回されてはいけないし、それに囚われるべきでもない。

|

« 内製の前に「自社保守」を目指そう | トップページ | UML版在庫データモデルの問題 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 業務システムを「牢獄」にしないために:

« 内製の前に「自社保守」を目指そう | トップページ | UML版在庫データモデルの問題 »