Webサイト保守・分析の実績の見せ方｜出せない仕事をどう伝えるか

2026年5月20日

＠SOHO編集部

この記事のポイント

✓Webサイト保守・分析の実績の見せ方を
✓守秘義務で社名や数字を出せない前提で整理しました
✓作業内容を抽象化して伝える方法

結論から書きます。Webサイトの保守と分析で実績を示すときに使うべき材料は、社名でも成果の数字でもありません。「どういう状況で、何を判断し、どう処理したか」という過程です。この職種は、そもそも成果が見えにくく、しかも守秘義務で出せないものが多い。だからこそ、出せる部分の見せ方が勝負になります。

制作の仕事なら、作ったサイトのスクリーンショットを並べれば伝わります。ところが保守は違います。「1年間、何も起きませんでした」が最高の成果である仕事を、どう見せるのか。分析も同様で、レポートの中身はほぼ全部が守秘対象です。

この記事では、保守・分析の実績を、守秘義務を守りながら伝える方法を整理します。抽象化の技術、成果の代わりに示すもの、許諾の取り方、ポートフォリオの構成、そして初回の商談で使う話し方まで。出せないものが多い仕事だからこそ、見せ方に技術が要ります。

保守・分析の実績は、そもそも見せにくい

まず、なぜ見せにくいのかを構造で押さえておきます。原因が分かれば、対処の方向が決まります。

成果が「起きなかったこと」だから

保守の価値は、サイトが落ちなかったこと、改ざんされなかったこと、表示が崩れなかったことにあります。つまり、起きなかった事象が成果です。起きなかったことは、写真に撮れませんし、数字にもなりにくい。

この構造は、店舗の運営と似ています。実務側の説明でも、次のような比喩が使われています。

ホームページの運用や保守は実際の店舗と似たようなものと考えるとわかりやすいでしょう。実際の店舗（例えばファッション衣料店）では、お店の商品をきれいに並べて、お客様の応対をして、商品を販売して、売れたら補充して、季節ごとに陳列方法を変えたり、売値を変更したり、販促ポップを作ったりしていきます。時間が経てば陳列棚は乱れて来ますので、洋服もこまめに1つずつきれいに折りたたんで、店内もきれいに掃除をして清潔にします。そして毎月のテナント料や光熱費、商品の仕入れ代金を払ったりします。電話やパソコン、プリンターなど必要な備品の故障や買い換えもあります。出典: tol.jp

店をきれいに保っている状態を、写真1枚で示すのは難しい。乱れた状態と比べて初めて価値が伝わります。実績の見せ方も同じで、「維持している状態」を単独で見せるのではなく、「維持しなければどうなるか」との対比で見せる必要があります。

守秘義務で社名も数字も出せないから

保守と分析は、依頼側の内部情報に触れる仕事です。アクセス数、コンバージョン数、売上、施策の内容。これらは競合に知られたくない情報であり、契約で開示を禁じられているのが普通です。

社名すら出せないケースも多い。「大手企業の保守を担当」と書きたくても、その一言が守秘義務に触れる可能性があります。特に業種と規模を組み合わせると、対象が特定できてしまうことがある。「都内の大手アパレル企業」と書けば、候補は数社に絞られます。

作業内容が地味で伝わりにくいから

プラグインの更新、バックアップの確認、ログの監視。どれも重要ですが、言葉にすると地味です。地味な作業を並べただけの実績紹介は、読む側の印象に残りません。

正直なところ、ここで多くの人が諦めています。「保守は地味だから仕方ない」と考えて、実績紹介を作らずに口頭の説明だけで済ませてしまう。ただ、地味であることと伝わらないことは別問題です。作業の羅列ではなく、判断の記録として書けば、専門性は十分に伝わります。

出せないものと出せるものを切り分ける

対処の第一歩は、何が出せて何が出せないのかを整理することです。ここが曖昧なまま考えると、全部出せない気がしてきます。

出せないもの

依頼側の社名と、社名が推測できる情報。具体的なアクセス数、コンバージョン数、売上。施策の詳細な内容と、その結果の数字。契約金額。担当者の氏名。管理画面のスクリーンショットで、データが写り込んでいるもの。

これらは原則として出せません。契約書に明記されていなくても、慣行として出さないほうが安全です。ひとつ出してしまうと、他の依頼側から「うちの情報も出されるのでは」と見られます。

条件付きで出せるもの

社名は、許諾を取れば出せます。数字も、丸めた形であれば許諾が下りることがあります。管理画面のスクリーンショットは、データをぼかすか、自分で作ったサンプルデータに置き換えれば出せます。

