業務委託エンジニアが使えないと感じたときの3ステップ｜原因の切り分け方

定例ミーティングで「今週も想定より進んでいません」と報告を受ける。理由を聞いても、技術的な言葉が並ぶばかりで腹落ちしない。かといって「遅い」と指摘してよいのかも分からない。そんな状態が 2 週、3 週と続くうちに、「この人は使えないのではないか」という言葉が頭をよぎる——業務委託エンジニアを初めて受け入れた発注企業では、珍しくない場面です。

やっかいなのは、自分に技術的な知識がないと、その遅れが「妥当な範囲」なのか「明らかな力不足」なのかを判定できないことです。判定できないから強く言えず、強く言えないから状況は変わらない。その間も委託費だけは毎月発生し続けます。社内にエンジニアの上長にあたる人がいない企業ほど、この膠着は長引きます。

しかし、「使えない」は感覚であって、そのままでは是正を求める根拠にも、契約を終える根拠にもなりません。逆に言えば、この感覚を観測できる事実に変換し、原因の所在を切り分け、期限を切って判断するという順序さえ踏めば、非エンジニアの発注担当者でも意思決定は可能です。必要なのは技術力ではなく、手順です。

本記事では、業務委託エンジニアが「使えない」と感じたときに発注者が取るべき 3 ステップ（事実への分解 → 帰責の切り分け → 期限付きの判断）と、各ステップで具体的に何を集め、何を確認し、いつまでに何を決めるのかを、非エンジニアの立場から実行できる形で解説します。KPI も検収基準も設定していない、手元にあるのは違和感だけ——そこから出発できる手順として整理しました。

業務委託エンジニアが「使えない」と感じたとき、すぐ交代させてはいけない理由

不満が一定量を超えたとき、多くの発注者が最初に思いつくのは「別の人に代えてもらう」という選択肢です。しかし、切り分けを飛ばした交代は、状況を改善しないまま費用と時間だけを失う結果になりやすいものです。まずは、その理由と全体の見取り図を確認します。

「使えない」は感覚であって、契約上の指摘事項ではない

「使えない」という言葉には、実にさまざまな内容が詰め込まれています。進捗が遅い、実装の質が粗い、説明が要領を得ない、指示しないと動かない、連絡がつかない——これらはすべて別の問題であり、対処法も、そもそも相手の責任と言えるかどうかも異なります。

特に注意したいのが、契約形態との関係です。システム開発の業務委託で多く使われる準委任契約は、業務の遂行そのものを目的とし、受託者は善管注意義務（善良な管理者の注意をもって業務にあたる義務）を負いますが、成果物を完成させる義務は負いません。一方、請負契約は仕事の完成を目的とし、完成物に不備があれば契約不適合責任を負います（出典: 民法第632条・第643条・第644条・第656条）。

つまり、準委任契約で「思ったほど機能が完成していない」と感じても、それが直ちに契約違反になるわけではありません。あなたの不満が正当かどうかではなく、その不満が契約上の指摘事項として成立するかどうかは、別途の判断が必要なのです。この整理をしないまま感情で交代を切り出すと、交渉の場で相手に反論され、結局こちらが引き下がることになります。

即交代が高くつく3つの理由

判断を急ぐ前に、交代のコストを可視化しておきます。

1. コードがブラックボックスのまま社内に残る

外部エンジニアが去った後に残るのは、社内の誰も設計意図を説明できないコードです。ドキュメントが整備されていない状態で引き継ぎなしに終了すると、次に入る人は解読から始めることになり、着手までに数週間を要することも珍しくありません。「使えない」と感じている相手であっても、現時点でそのコードを最もよく理解しているのはその人です。

2. 再調達のリードタイムが読めない

代替人材を探し直す場合、候補者の選定・面談・条件調整・稼働開始までの期間が必要です。エージェント経由でも即日というわけにはいかず、稼働開始まで数週間から 1 ヶ月以上かかることを見込んでおく必要があります。その間、開発は完全に止まります。

3. すぐに契約を終えられるとは限らない

2024 年 11 月に施行されたフリーランス法（特定受託事業者に係る取引の適正化等に関する法律）では、6 か月以上の期間で行う業務委託を中途解除する場合、原則として解除日の少なくとも 30 日前までに予告することが義務づけられています（公正取引委員会 フリーランス法 Q&A）。「来週から来なくていい」という進め方は、契約内容にかかわらず取れない場合があるということです。

