システム内製化の進め方。採用より先に引き取れる状態を作る
正社員を採用し、外注をやめて内製化するのは、計画としてきれいな順序に思えます。ところが実際には、入社したエンジニアが初日にリポジトリへ入れず、開発環境も作れず、外部会社への質問係になる場合があります。
システム内製化の進め方で最初に決めるのは、採用人数ではありません。会社名義の管理権限を整え、現在の担当者以外のエンジニアでも現行システムを動かし、修正内容を確認できる状態を作ります。
僕は、外注を一度にゼロにする内製化を勧めません。まずは外部会社と一緒に影響範囲の小さい修正を行い、レビュー、テスト、デプロイまでの流れを社内でも理解します。採用活動を進める場合も、入社するエンジニアが引き取れる環境を先に作ります。
システム内製化の進め方は、採用より準備が先です
内製化は、社員だけで全コードを書く状態を意味しません。事業の優先順位を自社で決め、ソースコードと事業データへ自社名義でアクセスし、何を変更していつデプロイするかを自社で判断できる状態が先です。専門性の高い開発を外部へ頼み続けても、自社が継続と変更を選べるなら、システム運営の主導権は社内にあります。
準備がないまま一人目を採用すると、新しいエンジニアは外部会社から情報を集める仕事に追われます。管理者アカウントを申請し、動かない開発環境を直し、古い設計書と現行画面の差を調べます。機能開発を期待して採用したのに、引き継ぎ整備へ時間を使った人を成果不足と評価すれば、内製化は個人の頑張りだけに依存します。
採用前に必要なのは、完璧な設計書ではありません。会社が管理するリポジトリ、再現できる開発環境、検証環境へのデプロイ手順、失敗時の切り戻し、監視画面へアクセスする方法、直近の判断記録が必要です。加えて、誰がレビューし、誰がデプロイを承認し、外部会社へ質問する窓口を誰が持つかも決めます。
最初から全システムを対象にすると、棚卸しだけで止まります。売上、請求、予約、顧客対応など、停止時の影響が大きい業務フローを一つ選びます。業務フローに関係するコード、データ、外部サービス、運用手順だけを先に引き取ります。
管理権限や成果物の所在が分からない場合は、リポジトリ、クラウド、事業データ、設計資料、外部サービスの契約者を確認します。確認結果は外部会社を評価するためではなく、社内へ戻すべき権限と不足資料を決めるために使います。
システム内製化の進め方を四段階に分けます
第一段階では、自社で管理できるアカウントと権限を揃えます
最初にリポジトリのメンバー画面、クラウドの権限画面、ドメインの登録者画面、CIの実行履歴、監視の通知先、課題管理ツールを開きます。請求書の宛名だけで所有を判断せず、自社の担当者が利用者を追加し、退職者や委託終了者の権限を外せるか確かめます。
秘密情報をチャットで受け取る方法は引き継ぎにしません。会社が管理する保管先を決め、利用者ごとに個別の権限を発行します。最上位権限は日常作業に使わず、多要素認証の復旧先も会社側で管理します。
資料は、構成図、開発環境の作り方、デプロイと切り戻しの手順、バックアップからの復元、外部連携一覧、未対応課題、技術選定の理由を対象にします。資料が置かれているだけでは、引き継ぎができたとは判断しません。直近の変更を一件選び、資料の手順で安全な環境を再現できるか試します。
現行の業務委託に資料作成、説明、移管作業が含まれるかは、見積書と作業範囲で照合します。含まれない作業は、成果物、期限、確認方法、費用を外部会社と合意します。担当者の善意へ任せず、通常の開発予定から移管に使う時間を確保します。
第二段階では、外部会社と一緒に修正し、デプロイします
次に、影響範囲を追いやすい修正を一件選びます。たとえば、社内管理画面の文言修正です。事業側の担当者が目的と受け入れ条件を説明し、外部会社のエンジニアが実装とテストを行います。社内担当者も変更差分とテスト結果を確認し、外部会社と一緒に検証環境へデプロイします。
修正を依頼して納品を待つだけでは、内製化の準備になりません。社内担当者も、課題の確認から変更差分、テスト結果、デプロイ履歴、監視画面の確認まで外部会社と一緒に進めます。どの工程で誰の承認が必要か、問題が起きたときにどこまで戻すかを短い手順に残します。
社内にエンジニアがいない段階でも、事業側は受け入れ条件を決められます。表示する文言、操作できる利用者、記録すべきデータ、デプロイ後に確認する問い合わせ件数などを決めます。技術面の安全確認は外部の技術責任者が補いますが、事業として受け入れてよいかどうかは社内で判断します。
第三段階では、レビューとデプロイを社内主導へ移します
一人目の社内エンジニアが入ったら、最初から大きな機能を任せません。第二段階で外部会社と一緒に進めた修正と影響範囲の近い仕事を実装し、外部会社にレビューしてもらいます。社内エンジニアがデプロイ手順を読み、検証環境へ反映し、監視画面で結果を確認します。
外部会社と修正・デプロイを何度か行った後は、役割を入れ替えます。外部会社が実装した変更を社内エンジニアがレビューし、受け入れ条件と切り戻し方法を確認します。レビュー担当、回答期限、デプロイの承認者を決め、担当者が忙しい日に変更が止まる状態を避けます。
移行中の評価に、完成した機能数だけを使ってはいけません。開発環境を再現できたか、変更理由を追えたか、レビューで危険を見つけたか、デプロイと切り戻しを実行できたかを確認します。各項目は移管の完了確認であり、開発全体の生産性や事業価値を表す数字ではありません。
第四段階では、実行結果を見て外注範囲を狭めます
外注範囲を減らす日は、採用者の入社日だけで決めません。社内側が要件を整理し、実装をレビューし、検証環境へデプロイし、監視と切り戻しまで実行できた業務フローから移します。実行できない作業は、外部会社との分担を残します。
難しい基盤変更、セキュリティ確認、繁忙期の開発などは、内製チームができた後も外部の専門家へ頼めます。内製化の目的は外注費をゼロにすることではありません。社内が優先順位と合否を持ち、必要な専門家へ必要な範囲だけ頼める状態を作ることです。
システム内製化の進め方では、外部会社との契約を急に終えません
現行システムを長く保守した外部会社は、コードだけでなく、障害時の注意点や利用部門との調整方法も知っています。内製化を一方的な契約終了として伝えると、移管に必要な作業と通常開発の優先順位を決めにくくなります。
最初の説明では、特定の会社や担当者への不満ではなく、事業継続のために社内でも変更と復旧を行える体制へ移す目的を共有します。外部会社には、資料の提出だけでなく、社内担当者による環境構築、修正内容のデプロイ、復元試験への同席を依頼します。作業時間と費用を合意し、機能開発の予定も同じ分だけ減らします。
引き継ぎができたかどうかは、資料のページ数では決めません。社内側がリポジトリを取得してテストを動かし、検証環境へデプロイし、監視画面から異常を探せるかで決めます。外部会社は説明する側から、社内側の実行結果をレビューする側へ役割を変えます。
内製化と同時に委託先も替える必要がある場合は、開発会社を変更するときの並走と復旧試験を別の移行計画として扱ってください。新しい会社への移管と社内への移管を同じ日に終わらせようとすると、問題が起きた際の確認先が増えます。
社内にレビューできる人がいない段階では、CTO代行が橋渡し役に入れます。CTOを業務委託で置く場合の役割分担と同じく、僕が担うなら、管理権限と資料の棚卸し、引き取り試験の設計、外部会社の回答確認、採用候補との技術面談、最初の修正のレビューを担当します。事業の優先順位と受け入れ条件は経営側が持ち、技術上の不足を僕が具体的な作業へ分けます。
外部の技術責任者を入れる場合も、判断記録や手順を個人の保管場所へ置いてはいけません。会社名義のアカウントを使い、社内担当者も会議と引き取り試験へ参加します。内製化支援によって、新たな外部人材への依存を作らないためです。
最初の内製メンバーへ渡す仕事を一件決めます
採用は、引き取る仕事を説明できる段階で始めると、必要な経験と入社後の優先順位を候補者へ示せます。「システム全般を担当してほしい」では、担当範囲も最初の仕事も伝わりません。最初に担当する業務フロー、現在の外部会社の役割、社内へ移す範囲、レビューを頼める相手を求人票と面談で説明します。
候補者には、秘密情報を除いた構成図、直近の変更例、未対応課題、デプロイ手順、過去の障害記録を見せます。技術名の知識だけを聞かず、情報が欠けた状況で何を確認し、どの変更から引き取るかを話してもらいます。入社後に任せる仕事と面談の問いがつながります。
一人目の採用者を、新しい属人化の中心にしてはいけません。経営側は業務の優先順位と受け入れ条件を説明し、外部会社または外部の技術責任者は技術レビューを続けます。社内の別担当者も管理画面を開き、デプロイ日と障害時の連絡先を把握します。
現行システムに詳しい人がいる事実より、別の人でも同じ作業を進められる状態かを見ます。採用直後から、変更理由、レビュー結果、デプロイ手順を会社の保管場所へ残します。
明日は、最も顧客影響が大きい業務フローを一つ選び、次の五つを実際に開いてください。
- リポジトリのメンバー画面を開き、自社の管理者が利用者を追加できるか確認します。
- 開発環境の手順を開き、担当外のエンジニアが検証環境でテストを動かせるか確認します。
- デプロイ履歴と切り戻し手順を開き、最後に試した日と承認者を確認します。
- 監視画面とバックアップ履歴を開き、障害の検知先と復元試験の記録を確認します。
- 直近の変更記録を開き、事業側の目的、採用しなかった案、受け入れ条件を説明できるか確認します。
五つが揃わない場合も、採用活動を止める必要はありません。開けなかった画面や再現できなかった手順を、次回の外部会社との定例で作業範囲へ入れます。求人票の公開と引き取り準備は並行できます。
ただし、外部会社との業務を縮小する日は、影響範囲の小さい修正について、レビュー、検証環境へのデプロイ、切り戻しまで社内側で再現できた後に決めます。一件の修正からデプロイまで完了できたら、内製チームへ渡す二件目を選べます。完了できなければ、止まった画面か資料を次の作業へ戻してください。
内製化を始めたかどうかは、採用人数ではなく、会社側で修正からデプロイまで完了できるかで判断できます。
次に読む