開発期間の考え方

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

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

決めごとの速さは、着手前に整理しておくほど効きます。関係者と決裁の地図で誰が何を決めるかを1枚にし、フェーズごとの意思決定リストで各段階の判断を先に割り当てておくと、「確認します」で止まる日数が減ります。

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

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

検収に何日を見込めばよいか分からない場合は、検収テストの項目シートの9分野をご覧ください。確かめる項目の数が見えると、必要な日数と担当者を先に押さえられます。着手前に揃えておくものはキックオフ前の確認事項にまとめています。

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

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

進み具合のずれに早く気づく仕組みとしては、週次デモの確認シートの観点で毎週動くものを見ていただく形をおすすめしています。詳しくはアジャイルと契約の関係もご覧ください。

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

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

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

範囲を絞る作業にはMVPの範囲を決めるチェックシートを、範囲・期日・費用のどれを固定してどれを動かすかの判断には範囲・期日・費用の優先順位シートをお使いください。期日を動かせないと決めた場合は、範囲か費用のどちらかが動きます。三つとも固定すると、期日が来たときに品質が動きます。

期間についても、何が効くのかを先にお伝えします。ご提示した工程表が長いと感じられたときに、どこを動かせば縮むのかをご自身で判断していただくためです。具体的な日数は範囲によって変わるため、ここでは向きだけを示します。

このうち、延びる方向の要因の多くはお客様側で早めに手を打てるものです。特に外部の手続きは、必要と分かった時点で並行して始めていただくと、そのまま期間の短縮になります。

複数社から見積りと工程表を受け取ったとき、期間の短い提案が優れているとは限りません。範囲が狭い、設計や検収の工程が入っていない、お客様側の作業日数を見込んでいない、といった理由で短く見えることがあります。各社に同じ観点で尋ねてみてください。

• どの工程に何日を見込んでいますか: 設計・開発・検収・公開の配分を出してもらいます。開発だけが書かれた工程表は、設計と検収の日数が計上されていない可能性があります
• 弊社側（発注側）の作業日数は含まれていますか: 画面案の確認、実データの提供、検収作業に何日を見込んでいるか。ここが空欄の工程表は、実際にはその分だけ延びます
• 確認の待ち日数を何日で計算していますか: 返答に3日かかる前提と、当日中に返ってくる前提では、同じ作業量でも工程表の長さが変わります
• 外部の手続きの待ち時間は入っていますか: 決済代行の審査、ドメイン移管、外部APIの利用申請などは、開発の速さでは縮みません
• 遅れた場合、何がどうなりますか: 範囲を削るのか、公開日を動かすのか、費用が増えるのか。契約形態によって扱いが変わります
• この期間を縮めるとしたら、どこを削ることを勧めますか: 答えの内容よりも、削る判断の根拠を持っているかが分かります

同じ質問を弊社にもお尋ねください。工程表の前提をご説明します。見積り全体を並べて比べる手順は相見積もりの比較シートに、契約前に確認したい観点は開発パートナー選定で確認する15の質問にまとめています。

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

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

資金の残り月数から逆算する場合は、期間と費用を同時に考える必要があります。ランウェイから逆算する開発予算で開発に回せる額と範囲を先に決めてからご相談いただくと、実現できる工程を具体的にご提案できます。公開当日の段取りはリリース前チェックリストにまとめています。