表計算ソフトの上に何年もかけて積み上げられてきた仕組みの相談は、担当者の異動や引き継ぎの時期に、静かに舞い込んできます。切り出し方はほとんどの場合同じで、「もう限界だから作り直したい」という言葉ではなく、「担当者が変わっても止めずに回したい」という声から始まります。だからこそ最初に取り組む仕事は、実装ではなく移す先を決めることになります。この記事では、移す先が分かれる基準と、決めるために確かめたい前提を、クライアントと一緒に整理していきます。

1. 「作り直したい」から始まらない相談

依頼の言葉が「作り直したい」にならない理由

相談を受ける場面を思い浮かべると、切り出し方はいつも同じです。「もう限界だから作り直したい」ではなく、「担当者が変わっても止めずに回したい」という声から始まります。真新しい仕組みへの憧れよりも、今の仕組みを失うことへの不安のほうが、相談の出発点になっています。

この言い方の違いは軽く扱えません。作り直す前提で耳を傾けると要件定義や機能の洗い出しから入りたくなりますが、相手が実際に抱えているのは「今の仕組みを、誰かが安心して引き継げる形に整えたい」という願いのほうです。ここを取り違えると、聞く順番そのものがずれてしまいます。

最初に求められているのは、真新しい仕組みを組み上げる技術力よりも、今の前提を壊さずに移す先を選び切る判断力のほうです。作る力よりも、決める力のほうが先に試されます。

だからこそ最初の対話では、今の仕組みを否定する言葉を選ばないことが大切です。長く使われ続けてきた仕組みには、そのぶん積み重ねてきた事情があります。

最初に握るのは実装ではなく移す先

表計算ソフト上の仕組みを抱える企業の外側でも、道具はすでに動き始めています。ノーコードやローコードの仕組みを一部利用も含めて取り入れている企業は、全体の約4割にのぼります¹。相談を受ける前から、選択肢はすでに社内のどこかで動き始めている場合があります。

同じ調査では、システム開発の内製化を進めている企業も約半数にのぼります¹。つまり移す先の候補は、ゼロから探し出すものではなく、社内の別の部署ですでに試されている場合があります。

だからこそ最初に取り組む仕事は、白紙に設計図を描くことではありません。今どの選択肢がどこまで進んでいるかを、依頼主と一緒に確かめることです。ここを飛ばして提案を急ぐと、後になって「別のやり方がすでに動いていた」と分かり、決め直しになります。

2. 移す先の3つの分かれ方

3つの選択肢と、それぞれが向く場面

移す先を尋ねられると、つい一つに絞り込みたくなります。しかし実際の現場で起きているのは、選択肢が一つに定まらず、3つの方向に分かれていく状況です。

一つ目はノーコードやローコードの仕組みに置き換える道、二つ目は内製での開発体制を整える道、三つ目は今の仕組みを一部残しながら併用する道です。ノーコードやローコードの仕組みを一部利用も含めて取り入れている企業は、全体の約4割にのぼります¹。内製化を進める企業も、約半数にのぼります¹。移す先の候補は、遠くから探すものではなく、すでに社内のどこかで動き始めています。

3つの道は、どれも間違いではありません。向いている条件が違うだけです。ノーコードやローコードの仕組みは、扱う量や更新の頻度がある程度定まっている業務に向き、内製での開発は、育てながら使い続けたい仕組みに向きます。一部を残す道は、今すぐには手を付けられない事情がある場合の現実的な選び方です。次の表に、それぞれが向く場面と、決める前に確かめる前提をまとめました。

選択肢	向いている場面	確かめる前提	決め手になる問い
ノーコード・ローコードの仕組みに置き換える	扱う量や更新の頻度がある程度定まっている業務	続ける人が仕組みの操作に慣れられるかどうか	誰が日常の設定変更を見ていくか
内製での開発に切り替える	今後も機能を育てながら使い続けたい仕組み	要件定義や設計を担える体制があるかどうか	設計の考え方を引き継ぐ人がいるか
今の仕組みを一部残して併用する	今すぐには手を付けられない事情がある業務	残す部分と移す部分の境目が明確かどうか	境目をどこで区切るか

3つの数字を並べても、どれか一つが圧倒的に優勢というわけではないことが見えてきます。だからこそ選ぶ基準は、数字の大小ではなく、続ける人と引き継ぐ前提のほうに置くことになります。

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

決め手になるのは続ける人と引き継ぐ前提

表と図を並べて見えてくるのは、どの道を選ぶかよりも先に、確かめることがあるという点です。それが、続ける人が社内にいるかどうかという前提です。

