450人月と900人月の差は
作業量ではありません

刷新の見積書を前に判断を求められている方へ

基幹システムの刷新でベンダーから幅のある見積もりを受け取り、上限と下限のどちらで稟議を書くか迷っている方に向けて書いています。

幅が大きいベンダーを疑う記事ではありません。その幅がどこから来ているのかを、発注側が言葉にできるかの話です。

同じプロジェクトに2つの数字があります

日経クロステックが、ひとまいる（旧カクヤスグループ）の基幹システム刷新を取り上げています（2026年8月27日）。

対象は1995年に構築されたクライアント／サーバー型の基幹システムです。画面はVB.NETで書かれ、業務ロジックの大半はオンプレミスのOracle Database内のストアドプロシージャに集約されています。画面は2000以上、ストアドは1200本。刷新の期限は2027年8月と定められました。

記事には、検討段階で出た工数の数字が2つ載っています。

把握できた情報から見積もった必要工数は450人月だった。

そしてもう1つ。要件の不明確さなど当時の状況を加味すると、見積もりの倍の900人月程度を要する取り組みになるのではないか、という感覚だったと書かれています。

報道の見出しに出ているのは900人月のほうです。ただし内訳を読むと、この数字は作業を積み上げて出たものではありません。

差の450人月に対応する作業はまだありません

450人月は、分かっている範囲を数えた結果です。画面が何枚あるか、ストアドが何本あるか、それぞれをどう置き換えるか。数えられるものを数えれば出ます。

900人月は、そこに分からないことの重みを掛けた結果です。差の450人月に「この作業に何人月」と対応づけられるものはまだ存在しません。

だから、この2つは精度の違う見積もりではありません。測っている対象が違います。前者はシステムを測り、後者は情報の欠けを測っています。

「今と同じものが欲しい」は要件ではありません

上の層が膨らんだ理由も、記事に書かれています。プロジェクトを率いる同社グループシステム開発部の石井伸明部長は、ベンダー側で見積もりを担当していた当時をこう振り返っています。

要件を聞いても、「今と同じものが欲しい」という感覚的なものしか出てこない。

そして、システムそのものについてはこうです。

30年間積み重ねた結果「なぜこうなっているのか」を誰も知らない。それでも使っている状態だった。

「今と同じもの」は、一見すると最も明確な要件に見えます。仕様書がなくても現物があるからです。

ただし現物が仕様の代わりになるのは、その現物がなぜそうなっているかを説明できる場合だけです。説明できないなら、今と同じものを作る指示は「30年分の判断をすべて再現しろ」と同じ意味になります。再現すべき判断の総量が分からないので、見積もりは幅を持ちます。

AIは主役として登場していません

連載の第2回（2026年9月1日）の見出しは、こうなっています。

AIは「たまたま出てきた」時短手段、カクヤスの基幹刷新は手作業との両輪

刷新の手段としてAIを全面活用している事例でありながら、当事者はAIを主役に置いていません。

幅を縮めるのは値引き交渉ではありません

発注側が上限と下限の差を見て「間を取ってほしい」と言うと、リスクの置き場所が動くだけで幅は縮みません。縮むのは、上の層に入っていた「分からないこと」が1つずつ分かったときです。

私たちが刷新の相談を受けるとき、この層を先に薄くする作業から入ります。ブラックボックス化したシステムをAIで読み解く工程がそれにあたります。現物のコードから、なぜそうなっているかの候補を出す作業です。

ただし、これで幅がゼロになることはありません。コードから復元できるのは「何をしているか」までで、「なぜそうしたか」は当時の判断だからです。残った分は、決める人を先に決めておくしかありません。

期限は2027年8月です

このプロジェクトには、工数とは別の制約があります。刷新の期限が2027年8月と決められていることです。

工数の幅と期限が両方ある状態では、幅の上限で間に合うかどうかが判断の基準になります。下限で計画を立てて上限が出れば、足りないのは予算ではなく時間です。

刷新の速さをAIで縮められるかという議論は、実際に動いていた時間の内訳を開くと見え方が変わります。速くなるのは分かっている範囲の処理で、分からない範囲を分かるようにする工程は別に要ります。

その工程を契約のどこに置くかは、移行のテストをどの範囲で数えるかと同じく、発注側が先に決められることです。