MySQLの移行案件は、声をかけられた時点では「サーバーを移すだけ」に見えることがあります。ところが進めていくうちに、運用の見直しまで踏み込む場合が出てきます。範囲の広がり方には見分け方があり、受ける前に確かめておけば、稼働後の想定外を減らせます。この記事では、移す範囲と作り替える範囲の分かれ目を、公的な資料に基づいて整理します。

1. 移すだけでは効果が出ない

「移すだけ」と聞くと、作業量が読みやすい案件に見えます。データと処理を新しい基盤へ動かして、動作を確かめれば終わり、という進め方を思い浮かべる人は少なくありません。

ところが実際に話を聞いてみると、範囲がどこまでなのかがはっきりしないまま進む案件もあります。打ち合わせの回数を重ねるうちに、当初の説明になかった作業が加わることも起こり得ます。この読みにくさが、移行案件を検討するときの不安の中心になっています。

ところが公的な資料では、刷新しても運用のやり方が従前のままだと、コスト削減の効果は十分に出ないとされています⁶。箱を新しくしても、中の進め方が変わらなければ、効果は狙いどおりに出てこないという指摘です。

同じ資料では、本番稼働の後も改善を続けることを前提に、予算と体制と日程を計画する必要があるとも述べられています⁷。移行の完了日をゴールに置くのではなく、稼働してからの数か月を含めて計画する考え方です。

移すだけの計画よりも、稼働後の改善まで含めた計画のほうが、依頼する側の意図に近いことが多くなります。案件の説明が「移設」という言葉だけで終わっているときほど、その先に何が続くのかを確かめる価値があります。

この分かれ目を早い段階で見分けられると、見積りの前提や日程の組み方に無理が出にくくなります。次の章では、この分かれ目をどう見分けるかを具体的に見ていきます。

範囲の広がりを恐れて移行の案件を避けるよりも、先に見分け方を知っておくほうが選べる案件は増えます。分かれ目を自分の言葉で説明できるようになると、打ち合わせの場でも落ち着いて話を進められます。

図の作成：Remogu編集部。デジタル庁の資料をもとに、移行案件で扱う範囲の違いを整理したもので、統計データではありません

2. 運用の作り替えが入るかの分かれ道

移行案件を検討するとき、最初に確かめたいのは「運用の作り替えが入るかどうか」という一点です。ここが読めていないと、見積りの前提が依頼する側と食い違ったまま話が進んでしまいます。

先ほど触れたとおり、資料は稼働後も改善を続ける前提で、予算と体制と日程を計画する必要があると述べています⁷。これは移行の作業だけでなく、その後の運用まで見積りの対象になり得るという意味です。

移行の作業量よりも、稼働後にどこまで関わるかという条件のほうが、実際の負担を大きく左右します。この条件が曖昧なまま参画すると、稼働後になって作業が積み増しになる場面が出てきます。

同じ資料には、見積りを取るときの留意点が項目として置かれています²。留意点が独立した項目になっているということは、見積りの前提を丁寧に確かめる必要がある場面だと、資料の側が想定していることになります。

案件の説明文だけでは、この分かれ道が見えないことがあります。「移設」という言葉が使われていても、稼働後の改善計画まで含む案件は少なくありません。言葉の印象よりも、稼働後の体制がどう書かれているかを見るほうが手がかりになります。

分かれ道を見誤ると、話が進んでから作業量の見通しが変わり、日程を組み直す事態にもつながります。逆に、最初の打ち合わせで分かれ道を確かめておけば、途中で条件を協議し直す回数は減らせます。

移すだけの案件よりも、運用まで作り替える案件のほうが、身につけた経験を幅広く生かせる場面が多くなります。範囲が広い分だけ、任される裁量も大きくなりやすいという見方もできます。

移すだけの場合と、運用まで作り替える場合の違い

2つの進め方を並べると、確かめるべき観点がはっきりします。以下の表は、コスト削減の効果、予算と体制と日程、見積りの前提、案件で確かめたいことの4つの観点で、移すだけの場合と運用まで作り替える場合を整理したものです。案件の説明文を読むときの照らし合わせとして使えます。

