システムの追加開発・二次開発の進め方｜作った会社に頼む？別会社に頼む？

「今のシステムにこの機能も足したい」「作ってもらった会社の追加見積りが高い気がする」——運用が始まると、必ず出てくるのが追加開発の悩みです。この記事では、既存システムの追加開発・二次開発を、作った会社に頼む場合と別会社に頼む場合の違い、引き継ぎの壁、費用の考え方まで、発注側の視点で整理します。

追加開発・二次開発とは

追加開発（二次開発）とは、すでに動いているシステムに、後から手を加えて機能を足したり作り替えたりすることです。ゼロから新しく作る新規開発と違い、いまある資産を土台にして育てていく進め方を指します。中身を分けると、大きく次の3つになります。

• 機能追加：新しい画面や項目、帳票、通知など、これまでなかった機能を足す
• 改修：既存の機能の動きを変える、使いにくい部分を直す、不具合を修正する
• 拡張：他システムとの連携、外部サービスとのデータのやり取り、処理速度やアクセス数への対応

「一度作れば終わり」というシステムはほとんどありません。業務は変わり、扱う件数は増え、法制度も動きます。だからこそ、多くのシステムは運用しながら少しずつ手を入れていくのが前提です。追加開発は例外的な作業ではなく、システムを使い続ける以上、必ず付き合っていく通常の工程だと考えておくと判断を誤りません。

なお、追加開発と似た言葉に「リプレース（作り替え）」があります。両者の違いは、既存の資産をそのまま活かすかどうかです。追加開発は今のシステムを土台に手を足すのに対し、リプレースは古くなった土台ごと新しく作り直します。まだ土台が使えるなら追加開発、土台自体が限界なら作り替え、というのが大まかな線引きです。判断に迷う場合はシステムのリプレースの兆候リストと照らし合わせると切り分けやすくなります。

作った会社に頼む vs 別の会社に頼む

追加開発の相談先は、大きく「最初に作った会社に頼む」か「別の会社に頼む」かの2択です。それぞれに向き不向きがあります。

相談先	メリット	デメリット
作った会社	中身を把握済みで調査が不要／スピードが速い／仕様の経緯を分かっている	比較対象がなく金額が高止まりしやすい／囲い込みが起きやすい
別の会社	相見積りで費用を比較できる／新しい視点で改善提案が得られる	現状調査に手間と費用がかかる／引き継ぎがうまくいかないリスク

基本の考え方はシンプルです。まず作った会社に見積りを取り、金額と対応に不満がなければそのまま頼むのが手堅い選択です。中身を分かっている会社は調査が不要なぶん速く、経緯も踏まえた対応ができます。「なぜこの処理はこうなっているのか」という背景まで把握しているため、既存機能を壊さずに足せる可能性も高くなります。追加開発の初回から別会社に切り替えるのは、費用や引き継ぎのリスクを考えると、必ずしも得策とは限りません。

一方で、追加見積りが毎回高い、対応が遅い、「うちでないと無理」という雰囲気を感じる——こうしたサインが出たら、別会社への切り替えを検討する場面です。ただし勢いで乗り換えるのではなく、後述する「引き継ぎに必要なもの」を手元に確保してから動くのが鉄則です。ここを飛ばすと、別会社に頼んでもうまくいかず、結局もとの会社に戻る、という遠回りになります。内製と外注の使い分けは内製と外注の比較も参考になります。

別の会社が引き継ぐときの注意点

別の会社に追加開発を頼む場合、最初の壁になるのが引き継ぎです。新しい会社は、まず「今どう作られているか」を把握するところから始めるため、その調査の重さが費用と期間を左右します。

• 現状調査が先に必要：いきなり機能追加には入れません。既存のソースコードやデータ構造を読み解き、影響範囲を確認する工程が入ります。
• ソースコードとドキュメントの有無が決定的：これらが揃っていれば調査は短く済みます。逆に、実物のコードが手元になかったり仕様書が残っていなかったりすると、動きから推測するしかなく、時間も費用も膨らみます。
• 見えないリスクが読みにくい：他社が作った中身には、表からは見えない依存関係や独自の作り込みが潜んでいます。一見小さな修正が、思わぬ箇所に波及することもあります。
• 費用が見積もりにくい：中身がブラックボックスなほど、着手前に正確な工数を出しにくくなります。「調査してみないと分からない」という状態は、発注側にとって金額の不確実性そのものです。

