業務システム開発のもう一度頼まれる人｜次に繋がる終わり方

2026年7月10日

朝比奈蒼

この記事のポイント

✓業務システム開発でリピートされる人は何が違うのか
✓次の提案を出すタイミングまで
✓次に繋がる終わり方の手順を工程順に整理します

業務システム開発でリピートされるかどうかは、納品した後の営業活動ではなく、プロジェクトの終わり方で決まります。結論から言うと、次も頼まれる人は、開発の最終盤に「次に何が必要になるか」を発注者と一緒に言語化しています。逆に、納品して請求書を送って終わりにする進め方では、たとえ品質に問題がなくても関係はそこで止まります。

業務システムは一度作って終わるものではありません。組織が変われば権限が変わり、制度が変われば帳票が変わり、事業が伸びれば処理量が変わります。つまり、追加の仕事は必ず発生します。問題は、その仕事が自分に来るかどうかです。この記事では、業務システム開発でもう一度頼まれる人がプロジェクトの終盤に何をしているのかを、工程順に整理します。

リピートが起きる構造を理解する

発注者が同じ相手に続けて頼むのは、義理でも好意でもありません。乗り換えるコストが高いからです。この構造を理解しておくと、何をすればリピートにつながるのかが明確になります。

発注者にとっての切り替えコスト

業務システムを別の開発者に引き継ぐとき、発注者は次の負担を負います。業務内容の説明をゼロからやり直すこと、既存のコードとデータ構造を理解してもらう時間を待つこと、その理解が不十分なまま改修されるリスクを取ること、そして品質が読めない相手に発注する不安です。

この負担が大きいほど、現在の開発者に頼み続けるほうが合理的になります。つまり、業務を深く理解している状態そのものが、リピートの源泉です。技術力で差をつけるのは難しくても、その会社の業務を理解している度合いでは、後から来た人に簡単には追いつかれません。

ただし、この優位は放っておくと失われます。担当者が異動すれば、あなたを知る人が社内からいなくなります。業務理解を資産として残すには、それを文書と関係の両方で残す必要があります。

受注した時点がゴールではない

開発会社の営業現場でも、同じ考え方が共有されています。

前回までは成約率を高めるためのTipsを紹介した。見事、受注に至ったら次は何を考えるか。システム開発では『受注=ゴール』ではない。受注して実際に開発プロジェクトが動き出し、システム開発に取り掛かっている間にも、「継続的に成約率を高めていくには、開発が終わった後を見越して、次の受注に向けての準備を進めておくことが大切です」と伊藤氏は言う。具体的には、後続の開発案件への提案だ。出典: hnavi.co.jp

重要なのは、次の提案の準備を開発期間中に始めるという点です。納品してから「次は何かありませんか」と聞くのでは遅く、その時点では発注者の関心はすでに次の期の別の課題に移っています。

業務システムは運用が本体である

業務システムは、作った時間より使われる時間のほうが圧倒的に長いという特徴があります。開発が数か月でも、稼働は数年に及びます。この非対称性が、継続的な仕事を生みます。

また、業務システム開発には、ユーザー視点を重視したUI/UX設計や、運用後の保守・サポートまでを含みます。これにより、システムが実際の業務に役立つものとなり、企業にとって価値ある投資となるのです。出典: m-gild.com

保守とサポートまでを含めて設計するという考え方は、受注する側にとっては、収益の構造をどう作るかという話でもあります。開発だけを単発で請けるのか、運用まで含めて関わるのかで、年間の収入の安定度がまったく変わります。

次の仕事が生まれる場所

業務システム開発でリピートが発生する領域は、おおむね決まっています。どこに次の仕事があるかを知っていれば、終盤の会話の焦点を合わせられます。

追加開発と第二期

初回の開発では、予算と期間の制約から機能を絞ります。絞った機能は消えたわけではなく、保留されているだけです。稼働後、業務が回り始めると、保留した機能への要望が現実味を帯びてきます。

このとき、初回のプロジェクトで「今回は第一期として、この範囲を作ります」と定義していたかどうかで展開が変わります。第一期と呼んでいれば、第二期の話は自然に始まります。単に「今回の開発」としか呼んでいなければ、次があるという前提が共有されません。呼び方ひとつの違いですが、効果は小さくありません。

制度と組織の変化への対応

