プラットフォームエンジニアを業務委託で確保｜SREとの違いと発注要件の設計

「Backstage で開発者ポータルを作りたい」「Golden Path を整備したい」——社内エンジニアからそんな声が挙がり、経営からも「開発生産性を改善せよ」と指示が出ている。ところが専任のプラットフォームエンジニアを中途採用しようとすると半年〜1 年もエントリーが集まらず、SES ベンダーに相談すれば「SRE を月 XX 万円で送れます」と提案される。SRE と Platform Engineer は本当に同じものなのか、それとも別物なのか。自社が今必要なのはどちらなのか——この最初の判断でつまずいている発注責任者は少なくありません。

Platform Engineering は Gartner が「2026 年までに大規模ソフトウェアエンジニアリング組織の 80% がプラットフォームチームを設置する」と予測した領域です（Platform Engineering（プラットフォームエンジニアリング）とは（一創））。国内でも SaaS・事業会社を中心に導入が進みつつありますが、SRE や DevOps に比べて日本語の事例情報がまだ薄く、「業務委託で外部から確保する」場合の発注実務は空白領域と言えます。

とくに難しいのが契約設計です。Platform Engineering は「開発者体験（DevEx）を継続的に改善する」性質の業務で、請負契約が想定する「完成品を納品する」モデルには馴染みません。準委任契約が中心になりますが、社内エンジニアとの共同開発・コードレビュー・ペアプロが日常的に発生するため、指揮命令権や偽装請負リスクの線引きにも配慮が必要です。

本記事では、この意思決定を「発注者の視点」で言語化します。SRE との違いを発注視点で 5 つの差分に整理し、準委任契約で発注要件書・スコープ定義書に書くべき項目、指揮命令権を Platform Engineering 特有の業務パターンに照らして整理する方法、そして 6〜12 ヶ月かけて内製化へ引き継ぐロードマップを、契約初期の条項レベルまで落とし込んで解説します。読み終えたときに、社内稟議書と要件書のドラフトを書き始められる状態を目指します。

プラットフォームエンジニアを業務委託で確保するとはどういうことか

はじめに、Platform Engineering という職種を発注者視点で定義し、「なぜいま業務委託で確保するニーズが強まっているのか」を整理します。SRE との違いを扱う前に、まず「そもそも自社が欲しいのは Platform Engineer なのか」を判断する起点を揃えます。

プラットフォームエンジニアの役割を発注者視点で 3 行に整理する

技術者向けの解説では「Internal Developer Platform（IDP）を構築する」「Cognitive Load を下げる」といった専門語で語られがちですが、発注者が押さえておくべきポイントは 3 行に集約できます。

1. 開発者体験（DevEx）の改善: 自社エンジニアがコードを書き始めてから本番に届くまでの時間・手数・ストレスを減らすことが最終目的です
2. 共通基盤の整備: CI/CD テンプレート・IaC モジュール・監視標準・シークレット管理など、各開発チームが「毎回自作している」ものを共通化します
3. Golden Path の提供: 新規サービスを立ち上げるときに「この手順に従えば、監視もセキュリティもコンプライアンスも一通り揃う」という推奨経路を提供します

つまり Platform Engineering の顧客は「エンドユーザー」ではなく「社内の開発チーム」です。この視点が SRE との違いを理解する土台になります。

業務委託で確保するニーズが高まる 3 つの背景

Platform Engineering を業務委託で確保するニーズは、以下 3 点が重なって高まっています。

• 専任人材の採用難: 国内では Platform Engineer の求人数がまだ SRE ほど整理されておらず、経験者の絶対数が少ない。中途採用は半年〜1 年のリードタイムを想定する必要があります
• 立ち上げの速度: 「まず動く共通基盤を 3 ヶ月で用意する」というスピードが、採用の待ち時間より優先されるフェーズがあります
• 内製化前の実験: 自社にとってどこまでの共通基盤が本当に必要か、走りながら見極めたい。フルタイム採用の前に、外部の経験者と伴走してスコープを固めるアプローチが合理的です

いずれの背景も「業務委託で立ち上げて、その後に内製化する」という 2 段階の意思決定を前提にしています。この前提が、後述の契約設計と内製化ロードマップに直結します。

本記事の読み方｜SRE 案件との違いから内製化ロードマップまで

