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

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月）をもとに作成

決める人を置く順番

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

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

この記事で見てきた選び方や決めごとは、実際の相談ではよくある疑問という形でも返ってきます。ここからは、その代表的な問いに答えていきます。

移す先を1つに絞らないといけませんか

絞る必要はありません。表計算ソフト上の仕組みの一部だけをノーコードやローコードの仕組みに移し、残りは内製での開発に回すというように、部分ごとに使い分ける進め方も珍しくありません。決めるべきなのは技術の種類よりも、それぞれの部分を誰が続けて見ていくかという点です。

依頼主が決める人を用意できない場合はどうしますか

決める人がすぐに用意できない場合は、まず評価の軸を言葉にして共有することから始めます。前の章で触れた、品質を最優先事項とする考え方を軸に置けば、決める人が後から加わっても判断がぶれにくくなります。

知識が担当者に付いている状態は、移行のどの段階で解消しますか

移す前の整理の段階で着手するのが最も効果的です。移してから知識を移そうとすると、担当者の手が実装に取られてしまい、結局は仕組みではなく人に知識が残ったまま先に進んでしまいます。技術情報の収集が体系立っていない状態を変える機会は、移行の前にしかありません。相談の早い段階で、この整理にどれだけ時間を割けるかを、依頼主と一緒に確かめておくと、後の工程がぶれにくくなります。

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

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」書かない選択（2025年4月）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」内製化の広がり（2025年4月）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」入る余地（2025年4月）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」知識の持ち方（2025年4月）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」方針の遅れ（2025年4月）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人（2025年4月）