SREの案件を受けると、最初に立ち止まるのは技術の難しさではなく、信頼性の目標を誰が決めるのかという点です。何をどこまで測り、どこまでの状態なら許容するのかが、案件の中で明確になっていないまま話が進むことがあります。デジタル庁とIPAの資料には、目標を決めるための材料と、決まっていない現場の実情の両方が示されています。この記事では、測れるものから目標を組み立てていく順番を整理します。

1. 目標を決める人がいないという前提

誰が判断するのかが決まっていない

SREの案件に入って最初に感じる戸惑いは、設計や運用の難しさではなく、判断の所在がはっきりしないことです。信頼性をどこまで守るかを決める役割が、案件の中で誰にも割り振られていないまま作業だけが進むことがあります。

IPAの調査では、意思決定を担う責任者を設置していない企業が約半数に上ります¹⁰。責任者が置かれていない状態は、担当者の力量の問題ではなく、目標そのものがまだ言葉になっていないことの裏返しでもあります。

一方で、利用する側の企業はシステムの品質を最優先事項として捉えています⁸。重視する気持ちは共有されていても、それを具体的な数値や基準に落とし込む役割が空席のままになっているのです。

図の作成：Remogu編集部。目標を決める前後の状態を整理したもので、統計データではありません

現場に判断が寄せられる場面が増える

責任者が明確でない案件では、判断の一部が現場のエンジニアに寄せられる場面が増えます。設計を組み立てる力よりも、決まっていない点を言葉にしてクライアントに投げ返す力が問われる場面です。

抽象的な期待に応えようとするよりも、決まっていない部分を具体的な質問に変えるほうが、話は早く進みます。「品質を守ってください」よりも、「どの状態になったら知らせてほしいか」を尋ねるほうが、クライアントも答えやすいのです。

目標を決める人が明確でない状態を出発点として受け止めると、次に見えてくるのは何を基準に会話を始めるかという点です。次の章では、品質への期待と、どこまで許容するかの決め方の差を具体的に確認します。

2. 「落ちたら困る」と「どこまで許すか」の差

期待は共有されていても基準は別

「落ちたら困る」という感覚は、クライアントとの間でほぼ必ず共有されています。利用する側の企業は、システムの品質を最優先事項として捉えているためです⁸。この点でクライアントと対立することは、まずありません。

問題は次の段階にあります。品質を大切にしたいという気持ちと、どこまでの状態なら受け入れられるかという基準は、別のものです。前者は感覚として共有されやすく、後者は言葉にしないと共有されません。

ITのリスク管理と業務継続計画については、全体の5〜6割程度の企業が整備しています⁷。裏を返せば、整備の度合いは案件によって大きく異なるということです。体制が整っている前提で話を進めると、途中で前提がずれます。

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

整備状況を先に確かめておく

参画前の面談では、案件そのものの技術構成よりも先に、体制の整備状況を確かめる価値があります。整っている前提で受けてしまうと、目標を一から言葉にする作業まで抱え込むことになるためです。

観点	共有されやすい側	言葉にしないと決まらない側
品質への評価	品質を最優先事項として捉えている8	どこまでの状態なら受け入れられるか
体制の整備	整備の必要性そのものは認識されている	全体の5〜6割程度しか整備が進んでいない7
意思決定	品質を重視する方針は伝わっている	誰が最終的に基準を決めるか

表に並べると分かるとおり、左側はクライアントとの間ですでに一致している部分で、右側はこちらから言葉にしなければ埋まらない部分です。次の章では、この右側を測れる形に変えていく考え方を見ていきます。

3. 測れるものから決める

感覚の共有を測れる形に変える

「落ちたら困る」を測れる形に変えるための材料は、すでに示されています。定量的な計測とダッシュボードによる状況の可視化が挙げられています¹。感覚として共有されている期待を、数値で追える指標に置き換える作業です。