選択肢そのものの新しさよりも、選んだ先を支え続ける体制のほうが、結果を左右します。ここを飛ばして道具だけを決めると、移した先でまた同じ悩みが繰り返されます。

続ける人がいるかどうかで、この先の話は大きく分かれます。では、その分かれ方は具体的にどう違うのでしょうか。

3. 続ける人の有無という分かれ目

「いる」場合と「いない」場合の違い

移す先を決めても、その後の景色は同じにはなりません。分かれ目になるのは、選んだ仕組みを日常的に見ていく人が、社内にいるかどうかです。

続ける人がいる場合、移行はゆっくりでも定着していきます。逆に続ける人がいないまま移すと、しばらくして元の表計算ソフト上の仕組みに戻る相談が、また舞い込んできます。移した直後は動いていても、半年後に同じ相談が繰り返される理由はここにあります。

移す先の技術を選ぶことよりも、その技術を見ていく人を先に置くことのほうが、長い目で見た結果を左右します。

この見分けは、移す先を提案する前に済ませる作業です。技術の説明を先にしてしまうと、続ける人がいるかという確認が後回しになり、話の順番が入れ替わってしまいます。

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

続ける人を先に置く順番

内製化を進める企業が向き合う課題を尋ねると、人材の確保や新技術への対応を挙げる企業が目立ちます¹。続ける人を置くこと自体が、すでに現場の悩みの中心にあるということです。

この悩みは、依頼主だけで解決できるとは限りません。続ける人を社内で育てる道と、社外から力を借りる道の両方を、選択肢として並べて考える余地があります。

社外から力を借りる場合も、丸ごと任せる形である必要はありません。移行の期間だけ加わってもらい、続ける人が育つまでを一緒に見ていく関わり方もあります。

続ける人をどう置くかまで話が進んだら、次に見るのは、決めごとを飛ばして移した場合に何が起きるかです。

4. 決めごとを握らずに移した場合の結果

データの持たせ方が決まらない状態

続ける人を置く目処が立つと、次はつい実装に急ぎたくなります。しかし決めごとを飛ばしたまま移すと、後になって効いてくる問題が残ります。

データをどう持たせ、どう活かしていくかという方針を明確にしている企業は少なく、対応の遅れが目立ちます¹。移す前にこの方針を握らないと、移した先でも同じ状態が続きます。

後回しになる設計の作り込み

モジュール性やデータモデルを意識した設計に取り組む企業は、特に利用する側の企業を中心に、今も少ない状況です¹。ここを飛ばすと、移した先の仕組みも、直しにくい形のまま育っていきます。

後から直しにくい形は、担当者が変わるたびに重荷になります。設計の作り込みは、移す作業そのものより前に済ませる工程です。

決めごとの有無による、後からの違い

決めごとを飛ばした場合と、先に握った場合とで、後から起きることは大きく変わります。次の表は、データの持たせ方と設計の作り込みという2つの決めごとについて、握らずに移した場合に起きやすいことと、先に握った場合の違いをまとめたものです。移す前の相談で、この2点を確かめておくと、後戻りが減ります。

決めごと	握らずに移した場合	先に握った場合
データの持たせ方	移した先でも方針が定まらないまま、対応の遅れが続きます	移す前に置き場所と使い方の方針を共有できます
設計の作り込み	モジュールごとの区切りが曖昧なまま育っていきます	区切りを決めてから移すため、後から直す余地を残せます
引き継ぎの資料	手順の理由が担当者の記憶だけに残ります	背景を含めて資料に残せます

表に並べた2つの決めごとは、どちらも移してから握るのでは遅く、移す前の相談の中で確かめる事柄です。あとから直す手間は、先に決める手間よりも重くなります。

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

早く動かすことよりも、動かす前にこの2点を握ることのほうが、結果的に近道になります。工程の前提や引き継ぎの材料も、同じように移す前に確かめる事柄です。では、その工程の前提とは何でしょうか。

5. 工程の前提と引き継ぎの材料

要件定義と設計は今もドキュメント中心

移す先を決めたあと、実際の工程に入ると、思っていたよりも前提が古典的だと感じる場面があります。

要件定義や設計は、今もドキュメントを中心に行われています¹。新しい仕組みに移すからといって、この進め方そのものが急に変わるわけではありません。

ドキュメントを中心にする進め方は、それ自体が問題というわけではありません。移す先を選ぶ際に、引き継ぎの材料として活かせる形になっているかどうかが問われています。

開発の進め方はウォーターフォールが主流

開発の進め方も、今なおウォーターフォール型の手法が主流です¹。段階を追って確かめながら進める前提は、移す先が変わっても引き継がれます。

