案件の稼働時間を決める場面で、意識が向きやすいのは仕組みを作り上げるまでの時間です。設計してコードを書き、動作を確認して納品する。そこまでを一つの区切りとして数える見方は自然に思えます。ところが実際に案件が始まると、作った後にも時間を使う場面が次々に出てきます。稼働時間の見積りが崩れやすいのは、条件として提示する前にこの部分を数えていないからです。

1. 崩れるのは作るまでしか数えていないから

運用フェーズも計画に入れる前提がある

案件の稼働時間を見積もるとき、多くの場面で対象になるのは仕組みを作り上げるまでの時間です。設計してコードを書き、動作を確認して納品する。ここまでを一つの区切りとして数える見方は、確かに分かりやすい区切り方です。

しかしデジタル庁が示す政府情報システムの整備方針では、運用フェーズも含めて日々改善していくことを前提に、予算と体制とスケジュールを計画する必要があると述べられています¹。作って終わりではなく、動かし続ける段階までを一つの計画の範囲に含める考え方です。

この前提を知らずに稼働時間を示すと、運用フェーズに入ってから「思っていたより時間がかかる」という食い違いが起きやすくなります。作るまでの時間だけで区切っていた側からすると、その先の対応は想定外の追加作業に見えてしまいます。

作るまでの時間だけで区切る見方よりも、作った後の時間まで含めて数える見方のほうが、実際の仕事量に近づきます。ここでの違いは、条件として置く数字そのものに直結します。

見積りの対象がどこで切れているかを確認する

同じ資料では、見積りを取得する段階での留意点が項目として置かれています²。事前に何を確認しておくかが整理されているということは、見積りの精度が担当者の感覚だけに委ねられている領域ではないという裏付けにもなります。

見積りが崩れる原因は、技術力の不足ではなく数える範囲の設定にあることが多いといえます。作るまでの時間で区切るか、作った後の時間まで含めるかを、条件を決める前にはっきりさせておくことが出発点になります。

参画する前の場面では、見積りの対象がどこまでかを尋ねられることがあります。作るまでの時間だけを答えるか、作った後の時間まで含めて答えるかで、相手に伝わる稼働時間の厚みは変わります。自分がどちらの前提で数えているかを、先に言葉にしておくと説明がぶれにくくなります。

この違いは、条件を確認する側にとっても重要です。作るまでの時間だけを聞いて納得してしまうと、作った後に続く仕事の分だけ、想定していた稼働時間との差に後から気づくことになります。

図の作成：Remogu編集部。稼働時間の見積りにおける時間の区分を整理したもので、統計データではありません

2. 作った後に続く仕事

更新への対応は日常の中に組み込まれている

作った後に続く仕事の中心にあるのは、更新への対応です。デジタル庁の方針では、継続的なアップデートへの対応が項目として挙げられています³。仕組みを作った時点で終わる仕事ではなく、その後も対応を重ねていく仕事として位置づけられています。

さらに同じ資料では、サービスの更新は特別な出来事としてではなく、日常的に対応していく必要があると述べられています⁴。月に一度あるかないかの例外的な作業ではなく、続けて発生する前提の仕事だということです。

続く仕事の存在を知らずに稼働時間を決めると、仕組みを作り終えた後の時期に、想定していなかった作業時間が積み重なっていきます。作り終えた直後の落ち着いた時期こそ、次に何が発生するかを確認しておく機会になります。

何が「続く仕事」に当たるのかを整理する

続く仕事を漠然と捉えていると、稼働時間の条件を決める場面でも扱いが曖昧になります。どんな種類の仕事が、いつ、どのくらいの頻度で発生するのかを、あらかじめ言葉にしておくと話が進めやすくなります。

仕事の種類	主な内容	発生のタイミング
継続的なアップデートへの対応	機能や仕組みの更新に合わせて確認や調整を重ねる	更新が公開されるたび
サービス更新への日常対応	提供元の更新を前提に、都度点検する仕組みを保つ	日常的に、随時
稼働中の状況確認	動いている仕組みについてクライアントと状況を確認する	必要に応じて