指標を決めるより先に、どの状態を「良い」「悪い」と呼ぶのかをクライアントと言葉で合わせておく必要があります。指標だけを先に決めてしまうと、後から「思っていたものと違う」という食い違いが起こりやすくなります。

合わせて、監視対象を見直すことも挙げられています⁵。今の監視が、決めたい目標と噛み合っているとは限りません。目標を先に言葉にしてから、それに合わせて監視の中身を見直す順番のほうが、手戻りが少なくなります。

測れる対象と測れない対象を分ける

測れるものから決めるとは、測れないものを後回しにするという意味ではありません。まず測れる対象を確定させ、測れない部分は「協議で決める領域」として残しておく、という整理です。あいまいさを消すのではなく、あいまいさの置き場所を決めるということです。次の一覧は、可視化の指標と監視の対象、協議で決める領域を分けて並べたものです。

対象	示されている材料	決め方の起点
状況の可視化	定量的な計測とダッシュボードによる可視化1	数値で追える指標を先に並べる
監視の範囲	監視対象を見直すことが挙げられている5	目標に合わせて対象を選び直す
協議で決める領域	示された材料の外にある部分	数値化を急がずクライアントと言葉で合わせる

測れる部分と協議で決める部分を分けておくと、目標の議論が「全部を数値にしなければならない」という重さから解放されます。次の章では、監視の対象そのものをどう見直すかを具体的に見ていきます。

4. 監視の対象を見直す

今の監視が目標と噛み合っているか

監視の対象を見直すことは、単に監視項目を増やす作業ではありません⁵。今の監視が、決めたい目標に対して意味のある情報を返しているかを確かめる作業です。項目数の多さと、目標との噛み合いは別の話です。

既存の案件に途中から参画する場合、監視の設定は前任者が組んだものであることが多く、目標が決まった後にあらためて見ると、測りたいものと測っているものがずれていることがあります。項目を足すよりも、まず今ある監視の目的を確かめるほうが早い場合もあります。

あわせて、運用作業の自動化を徹底することも挙げられています⁶。監視を見直した後は、対応そのものを人手に頼る範囲を減らし、決めた基準に沿って自動で動く部分を増やしていく流れになります。

図の作成：Remogu編集部。監視の対象を見直す一般的な流れを整理したもので、個別の案件の手順を示すものではありません

見直しは一度で終わらない

監視の対象は、一度決めたら固定するものではありません。目標そのものが運用の中で調整されていくため、監視の中身もそれに合わせて動きます。見直しを一度きりの作業と考えると、次に触れる章の内容とずれが生じます。

参画したばかりの立場では、既存の監視設定に手を入れることに慎重になりがちです。まずは「なぜこの項目を測っているのか」をクライアントに確かめるところから始めると、見直しの理由を後から説明しやすくなります。

監視の対象を見直す作業は、一度で完成させるものではなく、繰り返す前提のものです。次の章では、この繰り返しを予算や日程にどう織り込んでおくかを見ていきます。

5. 改善を続ける前提で計画する

完成の日を決めない計画

信頼性の目標は、一度決めて終わりにできるものではありません。運用の段階も含めて日々改善していくことを前提に、予算や体制、日程を計画する必要があります²。完成の日を先に決めてしまう計画とは、前提が異なります。

言い換えると、リリース後の改善期間を「余ったら使う時間」ではなく、最初から計画に組み込んでおく時間として扱うということです。日程表に改善の枠が一行も無い案件は、この前提とかみ合っていない可能性があります。

この考え方は、刷新すること自体を目的にした計画とも相性がよくありません。システムの運用が従前のままでは、コスト削減の効果は十分に出ません⁹。作り替えても、運用のやり方まで変えなければ、期待した結果には届かないということです。

計画に改善の時間を組み込む

参画する側から見ると、この前提は日程の交渉材料になります。改善の時間が計画に含まれているかどうかを、参画前に確かめておく価値があるということです。含まれていない場合は、後から時間を捻出する交渉が発生しやすくなります。

