通信業界の経験をスキルシートで伝える書き方｜区分・サービス・工程をそろえる

通信業界の経験をスキルシートで伝えるときは、事業者の種別、設備か業務システムかの区分、対象のサービス、担当した工程の4点をそろえて書くのが基本です。「通信キャリア向けネットワーク構築」だけでは、携帯のコアなのか、ISPのバックボーンなのか、料金システムなのかが分からず、発注側は合う案件を判断できません。

同時に、通信事業者は数が限られ、大きな設備の更改や障害は公表されることもあるため、書き方しだいで発注元が推測されやすい分野です。この記事では、4点のそろえ方、書かない情報の線引き、記入例を紹介します。ネットワークの経験全般の書き方（機器のメーカー、規模のぼかし方、切り替え当日の役割など）はネットワークエンジニアのスキルシートの記事、守秘義務の一般的な考え方はスキルシートに書いてよいこと・いけないことで扱っているので、ここでは通信業界に固有の書き方に絞ります。

要約の1行目で「区分」と「サービス」を示す

スキルシートの冒頭の要約では、通信業界の経験の軸を1行で示します。区分の分け方は通信業界のIT案件の記事で説明しています。

• 軸の区分とサービス（例：固定のブロードバンドを提供する事業者のコア網、経路設計と更改）
• 立場と工程（例：構築会社の側で、基本設計から本番の切り替えまで）
• 広げられる領域（例：監視の自動化、OSSとの連携の設計）

設備系と業務システム系の両方の経験がある場合は、次に入りたい案件に近い方を先に書くと、読み手が判断しやすくなります。

プロジェクト欄は4点をそろえる

区分とサービスを分けて書くのがポイントです。同じ「コア」でも、個人向けのインターネット接続と法人向けのVPNでは、求められる設計の考え方が違います。業務システムなら、受付・オーダー・料金計算・請求のどこを担ったかまで書くと、深さが伝わります。業務の流れは通信業界の業務知識の記事で整理しています。

「影響範囲をどう扱ったか」を一文入れる

通信の案件で評価されやすいのは、作業で利用者への影響をどう抑えたかです。プロジェクト欄の工夫・成果の欄に、次のような一文を入れると、通信の現場の経験だと伝わります。

• 収容の単位ごとに切り替えの順番を決め、戻す手順と判断の基準を手順書に入れた
• 料金プランの追加で、既存の契約への影響を洗い出す観点表を作った
• 監視の閾値を見直し、利用者に影響の出る障害を早く検知できるようにした

数字で示す場合は、件数や利用者数の実数ではなく、「切り替えの手戻りがなくなった」「確認の工数を減らした」のように、自分の作業の変化として書きます。

通信業界の経歴で書かない情報

電気通信事業法第4条は、電気通信事業者の取扱中の通信の秘密を侵してはならないとし、第2項で、電気通信事業に従事する者は在職中に知り得た他人の秘密を守らなければならず、職を退いた後も同様と定めています。スキルシートに利用者の通信や情報に関わることを書かないのは当然として、次のように、一つひとつは問題なくても組み合わせると発注元や設備が特定できる情報にも気をつけます。

特に気をつけたいのは障害です。一定の規模を超える障害は、事業者が総務大臣に報告する「重大な事故」にあたり（同法第28条、同法施行規則第58条）、報道などで広く知られることがあります。「20XX年X月の大規模障害の復旧を担当」と書くと、それだけで事業者が分かってしまいます。障害対応の経験は、時期や規模を伏せて、自分が担った切り分けや再発防止の中身で書きます。

参画した案件の業務委託契約や秘密保持契約で経歴への記載について定めがある場合は、その定めに従ってください。何を書いてよいか迷うときは、発注元の担当者に確かめるのが確実です。案件で守るルールそのものは通信業界の規制の記事をご覧ください。

プロジェクト欄の記入例

以下は書き方を示すための例で、実在の案件や実績ではありません。

例1：コア網の更改（設備系）

期間：20XX年〜20XX年（1年6か月）
案件概要：固定のブロードバンドを提供する事業者の、コア網のルータの更改
規模・立場：構築会社の側で、設計・移行チーム5名（自分は移行の担当、後半はサブリーダー）
対象のサービス：個人向けのインターネット接続
担当した工程：移行計画、切り替え手順書の作成、検証、夜間の切り替えの実施
使用技術：BGP、OSPF、MPLS、Python（設定の差分確認）
工夫・成果：収容の単位ごとに切り替えの順番と戻しの判断基準を決め、手順書に反映した。設定の差分を自動で比べる仕組みを作り、当日の確認の時間を短くした

例2：料金プランの追加（BSS）

期間：20XX年〜20XX年（10か月）
案件概要：移動体通信事業者の料金システムへの新しい料金プランの追加
規模・立場：開発チーム7名（自分は料金計算の設計とテストの担当）
対象の業務：料金計算と割引、月の途中の変更の日割り
担当した工程：要件の整理、詳細設計、結合テスト、受入テストの支援
使用技術：Java、SQL、バッチ処理
工夫・成果：既存の契約からの変更のパターンを洗い出した観点表を作り、業務部門と例外の扱いを事前にそろえた

どちらの例も、事業者名、時期の詳細、加入者数、設備の構成は書いていません。それでも、区分・サービス・工程・工夫が書かれていれば、どの案件に合うかは読み手に伝わります。

面談で深掘りされやすい点

スキルシートの内容は、面談で深掘りされます。通信業界の案件で聞かれやすいのは、次のような点です。面談全般の準備は面談でよく聞かれる質問の記事で扱っています。

1. 切り替えや工事で、戻す判断をどの基準で、誰がしたか
2. 障害のとき、影響の範囲をどう見積もり、誰に何を報告したか
3. 業務システムなら、料金や契約の例外をどう洗い出したか
4. 本番の利用者の情報に触れない制約の中で、どう検証したか

4つ目は通信業界ならではの問いです。データを自由に見られない環境で、加工したデータや検証用の設備を使って品質を確かめた経験は、次の案件での安心材料になります。

よくある質問

事業者名を書かないと、経験の大きさが伝わらないのではありませんか？

事業者の種別と規模、自分のチームの人数と役割、担当した工程を書けば、経験の大きさは十分に伝わります。発注側が知りたいのは事業者名より、どの区分のどのサービスを、どの立場で担ったかです。規模は桁で示し、実数は書かないのが基本です。

大規模障害の対応を経験しました。実績として書いてもよいですか？

障害の対応は評価されやすい経験ですが、時期や影響の範囲を書くと事業者が特定されやすくなります。「障害時の切り分けと復旧手順の実施、再発防止策の検討」のように、自分が担った中身で書き、詳しくは面談で、話してよい範囲で口頭で説明します。

設備系と業務システム系の両方の経験があります。どちらを前に出すべきですか？

次に入りたい案件に近い方を要約の1行目に置き、もう一方は「広げられる領域」として添えるのがおすすめです。両方を同じ重さで並べると、軸が伝わりにくくなります。両方の接点（オーダーの受け渡し、監視と業務の連携など）に関わった経験があれば、それは強みとして書けます。