Linuxでサーバを構築し、障害時の復旧手順を整え、日々のログを運用してきた経験は、案件の打診を受けるたびに「構築しました」「監視していました」という作業名に置き換わっていきます。作業名だけを並べても、そこにあった判断の重さまでは伝わりません。非機能要件の標準は、可用性やログといった項目ごとに、選択できるレベルと、そのレベルを選ぶための条件を用意しています。この記事では、その物差しを使って経験を語り直す考え方を整理します。

1. 構築の作業名を並べても、経験は伝わらない

「構築した」「監視した」という自己紹介の限界

案件の打診を受けて経歴を尋ねられ、担当してきた作業をそのまま並べて答える場面は多いはずです。「Webサーバを構築しました」「死活監視の仕組みを組みました」という説明は、事実として正確でも、聞き手には作業の量しか伝わりません。

相手が本当に知りたいのは、何を選び、何を選ばなかったかという判断の中身です。同じ「バックアップを組んだ」という経験でも、どこまで戻す設計にしたかという選択が語られて初めて、その裏にあった判断の重さが伝わります。

この物差しとして使えるのが、非機能要件を項目ごとに整理した標準です。作業名の代わりに、標準が示す選択の軸に沿って経験を並べ直すと、これまで積み上げてきた経歴が、違う言葉で伝わり始めます。

面談でも同じ違いが表れます。「構築しました」で止まると、次の質問は作業の手順を掘り下げるものになり、話が技術要素の羅列で終わりがちです。一方、選んだレベルとその理由から語り始めると、質問は「その判断は他の条件でも通用しますか」という判断の再現性を確かめる方向に変わり、任せられる範囲の話へと進みます。

標準が示すのは「選ぶもの」という発想

非機能要件の標準は、可用性やセキュリティ、移行性といった項目ごとに、複数の選択レベルと、そのレベルを選ぶための条件を用意しています。水準を一つに固定して終わりにする作りではなく、案件ごとに選び直すことを前提に設計されている点が特徴です。

「高い水準を実現した経験」よりも「その水準を選んだ条件を説明できる経験」のほうが、判断力の証明になります。作業の完了報告として語るのではなく、選択の理由を語る準備をしておくと、経歴の伝わり方は大きく変わります。

図にすると、この違いがはっきりします。可用性やセキュリティ、移行性という別々の項目に見えても、語るべき中身は同じ一つの考え方に集約されます。

図の作成：Remogu編集部。非機能要件の標準の考え方を整理したもので、統計データではありません

2. どこまで戻すかを決めると、後ろの設計が決まる

RPOという物差しが示すもの

可用性の継続性という項目には、RPO(目標復旧地点)という考え方が置かれています。これは、バックアップしたデータなどから情報システムをどの時点まで復旧するかを定める目標値です¹。

「なんとなく毎日バックアップを取っている」状態と、「1営業日前まで戻すと決めている」状態は、同じ作業でも意味が違います。後者は、復旧にかかる時間や許容できる損失を先に見積もった上での選択だからです。

標準に示された選択レベルの一つには、「1営業日前の時点(日次バックアップからの復旧)」があります。このレベルを選ぶと、バックアップの頻度・装置・ソフトウェア構成などを決めるために必要な情報が定まっていきます²。

選んだレベルが、後ろの設計を全部決めていく

RPOのレベルを先に決めるという順番を知っていると、担当した仕事を「指示された設定を入れました」ではなく、「この復旧地点を実現するために、この頻度とこの構成を選びました」という一続きの説明に変えられます。

「バックアップを取った経験」よりも「どの地点まで戻すかを決めた上でバックアップを設計した経験」のほうが、次の案件でクライアントと条件を協議するときの材料になります。順番を押さえているかどうかで、同じ経験の見え方が変わります。

決める順番を先に固定する

どこから手を付けるかを先に決めておくと、以降の設計判断が芋づる式に進みます。戻す地点を最初に決め、そこから頻度、装置、ソフトウェア構成の順に落とし込む流れを一覧にしておくと、経験を語るときの骨組みにもなります。以下の表は、その順番を整理したものです。

順番	決めること	次に何を左右するか
1	どの時点まで戻すか(RPOの選択レベル)	バックアップを取る頻度が決まる
2	バックアップの頻度	使う装置や仕組みの規模が決まる
3	装置・仕組みの規模	ソフトウェア構成が決まる
4	ソフトウェア構成	復旧までの具体的な手順が固まる

3. 決まっていない値は、別の値から導く

「決められない」で終わらせない発想

RPOと並ぶもう一つの目標値がRTO(目標復旧時間)です。案件によっては、この数値がSLAとして明確に定められていないクラウドサービスを扱う場面もあります。

