SIerとWeb系の違いと転職の実態｜違い・年収・経験の活かし方を解説

「SIerからWeb系に転職したいが、ついていけないのではないか」「年収が下がって後悔しないか」「業務でモダンな技術を使っていないのでポートフォリオがない」。こうした不安から、転職に踏み出せない方は少なくありません。結論からお伝えすると、SIerからWeb系への転職は十分に可能であり、要件定義や設計、顧客折衝といったSIerでの経験は、伝え方を整えればWeb系企業でも評価されます。

この記事では、SIerとWeb系の違いやメリット・デメリットに加え、「Web系」を企業タイプごとに分けて自分に合う転職先を見極める方法、年収の正しい比較の仕方、経験の伝え方、入社後に「ついていけない」を防ぐ準備まで、順を追って解説します。

SIerからWeb系への転職は可能？難易度と転職市場の実態

SIer出身者のWeb系転職は珍しくない

結論からお伝えすると、SIerからWeb系企業への転職は十分に可能であり、エンジニアの転職市場では一般的なキャリアパスの一つです。Web系企業の求人では、要件定義や設計、プロジェクト推進といったSIerでの業務経験を評価する企業が増えています。

背景には、Webサービスを運営する企業の多くが事業の拡大とともに大規模なシステム構築や法人顧客への対応を求められるようになり、SIerで培われた進め方の知見を必要としていることがあります。未経験者と同じ枠で評価されるわけではなく、業務経験者として応募できるポジションが存在する点を、まず押さえておいてください。

「難しい」「後悔する」と言われる理由

一方で、SIerからWeb系への転職が「難しい」「後悔する」と言われるのには、大きく3つの理由があります。

1つ目は、業務でモダンな技術に触れる機会が少なく、実装スキルを示しにくいことです。2つ目は、仕様書通りに作ることが評価される環境から、自分で判断して動くことを求める環境へ移るため、文化の違いに適応するまで時間がかかることです。3つ目は、残業代や手当を含めた年収や待遇の構成が変わり、額面が一時的に下がる可能性があることです。いずれも事前に対処できる課題であり、この記事では各章で具体的な準備の方法を解説します。

評価されやすい人・苦労しやすい人の違い

Web系企業の選考で評価されやすい人と苦労しやすい人の違いは、技術力の高さだけで決まるものではありません。評価されやすいのは、分からないことを自分で調べて動ける姿勢を持ち、SIerでの経験を「どんな課題をどう解決したか」という形で言語化できる人です。

反対に、担当した工程や使った製品の名前を並べるだけで、自分の判断や工夫を説明できない人は苦労しやすい傾向があります。つまり、準備すべきことは新しい言語を一から学ぶことだけではなく、経験の棚卸しと伝え方の整理です。この記事では、その具体的な方法を順を追って説明していきます。

SIerとWeb系企業の違い（仕事内容から文化・働き方まで）

仕事内容・担当する開発工程の違い

SIerとWeb系企業の違いは、まず業務内容と担当する開発工程に表れます。

SIerでは顧客企業のシステムを受託で構築するため、要件定義、設計、開発、テスト、運用保守といった工程が分業され、年次が上がるほど管理や調整の業務が中心になります。一方、Web系企業では自社のWebサービスやアプリを開発するため、企画から実装、リリース、運用、改善までを一人のエンジニアが幅広く担うことが多いです。

整理すると次のようになります。

比較項目	SIer	Web系企業
開発対象	顧客企業のシステム	自社のサービス・プロダクト
担当範囲	工程ごとの分業	企画から運用まで幅広く担当
成果の指標	納期と品質の達成	ユーザーの反応や事業の数値

開発手法とスピード感の違い（ウォーターフォールとアジャイル）

開発手法の違いも、SIerとWeb系で働き方が変わる大きな要因です。SIerでは、要件を固めてから設計、開発、テストと順に進めるウォーターフォール型が主流で、計画を重視し、手戻りを避けることが求められます。

Web系企業では、小さく作ってリリースし、ユーザーの反応を見ながら改善を繰り返すアジャイル開発が広く採用されており、スピード感を重視します。ご自身の経験と照らし合わせると、「計画通りに進める力」はSIerで鍛えられている一方、「不確実な状態で判断して前に進める経験」は不足しているケースが多いはずです。この差を認識しておくことが、入社後の適応を早めます。

