業務システム開発は完全在宅で進むのか、現地でのヒアリングが残る工程を見る

2026年4月24日

朝比奈蒼

この記事のポイント

✓業務システム開発は完全在宅で成立するのか
✓要件定義から保守までを工程ごとに分解し
✓現地でのヒアリングが残る場面とオンラインに置き換えられる場面の境界を整理します

結論から書きます。業務システム開発は、完全在宅で「ほぼ」進みます。ただし、その「ほぼ」の中に、現地に行かないと精度が出ない工程が確実に残っています。そして厄介なことに、その工程はプロジェクトの序盤と終盤という、最も失敗が高くつくタイミングに集中しています。

「業務システム開発完全在宅」で検索する人の多くは、求人票やスカウトメールで「フルリモート可」という文字を見たあとに、少し疑っている状態です。実装だけなら家でできるのは分かる。でも、業務の流れを聞き出す仕事や、現場の紙の帳票を見る仕事まで在宅で片付くのか。その疑いは、正直なところ正しい直感です。

この記事では、業務システム開発の工程を要件定義から保守運用まで分解して、どこが完全在宅で成立し、どこに現地が残るのかを一つずつ見ていきます。そのうえで、現地訪問を減らすために発注側と何を握っておくべきか、副業やフリーランスとして在宅前提の案件を選ぶときに何を確認すべきかまで整理します。

「完全在宅」という言葉は、求人ごとに指している範囲が違う

まず前提を揃えます。求人サイトや案件情報に並ぶ「完全在宅」「フルリモート」という表記は、統一された定義を持っていません。同じ言葉が、まったく違う働き方を指していることが日常的に起きています。

たとえば在宅ワーク系の求人には、こういう書かれ方をしているものがあります。

仕事内容完全在宅勤務になりますので、自由にお仕事する時間を決めて進められる！美容品、化粧品、コスメ、サプリメント、日用品などの商品情報を専用システムに登録するだけのお仕事になります。【お仕事の流れ】 (1)専用システムに商品情報 (メーカー名・商品名・製品コード・発売日・商品紹介) (2)商品画像アップロード (3)商品登録完了！マニュアル完備なので、自分のペースでモクモクとお仕事できます！出典: jp.stanby.com

この種の求人における「完全在宅」は、作業が完全に定型化されていて、判断の余地がなく、成果物の受け渡しがオンラインで完結する状態を指しています。作業手順書が先にあり、そこから逸脱しない限り誰とも相談しなくてよい。だから在宅で成立します。

業務システム開発の「完全在宅」は、ここと同じ意味ではありません。開発の本体は「まだ言語化されていない業務のルール」を、依頼側から引き出して構造に落とす作業です。定型化されていないどころか、定型化することそのものが仕事の中身になっています。この違いを踏まえずに「フルリモートだから在宅で完結するはず」と思って入ると、契約後に現地訪問の話が出てきて揉めます。

在宅可否を分けているのは技術ではなく、情報の置き場所

在宅でできるかどうかは、開発の難易度では決まりません。決めているのは、必要な情報がどこに置かれているかです。

情報がドキュメントやデータベースの中にあるなら、在宅で取り出せます。画面キャプチャ、既存システムのER図、CSVで吐き出した実データ、業務マニュアル。これらは全部オンラインで渡せます。

一方、情報が人の頭の中や、机の上の紙、あるいは工場や店舗の物理的な動線の中にあるなら、在宅では取り出しにくくなります。「この帳票、実は3種類あって、拠点ごとに使い分けてるんですよ」という話は、担当者の机を見ないと出てこないことがあります。ヒアリングの席では誰も言い出さないのに、現地で作業を眺めていると10分で分かる。この非対称性が、業務システム開発から現地訪問が消えない理由です。

契約形態によっても「在宅可」の重さが変わる

