旅行・ホテル業界の経験をスキルシートで伝える書き方｜立場・仕組み・業務・工程をそろえる

旅行・ホテル業界の経験をスキルシートで伝えるときは、発注元の立場、関わった仕組み、対象の業務、担当した工程の4点をそろえて書くのが基本です。「ホテル予約システムの開発」だけでは、発注側はどの案件に合うかを判断できません。「ホテルチェーンのPMS入れ替え、予約の取込みと精算の連携、移行の検証を担当」まで書くと、経験の中身が伝わります。

同時に、旅行・ホテルの経歴は、施設の場所や規模、連携先の組み合わせから発注元が推測されやすい分野です。この記事では、4点のそろえ方、書かない情報の線引き、記入例を紹介します。スキルシート全体の構成はスキルシートの基本、守秘義務の一般的な考え方はスキルシートに書いてよいこと・いけないことで扱っているので、ここでは旅行・ホテルの経験に固有の書き方に絞ります。

要約の1行目で「立場」と「仕組み」を示す

スキルシートの冒頭の要約では、旅行・ホテルの経験の軸を1行で示します。この業界の案件は、発注元が旅行会社・OTAか、ホテル・旅館かで前提が違い、関わる仕組みによって求められる経験も大きく変わります。立場と仕組みの分け方は旅行・ホテルのIT案件の記事で説明しています。

• 軸の立場と仕組み（例：ホテル側のPMSとサイトコントローラーの連携）
• 立場と工程（例：要件定義から移行まで、導入ベンダー側のリーダー）
• ほかに対応できる仕組みや技術（例：予約サイトのAPI開発、会員データの基盤づくり）

複数の仕組みを経験している場合は、年数の長い順ではなく、次に入りたい案件に近い順に並べると、読み手が判断しやすくなります。

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

プロジェクトごとの欄では、使用技術に加えて次の4点を書きます。

業務の欄は、業務知識の記事で整理した「在庫と料金」「予約から精算までの流れ」「繁閑」のどこに関わったかを入口にすると書きやすくなります。そのうえで「取消しのときの在庫の戻し」「深夜の到着の日付の扱い」のように業務の単位を一段細かくすると、深さが伝わります。

旅行会社の案件は「商品の形」も書く

旅行会社の案件では、扱った商品の形を添えると読み手が判断しやすくなります。旅行業法第2条は、旅行の計画を作って手配する企画旅行と、旅行者のために運送や宿泊を手配する行為などを分けて定めています。スキルシートでは「ツアー（企画旅行）の造成と販売」「航空券とホテルの手配」のように、自分の言葉で区別して書けば十分です。

外部連携は「相手の種類」と「自分の範囲」で書く

この業界の案件では、OTA、サイトコントローラー、決済、航空や鉄道の予約の仕組みなど、外部との連携が多くなります。連携の経験は評価されやすい一方、連携先の名前を並べると発注元が推測されやすくなります。

• 相手の種類（例：国内外の複数のOTA、航空の予約の仕組み）
• 連携の方式（例：APIでの在庫と料金の送信、予約データの取込み）
• 自分の範囲（例：取込みの不具合の調査と、重複を防ぐ処理の改修）

規模は「件数」ではなく「体制と範囲」で示す

予約の件数、客室数、売上の額は書きません。規模は、体制と期間、自分の範囲で伝えます。

• 全体の体制の目安（例：複数のベンダーが関わる全社的な入れ替え）
• 自分のチームの人数と、自分の立場（例：5名のチームで、連携部分のリーダー）
• 担当した範囲（例：3つのチャネルとの予約の取込みと、PMSへの反映）

繁忙期を意識した作業も、書き忘れやすいのに評価されやすい経験です。「繁忙期前の負荷テストの計画と実施」「連休前の凍結期間に合わせたリリースの計画」のように書くと、業界の進め方への理解が伝わります。

旅行・ホテルの経歴で書かない情報

ホテルや旅館は、地域と規模を書くだけで施設が絞り込めることがあります。旅行会社も、扱う商品や連携先の組み合わせで推測されやすくなります。一つひとつは問題なくても、組み合わせると発注元が特定できることに気をつけます。

