プロジェクトマネージャー（PM）が行うべきリスク管理とは

• PMが行うリスクマネジメントの定義とは
• プロジェクトのリスク要素
• PMの行う基本のリスクマネジメント6ステップ
• PMのリスクマネジメントの実施内容
• PMのリスクマネジメントの事例
• リスクマネジメントに役立つシステム開発のリスク管理表
• PMのリスクマネジメントに関するよくある質問
• まとめ

PMが行うリスクマネジメントの定義とは

プロジェクトマネージャー（PM）の重要な業務の一つが、プロジェクトのリスクマネジメントです。プロジェクトの運営、推進を行っていくうえで発生する可能性があるリスクに対し、以下のような内容を行います。

IPAの定義するリスクとリスクの3要素

IPAでは、リスクの定義として、「発生確率を持ち、最終的に損失または利益になること」としています。IPAとは、独立行政法人 情報処理推進機構の略称で、IT人材の育成や研究、IT分野の技術開発を行っている組織です。ここで重要なのは、最終的に損失になる場合だけでなく、利益になることもリスクとして含まれる点です。つまり「発生するかは分からないが、もし発生した場合にプラスにもマイナスにもなり得る不確定要素」がリスクとして定義されています。
上記の定義を踏まえてまとめると、リスクはその性質として以下の3つの要素を含むといえるでしょう。

プロジェクトマネージャーだけでなく、プロジェクトに関わるすべてのステークホルダーがリスクの定義を正確に把握した上で、リスクマネジメントに取り組む必要があります。

リスクマネジメントと危機管理の違い

リスクマネジメントと危機管理は同義で語られる場合がありますが、これらには明確な違いがあります。リスクマネジメントはリスクが顕在化する前に発生を防止する活動です。一方で危機管理とは、実際に発生した危機を管理する活動です。
リスクはIPAによる定義にもあるとおり、将来発生するかもしれないし、発生しないかもしれない事象に対して用いられる用語であるため、混同しないよう注意しましょう。

リスクマネジメントとリスクアセスメントの違い

リスクマネジメントと似た言葉として、リスクアセスメントという言葉もあります。リスクアセスメントとは、リスクの特定と分析、評価を行うプロセスを指します。一方で、リスクマネジメントは特定から評価に加えて対処も含まれます。つまり、リスクアセスメントはリスクマネジメントの一部の活動を指した用語であることを理解しておきましょう。

プロジェクトで発生しうるリスクへのケアがリスクマネジメント

システムやソフトウェア、アプリケーションの開発、改修、運用を行うプロジェクトでは、その推進がスムーズに運ぶとは限りません。システム、ソフトウェア、アプリケーションはそれぞれ独自性の高いものです。技術面、人員リソース面、金銭面、顧客要因などリスクの要因もプロジェクトごとに違ってきます。

プロジェクトマネージャーは、プロジェクトごとに発生しうるリスクを全て洗い出し、可能な限り顕在化させないようにしなければなりません。リスクが顕在化しないか監視し、発生した場合は早期検知とリスク対応を行う必要があります。プロジェクトのQCDの達成および事業の利益の確保を目標として、それに立ちはだかる全てのリスクを排除することがプロジェクトマネージャーの大きな役割です。（※）

※IPA独立行政法人情報処理推進機構「ITプロジェクトのリスク予防への実践的アプローチ」

プロジェクトに発生するリスク全てがマネジメント対象

リスクマネジメントが難しい理由の一つとして、プロジェクトに発生するすべてのリスクを対象にしなければならないことがあります。各プロジェクトにおけるリスクとして、ありとあらゆる可能性を考慮する必要があります。

極端なことをいえば、自然災害によって作業ができない状態もプロジェクト推進上のリスクです。極端に考える必要はありませんが、どんなことが起きるか分からないという考えの元、リスクマネジメントに取り組む必要があります。

リスクマネジメントが必要な条件

リスクマネジメントはプロジェクト全体にかかる業務ですが、時間や人的リソースを考えれば実際にはすべてを対象に逐一管理するわけにはいきません。ある程度リスクを誘発しうる要因があるかどうかに絞ってマネジメント対象を決める必要があります。