派遣や準委任で客先のシステム部門に入るタイプは、セキュリティ要件が厳しいぶん在宅の壁が高くなります。反対に、請負で成果物ベースの契約を結び、開発環境を自分側に持てるタイプは、在宅で完結しやすくなります。求人票の「フルリモート可」を見たら、契約形態と開発環境の所在をセットで確認したほうが確実です。

市場は在宅前提に寄っている。ただし業務システムには固有の事情がある

在宅の求人市場そのものは、ここ数年で明確に厚くなりました。エンジニア向けの求人サイトでは、勤務地の条件に「フルリモート」を入れた検索が定着していますし、リモート比率を前面に出す企業も増えています。副業やフリーランス向けの案件紹介サービスでも、リモート可の案件が主流になりました。

在宅系の求人では、勤務時間の柔軟さを訴求する書き方も一般的です。

勤務時間シフト制 ●週2～5日 ●1日3～6時間勤務 ●9時～21時の間であればOK ※在宅でのお仕事になりますので、勤務時間は自由に決めていただいて構いません。出典: jp.stanby.com

ただ、この「時間は自由」がそのまま業務システム開発に当てはまるかというと、そこは分けて考える必要があります。開発の在宅は「場所の自由」であって、「時間の自由」とは別物だからです。発注側の業務時間中に仕様確認の連絡が飛んでくる以上、完全な非同期にはなりません。この点は、場所の自由だけを見て応募すると後で効いてきます。

単価と年収の相場をどう読むか

業務システム開発の報酬は、担当する工程の幅で大きく変わります。詳細設計以降だけを受けるのか、要件定義から入るのかで、同じ「システム開発」でも単価の桁が変わってきます。そして在宅可否も、この工程の幅と連動します。上流ほど現地が残り、下流ほど在宅で完結します。つまり「完全在宅にこだわるほど、単価の上限が下がりやすい」という構造があります。

相場の水準そのものは、職種ごとの統計を見て把握しておくのが早いです。ソフトウェア作成者の年収・単価相場では、開発職の報酬レンジを職種別に整理しています。副業として受けるのか、本業を在宅に切り替えるのか、あるいは転職して社内SEを目指すのかで、狙うべきレンジは変わります。文章を書く仕事と兼務している人であれば、著述家，記者，編集者の年収・単価相場も併せて見ておくと、時間あたりの収益性を比較しやすくなります。

正直なところ、在宅案件の単価を語るときに「在宅だから安い」と一括りにするのは雑だと思っています。安くなるのは在宅だからではなく、在宅で切り出せる範囲が下流に寄りやすいからです。上流を在宅でこなせる人は、在宅のまま単価を維持しています。

転職市場では「完全在宅の業務システム開発」は狭き門になりやすい

正社員として完全在宅の業務システム開発職を探すと、選択肢は思ったより絞られます。社内SEは自社の現場に近いことが価値なので出社が残りやすく、受託開発は客先の要求に左右されます。結果として、完全在宅を最優先にすると、自社サービス開発か、リモート前提で組織を作っている受託会社に候補が寄ります。副業やフリーランスのほうが、在宅前提の案件は見つけやすいというのが実感に近い状況です。

工程別に見る、在宅で完結する作業と現地が残る作業

ここからが本題です。業務システム開発の工程を分解して、在宅適性を一つずつ判定していきます。

要件定義とヒアリング：現地が最も残る工程

最も現地が残るのがここです。理由は3つあります。

1つ目は、業務が言語化されていないこと。依頼側の担当者は自分の仕事を毎日やっているので、手順が体に入りきっていて説明が飛びます。「そこで承認をもらって」と言われても、承認が口頭なのか印鑑なのかシステム上のボタンなのかは、聞き手が意識して掘らないと出てきません。オンライン会議でも掘れますが、画面越しだと相手の手元が見えないぶん、掘る手がかりが減ります。