条件付きのものは、聞いてみる価値があります。断られても失うものはありません。聞かずに諦めているケースが、実務では非常に多い。

許諾なしで出せるもの

作業の種類。使った技術やツールの名前。対応した障害の種類。判断の考え方。関わった期間の長さ。業種を大きな括りで示すこと。これらは、特定につながらない限り出せます。

ここが実績紹介の主戦場です。「どの会社の」を消しても、「どういう状況で何をしたか」は残ります。そして、依頼を検討している人が知りたいのは、実は後者です。

抽象化して伝える技術

出せないものを消して、伝わる形に組み直す。この作業には型があります。

主語を会社から状況に置き換える

「A社のサイトを保守しました」ではなく、「月間の更新頻度が高い企業サイトで、複数の担当者が同時に編集する環境の保守を担当しました」と書く。主語を会社名から状況の説明に置き換えると、社名を出さずに具体性が保てます。

状況の説明に含めるとよいのは、サイトの性格、更新の頻度、関わる人数、使っている技術、そして特有の制約です。「決済機能を持つサイトで、稼働を止められない制約があった」といった記述は、社名がなくても難易度を伝えます。

数字を規模の表現に置き換える

具体的なアクセス数は出せませんが、規模感は伝えられます。「月間数十万規模のアクセスがあるサイト」といった書き方であれば、多くの場合は許容範囲です。ただし、業種と組み合わせると特定されるケースがあるので、そこは注意してください。

成果の数字についても同様です。「コンバージョン率が改善しました」とだけ書き、具体的な数値は書かない。物足りなく感じるかもしれませんが、数字を書けない事情は、同業者にも依頼側にも理解されます。むしろ、数字を無造作に出している実績紹介のほうが、「この人は自分の情報も出すのでは」と警戒されます。

作業ではなく判断を書く

これが最も効く技術です。「プラグインを更新しました」ではなく、「複数のプラグインに依存する構成だったため、更新は検証環境で先に実施し、依存関係の競合がないことを確認してから本番へ反映する手順を組みました」と書く。

作業は誰でも書けますが、判断は経験がないと書けません。読む側は、判断の記述から実力を推定します。特に、「なぜその方法を選んだのか」「他の選択肢をなぜ採らなかったのか」を書けると、専門性が明確に伝わります。

判断を書く形式であれば、守秘義務にも触れにくい。判断の背景にある技術的な事情は、その会社固有の秘密ではなく、一般的な技術判断だからです。

失敗と、その後の対処も書く

うまくいった話だけを並べた実績紹介は、かえって信用されません。実務を知っている人ほど、「そんなに順調なわけがない」と思うからです。

書けるのは、自分の判断ミスとその修正です。「更新後の検証項目にフォームの送信テストを含めていなかったため、送信エラーに気づくのが遅れた。以降、検証項目のチェックリストを作り、毎回同じ手順で確認する運用に変えた」といった記述です。この種の記述は、再発防止の仕組みを作れる人だという証明になります。

ただし、依頼側に損害を与えた事案を書くときは慎重にしてください。相手が特定できる形で書くのは避け、あくまで自分の手順の改善として書きます。

許諾を取りにいく

条件付きで出せるものは、聞けば出せることがあります。聞き方に工夫が要ります。

契約時に先に決めておくのが最善

最も確実なのは、契約の段階で実績掲載の可否を決めておくことです。「業務終了後、社名を伏せた形での実績掲載を可とする」という条項を入れておく。もしくは、社名の掲載可否を明示的に確認しておく。

契約時に聞くほうが、後から聞くより通りやすい傾向があります。後から聞くと、担当者は上長に確認する手間が発生しますし、「今さらなぜ」という疑問も生まれます。契約時なら、条件の一部として自然に処理されます。

途中で聞くときは、掲載する文面を添える

契約の途中や終了後に許諾を求めるときは、「掲載してもよいですか」とだけ聞かないでください。掲載する文面をそのまま作って添えます。

「実績紹介に掲載させていただきたく、以下の文面を作成しました。社名は伏せ、業種も大きな括りにしております。ご確認のうえ、問題があれば修正いたします」という形で送る。相手は、何が公開されるのかを見て判断できます。判断材料が具体的なほど、許可は下りやすい。

断られたときの記録も残す

許諾が下りなかった場合、その事実を記録しておいてください。次の営業の場で「守秘義務の関係で個別の事例はお出しできません」と説明するときの根拠になります。