そこで標準が示しているのが、決まっていない値を、決まっている別の値から導く方法です。目標復旧時間をSLAに定めていないクラウドサービスを利用する場合には、示された稼働率をもとに業務停止時間の最大値を算出し、RTOを検討する進め方が示されています³。

「分からないので決められません」ではなく、「この数値から、この手順で導きました」と語れることが、経験の厚みになります。稼働率の具体的な数字は案件ごとに異なるため、ここで大切なのは数値そのものではなく、導く手順を持っているかどうかです。次の案件でも、この手順があれば数値が示されていない場面に落ち着いて対応できます。

導く手順を持っている人は、案件の打診の段階で「数値が示されていない項目に出会ったら、どう進めますか」と尋ねられることがあります。答え方の型は、まず仕様書やSLAの中にすでに示されている値を探し、次にその値から導ける範囲を洗い出し、最後にどの前提で導いたかを記録に残す、という順番です。この順番を説明できると、都度確認するだけの対応ではなく、任せられる判断として伝わります。

図の作成：Remogu編集部。標準が示す手順の考え方を整理したもので、統計データではありません

4. 水準は、高くしておけばよいわけではない

外部にデータがあるなら、レベルは下げて考えられる

運用・保守性の項目には、「外部データの利用可否」という観点があります。これは、外部データによってシステムのデータが復旧可能かどうかを確認するための項目です⁴。

外部データによってデータの復旧が可能な場合は、検討の優先度やレベルを下げて考えることができます⁵。自分のシステムの外側に復旧の手がかりがあるかどうかを、先に確認しておく価値がここにあります。

「水準を高く保った経験」よりも「条件を見てレベルを下げると判断した経験」のほうが、コストと必要性のバランスを見る力の証明になります。高い水準を選ばなかった理由を説明できることは、経験の不足ではなく判断の跡です。

レベルを下げる判断は、説明の仕方によっては手を抜いたと受け取られることがあります。そこで添えたいのが、下げてよいと確認した事実です。「外部のどこに、どの形でデータが残っているかを確認した上で、その分だけレベルを下げました」と語れば、判断の質は落ちません。この確認は、参画して間もない段階で、クライアントや前任の担当者に既存のバックアップ体制を尋ねておくと進めやすくなります。

上げる条件と下げる条件を並べて語る

レベルは、上げて考える条件と下げて考える条件をセットで押さえておくと、案件ごとの判断がぶれません。以下の表は、この記事で扱った観点について、レベルを上げて考える場面と下げて考える場面を並べたものです。

観点	レベルを上げて考える条件	レベルを下げて考える条件
復旧の手がかり	外部に同じデータを持つ仕組みがない	外部データでシステムのデータが復旧できる
戻す地点(RPO)	直近までの状態を戻す必要がある	ある程度前の状態からでも復旧を許容できる
停止の許容時間	停止時間を短く抑える必要がある	停止時間にある程度の幅を持たせられる

図の作成：Remogu編集部。レベルを上下させる条件の考え方を整理したもので、統計データではありません

5. ログは「取る」と「見る」を分けて決める

取得と確認は、別の意思決定

セキュリティの不正追跡・監視の項目では、どのようなログを取得するかは、実現する情報システムやサービスに応じて決定する必要があります⁶。全部のログを一律に取ればよい、という話ではありません。

さらに標準は、ログを取得する場合には、取得したログのうち確認する範囲を定める必要があるとも示しています⁷。「取る」だけでなく「見る」範囲まで決める視点が、運用経験の解像度を上げます。

「すべてのログを漏れなく確認していました」という語り方よりも、「確認する範囲をこの基準で絞りました」と語れるほうが、優先順位をつけられる経験として伝わります。取得と確認を分けて考えていたかどうかは、経歴を語るときに意外と抜け落ちる視点です。

取る範囲と見る範囲を分けておくと、日々の運用も変わります。確認する範囲に入らないログは、異常が起きない限り目を通さない前提で扱い、日常の点検は定めた範囲だけに絞れます。この絞り込みがないと、点検が際限なく広がりがちです。もう一つ効くのが、確認する範囲をどう決めたかという記録です。後になって障害対応の場面で理由を尋ねられても、当時の条件を記録に残していれば、選んだ理由をそのまま示せます。

移行も、経験を語る材料になる

移行性の項目には移行対象(機器)という観点があり、移行前の情報システムで使用していた設備のうち、新システムで新たな設備に入れ替える対象となる設備を指します⁸。

構築や運用だけでなく、何を引き継ぎ、何を切り替えたかという移行時の判断も、Linuxで積み上げてきた経験の一部として語れます。移行は一度きりの作業に見えて、実は判断の連続です。

