Webシステム開発でよくある失敗10選と回避策

Webシステムの開発は、多くの中小企業にとってそう何度も経験するものではありません。慣れていないのが当然で、同じような失敗が繰り返されるのも無理はありません。裏を返せば、典型的な失敗はある程度パターン化されており、事前に知っておくだけで避けられるものが多いということです。この記事では、よくある失敗を要件、契約・費用、進め方、運用の四つの場面に分け、それぞれの回避策を整理します。挙げている場面はいずれも想定例です。

要件の失敗

最初のつまずきは、作るものを決める段階で起きます。ここでの判断が後の工程すべてに影響するため、手戻りの費用も大きくなります。

1. 「今の業務をそのままシステムにする」と決めてしまう

想定例：紙の伝票と表計算ソフトで回している受注業務を、そのままの手順で画面にした。結果、紙では気にならなかった転記や二重入力がシステム上でも残り、入力の手間だけが増えた。

回避策は、要件定義（作るものと目的を決める工程）の前に業務の流れを書き出し、「システム化で何をなくしたいか」を先に決めることです。手順の一部は、システム化を機に見直した方がよい場合があります。業務効率化システム開発の相談でも、最初に確認するのはこの点です。

2. 要望を並べただけで優先順位がない

想定例：各部署から集めた要望をすべて盛り込んだ。開発が長引き、費用も膨らんだうえ、いざ使い始めると使われない機能が多かった。

「なくては業務が回らないもの」「あると助かるもの」「将来検討するもの」の三段階に分け、最初の開発では一段階目に絞ります。残りは使い始めてから、実際の必要性を見て追加する方が結果的に無駄が少なくなります。

3. 使う人の意見を聞いていない

想定例：経営者と総務担当者だけで仕様を決めた。現場の担当者が実際に使う場面では、入力順が業務と合わず、結局元の表計算ソフトに戻ってしまった。

要件定義の段階で、実際に操作する人に画面案を見せ、業務の言葉で説明してもらう時間を取ります。全員の意見を反映する必要はありませんが、主要な利用者が一度も見ていない仕様は避けるべきです。

契約・費用の失敗

金額だけを見て契約すると、「どこまでやってもらえるのか」が曖昧なまま進みます。範囲と責任の所在を書面で確かめておくことが、後のトラブルを防ぎます。

4. 見積書の範囲を確認せずに発注する

想定例：金額だけを比べて安い会社に決めたところ、データ移行やスマートフォン対応、公開後のサポートが含まれておらず、追加費用が積み上がった。

見積書は金額ではなく、「何が含まれ、何が含まれないか」を読みます。人月（技術者一人あたりの月単位の作業量）で書かれている場合は、その作業量にどの作業が入っているかを確認します。詳しくは見積書の読み方も参考にしてください。

5. 契約形態と責任の範囲を理解していない

想定例：完成責任があると思って発注したが、契約は準委任契約（作業に対して対価を払う契約）で、期日までに完成しなくても追加費用が必要だった。

請負契約は完成に、準委任契約は作業に対価を払う契約です。どちらが悪いわけではなく、要件が固まっている部分は請負、探りながら進める部分は準委任、と使い分けるのが実務的です。契約書には成果物、検収（納品物を確認して受け入れを認める手続き）の条件、契約不適合責任（納品物が契約内容に合わない場合の責任）の期間が書かれているかを確認してください。

進め方の失敗

開発が始まると発注側は待つだけになりがちですが、途中の関与の仕方で結果は大きく変わります。任せきりにしないための工夫を挙げます。

6. 途中の確認をせず、完成まで待ってしまう

想定例：要件定義の後は開発会社に任せきりにし、納品時に初めて画面を見た。想像していたものと違い、大幅な手戻りが発生した。

基本設計・詳細設計（画面や処理の仕様を決める工程）の段階で画面案を確認し、開発中も動くものを区切りごとに見せてもらう進め方を最初に取り決めます。確認の回数は多少手間でも、完成後の作り直しに比べれば負担は小さいものです。

7. 決める人が決まっていない

想定例：開発会社からの質問に対し、社内で誰が答えるのかが曖昧で、返答に時間がかかった。開発が止まり、結果として期日が後ろにずれた。

発注側の窓口と、仕様を決める権限を持つ人を一人ずつ決めておきます。兼任でも構いませんが、質問への返答期限を社内で決めておくと、開発の停滞を防げます。

8. 検収を「動いたから合格」で済ませる

想定例：納品時に主要な画面だけ操作して検収した。公開後に月末の集計機能が想定と違うことが判明し、修正が有償か無償かで揉めた。

検収は、合意した仕様と納品物を照合する作業です。業務の流れに沿ったテスト項目を用意し、ステージング（本番と同じ構成の確認環境）で実際の担当者が確認します。詳しい手順は検収で確認すべきことにまとめています。

運用の失敗

システムは公開してからのほうが長く付き合うものです。公開を目前にして決め忘れがちな、運用に関する取り決めを整理します。

9. 公開後の保守を決めていない

想定例：公開後は自社で何とかするつもりだったが、サーバーの更新やセキュリティ対応の方法が分からず、そのまま放置していた。ある日サイトが表示されなくなり、対応先もなかった。

公開はゴールではなく運用の始まりです。保守（公開後の維持管理）の範囲（監視、バックアップ、更新、問い合わせ対応）と担当を、開発の契約と同時に決めておきます。自社で担えない部分はシステム保守・運用サポートのような外部の支援を検討してください。

10. 資料とアカウントを自社で持っていない

想定例：開発会社の担当者が退職し、連絡が取れなくなった。ドメインとサーバーの契約が開発会社名義で、ソースコードも設計書も手元になく、別の会社に頼むこともできなかった。

納品物にソースコード、設計書、アカウント情報を含めることを契約時に明記し、ドメインとサーバーは自社名義で契約します。引き継ぎが必要になった場合の手順は引き継ぎのチェックリストを参照してください。

失敗の多くは、決めないまま進めたこと

10の失敗を振り返ると、共通するのは「決めるべきことを決めないまま進めた」という点です。何をなくしたいかを決め、優先順位をつけ、契約の範囲と責任を理解し、途中で確認し、検収を丁寧に行い、運用と資料の所在を最初から決めておく。どれも特別な技術は要りません。回避策をチェックリストとして手元に置き、開発会社との打ち合わせで一つずつ確認してみてください。進め方に不安がある場合はお問い合わせからご相談いただけます。

一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。