たとえば要件定義工程において、ヒアリングすべき要件項目を満たしていない場合があります。この事象は、「要件定義に漏れが生じる」というリスクを誘発しうる要因といえます。こういった要素がプロジェクトに潜在しているかどうかを見極めることが大切です。
プロジェクト自体の性質、取り巻く外部環境、業界全体の動向なども考慮しながら、リスクマネジメントをしていくことが求められます。

プロジェクトのリスク要素

プロジェクトの推進においては各工程などで考慮しなければならないリスクがあります。また、プロジェクトの特性によっては複数のリスクが潜んでいると予想できるので、事前に把握しておくと慌てずに対処できるでしょう。ここでは代表的なものを記載しているのでぜひ参考にして下さい。

プロジェクト開始前

プロジェクトの開始前には、プロジェクトを進める計画を立て、自社および顧客への承認を行います。いわゆるプロジェクトのキックオフがそのタイミングにあたりますが、その際に考慮すべきリスクを挙げていきます。

タスクの洗い出し漏れ

プロジェクトの推進計画を立てるにあたり、ベースとなるのが全タスクの一覧化です。自社、自チームのタスクのみならず、プロジェクトに関わる全員のタスクを漏れなく考慮する必要があります。

たとえば自社内のアプリケーション、インフラ、営業、サブチームなどの担当者のほか、スポンサーや顧客情報システム部門、顧客業務部門、顧客の意思決定者のタスクも洗い出します。このタスクの洗い出しをもとにスケジュールを組むので、タスクの漏れはリスクへ繋がってしまいます。

人員確保

タスクを洗い出し、スケジュールを組むのとともに行われるのはシステムの推進要員の確保です。この際、ほかの仕事との兼ね合いや時期などにより社内、社外の要員を、ある程度流動性が残った状態で仮に決めておくことも多いです。その中でも、システムの中核となる機能の開発を行う要員が確保できない場合には大きなリスクとなり得ます。

顧客の不確定要素

自社だけでなく顧客側のプロジェクト推進体制についても、リスクマネジメントの対象となってきます。たとえば顧客の意思決定者やキーマンが複数存在したり、一人も存在しなかったりした場合には、スムーズなプロジェクトの推進に大きな影響を与えてしまいます。顧客側の要員、各部門の担当者、承認のためのルール、タスクやスケジュールがときに不明確であることも、リスクとなる要素の一つです。

要件定義

キックオフが済み、プロジェクトが開始すると始まるのが要件定義です。クライアントの要望を把握しシステム開発を達成するために全体の計画を立てることをいい、要件定義の工程で発生、または埋め込まれるリスクは、将来の工程に大きな影響を与える可能性があります。

顧客部門間の合意

システム開発のプロジェクトにおいては、窓口となる部門とできあがったシステムを利用する部門が異なることもあります。たとえば、システム開発プロジェクトの窓口は情報システム部門で、完成したシステムの利用者は現場部門となっている場合です。「システム開発部門の了承＝顧客の承認」のように見えますが、実際のシステムの利用者が後から仕様を覆すことも多く、トラブルの原因となります。

外部連携先システムとのIF

開発対象のシステムによっては、別のシステムとの連携機能が必要なことがあります。連携先のシステムの所有部門や利用部門が窓口の部門でない場合や、自社以外の企業が運用を行っている場合は、インタフェース（IF）など決まりごとを作る必要があるため、リスクとなる場合があります。また、のちの工程で連携テストを行う際にも足並みをそろえる必要があり、片方の遅れが全体の進捗遅れにつながることもリスクといえます。

性能要件の確定

要件定義において、プロダクトに必要な機能に関しては意見が多く出ますが、処理速度、想定データ件数などの性能要件は明確に決まらないことも多いです。性能要件は後から改善しようとすると大きなコストがかかることもあるため、要件が明確でなければ早い段階でリスクとしてとらえておく必要があります。

技術要件

自社に事例のない技術や先端技術を利用したシステム構築が必要となるプロジェクトは、その技術の利用および機能の実現可能性などの裏取りをする必要があります。技術的に特殊なことを行う場合は、その検証や問題発生時のサポートに大きなコストがかかることもあり、これもリスクとして考えなければなりません。

設計工程

要件定義で出た機能を実現するのに向けて設計に落とし込むのが設計工程です。設計工程には、機能を画面イメージや項目といったレベルで表現する基本設計、システム化を行う際の内部的な構造を設計する詳細設計、プログラムレベルでの記法、関数を設計するプログラミング設計などがあります。この設計工程で起こり得るリスクについて、以下に記載します。

