外注で作ったシステムを内製に移すときの進め方 — 引き継ぐ範囲・残す資料・社内の担当をどう決めるか

外注して作ってもらったシステムが業務に入って何年か経つと、同じ種類の不満が出てきます。 画面の文言をひとつ直したいだけなのに、依頼して見積もりを待って日程を調整する。 問い合わせが来ても社内では答えられず、取り次ぐところまでしかできない。 そして何より、中で何が起きているのかを社内の誰も説明できない。 そこから「少しずつでも内製に移せないか」という話が出てきます。

ところがこの相談は、「社内にできる人がいない」という結論で止まることが少なくありません。 人員の問題は確かにありますが、止まる本当の原因はもう少し手前にあります。何をどこまで移すのかが決まっていないため、必要な人の像が描けないのです。 どこまで移すかが決まれば、それを扱えるのが社内の誰なのか、新しく人を入れる必要があるのかも判断できます。 この記事では、受託開発を手がけるCoconutWorksが、内製に移す範囲の切り方・残す資料の選び方・社内の担当の決め方を整理します。 費用の数字は扱いません。既存の仕組みの中身が分からない場合の調べ方は仕様書のない既存システムをどう引き継ぐかで扱っているので、ここでは発注側が何を手元に移すかという一点に絞ります。 また、ホームページの更新を社内に移す場合はホームページの更新を社内で回すための引き継ぎで扱っているので、ここでは業務システムの運用と改修を対象にします。

結論: 内製に移す4つの領域と、移す前に必要なもの

表で見ていただきたいのは、移しやすさが領域ごとにはっきり違うという点です。 内製化の話が「できる・できない」の二択になりがちなのは、この4つをひとまとめに考えているからです。 日々の運用は手順が決まっていれば移せますが、機能の追加まで移すなら開発を本業にしている人の時間が必要です。 全部を一度に移すか外注のままにするかではなく、領域ごとに順番を決めるほうが現実的に進みます。以下、順に掘り下げます。

なぜ内製化の話は途中で止まるのか

止まり方には共通の形があります。 社内で内製化を検討しようとすると、最初に出る問いが「誰がやるのか」になります。 これは自然な順番のようですが、実際には逆です。 担当者を決める段階で必要なのは、その人に何をしてもらうのかという範囲です。 範囲が決まっていないまま人材像を考えようとすると、「システム全般が分かる人」という書き方になり、 社内を見渡しても該当者がいないという結論に行き着きます。

たとえば、受注から請求までを扱う仕組みを外注して使っている会社を考えてみてください。 困っているのは、取引先が増えるたびに帳票の宛名の書き方を直したい、 画面の項目名が現場の呼び方と合っていないので変えたい、といった小さな話です。 この範囲だけを移すのであれば、必要なのは開発の技量ではなく、どこを触ればどこに反映されるかを知っていることと、間違えたときに戻せることです。 ところが「システムを内製化する」という言葉で検討を始めると、 設計から実装までできる人を前提に話が進み、人がいないから無理という答えになります。

もう一つ、検討が止まる理由として費用の見込みがあります。 内製にすれば外注費が減るという期待で始めると、 人の時間・環境の用意・学ぶための期間といった表に出にくい負担が見えた時点で判断に迷いが出ます。 内製化が効くのは支払いが減るからではなく、依頼して待つという時間がなくなるからです。 小さな直しに毎回調整が挟まる状態を解消することが目的であれば、 移す範囲は小さくて済み、判断もしやすくなります。 逆に費用の削減が目的なら、そもそも内製化が手段として合っているかを先に確かめたほうがよい場面です。

移す順番は、手が止まらない領域から

4つの領域には移す順番があります。 先に移すべきなのは、社内で扱えないと日々の業務の手が止まる領域です。 問い合わせへの一次対応と小さな直しがここに当たります。 逆に、機能の追加や作り替えは、頼んで待つことが業務の妨げになりにくいため、後に回しても困りません。

ただし、順番の中で一つだけ例外があります。 基盤と外部サービスの管理、つまり契約の名義と管理者権限は、 移す順番とは別にいちばん最初に押さえておくものです。 サーバーやドメイン、メール配信や決済といった外部サービスが外注先の名義や担当者個人のアカウントで契約されていると、 関係が終わった時点で何も触れなくなります。 ここは技術の話ではなく名義と支払いの話なので、社内の判断だけで進められます。 Web周りについてはホームページの制作会社を変えるときに引き継ぐもので同じ論点を扱っています。