表からも分かるとおり、続く仕事には発生のタイミングが読みやすいものと、そうでないものが混ざっています。この違いを分けて数えておくと、条件として提示する材料が具体的になります。

参画する前の面談では、更新への対応をどの程度の頻度で見ているかを尋ねられる場面があります。表に挙げた仕事のうち、どれがこれまでの経験と結びつくかを言葉にしておくと、条件の話し合いで具体的な材料になります。

続く仕事の中身を具体的に言葉にできると、条件の話し合いの場面でも、根拠のある材料として伝わりやすくなります。反対に漠然とした言い方のままだと、稼働時間の条件も曖昧なまま進んでしまいます。

3. 更新への対応は毎月ある仕事

更新をイベントとして数えると見積りがぶれる

更新への対応をイベントとして扱うと、更新が集中した月だけ稼働時間が膨らみ、そうでない月は少なく見えます。デジタル庁の方針が示すとおり、更新は日常的に対応していく仕事です⁴。イベントではなく、毎月ある仕事として数え方を組み立てたほうが実態に近づきます。

毎月ある仕事として扱うよりも、発生した月だけ特別扱いする数え方のほうが、条件を決める場面では扱いにくくなります。月ごとの増減をならして考える視点が必要です。

更新への対応を月ごとの増減だけで捉えていると、平均的な時間を示しても実感が伝わりにくくなります。多い月と少ない月がどちらもあるという前提を先に共有しておくと、稼働時間の説明がしやすくなります。

確認テストの最適化が時間の使い方を左右する

同じ資料では、マネージドサービスの更新時における確認テストを最適化することが挙げられています⁵。確認の手順を整えておけば、更新のたびにかかる時間を抑えられるという考え方です。

更新への向き合い方	稼働時間の扱い	起きやすいこと
更新をイベントとして数える	発生した月だけ時間を足す	見積りが更新の頻度でぶれる
更新を日常の仕事として数える	毎月一定の時間をあらかじめ確保する	確認テストを最適化すれば時間を抑えられる

確認テストがどこまで最適化されているかによって、更新への対応にかかる時間の幅は変わります。条件を決める前に、確認の手順がどこまで整っているかを合わせて確認しておく意味があります。

確認テストの最適化がどこまで進んでいるかは、参画する前に確認しておきたい点の一つです。整っている案件では確認にかかる時間が読みやすく、整っていない案件では確認そのものに時間を割く前提で考える必要があります。

4. 自動化をどこまで含めるか

自動化は時間を減らす手段であって前提ではない

更新への対応にかかる時間を抑える手段として、デジタル庁の方針では運用作業の自動化を徹底することが挙げられています⁶。自動化が進んでいれば、確認や調整に使う時間は減っていきます。

ただし自動化がどこまで進んでいるかは案件によって異なります。見積りを取得する段階の留意点として置かれている項目の中にも²、前提を確認する視点が含まれていると読めます。自動化を前提にした数え方を先に置いてしまうと、確認の仕組みがまだ整っていない案件では時間が不足します。

自動化が進んでいない案件では、確認作業を人の手で担う場面が増えます。これまでの経験の中で、確認や調整を手作業で担ってきた経験があるなら、その経験は自動化が途上の案件でこそ活きてきます。

自動化の有無を条件確認の材料にする

自動化が進んでいる案件のほうが、確認や調整に使う時間は短く済みます。反対に自動化が進んでいない案件では、確認作業そのものに時間を割く必要が出てきます。どちらの前提で稼働時間を数えるかは、条件を決める段階で確かめておきたい点です。

自動化が進んでいるかどうかで、稼働時間の中身も変わります。自動化が進んだ案件では確認の時間が短くなる一方、判断や調整の質が問われる場面が増えます。反対に自動化が途上の案件では、確認作業に割く時間そのものが多くなります。