2つ目は、例外処理が現場にしかないこと。業務システムの工数を膨らませる犯人は、だいたい例外処理です。「基本はこの流れですが、○○の場合だけ別で処理しています」という別ルートが、拠点ごと、担当者ごとに存在していることがあります。会議室に集まる人は代表者なので、代表的なフローしか語りません。

3つ目は、紙とExcelの現物確認。既存の帳票やExcelファイルは、電子データで送ってもらえば見られます。ただ、それが実際にどう回覧され、どこに書き込まれ、どこに積まれているかは、現物を見ないと分かりません。「このExcel、実は3人が別々のコピーを持っていて、月末に手で突き合わせています」というような話が出てくるのは、たいてい現地です。

とはいえ、全回を現地にする必要はありません。初回のキックオフと業務観察だけを現地にして、以降の詳細詰めをオンラインに寄せる進め方が、現実的な落としどころになります。

基本設計・詳細設計：在宅で回るが、合意形成に工夫が要る

設計は在宅で成立します。画面設計、データ設計、機能の一覧化。これらは資料を作って共有すれば、オンラインでレビューできます。

ただし、合意形成の質が落ちやすい点には注意が必要です。対面のレビューでは、相手が資料のどこで止まったか、どこで眉をひそめたかが見えます。オンラインだと、その微細な反応が拾えません。「特にありません」で終わった設計レビューが、実装後に「思っていたのと違う」に化けるのは、この情報落ちが原因です。

対策は、抽象度を落とすことに尽きます。仕様書の文章でレビューするのではなく、動く画面か、それに近いモックを見せる。文字で「一覧画面に検索条件を配置する」と書くより、実際の画面イメージを出したほうが、相手は具体的な指摘を返せます。在宅で設計を進めるなら、モックを作る手間は削らないほうが結果的に早く終わります。

実装：ほぼ完全在宅で成立する

実装は在宅適性が最も高い工程です。ソースコードはバージョン管理システムの上にあり、レビューはプルリクエストで回り、進捗はチケットで見えます。ここを現地でやる必然性は、セキュリティ要件を除けばほぼありません。

実際、リモート前提の開発案件が増えたのは、この工程の切り出しやすさが大きいと考えられます。仕様が固まってさえいれば、開発者がどこにいるかは成果物の品質に影響しません。副業として業務システム開発に関わる人の多くが、この工程から入るのも自然な流れです。仕事の内容をもう少し具体的に把握したい場合は、Web・業務システム開発のお仕事で、実際にどんな作業が発注されているのかを確認しておくと、自分が受けられる範囲を見積もりやすくなります。

テストと受入検査：現地が復活しやすい山

実装が終わると、現地が再び顔を出します。単体テストと結合テストは在宅で完結しますが、受入テストは依頼側の実務担当者が触る工程なので、事情が変わります。

依頼側の担当者は、テストの手順書を渡されても、その通りに操作してくれるとは限りません。普段の業務のつもりで触るので、想定外の順番でボタンを押します。それ自体は悪いことではなく、むしろ本番で起きることの先取りです。ただ、オンラインだと「今、何をしたらそうなったのか」の再現が難しくなります。画面共有をしてもらっても、手元のメモや紙の資料は映りません。

規模が小さい案件なら、テスト期間中に1日だけ現地に入って、担当者の隣で操作を見る。これだけで手戻りが目に見えて減ります。逆に言えば、ここを完全に在宅で押し切ろうとすると、テキストでの往復回数が増えて、結果的に工数が膨らむことがあります。

本番移行とデータ移行：立ち会いを求められることがある

既存システムからの移行がある案件では、移行当日の立ち会いを求められることがあります。技術的には遠隔で作業できても、依頼側の心理として「何かあったときに人がいてほしい」という要求が出ます。これは技術の問題ではなく信頼の問題なので、正論で押し返しても解決しません。