業務システムは、外部の変化に追随する必要があります。消費税率や電子帳簿保存の要件、社会保険の手続き、労務管理の基準といった制度は変わります。制度変更の情報は各省庁が公開しており、e-Govなどで確認できます。

組織の変化も同様です。部署の統廃合、拠点の追加、承認ルートの変更は、権限管理やマスタの構成に直接影響します。こうした変化は予測できるものと、突然来るものがあります。予測できる変化については、稼働時に「この時期にこの対応が必要になります」と伝えておくと、その時期に相談が来ます。

保守と問い合わせ対応

稼働後の問い合わせ対応は、地味ですが関係を維持する最も確実な接点です。操作方法の質問、想定外のデータによるエラー、月次処理でのつまずきといった連絡が入ります。この対応を有償の保守契約として設計しておくと、定期的な収入になると同時に、システムの使われ方の情報が入ってきます。

問い合わせの内容は、次の改善提案の材料そのものです。同じ質問が繰り返されているなら、画面の作りに問題があります。特定の処理でエラーが多いなら、入力チェックが足りません。これらは発注者から要望として出てくることはありませんが、提案すれば通ります。

別部署への横展開

ひとつの部署で使われ始めたシステムは、隣の部署から見えます。同じような課題を抱えた部署が社内にあれば、横展開の話が出ます。これは新規開発と同じ規模の仕事になることもあり、リピートの中では最も大きい部類です。

横展開が起きるかどうかは、最初のシステムが社内でどう評価されているかにかかっています。使われていないシステムは横展開されません。定着支援に力を入れる理由のひとつがここにあります。

次に繋がる終わり方の手順

ここからは、プロジェクトの終盤に具体的に何をするかを順に見ていきます。

検収の前に認識を合わせる

検収でもめる案件は、その時点でリピートの可能性が大きく下がります。検収は、双方が納得して終わる工程にしておく必要があります。

そのために、検収の2週間ほど前に、検収の観点をすり合わせる場を設けます。何をもって完成とするのか、どのテストを誰が実施するのか、指摘があった場合の修正期間はどれくらいかを確認します。この場を持たないまま検収に入ると、発注者は思いつくままにテストし、仕様外の要望が不具合として上がってきます。

指摘が上がったときの分類も、あらかじめ決めておきます。仕様書との不一致は無償修正、仕様書に書かれていない新規要望は別途見積もり、という区分です。この区分を検収前に合意しておけば、指摘への回答が交渉ではなく事務処理になります。

引き渡し資料を実用的に作る

引き渡し資料は、あればよいというものではありません。実際に使われる資料を作った人は、その後も相談される傾向があります。使われない資料しか残さない人は、次に別の人が触ることになります。

実用的な資料とは、次の4種類です。ひとつ目は操作マニュアルで、画面ごとではなく業務の流れに沿って書きます。ふたつ目は運用手順書で、月次処理や年度切り替えのように定期的に発生する作業の手順です。3つ目は障害対応手順で、よくあるエラーとその対処を並べます。4つ目は設計資料で、データ構造と処理の考え方を残します。

このうち発注者が最も価値を感じるのは運用手順書です。担当者が交代したときに、これがあるかないかで業務が止まるかどうかが決まります。設計資料は技術者向けですが、これを残しておくと、あなた自身が半年後に改修するときに助かります。

資料を作る際、文書としての体裁も見られています。用語の統一、章立ての一貫性、図表の番号付けといった基本は、ビジネス文書検定で扱われる形式がそのまま基準になります。技術的に正しくても読みにくい資料は、結局使われません。

稼働直後に張り付く

システムが稼働した最初の1か月は、その後の評価が決まる期間です。この時期に対応が遅いと、システムそのものが使いにくいという評価になります。逆に、この時期に丁寧に対応すると、多少の不便は許容されます。

稼働直後にやることは、待つのではなく聞きに行くことです。実際に操作している人に、困っていることがないかを直接尋ねます。問い合わせとして上がってこない不満が必ずあります。「入力する順番が業務と逆で使いにくい」「よく使う項目が下のほうにあって面倒」といった声は、聞きに行かないと出てきません。

聞き取った内容は、すぐ直せるものと、改修が必要なものに分けます。すぐ直せるものは直します。改修が必要なものはリストにして残します。このリストが、次の提案の骨格になります。

振り返りの場を作る