これらを合計すると、切り分けを飛ばした交代の実質コストは、少なくとも 1〜2 ヶ月分の停滞に相当します。逆に言えば、判断を数週間かけて丁寧に行うことは、決して遅すぎる対応ではありません。

3ステップの全体像と期間の目安

本記事で提案する手順は、次の 3 段階です。各ステップに期限を設けている点が重要です。期限がないと、切り分けそのものが先送りの言い訳になってしまうためです。

合計すると、着手から最終判断まで約 1 ヶ月です。今日から始めれば、来月の頭には「続けるか、条件を変えるか、終えるか」を根拠つきで決められる計算になります。

なお、すでに KPI や成果指標を数値で設定していて「未達であることが確認できている」段階にある場合は、本記事のステップ1（事実への分解）は大部分が完了しています。その場合は原因別の立て直し手順を扱う業務委託KPI未達の対応を参照してください。本記事は、KPI も検収基準も設定しておらず、手元にあるのが違和感だけという状態から出発する手順を扱います。

ステップ1｜「使えない」という感覚を観測可能な事実に分解する

最初のステップは、原因を探ることではありません。自分の不満を、他人に説明できる形に翻訳する作業です。ここを飛ばして原因分析に進むと、「なんとなく遅い気がする」という前提の上に推論を重ねることになり、相手と話しても水掛け論になります。

不満を5つの型に仕分ける

まず、自分が何に不満を感じているのかを型に分けます。外注したエンジニアが期待外れだと感じるとき、その中身はたいてい次の 5 つのいずれか、または複数の組み合わせです。

この段階では、必ず 1 つ以上を選びます。「全部だ」と感じる場合もありますが、その場合も最も強く困っているものから順位をつけてください。すべてを同時に是正要求すると、相手は何を優先すべきか分からず、結果として何も変わりません。

意外に多いのが、ふたを開けてみるとアウトプット量に問題はなく、コミュニケーション（進捗が見えないこと）だけが不満だったというケースです。型に分けるだけで、対処すべき対象が変わることがあります。

非エンジニアでも集められる事実データ

型が決まったら、その型に対応する事実を集めます。コードを読む必要はありません。非エンジニアでも確認できる場所だけを使います。

稼働報告・作業ログ 契約上、日次または週次の稼働報告を求めている場合は、その提出状況と内容を並べます。提出されていない週があること自体が事実です。

課題管理ツールの起票日と完了日 Backlog、Jira、Notion、GitHub Issues など、何を使っていても構いません。各タスクが「いつ起票され、いつ着手され、いつ完了したか」の 3 つの日付だけを拾います。技術的な中身を理解する必要はありません。

Pull Request の作成日と反映日 GitHub を使っている場合、リポジトリの「Pull requests」タブを開き、「Closed」で絞り込むと、変更が提案された日とマージ（反映）された日が一覧で表示されます。コードの中身は読まなくて構いません。件数と日付だけで、作業がどのペースで積み上がっているかが分かります。

定例の議事録・チャットのログ 「今週中に終わらせます」といった口頭の約束が、いつなされ、いつ達成されたか。議事録がない場合は、チャットの該当メッセージを日付とともに拾います。

質問への返信までの時間 チャットで質問を投げてから最初の返信が返るまでの時間を、直近 10 件程度計測します。反応の速さは、稼働実態を推し量る数少ない手がかりです。参考までに、開発会社が体制として掲げる水準の一例として、TechBand は顧客からの問い合わせに 2 時間以内で応答する体制を公表しています（出典: TechBand 公式サイト「特徴 04: 入念なコミュニケーション」）。これは特定サービスの運用方針であり業界共通の基準ではありませんが、「どの程度なら速いと言えるのか」の目安がまったくない状態よりは、判断の足場になります。

事実に落とし込む記述フォーマット

集めたデータは、次の 4 要素で 1 行にまとめます。ここが本記事で最も重要な作業です。

いつ / 何が / どの基準に対して / どう届かなかったか

記入例を示します。

ここで注目してほしいのは、「基準未設定」という記入が並ぶことです。多くの発注者は、この表を書き始めて初めて「自分は何も基準を伝えていなかった」ことに気づきます。