本記事は以下の順で意思決定に必要な材料を提示します。SRE との違いで「どちらを頼むべきか」を判断し、契約形態と発注要件で「どう頼むか」を決め、指揮命令ルールで「どう働いてもらうか」を整理し、内製化ロードマップで「どう引き継ぐか」を設計する——という流れです。最終セクションに 8 項目のチェックリストを用意しています。

SRE 案件との違いを発注視点で言語化する

Platform Engineer と SRE の違いは、技術ブログでは「サービスの信頼性 vs 開発者の生産性」で説明されることが多いのですが、発注者が契約設計時に直面する差分はもっと具体的です。ここでは既存の技術解説を前提にしたうえで、発注視点の 5 つの差分を対比表で整理します（役割定義の詳細はSREとPlatform Engineerの違いを3つのポイントで理解する（スリーシェイク）・SRE、DevOps、プラットフォームエンジニアリングの違い（Splunk）を参照してください）。

役割の違い｜「サービスの信頼性」と「開発者の生産性」を発注目的で書き分ける

役割の違いを一言で書き分けるなら、SRE は「本番稼働中のサービスの信頼性（SLO / エラーバジェット）」に責任を持ち、Platform Engineer は「社内開発者の生産性（Golden Path・IDP の利用率）」に責任を持ちます。

発注目的を書き出すときには次のように整理すると SES ベンダーとの認識齟齬が減ります。

• 「本番障害を減らしたい／MTTR を短縮したい／SLO を守りたい」 → SRE の発注目的
• 「新機能のリードタイムを短縮したい／開発チームが自走できる基盤を作りたい／CI/CD テンプレートを標準化したい」 → Platform Engineer の発注目的

社内で「両方欲しい」となる場合は多いのですが、業務委託で 1 名から始める場合はまずどちらか一方に軸足を置いた方が成果が見えやすくなります。

発注設計で直面する 5 つの差分（対比表）

発注要件書・契約書・稼働ルールを設計する際に直面する差分は、以下の 5 点に集約されます。

この 5 点はいずれも「準委任契約書の雛形」に反映すべき論点です。SRE の雛形をそのまま Platform Engineer に流用すると、オンコール当番条項が過剰に残ったり、社内共同開発のルールが不足したりします。

誤発注の典型パターン｜「Platform Engineer を頼んだのに、いつの間にか SRE 業務になっていた」を防ぐシグナル

現場で起きがちな誤発注の典型は「Platform Engineer として発注したのに、契約後 1〜2 ヶ月で本番障害対応・オンコール当番・SLO レビューに稼働の大半を吸われる」パターンです。逆に「SRE として頼んだのに、開発チームからの雑多な相談窓口になっている」というケースもあります。

以下は早期に軌道修正するためのシグナルです。月次の振り返り時に確認してください。

• インシデント対応時間が全稼働の 30% を超え始めた → SRE 業務に寄っている可能性
• Golden Path 整備・IDP 開発の進捗が 4 週連続で停滞 → 本来のスコープが押し出されている可能性
• 「今週も MTG が続いて設計時間が取れませんでした」がステータス報告に頻出 → 相談窓口化のサイン

軌道修正には、次章で扱うスコープ定義書とタスク優先順位の再握りが有効です。

業務委託契約の設計｜準委任契約を中心にした発注要件・スコープの決め方

Platform Engineering を業務委託で確保するときの契約形態は、原則「準委任契約」となります。ここではその根拠を整理したうえで、発注要件書・スコープ定義書に書き込むべき項目と、単価相場の考え方を扱います。

なぜ Platform Engineering は準委任契約が中心になるのか

業務委託契約の 2 大類型は「請負契約」と「準委任契約」で、大きな違いは成果物完成義務の有無にあります（詳細はシステム開発の業務委託｜準委任と請負の違い（Workship ENTERPRISE）を参照してください）。Platform Engineering が請負に馴染まない理由は次のとおりです。

• 成果物の範囲が事前確定しにくい: Golden Path や IDP は、社内開発チームからのフィードバックを受けながら継続改善する性質があり、「完成」の定義が曖昧です
• 業務が継続的: 一度作って納品するのではなく、日常的な改善・運用・チームサポートが本体です
• 社内エンジニアとの共同開発が発生: 請負契約は原則として受託側が独立して作業する前提であり、社内エンジニアとの継続的なペアプロは想定していません

