
監修者
リメディ株式会社 ヘッドハンター
日髙 大志 | HIDAKA Taishi
筑波大学大学院を卒業後、日本工営(開発コンサルティング会社)に新卒入社。官公庁・建設・不動産・総合商社セクターでの国際開発プロジェクトにコンサルタントとして従事。その後、KPMGコンサルティング株式会社に参画し、DXコンサルタントとして、官公庁・不動産セクターでのDX推進に携わる。
コンサルタントとしてキャリアを歩む中で、優秀な人材がポテンシャルを最大限発揮して活躍することが企業の成長へ直結することを実感し、ヘッドハンターとしてリメディに参画。コンサルティングファーム、M&A、不動産・建設業界を中心にハイキャリア層の採用・転職支援を実施。
2026年7月1日、TIS株式会社と株式会社インテックは合併し、応募先の現行商号はTISI株式会社になりました。旧TIS向けの職務経歴書を準備していた人は、応募先の社名だけを直すのではなく、現行の職種と募集要項へ実績を対応させる必要があります。一方、過去の在籍・案件までTISI名義へ遡って書き換えてはいけません。本記事では、社名の時系列と職種別の実績を同時に整える方法を解説します。
TISI(旧TIS)向け職務経歴書の結論
最初に二つの軸を決めます。一つは現在の応募先と過去の経歴を、日付に沿って書き分けること。もう一つは、現行TISIのどの職種で、どの顧客・事業課題へ貢献するかを決めることです。
| 確認項目 | 正しい整理 | 避けたい状態 |
|---|---|---|
| 応募先 | 2026年7月1日以降はTISI株式会社 | 現在の応募先をTIS株式会社とだけ書く |
| 旧TISでの在籍 | 在籍当時の正式社名と期間を記載 | 過去の在籍先をTISIへ遡及して変更する |
| 旧インテックでの在籍 | 在籍当時の正式社名と期間を記載 | 合併後の名称だけにして時点を曖昧にする |
| 応募職種 | 現行募集の職種、仕事内容、条件を確認 | 旧TIS時代の検索結果だけで書類を作る |
| 主要案件 | 本人の判断と提供結果を職種別に示す | 大規模案件の看板を個人実績にする |
旧TIS名で検索した読者も、提出先は現行TISIです。ただし、2026年7月1日より前に経験した案件の会社名や期間は、当時の事実を守ります。現在へ更新する情報と、過去のまま残す情報を分けることが出発点です。
応募先と過去の社名を時系列で書き分ける
TISI公式発表によると、TIS株式会社と株式会社インテックは2026年7月1日付で合併し、商号をTISI株式会社へ変更しました。職務経歴書では、応募日、在籍期間、案件期間の三つを並べて確認します。
| 時点 | 書く内容 | 補足のしかた |
|---|---|---|
| 応募日 | 応募先の現行正式名称 | TISI株式会社と記載する |
| 在籍期間 | 当時の雇用主の正式名称 | 必要なら括弧で「現TISI」と補足する |
| 案件期間 | 当時の所属、顧客領域、担当 | 合併前後をまたぐ場合は期間で区切る |
| 志望理由 | 現行TISIの職種・事業への接続 | 旧会社の一般論ではなく現行募集を使う |
たとえば旧TISに在籍した経験がある人は、その在籍欄をTISIへ置換せず、当時の正式名称を残します。応募先との関係を明確にしたい場合は、注記で現TISIと示せます。合併前後をまたいで在籍している場合は、社内の正式な人事記録に沿って期間を区切ってください。
外部企業で旧TIS向け案件に参加した経験も、当時の顧客・契約・守秘義務に沿って記載します。合併を理由に、旧TIS時代の案件を現TISIでの実績だったように見せないことが重要です。
現行8職種から応募単位を決める
2026年8月22日にTISIの公式求人一覧を確認すると、プロジェクトマネージャー、アプリケーションスペシャリスト、ITアーキテクト、ITスペシャリスト、コンサルタント、データサイエンティスト、セールス、企画の区分があります。「TISIへ応募する」だけでは書類の主語が決まらないため、職種を一つ選んでください。
| 職種 | 中心となる責任 | 先に示す経験 |
|---|---|---|
| プロジェクトマネージャー | スコープ、品質、日程、コスト、リスク、関係者 | 対立条件、判断、合意、提供結果 |
| アプリケーションスペシャリスト | 業務要件、設計・実装・テスト、保守改善 | 業務課題、設計、品質、業務変化 |
| ITアーキテクト | 方式、非機能、標準、共通化、新技術判断 | 制約、比較、技術決定、複数案件への再利用 |
| ITスペシャリスト | クラウド・基盤・セキュリティ等の専門設計・運用 | 構成、移行、運用、障害、標準化 |
| コンサルタント | 課題、仮説、選択肢、意思決定、施策 | 判断を前へ進め、実行・定着させた事実 |
| データサイエンティスト | データ、分析・モデル、検証、業務利用 | データ制約、検証、本番利用、改善 |
| セールス | 顧客、アカウント、提案、社内外組成 | 顧客課題、提案仮説、合意、導入・継続 |
| 企画 | 社会・市場課題、パートナー、事業仮説、検証 | 調査、仮説変更、事業化・継続判断 |
同じ経験を複数職種へ使う場合も、強調点を変えます。クラウド案件をPM向けに書くなら提供責任、ITアーキテクト向けなら構成・方式の判断、ITスペシャリスト向けなら移行・運用・障害や標準化を主線にします。
4つの事業ドメインで案件の価値を選ぶ
TISIの公式キャリアサイトが示す正式名称は、ソーシャルイノベーションサービス(SIS)、コ・クリエーションビジネス(CCB)、IT&ビジネスオファリングサービス(IOS)、ストラテジックパートナーシップビジネス(SPB)の四つです。名称を職務要約へ入れることが目的ではありません。応募する仕事が、誰へどの形で価値を届けるかを決める材料にします。
| 公式ドメインと編集部要約 | 案件で確認する問い | 中心となる経験 |
|---|---|---|
| SIS(社会課題解決型) | 誰のどの課題を、サービスとして継続的に変えたか | 利用者、社会実装、運用、確認できる変化 |
| CCB(共創型) | パートナーと何を分担し、どの仮説を検証したか | 役割、利害調整、検証、事業化 |
| IOS(サービス・オファリング型) | 個別知見を再利用可能な仕組みにしたか | 標準化、共通化、サービス化、利用拡大 |
| SPB(戦略的パートナー型) | 顧客の中長期テーマを複数案件でどう前進させたか | 構想、統合、品質、継続改善 |
たとえば同じPMでも、顧客固有の保守開発を安定させた経験と、複数顧客へ提供するサービスを立ち上げた経験では、結果の単位が同じではありません。職種を決めた後に、仕事の性格まで絞ると主要案件を選びやすくなります。
現行募集6タイプと書くべき実績
現行募集を比べると、職種名が同じでも顧客領域と責任が異なります。次の表は、公式募集の仕事を職務経歴書へ対応させたものです。採用で各項目がどの程度重視されるかを示すものではありません。
| 公式募集要項で求める経験・仕事 | 職務経歴書に書く項目 | 成果指標 | NG表現 | 改善方向 |
|---|---|---|---|---|
| エネルギー業界の大型案件、上流、スコープ・日程・品質・価格調整、新規提案 | 顧客業務、本人の責任範囲、対立条件、合意、提供結果 | 承認、変更、品質、リリース、提案結果等の実績値 | 「大規模案件のPMを担当」 | 何を決め、誰と合意したかを書く |
| 通信業界の開発PM・PL候補 | 現在のリード範囲、支援・育成、課題・リスク、結果 | 提供、品質、課題解消、チーム状態等の実績値 | 将来PMを担いたいという希望だけ | 現在証明できる責任と将来像を分ける |
| 決済領域のWeb保守開発PM | 変更要求、影響、品質、顧客調整、保守改善 | 変更、障害、リリース、運用等の実績値 | 「決済業界未経験でも問題ない」 | 当該募集の他条件と移せる責任を確認する |
| クラウド開発・運用PM/PL | 要件、構成判断、移行、運用、リーダー責任 | 可用性、復旧、変更、運用工数等の実績値 | クラウド名を大量に列挙 | 構成を選んだ理由と運用後を示す |
| 金融Web・モバイルの横断ITアーキテクト | 非機能制約、方式、共通部品、標準、新技術判断、横断展開 | 採用、再利用、品質、生産性等の実績値 | 個別機能の実装だけ | 複数案件へ残した判断・標準を書く |
| コンサル・セールス・企画職群 | 顧客・市場課題、仮説、提案・事業設計、関係者、検証 | 承認、導入、利用、継続、事業化等の実績値 | 「DX・社会課題へ貢献」 | 誰の何を、どの判断で変えたかを書く |
取得時点では、一部の求人本文や見出しに旧TIS表記が残っていました。発行主体がTISIへ切り替わっていても、ページの社名・URL・募集状態を提出直前に確認してください。古い検索結果だけを正本にしないことが大切です。
主要案件を五つの判断で分解する
案件規模や担当工程を並べる前に、本人の意思決定を五つへ分けます。これはTISIの公式評価項目ではなく、経歴と現行募集の接点を整理する方法です。
| 判断 | 書く内容 | 確認する問い |
|---|---|---|
| 顧客・利用者の課題 | 対象業務、困っていた状態、優先理由 | なぜその案件が必要だったか |
| 制約と対立条件 | 品質、納期、コスト、制度、既存技術、利害 | 何と何が両立しにくかったか |
| 本人の決定 | 比較案、選んだ方針、見送った案 | 自分が決めた範囲はどこか |
| 合意と実行 | 顧客、社内、協力会社、パートナーとの役割 | 誰と何を合意し、何を形にしたか |
| 提供後の結果 | 利用、品質、運用、事業、標準化の変化 | 提供後に何を確認したか |
自分の担当が一部工程なら、五つすべてを自分の成果にしません。上流で決まった要件を受け取った場合は、その前提を明記し、自分が比較した技術・品質条件から書き始めます。PMでも最終承認者が別にいる場合は、自分の提案・調整と承認者の決定を分けます。
職種別のBefore・After
以下のAfterは完成文ではありません。角括弧を、自分で説明できる事実へ置き換えてください。旧TIS・旧インテック時代の案件は、当時の会社名・期間を守ります。
プロジェクトマネージャー
Before:「金融業界の大規模システム開発をPMとして成功させた」
Afterの構造:「[当時の所属・案件期間]に、[顧客・対象業務]の[課題]へ対応。[本人の責任範囲]で[品質・納期・コスト・リスク等]を比較し、[関係者]と[合意した方針]を実行。[提供後の状態]を確認した」
業界や規模は背景です。本人の責任範囲、変更時の判断、顧客との合意を主線にすると、別領域でも再現できるPM責任が見えます。
ITアーキテクト・ITスペシャリスト
Before:「クラウドやJavaを使った多くの開発案件を経験した」
Afterの構造:「[複数案件・対象システム]に共通する[非機能・保守上の課題]に対し、[比較した方式・技術]から[採用理由]を定義。[標準・共通部品・レビュー等]として展開し、[再利用・品質・生産性の変化]を確認した」
個別案件だけを担当した場合は、横断展開を加えません。その案件で扱った要件、構成判断、実装・運用までを正確に示します。横断経験は再利用された事実がある場合だけ書きます。
コンサルタント・セールス・企画
Before:「顧客のDXと新規事業の推進に貢献した」
Afterの構造:「[顧客・市場]の[経営・業務課題]に対し、[調査・データ]から[仮説と選択肢]を作成。[顧客・技術・パートナー]の[対立条件]を整理して[決定・検証]へ進め、[導入・利用・事業化の状態]を確認した」
コンサルは意思決定と実行、セールスは提案と顧客関係、企画は仮説検証と事業化を中心にします。同じ案件へ参加しても、本人が負った責任に合わせて成果を分けてください。
募集要項を「満たす・隣接・不足」へ分ける
中途採用の対策は、現行募集の仕事・条件と経歴を照合することから始めます。「TIS出身だから分かる」「大手IT企業で働いたから近い」と会社名だけで判断せず、責任と経験を一つずつ対応させます。
| 区分 | 書類での扱い | TISIの募集での確認例 |
|---|---|---|
| 満たす | 職務要約と最初の案件で、期間・責任・結果を示す | 上流工程、PM/PL、クラウド開発・運用、横断設計等 |
| 隣接 | 共通責任と、未経験の業界・工程・規模を分ける | 別業界のPM、別基盤、個別案件の設計、他商流の営業等 |
| 不足 | 経験済みに見せず、別募集や準備行動を検討する | 個別募集固有の業務知識、経験期間、技術、責任範囲等 |
決済領域のWeb保守開発PM募集には、当該業界経験を問わない旨があります。しかし、これはその募集に関する記載です。すべての金融系募集で業界経験が不要とはいえません。有利・不利を一般化せず、応募するページの全条件を確認します。
規模と本人の責任を分ける
TISIの現行募集には、大型案件、社会インフラ、複数ベンダー、横断組織などの仕事があります。案件の大きさは重要な背景ですが、候補者の実績は別です。会社・チーム全体と本人の経験を二段で書きます。
| 背景 | 全体情報 | 本人の経験 |
|---|---|---|
| 大型案件 | 対象、期間、体制、提供結果 | 担当範囲、判断権限、リスク・変更、合意 |
| 社会インフラ | 利用者、止められない理由、品質要求 | 扱った非機能要件、設計・運用判断、検証 |
| 複数ベンダー | 全体体制、役割分担 | 争点、依存関係、合意、本人が変えた運営 |
| 横断技術 | 対象案件・組織 | 標準、共通部品、採用判断、再利用された結果 |
実績値を使う場合も、案件全体の数字と自分の担当指標を分けます。自分の寄与を説明できなければ、承認、リリース、移行、標準採用、運用定着等の確認可能な状態変化へ戻してください。
職務要約・志望理由・面接を一致させる
職務要約では、応募職種と再現できる責任を第1文で示します。志望理由では、その責任をTISIのどの顧客・仕事の性格で広げるかを書いてください。面接では、主要案件の判断を同じ時系列で説明します。
| 場所 | 答えること | そろえる情報 |
|---|---|---|
| 職務要約 | どの職種で何を任せられるか | 顧客領域、責任、代表結果 |
| 主要案件 | その責任を何で証明するか | 課題、制約、決定、合意、結果 |
| 志望理由 | 現行TISIのどの仕事へ接続するか | 職種、顧客・事業ドメイン、広げたい責任 |
| 面接 | 書類の因果を深掘りして説明できるか | 比較案、権限、失敗・修正、実績値の根拠 |
「TISで知られていた事業に関心がある」といった過去の会社理解だけで終わらず、現行TISIの募集ページで役割を確認します。反対に、合併後の会社像を語るために、まだ経験していない統合後の仕事を自分の実績へ混ぜないでください。
2026年度の移行情報をどう読むか
TISI公式ページは、2026年度は旧両社の人事制度を並行運用し、2027年度から統合制度を導入予定と注記しています。職務経歴書で制度を説明する必要はありませんが、移行中の情報を恒久的な評価基準とみなさないために押さえておきたい点です。
旧TIS時代の制度や社員記事を見つけても、それが現在のすべての職種へ同じ形で適用されるとは断定できません。本記事では、現行募集の仕事内容と応募条件だけを書類の直接根拠にします。制度や働き方は、選考中に公式情報と担当者へ確認してください。
提出前チェック
- 応募先をTISI株式会社と記載したか
- 旧TIS・旧インテック時代の在籍名を、当時の正式名称で残したか
- 求人ページの発行主体、社名、募集状態、URLが最新か確認したか
- 現行8職種から応募職種を一つ選んだか
- 顧客・事業ドメインまで絞ったか
- 案件規模と本人の判断を分けたか
- 現在の経験と入社後に広げたい責任を分けたか
- 実績値の対象期間・母数・算出方法を説明できるか
- 職務要約、志望理由、面接の説明が現行TISIの同じ募集へ向いているか
よくある質問
応募書類にはTISとTISIのどちらを書きますか?
2026年7月1日以降の現行応募先はTISI株式会社です。過去の在籍・案件は、その時点の正式社名を使います。現在の応募先と過去経歴を同じ名称へ統一しないでください。
旧TISに在籍していた経歴はTISIへ変更しますか?
遡って変更しません。在籍期間中の正式社名を記載し、必要なら「現TISI」と補足します。合併前後をまたぐ在籍は、正式な人事記録に沿って整理してください。
求人ページに旧TIS表記が残っている場合はどうしますか?
検索結果の見出しだけでは、現行募集かどうかを判断できません。公式求人一覧からページを開き、発行主体、募集状態、職種名、条件を確認してください。応募フォームの案内に従い、現行の正式名称を使います。
複数職種へ同じ職務経歴書を提出できますか?
在籍期間や案件の事実は共通です。ただし、PM、アーキテクト、コンサルタント、セールスでは証明すべき責任が違うため、職務要約と案件の掲載順を組み替えます。
数値で示せる成果がない場合はどうしますか?
承認、リリース、移行完了、標準採用、運用定着など、確認できる状態変化を書きます。数字は作らず、使う場合は対象期間・母数・算出方法を説明できる値に限ります。
まとめ
TISI(旧TIS)向けの職務経歴書では、2026年7月1日の商号変更を踏まえ、現行応募先と過去経歴の時間軸を分けることが最初の条件です。そのうえで、現行職種と顧客・事業ドメインを決め、課題、制約、本人の決定、合意、提供後の結果をつなぎます。旧情報だけで提出せず、最後にTISI公式の最新募集ページを確認してください。