自動化の状況は、実際に参画してみないと分からない部分もあります。それでも事前に尋ねられる範囲で確認しておくと、稼働時間の条件を決めるときの前提がそろいやすくなります。

自動化の状況を尋ねる場面では、尋ね方によっても得られる情報の厚みが変わります。仕組みそのものについて尋ねるだけでなく、確認の手順がどこまで整っているかまで尋ねると、稼働時間の前提がより具体的になります。

自動化の状況を尋ねる質問を一つ持っておくだけでも、稼働時間の条件をクライアントと協議する場面の材料になります。数字を示す前に、前提をそろえておくことが先になります。

5. 進め方によって数え方が変わる

ウォーターフォールとアジャイルでは見積りの単位が違う

稼働時間の数え方は、案件の進め方によっても変わります。IPAの調査では、アジャイル開発は一部を含めると全体の2〜4割程度の企業が導入しています⁷。一方で、開発手法はいまもウォーターフォールが主流だと述べられています⁸。

ウォーターフォール型の進め方では、工程ごとにまとめて見積もる数え方が中心になります。対してアジャイルを一部含む進め方では、短い区切りごとに見積もりながら積み上げていく数え方になります。

進め方が工程ごとにまとめる形かどうかを、参画する前に確認しておくと、稼働時間の数え方をどちらの前提で示せばよいかが分かります。進め方を確認しないまま数え方を決めると、後になって前提のずれに気づくことになります。

進め方を確認してから数え方を選ぶ

どちらの進め方が採られているかで、稼働時間を条件として提示するタイミングも変わります。工程ごとにまとめる進め方では区切りの前に、区切りごとに積み上げる進め方ではその区切りが始まる前に、それぞれ条件を置く場面があります。

進め方	見積りの単位	数え方の特徴
ウォーターフォール型	工程ごとにまとめて見積もる	工程が終わるまでの時間を通しで数える
アジャイルを一部含む進め方	短い区切りごとに見積もる	区切りごとに見直しながら積み上げる

進め方を確認せずに数え方だけを決めてしまうと、実際の仕事の進み方と条件がかみ合わなくなります。まず進め方を確認し、それに合った数え方を選ぶ順番が大切になります。

区切りごとに見直しながら積み上げる進め方の経験があるなら、その経験は短い区切りごとに条件を確認する場面でそのまま活きます。反対に工程ごとにまとめる進め方に慣れているなら、区切りが変わるたびに条件を出し直す進め方には調整が必要です。

進め方の単位を確認しておくと、条件を出し直す場面がいつ来るのかも予測しやすくなります。予測できていれば、条件の見直しを持ちかけるタイミングも自分で選びやすくなります。

6. 止まったときの対応を含めるか

業務継続計画を整えている割合は半数程度

動いている仕組みが止まったときの対応をどこまで稼働時間に含めるかも、決めておきたい点です。IPAの調査では、ITのリスク管理と業務継続計画は全体の5〜6割程度の企業が整備しています¹⁰。

出典：2024年度ソフトウェア動向調査 簡易分析レポート、IPA、2025年4月をもとに作成

整えている側と、まだそこまで至っていない側が、ほぼ半々に近い形で分かれています。止まったときの対応をどう扱うかという前提も、案件によって差があるということです。

整えている側の案件では、止まったときの対応があらかじめ手順として用意されています。まだそこまで至っていない側の案件では、止まった場面での対応を、その都度その場で決めていくことになります。

契約の手間も止まったときの対応に関わる

同じ調査では、システム開発の契約では、取引ごとに手間や工数がかかる点が課題として挙げられています⁹。止まったときの対応を都度の取り決めとして扱うと、その都度の手間が発生しやすくなります。

止まったときの対応を稼働時間の条件に含めるかどうかは、案件が始まる前に確認しておきたい一点です。含めないまま進めると、実際に止まった場面で条件のすり合わせから始めることになります。

