サーバー・インフラ構築の実績の見せ方｜出せない仕事をどう伝えるか

2026年9月3日

丸山桃子

この記事のポイント

✓サーバー・インフラ構築の実績の見せ方を
✓守秘義務で公開できない仕事をどう伝えるかという観点で整理しました
✓実績の代わりになる材料

サーバー・インフラ構築の実績の見せ方が難しいのは、成果物が画面に出ないうえ、大半の案件が守秘義務の対象になるからです。Webデザインなら制作物のURLを並べれば伝わりますが、インフラでは「あの会社の基盤を作りました」と言えないことのほうが多い。この制約のせいで、実力があるのに提案が通らない受け手は珍しくありません。

結論から書きます。出せない実績を伝える方法は、事例そのものを見せることではなく、判断の過程を見せることです。どんな制約があり、どの選択肢を検討し、なぜその構成を選んだか。この思考の筋道は、固有名詞を伏せても伝えられます。そして発注する側が本当に見たいのは、実はここです。

この記事では、なぜインフラの実績は出しにくいのか、匿名化するときの具体的なルール、実績の代わりになる材料の作り方、ポートフォリオの構成、そして掲載許可を取るための手順まで、順番に整理します。

インフラの実績が公開しにくい構造

守秘義務が広く設定されている

インフラの案件では、システム構成そのものが機密として扱われます。どのクラウドを使い、どんなネットワーク構成で、どのミドルウェアのどのバージョンが動いているか。これらは攻撃の手がかりになり得るため、公開を認めない企業がほとんどです。

契約書に「本業務に関する一切の情報」と書かれている場合、社名だけでなく、業種や規模も対外的に出せない解釈になり得ます。実績を出すときは、必ず契約書の秘密保持条項を読み返してください。曖昧なまま出して問題になると、案件を失うだけでなく、業界内の評判にも響きます。

成果物が目に見えない

デザインやライティングと違い、インフラの成果物は「動いている状態」そのものです。スクリーンショットを撮っても、管理画面の断片が写るだけで、そこに込めた設計の意図は伝わりません。

見えないものを伝えるには、翻訳が必要です。何が課題で、どんな制約のもとで、どう解いたか。この構造に落とし込めば、画面がなくても価値は伝わります。逆に「AWSで構築しました」という技術名の羅列だけでは、何ができる人なのか分かりません。

知識が属人的に蓄積される

外部に委託する側から見たとき、ノウハウが社内に残らない点は課題として認識されています。

インフラ構築を外部委託した際には、社外の人間によって行われるため、当然社内に業務ノウハウが蓄積されません。業務を社外の人材が行うと、ノウハウが蓄積されないと同時に、スキルと経験をもった人材が社内で育成できないという点もデメリットとして挙げられます。出典: hnavi.co.jp

この指摘は、受け手にとってはむしろ好機です。知識が社外に出ていくことを懸念する発注者に対して、「引き継ぎができる形で残します」と示せるなら、それ自体が差別化になります。手順書の作り方、構成図の粒度、運用移管の進め方を実績として語れば、社名を出さなくても提供価値が伝わります。

匿名化のルール

特定につながる情報を削る

匿名化は、社名を伏せるだけでは足りません。業種、地域、システムの用途、規模、時期。これらを組み合わせると特定できてしまいます。「関東の中堅アパレル企業のEC基盤を、昨年の夏に刷新」まで書けば、業界の人にはかなり絞り込めます。

削るべきは、組み合わせによって特定に至る要素です。時期をぼかす、地域を書かない、業種の粒度を粗くする。この3つで、たいていの案件は安全な範囲に収まります。

業種はどこまで書けるか

業種を完全に伏せると、実績としての説得力が落ちます。「小売業」「製造業」「医療関連」といった大分類までにとどめるのが、実務上の落としどころです。

大分類でも意味はあります。同じ業種の環境を扱った経験は、発注者にとって安心材料になります。この点は業界側でも共通の認識で、同種の実績があるかどうかが選定の基準として挙げられています。