これは落胆すべきことではなく、極めて有用な発見です。基準未設定の項目は、後のステップで「相手に是正を求められる項目」ではなく「これから合意すべき項目」に分類されます。逆に、基準が存在する項目（口頭合意・契約書・仕様書に書かれているもの）は、正当に是正を求められる項目です。この仕分けが、次のステップの入力になります。

集めた事実を1週間で棚卸しする進め方

対象期間は直近 4 週間とします。それ以上さかのぼらない理由は 2 つあります。

第一に、稼働初期は立ち上がり期間であり、その時期のパフォーマンスを判断材料にすると評価が不当に厳しくなります。第二に、古い事実を持ち出すと、相手から「なぜそのときに言わなかったのか」と返され、議論が本筋からそれます。是正を求める場面では、直近の事実のほうが説得力を持ちます。

作業自体は 1 週間で終わらせてください。完璧なデータを集めようとすると、いつまでも着手できません。上記の 4 要素が 5〜10 行埋まれば、判断には十分です。この作業中に相手へ何かを伝える必要はありません。普段どおりに進行しながら、記録だけを取ります。

ステップ2｜原因が発注側にあるか受注側にあるかを切り分ける

事実が並んだら、次はその事実がなぜ起きたのかを判定します。ここでの順序が重要です。先に自社側を点検してから、相手側を見ます。逆順にすると、相手の問題が見つかった時点で自社の要因を検討しなくなり、交代しても同じことが繰り返されるためです。

まず発注側を点検する4項目

次の 4 項目を、ステップ1 で並べた事実の一つひとつに対して当てはめます。

1. 依頼の粒度は、実装に着手できるレベルまで分解されているか

「会員機能を作ってほしい」は依頼ではなく、要望です。会員登録に何の項目が必要か、メール認証は必要か、パスワードを忘れた場合はどうするか——こうした判断が未確定のまま渡されると、エンジニアは確認待ちで止まるか、推測で作って手戻りするかのどちらかになります。着手が遅い事実の裏に、この項目が該当していないでしょうか。

2. 必要な情報・アカウント・権限は渡っているか

テスト環境へのアクセス権、外部サービスの API キー、既存システムの仕様書、社内担当者への質問経路。これらの提供が遅れている期間は、エンジニアの側では作業ができない時間です。「渡した」つもりでも、申請から発行まで社内で 1 週間かかっていたケースはよくあります。

3. 意思決定の待ち時間はどれだけ発生しているか

「この仕様はどちらにしますか」という質問に、発注側が回答するまでに何日かかっているか。ステップ1 で集めたチャットログから、質問と回答の日付差を拾ってみてください。相手の返信の遅さを問題視していた発注者が、自社側のほうが待たせていたと気づく場面は少なくありません。

4. レビューと受け入れの担当が決まっているか

作ったものを誰が確認し、誰が「これで完了」と判断するのか。これが決まっていないと、完了したはずのタスクが宙に浮き、進捗が積み上がっているように見えません。技術的なレビューができる人が社内にいない場合、この役割が空席のまま進んでいることが多くあります。

この 4 項目のいずれかが該当する事実については、是正を求める前に自社側の改善が必要です。相手に伝えるとしても、「こちらの依頼が粗かったため、今後は次のように渡します」という形になります。

受注側に起因する3つの型を見分ける

発注側の点検で説明がつかない事実が残ったら、受注側の要因を見ます。業務委託エンジニアのスキル不足を疑う前に、次の 3 つのどれに当たるかを判別してください。対処法がまったく異なるためです。

型A: スキルギャップ

必要な技術領域に対して、経験や習熟が不足している状態です。特徴として、同種の作業が繰り返し時間超過する、修正するたびに別の箇所で不具合が出る、実装方針の説明を求めても選択肢を提示できない、といった事実が観測されます。この型は短期間での改善が難しく、担当領域の入れ替えか終了の検討対象になります。

型B: 稼働実態の乖離

契約上の稼働時間（例: 月 140 時間）に対して、実際の投入時間がそれを下回っている状態です。他案件との掛け持ちが原因であることもあります。特徴として、返信時間が特定の曜日・時間帯に偏る、稼働報告の提出が滞る、成果は出るが常に締切ぎりぎりになる、といった事実が観測されます。この型は、稼働報告の粒度を上げることで比較的短期に是正できる場合があります。

型C: 報告不全