観点	移すだけの場合	運用まで作り替える場合
コスト削減の効果	十分に出にくいとされる6	改善を続けながら確かめられる
予算と体制と日程	移行の完了時点までを想定	稼働後も含めて計画する7
見積りの前提	移設の作業量が中心	運用設計や体制づくりまで含める
案件で確かめたいこと	対象システムと移設の方法	引き継ぐ運用の範囲と期間

移すだけの案件よりも、運用まで作り替える案件のほうが、稼働後の関わり方まで話し合っておく価値は大きくなります。表の左端にある観点を、案件情報や依頼者との打ち合わせで一つずつ確かめると、範囲の広がり方が見えてきます。

打ち合わせの場では、表の項目を一つの質問にまとめず、順番に一つずつ尋ねるほうが答えが具体的に返ってきます。まとめて尋ねると「基本的には移設です」という短い答えで終わってしまい、運用の見直しが含まれるかどうかがぼやけたままになりがちです。

出典：デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」をもとに作成

3. どの項目の話をしている案件か

資料には、移行に関わる論点がいくつかの項目として並んでいます。案件の説明が、そのうちどの項目に当てはまるのかを見分けると、求められている作業の中身がつかみやすくなります。

1つ目は、小規模なシステムにおける刷新という項目です³。対象が小さいシステムであれば、影響範囲も限られやすく、確かめる観点も絞りやすくなります。

2つ目は、組織ごとに独立していたシステムの刷新という項目です⁴。この場合は、複数の組織で別々に使われてきた仕組みを、一つにまとめる話が含まれることがあります。統合が入るかどうかで、確かめる内容は変わります。

3つ目は、クラウドへ移した後の刷新の時期という項目です⁵。すでにクラウドへ移した後の案件であれば、今回の依頼がその次の段階に当たるのか、最初の移行そのものなのかを分けて考える必要があります。

この3つを取り違えると、想定していた作業と実際に求められる作業の間にずれが生まれます。統合の話だと思って引き受けたら、単独のシステムを移すだけだった、という逆の食い違いも起こり得ます。項目を先に見分けることが、ずれを防ぐ近道になります。

項目ごとに確かめたいことを整理する

3つの項目に、見積りの留意点という項目を加えて整理すると、案件情報のどこを読めばよいかが具体的になります。以下の表は、資料に置かれている内容と、それぞれの項目で案件情報を読むときに確かめたいことをまとめたものです。

項目	資料に置かれている内容	案件で確かめたいこと
小規模なシステムの刷新3	小規模なシステムにおける刷新	対象がどの規模のシステムか
独立していたシステムの刷新4	組織ごとに独立していたシステムの刷新	統合を含む依頼かどうか
クラウド移行後の刷新時期5	クラウドへ移した後の刷新の時期	今回がどの段階に当たるか
見積りの留意点2	見積りを取るときの留意点	見積りの前提が説明されているか

項目を一つずつ言葉で確かめるよりも、この表に照らして案件情報を読むほうが、抜け漏れなく確認できます。統合を含む案件のほうが、単独のシステムを移すだけの案件よりも、話し合っておきたいことは多くなります。

4. 長く直してきたものへの対策

移行の対象になるシステムは、新しく作られたものばかりではありません。長い年月をかけて何度も手が加えられ、複雑になった仕組みが対象になることも多くあります。

資料には、長期間の改修で複雑になった現行システムへの対策が、項目として追記されています¹。裏を返せば、こうした対策が必要になるほど複雑な現行システムが、実際の案件では珍しくないということです。

複雑になった仕組みを移す案件では、動かし方だけでなく、なぜそう作られたのかという経緯まで確かめる作業が増えます。ここを見落とすと、移行の途中で想定していなかった依存関係が見つかり、日程が押すことにつながります。

