小規模Webアプリの開発期間はどれくらい？短期間で作れる範囲と前提条件

まず確認したい「いつから数えるか」

開発期間の話でずれが生まれやすいのが、起点の違いです。同じ「2週間」でも、何を起点にしているかで意味がまったく変わります。

開発会社が示す期間は、3つ目の「要件確定後」を起点にしていることが多くあります。使い始めたい日から逆算する場合は、その前後の期間も含めて考える必要があります。

「初回納品」と「本番公開」は違う

もう一つ確認したいのが、何をもって「完成」とするかです。小規模な開発では、次のような段階を踏むのが一般的です。

「何日で納品」という数字だけを見て公開日を決めてしまうと、確認と修正の期間が足りなくなることがあります。

開発期間を左右する要素

画面数と機能の複雑さ

画面の数が多いほど、また検索・集計・承認・通知などの機能が複雑なほど、作業量は増えます。費用と同じく、期間も作業量に比例します。

外部サービスとの連携

連携先の仕様の調査や、連携先側の設定・申請が必要な場合、開発会社だけでは進められない待ち時間が発生することがあります。

要件がどこまで決まっているか

期間に最も大きく影響するのがこの点です。要件が曖昧なまま始めると、開発の途中で判断を仰ぐ場面が増え、そのたびに作業が止まります。

発注者側の確認のスピード

見落とされがちですが、発注者の確認やフィードバックにかかる時間も期間の一部です。確認の担当者が忙しく、返答に数日かかる状態が続くと、全体の期間は延びていきます。

短期間で形にするために発注者ができること

• 最初の版の範囲を、期日までに必要な機能だけに絞る
• 要件メモを用意し、判断材料をまとめて渡す
• 仕様の最終判断をする人と、確認する人を決めておく
• 初回納品の確認日を、あらかじめ予定に入れておく
• フィードバックは、気づいた順ではなくまとめて伝える

特に最後の点は効果的です。修正点を少しずつ何度も伝えるより、確認したうえでまとめて伝えるほうが、修正の手戻りが少なく済みます。発注者の関わり方については、開発を依頼したあと発注者がやることで詳しく解説しています。

公開日が決まっている場合の考え方

イベントや年度の切り替えなど、公開日が動かせない場合は、日付から逆算して範囲を決めるのが現実的です。

1. 公開日を確認する：動かせない日付と、その理由を共有する
2. 公開前の準備期間を確保する：社内への周知、データの登録、操作の練習など
3. 確認・修正の期間を確保する：初回納品から公開までの余裕を見込む
4. 残りの期間で作れる範囲を決める：期日までに必要な機能を優先し、それ以外は公開後に追加する

期日に間に合わせるために範囲を削ることは、失敗ではありません。最初の版で業務を回し、公開後に機能を足していく進め方は、小規模な開発ではよく選ばれる方法です。

期間が延びやすいパターン

小規模な開発でも、次のようなことが起きると、当初の見込みより期間が延びやすくなります。事前に知っておくと、計画の段階で余裕を持たせられます。

相談のときに伝えておきたいこと

期間の見通しを立てるために、相談の段階で次のことを伝えておくと、より現実的な計画を提案してもらえます。

• 使い始めたい日と、その日付の理由
• その日までに必要な機能と、後からでもよい機能
• 社内の確認や承認にかかる期間
• 繁忙期など、確認の時間を取りにくい時期
• 連携が必要な外部サービスや既存の仕組み

特に「その日付の理由」は大切です。理由が分かれば、期日までに何が本当に必要なのかを一緒に考えられます。

期間を短くすることだけを目的にしない

開発期間は短いほうがよいように思えますが、確認や修正の時間を削って急ぐと、公開後の手戻りが増えることがあります。期日までに必要な範囲を見極め、その範囲を確実に仕上げることを優先しましょう。

期間の見通しは、要件がどこまで決まっているかで大きく変わります。要件の決め方は小規模開発の要件定義はどこまで必要？で解説しています。

Tailboneの納期の考え方

Tailboneでは、要件が明確な場合、シンプルなWebアプリであれば最短7日以内、複数画面の構成や内容量の多いWebアプリであれば14日以内を目安に初回納品を目指します。いずれも、画面・機能・範囲などの要件が確定し、制作を開始した日から数えた目安です。

初回納品は、実際に触って確認できる状態のWebアプリです。ご確認と修正を経て、本番公開に進みます。画面数、機能の複雑さ、外部サービスとの連携、ご確認のタイミングなどによって変わるため、完成の日付をお約束するものではありません。詳しくはトップページの納期の目安もご覧ください。