使用する技術・開発環境の違い

使用する技術や開発環境にも違いがあります。SIerではJavaや顧客指定のパッケージ製品、オンプレミスのサーバー環境を扱うことが多く、バージョンも安定重視で古いものが使われがちです。

Web系企業ではTypeScriptやReact、Python、Goといった言語やフレームワーク、AWSなどのクラウド環境、GitHubを使ったコードレビューの運用が一般的です。ただし、設計の考え方やデータベースの知識、テストや運用の経験はそのまま活きます。補う必要があるのは主にモダンな言語とクラウド、Gitを使ったチーム開発の進め方であり、ゼロから学び直すわけではありません。

働き方・評価制度・コミュニケーションの違い

「ついていけない」と感じる原因の多くは、技術ではなく働き方や評価制度、コミュニケーションの違いにあります。SIerでは、仕様書通りに正確に作り、ミスを出さないことが評価されるため、自分の判断で仕様を変えることは避けるのが基本です。

Web系企業では、自ら課題を見つけて提案し、改善した成果が評価されるため、指示を待つ姿勢はマイナスに受け取られやすいです。また、Slackなどのテキストを中心にした非同期のコミュニケーションが主流で、会議や口頭での調整に慣れた人は戸惑うことがあります。この文化の違いこそが適応の壁であり、後の章で入社前からできる準備を説明します。

生成AI・内製化の進展で両者の将来性はどう変わるか

生成AIの普及と企業のシステム内製化は、SIerとWeb系の両方に変化をもたらしています。SIer側では、コードやテストの一部をAIが生成できるようになったことで、工数を積み上げて請求する従来の事業モデルに見直しの圧力がかかり、下流工程の案件が減る懸念が指摘されています。

Web系企業側でも、実装そのものの価値は相対的に下がり、何を作るべきかを決める企画力や、要件を整理して技術を選ぶ判断力の重要性が高まっています。この流れは、SIerで要件定義や関係者との調整を担ってきた人にとって、むしろ経験の価値が見直される方向に働いています。どちらか一方だけが安泰という状況ではありません。

SIerからWeb系に転職するメリット・デメリット

メリット：開発に直接関わる機会、技術の幅、ユーザーの反応が見えること

SIerからWeb系企業へ転職する主なメリットは、次の3点です。

• コードを書く時間が増え、技術者としての実感を取り戻せる
• モダンな言語やクラウド、アジャイル開発を実務で経験でき、技術の幅が広がる
• 自社サービスの改善に関わるため、ユーザーの反応や事業の数値を直接確認できる

SIerでは年次が上がるほど進捗管理や顧客との調整が中心になり、設計書やExcelでの資料作成に時間を取られがちです。Web系企業では、自分が実装した機能がリリースされ、使われ方が数値で見えるため、仕事の成果を実感しやすくなります。また、継続的に新しい技術に触れる環境は、中長期でエンジニアとしての市場価値を高めることにもつながります。

デメリット・注意点：年収の変動、学び続ける必要、文化への適応

デメリットや注意点として押さえておきたいのは、次の3点です。

• 残業代や手当の構成が変わり、額面の年収が一時的に下がる可能性がある
• 技術の変化が速く、業務時間外も含めて学び続けることが前提になる
• 自分で判断して動く文化に慣れるまで、評価されにくい期間がある

ただし、これらは対処法のある課題です。年収については企業タイプの選び方と比較の仕方で差が出ますし、学習は志望する企業に合わせて優先順位をつければ負担を抑えられます。文化への適応も、入社前に何が起きるかを知っておけば心構えができます。不安を増やすためではなく、後の章で解決策を示すための整理として受け取ってください。

「Web系」は一枚岩ではない｜SIer出身者に合う企業タイプの見極め方

自社開発スタートアップ・メガベンチャー

「Web系」と聞いて多くの人が思い浮かべるのが、自社開発のスタートアップやメガベンチャーです。少人数で自社プロダクトを開発するスタートアップは、スピードと裁量が大きく、企画から実装まで幅広く関われる反面、ドキュメントや研修が整っていないことが多く、自走力が強く求められます。

メガベンチャーは組織や制度が整っている分、選考で実装スキルを厳しく見られる傾向があります。SIer出身者が活躍しやすいのは、サービスが成長して大規模化し、設計の見直しや品質管理、他部門との調整が課題になっている段階の企業です。求人票だけでなく、企業の成長段階も確認して選ぶことをおすすめします。

