top of page

既存システムの改修作業を外注する際に開発だけ考えて失敗

更新日:2022年5月27日

WEB系、業務システム系どちらでも起こり得ますがシステム上のバグなどではなく、作業内容の洗い出しが不完全なために発生する失敗なので、未然に防ぐことは可能です。



【失敗例】既存データの修正作業や再アップなど開発以外の作業工程を見過ごしてしまった

同業他社の吸収合併が無事に成功したため、両社がそれぞれに持っていた商材管理システムを統一することになりました。


幸いにも買収した会社が弊社でしたのでこちらのシステムに統一することとなり、仕様を一から把握する必要がありませんでした。


商品説明や費目が両社共ほぼ同じであることから、開発工数が少ないであろうとの判断がでました。


そこで取引先システム会社を増やす意図もあり、新しいシステム開発会社に外注することが決定されました。


担当者は私と新人の2名ですが開発自体に携わるプロジェクトメンバーは上長を含め合計5名となります。


これまで新規のシステム開発会社に発注した経験を持つのは上長1人だけでしたので、上長と私、新人の3名で開発要件を取りまとめました。


要件が確定し、開発コストの想定も出来上がったため、開発会社選定が始まりました。


一括見積サイトのいくつかに登録し、見積もりに必要であると判断された最低限の案件情報を掲載し、開発会社の選定がスタートしました。


10日ほどで、10を超える開発会社からのオファーが届き、暫定見積もりをが出そろったので開発コストと見合う可能性があると判断できた企業とNDA(秘密保持契約書)を取り交わし要件定義を開示し、打ち合わせを重ね詳細な見積もりをいただきました。


最終的に2社に絞られたのでコストが安いA社に発注を依頼し開発が本格的にスタートしました。


いくつかのトラブルはあったのですが仕様を大きく変更する必要もなく、無事に結合テストまで進みました。


弊社で作成したテストデータで問題がありませんでしたので、本番環境に移行するにあたり既存のデータの入れ込み作業をお願いしたところで予期せぬ問題が発生しました。


改修作業では既存のデータに対して修正が必要なため構築仕様は取り決めていたのですが既存データに関する修正作業の発注が抜けていることが分かったのです。


上長に相談をしたところ追加予算にて対応することにして見積もりを取るように指示されました。


そこでA社に追加見積依頼を出すと、弊社の想定を超える見積もりが出てしまいました。弊社で想定していた金額の約6倍です。


費用の内訳について確認したところ既存データのボリュームが多いこと、商品説明用の画像修正にかかる工数が費用高騰の原因でした。


追加予算は経営者決済を通すことが出来なかったため、最終的にデータ修正の作業マニュアル作成費とし、弊社でデータ修正作業を行うことで予算内に収めることになりました。


1日レクチャーとマニュアルに沿ってデータの修正作業に取り掛かりましたが、思ったよりもプロジェクト内人員のリソースを取られることになり、他の作業に影響が出始めてしまったため、システム開発会社に再度データの修正作業を依頼することになりました。


結果として開発費がかなり高くなってしまい社内では失敗開発と言われてしまいました。


【失敗の理由】システム改修で忘れてはいけないこと

実はこの失敗例ですが既存システムの改修作業ではわりとよくある出来事だといえます。


「開発=機能を作る」と思ってしまうことで発生するトラブルです。


大事なことは「システムが問題なく稼働する」ことです。


今回のケースでは、機能構築が完了した段階では開発完了にはなりません。既存のシステムのバージョンアップが完了し、それまでのように使えることが確認できた時点が開発完了です。


今回の失敗例で忘れてはいけない点をいくつか挙げておきます。


・全体を考えてどうなればよいのか?を見極める

・発注者の目線でのみ考えない

・業者選定方法の見直し


全体を考えてどうなればよいのか?を見極める

既存データの修正作業が発生することがわかっているのであれば、発注前にこの点を見逃してしまうのは避けたいものです。


恐らくは最初の打ち合わせではデータの入れ込みについて、しっかりと話し合われていたのに要件定義や基本設計など落とし込み作業が始まると目の前の工程に目がいってしまい、依頼が抜けてしまったのではないかと思われます。


システム開発の外注に慣れていない発注者さんの場合、起こり得ることです。


既存システムをバージョンアップする場合は常に、


開発完了後も当たり前のように使える


ことを念頭に作業工程を洗い出すことが大切です。


発注者の目線のみで考えない

発注者と受注者で作業に関する予算感が合わないのも、あるあるです。特に発注者の担当者さんがエンジニア経験がない場合などに起こりがちです。


これについては発注者、受注者の目線で書いてみました。


発注者目線

これまでに私が経験してきたことや周りの担当者の意見から洗い出してみました。


・既存データの項目を3つ追加するだけだから簡単な作業だろう