作業自体は進んでいるが、その内容が発注者に伝わっていない状態です。特徴として、Pull Request や課題管理ツール上では作業が積み上がっているのに定例での説明が抽象的、質問への回答が技術用語のまま噛み砕かれない、といった事実が観測されます。実はこの型が最も多く、かつ最も是正しやすい型です。報告フォーマットを発注者側から指定するだけで解消することがあります。

「使えない」と感じた原因が型C だった場合、交代させるのは明らかに過剰な対応です。型の見分けが、判断の質を大きく左右します。

契約形態で求められる水準は変わる

帰責先を判定したら、最後にその事実が契約上どう位置づけられるかを確認します。同じ事実でも、契約形態によって是正要求として成立するかどうかが変わるためです。

（出典: 民法第632条〜第642条、第643条〜第656条）

準委任契約の場合、「予定していた機能が完成していない」ことだけを理由に是正を求めるのは、法的には筋が通りません。一方で、善管注意義務は負っているため、明らかに注意を欠いた業務遂行（合意した稼働時間を投入していない、報告義務を果たしていない、同種の不具合を繰り返し是正しない等）は、義務違反として指摘の対象になり得ます。

実務上の含意は明快です。準委任契約では、成果物の量を根拠にするのではなく、稼働実態・報告・プロセスの遵守を根拠に是正を求めるほうが成立しやすいということです。ステップ1 で稼働報告と返信時間を事実として集めておくべき理由が、ここにあります。

なお、契約書に検収基準や完了の定義が書かれていない場合、この判断はさらに難しくなります。その状態にあること自体が、次の発注に向けた改善課題です。

切り分けの結果を1枚に整理する

ステップ2 の成果物は、次の 3 列を加えた 1 枚の表です。これがステップ3 の入力になります。

この表を作ると、当初「全部ダメだ」と感じていた不満のうち、相手に是正を求められる項目は限られていることが見えてきます。同時に、自社側で先に手を打つべき項目もはっきりします。この 1 枚があれば、次の定例で何を話すかを迷わずに済みます。

ステップ3｜是正・条件変更・終了を期限付きで決める

切り分けが終わったら、いよいよ行動に移します。出口は 3 つ——是正を求めて継続する、条件を変更して継続する、終了する——のいずれかです。重要なのは、どの出口を選ぶにせよ期限をセットで決めることです。期限のない是正要求は、3 ヶ月後も同じ不満を抱えている未来につながります。

是正を求める伝え方——指揮命令にしない線引き

業務委託エンジニアに改善を求めるとき、多くの発注者が偽装請負を恐れて何も言えなくなります。しかし、伝えてよいことと避けるべきことの線引きは、実はそれほど複雑ではありません。

厚生労働省が示す区分基準（いわゆる 37 号告示）では、発注者が作業工程における仕事の順序や方法を指示したり、個々の作業者への割り当てを決めたりすることが、適正な請負とはみなされない要素として整理されています（厚生労働省 労働者派遣事業と請負により行われる事業との区分に関する基準及び当該基準に関する疑義応答集）。個人事業主への業務委託でも考え方は同様で、作業手順や勤務時間を細かく指示し、実態として指揮命令下に置いていると評価されると、契約の名称にかかわらず問題となる可能性があります。

裏を返せば、「何を、いつまでに、どの状態にしてほしいか」を伝えることは可能です。制約されるのは「どうやるか」と「いつ働くか」の指定です。具体的な言い換えを示します。

伝える順序も設計してください。感情を挟まず、ステップ2 で作った表の内容を、事実 → 影響 → 依頼の順に提示します。「7 月に差し戻しが 2 回発生しました（事実）。そのためリリース予定が 2 週間後ろ倒しになっています（影響）。今後は修正時に影響範囲の確認手順を共有いただけますか（依頼）」という形です。事実から入ることで、相手が防御的にならずに済みます。

立て直し期間を2週間で設計する

是正を求めたら、その効果を測る期間を明示的に区切ります。推奨は 2 週間です。1 週間では変化が観測できず、1 ヶ月では判断が遅くなりすぎます。

立て直し期間の設計では、次の 3 点を相手と合意してください。

1. 何をもって改善とみなすか

