サーバー・インフラ構築のポートフォリオの作り方｜見る人が知りたいこと

サーバー・インフラ構築のポートフォリオを作ろうとして、最初に手が止まる人は多いです。Webサイトやデザインなら完成品を見せれば済みますが、サーバーの構築は「動いている」以外に見せるものがありません。結論から書くと、インフラのポートフォリオで評価されるのは成果物そのものではなく、判断の記録です。何を作ったかより、なぜその構成にしたかを説明できるかどうかで見られています。

この記事では、守秘義務を守りながら何を出せるのか、どんな題材を選べばよいのか、ドキュメントに何を書けばよいのかを、順番に整理します。これ、知らないまま作り始めて時間を無駄にしている人が本当に多いのです。

インフラのポートフォリオが難しい理由

まず、難しさの中身を分解します。原因が分かれば、対処も決まります。

成果物が画面に出ない

Webサイトの制作なら、URLを渡せば相手が見て判断できます。インフラの構築は、正常に動いている状態が見えるだけで、その裏にある設計は表に出ません。

インフラエンジニアのポートフォリオは、成果物を動作する形で示すのが難しいです。そのため、環境設定をまとめたドキュメントを作成したり、クラウドでサーバーを構築したりして、スキルを提示します。また、構築した環境設定をGitHubに公開するのも有効です。 出典: career.levtech.jp

ここに書かれている通り、代替手段は文書とコードです。動くものを見せるのではなく、作る過程を見せるという発想の転換が必要になります。この転換ができていない人は、動くサイトを作ることに時間を使い、肝心の設計の説明を残さないまま終わります。

業務で作ったものは基本的に出せない

実務経験がある人ほど「一番良い仕事は見せられない」という問題に直面します。業務委託契約には秘密保持の条項が入っているのが通常で、構成図やIPアドレスの体系、使用しているソフトウェアの版数までが秘密情報に該当することがあります。

つまり、業務での成果をそのまま出すことは基本的にできません。ここを軽く考えて、前の案件の構成図をそのまま載せてしまう人がいますが、これは契約違反にあたる可能性があります。※契約書の秘密保持条項の解釈に迷う場合は、契約書を持参して専門家に確認することをおすすめします。

見る人が技術者とは限らない

ポートフォリオを見るのは、必ずしも同じ領域の技術者ではありません。発注担当者、人事担当者、別領域のエンジニアが見ることもあります。専門用語だけで構成された文書は、読める人を選びすぎて機会を減らします。

読み手を1人に絞る必要はありません。冒頭は誰でも読める言葉で書き、詳細は技術者向けに書く。この二段構えにしておけば、どちらの読み手にも対応できます。

見る人が知りたい4つのこと

ポートフォリオを評価する側が確認したいことは、おおむね4つに絞られます。この4つに答える構成にすれば、内容は自然に決まります。

何を扱えるのか

対応できる技術の範囲です。OSは何を扱えるのか、クラウドはどのサービスを使えるのか、ネットワークの設定はどこまでできるのか。

ここで大事なのは、扱える範囲を正直に書くことです。触ったことがある程度のものを「経験あり」と書くと、面談で確認されたときに崩れます。「業務で運用した」「学習として構築した」「調査したことがある」の3段階に分けて書くと、誠実さが伝わり、かつ範囲も広く見せられます。

なぜその構成にしたのか

最も見られているのがここです。同じ要件でも、選べる構成は複数あります。その中からなぜそれを選んだのかを説明できる人は、判断する立場を任せられます。

構成図だけを載せて説明がないポートフォリオは、手順書を見ながら作った成果物と区別がつきません。逆に、検討して見送った案を書いてあると、それだけで印象が変わります。「可用性を優先するならこの構成もあったが、費用の制約とこの用途を考えてこちらにした」という一文が、判断の経験を示します。

壊れたときにどうするのか

運用の観点があるかどうかは、実務経験の有無を分ける項目です。作ることしか考えていない構成は、見る人にすぐ分かります。