・修正はプログラムで簡単にできることだろうから工数はかからないだろう

・修正作業だから開発に比べれば楽な作業だろう

・最悪、自分たちでもできるレベルの作業だろう


気を付けなければならないのは、すべて憶測で動いてしまっているということです。


仕様を完全に理解している上での予測ではなく、あくまでも肌感覚で考えてみて簡単だろうと思ってしまうと、追加予算の想定も低くなってしまいます。


特にデータの入れ込み作業などは「誰にでもできる作業」として軽く見てしまう傾向があるため思わぬ落とし穴にはまってしまいます。


例えば、今回のケースでいうとバラバラの画像のリサイズに関して縦横幅を強制的に合わせれば画角がおかしくなってしまい昔のフリー掲示板にアップされている画像のようなものになってしまいます。


また、バラバラの画像をアップすることを最初から想定していなければ、開発半ばで縦横幅をフリー設定に変更すると商品ページの全体構成が崩れる可能性があります。


こうした問題を避けるため、画角が異なる画像をリサイズしてもきれいに見えるようにするため、新しく画像リサイズプログラムを作る必要があるかもしれません。


また、画像リサイズプログラムではなく修正を人的に行おうとすれば、要員を確保しなければなりません。単純作業だとしてもエンジニアが行うのであれば工数はエンジニア価格での計算となりますから必然的にコストは高くなります。


簡単な作業だからと言ってシステム開発会社がそのためだけにアルバイトを雇うことはありませんし、NDAを結んでいないフリーランスに画像加工作業を依頼することはできません。


結果として作業は自社内で完結する必要が出てきます。

システム開発会社はほとんどがエンジニアですから、単純作業でも動かせば工数は高くなります。


受注側目線

開発を請け負っている開発会社目線で書き出します。


・データ修正作業について調査、分析の時間が必要である

・バラバラの画像をリサイズするためのプログラム構築が必要である、人的作業にするならばエンジニアのリソースを確保しなければならない


新しい作業は既存の作業の延長線上にあるとは限りません。

特に、データ加工修正や入れ込み作業というのは開発とは別の作業の位置づけになる場合があります。


つまり、仕事としては改修作業とデータ加工作業と2つに分類されてしまうことがあります。


最初からデータ修正作業を組み込んでおけばより正確に開発予算と見比べることが出来ますが今回の失敗例では、作業内容の洗い出しが不完全であった結果、追加予算になってしまっています。


概算見積もりの正確性が怪しくなってしまいます。


業者選定方法の見直し

今回の件ですが、相見積もりで業者選定を行っています。


選定段階で失敗する確率を下げることが出来るテクニックがあります。


まず、システム開発会社で同様のケースを手掛けている場合、改修作業に伴いデータの修正作業を見越しています。


発注者が提供した案件詳細にそのことが記載されていなければ指摘してくれる開発会社もたくさんあります。


また、概算見積もり内にそのことを記載している場合もあります。


概算見積もりは「タタキ」くらいの感覚で見るのではなく、費目などによく目を通すことが大切です。


もしかすると今回の件では、選考漏れしている概算見積もりの中にデータ修正作業を考慮している開発会社があったのかもしれません。


業者の選定は見積もりの作り方からスタートしていると考えることで、失敗開発を回避することが出来ます。


特に、業務システムなどは手掛けた案件数がノウハウとなり要件定義で抜けている点が見えやすい開発です。


また、概算見積もりが出た時点で精査するのではなく、概算見積もりの根拠などを洗い出すため可能な限り、オンライン打ち合わせなどで見積もり根拠を探ることで精度の高い選定を行うことが出来ます。


選定基準をあらかじめ決めるのであれば事前に業者選定にあたりリストを書き出しておくと良いでしょう。


ただし、リストを作る場合はその項目をできるだけ細分化しておかないと打ち合わせ内容が各社ごとにバラバラになってしまうため意味を持たなくなってしまいます。


ちなみに弊社では

比較的工数の少ない改修案件を多数手がけてきたため、改修で気を付けなければならない箇所などをリスト化してまとめています。


要件定義などで漏れがあると思えた場合は打ち合わせなどでその点を指摘するようにしています。


言葉に発して確認をすることで漏れを見つけることを重視しています。


今回の件で言えば、


「既存データを入れ込むところまでが弊社作業ですか?」

「画像のリサイズは発注者側でおこなうのですか?」

「データの文字列修正は弊社で画像の修正は御社ですか?」

「画像リサイズプログラムは構築しますか?」


など、あらかじめ想定されることについては質問として挙げておき、事前確認作業を細かく行うようにしています。


仕事に限らず、事後報告は時としてトラブルの原因になりますし、何より心象が悪くなってしまいます。


弊社で大切にしていることの1つを最後に書いておきます。


【言われなかったからやりませんでした、は仕事として不義理である。】

bottom of page