まず、インフラ構築の経験や実績が豊富な開発会社を選びましょう。実績が豊富な企業のほうが、自社の課題とマッチしたインフラ環境を構築してくれるためです。システム開発の実績だけでなく、インフラ構築の実績が豊富かどうかという点に着目することが大切です。また、社内に優秀なサーバエンジニアやネットワークエンジニアが在籍している点も重要なポイントの1つだといえます。出典: hnavi.co.jp

つまり、大分類の業種だけでも「その領域を知っている」というシグナルにはなります。細部を出せない分、大枠を正確に伝えることに意味があります。

規模の表現の仕方

利用者数や台数を具体的に書くと、特定の材料になります。かといって「大規模」「小規模」だけでは何も伝わりません。

実務的なのは、構成の性質で表す方法です。「単一のサーバー構成から、冗長化した構成へ移行」「拠点間の接続を含む構成」「常時稼働が求められる業務システム」。この書き方なら、扱った難易度は伝わり、規模の特定にはつながりません。

契約書の条項を確認してから出す

匿名化しても、契約上は出せない場合があります。「本業務の存在自体を第三者に開示しない」という条項が入っていることもあります。

実績として使う前に、必ず契約書を確認してください。判断に迷う書き方であれば、依頼者に確認するのが最も確実です。確認の連絡自体が、誠実な相手だという印象につながることもあります。

出せない案件を伝える3つの型

課題と打ち手と結果で語る

最も汎用性が高いのがこの型です。「どんな課題があり」「どんな制約のもとで」「何を選び」「結果どうなったか」。この4段で書くと、固有名詞がなくても内容が伝わります。

たとえば「保守期限が迫る一方で機器の調達に時間がかかる状況だったため、先に監視と冗長化だけを整えて延命し、調達が整った時点で段階的に移行した」という書き方です。ここには社名も業種も入っていませんが、判断力は十分に伝わります。

制約から語る

インフラの案件では、技術的な難しさより制約の厳しさが本質になることが多い。止められない時間帯が限られている、社内規程で使えるサービスが決まっている、既存システムとの互換性を保つ必要がある。

制約を先に説明し、その中でどう組み立てたかを語る形にすると、「何ができるか」より「どんな状況でも回せるか」が伝わります。発注する側が不安に思っているのは、たいてい後者です。

失敗と対処から語る

うまくいった話だけを並べたポートフォリオは、かえって信用されにくい。想定外の事象が起きたときにどう対処したか、その一件のほうが評価されます。

書き方には注意が必要です。依頼者側の落ち度に見える書き方は避け、事象と対処に絞ります。「切り替え当日に外部連携の疎通が確認できず、事前に用意していた切り戻し手順で当日中に旧環境へ戻し、原因を特定したうえで翌週に再実施した」。この書き方なら、準備の周到さが伝わります。

実績の代わりになる材料を作る

自分で構築した検証環境

守秘義務のない実績を、自分で作れます。個人で契約したクラウドや自宅の機材に環境を組み、その構成と判断を公開する形です。

公開できる形で作るときのコツは、実務と同じ制約を自分に課すことです。予算の上限を決める、冗長化を前提にする、監視まで入れる、手順書まで書く。制約なしで作った環境は、遊んだ記録にしか見えません。

手順書と構成図のサンプル

実際の案件で作った文書は出せませんが、同等の粒度で書いたサンプルなら公開できます。架空の構成を題材に、構成図、パラメータの一覧、運用手順書を作ります。

これは非常に効果的です。発注する側は、納品物の質を事前に知りたいと思っています。サンプルがあれば、「この粒度で作ります」という提示がそのまま可能になります。文書の構成そのものを整える考え方はビジネス文書検定で扱われる内容が実務にそのまま応用できます。

技術記事として書く

案件で得た知見のうち、一般化できる部分を記事にします。特定の環境の話ではなく、「この構成でこの問題が起きたときの切り分け手順」といった形にすれば、守秘義務に触れません。