バックアップをどう取るのか、障害が起きたらどう気づくのか、復旧の手順はどうなっているのか。この3点に触れていれば、運用を意識できる人だと判断されます。実際に復旧を試した記録があれば、さらに強くなります。

人に説明できるのか

ポートフォリオそのものが、説明能力の証拠になります。読んで理解できる文書を書ける人は、現場でも設計書や報告書を書けると判断されます。

インフラの仕事は、社内の関係者やほかのベンダーとの調整が多い領域です。技術的に正しいことを、非技術者にも伝わる形で説明できるかどうかが、実務では大きな差になります。ポートフォリオはその能力を見せる場でもあります。

守秘義務との線引き

実務経験を持つ人が最初に整理すべきなのが、何なら出せるかという線引きです。

出せない情報

固有名詞は出せません。顧客名、システム名、ドメイン名、IPアドレス、機器の型番と台数、契約に関わる金額。これらは秘密情報として扱われるのが通常です。

構成図もそのままでは出せません。構成そのものが、その企業のシステムの弱点を示す情報になるためです。図を出したい場合は、実物ではなく同種の構成を自分で作り直したものを使います。

出せる情報

担当した工程、扱った技術の種類、直面した課題の類型、そこで採った対処の方針。これらは抽象化すれば出せます。

書き方の例としては、「金融系の顧客」ではなく「利用者数の多い業務システム」、「サーバー20台」ではなく「複数台構成」といった形になります。規模感を伝えたいなら、台数ではなく「単一障害点を排除した構成」といった性質で表現します。

判断に迷う場合は、契約先に確認を取ります。「経歴として、技術の種類と担当工程のみを記載したい」と伝えて許可を得ておけば、後の心配がなくなります。断られることは、経験上そう多くありません。

検証環境を自分で作るのが最も安全

結局のところ、自分で作った環境なら制約がありません。業務で得た知識を使って、自分の環境で同じ課題を解く。これが最も自由度が高く、説明もしやすい方法です。

業務で扱った構成を、規模を落として自分の環境で再現する。この作業自体が学習にもなりますし、出せるポートフォリオにもなります。実務経験のある人ほど、この方法の効率が良い。

作る題材の選び方

ゼロから作る場合、何を作るかで評価が変わります。難しいものを作れば良いというわけではありません。

クラウド上に小さな環境を作る

クラウドサービスの上にサーバーを立て、簡単なサイトやアプリケーションを動かす形が基本形です。オンプレミスの環境を自宅に用意するより、費用も手間も抑えられます。

AWSやGoogleCloud、Microsoft Azureなどのクラウドサービスを使って、サーバーを構築し、簡単なサイトやブログを公開する方法があります。

昨今サーバーをオンプレミスからクラウドへ移行する企業が増えています。そのため、クラウド上でサーバー構築する能力があると転職で有効です。 出典: career.levtech.jp

企業側の移行需要が続いている以上、クラウド上での構築経験は評価の対象になります。ただし、単に立てただけでは差がつきません。差がつくのは、この後に書く要素を含めているかどうかです。

構成をコードで管理する

管理画面から手作業で作った環境は、再現できません。構成をコードとして記述し、そのコードを公開すると、作業の再現性を示せます。

コードがあることの意味は2つあります。1つは、同じ環境をもう一度作れること。もう1つは、変更の履歴が残ることです。履歴を見れば、どういう順序で考えを進めたかが分かります。これは判断の記録そのものです。

監視と通知まで含める

構築だけで終わっているポートフォリオは多く、監視まで入っているものは少ない。ここが差別化の要素になります。

サーバーの状態を監視し、閾値を超えたら通知が飛ぶところまで作ります。閾値をなぜその値にしたかを書いておけば、運用の視点があることを示せます。通知の内容が具体的であること、鳴りすぎない設計になっていることも評価されます。

復旧のシナリオを1つ用意する