「もっと早く」ではなく、観測できる形にします。「週次報告を毎週金曜までに提出」「一次返信を当日中」「次の 2 週間でタスク A・B・C をテスト環境で確認できる状態にする」といった粒度です。ステップ1 で「基準未設定」と書いた項目は、ここで初めて基準を設定することになります。

2. 再評価の期日

「9 月 12 日の定例で、この 2 週間を振り返って継続の可否を判断します」と、日付で伝えます。判断の場があることを共有しておくと、相手も本気度を理解します。曖昧にしておくほうが角が立たないように思えますが、かえって双方にとって不利益です。

3. 期間中に発注側が用意するもの

ステップ2 の発注側点検で該当した項目は、この期間中に自社が解消します。「仕様の確定は依頼から 2 営業日以内に返します」「レビュー担当を〇〇に固定します」といった約束を、相手への要求とセットで提示してください。片方だけに改善を求める形にすると、立て直しは成立しません。

なお、この段階で改めて数値目標を設定して立て直しを進める場合、原因の型ごとに打ち手を変える必要があります。先に触れた業務委託KPI未達の対応で扱っている原因別の手順が、そのまま次の一手になります。

条件変更という中間解

是正か終了かの二択で考えると、判断はどうしても重くなります。実務では、その中間に位置する条件変更が有効な場面が多くあります。

スコープの縮小 担当範囲を絞り、得意領域に集中してもらう方法です。型A（スキルギャップ）が特定の領域に限られている場合に有効です。

稼働時間の調整 月 140 時間の契約を 80 時間に減らし、他の作業を別の手段でまかなう方法です。型B（稼働実態の乖離）で、実態に契約を合わせる形の是正になります。

担当領域の入れ替え フロントエンドからバックエンドへ、あるいは新規開発から保守・改修へと役割を変える方法です。同じ人でも、担当が変われば評価が一変することがあります。

報告体制の変更 型C（報告不全）の場合、報告のフォーマットと頻度を発注側から提示するだけで解決することがあります。厳密には条件変更ですらなく、運用の調整です。

単価の見直し 成果と単価が見合っていないと感じる場合、契約更新のタイミングで条件を協議する方法です。ただし、契約期間中の一方的な減額は、フリーランス法が禁止する行為に該当し得るため、必ず合意のうえで行ってください（公正取引委員会 フリーランス法特設サイト）。

条件変更は、相手にとっても受け入れやすい選択肢です。「使えないから切る」ではなく「役割を合わせ直す」という提示のほうが、関係を壊さずに稼働を続けられます。

終了を選ぶときの手順と中途解除の予告

立て直し期間を経ても改善が観測できず、条件変更でも整合しない場合は、終了を選びます。このとき確認すべきは 3 点です。

1. 契約書の解除条項

契約期間、中途解約の可否、解約の予告期間、違約金の定めを確認します。準委任契約は各当事者がいつでも解除できるのが原則ですが、相手方に不利な時期に解除した場合は損害賠償の対象になり得ます（民法第651条）。契約書に予告期間が定められている場合は、それが優先されます。

2. フリーランス法の中途解除予告

契約期間が 6 か月以上（更新により通算 6 か月以上となる場合を含む）の業務委託を中途解除・不更新とする場合、原則として解除日の少なくとも 30 日前までに、書面・電子メール等の記録が残る方法で予告する必要があります。また、予告を受けた相手から理由の開示を求められた場合は、遅滞なく開示しなければなりません（公正取引委員会 フリーランス法 Q&A）。この制度の詳細はフリーランス新法の解除告知義務で整理しています。

3. 終了理由の伝え方

理由の開示を求められる可能性があるため、伝えられる形で準備しておきます。ここで役立つのが、ステップ2 で作った 1 枚の表です。「なんとなく合わなかった」ではなく、事実と帰責の判定に基づいて説明できれば、相手も納得しやすく、無用なトラブルを避けられます。

終了を決めた後の具体的な手続き（通知文の作成、精算、機密保持、成果物の権利処理）は、業務委託を解除する5ステップで手順として整理しています。

交代させる場合に先に押さえる引き継ぎ

終了を決めたら、終了通知を出す前に引き継ぎの準備に着手してください。通知後は相手の協力意欲が下がるのが自然であり、通知前のほうが情報を得やすいためです。押さえるべきは次の 4 領域です。

1. 環境 開発環境・テスト環境・本番環境それぞれの構成と、動かすための手順。どのサービスを使っているか（サーバー、データベース、外部 API）の一覧。

