机の上に、3社の提案書が並んでいます。

レガシー化した EC サイトや業務システムのリプレイスを検討していて、複数のベンダーから見積りを取った。金額に差がある。どこから来ている差なのかを知りたい ── そういう状況で、この記事にたどり着いた方が多いのではないかと思います。

金額差の理由は、実のところ、突き合わせればかなりの部分が説明できます。どこまでを見積りの範囲に含めたか。リスクに対してどれだけの余裕を積んだか。データ移行の作業をどちらが持つことになっているか。この3つを各社の見積書から拾い出し、前提を揃えて並べ直せば、3社の数字はたいてい比較可能な形になります。 ここまでは、外部の助けを借りずに自社で詰められる範囲です。

問題は、その作業を丁寧にやって選んだ見積りでも、外れることがあるということです。

3社の見積りが並んでいるとき、何を比べているのか

日本情報システム・ユーザー協会（JUAS）が毎年公表している『企業IT動向調査報告書』の2025年版を見ると、システム開発プロジェクトの予算遵守状況が規模別に集計されています1。回答しているのは東証上場企業とその子会社が中心なので、そのまま自社に当てはまる数字とは限りません。ただ、傾向としては参考になります。「予定より超過」の割合は、100人月未満で 11.9%、100〜500人月未満で 26.1%、500人月以上で 37.2% でした。規模が大きくなるほど、予算どおりに収まらない割合が上がっていきます。

この調査はシステム開発全般を対象にしたもので、リプレイスやシステム再構築に限定した集計ではありません。ただ、同じ調査には見積りを考えるうえで示唆的な数字があります。

予算が予定どおりにならなかったと答えた企業に、その要因を尋ねた設問です。そこで 45.9% の企業が挙げていたのが、 「想定以上の現行業務・システムの複雑さ」 でした1。

これは、見積書の行を1つ足せば埋まる種類の項目ではありません。並行稼働の費用を計上し忘れたとか、保守費の単価を間違えたという話であれば、次からはチェックリストに1行足せば済みます。しかし「想定していたより複雑だった」は、見積りを作った時点では見えていなかったものについての申告です。何を書き足せばよかったのかが、その時点では分からない。

なお、この数字が示しているのは、発注側が理由をそう認識していたということまでです。複雑さの中身が何であったかまでは、この調査は語っていません。

そこから先は、私たちが実際に外した案件の話をします。

要求が「旧システムでできたことを、そのまま」に寄っていった

年商が億の規模にある美容系 EC サイトの、フルリプレイスの案件でした。

当初、話を進めていた相手はクライアントの IT 部門です。長年の運用で積み上がった機能を整理し、使われていないものを削ぎ落として、シンプルなシステムに作り替える。私たちもクライアントも、その方針で意気込んでいました。

ところが進むにつれて、現場の担当者から意見が集まってきます。あの画面のこの操作がないと困る。この帳票は毎月使っている。集まった声を反映していくうちに、要求は少しずつ 「旧システムでできたことを、そのままできるように」 へ寄っていきました。結果として、削ぎ落とすはずだった機能はかなりの部分が残り、むしろ追加され、工数も大幅に増えました。

誤解のないように書いておくと、これは誰かが悪かったという話ではありません。IT 部門は現場の要望を握りつぶさなかっただけで、発注側の組織として正しく振る舞っています。現場も、自分たちの業務に必要なものを言っただけです。起きたのは、着手前の時点では、現場が何に依存しているかが要件の形になっていなかった、という順序の問題でした。

この形については、以前 ECサイトのリプレイス、いつやるべき？ で「ベンダー任せで現場が使えないシステムに」という失敗パターンとして書いたことがあります。あちらでは、技術的には正しいのに現場の業務フローと噛み合わないシステムができてしまう、という現れ方で書きました。今回お話ししているのは、同じ齟齬が工数の膨張として出たケースです。あちらの記事では対処法として現場の業務フローを詳細にヒアリングすることを挙げましたが、この記事はその先で私たちが躓いた話になります。

似た構造は、公的な資料にも記録されています。情報処理推進機構（IPA）が大手システムインテグレーター各社と共同で作成した『システム再構築を成功に導くユーザガイド』は、利用部門に現行踏襲の内容を確認していたとしても、運用検証で利用部門が実物を触る段階になって「こんなはずではなかった」という認識齟齬が明らかになるケースがある、と書いています2。

つまり、確認していなかったから起きるのではなく、 確認しても起きる 、という書かれ方をしているわけです。