日々の運用を移すときにつまずきやすいのは、手順ではなく判断のほうです。 問い合わせの対応手順は書けば伝わりますが、 「この問い合わせは社内で返す、これは外注先に回す」という線引きが言葉になっていないと、 担当者は迷ってすべてを回すようになります。そのほうが安全だからです。 線引きの書き方としては、やってよいことを細かく並べるより、回す側の条件を少しだけ挙げるほうが機能します。 データが消えたかもしれない、お金の計算が合わない、複数の人から同じ不具合の報告が来ている。 この種の条件に当たらなければ社内で返す、という形にすると迷う回数が減ります。

小さな直しを移すときに必要なのは、試す場所と戻し方です。 本番の環境だけで直す状態で権限を渡すと、間違えたときに業務が止まり、 一度止めてしまった担当者は、その後触るのをためらうようになりがちです。 触ってよい範囲を明記し、試してから反映する手順と、元に戻す手順を用意しておく。 ここを飛ばして権限だけ渡すのが、内製化がうまくいかない代表的な形です。 ホームページの更新を社内に移す場合も同じ構造で、ホームページの更新を社内で回すための引き継ぎで詳しく扱っています。

機能の追加と作り替えについては、外注のままにしておく判断も十分に成り立ちます。 業務の変化に合わせて作り替える頻度が年に数回なら、 そのために社内に開発の体制を持つのは割に合わないことが多い部分です。 続けて頼む形を整えるのであれば、月額で手を確保しておく進め方もあります。 取り決めの作り方は月額で開発を続けてもらうときの決めごとで整理しています。

残す資料は「次に触る人の最初の一手」から逆算する

引き継ぎの話になると、多くの場合まず仕様書が求められます。 しかし網羅的な資料は、作る側の手数が大きいうえに、書かれた時点で古くなり始めて更新されないという問題を抱えています。 結果として、分量はあるのに誰も見ないものが残ります。 これは手抜きの話ではなく、網羅を目的に書かれた資料は読む場面が想定されていない、という構造の問題です。

実用的なのは、社内の人が引き継いだあと最初に何をするかを並べて、そこから逆算する選び方です。 問い合わせが来たらどこを見るか。文言を直すならどこを触って、どう反映するか。 月初や月末に決まった作業があるか。エラーの連絡はどこに届くか。 こうして挙げていくと、必要な資料は業務の手順書に近い形になり、分量も思ったほど多くなりません。 設計の詳細は、必要になったときにコードと一緒に読むほうが現実的です。

一方で、コードを読んでも分からないものは優先して残す価値があります。 なぜこの作り方を選んだのか、過去に別の方法を試して合わなかったのか、 特定の取引先だけ扱いが違う理由は何か。この種の経緯は書き残されていないと失われ、 後から触る人が「不自然なつくり」と判断して直してしまい、元の事情が壊れることがあります。 AIを使ってコードから仕組みを読み解く進め方も広がっていますが、 読めるのは書かれていることまでで、なぜそうしたかは残っていなければ出てきません。 AIを使う開発会社に期待できる範囲はAIコーディングを使う開発会社に頼むと何が変わるのかで扱っています。

引き継ぎの取り決めで曖昧になりやすい書き方を並べます。 どれも悪意から生まれるものではなく、双方が自然に読める言葉が入っていることで起きるものです。

右の列はいずれも、受け取るものの名前・形・含まれる範囲を加えているだけです。 難しい条文は要りません。打ち合わせの議事録に同じ粒度で書いて、相手に確認してもらう形でも効きます。 むしろ、引き渡しの時期が来てから相談するより、 移す範囲を決めた時点で一度書いておくほうが、双方の手数が少なくなります。

社内の担当は一人に貼り付けない

移す範囲が決まったら担当者を決めますが、ここで起きやすいのが一人への集中です。 興味のある人、覚えの早い人が自然に窓口になり、その人だけが触れる状態が固まります。 移した直後は回るので問題が見えませんが、その人が異動・退職した時点で、移す前より悪い状態になることがあります。 外注先は日々の運用から離れており、社内にも分かる人がいない状態です。

防ぎ方は単純で、同じ作業を二人以上が触れる状態にしておくことです。 交代で担当する必要はなく、片方が普段扱い、もう片方が手順を見て同じ作業ができる、という程度で足ります。 このとき効くのが、前の節で挙げた手順書です。 網羅的な仕様書より、実際の作業を書いたものが残っているほうが、二人目が入りやすくなります。

もう一つ決めておきたいのが、役割の分け方です。 外注先への窓口になる人と、社内で判断する人は、必ずしも同じでなくてかまいません。 窓口は連絡の整理をする役で、判断する人は業務としてどうするかを決める役です。 これを一人が兼ねると、依頼の多い時期にその人の手が詰まって全体が止まります。依頼を受ける入り口を一か所にまとめ、決める人を名前で決めておくという考え方は、 外注を続ける場合でも内製に移す場合でも同じように効きます。