これらの性質から、Platform Engineering は「業務の遂行そのものを委託する」準委任契約が自然な選択肢になります。月額制の準委任型契約で、月次単位で体制の縮小・拡大が可能な設計にしておくと、後述の内製化フェーズへの移行もスムーズです。

発注要件書に含めるべき 7 項目

準委任契約を有効に機能させるには、契約書とは別に「発注要件書」を用意し、業務範囲と期待水準を明文化しておく必要があります。以下 7 項目を含めてください。

1. 業務目的: 「開発チームのデプロイリードタイムを 24 時間から 2 時間に短縮する」など、Four Keys ベースの定量目標を書く
2. 現状課題: 「CI/CD テンプレートがチーム別に乱立」「シークレット管理が Slack DM 経由」など、対象となる具体的な状態を列挙
3. 対象システム範囲: 対象クラウド（AWS/GCP）、対象リポジトリ、触ってよい環境（開発／ステージング／本番）を明示
4. 優先タスク: 3 ヶ月以内に着手するトップ 3〜5 のタスク。網羅ではなく優先度で並べる
5. 社内エンジニアとの分業: 業務委託側が主導するタスク／社内が主導し委託側がレビューするタスク／完全に社内で行うタスクの 3 分類で仕分ける
6. 成果指標: Golden Path 利用率・IDP による自動化件数・社内開発チームからの CSAT など、稼働と別に成果を測る指標を 2〜3 個
7. 引き渡し条件: ドキュメント化・ペアプロ時間・オンボーディング資料の権利帰属を明記（詳細は後述）

7 項目のうちとくに 5 と 7 は Platform Engineering 特有の論点で、汎用の業務委託テンプレートには含まれていないことが多いため注意してください。

スコープ定義書のサンプル項目｜Backstage 導入・CI/CD テンプレート整備・監視標準化などタスク別の記述例

発注要件書とは別に、タスク単位のスコープ定義書を用意すると認識ズレを防げます。以下は代表的な 3 タスクの記述例です。

Backstage 導入・開発者ポータル整備

• スコープ: Backstage OSS 版のセルフホスト構築、ソフトウェアカタログ登録（最大 30 サービス）、TechDocs 導入、Scaffolder テンプレート 3 種
• スコープ外: プラグイン開発（別発注）、SSO 連携の IdP 側設定（社内担当）
• 完了条件: 開発チームからのソフトウェア登録が月 5 件以上セルフサービスで実行されている

CI/CD テンプレート整備

• スコープ: GitHub Actions の共通 workflow（build / test / deploy）3 種、Renovate 導入、脆弱性スキャンの標準化
• スコープ外: 個別サービスのデプロイスクリプト調整（各サービス担当）
• 完了条件: 新規リポジトリ作成時に共通 workflow が既定で適用される状態

監視・可観測性の標準化

• スコープ: OpenTelemetry 導入方針策定、ログ／メトリクス／トレースの命名規則、共通ダッシュボード雛形
• スコープ外: 個別サービスの SLI/SLO 設計（各サービス／SRE 担当）
• 完了条件: 新規サービスが命名規則に沿った可観測性を持つ状態でリリースされる

いずれも「完了条件」を数値または挙動レベルで書くことがポイントです。「〜を導入する」ではなく「〜が使われる状態」まで踏み込むと、成果の可視化が容易になります。

単価相場と稟議の説明軸

Platform Engineer の業務委託単価は、公開されている求人・案件情報の絶対数が少ないため、隣接領域（SRE・DevOps・シニアバックエンド）からの推定で稟議根拠を作るのが現実的です。国内フリーランス案件ポータル（レバテックフリーランス や Workship など）に掲載されている SRE・DevOps・プラットフォーム系案件の月額単価を集約すると、月額 90〜180 万円（週 5 日フル稼働ベース）のレンジが多く観測されます（2026 年時点の公開案件を参照）。エンジニア側目線での単価水準や需要感については、姉妹記事のプラットフォームエンジニア フリーランス単価とSREとの差分でも同様の相場感を整理しています。

稟議書での説明軸は以下の 3 点をセットで示すと通りやすくなります。

