プロジェクト成功の鍵：見積もりが最初の分かれ道
皆さんは既存システムの更改時に、プロジェクトの見積をどのように見ていますでしょうか。今までお付き合いしている、いわゆる既存ベンダーに見積もってもらっているケース、ソースコードの量( Source Line Of Code、つまり行数。 以下 SLOCと略) や複雑度から見積もってもらっているケースなどがあるかと思います。
見積から完成までの注意点を見ていきたいと思います。
見積の根拠が「既存のSLOC」の場合
ハードウェアやソフトウェアの保守切れ、または運用費用のコスト高等の理由により、新しいアーキテクチャ・新しいプラットフォームでの開発を夢見て、システムインテグレータに見積り依頼を出すかと思います。システムインテグレータ側は、お客様の要望などをヒアリングしながら見積を作ろうとしますが、設計書等が古い、または欠落しているなどで現状の様相がわからない、さらに業務側とのつながりもないために、どのようなシステムを希望しているのかもわからない状態です。お客様からは「類似のケースで見積もって欲しい」との要望も受けますが、全く同じ内容のシステムなど無いわけです。
となると、拠り所をどこにするかというと、既存ソースコードの量や難しさということになります。
難易度を図るのは業界で振り分けるにして、ほとんどのケースは、既存のソースコードの量からの見積なのではないかと思います。全体の工数を算出するにはわかりやすく、かつ、的確であると思われているため、多くのシステムインテグレータは、既存ソースコードの量や言語と、独立行政法人情報処理推進機構(IPA)が出している「ソフトウェア開発分析データ集」から、必要な工数を導出していると思います。例えば下記のような感じです
既存ソースコードの量を3,000,000SLOC とします。
現行ソースの解析を含めた要件定義 （デキるSE前提）
1,700,000 円/人月 * 80人月 = 136,000,000円
新しいアーキテクチャに合わせた設計（同じくデキるSE）
1,700,000 円/人月 * 100人月 = 170,000,000円
2022年度ソフトウェア開発分析データ集 P90 表A1-2-3 SLOC規模別 SLOC 生産性（再開発） 300KSLOC 以上:
平均値 3.32KSLOC/160人時 （160人時は1人月相当）
3,000,000 SLOC / 3,320 SLOC/人月 = 903人月
プログラマーを人月単価 1,200,000円として
1,200,000円/人月 * 903 人月 = 1,083,600,000 円
要件定義 + 設計 + 開発・テスト = 1,389,600,000円
リスクを 30% と勘案し、
1,853,900,000 * 1.3 = 1,806,480,000円
利益率を40%とすると、
2,410,070,000 * 1.4 = 2,529,072,000円
目眩がしてきますね…
つまり単純に考えると、300万行あるアプリケーションの作り変えには、おおよそ 25億円が必要となります。業務の重要性・難易度によっては、25億円以上の見積りも普通にありえることになります。
見積後の行動は？
統計情報から見積もると確かにこのような計算となりますが、エンドユーザ側から見ると、「そんな馬鹿な！高額すぎるのでは？」となります。
費用は高いがハードウェアやソフトウェアの保守も切れるとなると、やりきるしか無いということで稟議に掛けます。ところが、この費用に見合う効果を経営陣より求められます。効果を幾つか積み増すも、経営陣を説得する事ができない場合、次のようなアクションを取り始めます。
現行のベンダーに依頼することで、要件定義や設計のコスト圧縮を図る
既存のソースコードを流用するなどで費用の低減を図る
部分的な改修に留め、DB等のコストの掛かるところを等は延命を図る
現行のベンダーに依頼すると、どのようなことが起きるか、考えてみましょう。
まず、「機能単位」での仕様の作成をします。機能自体の分割や再構築を考えると費用が高くなるがゆえ、現行ベンダーにお願いするわけですが、そうすると現行ベンダーは「今やっているもの」のまま、設計を行っていきます。機能単位で一まとまりとなるため、その内部がスパゲッティになっている、もしくは多数のDBのテーブルを参照・更新しているような場合、分割案されずに「そのまま」の形で設計されていきます。
お客様からの「現行踏襲でお願いしたい」ということより、全ての機能を移管しようとします。ただし、費用削減のために「利用されているコードのみ」を抽出したいわけですが、ソースコードからでは、どの機能が使われている・使われていないかの判別ができません。そして、ソースコードの解析を勧めていく中で、使われなくなったロジックで消し忘れていたゴミ等が整合性を確認できず、多大な時間を消費した上で最終的には「辻褄が合わない」という結果が出て来るため、移管すべき機能の数で充足度を測ろうとしてもできず、何をもって現行踏襲とするか という観点が揺らいでしまいます。
こうなると、その後の開発においては、現行と同じアーキテクチャ・ロジック・データテーブル構造で実装することとなり、現行アプリとほぼ同じものが膨大な費用を掛けて出来上がることになります。
これは危機感を煽る空想ではなく、残念ながら実話なのです。（上記の金額は想造ですが…）
対策はあるのか？
なぜそうなってしまったのか。重要な分かれ道が、「システムインテグレータの見積り」です。
今までのアーキテクチャ・開発手法での見積りであるから高額になります。大変残念なことに、大手システムインテグレータは、「過去に実績のないアーキテクチャ・開発手法では見積もることが出来ず、社内承認が通らない。」という理由で、先進的な取り組みをやりたがりません。
無駄を排除する取り組み、品質を最初から高くする取り組みを行うべきなのです。その1つの答えが、サービス型のアーキテクチャと繰り返し開発です。特に、ルール駆動開発は、アプリケーションの中枢的な部分であるロジックの実装に注目し、ディシジョンサービスとデータサービスの分離ができれば、勝手にサービス型アーキテクチャになりますし、繰り返し開発になっていきます。
大きなプロジェクトの全体見積をプロジェクト開始前の段階で精緻に出すことは不可能です。システムインテグレータ側も、通常の工数に対してかなりのリスク分を載せてくるので、見積り金額としては膨大になりがちです。
そうであるのであれば、フェーズと役割に応じたプロジェクト進行とし、そのフェーズ毎に予算化と実行をすべきです。何かを製造する現場は、必ずモックやプロトタイプを作成し、その性能などをチェックしながら設計・製造を行っていきます。事前のチェックもなくいきなり量産品の製造は開始しません。それと同じことです。
まとめ
システムを新しくしたいが、どの機能やロジックが使われているかわからない、一方で過去に作っているものを捨てるのは勿体無い... という場合、思い切ってアーキテクチャや開発手法を変えて、「今やっているビジネス」から作り直すことを強くお勧めします。結果の整合性のチェックには、直近数年分等の過去のデータを使って確認します。間違っても過去のソースコードの解析から始めてはいけません。
現行踏襲の本当の意味も合わせてお読みください！