意図的に障害を起こし、復旧させる。この記録があるポートフォリオは強い。サービスを停止させた状態から復旧させる、バックアップから戻す、といった単純なもので構いません。

記録には、何をしたら何が起きたか、どこで気づいたか、どう戻したか、何分かかったかを書きます。作ることだけでなく戻せることまで示せる人は、実務でも安心して任せられます。

ドキュメントに何を書くか

ポートフォリオの中身は、ほとんどが文書です。構成は次の形が扱いやすい。

冒頭に「何を作ったか」を数行で書く

読む人は、最初の数行で読み進めるかどうかを決めます。技術の詳細から始めると、多くの読み手が離脱します。

「利用者が数十人規模の業務アプリケーションを想定し、可用性と費用のバランスを取った構成を作りました」といった要約を最初に置きます。誰が読んでも意味が分かる言葉で書くのがポイントです。

構成図は論理と物理を分ける

構成図を1枚で済ませようとすると、どちらの用途にも使えない図になります。通信の経路や名前解決の流れを示す論理構成図と、機器やインスタンスの実体を示す物理構成図は、読む場面が違います。

図の作成に高価なツールは要りません。線と四角で描かれた図でも、情報が整理されていれば伝わります。逆に、装飾に凝った図で情報が整理されていない場合、その点が評価されます。

設計判断のメモを付ける

構成図の隣に、判断の記録を置きます。要件、選択肢、選んだ案、選んだ理由、見送った理由。この5項目を1つずつ書きます。

判断が3つか4つ書いてあれば十分です。全ての設定について書く必要はありません。むしろ、重要な判断を選び出せること自体が能力の証明になります。

手順書は再現できる粒度で書く

第三者が読んで同じ環境を作れる粒度で書きます。自分の記憶を補うためのメモは、他人には読めません。

前提となる環境、必要な権限、実行するコマンド、確認する項目。この4つが揃っていれば再現できます。手順書の品質は、実務での文書作成能力をそのまま示します。文書の型を体系的に押さえたい場合は、ビジネス文書検定が扱う構成や表記のルールが土台になります。

費用の考え方に触れる

クラウドを使った構成では、費用の話に触れているかどうかが実務感覚の指標になります。同じ要件を満たす構成でも、費用は選択によって変わります。

費用を抑えるためにどこを妥協したか、逆にどこには費用をかけたか。この判断が書かれていると、企業の予算の中で仕事をする人だと分かります。技術的に最良の構成を作れることより、制約の中で妥当な構成を作れることのほうが、実務では求められます。

公開の方法

作ったものをどこに置くかも考えておきます。

コードと文書はGitHubに置く

構成のコードと文書を、まとめて公開の場所に置きます。履歴が残ること、URLひとつで渡せること、更新が反映されることが利点です。

置くときの注意点は、認証情報が混入していないかの確認です。設定ファイルの中に鍵やパスワードが残ったまま公開する事故は、実際によく起きています。公開前に、履歴を含めて確認します。一度公開した情報は、消しても残っていると考えるべきです。

記事として書き直す

同じ内容を、読み物として書き直すのも有効です。構築の過程で詰まった箇所、調べて分かったこと、次はこうすると書いた反省。これらを含めた記事は、判断の過程が見えるため評価されやすい。

文章にすると、自分の理解が曖昧な箇所が浮かび上がります。書けない部分は、理解していない部分です。ポートフォリオの作成は、学習の手段としても機能します。

動く環境を維持し続ける必要はない

実際にアクセスできるURLがあると分かりやすいのは事実ですが、維持には費用がかかり続けます。学習用の環境を何年も動かし続ける必要はありません。

構築の記録、画面の記録、コードが残っていれば説明はできます。「費用の観点から現在は停止していますが、コードから再構築できます」と書いてあれば、むしろ費用感覚がある人だと受け取られます。

よくある失敗

作ったものが評価されない場合、原因は決まっています。

手順書をなぞっただけになっている

公開されている構築手順をそのまま実行し、動いたところで終わっているポートフォリオは、すぐに分かります。判断の記録がないためです。