BtoB SaaS企業：大規模・企業向けの経験が活きやすい

SIer出身者と相性が良い選択肢として注目したいのが、企業向けにクラウドサービスを提供するBtoB SaaS企業です。顧客が法人であるため、業務フローの理解、セキュリティ要件への対応、顧客の情報システム部門との折衝、大規模な導入プロジェクトの推進といった、SIerで日常的に行ってきた業務がそのまま評価されます。

開発環境はモダンな技術とアジャイル開発が中心であるため、Web系で働く実感も得られます。金融や製造、物流など特定の業種に特化したSaaS企業であれば、その業界のシステム構築に携わった経験は大きな強みになります。年収水準も比較的安定しており、現実的な転職先になりやすい領域です。

事業会社のDX・内製化部門、Web系受託開発

自社のシステム開発を外注から内製に切り替えている事業会社のDX推進部門や社内SEのポジションも、SIer経験が活きる選択肢です。事業会社では、ベンダーとして関わってきた立場から発注側に回るため、要件を整理して開発を進める力や、ベンダーの管理経験がそのまま役立ちます。

残業が比較的少なく、安定した働き方を望む人に向いています。また、Web系の受託開発企業は、顧客のWebサービスやアプリを開発する形態で、受託という点ではSIerと共通する一方、技術はモダンで案件の期間も短い傾向があります。SIerの進め方に慣れた人が、Web系の技術と文化に段階的に移行する足がかりとして選ぶケースもあります。

年収維持・技術・安定のうち何を優先するかで選ぶ

ここまで見てきた企業タイプは、それぞれ得られるものと求められるものが異なります。自分の優先順位を明確にして選択肢を絞ることが、後悔を防ぐ第一歩です。

優先したいこと	相性の良い企業タイプ
技術の幅と裁量	自社開発スタートアップ、メガベンチャー
年収水準の維持と業務経験の評価	BtoB SaaS企業
安定した働き方と上流経験の活用	事業会社のDX・内製化部門
段階的な技術の移行	Web系受託開発企業

すべてを同時に満たす企業は少ないため、「年収は維持したいが技術は最新がよい」といった希望は、どちらを優先するか順位をつけておくと判断がぶれません。転職活動の最初にこの整理をしておくと、求人の見方が変わります。

SIerからWeb系への転職で年収は下がる？考え方の整理

年収が下がりやすいケース・維持しやすいケース

SIerからWeb系への転職で年収が下がるかどうかは、どの枠で応募するかによって大きく分かれます。下がりやすいのは、実装経験が少ない状態で自社開発企業のエンジニア職に応募し、未経験に近いポテンシャル枠で評価されるケースです。この場合、SIerでの年次や役職は考慮されにくくなります。

一方、維持しやすいのは、要件定義や設計などの上流経験、特定業種の業務知識、プロジェクト推進の実績を評価するBtoB SaaS企業や事業会社に応募するケースです。これらの企業では、SIerでの経験が即戦力として評価されます。つまり、年収は「Web系に行くか」ではなく「どの企業タイプのどの職種を選ぶか」で決まります。

提示年収だけで比較しない：残業代・手当・労働時間を含めて見る

年収を比較する際は、提示された金額の額面だけで判断しないことが大切です。SIerの年収には、残業代や住宅手当、家族手当などが含まれていることが多く、基本給の割合は見た目より低い場合があります。Web系企業では、みなし残業を含んだ年俸制や、手当が少ない代わりに基本給が高い構成が一般的です。そのため、比較の際は次の点を確認してください。

• 基本給と残業代、手当の内訳
• みなし残業の有無と時間数
• 実際の平均残業時間と、残業が減った場合の実質的な時給

残業が月40時間から10時間に減るなら、額面が同じでも時間あたりの収入は大きく変わります。労働時間を含めた全体で比較してください。

中長期で市場価値がどう変わるかという視点

年収は転職直後の条件だけでなく、3年後、5年後の市場価値がどう変わるかという時間軸でも考える必要があります。SIerで調整や管理の業務が中心のまま30代後半を迎えると、技術の実務経験が乏しくなり、転職市場での選択肢が狭まるリスクがあります。一方、Web系企業でモダンな技術とアジャイル開発の実務経験を積めば、上流工程の経験と組み合わせて評価されるポジションが広がり、数年後の年収の上限が上がる可能性があります。