仕様変更、機能追加

設計工程において顕在化してくるのが顧客の要望による仕様変更、機能の追加です。プロジェクトによっても異なりますが、基本設計の完了段階で仕様変更、機能追加を締め切る仕様凍結を顧客と合意の上で行います。仕様凍結後の顧客要望の扱いを決めておくこともリスクマネジメントの一つとなります。

設計工程の品質確保

設計工程において気をつけておかないと後の工程でのリスクとなるのが、設計の品質確保です。設計が一定のレベル以上で行われており、抜けもれがないかをチェックするためレビューを行うのが一般的です。この設計工程での品質が確保できていない場合、開発やテスト工程での障害に繋がるリスクとなります。

開発工程

設計工程にて作り上げた設計書に従い、プログラムなどの実行可能な状態を作り出すのが開発工程で、この開発工程でも「開発品質」「障害管理」のリスクを考慮しなくてはなりません。以下で詳しく解説します。

開発品質

開発工程では、プログラムのできに関する開発品質低下はケアしなければならないリスクです。開発者の技量、設計工程の品質、要件そのものから必要とされる技術力などが要因となり、開発品質の低下が起き得ます。

障害管理

開発工程におけるリスクが分かりやすく顕在化するのが障害件数や障害管理表です。品質の高さ、前工程までの積み上げなどの要因により障害は発生するため、その原因を突き止めてケアすることがプロジェクトマネージャーの行うリスクマネジメントとなります。

テスト工程

システムの開発や改修のプロジェクトの場合、リリースというゴールが見えてくるのがテスト工程です。この段階でのリスクの顕在化は、直接納期遅れにつながるため影響が大きくなってしまいます。テスト工程で遠ざけておきたいリスクを記載します。

システム障害

バグや製品の障害などによるトラブルはテスト工程での一番といえるリスクです。これまでの工程での小さなひずみが、テスト工程でははっきりと姿を見せるため、事前にどこまで手を打てているのかが問われます。

技術的制限

最終的な段階に近づきつつある中で技術的、性能的な制限に引っかかってしまい、何らかの機能が実現できないことが大きなリスクになります。たとえば、画面のクリックから画面表示までのレスポンスを0.1秒以下にしたい、データを1億件格納しておきたいといったコンピュータやミドルウェアの性能の制限により実現が難しい問題が発生した場合、ハードウェアレベルでの対応が必要となることもあります。

それによって、対応に大きな工数がかかってしまいます。問題を抱えたままリリースにこぎつけたとしても、解消までにはコストと時間がかかる場合があるでしょう。

システム移行

テストが一定以上の結果を挙げていれば、システムのリリースについても考えていかなければなりません。システム改修などの場合、システムの重要度によっては、リリースのために十分な停止時間が確保できないため、関係各所との調整が必要となります。また、問題なくシステムが移行できるかも大きなリスクになり得ます。

さらにはシステム移行が完了したのち、稼働フェーズとなってもなおリスクは存在します。潜在的なバグ、システム内で使用しているソフトウェア製品の保証期限の問題、大量のデータ発生など設計時の想定外の動作による障害といったリスクです。システムのログ、データ量、障害の発生件数といった稼働状況を注視することが、安定した稼働までのリスクマネジメント方法となります。

PMの行う基本のリスクマネジメント6ステップ

PMが行う基本的なリスクマネジメントには、「リスクマネジメント計画の立案」や「リスクの洗い出し・特定」など6つのステップがあります。それぞれ把握しておくことはPMの業務においてとても重要です。ここでは、詳しく説明するのでぜひ参考にしてください。

リスクマネジメント計画の立案

リスクマネジメントで最初にやることは、リスクマネジメント計画の作成です。リスクマネジメント計画では、リスクが発生した場合に、どのように対応していくのか方針を策定します。具体的には、リスクへの対処時の役割分担や、リスクの棚卸しのタイミング、リスクの影響度によるグループ化の考え方の整理などを行います。
また、リスクへの対応はプロジェクトマネージャー一人では完結しません。そのため、リスクマネジメント計画を策定したあとにはプロジェクトメンバー全員で共有し、考え方や方針の認識合わせを行うことが重要です。

リスクの洗い出し・特定