長く直し続けてきた仕組みほど、手を入れた人がすでに離れていることもあります。作った経緯を知る人がいないまま移行を進めると、確認の手間はさらに増えます。経緯を尋ねられる相手がいるかどうかも、早い段階で確かめておきたい点です。

同じ資料は、要件定義と設計がいまもドキュメントを中心に行われているとも述べています⁹。複雑になった仕組みほど、その経緯を示す資料があるかどうかが、確認の負担を大きく左右します。

複雑になった仕組みへの対策が項目として置かれているという事実は、依頼する側もその難しさを認識していることの表れでもあります。難しさを隠さずに書いてある案件のほうが、打ち合わせで具体的な話をしやすくなります。

複雑さそのものよりも、その複雑さがどこまで文書として残されているかを先に確かめるほうが、見積りを組み立てやすくなります。次の章では、この「古いという認識」がどう扱われているかを見ていきます。

5. 古いという認識が薄い現場

ここまで見てきた「長く直してきた仕組み」は、いわゆるレガシーシステム（長く使われてきた古い仕組み）にあたります。移行の案件を考えるうえで、まず確かめたいのはその広がり方です。

資料によると、利用する側の企業の半数程度が、いまもレガシーシステムを抱えているとされています⁸。移行の依頼を受ける側から見れば、対象システムがこの半数程度の側に入る可能性は、決して低くないということになります。

半数程度という割合は、珍しい状況ではなく、むしろよくある状況だと捉えるほうが実情に近づきます。長く使われてきた仕組みに出会う前提で準備しておくと、案件を受けたあとの戸惑いを減らせます。

一方で、「レガシーシステムはない」と答えた割合は、日本が最も高いとされています¹⁰。実際には長く使われてきた仕組みを抱えていても、依頼する側がそれを古いと認識していない場合があるという指摘です。

この2つを重ねると、依頼する側の言葉をそのまま受け取るよりも、実際の仕組みの成り立ちを確かめるほうが手がかりになると分かります。「古くない」という説明よりも、いつ、どんな経緯で作られたシステムかを尋ねるほうが役立ちます。

認識のずれを前提に打ち合わせへ臨むと、依頼する側の説明を鵜呑みにしないぶん、見立てにも余裕が生まれます。古いという自覚が薄い現場ほど、実際に手を動かしてから気づく点が多くなる、と捉えておくと動きやすくなります。

認識と実態のずれをどう埋めるか

依頼する側の説明と、実際のシステムの状態にずれがあると、見積りの前提も揺れやすくなります。以下の表は、レガシーシステムの有無、古いという認識、要件定義と設計の3つの観点で、資料からわかることと、案件で確かめたいことを整理したものです。

観点	資料からわかること	案件で確かめたいこと
レガシーシステムの有無8	利用する側の企業の半数程度がいまも抱えている	対象システムがどちらに当たるか
古いという認識10	「ない」と答えた割合は日本が最も高い	依頼する側の説明をそのまま受け取らない
要件定義と設計9	いまもドキュメントを中心に行われている	元の作りの資料が実際にあるか

説明を言葉だけで受け取るよりも、この表の右端にある確かめ方を実際にたどるほうが、案件の実態に近づけます。次の章では、この元の作りの資料の有無が、見積りにどう関わるかを詳しく見ていきます。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」「DX動向2025」をもとに作成

6. 元の作りの資料があるか

移行の見積りを大きく左右するのが、元の作りを示す資料があるかどうかです。ここが揃っているかどうかで、確認にかかる時間は大きく変わります。

資料では、要件定義と設計がいまもドキュメントを中心に行われているとされています⁹。裏を返せば、ドキュメントが最新の状態に保たれていない現場も一定数あるということです。移行の対象システムが、そのどちらに当たるかを早めに尋ねる価値があります。

元の作りの資料がそろっている案件よりも、資料が残っていない案件のほうが、動かしながら仕組みを読み解く作業が増えます。同じ「移行」という言葉でも、必要な時間と手間は大きく変わってきます。

