FDEは「常駐SES」なのか。契約構造とコミットの中身で見分ける。

Respectify STUDIOのようなFDE型支援サービスについて説明すると、「それは結局、客先常駐のSES（システムエンジニアリングサービス）と同じではないか」という質問をよく受けます。エンジニア採用が追いつかず、外部の支援を検討している事業責任者の方が、稟議資料に「準委任契約・月額定額」と書いた瞬間に、社内の情報システム部門や経営企画から「それってSESの言い換えでは」と指摘される、という場面は珍しくありません。準委任という同じ契約用語が並ぶ以上、この反応はむしろ自然なものです。

こうした場面で困るのは、抽象的な理念で押し返そうとしても、稟議を通す立場の側は納得しにくいという点です。「AIネイティブな新しい働き方です」といった説明だけでは、法務や経営企画からすれば「結局それは何契約で、何が担保されるのか」という具体的な問いへの答えになりません。増員も外注も難しいなかで新しい支援の形を検討する事業責任者にとって必要なのは、抽象的なDX論ではなく、契約書のどの条項がどう違うのか、何を確認すれば見分けられるのかという、実装レベルの具体性です。

たしかに、顧客の現場で働くという点、契約形態が準委任であることが多い点は共通しています。実際、SESの多くも準委任契約であり、この点を誇張して否定する必要はありません。本稿の目的は、FDEとSESを優劣で語ることではなく、契約構造・指揮命令・評価軸という3つの切り口から、両者がどこで交差し、どこで枝分かれするのかを整理することです。稟議を通す立場の方が、社内の疑問に自分の言葉で答えられるだけの具体性を持ち帰れることを目指します。姉妹記事「FDEとは何か」でFDEという働き方そのものの成り立ちを解説していますので、まだお読みでない方はあわせてご覧ください。

なぜFDEがSESに見えるのか

FDEがSESと混同されやすい背景には、実務上の共通点があります。第一に、FDEも多くのSESも、顧客の作業現場（オフィスやプロジェクトルーム、あるいはオンライン会議上のチーム）に入って作業をするという点で似ています。第二に、契約形態です。SESは労働者派遣とは異なり、多くの場合準委任契約で結ばれます。準委任契約は、成果物の完成そのものを約束するのではなく、専門家として業務を遂行すること自体に対価が支払われる契約形態です。この点、FDE型支援も同じく準委任契約を採ることが一般的であり、契約書の建てつけだけを見比べると、SESとFDEはほぼ同じ枠に分類されます。

そもそもSESは、日本のIT業界において長年、人手が足りない現場に専門知識を持つエンジニアを機動的に供給する仕組みとして機能してきました。急な増員が必要な開発プロジェクト、特定の技術に詳しい人材が社内にいない局面、繁忙期だけ手を借りたい場面など、SESが埋めてきた需要は現実に存在し、日本のソフトウェア開発の多くがこの仕組みの上に成り立ってきたともいえます。エンジニア個人にとっても、複数の現場を経験しながら技術を磨ける契約形態として、SESには一定の意義があります。この存在意義そのものは、FDEという新しい働き方が登場したからといって否定されるものではなく、両者は優劣で語るべきものではなく、目的に応じて使い分けるべき異なる選択肢として並べて理解するのが妥当です。

書類の見た目が似ていることも、混同に拍車をかけます。準委任契約であるSESとFDE型支援は、契約書のひな形も、月次の請求書の記載項目も、稼働報告書のフォーマットも、外形的にはよく似た形になりがちです。法務や経理の担当者が、契約書と請求書だけを見て両者を区別しようとすれば、見分けがつきにくいのも当然です。この違いは、書面の様式ではなく、その裏側にある運用の設計にあります。だからこそ、契約書や請求書という書面だけを見て判断するのではなく、実際にどのようなリズムで仕事が進んでいるのかという運用の実態にまで踏み込んで確認する必要があります。

だからこそ、この混同は自然な反応だといえます。「準委任」「客先」という2つのキーワードが重なれば、契約実務に詳しい方ほど「同じ仕組みではないか」と感じるのは無理もありません。しかし、契約形態が同じであることと、実際に現場で何が起きているかは、別の問題です。次章から、この「同じ契約形態の中にある違い」を具体的に見ていきます。