同じ題材でも、要件を自分で設定し、選択肢を比較して選んだ過程が書かれていれば評価は変わります。技術の難易度ではなく、思考の過程が見られています。

構成を盛りすぎている

小規模な用途に対して、過剰な冗長構成や複雑な仕組みを組み込んだポートフォリオは、逆に評価が下がります。実務では、要件に対して過剰な構成はコストの無駄と判断されるためです。

規模に見合った構成を選び、その理由を書く。この判断ができる人のほうが、実務では信頼されます。

更新が止まっている

数年前に作ったまま放置されているポートフォリオは、古い技術の記録になります。クラウドサービスの機能は変わり続けるため、古い構成は現在の推奨と異なることがあります。

全面的に作り直す必要はありません。「この時点での構成です」と時期を明記し、現在なら別の選択もあると1行添えるだけで、状況を把握している人だと分かります。

認証情報や個人情報が残っている

公開したコードや設定ファイルに、鍵やパスワード、自分の環境の識別子が残っている例は少なくありません。技術的な失点であるだけでなく、情報の扱いが雑な人だという評価に直結します。

公開前の確認は、現在のファイルだけでなく変更の履歴も含めて行います。一度削除しても履歴には残るためです。設定値を外部から読み込む形にし、実際の値は公開しない構成にしておけば、この事故は起きません。この設計にしていること自体が、実務で情報を扱える人だという証明になります。

経歴書との整合が取れていない

ポートフォリオと経歴書で、扱える技術の記述がずれている例も見かけます。経歴書に書いていない技術がポートフォリオに出てくるのは問題ありませんが、逆は不自然に見えます。

両方を同時に見直し、記述を揃えておきます。細部の整合が取れている書類は、それだけで丁寧な仕事をする人だという印象を作ります。

実務経験が少ない状態から作り始める場合

未経験や経験の浅い状態から作る場合、進め方が変わります。いきなり大きなものを作ろうとすると、途中で止まります。

小さく作って必ず1つ完成させる

最初の1つは、規模を絞って完成まで持っていきます。サーバーを1台立て、Webサーバーを動かし、証明書を設定し、監視を入れ、バックアップを取る。この範囲で十分です。

完成の定義を先に決めておくのがポイントです。「監視の通知が実際に届いたら完成」といった形で、達成の判定ができる基準を置きます。基準がないと、際限なく機能を足し続けて完成しません。未完成のものが複数ある状態より、小さくても完成したものが1つあるほうが評価されます。

2つめで規模ではなく観点を変える

1つめが完成したら、2つめは規模を大きくするのではなく、観点を変えます。1つめが構築中心なら、2つめは移行や切替を題材にする。1つめが単一のサーバーなら、2つめは複数台の構成にする。

観点を変えると、扱う判断の種類が増えます。判断の種類が増えることが、対応できる範囲の広さを示します。同じことを大きくやり直しても、示せる判断は増えません。

費用を抑える工夫を記録に残す

学習用の環境は、費用を抑える設計が必要です。使わない時間帯は停止する、無料枠の範囲で組む、検証が終わったら削除する。

この工夫自体が、記録として価値を持ちます。企業の環境でも、費用の最適化は常に求められる観点です。「学習用のため使用時間外は自動停止する設定にした」と書いてあれば、費用を意識する人だと分かります。

ポートフォリオと一緒に用意する書類

ポートフォリオ単体では、案件の獲得には繋がりません。周辺の書類と揃って機能します。

経歴書には担当工程を書く

経歴書で見られるのは、参加したプロジェクトの規模ではなく、その中で何を担当したかです。「大規模システムの構築に参画」とだけ書かれた記述は、評価の材料になりません。

担当した工程を明示し、判断した内容を1行添えます。使用した技術の羅列より、判断の記述のほうが評価されます。技術の名前は誰でも書けますが、判断の内容は実際に担当した人しか書けないためです。

スキルの記載は3段階に分ける

