開発を外部に委託するときの進め方。委託先の種類と、失敗を避けるための準備

システム開発を外部に任せる方法は一つではありません。丸ごと委託する、人材だけを補う、専門領域だけを依頼する。どれを選ぶかで、自社に必要な体制も、かかる費用も、抱えるリスクも変わります。この記事では、委託先の種類ごとの違いと、着手前に決めておくべきことを整理します。

委託の3つの形

← 横にスクロールしてご覧いただけます →

受託開発は、要件を伝えれば成果物が出てくる形です。自社の負担は小さく見えますが、要件を正確に伝えられることが前提になります。要件が固まっていない状態で依頼すると、認識のずれが後で表面化します。

人材の補充は、自社が主導権を持ちます。柔軟に進められる一方、設計や優先順位を決める担当者が社内に必要です。ここが空席だと、人を入れても進みません。

専門領域の依頼は、社内にない技術だけを外部から補う形です。SAP、Salesforce、AI、セキュリティといった領域で使われます。全体は社内で見て、難所だけ任せるという構図です。

どう選ぶか

判断の軸は3つです。

• 要件が固まっているか／固まっている → 受託開発が候補。動く前提 → 人材の補充が適する
• 社内に主導できる人がいるか／いる → 人材の補充や専門領域の依頼が機能する。いない → 受託開発を検討
• 継続的に改善していくものか／継続する → 社内に知見を残す形が望ましい。一度きり → 受託でも支障は少ない

実務では、組み合わせることが多くなります。上流の構想策定だけ経験者に依頼し、実装は社内で進める。あるいは基盤の設計だけ外部に任せ、アプリケーションは自社で作る。全部を任せるか、全部を自前でやるかの二択ではありません。

着手前に決めておくこと

依頼を始める前に、次の点を決めておくと進行が安定します。

• 目的と成功の基準／何ができれば成功なのか。稼働することか、業務時間が減ることか
• 担当範囲の線引き／どこまでが依頼で、どこからが自社の作業か
• 意思決定者／仕様の判断を誰がするか。複数人いる場合、最終決定者を一人決める
• 成果物の定義／コード、設計書、手順書、テスト結果。何を納めてもらうか
• 検収の条件／何をもって完了とするか。判断の基準を文書にする
• 知的財産権の扱い／成果物の権利がいつ誰に移るか
• 稼働後の保守／誰が面倒を見るか。同じ相手に継続を頼むのか

とくに意思決定者と検収の条件は、後から揉める要因になりやすい部分です。「関係部署に確認します」が繰り返されると進行が止まり、「これで完成と言えるか」で認識が食い違うと精算が難航します。

よくある失敗の型

要件が固まらないまま請負契約にする。完成の定義が曖昧なまま完成義務だけが発生し、双方が消耗します。要件が動く前提なら、準委任契約で進めるほうが実態に合います。

社内に判断できる人を置かない。技術的な提案が来ても採否を決められず、進行が止まります。専門知識がなくても、「業務としてどうあるべきか」を判断できる人は必要です。

安さで選ぶ。単価だけで比較すると、品質やドキュメントの不足が後から効いてきます。稼働後に別の相手が引き継げない状態になれば、結果として高くつきます。

丸投げして中身を把握しない。稼働後に修正が必要になったとき、何がどう作られているか分からないという状態になります。

契約と実態がずれる。業務委託でありながら日々の指揮命令をしていると、労働者派遣法上の問題が生じる可能性があります。受け入れ方を決める段階で確認が必要です。

社内に残すべきもの

外部に任せる範囲を決める際、「これは社内に残す」と決めておくべきものがあります。

• 業務の設計／システムをどうするかの前に、業務をどうするかは自社の判断
• データの理解／自社のデータが何を意味するかは、外部には分かりません
• 選定の理由／なぜその技術・その構成を選んだのかの記録
• 運用の勘所／障害時にどう動くか、誰に連絡するか

これらが社内に残っていれば、委託先が変わっても継続できます。残す仕組みは、契約の段階で設計しておくのが確実です。ドキュメントを成果物に含める、社内メンバーが一緒に作業する、定例で内容を共有する、といった形が考えられます。