宿泊者の氏名や連絡先などは、例示のつもりでも実データを書き写さないでください。宿泊者名簿は旅館業法第6条に基づいて作られるもので、扱いのルールは旅行・ホテルの規制の記事で整理しています。個人情報を扱う業務の契約の考え方は個人情報を扱う業務の契約の記事をご覧ください。

契約で秘密とされた範囲を書かないことが基準になります。参画した案件の業務委託契約や秘密保持契約で、経歴への記載について定めがある場合は、その定めに従ってください。不正競争防止法の営業秘密の考え方はスキルシートと守秘義務の記事で扱っています。

プロジェクト欄の記入例

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

例1：ホテルのPMSの入れ替え

期間：20XX年〜20XX年（1年2か月）
案件概要：国内のホテルチェーンのPMSの入れ替え（パッケージ製品への移行）
規模・立場：導入ベンダー側の連携チーム5名（自分は連携部分のリーダー）
対象の業務：予約の取込み、チェックイン時の名簿の記録、チェックアウト時の精算
担当した工程：現行の連携の調査、連携の設計、結合テスト、移行の検証、本番切替の立会い
使用技術：Java、SQL、REST API
工夫・成果：新旧のシステムで同じ予約データを取り込み、差を「仕様の差」「移行の誤り」「現行の不具合」に分けて一覧にし、現場の確認を進めやすくした

例2：サイトコントローラーとOTAの連携の改善

期間：20XX年〜20XX年（10か月）
案件概要：サイトコントローラーの事業者で、OTAとの在庫・料金の連携の改善
規模・立場：開発チーム6名（自分は予約の取込みの設計と実装の担当）
対象の業務：在庫と料金の送信、予約・変更・取消しの取込み
担当した工程：不具合の調査、詳細設計、実装、結合テスト
使用技術：Go、PostgreSQL、メッセージキュー
工夫・成果：取込みの重複が起きる条件をログから洗い出し、同じ予約を二重に登録しない処理に改めた

例3：旅行会社の予約サイトの改修

期間：20XX年〜20XX年（1年）
案件概要：オンライン旅行会社の、宿泊と航空券を組み合わせた商品の予約画面の改修
規模・立場：フロントエンドのチーム4名（自分は検索と予約確認の画面の担当）
対象の業務：商品の検索、料金と取消しの条件の表示、予約内容の最終確認
担当した工程：画面設計、実装、総合テスト
使用技術：TypeScript、React
工夫・成果：取消しの条件と合計の金額を、予約を確定する直前の画面にまとめて表示するよう見直した

どの例も、施設名、製品名、連携先の名前、件数は書いていません。それでも、立場、仕組み、業務、工程、工夫が書かれていれば、どの案件に合うかは読み手に伝わります。

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

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

1. 変更や取消し、ノーショーのとき、在庫と料金がどう動く仕組みだったか
2. 外部連携の不具合を、どう切り分けて原因を見つけたか
3. 繁忙期を前に、リリースや性能の対策をどう計画したか
4. 現場（フロントや予約の担当）の要望を、どう仕様に落としたか

よくある質問

ホテルの名前を書かないと、経験の大きさが伝わらないのではありませんか？

立場と規模、自分のチームの人数と範囲、担当した工程を書けば、経験の大きさは十分に伝わります。発注側が知りたいのは施設名より、どの仕組みのどの業務を、どの立場で担ったかです。施設名は契約で秘密とされていることが多いため、書かないのが基本です。

PMSの製品名は書いてもよいですか？

製品の経験そのものが案件の条件になることもあるため、スキル一覧に「経験のある製品」として書くことはあります。ただ、導入先の規模や地域、時期と組み合わせると発注元が推測されやすくなります。プロジェクト欄では一般的な表現にとどめ、契約で記載が制限されていないかを確かめてください。

旅行業界とEC業界の両方の経験があります。どう書き分ければよいですか？

検索や決済、会員などの共通する経験は、まとめてスキル一覧に書いて構いません。プロジェクト欄では、旅行・ホテルの案件は在庫と料金、予約の変更と取消しなど業界に固有の業務を書き、ECの案件とは分けて書くと、どちらの案件にも合うことが伝わります。ECの書き方はEC業界のスキルシートの記事が参考になります。