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

1. 半分は決まっていて、半分は決まっていない

非機能の話が定まらないまま進む案件は、珍しくありません。ただし「まったく手つかず」ではなく、実際には項目によって整い方に差があります。まず押さえておきたいのは、この差そのものが話し合いの材料になるという点です。

備えの状況は、企業によって半分ずつに割れています

ITのリスク管理と業務継続計画については、全体の5〜6割程度の企業が整備しています¹。裏を返すと、残り4割前後の企業では、障害が起きたときに誰が何を確認し、どの順番で対応するかという手順がまだ言葉になっていないと考えられます。案件に入る前にこの有無を確かめておくと、後から慌てて手順を作る事態を避けやすくなります。

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

セキュリティのガイドラインも、利用する側では追いつききっていません

セキュリティのガイドラインについても、利用する側の企業では4〜5割程度にとどまっています¹⁰。整備を進めている側と、実際にそれを使う側とでは、足並みが完全にはそろっていない場面があるということです。ガイドラインの有無を確かめることは、担当する範囲を見積もる最初の一歩になります。

この差は、どちらかの企業の怠りというより、優先順位の置き方の違いとして捉えるほうが自然です。指摘するための材料として使うのではなく、条件を具体化するための入り口として使うと、話し合いが前に進みやすくなります。整っていない部分が見つかったときほど、条件を書き出す好機と捉えられます。

割れていること自体が、条件を引き出す材料になります

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

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

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

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

非機能を条件として詰めるときは、相手が何を評価の軸に置いているかを知っておくと、話が噛み合いやすくなります。

利用する側は、品質を最優先の視点に置いています

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

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

評価の視点は、案件によって置き所が変わります

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

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

評価の視点を、条件を引き出す会話に落とし込みます

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

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

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

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

評価の軸が分かったところで、次に見ておきたいのは、確認の自動化がどこまで進んでいるかという前提です。

自動化された確認は、作る側を除くとまだ限られています

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

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

アジャイル開発の広がりも、まだ一部にとどまっています

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

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

自動化が薄い前提こそ、条件を引き出す出番です

自動化された確認が薄い案件は、避けたほうがよい案件というわけではありません。むしろ、確認の仕組みをどう組み立てるかという相談ができる案件と捉えると、自分の経験を生かせる余地が見えてきます。

確認の自動化がどこまで進んでいるかを早い段階で聞いておくと、参画後に想定外の作業が積み上がる事態を防ぎやすくなります。次に言葉にしておきたいのは、この確認をいつ、誰と行うかという条件です。

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

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

定量的な計測とダッシュボードが、出発点になります

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

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

測る土台ができてから、条件を書き出す順番にします

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

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

測る対象を、観点ごとに整理します

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

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

3つの観点をそれぞれ確かめておくと、測る土台がどこまで整っているかを、感覚ではなく事実として相手に示せます。測れる状態を先に作ることが、この記事全体を通じた考え方の軸になります。

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

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

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

継続的なアップデートへの対応が前提になっています

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

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

確認テストの最適化も、続く作業のひとつです

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

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

終わらない前提を、条件として共有しておきます

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

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

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

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

更新への追従と並んで、日々の運用の中で意識しておきたいのが、リソースの使い方です。

ピーク時に備えた余裕を、通常時にそのまま使わない考え方です

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

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

「ピーク」の定義を、最初にそろえておきます

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

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

場面ごとに、確認したい条件を分けます

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

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

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

7. 続ける前提で計画に入れる

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

運用フェーズも含めて、予算と体制と日程を計画します

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

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

書き出しておきたい条件を、まとめます

ここまでの内容を踏まえると、案件に入る前に条件として書き出しておきたい項目が見えてきます。次の図に、その一覧を示します。

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

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

条件を引き出す立場だからこそ、見える案件があります

非機能の条件を引き出す会話ができることは、要件を一方的に決められる立場よりも、むしろ経験を生かせる場面が広がります。曖昧なままの案件ほど、条件を言葉にする力が評価される余地があるからです。

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

非機能の条件は、参画前にどこまで確認しておくといいですか

すべてを事前に確定させる必要はありません。ここで見てきたように、備えの状況や評価の軸、測れる状態の有無、更新への追従の頻度といった前提を、条件として一緒に言葉にできるかどうかが重要です。分からない部分は「分かりません」と伝え、稼働しながら確認していく進め方でも十分に機能します。

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

避ける必要はありません。定量的な計測とダッシュボードによる可視化は、方針として挙げられている取り組みであり⁵、まだ整っていない案件だからこそ、その仕組みを一緒に作る役割を担える余地があります。自分の経験が生きる場面として捉えるほうが、選べる案件の幅も広がります。

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

案件によって異なります。継続的なアップデートへの対応は方針として挙げられており⁶、更新のたびに確認テストを最適化する取り組みも同じ方針の中に含まれています⁸。負担の大きさそのものは案件ごとに幅があるため、稼働頻度や確認の範囲を、参画前の条件として確認しておくと見通しが立てやすくなります。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まる備え（2025年4月）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」確認の自動化（2025年4月）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」混在する現実（2025年4月）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見えるようにする（2026年）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」終わらない作業（2026年）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」常時の余裕（2026年）
＊8 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」テストの費用（2026年）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」整備の差（2025年4月）