現実的には、移行リハーサルを事前にオンラインで複数回実施し、当日の手順書と切り戻し手順を文書で共有しておくことで、立ち会い要求が和らぐことがあります。それでも残るなら、移行日だけスポットで訪問する前提を見積もりに含めておくのが穏当です。

保守運用：在宅が最も定着しやすい

稼働後の保守は、在宅がいちばん定着します。問い合わせ対応、軽微な改修、障害の一次切り分け。いずれもリモートで完結しますし、依頼側も日常的に人が来ることを期待しません。

副業として長く続けるなら、開発を一度受けたあとに保守で関係を継続する形が、時間あたりの効率が良くなりやすい傾向があります。業務を理解している人が対応するので調査時間が短く済み、依頼側も引き継ぎコストを払わずに済むためです。

工程ごとの在宅適性を一覧で整理する

ここまでの内容を、判断しやすい形にまとめておきます。案件の話を受けたときに、自分がどの工程を担当するのかを当てはめると、在宅で成立するかどうかの見当がつきます。

工程	在宅適性	現地が残る理由	在宅で補う手段
要件定義・業務ヒアリング	低い	業務が言語化されておらず、例外処理が現場にある	初回のみ訪問し、現物写真とサンプルデータを事前に受領
基本設計・詳細設計	高い	対面レビューに比べ相手の反応が拾えない	モックや画面イメージでレビューし、抽象度を下げる
実装	非常に高い	セキュリティ要件がある場合のみ	匿名化データでの開発、支給端末とVPNでの接続
単体テスト・結合テスト	非常に高い	ほぼなし	テスト結果をチケットとログで共有
受入テスト	中程度	依頼側の担当者が想定外の操作をする	画面共有と録画、テスト期間中の短期訪問
本番移行・データ移行	中程度	当日の不安から立ち会いを求められる	リハーサルの反復と切り戻し手順の文書化
保守運用	非常に高い	ほぼなし	問い合わせ窓口とチケット運用の整備

この表で言いたいのは、在宅適性が低い工程は全体の中で見ればごく一部だということです。プロジェクト期間の大半を占める設計と実装と保守は、在宅で成立します。にもかかわらず「業務システム開発は在宅では無理」と語られがちなのは、序盤のヒアリングという最も印象に残る場面が現地だからです。全体の構成比で見れば、印象と実態にはずれがあります。

現地訪問を減らすために、発注側と先に握っておくこと

完全在宅を実現したいなら、契約前の交渉が勝負です。始まってから「在宅でお願いします」と言っても通りません。

現地を「初回だけ」に集約する提案をする

現地訪問をゼロにする交渉より、回数を限定する交渉のほうが通ります。「キックオフと業務観察で1日だけ伺い、以降はオンラインで進めます」という提案は、依頼側にとっても納得しやすい形です。移動時間と交通費が減るのは発注側の利益でもあるので、双方の合意が取りやすくなります。

打ち合わせの録画と議事録を、成果物として扱う

在宅で進めるプロジェクトが崩れる典型は、「言った言わない」です。オンライン会議は録画できるという利点があるので、これを使い切ります。録画を残し、議事録を24時間以内に共有し、認識の相違があればその場で修正してもらう。この運用を最初に合意しておくと、現地に行かない不安をかなり打ち消せます。

議事録の書き方そのものが評価に直結するのも、在宅案件の特徴です。文章で伝える力が、対面で補えないぶん重くなります。ビジネス文書の型を体系的に身につけたいなら、ビジネス文書検定のような資格の学習範囲が、そのまま実務の型として使えます。資格を取ること自体が目的でなくても、書式と敬語の基準を一度通しておくと、依頼側とのやり取りが安定します。

現物の写真とサンプルデータを先に出してもらう

現地に行かない代わりに、現地の情報を送ってもらいます。使っている帳票の写真、Excelファイルの実物、既存システムの画面キャプチャ、実データを匿名化したサンプル。これらを要件定義の前に集めておくと、オンラインのヒアリングでも掘る手がかりが手に入ります。