プロジェクトが終わったら、発注者と一緒に振り返る場を持ちます。うまくいった点と、次はこうしたい点を出し合います。この場は、単なる反省会ではなく、次の話を始めるための場でもあります。

振り返りで発注者から出る「次はこうしたい」は、そのまま次の案件の種です。「今回は現場の意見を聞く時間が足りなかった」という反省が出れば、次は要件定義を厚めに取る提案ができます。「帳票の調整に時間がかかった」という話が出れば、帳票を切り出した契約の提案ができます。

振り返りの場を持つ開発者は多くありません。だからこそ、やっている人は記憶に残ります。

開発期間中から次の準備をする

終盤にまとめてやろうとすると間に合いません。次の提案の材料は、開発期間中に集めます。

中長期の課題を聞いておく

見積もりや要件定義の段階で、目の前のシステムだけでなく、その会社が中長期で何をしたいのかを聞いておきます。ここで得た情報が、次の提案の土台になります。

第2回で触れたとおり、同社では見積書の作成プロセスの間に、発注者にビジネス上の中・長期的な方向性や課題感を聞き、システムの将来像や理想形を共有しておくようにしている。「例えば、システムの開発期間が3カ月であるなら、2カ月で開発して、ラストの1カ月は次の提案に向けた準備にあてるのが理想的です」（伊藤氏）。実際、同社では、ラストの1カ月で翌期の提案に向けたディスカッションをすることが多いという。出典: hnavi.co.jp

期間の最後の1か月を次の提案の準備にあてるという配分は、個人で受ける場合にもそのまま適用できます。実装を前倒しで終わらせ、余った期間を関係づくりに使うという設計です。

保留した要望を記録する

開発中には、予算や期間の都合で保留した要望が必ず出ます。これを口頭で「今回は難しいですね」と流さず、リストとして記録します。記録するのは、要望の内容、保留した理由、実装するとしたらどの程度の規模か、の3項目です。

このリストを、納品時に「次に検討できる項目」として渡します。発注者にとっては、次の予算を取るときの根拠資料になります。受注者にとっては、次の案件の提案書の下書きになります。

発注者の予算サイクルを把握する

企業には予算の期があります。次の期の予算を組む時期に提案を出さなければ、その期の仕事にはなりません。この時期を聞いておくのは、営業として当然の準備です。

予算編成の2か月前を目安に、次の提案を持っていきます。このタイミングで概算の金額と効果を示せれば、担当者は予算に組み込めます。稼働が始まってから思いつきで提案しても、予算がないという理由で流れます。

リピートされない人の共通点

逆のパターンも整理しておきます。技術的には問題がないのに、次が来ない人には共通の傾向があります。

ひとつは、連絡が遅いことです。返信に数日かかる相手には、急ぎの相談は来ません。急ぎの相談が来ないということは、追加の仕事の入り口がひとつ閉じているということです。返信そのものは短くてかまわず、受け取ったことと、いつまでに回答するかを伝えるだけで印象は変わります。

ふたつ目は、指摘への反応が防御的なことです。不具合を指摘されたときに、まず言い訳から入る人がいます。仕様通りだと主張することが正しい場面もありますが、伝え方の順序を間違えると、話しにくい相手だと認識されます。事実の確認、原因、対処、その後の再発防止という順で伝えるほうが、結果的に立場も守れます。

3つ目は、業務に興味を示さないことです。言われた仕様を実装するだけで、なぜその業務がそうなっているのかを聞かない人には、相談が来ません。業務の背景を聞く人には「こういうこともできますか」という質問が来ます。この質問こそが次の仕事です。

4つ目は、納品後に連絡が途絶えることです。保守契約がない場合でも、稼働から数か月後に一度連絡を入れる程度のことはできます。この一通があるかどうかで、次に何か起きたときに思い出される確率が変わります。

5つ目は、できないことを言わないことです。技術的に無理な要望や、期間内に収まらない依頼に対して、曖昧な返事をしてしまう人がいます。その場は穏やかに済みますが、後で守れないと信用を失います。できない理由と、代わりにできることをセットで示せば、断っても関係は壊れません。むしろ、線を引ける相手だと認識されます。

6つ目は、成果を言語化しないことです。作ったシステムによって何がどう変わったのかを、発注者側が把握していないことがあります。処理にかかっていた時間が短くなった、転記の作業がなくなった、月末の残業が減ったといった変化は、現場では実感されていても、予算を承認する立場の人には届いていません。稼働から数か月後に、変化を数字で整理して共有すると、次の予算が通りやすくなります。これは発注者の稟議を助ける行為であり、結果として自分の仕事にも返ってきます。