転職直後に年収を下げられない事情がある人は、年収を維持しやすい企業タイプを選びつつ、将来の選択肢を広げる経験が積めるかを確認するという両立の視点で判断してください。

Web系企業で評価されるSIerの経験と、その伝え方

要件定義・設計など上流工程の経験

SIerで培った要件定義や設計の経験は、Web系企業でも高く評価される資産です。顧客の曖昧な要望を聞き取り、業務を整理して仕様に落とし込む力は、プロダクト開発における要求整理や、機能の優先順位づけに直結します。

また、基本設計や詳細設計で非機能要件やデータ構造を検討してきた経験は、技術選定の理由を説明したり、設計レビューで議論したりする場面で役立ちます。Web系企業の中には、サービスの成長に伴ってシステムが複雑化し、設計を見直せる人材を求めているところも多いです。「設計書を書いた」ではなく、「どんな制約の中で何を判断して設計したか」を伝えられるように整理しておきましょう。

品質管理・テスト・運用保守・障害対応の経験

本番稼働するシステムを支えてきた品質管理やテスト、運用保守、障害対応の経験も、Web系企業で重視されます。Webサービスは24時間稼働が前提であり、障害が発生すれば事業に直接影響するため、安定運用を担える人材は常に不足しています。

テスト計画を立てて網羅的に検証した経験、障害発生時に原因を切り分けて根本対策まで進めた経験、顧客への報告と再発防止をまとめた経験は、どれも具体的なエピソードとして語れます。SIerでは当たり前に行ってきたことでも、Web系企業では属人的に処理されていることが少なくありません。品質への意識と手順を整えて進める力は、差別化できる強みとして伝えてください。

顧客折衝・調整・プロジェクト推進の経験

顧客との折衝や関係者の調整、プロジェクト推進の経験は、職種を問わず求められる能力です。Web系企業では、エンジニアが営業や企画、マーケティングなどビジネス側のメンバーと直接協働する機会が多く、要望を聞き取って技術的な制約を説明し、合意をつくる力が必要になります。

SIerで顧客や協力会社との間に立ち、納期や仕様の調整を進めてきた経験は、まさにこの場面で活きます。また、複数のメンバーを率いて進捗を管理し、課題を解決してきた経験は、将来テックリードやエンジニアリングマネージャーを目指す際の土台になります。「調整ばかりで技術から離れた」と感じている経験こそ、伝え方を変えれば評価の対象になります。

SIerの経験をWeb系の言葉に置き換える方法

SIerの経験を職務経歴書や面接で伝える際のポイントは、「何を担当したか」ではなく「どんな課題に対して、何を判断し、どう解決したか」を軸に書き直すことです。具体的には、次の形で整理すると伝わりやすくなります。

• 状況：プロジェクトの規模、体制、制約
• 課題：直面した問題と、放置した場合の影響
• 判断と行動：自分が考えた選択肢と、選んだ理由
• 結果：品質、納期、工数などに表れた成果

また、SIer特有の用語は一般的な言葉に置き換えてください。「ベンダーコントロール」は「外部パートナーとの開発推進」と表現すると、Web系企業の担当者にも伝わります。面接でも、この整理をもとにエピソードを話せるようにしておきましょう。

ポートフォリオは必要？開発経験が少ないSIer出身者の対処法

ポートフォリオが求められるケース・なくても進めるケース

ポートフォリオが必要かどうかは、応募する企業タイプと職種によって異なります。求められやすいのは、実装力を重視する自社開発企業のエンジニア職や、未経験に近い枠での応募です。この場合、GitHubのコードで実装スキルを確認されることがあります。

一方、上流経験や業務知識を評価するBtoB SaaS企業、事業会社のDX部門、プロジェクトマネジメントに近い職種では、ポートフォリオが必須でないことが多く、職務経歴書と面接での説明が中心になります。「ポートフォリオがないから応募できない」と考える前に、志望する企業が何を見ているのかを確認してください。業務経験者の枠を選べば、有無は決定的な要素ではなくなります。

業務経験を示す代替手段：設計や技術選定の考え方を文章にする

守秘義務があり業務のコードを公開できない場合でも、実務能力を伝える方法はあります。有効なのは、担当したシステムの設計の考え方や技術選定の判断、障害対応の進め方を、固有名詞を伏せて一般化した文章にまとめることです。