依頼側は「何を送ればいいか分からない」ことが多いので、こちらからリストを出すのが確実です。ここで手を抜くと、後工程で「聞いていない仕様」が湧いてきます。

オンラインのヒアリングを現地に近づける進め方

現地でしか取れないと言われる情報のうち、いくつかはやり方を変えれば在宅でも取れます。実務でよく効く方法を3つ挙げます。

1つ目は、業務の実演をしてもらうことです。「説明してください」ではなく、「いつも通りに作業してみてください。画面を共有しながらで構いません」と依頼します。説明を求めると相手は要約して話しますが、実演を求めると手順が省略されずに出てきます。省略されない手順の中に、仕様の種が埋まっています。

2つ目は、時系列で聞くことです。機能単位で聞くと業務の順序が抜け落ちます。「朝、出社してから最初にこのシステムで何をしますか」から始めて、1日、1週間、1か月、決算期という順に時間の粒度を広げていくと、月次処理や年次処理の存在に気づけます。この聞き方は現地でもオンラインでも使えますが、オンラインのほうが効果が大きくなります。相手の作業を目で見て補完できないぶん、質問の構造で埋める必要があるからです。

3つ目は、間違った理解をわざと投げることです。「つまり、承認は課長が一人でやっている、ということでよいですか」と、あえて断定して確認します。合っていれば肯定が返り、間違っていれば訂正が返ります。曖昧な質問より、訂正を引き出す質問のほうが情報量が多くなります。オンラインでは沈黙が続くと気まずくなりやすいので、この形式は相手にとっても答えやすいという副次的な効果があります。

完全在宅を阻む3つの壁と、その外し方

壁1：セキュリティ要件

最も硬い壁がこれです。個人情報や機密データを扱う業務システムでは、開発環境の持ち出しが禁止されていたり、客先が支給する端末からVPN経由でしか接続できなかったりします。金融、医療、公共系では特に厳しくなります。

外し方は2つあります。1つは、開発を本番データから切り離すこと。匿名化したテストデータで開発し、本番データに触れる作業だけを依頼側の担当者に任せる分担にすれば、在宅の余地が生まれます。もう1つは、ネットワーク要件を満たす環境を自分側に用意すること。固定IPからの接続を求められるケースもあるので、自宅の回線が要件を満たすかは事前に確認しておく必要があります。回線の選び方は在宅ワークに最適なネット回線｜光回線vsホームルーターの選び方で整理されています。VPNやネットワークの基礎を体系立てて押さえたいなら、CCNA（シスコ技術者認定）の学習範囲が実務と直結します。

壁2：属人的な業務知識

要件が担当者個人の頭にしかなく、その人が忙しくてオンライン会議の時間を取れない。この状況は在宅開発を止めます。相手の時間を確保できないなら、非同期で答えられる形に変換します。質問を選択式にして、テキストで返せる粒度まで砕く。「この処理はどうしますか」ではなく、「AとBのどちらですか。理由も一行で」まで落とすと、返信率が上がります。

壁3：対面を前提とする文化

決裁者が対面を好む組織では、技術的な必然性がなくても訪問を求められます。ここは真正面から否定せず、オンラインでの接触頻度を上げて代替するのが現実的です。週次の定例を短く高頻度にし、進捗を可視化する。会わない不安の正体は情報の欠如なので、情報量で埋めます。

在宅で業務システム開発を続けるための環境とスキル

環境面で先に整えるもの

回線の安定性は最優先です。オンライン会議中に音声が途切れる状態では、要件定義を在宅で進めるのは無理があります。次に、作業机とモニタ。設計とコードを同時に見る作業が多いので、画面の面積が生産性に直結します。

集中の維持も、在宅特有の課題です。設計や実装は連続した思考時間が要る作業なので、細切れの時間では進みません。時間の区切り方については在宅ワークの集中力アップ｜ポモドーロ以外に効く7つのテクニックに手法がまとまっています。