資料の有無は、経験を積んだ人ほど気にかけるポイントでもあります。積み上げてきた経験があれば、資料が薄い現場でも仕組みを読み解く手がかりを自分で見つけられる場合が多く、対応できる案件の幅も広がります。

見積りを取るときの留意点という項目にも、こうした前提の違いが関わってきます²。資料の有無を確かめないまま見積りを固めると、後になって作業量の見通しがずれる原因になります。

資料の有無は、案件の説明文には書かれていないことが多い項目です。だからこそ、依頼する側との打ち合わせで最初に尋ねておきたい観点になります。

資料が薄い案件を引き受けるときは、確認にかかる時間を見積りの前提にあらかじめ含めておくと、後から条件を協議し直す場面を減らせます。資料の有無を尋ねる一言が、稼働後の進め方を左右します。

7. 受ける前に確かめる順番

ここまで見てきた観点を、受ける前に確かめる順番として並べ直すと、案件情報を読むときの手順になります。範囲、運用、見積りの前提、資料の有無の順に確かめると、抜け漏れが減ります。

最初に確かめたいのは、移す範囲と作り替える範囲のどちらが対象になっているかです。次に、稼働後も改善を続ける前提が計画に含まれているかを確かめます⁷。ここまでで、依頼の大枠がつかめます。

続いて、見積りを取るときの留意点として書かれている内容を、実際の案件情報と照らし合わせます²。最後に、元の作りを示す資料が残っているかどうかを尋ねます。この順番であれば、話し合いの初期段階で確認が終わります。

順番を決めて尋ねる姿勢は、依頼する側からの信頼にもつながります。特に画面越しでのやり取りが中心になる案件では、確認の仕方そのものが、これまで積み上げてきた経験の裏づけとして伝わります。

この4つを一度に覚える必要はありません。案件情報を開いたら、まず範囲の言葉を探し、次に稼働後の記述があるかを確かめる、という形で少しずつ習慣にしていくと、無理なく続けられます。

順番を決めずに話を進めると、依頼する側も答える準備ができておらず、確認が後回しになりがちです。先に順番を示して尋ねるほうが、依頼する側にとっても答えやすくなります。

場所に縛られずに、積み上げてきた経験を生かせる案件を選びたいと考える人にとって、範囲を早めに見分けられることは大きな支えになります。Remoguでは、案件の90%以上がフルリモート可能です。移行の案件を検討するときも、まず自分の経験に近い条件から探してみると、範囲の見通しが立てやすくなります。

図の作成：Remogu編集部。移行案件を受ける前に確かめたい順番を整理したもので、統計データではありません

移す範囲と作り替える範囲は、案件情報のどこを見れば分かりますか

案件情報の説明文だけで判断せず、稼働後の関わり方や運用の見直しに触れているかを打ち合わせで尋ねるのが確実です⁷。範囲の広がりは言葉の印象より、稼働後の計画に含まれているかどうかで見分けられます。

元の作りの資料が無い案件は避けたほうがよいですか

避ける必要はありません。要件定義と設計がドキュメントを中心に行われている現場は多く⁹、資料が薄い案件もめずらしくありません。資料の有無を先に尋ね、見積りの前提に反映できれば、話し合いは進めやすくなります。資料が薄い現場を読み解く経験そのものが、次の案件で強みになることもあります。

確かめる順番を、依頼する側にどう伝えればよいですか

範囲、運用、見積りの前提、資料の有無の順に、一つずつ質問として投げかける形が伝わりやすくなります²。まとめて尋ねるより、順を追って確かめるほうが、依頼する側も答えを整理しやすくなります。自分の経験に近い案件を先に見ておくと、質問の具体度も上げやすくなります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」複雑さへの対策（2026年・2026年8月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見積りの作法（2026年・2026年8月確認）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」規模で変わる（2026年・2026年8月確認）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」分かれている前提（2026年・2026年8月確認）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」移した後の話（2026年・2026年8月確認）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」刷新の限界（2026年・2026年8月確認）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年8月確認）
＊10 IPA「DX動向2025」古い仕組みの見え方（2025年6月・2026年8月確認）