引き継ぎの見積もりが甘くなるのはどんなときか｜調査を省いて難航した実例

他社が作ったシステムの引き継ぎは、やり切ったあとに得られるものがある一方で、途中で思うように進まない案件もあります。この記事では、古いフレームワークで作られたサービスを引き継いだ案件で、見積もりが甘くなり難航したときに何が起きたかを、実際の経験として書きます。うまくいった話ではなく、苦しんだ側の話です。

引き継ぎの見積もりが甘くなるのはどんなときか

引き継ぎの見積もりが甘くなるとは、システムの中身を調べきる前に総額を決めてしまうことです。実際に難航した案件は、まさにこの形でした。

中身を説明できる人が誰もいない状態だった

引き継いだのは、古いフレームワークで開発されたサービスでした。作った当時の担当者はすでにおらず、発注側にも開発側にも詳細を知っている人が誰もいない状態です。ドキュメントから読み取れることには限りがあり、実際に何がどう動いているかは、コードとサーバーを見て確かめるしかありませんでした。

この状態で総額を出すと、見積もりは「調べれば分かること」ではなく「たぶんこのくらいだろう」という見通しの上に乗ります。見通しは、当たることもあれば外れることもあります。外れたときに差を吸収するのは、多くの場合、開発会社の工数です。

本来は調査を別の見積もりにすべきだった

本来であれば、まず調査に時間を割き、その結果を見てから開発の見積もりを出すべき案件でした。実際にはそうしていません。調査だけで費用が発生することに顧客側が難色を示したため、ある程度の見通しで進める形になりました。

結果として、進めていく中でさまざまな問題が出てきました。何が出てくるか分からないから調査が必要だったわけで、調査を省いた以上、想定外が出るのは順番として当然のことです。ここは開発会社側にも反省があります。調査が必要だと判断していたのなら、費用の話になる前に、調査を挟まない場合に何が起こりうるかをもっと具体的に伝えるべきでした。

難航する前に出ていた兆候

あとから振り返ると、難航する兆候は着手前の時点で見えていました。引き継ぎを検討している発注側にも、同じ見方ができます。

フレームワークやライブラリが更新されず、パッチワークが積み重なっている

最も分かりやすい兆候は、フレームワークやライブラリが更新されないまま、その場しのぎの修正が積み重なっている状態です。パッチワークとは、根本原因に手を入れず、表面に出た不具合だけを個別に塞いでいく直し方を指します。

この状態のシステムは、一箇所を直したときに何が連動して壊れるかが読めません。読めないということは、影響範囲を確かめる作業が要るということで、その作業量は事前の調査でしか見積もれません。引き継ぎ調査で何を見ているかという話は、突き詰めればこの「読めなさ」がどれくらいあるかを測ることです。

増員できないまま、スケジュールだけが伸びていく

問題が出てきたあと、体制をどう立て直したかというと、実際には増員はできませんでした。予算が先に決まっている案件では、人を足すとその分だけ赤字が深くなるためです。

増員できない案件で調整できるのは期間だけなので、スケジュールが大幅に伸びる形になりました。これは体制の立て直しに失敗したというより、予算が固定されている以上そこにしか逃げ場がない、という構造の問題です。

調査費に難色を示されたとき、実際には何が起きるか

発注側から見ると、調査費は「まだ何も作っていない段階で出ていくお金」に見えます。総額を抑えたい場面で削りたくなるのは自然なことです。ただ、削って消えるのは費目であって、不確実性そのものではありません。

不確実性は、どこかで必ず誰かが負担する

調査を省いた場合、開発会社の出方は二つに分かれます。想定外を織り込んで高めに見積もるか、見通しで安く見積もって差を自社で吸収するかです。前者なら発注側は高い金額を提示され、後者なら金額は収まる代わりに、進行中に納期が伸びるリスクを負います。

