開発期間の考え方

開発期間は、次の4つの掛け合わせで決まります。

このうち弊社が直接コントロールできるのは作業の範囲と確認の頻度です。決めごとの速さと公開の条件はお客様側の事情によるため、ご相談の初期に「社内の窓口と決定権者」「返答にかけられる日数」「避けたい時期」を伺っています。

開発の流れで示している工程のうち、期間の大部分を占めるのは設計・開発・検収の3つです。おおまかな比重は次のとおりです（実際の配分は案件により変わります）。

「開発」が最も長い工程ですが、期間が想定より延びる原因の多くは、開発そのものではなく設計と検収での確認待ちです。設計段階で実際に使う方に画面案を見ていただき、検収の時間をあらかじめ確保していただくことが、期間を守るうえで最も効きます。

過去の経験から、期間が延びる原因は次のパターンに集約されます。いずれも事前の取り決めで防げるものです。

1. 決める人が決まっていない: 画面案を見た担当者が「上に確認します」となり、返答に時間がかかる。着手前に決定権者と返答期限を決めておきます。
2. 要望が途中で増える: 開発中に「ついでにこれも」が積み重なる。初回開発の範囲を要件定義で固め、追加分は次の段階に回します。
3. 検収の時間が取れない: 完成しても、繁忙期で実際に使う方が確認できない。検収の時期と担当者を契約時に決めておきます。
4. 移行データの整理に手間取る: Excelや旧システムのデータに重複や表記ゆれが多く、移行に想定以上の作業が必要になる。設計段階で実データを見せていただき、移行方針を先に決めます。
5. 外部の手続き待ち: ドメイン移管、決済代行の審査、外部APIの利用申請などは弊社側で短縮できない。必要な手続きを早い段階で洗い出し、並行して進めます。

詳しくはWebシステム開発でよくある失敗10選と回避策もご覧ください。

期間を短くする最も確実な方法は、初回に作る範囲を絞ることです。弊社では見積りの段階で作業項目を「必須」「あると便利」「今回は見送り」に仕分けし、必須だけで動く構成を先に公開する進め方をご提案しています。

• 段階的に公開する: 最も困っている業務から先にシステム化し、使いながら次の範囲を決めます。全部を一度に作るより、最初の効果が出るまでの期間が短くなります
• 既製サービスと組み合わせる: 決済、メール配信、予約など、既製サービスで足りる部分は開発せずに連携します
• 確認の頻度を上げる: 動くものを早い段階から見ていただくことで、完成後の大きな手戻りを防ぎます
• AIを開発工程に活用する: 弊社は生成AIを設計・実装・テストの各工程で積極的に使い、同じ品質でかかる時間を短くしています。詳しくはAI開発をご覧ください

一方で、期間だけを優先して設計や検収を省くと、公開後の不具合対応で結局長くかかります。短くできる部分と、省いてはいけない部分を分けてご提案します。

「いつまでに公開したいか」が決まっている場合は、そこから逆算して着手時期をご提案します。公開日の直前に検収が重なると確認が不十分になりやすいため、検収と公開の間に余裕を見ます。

公開日が決まっていない場合も、避けたい時期（決算期、繁忙期、担当者の異動時期）を伺い、検収や公開がそこに重ならないよう工程を組みます。お見積りには、作業項目ごとの工数とあわせて工程表をお付けします。