だからこそ、別会社に引き継ぐときは、まず現状調査だけを小さく切り出して依頼する進め方が安全です。いきなり大きな改修を丸ごと発注するのではなく、現状の棚卸しと概算見積りをワンステップ挟むことで、費用が読めない状態のまま突っ込むリスクを避けられます。調査の結果、「思ったよりきれいに作られていて安く引き継げる」と分かることもあれば、逆に「作り替えたほうが早い」と判断できることもあり、いずれにしても次の一手を決めやすくなります。

追加開発の費用の考え方

追加開発の費用は、足す機能の大きさと、既存システムの分かりやすさで決まります。あくまで目安ですが、規模別に整理すると次のようになります。

規模	内容の目安	費用の目安
小さな改修	項目追加・表示調整・軽微な修正	数万〜数十万円
機能追加	新しい画面・帳票・通知などの追加	数十万〜100万円前後
大きめの拡張	他システム連携・大幅な作り替え・性能改善	100万〜数百万円

費用を読みにくくする最大の要因は、既存システムの中身の分かりやすさです。ソースコードと仕様書が揃っていれば調査は最小限で済み、追加分の工数だけで見積もれます。逆にブラックボックス化していると、調査そのものに費用がかかり、金額の幅も大きくなります。追加開発の割高感は、機能そのものより「調べる手間」から生まれることが多いのです。

D-oneAppでは、標準的な業務システムの開発を一律100万円（スタンダード）／大規模なプロプランは一律200万円で承っています。追加開発でも考え方は同じで、次の点が発注側の安心につながります。

• 着手前に総額が確定する：追加費用なし。工数が読みにくい追加開発ほど、金額が固定されている安心感は大きくなります。
• 成果物（ソースコード）の権利をお渡しする：次の追加開発を別の会社に頼みたくなっても引き継げるため、囲い込みに逆戻りしません。
• 仕様書・データ構造を残す：これが次回以降の調査コストを下げ、二次開発を積み重ねるほど効いてきます。

一律料金で具体的に何ができるかは100万円でできることに、機能追加の見積りの見方は見積書の見方にまとめています。

費用を考えるうえでもう一つ押さえておきたいのが、**「小さく見える追加ほど割高になりやすい」**という感覚です。項目を1つ足すだけの作業でも、影響範囲の確認・動作テスト・既存機能への波及チェックが必要で、実際に手を動かす時間よりも周辺の確認に工数がかかることが珍しくありません。見積りを見て「たったこれだけの修正になぜこの金額？」と感じたら、多くの場合その差は調査とテストの手間です。金額の内訳を尋ね、どこに時間がかかっているのかを聞いておくと、妥当性を判断しやすくなります。

小さく足していく設計

追加開発を前提にするなら、最初から拡張しやすく作っておくのが結局いちばん安く済みます。土台の設計が悪いと、機能を1つ足すたびに全体を触る羽目になり、その都度コストがかさむからです。逆に、拡張前提で作られていれば、必要な部分だけを差し込むように追加できます。

• 一般的な技術で作る：世の中で広く使われている技術なら、後から別の会社でも対応できます。独自の作り込みは短期的には便利でも、それ自体が拡張の壁になります。
• 機能を部品ごとに分けておく：ひとかたまりに作り込むのではなく、役割ごとに区切っておくと、1つ直しても他に波及しにくくなります。
• 最初は小さく作り、使いながら足す：あれもこれもと盛り込むより、まず必要最小限で動かし、現場の声を見ながら育てるほうが、無駄な機能に払う費用を抑えられます。

大きく作り込んでから使い始めるより、小さく作って足していくほうが、要らない機能に払う費用も、後からの手戻りも減ります。発注時に「後から機能を足す前提で作ってほしい」と一言伝えておくだけでも、設計の方針は変わります。要件のまとめ方は要件定義の進め方もあわせてご覧ください。

ベンダーロックインとの関係

追加開発の悩みは、突き詰めるとベンダーロックインの問題に行き着きます。ロックインとは、特定の会社に依存して他社に乗り換えられなくなる状態のことです。追加開発の場面では、次のように表面化します。

• 追加見積りが高くても、他社が引き継げないので断れない
• ソースコードや仕様書が手元になく、別会社に相談すらできない
• 独自の作りで囲われていて、そもそも他社が対応不可能

つまり、追加開発を安心して進められるかどうかは、発注時に権利とドキュメントを押さえていたかでほぼ決まります。ここを最初に固めておけば、追加開発のたびに相見積りを取る自由が保たれ、価格も対応も健全に保たれます。仕組みと回避策はベンダーロックインの回避方法に、既存の作り替え全体の進め方はシステムのリプレースに詳しくまとめています。