そして、断られた理由を聞いておくと、次に活きます。社名だけが問題なのか、数字が問題なのか、掲載自体が方針として不可なのか。理由が分かれば、条件を変えて再提案できます。

ポートフォリオをどう組むか

材料が揃ったら、見せ方を組み立てます。保守・分析のポートフォリオには、制作とは違う構成が要ります。

事例ではなく、対応領域から見せる

制作のポートフォリオは事例を並べる形が主流ですが、保守は対応領域を軸にしたほうが伝わります。監視と障害対応、更新作業、セキュリティ、バックアップと復旧、解析の設計、レポートと改善提案。この領域ごとに、何ができるかを書く。

領域ごとに書くと、依頼側は自分が必要としている部分を探せます。事例を並べる形式だと、依頼側は自社と似た事例を探すことになり、該当がなければ判断できません。保守や分析の業務がどう分類されるかはWebサイトコンサル・保守・分析のお仕事にまとまっているので、領域の区切り方を決めるときの参考になります。

対応した障害の種類を一覧で示す

これは非常に効きます。「対応経験のある障害」として、サーバーの停止、改ざんの検知と復旧、証明書の失効、プラグインの競合による表示不良、フォームの送信エラー、外部APIの仕様変更による連携停止、といった項目を並べる。

この一覧は、社名も数字も含みません。それでいて、経験の幅を明確に示します。依頼側は自社で起きそうな事象を探し、それが一覧にあれば安心します。障害対応の経験は、保守の仕事で最も評価される要素です。

使える技術とツールを具体名で書く

CMSの種類、サーバー環境、監視ツール、解析ツール、バージョン管理の仕組み。具体名で書いてください。ここは守秘義務に関係しない領域です。

技術名を並べるだけでは自慢に見えると心配する人がいますが、依頼側にとっては検索の対象です。自社が使っているCMSの名前を探して、あればそこで判断します。名前がなければ、対応できないと見なされます。書かない理由がありません。

ネットワークやサーバーの基礎知識を体系的に持っていることを示したい場合は、資格が客観的な材料になります。CCNA（シスコ技術者認定）は、ネットワークの基礎と障害切り分けの範囲を扱う認定で、保守の文脈では「切り分けができる人」という説明に使えます。実績を出せない分、資格のような外形的な証明の価値は相対的に上がります。

レポートのサンプルを自作する

分析の実績で最も強いのは、実際のレポートを見せることです。ただし本物は出せません。だから、自分で作ったサンプルを用意します。

自分のサイトや、公開データを使ったサンプルレポートを作る。構成、グラフの見せ方、考察の書き方、提案の粒度。これらは実データでなくても伝わります。むしろ、守秘義務を守りながら実力を示す方法として、最も正当なやり方です。

サンプルを作る手間はかかりますが、一度作れば長く使えます。そして、レポートの品質は文章力に大きく依存します。報告書の型を押さえておきたい場合はビジネス文書検定の出題範囲が参考になります。数字を並べただけのレポートと、判断が書かれたレポートでは、評価がまったく違います。

分析を軸に独立している人がどう実力を示しているかは、上級ウェブ解析士でコンサルティング独立｜分析のプロとして稼ぐ方法にまとまっています。資格と実務の組み合わせで信用を作る進め方は、実績を出しにくい職種では特に有効です。

商談の場での話し方

書面のポートフォリオとは別に、口頭での説明にも型があります。

「守秘義務のため」を言い訳にしない

「守秘義務があるのでお話しできません」で止めると、警戒されているように受け取られます。言うべきは、その先です。

「個別の社名や数字はお出しできませんが、どういう状況でどう対応したかはご説明できます」と続ける。そして実際に、状況と判断の話をする。この流れであれば、守秘義務を守る姿勢が信頼の材料に変わります。将来自分が依頼側になったときも同じように守られる、と伝わるからです。

相手の状況に合わせて事例を選ぶ

実績を全部並べる必要はありません。相手の困りごとを聞いたうえで、それに近い状況の話をひとつかふたつ出す。これが最も効きます。

そのために、事前に自分の経験を「状況別」に整理しておいてください。障害対応の話、引き継ぎの話、更新頻度が高い環境の話、複数人が編集する環境の話。引き出しを分けておけば、その場で適切なものを取り出せます。

数字を求められたときの返し方

「どのくらい改善しましたか」と聞かれることがあります。答えられない場合、正直に理由を説明したうえで、代わりの材料を出してください。