人を新しく入れるかどうかについては、移す範囲を決めてから考える順番を崩さないことをおすすめします。 日々の運用と小さな直しまでなら、業務の分かる既存の担当者が兼務で扱える範囲に収まることが多いものです。 機能の追加まで移すと判断したのであれば、開発を本業にしている人の時間が必要になります。 そのときも、採用だけが手段ではありません。外部のエンジニアに一定期間入ってもらう形もあり、 使い分けはSESと受託開発、どちらで頼むかで整理しています。

迷ったときのチェックポイントと、進めていく順序

内製に移すかを決める前に、次の5点に答えられるか確かめてみてください。 詰まった項目は、移したあとに「これでは回らない」として出てくる場所です。

• ①移したい理由を、待ち時間か費用かで言えるか — 目的が違うと、移す範囲も判断も変わります。
• ②4つの領域のうち、どこまで移すか決めているか — 「システムを内製化する」で止まっていないか。
• ③契約の名義と管理者権限が社内にあるか — 外注先や担当者個人の名義のままになっていないか。
• ④試す場所と、元に戻す手順があるか — 本番だけで直す状態のまま権限を渡していないか。
• ⑤同じ作業を二人目が扱えるか — 一人に貼り付いた状態で完了としていないか。

進める順序としては、①小さな直しの依頼が今どのくらいの頻度で出ているかを書き出す → ②契約の名義・支払い・管理者権限を一覧にして社内に寄せる → ③4つの領域のどこまで移すかを決めて外注先に分担の見直しとして伝える → ④移す範囲について、受け取る資料の名前と形を書いて依頼する → ⑤試す場所と戻し方を用意し、担当者が実際に一度直してみる → ⑥二人目が同じ作業をできるか確かめ、できない部分を手順書に足すという流れが無理がありません。

⑤を入れているのは、資料と権限がそろっても実際に触れるかは別の話だからです。 外注先との関係が残っているうちに一度通しておけば、足りないものがその場で分かります。 移したあとに頼める範囲をどう残すかはシステムの保守契約で確認すべきことで扱っています。

よくある誤解と、起きやすい失敗

「内製にすれば費用が下がる」 — 支払う先が外注費から人件費に移るだけで、 総額が下がるとは限りません。学ぶための時間、環境を用意する手間、 担当者が本業と兼務する分の負担は、見積書にも給与明細にも出てきません。 内製化で変わるのは金額ではなく、依頼して待つ時間のほうです。 費用を理由に始めると、負担が見えた時点で判断がぶれます。

「資料がそろえば引き継げる」 — 資料は必要ですが、十分ではありません。 引き継ぎで効くのは、資料の分量ではなく実際に一度触ったかどうかです。 説明を受けて理解した状態と、自分で直して反映できた状態の間には差があり、 その差は触ってみるまで見えません。 だからこそ、外注先との関係が残っているうちに一度やってみる工程を入れる価値があります。

「詳しい人を一人採れば回る」 — その人がいる間は回りますが、 仕組みの事情がその人だけに蓄積していきます。 一人体制は、移す前の「外注先しか分からない」状態を、「社内の一人しか分からない」状態に置き換えただけになりがちです。 人数を増やすという話ではなく、同じ作業を二人目が手順を見て扱えるか、という点で確かめてください。

「内製化とは外注先との関係を切ること」 — 切る必要はありません。 日々の運用と小さな直しを社内に移し、込み入った改修は引き続き頼むという分担は普通に成り立ちます。 それに、担当者の異動などで手が足りなくなったとき、 相談できる先が残っていれば一部を戻す判断ができます。 関係を完全に切ると、戻すときに現状の把握からやり直すことになりがちです。

よくある質問

まとめ

外注で作ったシステムを内製に移すとき、最初に決めるのは担当者ではなく範囲です。日々の運用と問い合わせ・小さな直し・機能の追加と作り替え・基盤と外部サービスの管理の4領域に分けると、移しやすさがはっきり違うことが見えてきます。 移す順番は手が止まらない領域からで、契約の名義と管理者権限だけは最初に社内へ寄せておく。 残す資料は網羅ではなく、次に触る人が最初に何をするかから逆算して選び、 コードから読めない経緯を優先する。担当は一人に貼り付けず、同じ作業を二人目が扱える状態にしておく。 そして、外注先との関係は切らずに分担を見直す形にしておくほうが、後から戻す判断ができます。 移す範囲の切り方や引き継ぎの進め方のご相談はシステム開発・業務改善サービスのページから承っています。相談・お見積もりは無料です。