同じガイドには、こうも書かれています。ギャップはユーザ企業とベンダ企業の間だけではなく、 ユーザ企業の中でも、システム部門と利用部門との間に 生じることがある2。

私たちは要件を聞いていなかったわけではありません。聞いた相手が、現場の全部を知っているわけではなかったのです。

稼働後に見つけた、中途半端な状態のデータ

もうひとつ、別の出来事があります。

システムが稼働したあとで、作業中のような、中途半端な状態のデータがあることに気づきました。何かの処理が途中で止まったのだろうか。気になって、クライアントに問い合わせました。

返ってきた答えは、こうです。特定の条件のときに、意図的にその状態にしている。現場ではそういう運用になっている ── と。

現場にとっては、日々の当たり前の手順でした。異常でも何でもない。ただ、それは私たちに伝わっていなかっただけではありませんでした。 クライアントの IT 部門も、そのことを知らなかった のです。

窓口の担当者は、私たちに対して誠実に答えてくれていました。隠していたわけでもありません。それでも、窓口自身が知らないことは、そこを通っては届かない。1件の経験から一般化するつもりはありませんが、そういうことが起こりうるのだと考えるようになりました。

こうした体制自体は、特殊なものではないようです。要求工学の研究者たちは、一部の企業では、現場とソフトウェアの供給元との仲介に立つ IT の担当者が置かれている体制がわりあい一般的だと書いています3。

要件として現れたものと、データとして現れたもの。現れ方は違いますが、伝わっていなかったものは同じ種類のものでした。

2つに共通していたのは、窓口が現場の全部を知っているわけではなかったこと

2つの出来事を並べてみます。

要件として現れたものデータとして現れたもの
私たちが聞いていた相手発注側の IT 部門発注側の IT 部門
何が起きたか着手後に現場の意見が集まり、要求が反転した現場の運用が、稼働後に問い合わせて初めて分かった
窓口の状態現場が何に依存しているかを把握しきれていなかったその運用を知らなかった

どちらも、隠されてはいませんでした。悪意もありません。私たちは要件を聞いていましたし、相手は答えていました。それでも、聞いた相手は現場の全部を持っているわけではなかった。

窓口が現場を代表しきれないというのは、この2件に限った話ではありません。先ほどの IPA のガイドが、ユーザ企業の中でもシステム部門と利用部門との間にギャップが生じると書いているのは、まさにこの構造を指しています2。

では、なぜ現場は言わないのでしょうか。少なくともデータの件については、その説明に使える概念があります。

科学社会学者のハリー・コリンズは、原理的には言葉にできるのに言われないままになる知識を、いくつかの型に分けています。レナ・ソレールとスヨード・ズワートによる整理では、そのひとつが mismatched saliences と呼ばれるものです。ある知識は表現できるのに、 その知識を相手に伝える必要があると本人が気づいていないために、表現されない 4。

中途半端な状態のデータを作る手順は、現場の人にとっては毎日やっていることでした。伝えるべき特別な情報として認識される機会が、そもそもなかった。そういう型に当てはまります。

要件を聞き取る技術を扱う研究分野の側からも、同じものに別の名前が付いています。顧客は持っているのに分析者（ベンダー側で要件を聞き取る担当者）には渡らず、しかも分析者はその存在に気づいてすらいない情報を unknown known と呼びます。ここで大事なのは、それが顧客にとって 「原理的には表現できる」（can in principle express） ものだと定義されている点です3。

語れないのではなく、言われていないだけ。だとすれば、「暗黙知だから仕方がない」で終わらせる必要はなく、聞き方の問題として扱えることになります。

IPA のガイドは、同じことを経営の言葉で書いています。大規模なシステムでは、開発者とユーザが業務知識を互いに補い合いながら保持している状態になることが多く、 通常、ひとりのユーザや開発者が全ての業務知識を保持することはない 。そして要員交代などで知識が断片化していくと、 業務要件上本当に必要な機能かを誰も把握していない状態 になっていく2。

私たちの見積りから抜け落ちていたのは、費用項目ではありませんでした。窓口の向こう側にあって、その窓口自身も全部は持っていなかった前提だったのです。

私たちが取りこぼしたものは、チェックリストに載っていなかった