記事は実績の代替であると同時に、説明力の証明になります。インフラの仕事では、技術的な内容を非技術者に伝える場面が頻繁にあり、その力は文章に表れます。継続して書いている人は、それだけで一定の信頼を得ます。

資格を根拠として添える

出せる実績が少ない段階では、資格が基礎の証明として働きます。ネットワークの基礎を体系的に示す指標としてはCCNA（シスコ技術者認定）が広く参照されており、提案時の裏付けとして扱いやすい位置にあります。

ただし資格だけを並べても実績の代わりにはなりません。資格で基礎を示し、検証環境やサンプル文書で実践力を示し、匿名化した事例で判断力を示す。この3層で組み立てるのが現実的です。

ポートフォリオの構成

1件を1ページにまとめる

事例は1件ごとにページを分けます。並べて列挙する形より、1件ずつ深く書いたほうが伝わります。

1ページの構成は、案件の概要、制約、検討した選択肢、採用した構成、結果、期間の内訳。この順番で書きます。検討した選択肢を書くのが重要で、採用しなかった案とその理由まで書くと、判断の質が伝わります。

並べる順番を考える

最初に置くのは、最も再現性の高い事例です。一番難しかった案件ではありません。読み手は「自分の案件に似ているか」を探しています。

自分が受けたい種類の案件に近いものを先頭に置く。これが基本です。運用まで含めて受けたいなら運用移管の事例を、構築だけを受けたいなら構築の事例を前に出します。扱う領域の全体像はサーバー・インフラ構築・保守のお仕事に整理されており、自分がどこを強みとして打ち出すかを決める材料になります。

更新のタイミングを決める

ポートフォリオは、案件が終わった直後に書きます。時間が経つと、判断の理由を忘れます。細部を思い出せないまま書いた事例は、質問されたときに答えられません。

案件終了時の作業として、事例の下書きを作る工程を自分の手順に組み込みます。掲載できるかどうかは後で判断すればよく、まず記録を残すことが重要です。

面談や提案の場での伝え方

口頭で語るときの順番

聞かれてから話すのではなく、順番を用意しておきます。制約、選択肢、判断、結果。この4つを2分程度で話せる形にしておくと、どんな質問にも展開できます。

技術名を並べるのは避けます。「AWSとTerraformとAnsibleを使いました」では、何ができる人か分かりません。「調達に時間がかかる状況だったので、構成をコードで管理して環境を短時間で再現できるようにしました」と、目的から語ります。

出せないと伝えるときの言い方

「守秘義務があるので話せません」で終わると、印象が悪くなります。話せない事実を伝えたうえで、話せる範囲を提示するのが正しい形です。

「個別の案件名は契約上お出しできませんが、どういう課題にどう対応したかであればお話しできます」。この一言があるだけで、相手は続きを聞けます。そして、守秘義務を守る姿勢そのものが、これから発注する側にとっては安心材料になります。自分の案件も同じように守られると分かるからです。

質問への答え方

深く突っ込まれたときこそ、実力が見えます。「その構成を選んだ理由は」「他の選択肢は検討したか」「もし予算が半分だったらどうしたか」。この種の質問に即答できるかどうかが判断されます。

答えられるようにするには、案件ごとに判断の理由を記録しておくしかありません。当時の議事録や設計メモを残しておき、面談の前に読み返す。この準備が、そのまま説得力になります。

掲載の許可を取る手順

案件が終わった直後に依頼する

許可を取るなら、案件終了の直後です。時間が経つと、担当者の異動や関心の低下で判断が下りにくくなります。引き渡しが無事に終わり、依頼者の満足度が高いタイミングが最も通りやすい。

依頼の仕方は、範囲を具体的に示す形にします。「社名は伏せ、業種を大分類で、課題と対応の概要のみを掲載させていただきたい」と、掲載する文面の案を添えて相談します。文面があれば、依頼者は社内で確認しやすくなります。

掲載範囲を書面で残す

許可が下りたら、その範囲を文字で残します。口頭の許可は、担当者が異動した後に効力を失うことがあります。

