システム開発の納期はどう決まるのか｜急ぐと最初に削られるのはテストの時間

「いつまでにできますか」は、開発の相談で必ず出る質問です。そして「この日までに欲しい」という希望が、こちらの見立てと合わないことも珍しくありません。この記事では、FUNBREWが納期をどう見積もっているのか、そして納期を縮めたときに実際に何が削られるのかを書きます。

納期はどう見積もっているのか

機能数に、おおむね比例する

納期は機能数に応じて比例します。ですので、まず見るのはプロジェクトの規模です。「どれくらいでできますか」という質問に対して、その場で日数をお答えできないのは、この規模がまだ見えていないためです。

逆に言えば、作るものが決まっていれば納期の見当はつきます。過去の実工数から積む見積もりの考え方は、システム開発の見積もりはどう作られているかに書きました。納期も同じ材料から出しています。

だから「規模を変えずに納期だけ縮める」は難しい

機能数と期間が連動している以上、作るものをそのままにして期間だけを短くすることはできません。人を増やせば比例して早くなる、という性質の仕事でもありません。

ここが、発注側から見ていちばん納得しづらい部分だと思います。ですので、短納期のご要望には別の答え方をしています。

短納期のときにまずやること：機能を絞ってフェーズを分ける

期間が足りない場合、最初に検討するのは機能数を絞り、フェーズを分けてリリースすることです。全部を一度に出すのではなく、必要なものから順に動かしていきます。

この進め方の利点

• 期日に何かが動いている状態を作れる —— 全機能が揃わなくても、業務が回り始める形にできることが多いです。
• 後半の判断を先送りできる —— 前半を使ってみてから、後半の仕様を決め直せます。
• 品質を落とさずに済む —— これが最大の理由です。作る量を減らすので、テストの時間は確保できます。

そのためには、どの機能が先で、どれが後でよいのかという優先順位を発注側に決めていただく必要があります。ここが決まらないと、フェーズを分けられません。

それでも急ぐ場合、実際に削られるもの

正直に書きます。フェーズ分けをしてもなお期日に間に合わない場合、どうしても短縮されがちなのはテスト期間です。

テストを削ると何が起きるか

作る作業そのものは減らせません。仕様は決まっており、動かなければ納品になりません。一方でテストは、時間をかけるほど品質が上がるという性質のもので、削ろうと思えば削れてしまいます。

その結果、不具合が起こる可能性は高くなります。これは能力の問題ではなく、確認していない経路が残るという単純な話です。急いだ分のツケは、リリース後の対応として戻ってきます。

値下げのときと同じ構造

これは、値下げを受け入れたときに提案の質が削られるのと同じ構造です（値下げを受け入れた開発会社に何が起きたか）。削れない部分（仕様どおり動くこと）は残り、削れる部分から先に無くなります。そして発注側からは、削られた側は見えません。テストしていない経路は、リリースするまで誰にも見えないからです。

発注側が納期で損をしないために

期日の理由を伝える

「早いほどよい」ではなく、なぜその日なのかを教えてください。展示会、決算、契約の切れ目、繁忙期の前——理由が分かると、フェーズの切り方が変わります。その日に絶対に必要な機能と、後から足せる機能を分けられるためです。

優先順位を先に決めておく

フェーズを分ける判断は発注側にしかできません。すべての機能が同じ重要度のまま進むと、削る選択肢が使えず、テストを削るしか道が残らなくなります。追加要望が出たときの考え方は「これは追加費用です」と言われるのはどこからかも参考にしてください。

まとめ

納期は機能数におおむね比例するため、まずプロジェクトの規模を見ます。作るものを変えずに期間だけ短くすることはできません。

短納期のご要望には、機能を絞ってフェーズを分け、順にリリースする形でお応えします。この方法なら品質を落とさずに済みますが、そのためには発注側に優先順位を決めていただく必要があります。

それでも急ぐ場合、削られるのはテスト期間です。作る作業は削れませんが、テストは削れてしまうためで、その分だけ不具合の可能性は高くなります。期日の理由を教えていただければ、切り方を一緒に考えられます。お問い合わせよりご相談ください。