ここまで読んで、「では見落としがちな費用項目のリストが欲しい」と思われたかもしれません。それは有効です。並行稼働している期間の二重の運用費、データ移行そのものではなく移行結果を検証する工数、使わなくなった旧システムを止めるまで維持するための保守費、切り替え直後に一時的に落ちる現場の生産性。こうした項目が見積りに入っているかを確認することには、はっきり意味があります。

ただ、項目表に載るのは、 誰かが過去に忘れて、痛い目を見た項目 です。私たちが取りこぼしたものは、私たちもクライアントも聞くべきだと思っていなかったので、まだ誰のリストにも載っていません。

IPA のガイドには、この構造がよく分かる他社の事例が載っています2。

現行システムでは、ある処理を10秒以内で完了する設計にしていました。設計書にもそう書かれています。ところが実際の運用では、時間帯によってばらつきがあり、多くの場合は1秒で終わっていました。新システムでは、現行の性能設計にもとづいて「最大10秒で完了する」という仕様とし、利用部門・運用部門・システム部門・ベンダの間で合意しました。

完成したシステムは、ピーク時を除けば5秒で動作しました。設計上の要求は満たしています。しかし現場のオペレータは、1秒で終わることを期待していました。現行システムより遅くて業務が滞る、という改善要望が寄せられ、結局その処理は作り直しになり、予定していたサービス開始も延期になりました。

この事例で怖いのは、 誰も手を抜いていない ことです。設計書はありました。合意もしていました。性能は設計どおりに出ていました。それでも外れました。設計書に書かれた10秒と、現場が体で覚えていた1秒との差は、どんなチェックリストの行にも現れません。

顧客と分析者のやりとりを分析した要求工学の研究には、こういう指摘があります。一度すれ違ったまま気づかれずに終わった情報は unknown known に変わり、 何か新しい出来事が起きなければ、それ以上顧客の口から語られることはない 3。放っておいて、そのうち向こうから出てくるという性質のものではないわけです。

同じ研究には、踏み込んだ質問が前提のズレを表に出した例も載っています。美術史を専門とする顧客が、絵画の写真は専門のアーカイブにあると話していました。分析者は、それがデジタル画像で保管されているものと思い込んだうえで、「形式は jpg ですか、tiff ですか」と尋ねます。顧客は「それは重要な情報ですか」と聞き返したうえで、こう答えました。デジタルのアーカイブなど存在しません、と3。

分析者は、正しい事実を握っていたわけではありません。 間違った前提のまま具体的に踏み込んだら、反証が返ってきた のです。

私たちの場合も、現場の運用が説明されたのは、中途半端な状態のデータについて問い合わせたときでした。待っていても出てこないのなら、こちらから何か具体的なものを持ち込んで尋ねるしかありません。

いま打てる手を、安いものから並べる

以下に挙げるのは、知識を引き出す技法として以前から知られているものです。私たちはそれを見積りの工程に持ち込めないかと考えています。その組み合わせ方については、まだ試行の段階にあります。

安いものから順に並べます。それぞれ、 誰がやることなのか と、 これでは分からないこと も一緒に書きます。ベンダーを選ぶ前に自社だけでできるものと、選定の過程でベンダーに依頼するもの、そして提案書を読むときの確認項目が混在するので、そこを明示します。

1. 理解を説明し返してもらう（選定の打ち合わせの場で、その日からできます）

提案や要件の打ち合わせの場で、ベンダーの担当者に、その担当者が理解した業務の内容を説明し返してもらいます。合っているかどうかを判定するのは発注側です。追加のコストはほぼかかりません。

知識を引き出す技法の整理によれば、これは専門家が説明し、聞き手がそれを専門家に説明し返し、専門家が確認して必要なら訂正する、という手続きとして知られています5。

効くのは、相手が「それは言う必要がない」と判断していた事柄が、聞き手の説明のズレとして表に出てくるからです。逆に、説明の場に出てこない業務 ── 他部署が持っている処理や、めったに起きない例外対応 ── は、この方法では見つかりません。

2. 現行システムに溜まっているデータを、先に眺めておく（発注側が単独でできます）

ベンダーを選ぶ前に、自社の情報システム部門か、現行システムの保守を担当している会社に頼んで進められます。現行システムのデータを、種類ごと・状態ごとに数えてみます。仕様書に載っていない状態のものが何件あるかを出す、という作業です。

これをやると「作業中のような状態のものが何件あるか」といったことは確実に見つかります。 具体的な事実が1つ手に入る ので、次の打ち合わせで具体的に尋ねることができます。