扱える技術の一覧は、経験の濃さを分けて書きます。業務で運用した、学習として構築した、調査したことがある。この3段階です。

段階を分けると、範囲を広く見せながら誠実さも保てます。全てを「経験あり」と書くと、面談での確認で崩れます。崩れた場合、その技術の話だけでなく、書類全体の信頼が下がります。

稼働の条件を先に書いておく

在宅で受ける場合、稼働できる時間帯、対応可能な曜日、緊急時の対応可否を書いておきます。書いていないと、面談のたびに同じ確認が発生します。

条件を先に出すと機会が減るように見えますが、実際は逆です。条件が合わない相手との面談が減り、合う相手との話が早く進みます。この整理は、案件の探し方にも関わります。サーバー・インフラ構築・保守のお仕事のような募集情報で、実際にどんな稼働条件が求められているかを確認しておくと、書き方の基準が決まります。

面談での使い方

作ったポートフォリオは、渡して終わりではありません。面談で説明する場面が本番です。

説明の順序は、結論、根拠、補足の順にします。「どういう要件を想定し、こういう構成にしました。理由はこれです」と先に言い切り、詳細は聞かれてから話します。作った順に説明を始めると、聞く側は途中で全体像を見失います。

想定される質問は決まっています。なぜこの構成にしたか、他の選択肢は検討したか、障害が起きたらどうするか、費用はどれくらいか、実務ではどう応用できるか。この5つに即答できる状態にしておけば、面談は成立します。

インフラ領域の面談では、ネットワークの基礎知識も確認されます。CCNA（シスコ技術者認定）の学習範囲は、経路や機器の話を自分の言葉で説明する土台になります。認定そのものより、質問に答えられることのほうが評価されます。

市場を長く見てきた立場からの観察

フリーランスと在宅ワークの市場を20年運営してきた立場から言えば、選ばれる人のポートフォリオは、規模が大きいものではありません。読んで意図が分かるものです。読み手の時間を奪わない文書を作れる人は、仕事でも同じことができると判断されます。

運営者として見てきた限りでは、長く続く人ほど、単発の作業ではなく「この人に任せると楽」という関係づくりに時間を使っています。ポートフォリオは、その関係の入り口です。技術力の証明としてだけでなく、一緒に仕事をしたときの体験を先に見せる資料として作ると、内容の優先順位が変わります。

もう1つ、中間マージンが乗らない直接取引について触れておきます。仲介の手数料が差し引かれない取引では、依頼者が払った額がそのまま受け手に届きます。同じ予算で依頼者はより多く頼めるため、依頼の頻度も上がります。手数料0%の意味は金額の大小より、手取りが厚くなることで学習や資料作成に時間を回せるという点にあります。

案件の全体像を把握しておくと、ポートフォリオに何を含めるべきかも決まります。サーバー・インフラ構築・保守のお仕事では、構築と保守を含む在宅の業務委託がどう募集されているかを確認できます。求められている工程が分かれば、見せるべき経験も絞れます。

隣接する領域の見せ方も参考になります。UI/UXデザインのフリーランスになるには？必要スキルと案件相場では、成果物が目に見える職種でのポートフォリオの考え方を扱っています。見せ方の違いを知っておくと、インフラ領域で何を補うべきかが分かります。

経験を積んでから独立する人にとっても、ポートフォリオは必要です。定年後のフリーランス独立｜退職金を活かした起業プランと注意点では、独立時の準備と契約形態の考え方を扱っています。長く企業で運用に関わった人は、判断の記録を書く材料を豊富に持っています。

報酬の分布を確認したい場合は、ソフトウェア作成者の年収・単価相場で職種別の統計的な傾向を見られます。

作り始める前に決めておくこと

作業に入る前に、3つだけ決めておくと迷わずに進みます。

1つめは、誰に見せる資料なのかです。企業の採用担当に見せるのか、業務委託の発注担当に見せるのかで、強調すべき点が変わります。採用なら学習の姿勢と伸びしろ、業務委託なら即戦力としての判断力が中心になります。

