バックエンドの案件で非機能の条件を詰めないまま参画すると、稼働が始まってから認識のずれに気づき、対応の負担が一方に偏ってしまうことがあります。調査の数字を見ると、非機能に関わる備えは項目によって整い方に差があり、評価の軸も品質という特定の視点に寄っています。この記事では、条件を引き出す立場から、非機能をどう詰めていくかを整理します。

1. 決まっている備えと、決まっていない備え

非機能の話が定まらないまま進む案件でも、「まったく手つかず」とは限らず、実際には項目によって整い方に差があります。この差そのものが、話し合いの材料になります。

企業ごとに分かれる備えの状況

ITのリスク管理と業務継続計画については、全体の5〜6割程度の企業が整備しています¹。この数字は、全体が整っているわけではないことも示しています。障害が起きたときに誰が何を確認し、どの順番で対応するかという手順の有無は、案件に入る前に確かめる項目になります。

整っている前提で会話を進めるよりも、整備の有無をまず確かめる問いから入るほうが、実態に近づきます。「すでに手順があります」という答えが返ってくることもあれば、「これから整えます」という答えが返ってくることもあり、その違いによって、案件の中で担う役割の重さも変わってきます。

利用する側で4〜5割にとどまるセキュリティのガイドライン

セキュリティのガイドラインについても、利用する側の企業では4〜5割程度にとどまっています¹。ガイドラインの有無を確かめることは、担当する範囲を見積もる最初の一歩になります。

この差は、相手を指摘する材料ではなく、条件を具体化する入り口として使います。整っていない部分が見つかったら、その部分を条件として書き出します。

条件を引き出す材料としての備えの差

半分が整っていて、半分がまだ整っていないという状況は、悪い知らせではありません。整っていない側を早い段階で見つけられれば、案件に入る前にその部分を条件として言葉にしておけます。

反対に、整っている前提のまま話を進めてしまうと、稼働が始まってから「思っていたのと違う」という認識のずれが表面化します。備えの状況を最初に確かめる姿勢が、後の負担を減らす近道になります。

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

2. 品質に置かれる評価の軸

非機能を条件として詰めるときは、相手が何を評価の軸に置いているかを先に知ります。

利用する側が最優先に置く品質の視点

利用する側の企業は、システムの品質を最も優先する事項として捉えています¹。納期やコストの話が先に出る場面もありますが、根っこの部分では品質が判断の軸になっているということです。

この視点を先に知っておくと、条件を引き出す会話の組み立て方が変わります。コストを削る相談よりも、品質をどう確かめるかという相談のほうが、相手が最優先に置く視点と重なります。

案件ごとに変わる評価の置き所

品質が最優先とはいえ、案件ごとに何をもって品質とするかは同じではありません。応答の安定を重く見る案件もあれば、障害が起きたときの復旧のしやすさを重く見る案件もあります。どこに重心があるかを早い段階で聞くと、後の作業の優先順位を組めます。

評価の視点を確かめずに進めると、自分では十分と考えていた対応が、相手の基準とかみ合わないまま進むことがあります。作業を始める前に評価の視点を言葉にしてもらう一往復が、後の手戻りを減らします。

評価の視点を条件の会話に落とし込む整理

評価の視点を漠然と聞くだけでは、会話がかみ合わないことがあります。品質・コスト・スピードという3つの視点に分けて、それぞれ何が判断の理由になるか、条件としてどこを確かめるかを整理します。次の表に、視点ごとの整理を示します。

評価の視点	判断の理由になる背景	条件として確かめること
品質	利用する側が最優先に置く視点1	何をもって十分とするかの認識合わせ
コスト	見積もりの起点になる視点	想定している体制と稼働量の前提
スピード	短い納期の要望と結びつく視点	確認や検証にあてられる時間の幅

表に挙げた3つの視点は、どれか1つだけを確かめれば十分という話ではありません。品質を軸にしながらも、コストとスピードの前提を合わせて聞くと、条件のずれを減らせます。

3. 確認の自動化が薄い前提

評価の軸の次は、確認の自動化がどこまで進んでいるかという前提です。

作る側を除くと限られる自動化された確認

DevOpsやモデルベース開発については、ベンダー企業を除くと導入している企業は少なく¹、確認や検証を自動で回す仕組みが整っていない案件もあります。

