LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

外部の専門人材に頼んでいた開発を社員に引き取りたいが、何から移せばよいのか分からない。契約が終わる月は決まっているのに、社員がまだ一人では改修できない——。外部人材活用から内製化へ切り替える場面では、こうした悩みが起こりがちです。ここでいう技術移転とは、外部人材が持っている設計の考え方や作業の手順、システムの仕様についての知識を、社員が自分で使える状態にすることを指します。

技術移転は、契約の終わりにまとめて資料を受け取るだけでは進みません。社員と外部人材が同じ作業を進める期間を取り、移ったかどうかを確かめる方法と、移した知識を契約でどう扱うかを先に決めておくと進めやすくなります。ただし万能ではなく、社員の側に作業を引き取る時間と人数がなければ、どれだけ丁寧に移しても定着しません。本記事では、外部人材から社内へ開発を移すマネージャーに向けて、移すもの、ペア作業とレビューでの移し方、移ったことの確かめ方、そして契約に書いておきたい点を整理します。

外部人材からの技術移転とは

技術移転と引き継ぎは、似ているようで終わり方が違います。引き継ぎは、ある日を境に担当を渡せば終わります。技術移転は、渡したあとも社員が自分で判断し、改修や障害対応を続けられるようになって初めて終わります。資料が全部そろっていても、社員がその資料を読んで次の変更を決められなければ、技術はまだ移っていません。

情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書」の第二版（2025年4月8日更新）は、システムの開発を委託する側と受託する側の契約の標準的な形を示した資料です。^*2 第8条は、円滑な開発のためには、受託する側の「ソフトウェア開発に関する技術及び知識の提供」と、委託する側による仕様の早い確定が重要だとしています。^*1 外部人材活用は、もともと技術と知識を提供してもらう関係です。内製化は、その知識を社内に残して、社員が使い続けられるようにする段階だと言えます。

知識を残す責任がどちらにあるかについても、同じ資料が触れています。保守の工程の説明では、システムの所有者である委託する側に、必要に応じて受託する側の協力を得ながら「保守内容の設計文書等への確実な反映や、業務・設計のノウハウ等の円滑な引継ぎ」などの管理が求められるとしています。^*1 技術移転は、外部人材が気を利かせてやってくれるものではなく、社内が計画して進めるものです。

何を移すのか

移すものを考えるときは、モデル契約書がシステムの作り直しの説明で使っている「業務知識」の分け方が参考になります。業務知識は、ドキュメントと有識者の2つからなるとされています。ドキュメントは「現行システムの仕様（運用・業務の流れと各機能の概要）が確認できる資料のこと」、有識者は「担当する一定範囲の要件定義・運用検証シナリオの作成など自律的にプロジェクト実行が可能である人材のこと」です。^*1

技術移転に当てはめると、移すものは資料と人の両方になります。資料を受け取っても、それを読んで判断できる社員がいなければ、次の変更のたびに外部人材に聞くことになります。反対に、社員が詳しくなっても資料が無ければ、その社員が異動したときに同じ問題が起きます。

表のうち、いちばん抜けやすいのは判断の理由です。設計書には何を作ったかは書かれていても、なぜそうしたかまでは書かれていないことが多いからです。理由を知らないまま改修すると、以前に避けた問題をもう一度作ってしまいます。

資料そのものの状態も確かめます。モデル契約書は、長く運用しているシステムでは担当者の交代で業務知識の一部が失われることがあり、「機能追加・修正やトラブルの改修に対して設計書等のドキュメントがメンテナンスされていないと、業務知識の断片化はますます深刻になる」としています。^*1 外部人材がいるうちに、設計書とソースコードが食い違っている箇所を一緒に洗い出し、どちらが正しいかを決めておくと、移したあとに迷わずに済みます。

ペア作業とレビューでどう移すのか

技術は、資料を読むだけではなかなか移りません。実際の作業の中で、外部人材と社員の役割を少しずつ入れ替えていくのが確実です。進め方は、次の図のように3つの段階に分けると整理しやすくなります。

1つ目の段階では、外部人材が作業し、社員は隣で見ます。同じ画面を2人で見ながら1人が操作するペア作業の形で、離れて働く場合は画面の共有でも構いません。ここで大事なのは、外部人材に手順だけでなく判断の理由を口に出してもらうことです。「この値を先に確かめるのは、過去にここで止まったことがあるから」といった説明が、資料に残りにくい知識です。

2つ目の段階では、社員が作業し、外部人材がレビューします。レビューは、設計書やソースコードを別の人が読んで問題を指摘する作業です。外部人材には、直し方だけでなく、なぜ直すのかも書いてもらいます。指摘を種類ごとに分けて記録しておくと、同じ種類の指摘が減ってきたかどうかで、次の段階へ進めるかを判断できます。

3つ目の段階では、レビューも社員どうしで行い、外部人材は聞かれたときだけ答える役に回ります。この段階で社員が判断に迷った点は、そのまま資料に足りなかった点なので、手順書や設計書に書き足します。

段階は、システム全体ではなく作業の種類ごとに進めます。画面の文言の修正はすでに3つ目の段階でも、データの項目を増やす改修はまだ2つ目、障害が起きたときの調べ方は1つ目、ということは珍しくありません。影響の小さい作業から先に進めると、社員が失敗しても取り返しやすくなります。なお、ペア作業やレビューの間は、社員の普段の業務を減らしておきます。横で見る時間を取れないまま外部人材の作業が進むと、1つ目の段階から先へ進めません。

移ったことをどう確かめるのか