提供するものの違い 工数か成果物のリズムか

最初の違いは、契約の対象として何を提供しているかです。

SESの多くは、エンジニアの稼働時間そのものを提供します。契約書上は準委任であっても、実務上求められているのは「決まった時間、決まった場所（またはオンライン環境）で稼働すること」であり、その時間内に何を作るかは、現場の指示に委ねられているケースが少なくありません。たとえば、あるプロジェクトで人手が急に足りなくなったとき、SESで参画したエンジニアに求められるのは、まず稼働時間を確保し、割り振られたタスクを期日までにこなすことです。この関わり方自体は、プロジェクト運営として合理的であり、何も問題はありません。

これに対してFDE型支援が提供するのは、稼働時間ではなく、成果物が一定のリズムで届き続けることです。独立行政法人情報処理推進機構（IPA）が公開する「情報システム・モデル取引・契約書（第二版）」は、請負契約と準委任契約の違いを、成果物の完成に対する対価か、専門家として業務を遂行すること自体に対する対価か、という軸で整理しています（参照：IPA「情報システム・モデル取引・契約書（第二版）」(2020年)）。FDE型支援は契約形態としてはこの準委任に区分されますが、運用の設計として、週次で動くソフトウェアを届けるというリズムそのものを支援の中心に据えます。

具体的にイメージすると、稼働時間だけを提供する契約では、「今月何時間稼働したか」を積み上げた結果として月末の請求が確定します。一方、成果物のリズムを提供する契約では、「今週何が動くようになったか」が先に決まり、その積み重ねが月単位の成果として顧客に見える形になります。つまり「時間を切り売りする」のではなく「一定周期で価値が積み上がることにコミットする」という点で、同じ準委任契約の中でも提供物の実質が異なります。

この違いを取り違えると、発注側にも受託側にもすれ違いが起きます。稼働時間の提供を前提にした契約に対して「今週何が動きましたか」と成果物のリズムを求めても、それは契約の建てつけと運用実態が噛み合っていないことになります。逆に、成果物のリズムを前提にした契約に対して「先月は何時間稼働しましたか」と稼働時間だけを尋ねても、その契約が本来コミットしている価値を測ることにはなりません。契約を結ぶ段階で、提供されるものが工数なのか成果物のリズムなのかを、双方が同じ理解で共有しておくことが、後々のすれ違いを避ける鍵になります。

タクシーの料金体系にたとえると分かりやすいかもしれません。走った時間や距離に応じてメーターが上がっていく従量課金と、目的地までいくらと決まっている定額運賃の違いに近いものがあります。稼働時間の提供は前者にあたり、契約期間中にどれだけ動いたかという「投入量」が請求の根拠になります。成果物のリズムの提供は後者に近く、あらかじめ決めた月額の中で、毎週何が動くようになるかという「到達点」の積み重ねに対価が支払われます。どちらの契約形態にも合理性はありますが、稟議で説明すべき性質は明確に異なります。

指揮命令の構造の違い

2つ目の違いは、誰が業務の進め方を指示するかという、指揮命令の構造です。

厚生労働省が公開する「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」では、労働者派遣に該当するか、請負・業務委託に該当するかは、契約書の名称や形式ではなく実態に即して判断されるという考え方が示されています。あわせて、労働者派遣と請負の区分基準（37号告示）および厚生労働省の疑義応答集では、請負・業務委託であれば、発注者が労働者に対して業務の遂行方法や作業時間などについて直接の指揮命令を行わないことが、区分の重要な要件になるとされています（参照：厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」(2026年8月時点)）。

この考え方をもう少し噛み砕くと、契約が労働者派遣か請負・業務委託かを分けるのは、「誰が現場で日々の作業指示を出しているか」という実態です。発注者側の管理者が、朝礼で当日の作業を割り振り、進め方を細かく指示している状態であれば、契約書に準委任と書いてあっても、実態としては労働者派遣に近いと判断されるリスクがあります。逆に、受託側の企業が自社のエンジニアに対して指揮命令を行い、発注者は「何を実現したいか」という要望を伝えるにとどまる状態であれば、請負・業務委託としての実態が保たれます。この判断基準は、SESにもFDE型支援にも共通して当てはまる、契約実務上の大原則であり、どちらの契約形態を選ぶ場合であっても、発注側・受託側の双方が意識しておくべき前提だといえます。

