本業を続けながら、内製で開発を進める場合、「どれくらいの時間を確保できるか」を、現実的に見積もることが、計画を無理のないものにするために重要です。この記事では、本業を続けながら開発する時間を、どう見積もるかを解説します。
この記事で分かること
本業がある中での開発時間の見積もりは、単純に「1日に使える時間」を計算するだけでは不十分です。多くの人が最初に立てる計画は、「平日の夜に2時間、休日に5時間」といった、カレンダー上の空き時間をそのまま作業時間に変換したものになりがちです。しかし、実際に開発を始めると、この見積もりはほとんどのケースで崩れます。理由は、時間の「量」だけを見ていて、「継続できるかどうか」「実際に何に使われるか」という質的な側面を見落としているためです。
この記事では、より現実的な見積もりのための視点を紹介します。単発の週末プロジェクトではなく、数ヶ月にわたって本業と両立させながら開発を進める前提で、時間配分の考え方を整理していきます。
結論を先に示すと、押さえておきたいポイントは次の3つです。
- 「使える時間」ではなく「継続できる時間」を見積もる
- すべての時間を、作業時間として計算しない
- 週単位・月単位で、余裕を持った計画を立てる
ポイント1：「使える時間」ではなく「継続できる時間」を見積もる
本業がある中で、開発に使える時間を見積もる際、「今週は忙しくないから、多めの時間を使える」という一時的な余裕を、基準にしないことをおすすめします。開発は、数週間から数ヶ月にわたって継続する作業であるため、忙しい時期も含めた、平均的に継続できる時間を見積もることが重要です。
例えば、「平日は1時間、休日は3時間」というように、無理のないペースを設定し、それを継続できるかを、まず確認することをおすすめします。
「今週は調子がいい」を基準にしてしまう失敗パターン
見積もりの失敗で最も多いのが、開発を始めた直後、モチベーションが高い時期の作業ペースを、そのまま今後の基準にしてしまうことです。始めたばかりの数週間は、新しい技術を触る楽しさや、目に見える進捗があることで、普段より多くの時間を投入できます。休日に6時間、平日も1〜2時間、開発に充てられたとします。この時期の実績を見て、「1週間あたり15〜20時間は確保できる」と判断し、その後の計画をこのペースで組んでしまうと、数週間後に本業側の繁忙期や、私生活での予定が入った瞬間に、計画全体が崩れます。
重要なのは、開発を始めてから4週間ほどの実績を記録し、その中でも「一番忙しかった週」に、どれだけの時間を確保できたかを基準にすることです。好調な週の実績ではなく、不調な週でも維持できた時間を、継続できる時間として見積もるという考え方です。
本業の繁忙期・閑散期を織り込む
本業の仕事内容によっては、月内・年内で繁忙期と閑散期の差が大きい場合があります。月末に業務が集中する仕事であれば、月の後半は開発時間がほとんど確保できないことを、あらかじめ想定しておく必要があります。年間を通じて、決算期や年度末に業務が増える仕事であれば、その時期は開発を一時的に止める、あるいはペースを大きく落とすという判断も、計画に組み込んでおくことをおすすめします。
「繁忙期にどれだけ開発が進むか」を基準にするのではなく、「繁忙期は開発がほぼ進まない」という前提で、閑散期にどれだけ前倒しで進められるかを考えるほうが、現実に近い計画になります。
ポイント2：すべての時間を、作業時間として計算しない
開発にかかる時間には、実際にツールを操作する時間だけでなく、調べる時間、迷って手が止まる時間、休憩を挟む時間なども含まれます。「1時間確保できたから、1時間分の作業が進む」と考えるのではなく、実際に進む作業量は、確保した時間よりも少なくなることを、あらかじめ想定しておくことをおすすめします。
特に、慣れていない作業やツールを使う場合、想定よりも多くの時間がかかることが一般的です。
「確保した時間」と「実際に進む時間」のギャップ
例えば、平日の夜に1時間を確保できたとしても、その1時間の中身は、次のように分解できます。
- 本業から切り替えて、開発の状態に集中し直すまでの時間（5〜10分程度）
- 前回どこまで進めたか、何をしようとしていたかを思い出す時間（5〜10分程度）
- 分からないことを調べる、エラーの原因を探す時間（人によって大きく変動）
- 実際に手を動かして進める時間
慣れた作業であれば、実質的な作業時間は40〜50分程度になることが多いですが、慣れていない作業や、初めて使うツール・機能に取り組む場合は、調べる時間や迷う時間が半分以上を占めることもあります。1時間確保したのに、実質的に進んだのは20分分の作業だけ、という状況は、開発の初期段階では珍しくありません。
この「ギャップ」を最初から想定しておくと、計画が崩れたときの焦りを減らせます。逆に、確保した時間がそのまま作業量に変換されると考えていると、「思ったより進んでいない」という感覚が積み重なり、モチベーションの低下につながります。
見積もりに使える簡易的な目安
厳密な計測は不要ですが、大まかな目安として、次のような掛け算で考えると、現実的な見積もりに近づけやすくなります。
- 慣れた作業（過去に同種の作業をしたことがある場合）：確保した時間 × 0.7〜0.8
- 初めての作業（新しい機能・新しいツール・新しい概念を扱う場合）：確保した時間 × 0.4〜0.5
例えば、休日に5時間を確保していても、そのうち2時間が初めて触る機能の実装だとすれば、実質的な作業量は「3時間 × 0.75 + 2時間 × 0.45 = 3.15時間分」程度と見積もっておくと、計画と実績のズレを小さくできます。この目安はあくまで感覚的なものですが、「確保した時間=進む時間」という前提を外すこと自体に意味があります。
ポイント3：週単位・月単位で、余裕を持った計画を立てる
1日単位の細かい計画ではなく、週単位・月単位で、大まかな進捗の目安を設定することをおすすめします。「今週はこの機能を完成させる」という目標を立て、達成できなかった場合は、翌週に調整するという、柔軟な計画の立て方が、本業との両立には向いています。
厳密なスケジュールを組みすぎると、本業の都合で計画通りに進まなかった際に、焦りやストレスにつながることがあります。
1日単位の計画が崩れやすい理由
1日単位で「今日はこの機能を作る」と決めてしまうと、本業で急な残業が入ったり、私生活で予定外のことが起きたりするだけで、その日の計画が丸ごと崩れます。1日ごとに達成・未達成が発生すると、未達成が続くたびに「計画通りに進められていない」という感覚が積み重なり、開発自体への意欲が下がっていきます。
これに対して、週単位・月単位の計画であれば、平日に1日進められなかったとしても、休日や翌日でカバーする余地があります。「今週中にこの機能を完成させる」という単位であれば、多少の予定変動を吸収できる幅が生まれます。
バッファの入れ方
計画にバッファ（予備の時間・予備の期間）を入れる際は、「全体の期間に一律で1.2倍する」というような単純な掛け算ではなく、次の2種類のバッファを分けて考えることをおすすめします。
- 時間のバッファ：1週間の見積もり時間に対して、実際にはその7〜8割しか確保できない前提で計画する
- 期間のバッファ：全体の完成予定期間に対して、1〜2週間分の予備期間を、最初から計画の外側に用意しておく
例えば、「3ヶ月で完成させたい」という目標であれば、実際の計画は「10〜11週間で完成させる計画」を立て、残りの1〜2週間は最初から「予備」として扱います。この予備期間を使わずに済めば早く完成し、使うことになっても、当初の目標期間内に収まります。この考え方は、外部に納期を伝える必要がある場合にも有効です。
時間の確保が難しいと感じた場合の対処法
実際に開発を始めてみて、想定していたよりも時間の確保が難しいと感じた場合、無理に当初の計画を守ろうとするのではなく、計画自体を見直すことをおすすめします。機能を減らす、期間を延ばす、あるいは、一部を外注に切り替えるといった選択肢を検討することが、現実的な対応です。
一部だけ外注する「ハイブリッド」な進め方の作り方については、別記事で詳しく解説しています。
見直しの判断基準（チェックリスト）
「計画を見直すべきかどうか」を判断する際、次のようなチェックリストを使うと、感覚だけで判断せずに済みます。
- [ ] 直近2〜3週間、当初の見積もり時間の半分以下しか確保できていない
- [ ] 開発のことを考えると、憂鬱さや焦りを感じる頻度が増えている
- [ ] 本業側の状況（異動・業務量の増加など）が、今後数ヶ月変わらない見通しである
- [ ] 「今週こそ追いつく」という気持ちで、3週以上、同じ遅れを持ち越している
- [ ] 家族や周囲との時間を削ることが、当たり前になってきている
これらのうち、2つ以上に当てはまる場合は、当初の計画のまま続けるのではなく、次のいずれかの見直しを検討するタイミングだと考えられます。
見直しの選択肢とその考え方
機能を減らす：最初に計画した機能のうち、「本当に今必要か」を再確認し、後回しにできる機能を削ります。最小限の機能で一度リリースし、使いながら追加していくという進め方は、本業と両立させる開発では特に有効です。
期間を延ばす：目標としていた完成時期を、現実的な確保時間に合わせて後ろに動かします。期間を延ばすこと自体は後退ではなく、継続を優先した現実的な判断です。無理な期間で完成させて、その後燃え尽きて開発が止まってしまうよりも、長い期間でも続けられるペースを維持するほうが、結果的に早く完成することも少なくありません。
一部を外注に切り替える：自分で対応すると時間がかかりすぎる部分、特に専門性が高い機能や、セキュリティ・決済など失敗した場合の影響が大きい機能について、外部に依頼することを検討します。核となる機能は自分で、周辺機能は外注する分担の考え方は、時間の制約がある場合に特に有効な選択肢です。
開発時間を確保するための、具体的な工夫
工夫1：決まった時間帯を、開発の時間として固定する
「毎日、朝の30分は開発に使う」というように、決まった時間帯を、開発の時間として固定することをおすすめします。時間帯を固定することで、習慣化しやすくなり、継続的に時間を確保しやすくなります。
時間帯を選ぶ際は、本業の疲労の影響を受けにくい時間を選ぶことも重要です。本業が終わった直後の夜の時間は、疲労で集中力が落ちていることが多く、同じ1時間でも、朝の時間帯より進む作業量が少なくなる傾向があります。逆に、朝型でない人が無理に早朝に時間を作ろうとすると、続かずに挫折してしまうこともあります。自分の生活リズムに合った時間帯を選ぶことが、継続の前提になります。
工夫2：作業を、小さな単位に分けて進める
まとまった時間が確保できない場合でも、「今日は、この画面のこの部分だけ進める」というように、小さな単位に作業を分けることで、短い時間でも、着実に進捗を積み重ねられます。
作業を分割する際のコツは、「今日やること」を、開始前に具体的に書き出しておくことです。作業に取りかかる直前に「何をするか」を考え始めると、その分だけ実質的な作業時間が減ります。前回の作業の終わりに、次回やることをメモしておく、あるいは開発を始める前日の夜に、翌日の作業内容を軽く決めておくといった工夫で、限られた時間の中でも、迷う時間を減らせます。
なお、AIを使った開発そのものの進め方については、AIを使った個人開発の現実的な進め方で、本番化の線引きも含めて解説されている。限られた時間を使い切る工夫と合わせて、時間の使い道そのものを効率化する視点としても参考になる。
工夫3：進捗を記録し、実績ベースで見積もりを更新する
週ごとに、実際にどれだけの時間を確保できたか、どこまで進んだかを簡単に記録しておくことをおすすめします。記録を続けることで、「自分は1週間にどれくらいのペースで進められるのか」という実績データが積み重なり、当初の見積もりを、実態に近い数字に更新していくことができます。
最初の見積もりが正確である必要はありません。むしろ、開発を始めてから数週間の実績を見て、当初の見積もりを修正していくというプロセス自体が、時間の見積もりにおいて重要です。
専門知識を活かしたツールの場合、時間見積もりで注意したい点
専門分野の業務知識を活かしたツールの場合、要件の整理や、業務ロジックの検討にも、相応の時間がかかることを、見積もりに含めておくことをおすすめします。技術的な作業だけでなく、専門知識を整理する時間も、開発全体の時間として考慮する必要があります。
例えば、自分の専門分野の業務フローを、そのままツールに落とし込もうとすると、「実際の業務では、この例外パターンにはどう対応しているか」「この項目は、どの順番で入力されるのが自然か」といった、業務知識の整理・言語化に、想像以上の時間がかかることがあります。これは技術的な難易度とは別の時間であるため、「コードを書く時間」だけを見積もっていると、全体の所要時間を大きく見誤ることになります。
専門知識を活かしたツールを作る場合は、技術的な実装時間に加えて、「業務ロジックを整理する時間」を、別枠として見積もりに加えておくことをおすすめします。
具体例：会社員が3ヶ月でツールを完成させた見積もりの立て方
イメージをつかみやすくするために、架空の具体例で、見積もりの立て方を通してみます。
平日は会社員として働き、休日は基本的に空いている人が、業務効率化のための社内向けツールを、3ヶ月で完成させたいと考えたケースを想定します。
最初の見積もり（甘い見積もり）：平日は夜2時間、休日は各6時間確保できると仮定すると、1週間あたり「2時間×5日+6時間×2日=22時間」。3ヶ月・約13週間で計算すると、単純計算では286時間確保できることになります。この時間があれば、当初計画していた機能はすべて実装できる、という見積もりを立てました。
実績を踏まえた見直し：しかし、開発を始めて2週間が経過した時点で、平日の実質的な作業時間は1時間程度、休日も予定が入る週があり、平均して4時間程度しか確保できていないことが分かりました。さらに、初めて扱う技術要素があり、確保した時間の半分程度しか、実質的な作業には使えていない週もありました。
この実績を基に見積もりを修正すると、1週間あたりの実質的な作業時間は「1時間×5日+4時間×2日=13時間」に対し、実質作業として使えるのはその7割程度、つまり週9時間程度という見積もりに修正されます。13週間では、117時間程度です。当初の286時間という見積もりから、実質的には半分以下の水準に修正されたことになります。
計画の調整：この修正を踏まえ、当初計画していた機能のうち、優先度の低い機能を後回しにし、まず必要最小限の機能に絞って3ヶ月で完成させる計画に変更しました。後回しにした機能は、リリース後に追加開発する機能として、別の計画に切り出しています。
このように、最初の見積もりが甘かったこと自体は問題ではなく、実績を踏まえて早い段階で見積もりを修正し、機能の範囲を現実的な時間に合わせて調整したことが、計画を守れた要因になります。最初に立てた計画をそのまま押し通そうとしていた場合、3ヶ月では全く完成しない、あるいは無理を重ねて途中で開発自体を止めてしまう結果になっていた可能性があります。
時間の見積もりと、モチベーション管理の関係
時間の見積もりは、単なる計算上の問題ではなく、開発を継続するモチベーションとも密接に関わっています。見積もりが実態から離れていると、「計画通りに進んでいない」という感覚が積み重なり、それ自体が開発を続ける意欲を削っていきます。
反対に、実態に近い見積もりを立て、それを少しずつでも達成できていると、「計画通りに進んでいる」という感覚が積み重なり、継続する意欲を支えてくれます。見積もりの精度を上げることは、単にスケジュール管理の精度を上げるだけでなく、開発を長期間続けるための、心理的な土台を作ることでもあります。
本業を続けながらの開発は、短距離走ではなく、長期間にわたる取り組みです。無理な見積もりで一時的に速く進めることよりも、実態に合った見積もりで、着実に、そして継続的に進められることのほうが、最終的な完成への近道になることが多いといえます。
時間の見積もりでやりがちな失敗パターン集
ここまでの内容を踏まえて、実際によく見られる失敗パターンを、もう少し具体的に整理しておきます。自分の計画が同じ落とし穴にはまっていないか、確認する際の参考にしてください。
失敗パターン1：「有給休暇を使えば追いつける」と考えてしまう
計画が遅れてきたとき、「今度の休みに有給を取って、まとめて進めよう」という発想に頼りすぎるのは、あまりおすすめできません。有給休暇は本来、休息や私生活のために使うものであり、それを開発の遅れを埋めるための時間として繰り返し当て込んでしまうと、本業側の生活の質が下がり、長期的には本業と開発の両立そのものが難しくなります。有給休暇を使う場面は、計画の中に最初から「予備日」として組み込んでおく場合に限り、遅れを埋めるための救済手段としては、多用しないほうが安全です。
失敗パターン2：完璧な設計を先に固めようとして、着手が遅れる
本業がある中で開発時間が限られていると分かっているからこそ、「限られた時間を無駄にしないように、最初にしっかり設計を固めておこう」と考える人がいます。この発想自体は間違っていませんが、設計の検討に時間をかけすぎて、実際にコードを書き始めるまでに数週間かかってしまうケースも見られます。設計を検討する時間も、開発全体の時間の一部として見積もりに含め、「設計に使う時間」と「実装に使う時間」を、あらかじめ大まかに区切っておくことをおすすめします。設計は一度で完璧にする必要はなく、実装を進める中で見直していくものだと考えておくと、着手が遅れる問題を避けやすくなります。
失敗パターン3：休日にまとめて進める前提で、平日の時間をゼロで見積もる
「平日は本業で疲れているから、開発は休日にまとめてやる」という計画は、一見合理的に見えますが、実際には休日の予定が入っただけで、その週の進捗がゼロになるという脆さを持っています。平日にたとえ15〜20分程度であっても、開発に触れる時間を作っておくと、休日の予定が変わっても、最低限の進捗は維持できます。また、平日に少しでも触れておくことで、休日にまとまった時間を確保したときに、「何をするか思い出す時間」を削減できるという効果もあります。
失敗パターン4：見積もりを一度立てたら、固定してしまう
開発を始める前に立てた見積もりを、その後何ヶ月も見直さずに使い続けてしまうのも、よくある失敗です。開発を始めた当初は、自分がどれくらいのペースで進められるか、正確には分かりません。数週間分の実績が積み重なった段階で、当初の見積もりが実態と合っているかを確認し、ズレがあれば見積もり自体を更新することをおすすめします。見積もりを更新することは、計画が失敗したことを意味するのではなく、精度を上げるための、通常のプロセスだと捉えておくとよいでしょう。
時間の見積もりを助けるチェックリスト
計画を立てる段階、あるいは数週間ごとの振り返りの段階で、次のチェックリストを使って、見積もりの前提を確認することをおすすめします。
- [ ] 直近1ヶ月で最も忙しかった週の実績を基準に、継続可能な時間を見積もっているか
- [ ] 確保した時間のすべてが作業時間になるとは考えず、7〜8割程度で見積もっているか
- [ ] 慣れていない作業には、確保した時間の半分以下しか進まない前提を置いているか
- [ ] 1日単位ではなく、週単位・月単位で進捗の目安を設定しているか
- [ ] 全体の期間に対して、1〜2週間分の予備期間を確保しているか
- [ ] 本業の繁忙期・閑散期のスケジュールを、開発計画に反映しているか
- [ ] 決まった時間帯を、開発の時間として固定しているか
- [ ] 次回の作業内容を、前回の終わりにメモしておく習慣があるか
- [ ] 週ごとの実績を記録し、見積もりを更新する仕組みがあるか
- [ ] 専門知識の整理・業務ロジックの検討にかかる時間を、実装時間と別枠で見積もっているか
このチェックリストの多くにチェックが入る状態であれば、時間の見積もりは、実態から大きくズレにくい状態になっていると考えられます。逆に、チェックが少ない場合は、計画を立て直すタイミングかもしれません。
Q4. 見積もりのために、専用のツールやアプリを使うべきですか
専用の時間管理ツールやタスク管理アプリを使うこと自体は有効ですが、必須ではありません。重要なのは、ツールの種類よりも、「毎週、実績を振り返る」という行為を継続することです。手元のメモやカレンダーに、その週に確保できた時間と進んだ内容を簡単に書き残しておくだけでも、数週間分を振り返れば、自分のペースを把握するには十分な材料になります。凝ったツールを導入すること自体が目的化してしまい、記録する手間が増えて続かなくなるよりは、シンプルな方法を継続することを優先することをおすすめします。
まとめ
本業を続けながら開発を進める場合の時間の見積もりは、「使える時間」をそのまま「進む作業量」に変換しないことが出発点になります。忙しい時期も含めた継続可能なペースを基準にすること、確保した時間のすべてが作業に使われるわけではないことを前提に置くこと、そして1日単位ではなく週単位・月単位で柔軟に調整できる計画を立てることの3点を押さえておくことで、計画と実績のズレによる焦りやストレスを大きく減らすことができます。
見積もりは一度立てたら終わりではなく、実際に数週間動かしてみて、実績に合わせて更新していくものです。想定より時間の確保が難しいと感じた場合は、機能を減らす、期間を延ばす、一部を外注するといった選択肢を早めに検討することが、無理のない継続につながります。
この記事の次に読みたい記事
本業を続けながら開発する時間の見積もり方を理解したら、次は自分で作れる現実的な範囲についても、あわせて確認しておきましょう。