たとえば、「大量データのバッチ処理で性能要件を満たすために、処理方式を比較してどう選定したか」「本番障害の原因をどう切り分け、再発防止策をどう設計したか」といった内容は、コードがなくても技術的な判断力を示せます。これを職務経歴書の補足資料や技術ブログの記事として用意しておくと、面接で深掘りされた際にも具体的に答えられます。業務経験者には、未経験者のポートフォリオとは別の土俵があります。

GitHub・技術ブログを無理のない範囲で使う

GitHubや技術ブログは、大作を用意する必要はなく、無理のない範囲で使えば十分です。目的は高度な成果物を見せることではなく、学ぶ姿勢と文章で説明する力を示すことです。

たとえば、学習中の言語で書いた小さなツール、業務で得た知見を一般化した記事、読んだ技術書のまとめなどを継続的に公開するだけでも、採用担当者には「自分で調べて学び続けられる人」という印象が伝わります。特に技術ブログは、SIerで鍛えられたドキュメント作成力を活かせる手段であり、Web系企業で重視されるテキストコミュニケーションの力を示す材料にもなります。平日の業務と並行する前提で、週に1回程度の更新から始めることをおすすめします。

限られた時間で優先して学ぶ技術

学習に使える時間が限られる人は、志望する企業タイプに応じて優先順位をつけることが大切です。

志望する企業タイプ	優先して学ぶ技術
自社開発企業全般	Gitでのチーム開発、モダンな言語1つ
BtoB SaaS企業	クラウド（AWSなど）の基礎、API設計、認証やセキュリティ
事業会社のDX部門	クラウドの基礎、アジャイル開発の進め方

共通して最初に取り組むべきなのは、GitHubを使ったチーム開発の流れです。プルリクエストやコードレビューはどのWeb系企業でも日常的に使うため、知らないと入社後に最初につまずきます。言語はJavaの知識を土台に、1つに絞って進めると効率的です。

転職後に「ついていけない」を防ぐために入社前から準備すること

仕様書がない環境でのキャッチアップの進め方

Web系企業に入社して最初に戸惑うのが、整った仕様書や設計書が存在しないことです。SIerでは文書化された仕様を読めば業務を把握できましたが、Web系企業ではコードそのものや、GitHubのコミット履歴、プルリクエストのやり取り、Slackの過去の会話が仕様の代わりになっていることが多いです。

この環境でキャッチアップを進めるには、コードを読んで自分なりに仕様を整理し、「このように理解したが正しいか」と確認する進め方が有効です。整理した内容を簡単なドキュメントにして共有すれば、チームにも貢献できます。SIerで培った読解力と文書化の力は、ドキュメントが不足している現場でこそ価値を発揮します。

非同期・テキストコミュニケーションへの慣れ方

Web系企業では、Slackなどのテキストを中心にした非同期のコミュニケーションが主流です。会議や口頭での確認に慣れた人は、「質問しづらい」「反応が遅くて不安」と感じることがあります。この環境で信頼を得るためには、次の行動が役立ちます。

• 質問する前に自分で調べた内容と、現時点での仮説を添えて相談する
• 作業の進捗や判断の理由を、聞かれる前に文章で残す
• 相手の返答を待つ間に進められる作業を並行して進める

これらは、SIerで報告書や議事録を書いてきた人には取り組みやすい行動です。重要なのは、沈黙を「放置されている」と受け取らず、文章で状況を見える形にしておくことです。

「言われた通りに作る」から「自分で判断して提案する」への切り替え

もう一つの大きな切り替えは、評価の軸がミスを避けることから、改善を積み重ねることに変わる点です。SIerでは、仕様書通りに作り、不具合を出さないことが評価されるため、「勝手に判断してはいけない」という意識が身についています。

Web系企業では、小さく試して改善する姿勢が求められ、自分で判断して提案することが期待されます。最初は、コードレビューで多くの指摘を受けることが普通であり、それは能力の否定ではなく、チームの基準を共有するための過程です。「完璧に仕上げてから出す」のではなく、「早めに出して意見をもらい、改善する」進め方に切り替えてください。入社前に知っておくだけでも、受け止め方が変わります。

それでも合わなかったときの考え方