準委任契約である以上、SESもFDE型支援も、建てつけとしては受託側の企業がエンジニアに対する指揮命令権を持ち、発注者側が直接指示を出す立場にはならないことが求められます。ここは契約形態が同じであるがゆえに、両者に本質的な違いはありません。実務上この境界があいまいになりやすいのは、発注者側の担当者が日々の細かい作業指示まで踏み込んでしまうケースです。悪意があってそうなるというより、進捗を確実にしたいという善意から、つい「明日はこれをやってください」と直接指示を出してしまう、という状況は起こりえます。契約形態にかかわらず、この指揮命令の線引きを曖昧にしないことは、発注側・受託側の双方にとって実務上のリスク管理でもあります。

たとえば、週次デモの場で発注側の事業責任者が「来週はこの機能を優先してほしい」と要望を伝えるのと、日々の朝会で「今日はこの作業をこの手順でやってください」と細かく指示するのとでは、指揮命令の実態としての意味合いが異なります。前者は「何を実現したいか」という要望の伝達であり、後者は「どう作業を進めるか」という遂行方法への介入に近づきます。FDE型支援がバックログという仕組みを間に挟むのも、優先順位の共有と、日々の作業方法への直接介入とを、意識的に切り分けるための工夫だと理解できます。

ただし、実務上「誰の優先順位に沿って、何を作るか」を握る立場は異なります。SESの現場では、日々の作業の割り振りが顧客側の管理者に事実上委ねられがちで、受託側のエンジニアは与えられたタスクを順にこなす役割に留まることが多くなります。これは契約上の指揮命令権の所在とは別に、日々の優先順位づけという実務レベルの話です。一方、FDE型支援では、バックログ（着手すべきタスクの一覧）の優先順位づけそのものを、顧客の事業責任者と共同で行うプロセスを、契約の外側ではなく支援の設計そのものに組み込みます。指揮命令権の所在という法的な建てつけは同じでも、「何を先に作るか」を決める意思決定に受託側がどこまで踏み込むかという、実務上の関与の深さが異なる、というのがこの違いの正確な言い方です。

評価軸の違い 稼働時間か週次デモか

3つ目の違いは、何をもって「うまくいっている」と判断するかという評価軸です。

SESの現場で最も一般的な評価の単位は、稼働時間です。月にどれだけの時間稼働したか、稼働率がどの程度かという指標が、契約の履行状況を測る主な物差しになります。この評価軸のもとでは、稼働時間さえ満たしていれば契約上の履行義務は果たされたことになり、その時間で実際に何が動くようになったかは、別の管理項目として扱われがちです。極端な例を挙げると、月の稼働時間は満たしているのに、いざ動くものを見せてほしいと頼まれると、着手中のタスクが多く、完成した機能をすぐには見せられない、という状況が起きることがあります。稼働時間で評価される現場では、月末の定例会で「今月は何時間稼働しました」という報告が中心になり、事業責任者側は「では実際に何が変わったのか」を、別途エンジニアに聞き直さなければならない、ということも起こりがちです。

FDE型支援が採る評価軸は、これとは異なります。IPAが公開する「情報システム・モデル取引・契約書（アジャイル開発版）」は、アジャイル開発を「機能の追加・変更や優先順位の変更、先行リリース部分の改善などに柔軟に対応することができる手法」と位置づけたうえで、成果物の完成に対する対価ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提としたモデル契約書だと説明しています（参照：IPA「情報システム・モデル取引・契約書（アジャイル開発版）」(2020年)）。

この整理が示しているのは、同じ準委任契約であっても、運用の設計次第で評価の実質は大きく変わるということです。FDE型支援では、週次で動くソフトウェアを実際に見せる「週次デモ」を評価の中心に置きます。稼働時間の多寡ではなく、1週間という短いサイクルで動くものがどれだけ前に進んだかを、顧客が自分の目で確認できる状態を保ち続けることが評価軸になります。週次デモで評価される現場では、その週に着手したタスクがどこまで動く形になったかを、毎週必ず提示することが前提になるため、着手はしたが完成しない、という状態が長く続きにくい構造になります。稼働時間は「投入した労力」を測る指標であるのに対し、週次デモは「生み出された価値」を直接確認する仕組みです。この評価軸の違いは、費用感や契約形態の詳細とあわせて姉妹記事「FDE型支援の費用感と契約形態」でも扱っていますので、あわせてご参照ください。