• 調査を挟む場合：調査費は増えるが、その後の見積もりの精度が上がる
• 調査を省いて高く見積もる場合：総額が上がる
• 調査を省いて見通しで進める場合：総額は収まるが、期間が伸びる可能性が残る

どの道を通っても、分からない部分のぶんは誰かが持ちます。調査費は追加の出費というより、その負担を最初に、金額が確定した形で引き受ける方法だと考えると判断しやすくなります。

調査を挟むと、発注側は途中で降りる選択肢を持てる

調査を先に切り分けるもう一つの利点は、調査の結果を見てから開発に進むかどうかを決められることです。調べた結果、想定より状態が悪ければ、その時点で作り直しに切り替えることも、いったん見送ることもできます。開発まで一括で契約していると、この判断が途中でできません。

調査に必要な材料は、発注側にあるものだけでも構いません。引き継ぎで用意する資料のように、手元に何が残っているかを整理するところから始められます。ソースコードが残っていない場合でも、調べられる範囲と調べられない範囲を先に切り分けておくことに意味があります。

顧客との関係と、開発会社側に残るもの

この案件について、顧客との関係が悪くなったわけではありません。スケジュールが伸びたことについても、事情を共有しながら進められています。関係が壊れる形の失敗ではありませんでした。

ただ、開発会社としては難しさが残ります。追加の予算が見込めない中で伸びた分の工数は、そのまま自社の負担になるためです。関係が良好であることと、案件として成立していることは別の話で、この状態が続くと次の提案がしづらくなります。

他社の安い見積もりから、戻ってきた案件

ここまでは、FUNBREW自身が調査を省いて難航した話でした。逆の立場の実例もあります。相見積もりで一度は他社に決まったあと、FUNBREWに戻ってきた引き継ぎ案件です。

都合の良い提案が、その費用では実現できなかった

システムの引き継ぎと、そこからの追加開発の案件でした。お客様は、競合他社の提案を魅力的に感じて、そちらに依頼されました。その会社は、お客様にとって都合の良いことを多く伝えていたようです。ところが進めてみると、その費用の範囲では実現できないことが分かりました。

見積もりの裏側で起きていたこと

あとから分かったのは、次の2点です。

• エンジニアにほとんど調査を依頼しないまま、見積もりを作っていた
• 他社の見積もりに金額を当てて、通常よりかなり安くしていた

引き継ぎで調査を省くと何が起きるかは、この記事の前半に書いたとおりです。そこに他社の金額への合わせ込みが重なると、根拠の薄い金額がさらに下に引っ張られます。発注側から見ると、いちばん安く、いちばん都合の良い提案に見えるのは自然なことです。値下げの先で何が起きるかは値下げを受け入れた開発会社に何が起きたかにも書いています。

失注の理由は、ふだんは分からない

付け加えると、相見積もりで負けたこと自体は分かっても、負けた理由まで分かることはほとんどありません。この案件で理由が分かったのは、お客様が戻ってきてくださったからです。引き継ぎの見積もりを比べるときは、金額の大小より先に、その金額がエンジニアの調査に基づいているかを確かめてください。

これから引き継ぎを相談する場合にできること

発注側として、着手前にできることは多くありません。ただ、次の三つは相談の初期段階でも確認できます。

• そのシステムの中身を説明できる人が、社内か開発元に残っているか
• フレームワークやライブラリの更新が止まっていないか、その場しのぎの修正が積み重なっていないか
• 調査を開発と切り離して見積もってもらえるか、切り離せない場合は何が根拠で総額が出ているか

三つ目が特に重要です。調査を切り離せない事情がある場合でも、金額の根拠が「調べた結果」なのか「見通し」なのかを聞いておくと、途中で伸びる可能性がどれくらいあるかを事前に共有できます。FUNBREWでも、引き継ぎのご相談ではまず現状の調査からご提案しています。お問い合わせの段階で、手元にある資料と、中身を説明できる人がいるかどうかを教えていただければ、進め方の見立てをお伝えできます。