スキル面で在宅の可否を左右するもの

在宅で評価されるエンジニアの条件は、技術力そのものよりも「進捗が見えること」です。何をどこまでやったのか、次に何が必要なのかを、聞かれる前に出せるかどうか。この一点で、在宅の継続可否が決まっている場面をよく見かけます。

技術の幅を広げる方向では、業務システムの周辺にある領域を押さえると受けられる案件が増えます。データ分析や自動化、セキュリティ対応といった隣接領域は需要が伸びており、AI・マーケティング・セキュリティのお仕事では、その周辺でどんな仕事が発注されているかを確認できます。まったく別の軸として、音や映像の制作を在宅で扱う作曲・編曲・効果音・ジングルのお仕事のような分野もありますが、業務システムからの距離は遠いので、収入源の分散を考える段階で検討する話になります。

資格については、在宅案件の受注で直接効くケースと、そうでないケースがあります。実績が示せる人は資格の優先度が下がりますし、実績が薄い人には名刺代わりになります。在宅で働くこと自体と相性のよい資格の整理は在宅ワークに強い資格10選｜自宅で稼げるスキルを身につけるにまとまっています。

副業やフリーランスとして在宅案件を選ぶときの見極め方

副業で業務システム開発を受けるなら、案件の入り口で確認すべき項目は決まっています。

第一に、現地訪問の有無と回数。「基本リモート」と書かれていても、月に何回かの出社が前提になっていることがあります。契約前に文字で確認します。

第二に、依頼側の窓口が一人に決まっているか。窓口が複数いて意見が割れている案件は、在宅だと調整コストが跳ね上がります。

第三に、既存資料の有無。業務マニュアルや現行システムの資料が何もない状態で「完全在宅で」と言われたら、要件定義の難易度が上がることを見積もりに織り込む必要があります。

第四に、検収の基準。何をもって完了とするかが曖昧な案件は、在宅だと着地が見えにくくなります。

そして手数料の構造も、実は在宅で働くうえで見落とされがちな要素です。仲介手数料が報酬から差し引かれる仕組みでは、同じ作業量でも手取りが変わります。手数料0%で直接取引ができる形なら、依頼側は同じ予算でより多くを依頼でき、受け手の手取りは厚くなります。在宅で長く続けるなら、単価の交渉と同じくらい、この構造の違いが効いてきます。

独自データから見た、在宅の業務システム開発が続く条件

在宅ワークとフリーランスの市場を20年見てきた立場から言えば、完全在宅で業務システム開発を長く続けている人には、共通した特徴があります。それは技術のレベルではなく、「聞き方の設計」がうまいことです。

現地に行かない人ほど、質問の作り方が精密です。相手が考え込まないと答えられない質問を投げず、選択肢を用意して、判断だけを求める。逆に、在宅がうまくいかない人は、質問が抽象的で、返信が滞り、滞った結果として「やはり一度お会いしましょう」に着地します。在宅を続けられるかどうかは、この往復の設計で決まっている場面が多いというのが、運営者として見てきた限りの実感です。

もう一点。長く続く人は、単発の開発案件を積み上げるのではなく、「この人に任せると楽だ」という状態を作ることに時間を使っています。業務システムは一度作って終わりではなく、法改正や業務変更のたびに手を入れる必要が出てきます。そのときに真っ先に声がかかる位置にいる人は、在宅であることを不利にしていません。むしろ、移動時間がないぶん反応が速いという理由で選ばれています。

工程別に見れば、業務システム開発の8割方は在宅で完結します。残り2割の、現地でしか取れない情報をどう補うか。そこに手を打てているかどうかが、「完全在宅で受けられる人」と「結局出社することになる人」を分けています。案件を探す段階から、この2割をどう埋めるかまで含めて条件を確認しておくと、始まってからの齟齬が減ります。