発注側が用意するもの

追加開発をスムーズに進めるために、発注側が手元に揃えておきたいものを整理します。とくに別会社に頼む可能性があるなら、早いうちに確保しておくと立場が強くなります。

用意するもの	なぜ必要か
ソースコード（実物と権利）	これがないと他社は改修に着手できない
仕様書・設計書	調査の時間を短縮し、費用を下げる
データの構造・サンプル	移行や連携の検討に不可欠
やりたいことの一覧	「何を足したいか」を言葉にしておくと見積りが正確になる
現状の困りごと	改修の優先順位を決める材料になる

ここで大切なのは、やりたいことを完璧な仕様書にする必要はないという点です。「この作業が手間だから減らしたい」「この画面が使いにくい」というレベルで構いません。困りごとを箇条書きにして渡せば、あとは開発側が実現方法に落とし込みます。むしろ、権利とドキュメントという「引き継げる資産」を確保しておくことのほうが重要です。

ミニ事例（例：小売業のケース）：在庫管理システムに「発注点を下回ったら自動でアラートを出す機能」を足したいが、作った会社の見積りが高い。ソースコードと仕様書が手元にあったため別会社に相見積りを取ったところ、現状調査を1ステップ挟んだうえで、想定内の費用で追加できた——このように、資産さえ手元にあれば選択肢は取り戻せます。業種別の費用感は業務システムの費用も参考になります。

業種別・シーン別に多い追加開発

追加開発として持ち込まれる要望には、業種を問わず似たパターンがあります。よくある場面を整理しておくと、自社で「そろそろこれを足したい」と思ったときに相談しやすくなります。

シーン	よくある追加開発
業務量が増えた	一覧の検索・絞り込み強化、CSV出力、処理の自動化
手作業が残っている	帳票の自動作成、メール・通知の自動送信、二重入力の解消
他ツールと二重管理	会計ソフトや外部サービスとのデータ連携
スマホから使いたい	画面のスマホ対応、現場入力用の簡易画面
数字を見たい	集計ダッシュボード、月次レポートの自動集計

これらに共通するのは、**最初のシステムでは想定していなかった「使い始めてから分かったニーズ」**だということです。運用してみて初めて、どこが手間か、何が足りないかが見えてきます。だからこそ、最初に完璧を目指して作り込むより、動かしながら優先度の高いものから足していくほうが、費用対効果は高くなります。

導入効果の目安も押さえておきましょう。たとえば、毎日30分かかっていた集計を自動化すれば月10時間ほどの削減になり、人の手が減ればその分の転記ミスも起きなくなります。追加開発の費用を判断するときは、その機能でどれだけの手間とミスが減るかを金額に換算してみると、投資の妥当性を見極めやすくなります。

追加開発でよくある失敗

追加開発は身近なぶん、軽く考えて進めてしまい後悔するケースもあります。事前に知っておくだけで避けられるものがほとんどです。

• その場しのぎで足し続ける：目先の要望だけを継ぎ足していくと、全体の見通しが悪くなり、あるとき「もう手を入れられない」状態に陥ります。ときどき全体を俯瞰し、整理しながら育てる視点が要ります。
• 権利とドキュメントを確保しないまま進める：追加のたびに囲い込みが深まり、気づけば他社に相談できなくなります。回避の考え方はベンダーロックインの回避方法を早めに確認しておくと安全です。
• テストを省いて本番に反映する：既存機能への影響を確認せず追加すると、思わぬ場所で不具合が出ます。小さな修正でも動作確認は省かないのが鉄則です。
• 要望を丸投げする：「いい感じにして」では認識がずれます。困りごとと優先順位を言葉にして渡すだけで、仕上がりの精度は大きく上がります。

まとめ

追加開発・二次開発とは、動いているシステムに機能を足したり作り替えたりする、運用に付き物の通常工程です。相談先は「作った会社」か「別会社」の2択で、まずは作った会社に見積りを取り、金額や対応に不満があれば、ソースコードと仕様書を確保したうえで別会社の相見積りを検討します。

別会社への引き継ぎでは現状調査の重さが費用を左右するため、まず調査だけを小さく切り出すのが安全です。そして根本の対策は、発注時に一般的な技術で作ってもらい、権利とドキュメントを手元に残しておくこと。ここを押さえておけば、追加開発のたびに選択肢を持てます。「今の追加見積りが高いのか妥当なのか分からない」という段階でも、現状をお聞きすれば進め方と概算をお伝えできます。既存システムの追加開発でお悩みなら、まずは無料相談でお気軽にご相談ください。