リスクマネジメント計画が作成できたら、次は具体的なリスクの洗い出し・特定を行っていきます。
リスクの洗い出し方にはいくつか方法がありますが、たとえばプロジェクトメンバーへのヒアリングや、ブレインストーミング、前提事項の整理などが挙げられます。
前提事項とは、プロジェクトを進める上で、今後事実となることを確信している事象のことを指します。この前提事項を元にプロジェクトの計画が立てられているため、前提事項が変わるとプロジェクト全体への遅延や工数増加の要因になるため、事前に前提事項を整理しておきます。
これらいずれかの方法ではなく、複数の方法を組み合わせてさまざまな角度からリスクを洗い出していくことを意識しましょう。

リスクの分析

リスクの洗い出しが完了したら、リスク一つひとつに対する分析をしていきます。分析時には、リスクがどの程度の確率で発生するのか、リスクが顕在化した場合の影響度合いなどを整理していきます。
PM観点で影響度の低いリスクに見えても、ほかのステークホルダーからすると大きなリスクである場合もあるため、PMのみで考えるのではなく、さまざまな立場の担当者と会話しながら整理していくことが重要です。

また、この分析活動は、その後の対応策立案のインプットとなる工程となります。リスクが発生したときに、プロジェクトは遅延するのか、工数が増えるのか、品質が下がるのかなどを具体的にイメージすることが大切です。この分析結果が正しくない場合には、適切な対応策も検討することが困難になります。

リスクへの対応策立案（優先順位付けと担当者決定）

リスクの分析が終わり、影響度合いなどの整理が終わったら、次はリスクへの対応策を立案していきます。ここではリスクの発生確率と影響度合いを元に、発生確率が高く、影響が大きいものから順に優先順位をつけていきます。また、リスクに対する担当者を決定し、詳細な対応実施者を明確にしておくこともこの工程で行います。

プロジェクトの状況によっては、リスクマネジメント計画立案時点では具体的なリスクに対する担当者のアサインが難しい場合もあります。その場合には、いつ担当者を決めるのかの期限を明確にして定期的な棚卸しのタイミングで適切な担当者をアサインすることを意識しましょう。

また、すべてのリスクに対して影響をゼロにすることは困難です。そのため、リスク対応策を立案する際には、以下の検討をしておくことも重要です。

• 
  ・リスクを完全に排除すべきなのか（回避）

  ・リスクの影響度合いを下げる対策を打つのか（軽減）

  ・リスクが発生してから対処するのか（許容）

対応実施

実際にリスクが顕在化した場合には、上記で整理した対応策に基づいて対応を行います。役割分担や対応方針などを整理できていれば慌てることなく、プロジェクトへの影響を最小限にしてリスクに対処するできるでしょう。
また、リスクの対応が完了した後には、対処方法が適切だったかを振り返っておくと、次の類似プロジェクトでの参考にできます。

リスクの監視とコントロール

プロジェクトが順調に進み、リスクが顕在化していない間にも、常に監視とコントロールをしておくことが重要です。プロジェクトが進むにつれて、発生確率の下がったリスク、上がったリスク、新たに発生したリスクなどが出てきます。リスクに対して都度迅速に対応するためには、定期的にリスクマネジメント計画書を直近化して常にリスクの顕在化に備えるようにしておくことが大切です。

PMのリスクマネジメントの実施内容

ここまでは、システム開発のプロジェクトにおいて起こり得るリスクの代表的なものを、工程順にみてきました。ここからは、そのリスクに対してプロジェクトマネージャーは、どのようなリスクマネジメントを行うべきか、リスクマネジメントの方法について紹介します。

リスク費用の計上（計画立案）

プロジェクトの前段階である見積もりやプロジェクト計画の策定の段階でとれるリスクマネジメントの手段として、リスク費用の計上が挙げられます。費用、予算といった枠を作るにあたり、潜在的なリスクを予想し、リスク対策として費用を乗せておくことは実施しておきたい施策の一つです。

情報の収集（特定）

システム開発プロジェクトにおいて、情報収集は非常に地道だが確実なリスクマネジメントの方法の一つです。情報収集の目的としては、過去の事例からリスクを想定し、事前に備えておくためです。有識者などに相談し危機の回避策を考案しておくことは、リスクを遠ざける重要手段の一つといえます。プロジェクトの進捗や品質についても、順次情報を集めて分析することで、リスクの芽を早い段階で見つけ、小さな問題のうちに対処できるようになるでしょう。