業務理解を資産として残す

リピートの源泉が業務理解であるなら、その理解を失わないための仕組みが必要です。頭の中にしかない理解は、時間が経てば薄れ、担当者が変われば無効になります。

業務用語集を作る

その会社だけで通じる言葉は必ずあります。同じ「案件」という言葉が営業部と経理部で別の意味だったり、「締め」が月末を指したり請求書の発行日を指したりします。開発中に気づいたこうしたずれを、用語集として記録します。

用語集は、次の改修のときに自分を助けます。半年ぶりに触るシステムで、テーブル名やカラム名の意味を思い出すのに時間がかかるのは、業務用語との対応が残っていないためです。用語集があれば、この時間がほぼゼロになります。

用語集は発注者にも渡します。新しく入った社員の教育に使われることがあり、その場合は社内でこの資料の作り手として名前が残ります。地味ですが、担当者が変わったときに思い出される仕掛けとして機能します。

業務フローの図を残す

システムの画面遷移図ではなく、業務そのものの流れを図にします。誰が、どのタイミングで、何を判断し、次の誰に渡すのかという流れです。システムはこの流れの一部を担っているに過ぎません。

この図があると、追加要望が出たときに影響範囲を素早く判断できます。「この画面に項目を追加したい」という要望が、実は前工程の入力ルールの変更を必要とする、といった関係が見えるためです。判断の速さは、そのまま信頼につながります。

決定の経緯を記録する

なぜその仕様にしたのかという経緯は、記録しないと消えます。1年後に「なぜここは自動化していないのか」と問われたとき、当時の判断理由を答えられるかどうかで、対応の質が変わります。

記録は詳細である必要はなく、決定事項と、その理由、決めた人、日付の4点で足ります。打ち合わせの議事録に、この形式の欄をひとつ設けておくだけで蓄積されていきます。

担当者が交代したときにどうするか

発注者側の担当者が異動や退職で変わることは避けられません。この瞬間が、リピートが途切れる最も多いタイミングです。新しい担当者にとって、あなたは前任者が連れてきた外部の人でしかありません。

対策は、担当者が変わる前から複数の人と接点を持っておくことです。窓口の担当者だけでなく、実際に操作している現場の人、システムの費用を承認する上位者、情報システム部門の担当者といった複数の関係を作っておきます。ひとつの関係が切れても、他の関係が残ります。

新しい担当者が来たら、早い段階で引き継ぎの場を作ります。システムの概要、これまでの経緯、現在の運用状況、保留している課題を説明します。この場を持てば、新しい担当者にとってあなたは「システムのことを一番知っている人」になります。この場がないと、新任者は自分の知っている業者に相談し始めます。

引き継ぎの場では、資料を渡すだけでなく、口頭で背景を伝えることが重要です。文書だけを渡されても、新任者はそれを読む時間を取れません。1時間の説明があるかどうかで、その後の相談の来やすさが変わります。

保守と継続の契約をどう設計するか

継続的な関係を作るには、契約の形も設計する必要があります。都度の依頼を待つ形では、収入が読めません。

保守契約の形はいくつかあります。月額の定額で一定時間の対応を含める形、対応した時間分を都度請求する形、年間の一定回数まで対応する形です。個人で受ける場合は、月額定額に上限時間を設ける形が扱いやすくなります。上限を超えた分は追加請求とすることで、際限のない対応を防げます。

保守契約に含める範囲は明示します。障害対応、操作の問い合わせ、軽微な設定変更までを含め、機能追加は別途とするのが一般的な線引きです。この線引きが曖昧だと、保守の名目で機能追加を求められます。

契約の話を切り出すタイミングは、稼働の直前が適しています。稼働後は目の前の対応に追われ、契約の話をする余裕がありません。稼働前に「稼働後の体制をどうするか」として持ちかけると、発注者にとっても必要な話として受け止められます。

稼働後の接点を定期の予定にする

稼働してしばらく経つと、連絡は自然に途絶えます。不具合が出なければ相談する理由がないためです。この静かな期間に何もしないでいると、次に相談が必要になったとき、発注者は改めて相手を探すところから始めます。接点は、思い出したときに作るのではなく、予定として先に置いておきます。