2つめは、どれだけの期間をかけるかです。期限を決めずに始めると、作り込みが延々と続き、案件を探す時間がなくなります。完成の基準と期限を先に置き、その範囲で出せるものを出す。不足があれば、次の版で足せばよいだけです。

3つめは、更新をいつ行うかです。作りっぱなしにせず、半年に一度は内容を見直す予定を入れておきます。技術の状況は変わり続けるため、放置された資料は古さのほうが目立ちます。

作ったあとに何をするか

完成したポートフォリオは、置いておくだけでは機会になりません。

まず、応募や提案の場で必ず添えます。文書へのリンクを1行入れるだけで、相手が見るかどうかは相手が決めます。見られなかったとしても、あることを示すこと自体が準備の証明になります。

次に、面談で受けた質問を記録します。同じ質問が繰り返されるようなら、その内容が文書に不足しています。質問はそのまま改善の指示として使えます。

最後に、次に作るものを1つ決めておきます。観点を変えた題材を1つ用意しておけば、半年後の資料が自然に更新されます。作ることを止めた時点で、資料は古くなり始めます。

作る手順の整理

最後に、実行の順に並べ直します。

最初に、業務で得た経験のうち何を出せるかを整理します。固有名詞と構成の詳細は出せません。担当した工程と技術の種類は、抽象化すれば出せます。

次に、題材を決めます。業務で扱った構成を規模を落として再現するのが効率的です。クラウド上に環境を作り、構成をコードで管理し、監視と通知を入れ、復旧のシナリオを1つ通します。

文書は、冒頭の要約、論理と物理の構成図、設計判断の記録、手順書、費用の考え方の順で作ります。判断の記録は3つか4つで足ります。

公開はコードと文書をまとめた場所に置き、認証情報が混入していないかを確認します。同じ内容を読み物として書き直すと、理解の穴が見つかります。

最後に、面談で聞かれる5つの質問に即答できる状態にします。作った順ではなく、結論から説明する練習をしておきます。

作る作業そのものより、判断を言葉にする作業に時間をかけてください。見る人が知りたいのは、動いた事実ではなく、あなたが何を考えて選んだかです。

よくある質問

Q. 業務で構築した環境をポートフォリオに使えますか？

そのままは使えません。顧客名、システム名、IPアドレス、機器の型番や台数、構成図の実物は秘密情報として扱われるのが通常です。担当した工程と扱った技術の種類、直面した課題の類型は抽象化すれば記載できます。判断に迷う場合は、契約先に記載範囲を伝えて許可を取っておくと安全です。

Q. どんな題材で作るのがよいですか？

クラウド上に小規模な環境を作り、構成をコードで管理し、監視と通知を入れ、復旧のシナリオを1つ通す形が基本です。難易度の高い構成を作る必要はありません。要件を自分で設定し、選択肢を比較して選んだ過程が書かれているかどうかで評価が決まります。

Q. 実際にアクセスできるURLは必要ですか？

必須ではありません。クラウド環境を維持し続けると費用がかかり続けます。構築の記録、画面の記録、構成のコードが残っていれば説明はできます。費用の観点から停止しており、コードから再構築できると書いておけば、費用感覚のある人だと受け取られます。

Q. 文書には何を書けばよいですか？

冒頭に誰でも読める言葉で要約を数行、次に論理と物理を分けた構成図、設計判断の記録、再現できる粒度の手順書、費用の考え方を書きます。設計判断は、要件、選択肢、選んだ案、選んだ理由、見送った理由の5項目で記述し、重要な判断を3つか4つ選んで書けば十分です。

Q. 面談ではどのように説明すればよいですか？

結論、根拠、補足の順で話します。作った順に説明を始めると、聞く側が全体像を見失います。想定される質問は、なぜその構成か、他の選択肢を検討したか、障害時にどうするか、費用はどれくらいか、実務にどう応用できるかの5つです。これに即答できる状態にしておきます。