技術移転がどこまで進んだかは、社員が何をできるかで確かめます。目安になるのは、先に見た有識者の説明です。担当する範囲を決めたうえで、その範囲の変更について、要件を決めるところから動作の確認まで、社員が自分たちで進められるかどうかを見ます。

確かめ方として取り入れやすいのは、次の3つです。

• 説明してもらう：社員が外部人材に設計と判断の理由を説明し、外部人材は聞き手に回って抜けを指摘する
• 一人でやってもらう：小さな改修を1件選び、社員だけでリリースまで進める。外部人材は見ているだけにする
• 過去の障害でたどってもらう：以前に起きた障害の記録を使い、原因の調べ方と直し方を社員が順に説明する

どれも、外部人材がまだ契約の期間内にいるうちに行います。できなかった点が見つかれば、その作業だけ前の段階に戻せば済みます。契約が終わってから分かると、もう一度頼み直すことになります。

確かめた結果は、作業の種類ごとに記録します。モデル契約書では、支援の作業が終わったあと、受託する側が業務終了報告書を作って提出し、委託する側が決められた期間内に点検して終了を確認する手続きが定められています。^*1 同じように、外部人材の担当を外すときは、移し終えた作業、まだ外部人材が担っている作業、社員だけで行った確認の結果を書いてもらい、社内で点検してから次へ進むと記録が残ります。支援を終えて社員だけで進められるかの判断基準は「内製化支援から自走へ、自走化判断で確かめる3つの基準」で扱っています。

契約に書いておくこと

技術移転は、外部人材にとっては本来の開発に加わる作業です。レビューで理由を書く時間も、社員に説明する時間もかかります。契約に書いていなければ、忙しい時期ほど後回しになります。モデル契約書の第4条は、個別の業務ごとに、作業の内容や役割分担、「検査又は確認に関する事項」などを定めて契約を結ぶとしています。^*1 技術移転も、移す作業、期間、確かめ方を、この個別の取り決めに書いておきます。

次に、移した知識を社内で使い続けられるかを確かめます。モデル契約書の第44条は、業務の過程で生じた発明やノウハウ等に関する権利について、それを生み出した人が属する側に帰属するとしています。^*1 この形のまま契約すると、外部人材が作業の中で生み出したノウハウ等は、外部人材の側に帰属することになります。説明してもらった内容を社内の資料として残し、契約の終了後も社内で使ってよいことを、あらかじめ書いておきます。

作ったプログラムの著作権も確認が要ります。第45条には、著作権をすべて受託する側に帰属させるA案、汎用的に使えるプログラムを除いて委託する側へ移すB案、共有にするC案の3つが用意されています。^*1 A案では、委託する側は、プログラムを自ら電子計算機で実行するために必要な限度で、複製や翻案（作り変え）ができるとされています。^*1 内製化したあとに社員がソースコードを大きく作り変えていくつもりなら、どの案で契約しているかを先に確かめます。著作権の考え方は「業務委託エンジニアの参画後に知る成果物の著作権の基本」にまとめました。

秘密情報の扱いも見落とせません。第41条は、相手から受け取った秘密情報を契約の目的の範囲内でのみ使うよう定めています。^*1 外部人材の会社が持っている手順書のひな形や社内向けの道具を、秘密情報として見せてもらった場合、契約が終わったあとに社内で使えるとは限りません。どの資料を自社のものとして受け取るのかを、一覧にしておくと食い違いを防げます。

つまずきやすい点

一つ目は、契約の最後の月にまとめて移そうとすることです。最後の月は、外部人材も残りの開発の仕上げで手一杯になりがちです。3つの段階を踏むには、それぞれの作業で社員が実際に手を動かす期間が要ります。技術移転は、終了の数か月前ではなく、契約の途中から始めておきます。

二つ目は、資料を受け取った時点で終わったと考えることです。先に見たとおり、設計書が最新でなければ、資料と実際のシステムが食い違っています。受け取った手順書のとおりに社員が一度作業してみて、書かれていない手順や古い記述を直すまでを、移す作業に含めます。

三つ目は、移す相手を社員1人に絞ってしまうことです。1人にしか移していなければ、その社員の異動や退職で、外部人材に頼っていたときと同じ状態に戻ります。少なくとも2人が同じ作業をできるようにし、担当を交代しながら進めます。外部の人が抜けるときの引き継ぎの漏れ方は「業務委託エンジニアの離任で引き継ぎが漏れる理由と防ぎ方」でも扱っています。

まとめ：技術移転で確かめておきたい3つの点

外部人材活用から内製化へ切り替えるうえで、技術移転について確かめておきたい点は3つに整理できます。第一に、移すものを資料と、その資料をもとに判断できる社員の両方で考えること。第二に、外部人材が作業して社員が見る段階から、社員が作業して外部人材がレビューする段階へ、作業の種類ごとに進め、契約の期間内に社員だけで作業できるかを確かめること。第三に、移す作業と確かめ方、ノウハウや著作権、秘密情報の扱いを契約に書いておくことです。この3点を踏まえておけば、「契約が終わってから、社員だけでは直せないことに気づいた」という事態を避けやすくなります。作業を引き取る社員の人数に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞（2025年4月8日更新）」（Word）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087884.docx）。出典：第4条（個別契約）・第8条（協働と役割分担）・第32条（業務の終了・確認）・第41条（秘密情報の取扱い）・第44条（納入物の特許権等）・第45条（納入物の著作権）と、解説のうち保守の工程の説明、システム再構築における企画プロセスの「業務知識の対象と概要」「業務知識が失われる背景」を参照（2026年9月確認）
2. *2　参考：IPA「情報システム・モデル取引・契約書（第二版）」（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：公開ページ。第二版の更新日（2025年4月8日）を参照（2026年9月確認）

Tweet