点検の連絡を工程に入れる

稼働から1か月、3か月、半年の3つの時点で、状況を確認する連絡を入れる形にします。内容は難しいものでなくてかまいません。処理の件数が想定の範囲に収まっているか、月次や年度の切り替えで止まった処理がないか、使われていない画面がないか。この3点を聞くだけで、改善の材料が出てきます。

この連絡は、保守契約がある場合は契約の中の作業として位置づけます。契約がない場合でも、稼働時に「この時期に一度状況を確認させてください」と伝えておけば、その時点で連絡する理由が生まれます。理由のある連絡は営業に見えません。

使われ方の数字を見に行く

聞き取りだけでは、実際に何が起きているかは分かりません。処理の件数、エラーの発生した件数、ほとんど使われていない機能。これらはシステムの中に記録が残っています。稼働の設計段階で、こうした記録を後から取り出せる形にしておくと、点検のたびに事実で会話できます。

数字が出せると、提案の説得力が変わります。特定の画面でエラーが繰り返し起きているという事実は、入力の作りを直す根拠になります。ほとんど使われていない機能があるという事実は、次の開発で作るべきものを絞る根拠になります。要望として上がってこない改善は、この形でしか見つかりません。

制度と環境の予定を先に伝える

制度の改正や、使っているソフトの提供終了の時期は、あらかじめ分かるものがあります。データベースや実行環境の対応期限、帳票の様式の変更時期といった予定は、把握できた時点で発注者に伝えます。伝える相手は担当者だけでなく、予算を承認する立場の人にも届く形にします。

期限の情報は、発注者にとって予算を確保する根拠になります。期限が近づいてから伝えると、緊急の対応になり、双方に無理が生じます。早く伝えるほど、落ち着いた工程で受けられます。

連絡の文面を短く保つ

定期の連絡は、長い文章にすると読まれません。件名で用件が分かるようにし、本文は確認したい項目を並べるだけにします。返信の負担が小さいほど返事が来ます。返事が来ない場合も、送った記録が残っていれば、次の相談のときに経緯を辿れます。

返信をもらったら、その内容を課題の一覧に足していきます。一覧は自分の手元だけで持つのではなく、発注者にも共有できる形にしておきます。共有された一覧は、次の予算を組むときにそのまま検討の材料として使われます。手元にしかない一覧は、提案の場を作らないと相手の目に触れません。

業界の構造と、続けやすい取引の形

フリーランスと在宅の仕事の市場を20年見てきた立場から言えば、長く続いている人は、単発の作業を数多くこなす方向ではなく、少数の相手に深く入る方向を選んでいます。技術の幅を広げることより、その会社の業務を誰よりも知っている状態を作るほうが、結果として仕事が途切れません。新しい相手を探す時間がそのまま減るためです。

もうひとつ、運営者として見てきた限りでは、継続する取引は金額の話が少ない傾向があります。毎回の交渉が発生する関係は、どこかで疲れて途切れます。逆に、仲介の手数料が乗らない直接の取引では、発注者は同じ予算でより多くを依頼でき、受注者は同じ作業でより厚い手取りを得られます。手数料0%の意味は金額の大小ではなく、双方が納得したまま長く続けられるという点にあります。額面ではなく手取りで考えると、継続の価値がはっきりします。

業務システム開発という職種が、他の在宅の仕事と比べてどういう位置にあるのかを把握しておくことも役に立ちます。仕事の内容と求められる範囲はWeb・業務システム開発のお仕事にまとめられており、自分が受けている案件がどの領域に当たるのかを確認できます。関連領域として、AIの組み込みやセキュリティ要件の強い案件はAI・マーケティング・セキュリティのお仕事で扱われており、既存顧客への次の提案を考えるときの選択肢になります。

自分の立ち位置を数字で確認したい場合は、ソフトウェア作成者の年収・単価相場に職種ごとの統計がまとまっています。継続案件を増やす判断と、単価を上げる判断のどちらを優先するかを決める材料になります。インフラや通信の構成まで含めて提案する案件では、CCNA（シスコ技術者認定）の範囲にある知識が、保守の提案の幅を広げます。

長く現場で経験を積んだ人が独立して受託を始める場合は、継続の設計が特に重要になります。定年後のフリーランス独立｜退職金を活かした起業プランと注意点には、事業として組み立てる際に押さえておく点が整理されています。