2. 認証情報 各サービスの管理者アカウントが自社名義になっているかを確認します。エンジニア個人のアカウントで契約されているサービスがあると、終了後にアクセスできなくなります。これは終了時の実務トラブルとして頻出するため、優先度を最も高く扱ってください。

3. 設計意図 「なぜこの作りにしたのか」の記録です。コードそのものは残りますが、判断の理由は本人の頭の中にしかありません。1 時間の口頭説明でも録画・議事録として残しておくと、次の担当者の立ち上がりが大きく変わります。

4. 未完了作業 着手済みで完了していない作業の一覧と、それぞれの残り作業。課題管理ツール上のステータスと実態がずれていることがあるため、口頭で確認します。

引き継ぎを依頼する際は、それが契約上の業務範囲に含まれるかを確認し、含まれない場合は追加の稼働として費用を支払う前提で相談してください。ここを値切ると、結局は自社が損をします。

同じ「使えない」を繰り返さないために発注側が残しておくもの

一連の判断を終えたら、その経験を次の発注に持ち越します。ここまでの手順で最も価値のある副産物は、ステップ1 の表に並んだ「基準未設定」という記入です。基準未設定と書いた項目こそが、次回の契約前に決めておくべき項目にほかなりません。

稼働前に決めておく最小限の合意事項

次に外部エンジニアを受け入れるときは、稼働開始前に次の 4 点だけでも文書化してください。網羅的な契約書を作る必要はありません。この 4 点があるだけで、「使えない」という感覚が生まれたときに、それを事実として説明できるようになります。

このうち「完了の定義」は、社内に技術者がいない場合ほど丁寧に決める必要があります。検収の観点や品質基準の作り方は、成果物の検収・品質管理で具体的な仕組みとして解説しています。

判断の記録を次の発注に引き継ぐ

もう一つ残しておきたいのが、今回の判断プロセスそのものです。

• どの型の不満が発生したか（アウトプット量／技術品質／コミュニケーション／自走度／稼働とレスポンス）
• どんな事実を集め、どこで帰責を判定したか
• 立て直し期間に何を合意し、結果としてどう変化したか
• 最終的にどの出口を選び、その理由は何か

これを 1 ページにまとめて社内に残すと、次に外部人材を受け入れる担当者は同じ迷いを繰り返さずに済みます。また、稟議や社内報告の場でも、「感覚で判断した」のではなく「手順に沿って判断した」と説明できます。今回の経験は失敗ではなく、外部人材を扱うための社内ノウハウとして蓄積できるものです。

まとめ｜業務委託エンジニアが使えないと感じたときの3ステップ

業務委託エンジニアに対して「使えない」と感じたとき、発注者が取るべき手順を改めて整理します。

1. ステップ1（1 週間） — 不満を 5 つの型に仕分け、稼働報告・課題管理ツール・Pull Request・議事録・返信時間から事実を集め、「いつ／何が／どの基準に対して／どう届かなかったか」の 4 要素で書き出す
2. ステップ2（数日） — 先に発注側の 4 項目（依頼の粒度・情報と権限・意思決定の待ち時間・レビュー体制）を点検し、残った事実を受注側の 3 つの型（スキルギャップ／稼働実態の乖離／報告不全）に分類。契約形態を踏まえ、是正要求として成立するかを判定する
3. ステップ3（2 週間） — 指揮命令にならない形で是正を求め、改善の定義と再評価日を合意する。改善が見られない場合は条件変更または終了を選び、終了時は契約書の解除条項とフリーランス法の 30 日前予告を確認する

明日の定例で最初に取り組むことを 1 つだけ挙げるなら、直近 4 週間分の「いつ／何が／どの基準に対して／どう届かなかったか」を 5 行書き出すことです。相手に何かを伝える必要はまだありません。この 5 行が書けた時点で、あなたの不満は主観的な違和感から、説明可能な指摘事項に変わっています。そこから先の判断は、技術知識がなくても十分に下せます。

関連情報

外部エンジニアの受け入れ体制づくりや契約前の準備について体系的に整理したい方は、お役立ち資料もあわせてご覧ください。

現在の委託先との進め方や、開発体制の見直しについて相談したい場合は、お問い合わせフォームからご連絡ください。状況の整理段階からご相談いただけます。