• 採用 vs 業務委託の総コスト比較: 中途採用の場合、年収 1,000 万円クラス＋採用コスト（エージェントフィー 30〜35%）＋オンボーディング 3 ヶ月分の生産性ロスを含めた総額と、業務委託の月額 × 契約期間を並べる
• リードタイム比較: 採用の中央値リードタイム（6〜12 ヶ月）と業務委託の稼働開始リードタイム（2〜4 週間）を比較
• 内製化への引き渡し設計: 単なる外注ではなく、内製化に向けた知識移転が契約に組み込まれている旨を強調（詳細は本記事後半で扱います）

なお正社員採用と業務委託どちらを選ぶかの判断軸は、正社員採用と業務委託の判断軸でも詳しく整理しています。

指揮命令権・偽装請負リスクをPlatform Engineering特有の業務に照らして整理する

準委任契約でよくある悩みが「業務委託のエンジニアにどこまで指示していいのか」という指揮命令権の問題です。Platform Engineering は社内エンジニアと共同で開発する性質が強いため、この線引きが SRE や通常の受託開発より難しくなります。

業務委託と指揮命令の基本ルール｜「業務の完成方法」への指示は不可

まず基本ルールを確認します。業務委託（準委任・請負のいずれも）は、発注者が受託者（業務委託エンジニア）に対して「業務の完成方法」を直接指示できません。指示できる範囲は「業務の内容・目的・成果」に限られます。この線を越えると、実態が「派遣」または「偽装請負」と判定されるリスクがあります。

具体的には以下が「指示不可（指揮命令に当たる）」の例です。

• 出社時刻・退社時刻の指定
• 具体的な作業手順・使用ツールの指定
• 業務中の逐次的な指示・進捗管理

一方で以下は「指示可能（発注内容の範囲）」です。

• 業務目的・要件・成果物の指定
• 納期・マイルストーンの合意
• 完成物の受領・検収

Platform Engineering 特有の業務パターンで起きやすい 4 つのグレーゾーン

Platform Engineering の業務は、上記の基本ルールを適用しづらいグレーゾーンが構造的に発生します。よく相談を受ける 4 パターンを示します。

(1) 社内 Slack での逐次指示

「この PR、今日中にレビューお願いします」「明日の朝会までにドキュメント更新お願いします」といったチャットが日常化していないか。逐次的な指示は指揮命令に該当し得るため、依頼はタスク単位のチケット化＋期限提示に置き換えるのが安全です。

(2) 社内朝会への強制参加

Platform Engineer は社内エンジニアとの協働が本業なので朝会参加は自然ですが、参加を「業務指示」として強制すると指揮命令性が強まります。契約書上は「必要に応じて情報共有会に参加する」と業務内容として組み込み、「毎日 10 時に参加すること」といった時間拘束は避けます。

(3) ペアプロ・モブプロ中の指示

社内エンジニアとペアプロ／モブプロで共同開発する場面で、社内リーダーが「こう書いて」「そこは違う、こっちにして」と細かく指示すると指揮命令になります。ペアプロは「一緒に設計・実装を検討する場」として位置付け、意思決定は業務委託エンジニア自身が行う設計にします。

(4) 急ぎ対応の割り込み

「本番でインシデントが起きたので今すぐ調査を」「営業から急ぎ相談が入ったので対応を」といった割り込みは、業務委託エンジニアが自主的に判断・対応する形にする必要があります。「今すぐやって」と命令する形は指揮命令に該当します。

いずれも「業務内容として合意しておく」「タスク単位で依頼する」「実行判断は受託側に委ねる」の 3 原則で対応できます。

契約書に書くべき 5 つの防御条項

グレーゾーンに耐える契約書にするには、以下 5 条項を明記しておきます。

1. 作業場所: 「作業場所は受託者が自由に決定できる」旨（リモート／自社オフィスの選択権）
2. 作業時間: 「作業時間・稼働配分は受託者が自主的に決定する」旨（コアタイムを設ける場合はその範囲）
3. 指示経路: 発注者側の窓口責任者を 1 名指名し、業務指示は原則としてその窓口経由・タスク単位で行う旨
4. 成果物の受領方法: マイルストーン単位／月次単位での成果物レビューと受領プロセス
5. 秘密保持と情報アクセス範囲: 触ってよいリポジトリ・環境・機密情報の範囲を明記（アクセス過剰付与も後々の火種になります）

これらは Platform Engineering に限らず準委任契約の一般論ですが、Platform Engineering は共同開発が発生するぶん、条項の運用に日常的な注意が必要になります。