「具体的な数値は開示できませんが、改善の進め方はご説明できます。まず計測の設計を見直し、次に離脱の多い導線を特定し、そこから優先度を付けて改修していく流れです」と続ける。数字がなくても、手順が具体的であれば実力は伝わります。むしろ、手順を説明できない人が数字だけを出しているケースのほうが疑わしい。

実績が薄い段階でどう見せるか

まだ保守の経験が少ない場合でも、示せるものはあります。

自分のサイトを運用して記録する

自分でサイトを持ち、実際に運用してください。更新の記録、障害が起きたときの対処、改善の施策と結果。すべて自分のものなので、守秘義務の制約がありません。数字も画面も自由に出せます。

自分のサイトでの記録は、依頼案件の実績より劣ると考える人がいますが、そうとは限りません。全工程を公開できるという点では、依頼案件より情報量が多い。何をどう判断したかを最後まで見せられるのは、自分のサイトだけです。

手順書やチェックリストを作って公開する

保守の実力は、手順の設計に現れます。プラグイン更新時の検証チェックリスト、障害発生時の切り分け手順、バックアップの確認手順。これらを自分で作り、公開する。

手順書は、実務を経験していないと書けません。逆に言えば、書けていること自体が経験の証明になります。そして、依頼側にとっては「この人に任せたらこういう手順で管理される」というイメージが具体的に湧く。実績の一覧より効果的な場合があります。

小さく受けて記録を積む

経験が足りないなら、範囲を絞って受けるのが現実的です。監視と更新だけを引き受け、そこから記録を積む。範囲を絞れば責任も限定でき、依頼側にとってもリスクが小さい。

そして、受けた案件はすべて記録してください。作業の内容、判断、かかった時間、起きた問題。この記録が、次の商談で使う材料になります。記録を取っていない仕事は、終わった瞬間に実績としての価値を失います。

依頼側は実績の何を見ているか

見せ方を考えるうえで、受け取る側が何を判断材料にしているかを知っておくと精度が上がります。

「うちと同じ環境を扱えるか」を最初に見る

依頼側が最初に確認するのは、自社と同じCMS、同じサーバー環境、同じ規模を扱った経験があるかどうかです。ここが合わないと、それ以降の内容は読まれません。

だから、対応可能な環境は目立つ位置に書いてください。ページの下のほうに技術一覧を置くのは損です。冒頭近くに「対応環境」として並べ、そこで該当を見つけてもらう。特に、決済や会員機能を持つサイトを扱えるかどうかは、依頼側にとって大きな分岐点になります。

「止まったときにどう動くか」を見る

保守を検討している会社の多くは、過去に何かしらのトラブルを経験しています。だから、平常時の作業内容より、異常時の動き方に関心が向きます。

ここで効くのが、先に挙げた障害の種類の一覧と、対応の手順です。「サーバー停止を検知した場合、まず外形監視で範囲を確認し、次にサーバー側のログを確認し、原因が特定できない場合は事業者へ問い合わせます」といった手順の記述は、実績の代わりになります。手順が具体的であれば、経験の裏付けがあると判断されます。

「説明できる人か」を見る

意外に軽視されがちな観点ですが、依頼側の担当者は、社内に説明する立場にあります。技術に詳しくない上長へ、なぜこの費用が必要なのかを説明しなければならない。

つまり、担当者が求めているのは技術力そのものより、社内で使える説明です。実績紹介の文章が平易で、専門用語に説明が添えられていれば、そのまま社内資料に転用できます。この転用しやすさは、選定の場面で確実に効きます。難しい用語を並べた実績紹介は、実力があっても選ばれません。

「長く続けているか」を見る

保守は長期契約です。だから、依頼側は途中で投げ出さない相手を探しています。継続年数は、この不安に直接答える情報です。

社名を出せなくても、「同一クライアントの保守を継続中（継続4年）」といった書き方はできます。年数は成果の数字ではないため、開示の許諾が下りやすい部類でもあります。継続の事実は、成果の数字より強い証明になることがあります。

実績の見せ方でやりがちな失敗

最後に、避けるべきやり方を挙げておきます。

守秘義務の線を自己判断で越える

「社名は出していないから大丈夫」と考えて、業種と規模と地域を書いてしまう。この3つが揃うと、対象は容易に特定されます。特に、業界の関係者が読めば一発で分かる。

判断に迷ったら、書かないでください。実績紹介で1件を減らす損失より、守秘義務違反を疑われる損失のほうが圧倒的に大きい。既存の依頼側に見られる可能性も常にあります。実績紹介は、新規の相手だけが読むものではありません。

数字だけを並べる

