エンジニアのオンボーディング90日計画｜30・60・90日の到達目標

エンジニアのオンボーディング90日計画は、期間ごとの業務一覧ではなく、入社前・30日・60日・90日の各確認時点に、到達目標、支援者、確認材料を対応づけると作りやすくなります。評価基準は「慣れた」「自走した」といった印象ではなく、合意した業務計画、研修ニーズ、パフォーマンス基準、フィードバックで確かめます。

30日・60日・90日は、制度や公的な標準が定めた合格時点ではありません。自社で到達状況を確認するために置く、設計上の節目です。では、何をもって次の段階へ進めると判断するのか。答えは、本人の成果だけでなく、任せる役割、周囲との協働、支援の実施を同じ工程で確認することです。

エンジニアのオンボーディング90日計画を一枚で捉える

工程の中心は、入社前から90日まで切れ目なく続く確認の流れです。

入社前
  到達目標：担当する役割と、最初に取り組む業務の認識がそろっている
  支援者　：採用担当 ─ EM ─ CTO
  確認材料：職務記述・業務計画・パフォーマンス基準
      │
      ▼
30日［第1確認時点］
  到達目標：担当業務を進め、必要な支援と学習課題を説明できる
  支援者　：EM ─ Buddy／Mentor ─ チームメンバー
  確認材料：業務計画・研修ニーズ評価・フィードバック
      │
      ▼
60日［第2確認時点］
  到達目標：担当範囲で設計・実装・運用の期待を担い、関係職種と連携できる
  支援者　：EM ─ CTO ─ 関係職種
  確認材料：業務計画・パフォーマンス基準・研修ニーズ評価結果
      │
      ▼
90日［第3確認時点］
  到達目標：役割と協働の到達状況を説明し、次の開発課題を合意できる
  支援者　：本人 ─ EM ─ CTO
  確認材料：フィードバック・個人開発計画・工程への本人評価

この図は全員を同じ速度で進ませる採点表ではありません。各確認時点で「目標に対して何を確認できたか」「次にどの支援が必要か」を話し合うための設計図です。到達が未確認なら、本人の能力だけに理由を求めず、役割の伝達、業務付与、面談、学習機会が予定どおり提供されたかも点検します。

入社前：役割と評価の土台をそろえる

入社前に採用担当からEMへ渡すべきものは、選考の感想ではなく、入社後に使える役割情報です。EMは職務記述を業務計画へつなぎ、CTOはチームや事業の期待と矛盾していないかを確認します。本人が入社した後に初めて評価基準を知る状態を避けるため、パフォーマンス基準もこの段階で言葉をそろえます。

役割の範囲は、自社の開発体制と採用時の合意を優先して決めます。そのうえで参考になるのが、IPAのDX推進スキル標準にあるソフトウェアエンジニアの役割記述です。そこでは、デジタル技術を活用した製品・サービスのためのシステムやソフトウェアについて、設計・実装・運用を担う役割とされています。これは90日計画の公式標準ではなく、到達目標の抜けを確かめるための参照枠です（IPA「DX推進スキル標準（DSS-P）概要」、2026年8月22日確認）。

IPAの資料ダウンロードページには、デジタルスキル標準ver.2.0の全体版・スキルリストと、DX推進スキル標準のソフトウェアエンジニア編が最新版資料として掲載されています。同ページの公開日は2026年4月16日、更新日は2026年7月9日です（IPA「資料ダウンロード｜デジタルスキル標準」、2026年8月22日確認）。参照日と版を残しておけば、後から役割記述が変わった場合も、自社の計画を見直す起点が明確になります。

30日：活動量ではなく、仕事と支援の接続を確認する

30日目は第1確認時点です。ここで見るのは、研修を終えたかという項目だけではありません。本人が担当業務を進めるうえで、期待される役割を理解し、必要な支援と学習課題を説明できる状態を目標にします。

EMは上司として接点を予定し、BuddyまたはMentorは日々の相談経路を担い、チームメンバーは担当業務に関わる認識をそろえます。採用担当は、入社前に合意した役割が現場へ正しく引き継がれているかを確認します。役割ごとの確認材料は次のように置けます。