SES との違いに要注意｜「SES で SRE を雇う」と「業務委託で Platform Engineer と契約する」の混同を避ける

現場でとくに混同しやすいのが「SES で SRE を雇う」と「業務委託で Platform Engineer と契約する」の違いです。SES（システムエンジニアリングサービス）は労働者派遣に類似する契約形態で、発注者が直接指揮命令できます。一方、業務委託（準委任）は上記のとおり指揮命令できません。

SES ベンダーからの提案と、フリーランスや小規模開発会社からの業務委託提案は、法的性格がまったく異なります。「SES での SRE 雇用」の感覚で Platform Engineer と業務委託契約を結ぶと、朝会強制参加・逐次指示・オンコール当番指定などが偽装請負判定のリスクに直結します。契約前に契約類型を明確にしておくことが第一歩です。

内製化までのロードマップを契約初期から設計する

業務委託で立ち上げた後、いつまでも外部依存が続くと「気付いたら 2 年経っていた」という状況になりがちです。ここでは 0〜12 ヶ月の時間軸で内製化ロードマップを示し、契約書に組み込むべき引き渡し条項を整理します。

0〜3 ヶ月｜業務委託エンジニア主導で最小構成の共通基盤を立ち上げる

最初の 3 ヶ月は業務委託エンジニアが主導し、最小構成の共通基盤（MVP）を立ち上げるフェーズです。この段階での目標は以下です。

• Backstage or 同等ポータルの立ち上げ（ソフトウェアカタログ・TechDocs）
• CI/CD 共通ワークフロー 3 種のリリース
• 対象範囲を 3〜5 サービスに絞ってドッグフーディング開始

この段階では「社内エンジニアが理解できるかどうか」より「動くものが手に入るか」を優先します。ただし、後述の内製化を見据え、コード・IaC・ドキュメントは初日から Git 管理と社内リポジトリへの配置を徹底します。

3〜6 ヶ月｜社内エンジニアがコードレビュー可能な状態を作る

3〜6 ヶ月目は、社内エンジニアが業務委託エンジニアのコード変更を「レビュー可能」な状態を作るフェーズです。

• 社内エンジニア 1〜2 名を「Platform Team アシスタント」として指名
• 業務委託エンジニアの PR は必ず社内アシスタントのレビューを経由するルール
• 週次のペアプロ／モブプロを 2〜4 時間確保
• アーキテクチャ意思決定はドキュメント化（ADR: Architecture Decision Record）

この時期のポイントは「レビュー可能 ≠ 実装可能」です。まずは読める・質問できる状態を目指します。実装能力の獲得は次のフェーズで扱います。

6〜12 ヶ月｜運用・改善を社内が主導し、業務委託は特定領域のスポット支援にシフトする

6〜12 ヶ月目は、社内アシスタントが実装主導に切り替わり、業務委託エンジニアはスポット支援・アドバイザリー役に移行するフェーズです。

• 新規機能開発の主担当を社内エンジニアに切り替える
• 業務委託エンジニアは週 1〜2 日程度に稼働縮小、レビューと設計相談を担当
• 業務委託エンジニアが最後まで持ち続ける領域（高難度部分・外部システム連携等）を明示

契約の視点では、この時期に月額を段階的に縮小する「稼働縮小オプション」を初期契約に組み込んでおくと、内製化の意思決定を先延ばしにせず済みます。

なお共通基盤の外注は Platform Engineering に限らず、データ分析基盤の外注 vs 内製やデータ基盤構築の外注でも似た論点が発生します。内製化ロードマップの検討時にあわせて参照してください。

契約書に組み込むべき 3 つの引き渡し条項

契約初期から内製化を握るためには、以下 3 条項を業務委託契約に組み込みます。

1. ドキュメント化義務: 主要な設計判断・運用手順は Markdown で社内リポジトリに残す旨と、更新頻度（例: 週次または PR ごと）
2. オンボーディング資料の権利帰属: 業務委託エンジニアが作成したドキュメント・スライド・チートシート等の著作権が発注者に帰属する旨
3. ペアプロ時間の下限: 月間ペアプロ／モブプロ時間の最低ライン（例: 月 8 時間以上）を明示

これらは「知識移転パートナー化」という抽象論を、契約条項レベルで担保するための最小セットです。とくに 3 は最初に握っておかないと、業務委託エンジニア側で「作業時間の圧迫」として後回しにされやすい項目です。