工程ごとの品質分析（分析）

各粒度の設計工程や開発において全タスクを完了させた場合には、本来は次の工程に進む前に工程完了の判定を行うべきです。その中でも工程の成果物に対する品質分析は重要で、未来の工程で大きな問題となり得るリスクを素早く初期段階で見つけられる手段です。まずは、サンプルを取って調査や設計書のページ数、プログラムのステップ数など定量的な指標を定めます。その結果をもとに品質分析を行いましょう。

リスケジュール（対応）

本来予定していたスケジュール通りにプロジェクトが進められなくなった場合に行う重要なリスクマネジメントがリスケジュールです。リスケジュールで重要なのは、なんとなく予定を立て直すのではなく、遅れを定量的にとらえてどのような手段でリカバリするかを明確にすることです。たとえば、スケジュールで10人日分の遅れが出ていれば、最低でも10人日分以上のリソースを埋める具体的な方法がなければリスケジュールにはなりません。

エスカレーション（対応）

エスカレーションとは、業務を遂行する上で、上長の指示を仰いだり、業務を引き継ぐことを指しています。

プロジェクトマネージャーがシステム開発プロジェクトを推進する中で、リスクやリスクの予兆に気づいた場合、まず行うリスクマネジメントがエスカレーションです。スポンサーや上司へのエスカレーションを行うことで、組織の力、有識者の見解、過去の事例なども得やすくなり、プロジェクトマネージャーの手に余る問題も、力を合わせることで解決に向かえます。

品質強化策（対応策立案）

各工程の中間段階や終わりの段階で成果物の品質を確保することも、次工程以降のリスクを削減するリスクマネジメントです。設計書、ソースコードのレビュー、外部メンバーを入れての監査、工程ごとの品質分析もそのチェック方法です。また、工数削減のために抜き取りでレビューやチェックを行う、有識者のみでレビューを実施する、複数人体制で詳細なレビューを行うなど、必要に応じて強弱をつけて実施します。

顧客へのネゴシエーション（対応）

リスクとなり得る事項について、事前に顧客と対応の方針を話しておくこともリスクマネジメントの一つです。リスクをあらかじめ想定して共有しておくことで、想定内の事項とし、リスクではなく扱えます。

定期的なプロジェクト状況のチェック（監視）

情報の収集によりプロジェクトのデータを集め、定期的に予定していた通りの結果が出ているかをチェックすることもリスクマネジメントにあたります。スポンサーや上司と一緒に行うとより状況がわかりやすくなります。品質、コスト、進捗などの複数の観点でチェックを行います。

PMのリスクマネジメントの事例

リスク要素、リスクマネジメントの実施方法について触れてきましたが、実際どのような事例があるのか知っておくことは大切です。ここではシミュレーションとして、いくつかリスクマネジメントの事例を挙げていますので、ぜひ参考にしてみて下さい。

プロジェクト開始前のリスクチェック

システム開発プロジェクトにおいて、プロジェクトマネージャーとして最初に行うのがプロジェクト推進計画の策定です。その際にプロジェクトに対してリスクチェックを行います。利益を上げながらQCDを達成することをプロジェクトの目標とし、その際のリスクとなり得ることを全て洗い出しましょう。人員計画や予算にリスク費用を計上することはこのタイミングしかできないリスクマネジメントです。

設計工程でのリスケジュール

設計工程で遅れが発生した場合のリスケジュールを想定してみましょう。リスケジュールの目標として、設計工程の終了予定は守るのが前提です。

そのためには、まずエスカレーションして、スポンサー、上司に状況の共有および協力の要請を取り付けます。その後、投入するリソースを社内人員の追加や外部企業への発注により確保します。最悪の場合は、メンバーの残業によってでもリカバリの予定をたて、リスケジュールを行いましょう。リスケジュールは社内だけでなく、顧客のスポンサーにも共有して、承認してもらうのもリスクマネジメントとしては重要なポイントです。

テスト工程での品質問題への対応