自動化された確認が薄い前提で入る案件では、確認の手順そのものを自分たちで組み立てる場面が出てきます。仕組みが最初からある前提で見積もるよりも、まず有無を確かめてから見積もるほうが、後の負担のずれを減らせます。

一部にとどまるアジャイル開発の広がり

アジャイル開発は、一部を含めると全体の2〜4割程度の企業が導入しています¹。導入していない企業では、開発の進め方そのものが異なる前提で案件が組まれています。

進め方の前提が違うと、非機能の確認をどのタイミングで挟むかという段取りも変わります。開発の進め方を先に確認すると、確認の自動化がどこまで見込めるかを見積もる手がかりになります。

自動化が薄い前提での条件の引き出し方

自動化された確認が薄い案件は、確認の仕組みをどう組み立てるかという相談ができる案件でもあります。自分の経験を生かせる余地は、そこにあります。

確認の自動化がどこまで進んでいるかを早い段階で聞くと、参画後に想定外の作業が積み上がる事態を減らせます。次に言葉にするのは、この確認をいつ、誰と行うかという条件です。

4. 測れる状態を先に作る

確認の自動化が薄い前提で案件に入るなら、最初にやることは、状態を測れるようにすることです。

出発点となる定量的な計測とダッシュボード

クラウドサービスの適切な利用に関する方針では、定量的な計測とダッシュボードによる状況の可視化が挙げられています²。感覚で「大丈夫そう」と判断するのではなく、数値として見える状態を先に作るという考え方です。

測れる状態がないまま運用を始めると、何かが起きたときにも「いつもと違う」としか言えず、対応の判断が遅れます。感覚で判断するよりも、数値の変化で判断するほうが、条件を話し合う材料が揃います。

測る土台を先に置く、条件を書き出す順番

測れる状態を作る前に、可用性や応答の目標値だけを先に決めようとすると、根拠のない数字が独り歩きすることがあります。まず何をどう測るかを合わせてから、その数値をもとに条件を具体化する順番のほうが、後々の認識のずれを防げます。

この順番は、参画する側にとっても話し合いの材料になります。測る仕組みが整っていない案件では、「まず何を測るか」を一緒に決める工程そのものを、自分の役割として提案できます。

観点ごとの測る対象の整理

測るといっても、対象は一つではありません。応答や処理の状況、異常の兆候、体制の余力といった観点に分けて、何を確かめるか、いつ確認するかを整理します。次の表に整理を示します。

観点	確かめること	確認するタイミング
応答や処理の状況	数値として継続的に見えているか	参画の初期段階
異常の兆候	ダッシュボードで捕捉できているか2	本番稼働の前後
体制の余力	対応にあてられる人と時間があるか	条件を話し合う段階

3つの観点をそれぞれ確かめると、測る土台がどこまで整っているかを、感覚ではなく事実として相手に示せます。

出典：政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2026年）をもとに作成

5. 終わらない更新への追従

測れる状態ができても、非機能への対応は一度整えたら終わりではありません。更新への追従は、稼働が始まってからも続きます。

前提となる継続的なアップデートへの対応

クラウドサービスの適切な利用に関する方針では、継続的なアップデートへの対応が挙げられています²。土台となるサービスや部品は、時間とともに更新され続けるため、それに追従する作業も継続して発生するという前提です。

「一度作って終わり」という発想よりも、「作った後も更新に追従し続ける」という発想で臨みます。この前提を知らずに参画すると、稼働後の作業量を見誤ることがあります。

続く作業としての確認テストの最適化

同じ方針では、マネージドサービスの更新時の確認テストを最適化することも挙げられています²。更新のたびに広い範囲を一から確認し直すのではなく、確認する範囲や手順を効率化していく取り組みが挙げられています。

確認テストの最適化は、一度やれば済む作業ではなく、更新が続く限り見直しを重ねていく作業です。稼働後にどれくらいの頻度でこの見直しが発生するかは、参画前に聞きます。

条件として共有する、終わらない前提

更新への追従が終わらないという前提を、案件に入る前に共有できているかどうかで、稼働後の負担感は大きく変わります。終わりのある作業だと思って参画すると、続く作業が想定外の負担になります。

反対に、続く作業だと最初から共有できていれば、体制や時間の使い方をあらかじめ組み込んでおけます。次に言葉にするのは、更新への追従にどれだけの時間を見込んでいるかという条件です。