発注前チェックリスト｜社内でこの判断を握る 8 項目

ここまでの内容を、発注前に社内で握るべき 8 項目のチェックリストに集約します。稟議書・要件書ドラフトへ直接転記できる形式にしてあります。

8 項目のチェックリスト

• 1. 業務目的: Four Keys のどの指標を、いつまでに、どこまで改善するか（例: リードタイム 24h → 2h／6 ヶ月）
• 2. 対象範囲: 対象クラウド・リポジトリ・環境（開発／ステージング／本番）が具体化されているか
• 3. SRE との差別化根拠: 発注目的が「開発者生産性の改善」に軸足を置いており、SRE 業務（本番信頼性）の割合を明示できているか
• 4. 契約形態: 準委任契約であること／SES との違いを社内で認識できているか
• 5. スコープ定義: 3〜5 の優先タスクごとに「スコープ／スコープ外／完了条件」が定義できているか
• 6. 指揮命令ルール: 4 グレーゾーン（Slack 逐次指示・朝会・ペアプロ・急ぎ割込）への対応方針が決まっているか
• 7. 単価と稟議根拠: 採用 vs 業務委託の総コスト比較・リードタイム比較が稟議書に盛り込まれているか
• 8. 内製化ロードマップ: 0〜3 ヶ月・3〜6 ヶ月・6〜12 ヶ月の段階目標と、3 つの引き渡し条項が契約書に組み込まれているか

上記の 8 項目すべてに Yes と答えられれば、発注前の準備は整っています。1 項目でも空欄がある場合、そこが後々のトラブル源になりやすいポイントです。

よくある「発注前の意思決定ミス」5 例と回避策

とくに起きやすい発注前の意思決定ミスを 5 つ挙げます。

• ミス 1: 「Platform Engineer」の名称だけで発注し、実態は SRE 業務が中心 → 回避策: 発注目的を Four Keys でなく SLO/SLI で書いていないか確認
• ミス 2: SES ベンダーの人月単価と業務委託の月額単価をそのまま比較 → 回避策: 契約類型（指揮命令の可否・成果責任の所在）が違うことを稟議書に明記
• ミス 3: スコープ定義書なしに「業務委託だから柔軟に対応してもらえる」と期待 → 回避策: 契約前にスコープ／スコープ外／完了条件を書面で合意
• ミス 4: 内製化の話を契約後に持ち出す → 回避策: 初回打ち合わせから引き渡し条項を持参し、月次で進捗レビュー
• ミス 5: 指揮命令ルールを口頭確認だけで済ませ、現場で朝会強制参加・逐次指示が発生 → 回避策: 4 つのグレーゾーンごとに現場ルールを事前配布

いずれも「契約書だけ」では防げない領域なので、発注要件書・スコープ定義書・現場ルールの 3 点セットで対応します。

発注後 3 ヶ月で振り返るべき成果指標

発注後の 3 ヶ月時点で、以下の指標をレビューすることで軌道修正の判断ができます。

• Four Keys の改善幅: デプロイ頻度・変更リードタイム・変更失敗率・MTTR が目標値の何%まで到達したか
• Golden Path 利用率: 新規サービス・新規リポジトリのうち、共通テンプレート／共通 workflow を採用した割合
• 社内エンジニアのドキュメント自走率: 業務委託エンジニアが作成したドキュメントを、社内エンジニアが更新・追加できた件数

Four Keys の改善幅が期待より小さい場合、スコープが SRE 業務に押されている可能性があります。前述の「誤発注シグナル」を再確認してください。

なお、業務委託エンジニア側の視点は、姉妹記事のプラットフォームエンジニア フリーランス単価とSREとの差分でも整理しています。エンジニア側の期待水準・志向を発注者が理解しておくと、契約後のコミュニケーションが円滑になります。

Platform Engineering に限らず、外部エンジニアの活用や発注要件の設計にお悩みの方は、Workee のお役立ち資料もご参照ください。発注前に整理しておくべき論点をチェックリスト形式でまとめています。お役立ち資料一覧から自社のフェーズに合うものをお選びください。

Platform Engineering の発注要件書・準委任契約・内製化ロードマップの設計にお困りの場合は、お問い合わせフォームからご相談ください。要件の整理段階から一緒にスコープ定義書を書き下ろす形でご支援可能です。