対人スキルが技術力以上に重視されるという傾向も、この評価軸と無関係ではありません。エンジニアリングリーダー向けメディアのLeadDevは、FDEというロールについて、顧客と対話する能力こそが最も強い差別化要因であり、最も需要が高いのは深い業務知識を持つ技術者だと指摘しています（参照：LeadDev「The rise of the forward-deployed engineer (FDE)」(2026年)）。作業を指示通りにこなす力ではなく、顧客と一緒に優先順位を握り、それを動くものに変換し続ける力が問われている、というのがこの指摘の趣旨です。週次デモという評価の場が毎週訪れるからこそ、この対人スキルと業務理解の重要性が、契約の設計そのものに組み込まれることになります。週次デモの現場では、月末の定例会を待たずとも、毎週の30分から1時間程度の場で「今週動いたもの」を直接見て、その場でフィードバックを返せます。事業責任者にとっては、稼働報告書を読み解く手間よりも、実際に画面を動かして確認できるほうが、次に何を優先すべきかの判断がしやすいという利点もあります。

ここまで見てきた提供するもの・指揮命令・評価軸という3つの違いは、それぞれ独立した論点でありながら、実際には一体になって現れます。成果物のリズムを提供の中心に据えれば、必然的にバックログの優先順位を顧客と共同で握る必要が出てきますし、優先順位を共同で握るからこそ、週次デモという場で成果を確認する運用が意味を持ちます。逆に稼働時間を提供の中心に据えれば、評価も稼働時間で行うほうが整合的です。3つの違いは、ばらばらの差分ではなく、ひとつの運用設計としてつながっているものだと捉えると理解しやすくなります。

常駐の意味の変化

ここまでの3つの違いを踏まえると、「常駐」という言葉が指しているものも、見直す必要が出てきます。

物理的に客先のオフィスに座っていること自体は、本質的な違いを生みません。同じ場所に座っていても、指示されたタスクを順にこなすだけの関わり方と、顧客の優先順位の中で日々判断しながら動くものを作り続ける関わり方とでは、成果への当事者意識がまったく異なります。逆に言えば、物理的に常駐していなくても、後者の関わり方は十分に成立します。

日本のB2Bの現場に「常駐信仰」とでも呼べる感覚が根強く残っているのも事実です。発注側からすれば、エンジニアが目の前の席にいて、いつでも声をかけられる状態には、確かな安心感があります。進捗が目に見える、困ったときにすぐ相談できる、という感覚は、離れた場所で何が進んでいるか分からない状態への不安の裏返しでもあります。SESが客先常駐という形態で広く受け入れられてきた背景にも、この安心感への需要があったと考えられます。日本のIT業界に限らず、業務委託というものが「顔の見えない相手に発注する」不安と隣り合わせだった時代が長く続いてきたことを踏まえれば、常駐という形で相手の存在を目に見える形にすることには、それなりの合理性がありました。

ここで重要なのは、週次デモという仕組みが、この安心感を代替する役割を果たすという点です。毎週決まったタイミングで、動くものを実際に見せるという運用があれば、発注側は「今どこまで進んでいるか」を、席の有無に関わらず具体的に確認できます。むしろ、口頭で「順調です」と伝えられるだけの常駐よりも、実際に動く画面を毎週見せられるほうが、進捗に対する確信を持ちやすいという面もあります。

リモートワークやハイブリッド勤務が当たり前になった今、「常駐」というラベルが指す実態も変わってきています。かつては「客先に毎日通うこと」が常駐の定義でしたが、オンライン会議やチャットツールが定着した現在では、顧客のチームと同じリズムで動き、同じ優先順位を共有しながら手を動かしているかどうかのほうが、実質的な意味を持つようになっています。Respectify STUDIOが物理的な常駐を前提としないのも、この「現場」の実質を、席の有無ではなく優先順位への関与の深さで定義しているためです。

