多くの失敗は、技術ではなく「決めていなかったこと」から生まれます。
1. 目的が共有されていない
「業務を効率化したい」だけでは、何を作るべきか決まりません。関係者の間で目的の理解がずれたまま進むと、完成後に「思っていたものと違う」が起きます。
- 目的を一文で書き、関係者全員が同じ文を言えるか確認する
- 「成功した状態」を具体的な業務の変化で表現する
2. 現場の担当者が関わっていない
決裁者だけで要件を決めると、実際に使う人の手順と合わないものができます。
- 実際に毎日使う人に、一度は画面案を見てもらう
- 現場の「例外処理」を早い段階で聞き出す
3. 機能を盛り込みすぎる
「せっかくだから」で機能を足すと、費用も期間も膨らみ、使い方も複雑になります。
- 必須と任意を分け、任意は次の段階に回す
- 使用頻度の低い機能は、人の手で行う運用も検討する
4. 前提条件を確認していない
見積りには必ず前提があります。前提が崩れると追加費用になります。
- 見積書の「前提条件」「除外事項」を必ず読む
- 連携先システムの仕様を、早い段階で確認する
5. データの扱いを後回しにする
既存データの移行は、想定より手間がかかることが多い作業です。表記ゆれや欠損の整理に時間がかかります。
- 移行するデータの実物を早めに渡す
- 移行しないデータの扱いを決めておく
6. テストの時間を取っていない
検収期間が短いと、不具合を見つけられないまま公開することになります。
- 検収の期間と担当者をスケジュールに明記する
- 確認する観点を事前にリスト化する
7. 仕様変更のルールがない
「ちょっとした変更」の積み重ねが、納期と費用を圧迫します。
- 変更の申請方法と、費用・納期への反映方法を契約時に決める
- 変更の記録を残す
8. 運用担当者を決めていない
公開後、誰も面倒を見ない状態になると、使われないまま放置されます。
- 更新を担当する人を決める
- マニュアルの要否と、作成担当を決める
9. 保守を契約していない
納品後にサーバーやソフトウェアの更新が止まると、時間の経過とともに動かなくなります。
- 保守に含まれる作業の範囲を確認する
- 障害時の連絡方法と対応時間を確認する
10. 引き継ぎの準備がない
担当会社を変える可能性を考えて、最低限の資料を手元に残します。
- ソースコードの所在と、その権利の扱い
- サーバー・ドメイン・各種サービスの管理情報
- 設計資料と運用手順
関連する開発ガイド
- Webシステム開発でよくある失敗10選と回避策Webシステム開発で中小企業が陥りやすい10の失敗を、要件・契約と費用・進め方・運用の4つの場面に分けて想定例とともに紹介し、発注側が事前にできる回避策を解説します。
- 検収（受け入れテスト）で確認すべきことWebシステムの検収で発注側が確認すべきことを、検収条件の確認、テスト項目の作成、ステージングでの実施、不具合の記録と切り分け、検収書の作成の手順で解説し、契約不適合責任との関係も整理します。
- 他社が作ったシステムの引き継ぎ・保守を依頼するときのチェックリスト前の開発会社が作ったシステムの保守を別の会社に引き継ぐときの手順を、資料・アカウント・ソースコード・環境の棚卸しから調査、リスク整理、保守範囲の合意、移行まで、確認項目の表とともに解説します。
関連するサービス
監修: Unlogical Systems合同会社（杉並区・西荻窪）公開