書面には、掲載する媒体、掲載する内容の範囲、掲載を取り下げる場合の連絡方法を書きます。取り下げの手順を先に決めておくと、依頼者側も許可を出しやすくなります。

断られた場合の代替

許可が下りないことも当然あります。その場合は、その案件から得た一般化できる知見だけを技術記事として書く形に切り替えます。特定の環境に触れず、手法や考え方だけを取り出せば、守秘義務には触れません。

もう1つの代替は、依頼者に推薦の言葉をもらう形です。社名を出さない形での短いコメントであれば、許可が下りることがあります。「対応が丁寧だった」「引き継ぎの資料が分かりやすかった」といった一文でも、実績の裏付けとして機能します。

掲載後の管理も忘れない

掲載を始めたら、内容が古くならないよう定期的に見直します。使った技術のバージョンが古いままだと、更新していない印象を与えます。

また、依頼者側の状況が変わって掲載を取り下げてほしいと言われることもあります。連絡を受けたらすぐ対応できるよう、どの事例をどこに載せているかの一覧を自分で管理しておきます。掲載場所が分散していると、取り下げの対応に時間がかかり、信頼を損ないます。

一気通貫の対応を示すという見せ方

インフラの発注側が評価するのは、部分的な作業ができることより、全体を通して任せられることです。提案から設計、構築、そして運用までを一連で担える体制は、それ自体が実績の説明になります。

株式会社エヌアイデイは、50年以上にわたりシステムインテグレーター（SIer）として金融機関や航空会社、自治体、各種メーカーなどさまざまな業種のお客様のITインフラの導入にまつわる業務を担ってまいりました。ITプロフェショナルとしてインフラ構築のみならず、インフラの安定稼働を見据えた企画、要件定義・設計から、開発・構築、24時間365日の監視・運用・保守まで、一気通貫のサポートが可能です。お客様の課題を解決するため、長年培った知識と経験による最適な提案をおこないます。インフラ構築についてお悩みの方は、ぜひご相談ください。出典: dx.nid.co.jp

個人や少人数で活動する立場では、常時の監視体制まで用意するのは現実的ではありません。ただし、どこまでを自分で担い、どこからは別の体制に引き継ぐのかを明示できれば、それは弱みではなく設計の一部として説明できます。できないことを曖昧にせず、範囲を線で示すほうが信頼されます。

提案書の中で実績をどこに置くか

冒頭に置くのは実績ではなく理解

提案書の1ページ目に実績一覧を並べる形は、よく見かけますが効果が薄い。読み手はまだ、こちらに関心を持っていません。関心を引くのは、自分たちの課題が正確に言語化されている瞬間です。

冒頭には、打ち合わせで聞いた課題を自分の言葉で整理したページを置きます。「保守期限が近い一方で、調達のリードタイムが読めない。この2つを同時に満たす必要がある」といった形です。ここで「分かっている人だ」と思われて初めて、実績のページが読まれます。

実績は提案の根拠として差し込む

実績を独立したページにまとめるより、提案の各所に根拠として差し込むほうが効きます。「段階移行を提案する理由は、同様の制約がある案件で、先に監視と冗長化だけを整えて延命した経験があるためです」という形です。

こうすると、実績が「過去の自慢」ではなく「今回の提案の裏付け」として機能します。読み手にとっても、この人に頼んだ場合に何が起きるかが想像しやすくなります。

添付資料として粒度を示す

提案書の末尾に、成果物のサンプルを添えます。構成図の見本、手順書の目次、試験項目書の一部。実際の案件のものは出せないので、架空の構成で作ったサンプルを用意しておきます。

このサンプルがあると、金額の妥当性を説明しやすくなります。ドキュメント作成の工数が高く見える場合でも、実物を見せれば「この粒度ならこれくらいかかる」と納得されます。逆にサンプルがないと、文書作成の費用は削減対象として真っ先に狙われます。

発注する側が実績を見るときの視点

同じ領域の経験があるか

発注する側が最初に見るのは、自社と似た状況を扱った経験があるかどうかです。技術の一致より、状況の一致を見ています。同じクラウドを使った経験より、「止められない業務システムを移行した経験」のほうが響く場面が多い。