「改善率50%」「表示速度2倍」といった数字を並べただけの実績紹介は、根拠が見えないため信用されにくい。しかも、これらの数字は測り方によっていくらでも変わります。

数字を出すなら、測り方と条件を添えてください。条件を書けないなら、数字は書かない。数字のない実績紹介より、根拠のない数字が並んだ実績紹介のほうが評価は下がります。

制作の実績と混ぜて見せる

制作と保守の両方をやっている場合、実績を一緒に並べてしまいがちです。ただ、依頼側が保守を探しているとき、制作の実績は判断材料になりません。むしろ、「制作が本業で保守はついでにやっているのか」という印象を与えることがあります。

保守と分析の実績は、独立した区画にまとめてください。制作のポートフォリオとは別のページ、別のセクションにする。分けることで、保守を専門として扱っているという姿勢が伝わります。

更新せずに放置する

実績紹介を一度作って、何年も更新しないケースは非常に多い。保守の仕事は環境の変化が速く、扱っているCMSやサーバー環境の版も変わります。数年前の記述のままだと、古い環境しか扱えない人だと判断されます。

更新の負担を減らす方法は、記録の形式を先に決めておくことです。案件が終わったとき、あるいは節目のタイミングで、状況、判断、使った技術、起きた問題の4項目を書き足す。この形式を固定しておけば、更新は毎回数分で済みます。形式が決まっていないと、書き出すたびに構成から考えることになり、結局後回しになります。

年に一度は、対応環境の記述を見直してください。バージョンの表記、対応可能なCMSの一覧、使っているツール。ここが最新であるだけで、実績の中身が同じでも印象が変わります。放置された実績紹介は、放置されたサイトと同じに見えます。保守を売る立場でそれをやってしまうと、説得力を失います。

記録の粒度を決めておく

実績の材料になるかどうかは、記録の粒度で決まります。日付と作業名だけの記録は、後から読んでも何も思い出せません。逆に、細かすぎる記録は続きません。

実務で続く粒度は、案件ごとに月1回、4行程度です。その月に起きたこと、判断したこと、使った技術、次に持ち越した課題。この4行を月末に書くだけで、1年後には十分な材料になります。障害が起きた月は、切り分けの手順と結果を追記してください。障害対応の記録は、実績紹介で最も価値が高い部分になります。

記録を残す場所は、どこでも構いません。表計算ソフトでも、テキストファイルでも、メモアプリでも続くものを選んでください。重要なのは形式ではなく、同じ場所に貯め続けることです。散らばった記録は、必要になったときに集められません。

見せ方より、続けていることが効いてくる

フリーランスや在宅ワークの市場を20年運営してきた立場から見ると、保守・分析の分野で仕事が続いている人は、派手な実績を持っている人ではありません。同じ相手と何年も続いている人です。そして、その事実自体が最も強い実績になっています。「この会社の保守を4年続けています」という一文は、成果の数字より説得力を持ちます。

運営者として見てきた限りでは、実績を見せることに苦労している人ほど、記録を残していません。逆に、日々の作業を淡々と記録している人は、必要になったときに材料を組み立てられます。記録は、実績を作る作業ではなく、実績を取り出せる形にしておく作業です。

構造の話もしておきます。仲介の手数料が乗る取引では、依頼側が払った金額の一部が中間で消えます。中間マージンが乗らない直接の取引であれば、同じ予算でも依頼側はより広い範囲を頼めますし、受け手の手取りは厚くなる。手数料0%が意味を持つのは、単価が高く見えるからではありません。手取りが厚ければ、少ない件数で成立するので、1件あたりに長く関われる。長く関われば、継続年数という実績が積み上がります。件数を追う働き方では、この種の実績は作れません。

自分の稼働と収入の水準を確認したいときは、職業分類別の数字が目安になります。技術寄りの作業が中心ならソフトウェア作成者の年収・単価相場を見て、稼働時間に対して案件を抱えすぎていないかを点検してください。無理のない件数に収まっていれば、記録を残す時間も確保できます。

分析やレポート作成の工程を整理したい場合はマーケ戦略・分析・レポート作成のお仕事が参考になります。工程ごとに何をしているかを言語化しておくと、そのまま実績の説明文になります。実績紹介を書くのが難しいと感じる人の多くは、実は自分の作業を言語化していないだけです。

最後にひとつ。実績が出せないことを、この職種の弱点だと考える必要はありません。出せない情報を扱っているという事実そのものが、信頼される仕事をしている証拠です。伝えるべきは、何を扱ったかではなく、どう扱ったか。ここを丁寧に言葉にできる人は、社名を1つも出さずに選ばれています。