"項目一つを修正するのに、数十万円(もしくは数百万円)の見積もりが出てきた!" への回答

これまでに何回か、Wagbyの提案で新規のお客様を訪問したとき、次のような相談(あるいは愚痴)を伺ったことがあります。

現行システムは、項目一つを修正するのに、数十万円(もしくは数百万円)の見積もりが出てくるんだよ。

最初の頃は相槌をうって、"それは厳しいですね…” などと返していたのですが、かとって現在、保守を担当しているSIerが不当な金額を請求しているわけでもないでしょう。それだけの工数がかかる理由があるのです。

ということで最近は、”それは厳しいですね。しかしこの解決は簡単ではありません。Wagbyのようなツールを導入すれば安くなるということではないのです。” と切り返すようにしています。ツールの導入によって保守性が高まると期待されて声をかけていただいたところに冷や水を浴びせるのは申し訳ないのですが、ここをどれだけ丁寧に説明できるかは、営業の腕の見せ所でもあります。

そもそもなぜそんな高い見積もりがでてしまうのか

システム改修にかかる費用はほぼ人件費であり、要するに作業時間(工数)です。ところがお客様が大企業になるほど、例の一次請、二次請、三次請という多重ピラミッド構造が見え隠れするので、仮に300万円の見積もりでも現場担当エンジニアにはその数分の一ということもありえます。しかしこれは別の問題として、いったん置いておきます。

純粋に300万円分の工数がかかる場合もあります。最大の理由は影響調査でしょう。この変更によってどのモジュールが影響を受けるのかをシステム全体にわたって調査するのです。そしてもう一つは改修後のシステムテストです。これも規模が大きくなるほど工数がかかります。つまり変更作業そのものは数時間で終わったとしても、その前後に大きな作業がある、という構造になっています。加えて、ドキュメントの保守やら関係部署への連絡やら操作教育やら、既存システムのデータ移行やらが入ってくると、300万円でも足りないかも知れません。

理由はわかった。では諦めるしかないのか?

ここからが本題です。なぜ影響調査にこれだけ時間がかかるのか。一つ目の可能性は「サブシステムごとに縦割りで開発してきた」ため、システム全体でプログラムやデータの重複が発生しているというものです。ある修正によって影響を受けるプログラムを特定できたとして、それをコピー&ペーストして他で使っているところがないか、をシステム全体にわたって探すのは大変な作業です。これがプログラムではなくデータの重複であれば、もっと根が深いです。同じ「項目の追加」をあちこちのサブシステムに適用しないと整合性がとれなくなります。ということは、次回に同じような修正要求が発生した場合、データの重複の上にまた重複ということで、難易度はさらに上がることも容易に想像できます。

もう一つの可能性は「調査を支える設計書の不在」です。または設計書はあるが信用できない場合です。設計書が大量の印刷物であれば読む気も起こりません。これがExcelであっても同じです。自由文章で書かれた設計書から影響分析を行うのは大変な労力です。

これらは大規模システム開発の古典的な課題であり、多くの開発者がかかわる以上、不可避なことと考えられていました。しかし本当に解決できないのでしょうか。

超高速開発、でやろうとしていること

この積年の課題に対してソフトウェア工学からの取り組みがなかったわけではありません。対策の一つはサブシステムごとの開発の前に、データ構造の設計を行う、いわゆる「データモデリング・ファースト」です。上の理屈から、データの重複を排除することができれば、おのずと保守工程は軽くなります。そしてもう一つは、設計書の標準化です。ここでいう標準化とは、ルールに基づいた設計書であれば影響分析を自動で行えるというレベルを指します。それをExcelだけで実現するのは難しく、設計書を管理する専用のソフトウェアの存在が求められます。

標準化はもう一つの恩恵をもたらします。それはパターン化です。業務システムの本質はデータ管理ですので、登録して検索して集計して…というニーズは変わりません。それらをパターン化することによって、少人数で大規模システムを設計することができるようになります。

ここまでの下地があって、はじめて超高速開発手法を適用できます。パターン化された設計書と、適切なデータモデルがあれば、プログラムの自動生成が可能です。このレベルに達することで、開発生産性だけでなく、保守性も著しく向上できるようになります。

さらに昨今の超高速開発ツールは単体テストではなく、End to End テスト(E2Eテスト) も支援するようになっているため、テストの自動化も行えるようになりました。一度テストプログラムを作成すれば自動実行できるため、変更後のテスト工数も大きく削減できます。

現行システムへのツール導入はできない?

残念ながら、現行システムにそのまま適用できる都合のいいツールは存在しません。ツールの導入とはすなわちデータモデリング、パターン化された設計情報、テスト自動化フレームワークといった技術とセットです。そんなことをいったら作り直しではないか、となりますが、そのとおりです。このようなタネや仕掛けがある、ということを正しく説明するのがツールベンダー関係者にとって共通の仕事です。

このまま現行システムの軽微な?改修のたびに数百万円をかけ続けていくか、それとも部分的に(新しい手法で)作り直していくか。悩ましいテーマです。

前者はボディブローのように企業のIT投資金額を奪っていきますが、決してプラスにはならず、せいぜい現状維持です。そして昨今、「デジタルトランスフォーメーション」というキーワードを目にするようになりましたが、これが示唆しているのは、異業種または海外企業からの新規参入組は、現行システムをもたない分、有利な立場にいるということです。

もし後者でいこうとお考えなら、データモデリングという視点で開発会社を探すことを推薦します。ちなみに提案書とか持参させるのは無意味です。過去の実績も不要です。実際に担当してもらえる開発者に、その場でデータモデリングをしてもらいたいと声をかけるだけです。これで自然に選別されます。

これまで経験してわかったことは、発注者(ユーザ企業)の担当者とデータモデリングの専門家による協調作業という内製開発は、超高速開発と相性がよいのです。当然、受け側のデータモデラーの人月単価はお高いですが、長期運用を考えると、そのメリットははかりしれません。これが「1項目追加で数百万円かかる」という難題を解決する、私からの回答です。長文で失礼しました。これを口頭で話すのは難しい...。

これまで国内でデータモデラーが少ないのは、市場ニーズがなかったためでした。しかし今、ツールを前提とした開発機運が盛り上がる中で、データモデラーの重要性に気づいて、よい人材をプロジェクトに加えたいというニーズは高まっています。ツールの利用を前提としたデータモデリングというのが、新しい視点です。この普及のために、データモデリングの成果が「実際に動くシステム」になっているという体験ができる場を増やしていきたいと考えています。