ただし、そこから意味を読み取ることはできません。データプロファイリングの技術解説は、この点をはっきり書いています。こうして見つかるものはそのデータについてしか語らず、 確実に意味的な性質を導くことはできない。したがってプロファイリングの結果には解釈が必要であり、それは通常データベースの専門家とドメインの専門家が行う 6。

つまりこれは答えを出す道具ではなく、聞くべき質問を手に入れる道具です。私たちの場合、データが質問を連れてきたのは稼働後でした。それを見積りの前に持ってこられないか、というのがこの手の趣旨です。

3. 例外・中断・やり直しに絞って洗い出す（現場とベンダーを同席させて行います）

上のデータで見つかった状態を持ち込んで、「この状態のものが何件あります。これは何ですか」から始めます。網羅は狙いません。

この進め方には Example Mapping という名前が付いています。考案者は、結果がどうあるべきかについて全員に意見を言わせるのではなく、 質問を記録して先に進む ことを勧めています。そうすることで、知らないことがあると分かる状態に変わるからです。所要時間は、小さなグループなら25分程度が目安とされています7。

なお、レガシーシステムのデータの異常を着火剤として持ち込むのは私たちの転用で、考案者がそう書いているわけではありません。

この方法で見つからないのは、誰も質問を思いつかない領域です。データという着火剤なしにこれだけをやると、すでに分かっている論点をなぞって終わります。

4. 開発者を現場に1日置き、その費用を見積りに明示的に載せる（提案依頼の条件として書きます）

これは無償の持ち出しを期待する話ではありません。提案を依頼する時点で「現場を見る時間を工程に入れて、その費用も見積りに含めてください」と条件として伝え、各社の見積書にその行があるかを比べます。本格的な現場調査ではなく、主要な業務を1つに絞って半日から1日。「何をしているか」ではなく「いま何が起きたから、それをしたのか」を聞いてもらいます。

この調査手法について、Nielsen Norman Group の解説は、熟練職人と見習いの関係を参加者と調査者の関係のモデルにしていると説明しています。現場の担当者が熟練職人で、見に行く側が見習いという関係です。所要時間は対象次第で、1〜2時間から数日までの幅があるとされています8。

分からないのは、その日に起きなかったことです。月次や年次の処理、障害が発生したときの運用は、1日ではまず観察できません。

5. 「現行どおり」の範囲を、契約と見積りの側に書き分ける（発注側が提案依頼の前に決めます）

これは発見するための手ではなく、 発見できなかったときの着地を先に決めておく ための手です。

IPA のガイドは、「現行踏襲」の内容に曖昧な部分があると、その部分をベンダ側が認識できず、 試験工程になって初めて実現できていないと判明して問題プロジェクト化するケースが多い と書いています2。

同じガイドは、検討すべき観点それぞれの末尾に「見積りに反映すべき項目」という節を置いています。現行踏襲の内容を明確にするという観点については、そこに、内容を検討するタスク、実現できるかどうかを確かめるプロトタイプ検証のタスク、決められなかったときのために意思決定のプロセスを遂行するタスクが挙がっています2。

私たちはこれを、見積りとは費用項目の表ではなく、リスク対策のタスクを映したものだ、という考え方の表れだと読んでいます。

見積りを比べるときの、もう1つの観点

ここまでの手を踏まえると、手元の3社の見積書を読むときに見られる点が1つ増えます。 分からないことを潰すためのタスクが、行として立っているかどうか です。金額の内訳ではなく、分からないまま先へ進まないための段取りに、時間とお金が割かれているかどうか。

具体的には、見積書の中に「現行業務調査」「現行システム分析」「移行データの検証」「試作による実現性の確認」といった名前の行があるかを探してみてください。名前は会社によって違いますが、 成果物を作る作業ではなく、分からないことを減らすための作業に、工数が積まれているか という点は共通して見られます。

IPA のガイドも、企画工程では不確定要素が多く、その結果として精度の低い見積りになる点が課題であると認めたうえで、工程の区切りごとに見積りを詳細化していく段階的な見積りを推奨しています2。1回で正しい金額が出るものではないという前提は、公的なガイドラインの側にもあるわけです。

冒頭の JUAS の数字は結果の分布として、このガイドは手続きの処方として、それぞれ同じ不確実さを認めているように見えます。

どう解消するかは、まだ試行錯誤している

正直に書いておきます。

大きな改修を何度か経験して、クライアントの中の「当たり前」は受託側には分からない、という教訓は得ました。ただ、それをどう解消するのかについては、まだ試行錯誤しています。