テスト工程にて品質問題が発生した場合を想定してみます。まずはエスカレーションを実施しましょう。移行などの後のスケジュールが迫っているようであれば、社内に加えて、顧客の意思決定者、キーマンへのエスカレーションも必要です。その後、各工程の品質分析結果に立ち返り、品質悪化発生の原因を探します。見つかった原因に対し、そのケアを行って品質の強化を行います。何も考えずに闇雲に障害対応をしているだけでは、リスクマネジメントとして有効ではない場合もあるため見極めが必要です。

リスクマネジメントに役立つシステム開発のリスク管理表

リスクマネジメント計画書の別紙として、Excelなどでリスク管理表を作っておくと管理がしやすいため、おすすめです。
また、システム開発においては、リスクが与える影響を、さらに細分化して、スコープ、スケジュール、コスト、品質などに分けておくことで、スムーズなリスク管理・対処が行えます。

また、リスク管理表はプロジェクトの各工程で見直しと直近化することが重要であるため、更新しやすいフォーマットにしておき、新規の参画メンバーもすぐに参照できるように格納先を整理しておくことも大切です。

PMのリスクマネジメントに関するよくある質問

PMのリスクマネジメントに興味がある方の中には、リスク内容や重要性などが気になる方が多いようです。ここでは、PMのリスクマネジメントに関するよくある質問を紹介するので、似たような疑問をお持ちの方は参考にしてください。

Q1.プロジェクトマネジメントのリスクにはどのようなものがありますか？

プロジェクトマネジメントのリスクには、工程ごとにさまざまなものがあります。主なリスクには要件定義工程では顧客部門間での合意がとれておらず、要件が覆るリスクや、設計工程では仕様変更・機能追加といったリスク、テスト工程で品質懸念が発生するリスクなどが挙げられます。

Q2.リスクマネジメントの6つのステップを教えてください

リスクマネジメントは以下の6つのステップで整理していきます。

• 
  1.リスクマネジメント計画の立案

  2.リスクの洗い出し・特定

  3.リスクの分析

  4.リスクへの対応策立案（優先順位付けと担当者決定）

  5.対応実施

  6.リスクの監視とコントロール

Q3.プロジェクトマネージャーのリスク管理はどれくらい重要ですか？

リスクが顕在化してしまうと大きなスケジュール遅延・コスト増加・品質低下を招く可能性があります。リスクが発生した場合にも被害を最小限に留めるために、リスク管理は非常に重要なタスクと言えます。プロジェクト計画工程の一つの必須アウトプットとして捉えておきましょう。

まとめ

プロジェクトマネージャーの行うリスクマネジメントとは、プロジェクト推進において起き得るすべてのリスクを洗い出し、予防、観測、ケアをすることです。リスクとなる要素は工程や関係する人物などにより変わっていくため、逐次リスクのチェックと対策を行う必要があります。

リスクマネジメントの手段も、工程によってさまざまです。早い段階でリスク費用を計上するほか、スケジュールの遅れなどリスクが顕在化した場合のリスケジュールなどもリスクマネジメントの手段となります。

リスクマネジメントは地味で地道な作業の積み重ねです。ともすれば、発生するか分からない可能性を考慮する後ろ向きな面もある作業でもあります。楽しく達成感のある作業ではないかもしれません。

しかし、リスクマネジメントはプロジェクトマネージャーとして絶対に避けたいプロジェクトの炎上を防ぐための唯一といえる手段です。大規模なプロジェクトになればなるほど不確定要素は増え、リスクマネジメントの必要性は高まります。リスクマネジメントはプロジェクトごとの特性を考慮する必要があるため定型化しづらく、スキルと経験が必要です。プロジェクトマネージャーの腕の見せどころともいえるでしょう。

ITエンジニアの転職ならレバテックキャリア

レバテックキャリアはIT・Web業界のエンジニア職を専門とする転職エージェントです。最新の技術情報や業界動向に精通しており、現状は転職のご意思がない場合でも、ご相談いただければ客観的な市場価値や市場動向をお伝えし、あなたの「選択肢」を広げるお手伝いをいたします。

「将来に向けた漠然とした不安がある」「特定のエンジニア職に興味がある」など、ご自身のキャリアに何らかの悩みを抱えている方は、ぜひ無料のオンライン個別相談会にお申し込みください。業界知識が豊富なキャリアアドバイザーが、一対一でさまざまなご質問に対応させていただきます。

「個別相談会」に申し込む

転職支援サービスに申し込む
※転職活動を強制することはございません。

レバテックキャリアのサービスについて