こうした変化は、日本のIT業界に限った話ではありません。海外のテック企業を中心に、顧客企業の現場に深く入り込みながらも、拠点は分散したまま働くという形が広がっています。前出のLeadDevの分析が示すように、FDEというロールで重視されているのは対人スキルと業務理解であり、物理的にどこに座っているかではありません。日本のB2Bにおいても、「常駐しているかどうか」ではなく「顧客の優先順位にどれだけ深く関与しているか」を見る視点への移行は、今後さらに進んでいくと考えられます。

SES・派遣・受託・業務委託・FDEの整理表

ここまでの整理を、契約形態別の一覧表にまとめます。労働者派遣だけは指揮命令権が発注者側（派遣先）にあるという点で、他の4つとは根本的に異なる仕組みであることに注意してください。

この5分類が実務上重要なのは、稟議や契約審査の場面で「これは何契約か」という質問に答えられないと、話が前に進まないからです。労働者派遣に該当するかどうかは、偽装請負のリスクにも関わる重い論点であり、まずここを外形的に区別する必要があります。そのうえで、請負なのか準委任なのかは、成果物の完成義務の有無という一点で切り分けられます。

この表を前にしたとき、多くの発注担当者が最初に気にするのは「うちの契約はどれに当たるのか」という点です。既存の外部委託契約を見直す際にも、まずこの5分類のどこに位置しているのかを確認することが、次に何を交渉すべきかを見極める出発点になります。

契約前に発注担当者が確認しておきたい問いは、大きく3つに整理できます。1つ目は、指揮命令権が契約上どちら側にあると整理されているか。2つ目は、成果物の完成義務があるか、それとも業務遂行そのものが対価の対象か。3つ目は、その業務遂行の実態を、どのような頻度・形式で確認できるかです。SESと準委任型のFDE支援は、1つ目と2つ目の答えがほぼ同じになりますが、3つ目の答えが大きく異なります。契約書の文言だけでなく、この3つ目の運用面を具体的に確認することが、実務上の見分け方になります。

なお、表にある「業務委託（準委任契約、一般）」は、特定のスキルを持つ個人と単発で契約するような、一般的な業務委託を指しています。この場合、指揮命令の所在や成果物への責任という点ではFDE型支援と同じ枠に入りますが、成果物を一定のリズムで届け続けるという運用上のコミットまでは、契約の性質上必ずしも含まれません。FDE型支援を他の準委任契約と区別する最大のポイントは、この「リズムを運用として組み込んでいるかどうか」にあります。

この表からわかるのは、SESとFDE型支援は、契約形態・指揮命令の所在という法的な軸だけを見ると、ほぼ同じ枠に位置づけられるという事実です。両者を分けるのは契約書の文言ではなく、その準委任契約の中にどのような運用（成果物のリズム・バックログ運用・評価の方法）を組み込むかという設計の違いにあります。契約前に発注担当者が確認すべきなのは、契約書に書かれた「準委任」という一語だけでなく、その中身として、成果物をどのようなリズムで、どのような形で確認できるのかという運用の取り決めです。

日本のB2Bでの実務像

では、この違いは実務上どのような形で現れるのでしょうか。弊社Respectifyが提供するRespectify STUDIOを例に、具体的な運用イメージを紹介します。

Respectify STUDIOでは、契約は準委任・月額定額という形を取ります。稼働時間を積み上げて請求するのではなく、月単位で定額の支援を提供する形にすることで、稟議や予算計画に載せやすい形に整えています。

支援開始の初月は、まず顧客の事業と現場の状況を理解し、着手すべき項目を洗い出してバックログの原型を作るところから始めます。何か月もかけた要件定義を経てから着手するのではなく、初週から動くものを小さく作りはじめ、実際に触ってもらいながら方向性を確認していくやり方を採ります。

運用の中心にあるのは、週次のデモとバックログです。週の前半に、その週取り組むタスクをバックログから顧客の事業責任者と一緒に選び、優先順位を確認します。週の後半には、決まった曜日に週次デモの時間を設け、その週に動くようになった実装を実際に画面上で見せます。持ち寄るのは進捗報告のスライドではなく、実際に触って動かせる状態のソフトウェアです。デモの場でフィードバックが出れば、その場で次のバックログ項目として書き加え、翌週の優先順位に反映します。あらかじめ固定された仕様書に沿って進めるのではなく、市場の反応やチーム内の状況が変われば、翌週のバックログの並びもそのつど変わります。この進め方は、IPAのアジャイル開発版モデル契約書が前提とする、機能の追加・変更や優先順位の変更に柔軟に対応するという考え方と重なります。