だからポートフォリオでも、技術名の一覧より、状況の記述を厚くします。技術は後から学べますが、止められない環境を扱う緊張感は経験でしか身につかない、と考えられているためです。

将来の拡張に対応できるか

構築して終わりではなく、その後の成長に対応できるかどうかも判断材料になります。設計時点で拡張を想定しているかは、実績の書き方から読み取られます。

事例を書くときに「利用者の増加を見込んで、後から台数を追加できる構成にした」という一文を添えるだけで、この観点への対応が伝わります。実際にその後拡張したかどうかは重要ではありません。設計時に考えていた事実が評価されます。

引き継げる形で残せるか

外部委託でノウハウが社内に残らない懸念は、発注側に共通しています。ここに応えられる受け手は、それだけで選ばれやすくなります。

実績の中に、引き継ぎに関する記述を必ず入れます。どんな文書を残したか、運用担当者への説明をどう行ったか、引き渡し後にどう対応したか。この記述があるかないかで、印象は大きく変わります。

実績を積み上げる順番

最初の1件をどう取るか

公開できる実績がゼロの段階では、範囲を絞った小さな案件から入るのが現実的です。全体の構築ではなく、監視の導入だけ、バックアップの見直しだけ、といった形です。

小さな案件は、発注する側のリスクも小さい。実績が少ない相手にも任せやすく、そこで質を示せれば次につながります。最初から大きな案件を狙うより、確実に完了させられる規模で信頼を作るほうが早い。

範囲を段階的に広げる

同じ依頼者から次の依頼を受けるとき、範囲を1段広げます。監視の導入で入った案件から、バックアップ設計へ、さらに構成の見直しへ。段階的に広げると、環境の理解が深まっているため質を保てます。

いきなり範囲を広げると、把握しきれていない部分で事故を起こします。範囲の拡大は、その環境をどれだけ知っているかに合わせるのが安全です。

継続している事実が最も強い実績になる

同じ依頼者と長く取引が続いている、という事実は、どんな事例の記述よりも強い実績です。社名を出せなくても、「同一の依頼者と複数年にわたり継続」と書ければ、それだけで質の証明になります。

継続を作るのは、技術力そのものより、報告の丁寧さと約束を守る積み重ねです。長く続いている受け手ほど、単発の作業ではなく「この人に任せると楽だ」という関係づくりに時間を使っています。

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

在宅と業務委託の市場を20年見てきた立場から言えば、インフラ領域で仕事が途切れない受け手には共通点があります。実績の数ではなく、1件ごとの説明の解像度が高いことです。案件数を並べたポートフォリオより、3件を深く書いたポートフォリオのほうが問い合わせにつながる。発注する側は「たくさんやった人」ではなく「自分の状況を理解してくれそうな人」を探しているからです。

運営者として見てきた限りでは、間に何社も入る取引形態では、実績が誰のものか分かりにくくなります。元請けの実績として計上され、実際に手を動かした人の名前は残りません。中間マージンが乗らない直接取引では、成果と担当者が一致するため、次の依頼が本人に戻ってきます。手数料0%の効果は手取りの厚さだけでなく、実績が自分に積み上がるという点にも表れます。同じ1件の仕事でも、次につながる形で残るかどうかが違ってきます。

守備範囲を広げる方向を検討している場合はAI・マーケティング・セキュリティのお仕事で扱われる領域との重なりを整理しておくと、実績の見せ方にも幅が出ます。技術者としての市場の広がりについてはソフトウェア作成者の年収・単価相場で職種ごとの傾向が確認でき、どの領域に実績を積むかを考える材料になります。海外の発注者に対して実績を提示する場合の作法についてはUpworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法が、言語と評価の前提を整理しています。

出せない実績は、出せないまま終わらせる必要はありません。判断の過程を言語化し、匿名化した形で残し、代替となる材料を自分で作る。この3つを続けていれば、公開できる案件が1件もない状態からでも、提案が通る材料はそろいます。