開発の内製化と外注は、コア度と変更頻度で決めます

正社員の採用計画と開発会社の見積書が、同じ会議の机に並びます。「内製へ切り替えるべきか、外注を続けるべきか」と聞かれても、会社全体へ一つの答えを付けると現場は動きにくくなります。

開発の内製化と外注で迷ったら、機能ごとに事業のコア度と変更頻度を見ます。顧客が選ぶ理由に直結し、短い間隔で修正する領域は社内へ寄せます。標準化され、切り離して完成条件を書ける領域は外部の力を借ります。

僕は、全部内製にも全部外注にも賛成しません。社内が顧客との約束と優先順位を持ち、外部の専門家が実装量や専門領域を補う体制が現実的です。

開発の内製化と外注は、会社単位で決めません

全部内製を選ぶと、正社員を採用できるまで着手を待ち、必要な専門分野も常時雇う設計になります。開発量には波があり、データ移行、セキュリティ診断、基盤更新のように、限られた時期だけ深い経験が要る仕事もあります。全作業を社員だけで抱えると、採用できない仕事が未着手のまま残ります。

社員だけで作る方針は、社内へ知識が残る保証にもなりません。一人の端末に開発手順があり、公開できる人が一人しかおらず、選定理由が会議の記憶にしかなければ、雇用形態が正社員でも属人化します。

全部外注を選ぶと、顧客から届いた要望を開発会社へ伝え、見積もりを待ち、優先順位を相談する流れが増えます。顧客への約束まで開発会社へ預けた場合、技術上は作れる案でも、販売方法や現場運用と合わない危険があります。

外注が詰まる原因を、開発会社の能力だけへ帰すべきではありません。追加費用を承認する人が会議にいない、社内資料を渡す担当が決まっていない、質問への回答期限がない、完成を確かめる部門が参加していない場合も開発は止まります。

システム開発の丸投げで発注者に残る仕事で扱った通り、実装は外へ任せられます。顧客の誰を優先するか、予算をどこへ使うか、どの操作を合格とするかは社内に残します。

内製か外注かは、会社へ貼るラベルではありません。顧客との約束を決める役、技術案を評価する役、実装する役を機能ごとに分け、足りない役だけを採用や外部委託で補います。

内製化する開発は、事業のコア度から選びます

事業のコア度は、技術の難しさでは決まりません。顧客が会社を選ぶ理由、価格や利益の作り方、顧客へ約束した体験に、対象の機能がどれだけ影響するかで見ます。

たとえば予約サービスなら、空き枠の決め方、予約の成立条件、キャンセル時の扱いが顧客体験を左右します。一般的なログイン画面やメール送信も必要ですが、同じ重さで社内実装へ寄せる必要はありません。

コア度を確かめる時は、対象の機能を止めた場合に顧客へ何と説明するかを考えます。競合と同じ仕様へ替えた時に選ばれる理由が残るか、仕様変更を次回の外部定例まで待てるか、現場の例外を開発会社だけで選べるかも確認します。

答えが顧客との約束や収益の作り方に触れるなら、仕様を決める人と変更理由は社内へ置くべきです。社内へ置く対象は、コードを書く作業だけではありません。問い合わせを読み、採用しない案を選び、公開後の利用状況を確認する仕事も含みます。

コア度が高くても、専門家へ実装を頼めます。決済、認証、大規模なデータ移行などで外部の経験を借りながら、社内担当者が前提、受入条件、公開後に見る数字を決めます。実装者と仕様の決定者を分ければ、専門性を買いながら事業知識を社内へ残せます。

反対に、社内で書いたコードでも、顧客への影響を説明できる人がいなければ内製とは呼びにくいです。大切なのは雇用契約の種類ではなく、変更理由と合否を会社側が説明できる状態です。

外注する開発は、変更頻度まで見て切り分けます

変更頻度は会議の印象で決めません。課題管理ツール、公開履歴、顧客からの問い合わせを開き、過去3か月に何度仕様を変えたかを機能ごとに数えます。3か月という期間は将来を予測する統計ではなく、現在の受け渡し負担を見るための確認期間です。

変更回数には、文言修正、業務ルールの変更、障害対応、外部サービスの仕様変更を分けて記録します。件数は開発全体の生産性を示しません。社内と外部の間で、説明、見積もり、受入が何度発生するかを把握する材料です。

コア度が高く変更も多いなら、社内へ寄せます

顧客へ提供する価値に直結し、短い間隔で変更する機能は、社内担当者が日常的に触れられる位置へ置きます。顧客の声を読む人、仕様を選ぶ人、実装をレビューする人の会話を短くできるからです。

正社員の採用前なら、外部エンジニアが実装を続けても構いません。社内の事業責任者が優先順位を決め、技術案を評価できる人が変更差分を読み、会社名義のリポジトリへ理由を残します。採用後に実装を渡せる形まで先に作ります。

コア度が高く変更が少ないなら、社内に設計理由を残します