前提	示されている考え方	案件で確かめる点
予算・体制・日程	運用の段階も含めて日々改善していく前提で計画する2	改善のための時間が日程表に含まれているか
刷新と運用の関係	運用が従前のままだとコスト削減効果は十分に出ない9	刷新後に運用のやり方がどう変わるか
改善の続け方	目標そのものを繰り返し調整する前提	誰が改善の要否を判断するか

計画の段階でこれらを確かめておくと、途中で時間が確保できていないと気づいてから慌てる場面を減らせます。次の章では、改善の中でも特に日常的に発生する更新への向き合い方を見ていきます。

6. 更新は日常の作業になる

更新をイベントにしない

信頼性の目標を守り続けるうえで、更新の扱い方は見落とされやすい部分です。通常のアップデートと捉えて日常的に対応していく必要があると示されています³。更新を特別な作業として構えるほど、対応が後手に回りやすくなります。

継続的なアップデートへの対応も、あわせて挙げられています⁴。一度きりの大きな対応ではなく、小さな対応を積み重ねる前提です。積み重ねる前提と、まとめて対応する前提とでは、日々の進め方がまったく違います。

更新を日常の作業として扱う案件では、対応の頻度やタイミングがあらかじめ決まっていることが多く、突発的な作業として扱う案件では、都度クライアントと調整するところから始まります。どちらの前提かは、参画前の面談で確かめられる点です。

日常化すると振り返りやすくなる

更新を日常の作業として組み込んでおくと、目標を測る指標にも変化が反映されやすくなります。イベントとして扱っていると、更新の影響が数値のどこに出たのかを後からたどりにくくなります。

これは、これまで積み上げてきた運用の経験を活かせる領域でもあります。頻度の高い作業ほど、手順を型にして残しておく価値があり、型を作れる人ほど、次の案件でも同じ考え方を持ち込めます。

更新を特別な作業ではなく日常の作業として扱えるようになると、目標を決める作業そのものにも余裕が生まれます。最後の章では、ここまで見てきた要素をどの順番で決めていくかを整理します。

7. 目標を決める順番

材料をどの順で並べるか

ここまで見てきた材料を順番に並べ直すと、目標の決め方が見えてきます。まず、定量的な計測とダッシュボードによる状況の可視化を起点にします¹。数値で追える指標がなければ、どこまで許容するかの話も始まりません。

指標が決まったら、どこまでの状態を許容するかの範囲を言葉にします。次に、その指標に合わせて監視の対象を選び直します。最後に、運用の段階も含めて日々改善していく前提で、予算と体制と日程の計画に組み込みます²。

図の作成：Remogu編集部。目標を決める段階の順番を整理したもので、統計データではありません

この順番を面談の段階から共有しておくと、参画後に「誰が何を決めるのか」で立ち止まる時間が減ります。Remoguが扱う案件は、90%以上がフルリモートで進められる案件です。場所に縛られず、この順番を積み上げていく働き方を選べます。

信頼性の目標は自分から提案してよいのですか

提案すること自体は問題ありません。利用する側の企業は品質を最優先事項として捉えているため⁸、測れる指標の案を持ち込むと、話が前に進みやすくなります。最終的な基準はクライアントとの協議で決めるものとして扱ってください。

監視の対象はどのくらいの頻度で見直すものですか

決まった頻度はなく、目標や運用の状況に応じて見直す性質のものです⁵。更新への対応を日常の作業として捉える考え方³と同じで、まとめて一度に見直すよりも、小さな見直しを重ねるほうが状況に合わせやすくなります。

経験がまだ少ない案件でも目標を決める議論に加われますか

加われます。目標を決める議論は経験の長さよりも、測れる指標を具体的に言葉にできるかどうかで進みます。まず自分に近い経験の案件を確かめてみることが、最初の一歩になります。

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

出典・参考情報

＊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 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」刷新の限界（2026年・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人（2025年4月・2026年8月確認）