止まったときの対応をこれまでに経験してきたなら、その経験は条件を話し合う場面での材料になります。手順が用意されていない案件では、経験に基づいて対応の目安を示せること自体が、条件を先に置く材料になります。

止まったときの対応をどこまで担うかによって、稼働時間の幅も変わります。担う範囲を先に決めておけば、実際に止まった場面でも、条件からそれた対応を求められることは少なくなります。

7. 条件として先に置く順番

先に置いた場合と後から言った場合の違い

ここまで見てきた要素は、稼働時間の条件として先に置くか、後から言うかで結果が変わります。デジタル庁の方針では、見積りを取得する段階での留意点が項目として置かれています²。先に確認しておく項目があるという前提そのものが、順番の大切さを示しています。

後から言った条件よりも、先に置いた条件のほうが、双方が同じ前提で話を進める材料になります。後から言った条件は、すでに進んでいる話に割り込む形になりやすく、扱いが難しくなります。

先に置いた条件と、後から言った条件の差は、話し合いの雰囲気にも表れます。先に置かれた条件は前提として扱われますが、後から言われた条件は、すでに進んでいる話の中で扱いを決め直す対象になりやすくなります。

先に条件を置くことは、相手に一方的に要求することではありません。前提を共有しておくことで、双方が同じ内容を確認しながら話を進められるようにするための準備です。作った後に続く仕事や止まったときの対応について、あらかじめ言葉にしておくと、この準備が具体的になります。

図の作成：Remogu編集部。条件を伝える順番による違いを整理したもので、統計データではありません

条件として先に置く順番

運用フェーズも含めて予算と体制とスケジュールを計画する必要があるという前提に立てば¹、最初に置くのは作った後に続く仕事の範囲です。続けて、更新への対応の頻度、自動化の状況、進め方の単位、止まったときの対応の扱いという順番で確認していくと、話が積み上がりやすくなります。

図の作成：Remogu編集部。条件として先に置く順番を整理したもので、統計データではありません

条件を先に置く順番は、案件ごとにまったく同じにはなりません。ただし、作った後に続く仕事から止まったときの対応まで、何を確認する必要があるかを自分の中で並べておくことが、条件を先に置くための助けになります。

稼働時間の条件は、数字だけを先に置いても伝わりません。何を数えているのかという前提をそろえてから、条件として提示する。その順番を守ることが、見積りが崩れない案件との関わり方につながります。

稼働時間の条件は案件が始まってから決めても良いですか

話が進んでから条件を出すよりも、先に条件として置いておくほうが、双方の前提がそろいやすくなります。見積りを取得する段階での留意点が項目として置かれているのも²、条件を先に確認しておく前提があるからだと読めます。先に条件を出すことは相手に負担を求める行為ではなく、双方の前提をそろえるための準備だと捉えると、条件を切り出しやすくなります。

更新への対応の時間はどのくらい確保すればよいですか

更新への対応は、日常的に発生する仕事として扱う必要があります⁴。確保する時間の具体的な量は案件によって異なるため、確認テストがどこまで最適化されているかを合わせて確かめておく必要があります⁵。目安の数字を持たない場合は、直近の数か月で実際に何にどれだけ時間を使ったかを書き出して、その実績を材料にします。

止まったときの対応は稼働時間の条件に含める対象になりますか

業務継続計画を整えている企業は全体の5〜6割程度です¹⁰。整えている側と、まだそこまで至っていない側の両方があるため、止まったときの対応を含めるかどうかは案件ごとに確認しておきたい点です⁹。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年・2026年8月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見積りの作法（2026年・2026年8月確認）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」終わらない作業（2026年・2026年8月確認）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」更新の捉え方（2026年・2026年8月確認）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」テストの費用（2026年・2026年8月確認）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」人の時間（2026年・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」混在する現実（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まる備え（2025年4月・2026年8月確認）