準備をしても、入社した環境が合わないと感じることはあります。その場合に押さえておきたいのは、環境との相性は個人の能力とは別の問題であり、キャリアの失敗ではないということです。Web系企業で経験したモダンな技術やアジャイル開発の知見は、SIerや事業会社の内製化部門に戻る際にも評価されます。実際に、Web系企業を経験した後にSIerや事業会社へ再転職し、両方の文化を知る人材として活躍するケースもあります。

大切なのは、合わなかった理由を「技術か、文化か、企業の規模か」と具体的に整理し、次の選択に活かすことです。選択肢が一方向だけではないと知っておくと、転職の判断を冷静に行えます。

後悔しない企業選びの確認ポイントと転職活動の進め方

自社開発・受託・SESの区別と開発体制・裁量の確認

求人票の「Web系」「自社開発」という表現だけでは、実際の事業形態が分かりにくいことがあります。自社開発を掲げていても、売上の大半が受託やSESで、自社サービスは一部にとどまる企業もあります。確認したいのは、次の点です。

• 売上の中心が自社サービスか、受託か、SESか
• 配属予定のチームが担当するプロダクトと役割
• 技術選定や設計の意思決定を、エンジニアがどこまで担っているか

SESの場合は客先常駐が中心になり、SIerと働き方が大きく変わらない可能性があります。開発体制と裁量の実態は、企業の公開情報や面談で直接確認してください。入社後のギャップを防ぐうえで、最も重要な確認事項の一つです。

教育体制・レビュー文化・入社後サポートの確認

「ついていけない」を防ぐ鍵は、企業側の受け入れ体制にもあります。確認したいのは、入社後のオンボーディングの有無と内容、コードレビューの文化、質問しやすい環境かどうかの3点です。

オンボーディングが整っている企業では、最初の数週間で開発環境の構築やコードの構造を学ぶ期間が設けられ、メンターがつくこともあります。コードレビューが活発な企業は、指摘を通じて学べる機会が多く、SIer出身者がモダンな書き方を身につけやすい環境です。反対に、中途入社者がすぐ一人で成果を出すことを前提とする企業は、適応に苦労する可能性があります。求人票に書かれていないことが多いため、面談で確認してください。

カジュアル面談・面接で確認したい質問

カジュアル面談や面接は、企業を見極める場でもあります。入社前に確認しておきたい質問の例を挙げます。

• 開発プロセスはどのように進めていますか。スプリントの期間やリリースの頻度を教えてください
• 設計書や仕様書など、ドキュメントはどの程度整備されていますか
• エンジニアの評価は、どのような基準で行われますか
• 平均的な残業時間と、リモートワークの運用を教えてください
• 中途入社した方は、入社後どのように立ち上がっていますか

「自分の経験をどう活かせるか知りたい」という前向きな文脈で質問すると、意欲も伝わります。回答の具体性は、企業の体制を判断する材料になります。

転職エージェント・スカウトサービスの使い方

転職活動を進めるうえで、IT・エンジニア領域に特化した転職エージェントやスカウトサービスは有効な手段です。SIer出身者の経験がどの企業タイプで評価されるかを理解したキャリアアドバイザーであれば、求人票だけでは分からない開発体制や文化を踏まえて企業を提案してくれます。

活用のポイントは、年収、技術、働き方のうち何を優先するかを最初に明確に伝えることと、職務経歴書を前章の形で整理してから相談することです。希望が曖昧なままだと、提案される求人も広がりすぎます。スカウトサービスでは、経歴を具体的に書くほど、SIer経験を求める企業からの連絡が届きやすくなります。複数の手段を併用して進めてください。

SIerからWeb系への転職に関するよくある質問

まとめ：「どのWeb系か」と「入社後の準備」で後悔を防ぐ

SIerからWeb系への転職は十分に可能であり、要件定義や設計、品質管理、顧客折衝といったSIerでの経験は、伝え方を整えればWeb系企業でも評価されます。

後悔を防ぐ鍵は2つあります。1つは、「Web系」を自社開発スタートアップ、BtoB SaaS企業、事業会社のDX部門、Web系受託開発に分けて、年収、技術、安定のうち何を優先するかで選ぶことです。もう1つは、仕様書のない環境でのキャッチアップ、テキスト中心のコミュニケーション、自分で判断して提案する姿勢といった入社後の変化を、入社前から知って準備しておくことです。まずは、経験を課題と判断と結果の形で棚卸しすることから始めてください。