当時、実際に現場でシステムがどう使われているかを見学する、という案が出ていました。実現はしませんでしたが、いま思えば良い案でした。

いま考えているのは、業務のことを知らない人を現場に置いて、その人が引っかかったところを拾うのがよいのではないか、ということです。知らないからこそ、現場の人が説明する必要を感じていないものに引っかかる。

ただ、これを手法として言い切ることはできません。近い形の手法はすでにありますが、私たちが確認できた範囲では、そこで現場に入る「知らない人」は訓練された調査者でした。業務も調査法も知らない人をそのまま置く、という形は、いまのところ私たちの仮説の域を出ません。

発注側の立場からは、こう読み替えられるかもしれません。ベンダーが「現場を見せてほしい」「まず現行のデータを見せてほしい」と言ってきたとき、それは工程を増やして金額を上げるための口実とは限らない、ということです。分からないことを先に潰そうとしている、という読み方もできます。

まとめ — 見積りを比べる前に、自社の「当たり前」を疑う

3点にまとめます。

1つめ。システム開発全般を対象にした調査で、予算が予定どおりにならなかったと答えた企業の 45.9% が、その理由に「想定以上の現行業務・システムの複雑さ」を挙げていました。私たちの案件で抜けていたのも、費用項目ではなく前提でした。

2つめ。私たちは要件を聞いていました。ただ、聞いた相手が現場の全部を知っているわけではなかった。その前提が表に出たのは、私たちの場合、稼働後にデータについて問い合わせたときでした。

3つめ。打てる手はあります。ただしどれも万能ではありませんし、見積りの工程に組み込む形を私たちが実証できているわけでもありません。それでも、見積りの側に「分からないことを潰す時間」が計上されているかどうかは、今日から見られる一点だと考えています。

最後に、ひとつ問いを置かせてください。

自社の中で「これは言わなくても分かるはず」と思っていることは、何でしょうか。 そしてそれは、ベンダーとの窓口に立つ人が把握していることでしょうか。1つでも書き出せたら、手元の見積りの読み方は変わるはずです。

手元に複数社の見積りがあって、金額差の意味が判断できないときは、コンタクトフォームからご相談ください。見積りの妥当性を評価するところから、一緒に見ます。

Footnotes

  1. 企業IT動向調査報告書2025 ユーザー企業のIT投資・活用の最新動向（2024年度調査） 一般社団法人 日本情報システム・ユーザー協会、2025年3月31日。予算遵守状況は図表8-1-2（p.193）、要因は図表8-1-7（p.196、複数回答）。調査対象は東証上場企業とその子会社等、有効回答981社。 ↩ ↩2

  2. システム再構築を成功に導くユーザガイド 第2版 ～ユーザとベンダで共有する再構築のリスクと対策～ 独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター監修、2018年2月23日 2版1刷。認識齟齬は p.90、システム部門と利用部門のギャップは p.86、業務知識の分散は pp.12-13、性能をめぐる事例は p.17、現行踏襲の曖昧さと「見積りに反映すべき項目」は p.86・p.91、段階的な見積りは p.122。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  3. Ambiguity and tacit knowledge in requirements elicitation interviews Alessio Ferrari, Paola Spoletini, Stefania Gnesi、Requirements Engineering vol.21, no.3, pp.333–355, 2016（リンクは著者最終稿）。unknown known の定義と写真アーカイブの例は Sect. 5.1、仲介者の体制についての記述は Sect. 2.2。 ↩ ↩2 ↩3 ↩4

  4. Collins’s Taxonomy of Tacit Knowledge: Critical Analyses and Possible Extensions Léna Soler, Sjoerd D. Zwart、Philosophia Scientiæ 17-3、2013年、107–134頁。mismatched saliences の説明は第11段落。同論文はコリンズの分類を批判的に検討したものです。 ↩

  5. Knowledge Elicitation: Methods, Tools and Techniques Nigel Shadbolt, Paul Smart、Evaluation of Human Work (4th ed.) 所収、2015年、p.7。 ↩

  6. Data Profiling: A Tutorial Ziawasch Abedjan, Lukasz Golab, Felix Naumann、SIGMOD 2017。 ↩

  7. Introducing Example Mapping Matt Wynne、2015年12月8日。 ↩

  8. Contextual Inquiry: Inspire Design by Observing and Interviewing Users in Their Context Kim Flaherty、Nielsen Norman Group、2020年12月6日。 ↩