経験を4つの層に分けて書き出す

構築・復旧設計・ログ運用・移行という4つの層に経験を分けて書き出すと、作業の羅列だったものが判断の記録に変わります。以下の表は、それぞれの層で語るべき視点を整理したものです。

層	例	語り方
構築	OSやミドルウェアの導入、初期設定	何を選び、何を選ばなかったか
復旧設計	RPO・RTOの検討、バックアップ設計	どの条件でレベルを決めたか
ログ運用	取得範囲と確認範囲の設計	何を見て、何を見ないと決めたか
移行	新旧設備の入れ替え対応	何を引き継ぎ、何を切り替えたか

図の作成：Remogu編集部。ログの取得範囲と確認範囲の考え方を整理したもので、統計データではありません

6. まとめ

Linuxの案件で問われているのは、高い水準を実現したかどうかではなく、その水準を選んだ理由を語れるかどうかです。非機能要件の標準が示す選択レベルと条件という物差しに沿って経験を並べ直すと、作業の一覧が判断の記録に変わります。

戻す地点を先に決め、そこから頻度・装置・構成を決めていく順番、決まっていない値を別の値から導く手順、レベルを下げて考えてよい条件、ログを取る範囲と見る範囲を分ける視点。この4つを押さえておけば、次の案件の打診でも、作業名ではなく判断を語れます。

場所に縛られず、積み上げてきた判断の経験をそのまま活かしたいと考えるなら、Remoguが扱うリモート案件はその選択肢になります。Remoguが扱う案件は90%以上がフルリモート可能です⁹。まずは自分の経験がどのレベルの話として伝わるか、案件の条件と合わせて確かめてみましょう。

7. よくある質問

構築が終わったら、関わる余地はなくなるのか

構築は最初の1回で区切りがつきますが、運用・保守性や不正追跡・監視、移行性といった項目は、稼働してからも判断が続く領域です。ログの確認範囲を見直したり、移行のタイミングで設備を入れ替えたりする場面では、構築時とは別の判断が必要になります。関わる余地がなくなるどころか、構築後の経験のほうが選択の幅は広がります。

自治体向けの標準は、民間の案件でも参考になるのか

ここで紹介した標準は、地方公共団体の業務システムを対象に整理されたものです¹。制度としての適用範囲は自治体向けですが、可用性やログ、移行性といった項目ごとに選択レベルと条件を用意するという考え方そのものは、民間の案件で経験を整理するときの物差しとしても使えます。制度の対象と、考え方の使いどころは分けて捉えておくと混同がありません。

クラウドに移るとLinuxの経験は不要になるのか

標準の中でも、目標復旧時間をSLAに定めていないクラウドサービスでは、示された稼働率から業務停止時間の最大値を算出してRTOを検討する進め方が示されています³。これは、クラウド環境でも復旧の目標値を自分で導く判断が必要な場面があることを示しています。基盤の置き場所が変わっても、選択レベルを考える経験そのものは引き継がれます。

決めた理由が記録に残っていない場合はどうするか

記録が残っていなくても、当時の条件を思い出しながら、どの選択レベルを選んだか、なぜそのレベルにしたかを今から言葉にしておくことができます。次の案件の打診に備えて、構築・復旧設計・ログ運用・移行という4つの層ごとに判断の理由を書き出しておくと、経歴の説明にそのまま使えるようになります。

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

出典・参考情報

＊1 デジタル庁「地方公共団体情報システム非機能要件の標準」A.1.3.1 可用性／継続性／RPO（目標復旧地点）（業務停止時）（2025年9月）
＊2 デジタル庁「地方公共団体情報システム非機能要件の標準」A.1.3.1 選択レベル2（2025年9月）
＊3 デジタル庁「地方公共団体情報システム非機能要件の標準」A.1.3.2 可用性／継続性／RTO（目標復旧時間）（業務停止時）（2025年9月）
＊4 デジタル庁「地方公共団体情報システム非機能要件の標準」C.1.2.2 運用・保守性／通常運用／外部データの利用可否（2025年9月）
＊5 デジタル庁「地方公共団体情報システム非機能要件の標準」C.1.2.2 注意事項（2025年9月）
＊6 デジタル庁「地方公共団体情報システム非機能要件の標準」E.7.1.1 セキュリティ／不正追跡・監視／ログの取得（2025年9月）
＊7 デジタル庁「地方公共団体情報システム非機能要件の標準」E.7.1.1 ログの取得（続き）（2025年9月）
＊8 デジタル庁「地方公共団体情報システム非機能要件の標準」D.3.1.1 移行性／移行対象（機器）（2025年9月）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）