独自の計算方法や顧客データの構造は重要でも、頻繁には変えない場合があります。専門分野に強い外部エンジニアへ設計や実装を依頼し、社内の技術責任者が前提と採用理由を確認する分担が使えます。

納品物だけを受け取ると、数年後の変更時に同じ調査をやり直します。採用しなかった案、変えてはいけない条件、テスト方法、復旧手順を会社管理の文書へ残します。次回の変更を同じ委託先へ頼む場合も、社内から説明できる状態にします。

コア度が低く変更が多いなら、運用担当者が設定を持ちます

社内帳票の項目、通知文、承認経路のように、競争力への影響は小さくても変更が多い機能があります。毎回コード変更を外注すると、依頼と確認の負担が積み上がります。

設定画面を持つSaaSや管理画面を選び、業務を知る社員が安全な範囲で変更できる形を検討します。外部エンジニアには、設定では対応できない基盤部分や利用者のアクセス制御を任せます。業務担当者が触れる範囲と、エンジニアのレビューが要る範囲を画面単位で分けます。

コア度が低く変更も少ないなら、完成条件を切り出します

一度きりのデータ移行、標準的な外部サービス連携、更新頻度の低い社内ページは、外注しやすい領域です。対象範囲、入力データ、期待する出力、確認方法、終了時に返す資料を書けるためです。

外注しやすい仕事でも、会社名義のアカウントと成果物の保管場所は社内で管理します。担当者の退職や委託終了が起きても、利用者を追加し、停止し、別のエンジニアへ渡せる状態を確認します。

開発を内製化と外注で分けるなら、受け渡しを設計します

ハイブリッド体制では、社内と外部の境目に仕事が落ちます。障害を誰が最初に見るか、追加見積もりを誰が承認するか、公開前のテストを誰が行うかが空欄だと、実装担当者を増やしても待ち時間は減りません。

機能ごとに、事業上の優先順位を決める人、技術案を作る人、実装する人、変更を確認する人、公開を承認する人を記録します。同じ人が複数を担っても構いませんが、名前のない仕事は残さないようにします。

外部へ渡す作業範囲には、画面や機能だけでなく、会社管理のリポジトリへ変更を入れる方法、検証環境への公開、テスト結果、障害時の連絡先、委託終了時の説明を含めます。資料を提出して完了にせず、社内担当者か別のエンジニアが手順を実行できるか確かめます。

アクセスも同じ考え方で分けます。開発会社へ最上位の管理者アカウントを共有せず、作業に必要な利用者を個別に発行します。リポジトリ、クラウド、ドメイン、監視、課題管理の利用者一覧を会社側で開けるようにします。

外注から社内へ仕事を移す場合は、一斉に契約を終えません。システム内製化を小さな変更から進める手順のように、外部担当者と一緒に一件を実装し、次は社内担当者が実装して外部担当者がレビューします。公開と切り戻しまで社内で再現できた領域から移します。

社内に技術案を評価できる人がいない場合は、外部の技術責任者を実装会社と別に置く方法があります。設計案、見積書、変更差分、テスト結果を読み、経営者が選べる選択肢へ整理する役です。顧客への約束や予算の最終決定は経営側に残し、技術上の推奨と採用理由を会社の記録へ置きます。

外部の技術責任者も、新しい依存先にしてはいけません。会議資料、設計理由、採用候補者の評価基準を会社管理の場所へ残し、正社員が入った後に役割を縮められる形にします。

次の会議では、四つの画面から機能を一件選びます

次の経営会議では、会社全体の内製化方針を決める資料を作らなくて構いません。課題管理ツール、直近の公開履歴、顧客問い合わせの一覧、現在の委託契約とリポジトリのメンバー画面を開きます。

課題管理ツールと公開履歴から、過去3か月で変更が多かった機能を一件選びます。問い合わせ一覧では、顧客が対象機能を選ぶ理由と、利用できない時の影響を読みます。委託契約では、追加変更、資料作成、引き継ぎが作業範囲に入っているかを確認します。

一枚の記録に、機能名、顧客への約束、3か月の変更回数、優先順位を決める人、技術案を評価する人、実装する人、受入を行う人、成果物の保管場所を書きます。変更回数が多い事実だけで採用人数は決めません。空欄になった役と、外部との受け渡し回数を見ます。

コア度が高く変更も多いなら、社内の担当者を置き、採用か配置転換の対象にします。コア度が低く変更も少ないなら、完成条件を決めて外部へ切り出せます。中間にある機能は、仕様を選ぶ役を社内に残し、実装だけを外部へ任せる案から試せます。

事業の段階が変われば分担も変わります。開発体制を事業の段階ごとに組み替える方法も参照し、顧客要望、運用負荷、採用状況を見直す日を記録へ入れてください。

明日決める対象は、会社全体を内製か外注へ寄せる方針ではありません。変更が多かった一機能について、顧客との約束を誰が決め、誰が実装し、誰が公開後の結果を見るかを決めます。

三つの担当が埋まれば外注を活かせます。空欄が残る場合は、次の発注より先に担当者を置いてください。