• 本人とEM：業務計画とパフォーマンス基準を見ながら、期待と実際の差を確認する
• EMとBuddy／Mentor：相談経路が機能しているか、追加の支援が必要かを確認する
• 本人とEM：研修ニーズ評価とフィードバックを、次の開発課題へ結びつける

確認材料が残ることで、「順調そう」という感触を、次の支援を決められる判断へ変えられます。

この組み方は、OPM自身が公開する新入職者向けチェックリストの構成とも整合します。同資料は、上司が活動と主要人物との面談をあらかじめ予定し、本人と上司がチェックリストで追跡する形を示しています。初期工程には上司との接点、BuddyまたはMentorの紹介、チームメンバーとの面談、最初の業務付与、職務記述と業務計画の確認が含まれます。また、初期の確認材料には研修ニーズ評価、パフォーマンス基準、上司とのフィードバックセッションが挙げられています（U.S. Office of Personnel Management「New Employee Checklist」、2026年8月22日確認）。

60日：担当範囲と協働の質を同時に見る

60日目は第2確認時点です。設計・実装・運用のうち本人が担う範囲について、期待された仕事を進められているかを確認します。ただし、個人の作業だけを見て「立ち上がった」と判断するのは不十分です。

IPAのDX推進スキル標準は、DX推進人材について、他類型とのつながりを構築し、巻き込みや手助けを行い、複数類型で協働関係を構築して連携することの重要性を示しています（IPA「DX推進スキル標準（DSS-P）概要」、2026年8月22日確認）。そのため、工程図の到達目標には関係職種との連携も含めます。

EMは業務計画とパフォーマンス基準をもとに担当範囲を確認し、CTOは技術上の期待と組織の優先事項との接続を確認します。関係職種は、協働に必要な情報共有や役割分担が成立しているかを確かめます。確認結果は、本人への評価だけで終わらせず、研修ニーズ評価結果と照らして支援の更新に使います。

採用から受け入れまでの責任を社内でつなぐ考え方は、エンジニア採用を内製化する支援の考え方も参考になります。また、入社前の期待形成を整えるなら、エンジニアのオファー承諾を支える設計とオンボーディング計画を分断しないことが大切です。

90日：合否ではなく、次の合意を作る

90日目は第3確認時点です。本人は、自分が担う役割、担当業務の到達状況、関係職種との協働、残っている学習課題を確認材料に沿って説明します。EMは業務計画とフィードバックをつなぎ、CTOは次に担う範囲と組織の優先事項との関係を確認します。

OPMのチェックリストでは、後続工程として、研修ニーズ評価結果を上司と確認して個人開発計画を作ること、研修機会と組織の戦略的優先事項を確認すること、オリエンテーション工程を評価して調査でフィードバックすることが示されています（U.S. Office of Personnel Management「New Employee Checklist」、2026年8月22日確認）。したがって90日目は、本人だけを評価して工程を閉じる日ではなく、次の個人開発計画を合意し、受け入れ工程そのものも見直す節目にします。

評価基準を運用できる形にする

評価基準は、抽象的な人物像ではなく、工程図の列を横に読むと作れます。「到達目標に合意したか」「支援者が必要な接点を持ったか」「確認材料で到達状況を説明できるか」を同じ場で確認します。採用担当、EM、CTOの分担も、入社前だけ、現場だけ、最終確認だけに閉じません。

• 採用担当：入社前の役割合意をEMへ引き継ぎ、受け入れ後のずれを確認する
• EM：各確認時点の面談を設計し、業務計画、基準、フィードバックを結びつける
• CTO：技術上の役割と組織の優先事項が接続しているかを確認する
• Buddy／Mentor：相談経路を支え、必要な支援をEMと共有する
• 本人：確認材料をもとに到達状況と次の支援ニーズを説明する

この分担なら、到達していない項目があっても、評価を急ぐ前に「目標が曖昧だったのか」「支援が不足したのか」「確認材料がないのか」を切り分けられます。

エンジニアの90日計画で最後に回収すべき問いは、期間を終えたかではなく、次の役割を合意できるだけの材料がそろったかです。入社前に役割と基準をそろえ、30日で仕事と支援の接続、60日で担当範囲と協働、90日で到達状況と次の開発課題を確認する。到達目標、支援者、確認材料が一本の工程でつながっていれば、オンボーディングは印象評価ではなく、支援と判断を更新できる運用になります。