新しい仕組みに合わせて進め方を一新することよりも、今の工程の前提に合わせて引き継ぎの材料を整えることのほうが、現実に近い進め方です。

引き継ぎの材料として意味を持つのは、仕組みの中身そのものよりも、なぜその手順になっているかという背景です。表計算ソフト上の仕組みには、この背景が担当者の記憶に残っているだけのことが少なくありません。

記憶に残っているだけの背景をどう扱うかは、このあとの、知識が人に付いているという話につながります。

6. 人に付いた知識の扱い

体系立っていない技術情報の集め方

表計算ソフト上の仕組みを長く見てきた担当者に話を聞くと、手順の理由がすらすらと出てくることがあります。頼もしく見える一方で、これは引き継ぎの面では心もとない状態でもあります。

技術情報の収集は体系的な仕組みを持たず、個人に委ねられている企業が数多くあります¹。知識が仕組みではなく人に付いている状態は、表計算ソフト上の仕組みに限った話ではありません。

属人化は、移す作業と重なった瞬間に、引き継ぎの負担として一気に表面化します。

担当者の頭の中にある知識を移すことよりも、知識の置き場所そのものを人から仕組みに移すことのほうが、移行の本体に近い作業です。

知識の置き場所の変え方

知識の置き場所を変えるといっても、やり方は一つではありません。次の表は、知識がどこに置かれているかによって、引き継ぎのときに起きやすいことと、整えておくとできることを並べたものです。今どこに近いかを確かめると、次に手を付ける場所が見えてきます。

知識の置き場所	引き継ぎで起きやすいこと	整えておくとできること
特定の担当者の記憶	担当者が離れた時点で手順の理由が分からなくなります	先に理由を聞き出して言葉にしておけます
共有フォルダの断片的なメモ	どれが最新か分からず、探す手間がかかります	更新日と経緯を添えて整理し直せます
整理された引き継ぎ資料	担当者が変わっても手順の理由をたどれます	次に移す先を選ぶときの材料にもなります

知識を仕組みに移す作業は地味に見えますが、ここを飛ばして移行だけを急ぐと、新しい仕組みの上でまた同じことが起きます。担当者が変わった瞬間に、手順の理由が分からなくなるという事態です。

知識を言葉にする作業は、担当者本人にとっても意味があります。自分が積み重ねてきた経験のどこが効いているのかを、あらためて言葉にする機会になるからです。

知識の置き場所を変える作業は、依頼主だけでは進めにくい場面もあります。では、この仕組み全体を最終的に見ていくのは誰なのでしょうか。

7. 評価の軸と、決める人の不在

優先事項を握る、利用する側の企業

決めごとを一つずつ握っても、最後に残る問いがあります。評価する軸を握っているのは誰か、という点です。

利用する側の企業は、システムの品質を最も優先する事項として捉えています¹。速さや目新しさよりも、まず崩れないことが評価の軸になっているということです。

この軸を先に知っておくと、提案の組み立て方も変わります。目新しい技術を並べる説明よりも、崩れずに続けられる理由を丁寧に示す説明のほうが、評価の軸に合っています。

早く動くことよりも、崩れずに続くことのほうが、評価の軸として重く見られています。移す先を選ぶときも、この軸に沿って考える必要があります。

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

決める人を置く順番

一方で、意思決定を担う責任者を設置していない企業は約半数に上ります¹。評価の軸は握っていても、その軸に沿って決める役割を持つ人が、社内に定まっていないということです。

ここに、依頼を受ける側が果たせる役割があります。決める人を待つのではなく、決めるための材料を先に並べて、依頼主と一緒に順番を追っていく進め方です。

この記事で見てきた選び方や決めごとは、どれも実装に入る前の相談で扱う内容です。

移す先を決める仕事は、実装よりも先に、対話の質で決まります。決めた道を実際に手を動かして進める役割は、社内だけで抱える必要はありません。まずは登録して、こうした移行の相談に関わる案件がどれくらいあるか、自分の目で確かめてみませんか。

8. よくある質問

新しい仕組みに移したあとの開発の進め方は、今と同じですか

開発手法は、依然としてウォーターフォール型が主流です¹。要件定義と設計も、ドキュメントを中心に行われています¹。

設計の作り込みに取り組む企業の状況はどうですか

モジュール性やデータモデルを意識した設計に取り組んでいる企業は、特にユーザー企業を中心に依然として少ない状況です¹。

技術情報の収集は、個人任せの状態ですか

体系的な仕組みを持たず、個人に任されている企業が数多くあります¹。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」書かない選択（2025年4月・2026年10月確認）