出典：政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2026年）をもとに作成

6. 常時の余裕という非機能

更新への追従と並んで、日々の運用で関わるのが、リソースの使い方です。

ピーク時に備えた余裕と通常時の使い方

クラウドサービスの適切な利用に関する方針では、ピーク時を想定した大きなリソースを通常時に使用しないことが挙げられています²。負荷の高い場面に備えた余裕を、普段の運用にそのまま持ち込まないという考え方です。

常に大きな余裕を確保しておくことは、安心材料に見えて、実際にはコストや管理の負担として跳ね返ってきます。ピーク時とそれ以外の場面を分けて考えるほうが、限られた予算を無理なく使えます。

最初にそろえる「ピーク」の定義

何をもって「ピーク時」とするかは、案件によって前提が異なります。利用が集中する時間帯を指す場合もあれば、特定のイベントに合わせた一時的な増加を指す場合もあります。この認識がそろわないまま話を進めると、必要な余裕の大きさについても意見が食い違います。

「ピーク」の定義を最初にそろえておくことは、通常時のリソースの使い方をどこまで絞れるかという話にも直結します。定義があいまいなまま余裕を積み増すよりも、定義をそろえてから必要な分だけ用意するほうが、無理のない設計になります。

場面ごとに分ける確認の条件

ピーク時と通常時とでは、リソースの使い方に対する姿勢も変わります。それぞれの場面で何を確認するかを、次の表に整理します。

場面	リソースの使い方の姿勢	条件として確認すること
ピーク時	想定する負荷に対応できる余裕を用意する	何を「ピーク」と見なすかの認識合わせ
通常時	ピーク時想定の余裕をそのまま使い続けない2	普段のリソースの使い方をどこまで絞るか

場面を分けて条件を確認しておくと、常時の余裕という非機能についても、感覚ではなく合意として共有できます。

7. 続ける前提での計画づくり

非機能への対応は、どれも「一度整えたら終わり」ではなく、続けることが前提です。この前提を計画にどう組み込むかを整理します。

運用フェーズを含む予算と体制と日程の計画

クラウドサービスの適切な利用に関する方針では、運用フェーズも含めて日々改善していくことを前提に、予算、体制、スケジュール等を計画することが挙げられています²。作って終わりではなく、運用しながら改善し続けることを、最初から計画に織り込むという考え方です。

この前提を知らずに参画すると、稼働後に発生する改善の作業を「想定外」として受け止めてしまいます。最初から計画に含まれているものとして受け止めれば、日々の進め方に無理が出ません。

書き出しておく条件の一覧

案件に入る前に条件として書き出す項目を、次の図に示します。

出典：政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2026年）をもとに作成

予算・体制・日程・更新への対応という4つの項目は、どれも一度決めたら固定されるものではなく、運用の中で見直しが入る前提のものです。この前提を共有できているかどうかが、条件を引き出す会話の質を左右します。

条件を引き出す立場から見える案件

非機能の条件を引き出す会話ができる立場は、要件を一方的に決められる立場とは別の形で、経験を生かせます。曖昧なままの案件では、条件を言葉にする力が役に立ちます。

Remoguが扱う案件は、90%以上がフルリモート可能です。場所に縛られずに、条件を確かめながら参画先を選びたいなら、まず自分の経験に合う案件を見てみることが、次の一歩になります。

8. よくある質問

監視や計測の仕組みがまだ無い案件は、避けたほうがいいですか

定量的な計測とダッシュボードによる可視化は、基本方針に挙げられている取り組みです²。仕組みがまだ整っていない案件では、その仕組みを一緒に作る役割を担えます。

アップデートへの対応にかかる負担は、案件によってどのくらい違いますか

継続的なアップデートへの対応は基本方針に挙げられており²、更新時の確認テストの最適化も同じ方針に含まれています²。負担の大きさは案件ごとに異なるため、稼働頻度や確認の範囲は、参画前の条件として確かめます。

運用に入ったあとの改善作業は、最初から計画に入っているものですか

基本方針は、運用フェーズも含めて日々改善していくことを前提に、予算、体制、スケジュール等を計画することを挙げています²。個々の案件での扱いは、参画前に予算と体制の前提を聞いて確かめます。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まる備え（2025年4月・2026年10月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見えるようにする（2026年・2026年10月確認）