バックログの中身は、抽象的なタスク名の羅列ではなく、「この画面でこの操作ができるようになる」「このデータをこの条件で自動的に集計できるようになる」といった、動く単位まで具体化した項目で構成されます。1つの項目を1週間程度で動く形にまで持っていけるかどうかを基準に優先順位を組み立てるため、着手したものの何週間も完成しない、という状態が生まれにくくなります。

物理的な常駐は行わず、AIネイティブな開発ツールを使いながらリモートで実装を進める体制を取っています。これは前章で述べた「常駐の実質は席ではなく優先順位への関与にある」という考え方を、そのまま運用に落とし込んだ形です。あるシリーズAのB2B SaaS企業では、エンジニア採用が追いつかないなかでも、この体制によって毎週動くものが届く状態を止めずに保っています。エンジニアが自社にいなくても、週次デモという場を通じて、事業責任者が自分の目で進捗を確認できる状態が保たれるため、外部に任せているという不安を抱えずに運用できる、という声も少なくありません。バックログも週次デモも、特別な管理ツールを新たに導入しなくても運用できる範囲で設計しており、顧客側に運用負荷を新たに背負わせない形を意識しています。

稟議の場で問われやすいのは、「途中で契約を止めやすいかどうか」という点でもあります。月額定額・準委任という形態は、長期の一括契約に比べて、事業の状況に応じて継続や見直しの判断をしやすいという特徴があります。数か月先まで要件を固めてから契約するのではなく、直近のバックログと週次デモの積み重ねを見ながら、継続の判断を都度下せるという運用は、事業のフェーズが変わりやすいスタートアップやSaaS企業にとって、扱いやすい契約の形だといえます。

こうした運用のもとでは、事業責任者の側の関わり方も変わります。週次デモの場に毎週顔を出し、優先順位の判断を都度下す役割を担うことになるため、外部に丸投げして結果だけを待つという関わり方はできません。その代わりに、自社の事業の中で今何が最も重要かを、実装の解像度で判断し続けられるという利点があります。エンジニアの採用や管理という負担を負わずに、事業判断そのものには深く関与し続けられるという点が、この運用の設計が目指しているところです。人を採って育てる負担と、実装を進める推進力とを切り離しながら、意思決定の主導権は事業側に残すという設計は、増員も外注の一括発注も難しい局面にある企業にとって、現実的な選択肢のひとつになります。

まとめ

FDEとSESは、契約形態としては同じ準委任契約の枠に収まることが多く、その意味で「まったくの別物」と言い切ることはできません。両者を分けるのは、契約書の建てつけではなく、提供するもの（工数か、成果物のリズムか）、優先順位を握る立場、評価の軸（稼働時間か、週次デモか）という運用の中身です。SESという業態そのものが劣っているわけではなく、契約が想定している役割と評価の設計が、そもそも異なるということです。

社内で「それはSESと同じでは」と聞かれたときに大切なのは、感覚的に反論することではなく、契約構造・指揮命令・評価軸という3つの軸に沿って、具体的にどこが同じでどこが違うのかを説明できることです。この記事で整理した内容が、その説明の材料になれば幸いです。

改めて整理すると、SESとFDE型支援は、労働者派遣とは明確に異なる準委任契約という同じ土台に立ちながら、その土台の上にどのような運用を組み立てるかで、実質が大きく分かれます。稼働時間の提供か成果物のリズムの提供か、優先順位を誰と共同で握るか、稼働時間で評価するか週次デモで評価するか。この3つの問いに対する答えが、契約書の文言よりも雄弁に、両者の違いを語ります。稟議や社内説明の場では、この3つの問いに沿って自社が求めている支援の形を言語化することが、遠回りに見えて最も確実な近道になります。

Respectify STUDIOは、専属チームによる準委任・月額定額の支援体制で、毎週動くものが届く運用を組み込んだFDE型支援サービスです。SESや受託開発とどう違うのか、自社の状況に当てはめて具体的に検討したい方は、Respectify STUDIOの詳細をご覧ください。個別のご相談は無料相談へお気軽にお問い合わせください。