日経のITProのサイトで記事を読んでいると、「IT部門が唱える滅びの呪文「ゲンコウドオリ」の本当の恐怖」という記事がありました。
この「現行通り」とか「現行踏襲」というキーワードが出てくるプロジェクトは本当に危険です。
新システムの難易度
一見、現行で動いているシステムの通りに新しいシステムを作れば良いとだけ聞くと簡単に聞こえてきます。プログラムはそのままに単にハードウエアやミドルウエアを最新バージョンに入れ替えるだけであれば、さほど恐れなくても良いかもしれません。
しかし、メインフレームからオープン系のサーバーへ載せ替えたり、プログラムをCOBOLからJavaに書き換える、データベースの構造を正規化して更に整理するといった話しが付いてくると、かなり難易度の高いプロジェクトになります。
また、そのお客様特有のビジネスロジックを多く含んでいたり、トランザクション量が多いがために処理速度が速くなるような工夫が随所に散りばめられているような現行システムを新システムで動かすのは更に難易度は高くなります。
現行システムから新システムへの変換
現行システムの延長ではなく、「プログラムもデータベースも新たに設計をやり直して、最新の技術を使って綺麗な状態のシステムを作ろう」という目的自体は否定するものではありません。問題はそのプロジェクトのお客様なりベンダーなりに、システムで具備すべき要件を把握している人がいるかどうかにかかっています。現行システムから新システムを再構築するときには、一般的に下記の道筋をたどると言われています。
———————————————————————
①現行物理モデル ： 現行で実装されているシステムのモデル
↓
②現行論理モデル ： 実装状態（手段）を取り除き、要件まで持ち上げたモデル
↓
③提案論理モデル ： 現行論理モデルに新システムの新要件を加えたモデル
↓
④提案物理モデル ： 提案論理モデルを物理実装状態に落としたモデル
———————————————————————
現行物理モデルの設計書があるか
第一のハードルは現行物理モデルの設計書等ドキュメントがすべて揃っているかどうかです。詳細な実装スペックはおろか、現行システムを構成する資材（プログラム、JCL、・・）が全部でどれだけあるかを正確に管理できているシステムですら、さほど多くないかもしれません。
要件は揃っているか／解っているか
第二のハードルは現行の実装内容は何のために行われているのかという要件が適切に整理できているかどうかです。これが無いと②の現行論理モデルを作ることができません。しかし、この部分のドキュメントや知っている人が残っているシステムは稀なのではないかと思います。
伊勢神宮では原則として20年に一度、内宮、外宮、別宮のすべての社殿を造り替えます。第一回が690年に実施されて、以来、1300年にわって実施されてきています。一つは老朽化しやすい素材、構造が一部で使われているため、20年をめどに建て替えが必要なことが挙げられています。しかし、もっと長持ちする建築技法も確立されているのに、なぜ長年にわたってこの建築様式が守られてきた理由の一つに建て替えの技術の伝承があるのではないかと言われています。
Wikipediaによれば、建築をする大工は10歳代から20歳代で見習いとして働き、30歳代から30歳代で棟梁となり、50歳代以上は後見となります。このため、20年に一度の遷宮であれば、少なくとも2度は遷宮を経験すれば技術の伝承を行うことができると推測されています。
システム開発もこれと同様なことが言えて、20年以上にわたって手を付けられずにハードの更改と機能追加で何とかしのいできたシステムは、いきなり新システムにしようとしても、お客様の中にもベンダーの中にも中身が判っている人の数が少なくなってしまっていると思います。
もし、このようなシステムを新システムに再構築したい場合には、現行システムの構成内容を棚卸しして、なぜそのような実装が行われているのかという要件を洗い出す必要があります。この要件（現行論理モデル）から新システムの要件（提案論理モデル）を作らなければいけません。
この過程を経ないで、「現行踏襲」の一言で片づけられてしまうと、何が要件なのかが定かではない中で開発が先に進んで、やがて大混乱に陥ります。この新システムの要件については現行システムからの踏襲分も含めて、発注者の責任の下で定義される必要があります。
プログラムソースからは要件は読み取れない
よく、現行の要件はソースプログラムを渡すからそこから読み解いてくれというお客様がいます。しかし、ソースプログラムには実際に現行のアーキテクチャの上でどのように実装されているかは書かれていますが、「なんのために」そのロジックになっているかの要件は書かれていません。したがって、要件を正確に読み解くことができません。
大胆な改革は経営主導で
大きなコスト削減を目的として新システムを構築するのであれば、ビジネスプロセスの改革やあまり使われていないサービスの廃止など大胆な改革も必要になるので、経営の責任者主導で進める必要があります。開発の現場任せで進めてしまっては小手先の対応で終わってしまい、苦労して作った新システムの開発コストが回収できないような事態になる危険があります。
本当に新システムにするのが良いのか否か
あるシステムで機能追加を繰り返したがために、保守性が悪化しており、機能追加時の品質が悪かったり、デグレードテストの範囲が広がるために改造にかかる費用が高くなっているという話しはよく聞きます。しかし、これが本当にプログラムの構造が悪くなっているためなのか、そのシステムが要求する機能的品質レベル、非機能的な品質レベルが高いことに依存して高くなっているのかは、よく評価する必要があります。
ときどき、「プログラムの規模が数百Kstepの開発経験を持つ人が、1stepあたりの開発コストは1000円未満でなければおかしい」と指摘される方がいます。これは確かにある規模、求められる品質レベルがある範囲のシステムであれば、この基準は適用されるはずですが、大規模ミッションクリティカルシステムもこの基準で測ろうとすると変なことになってしまいます。
対象とするシステムの規模や載っている業務の難易度、トランザクション量などから、本当にそのシステムの保守にかかる工数はいくらが適切なのかを評価して、それよりも費用がかかっているのであれば何故高いのか、その原因を取り除くためには新システムの再構築が良いのか、保守支援用の仕組みを導入するのが良いのかといった具体的な対策を綿密に比較評価する必要があります。
コメント