既存システムへの追加開発を検討するとき、多くの担当者がまず知りたいのは「自社と似た状況の企業が、稼働中のシステムにどうやって新機能を足し、どんな成果を出したのか」という具体的な事例ではないでしょうか。すでに動いている基幹システムやWebサービスに手を入れる追加開発は、ゼロから作る新規開発とは勝手が違い、既存の処理を壊さずに機能を足す難しさがあります。だからこそ、自社の状況に近い導入事例・成功事例こそが、投資判断の精度を高めてくれます。
本記事は、既存システムへの機能追加・改修を中心とした追加開発の導入事例・開発事例・活用事例・成功事例を、発注企業の視点から掘り下げる「事例特化」の解説です。補助金を活用した中小企業の等身大の成功事例、データ移行や並行稼働を伴うリプレイス型の追加開発、さらにANAやデンソーといった大企業の実例、そして炎上したプロジェクトを火消しして立て直した事例まで、一次データとあわせて具体的に解説します。読み終えるころには、自社が「どこから着手し、どんな効果を狙うべきか」のイメージが描けるはずです。なお、追加開発の全体像をまだ把握していない方は、まず追加開発の完全ガイドから読むことをおすすめします。
補助金を活用した中小企業の追加開発事例
追加開発の事例というと、大企業の華やかなプロジェクトを思い浮かべがちですが、発注側がもっとも参考にできるのは、自社と規模感の近い中小企業の等身大の事例です。すでに導入済みの業務システムやECサイトに、補助金を使って機能を足し、限られた予算で着実に成果を出している中小企業は数多く存在します。ここでは、その堅実な進め方を具体的に見ていきます。
IT導入補助金で自己負担を抑えた機能追加事例
中小企業の追加開発でまず注目したいのが、補助金の活用です。IT導入補助金は5万円から450万円までを対象とし、採択率は45〜55%とされています。すでに使っている販売管理システムや予約システムに、在庫連携機能や顧客向けのオンライン機能を追加したい、といったケースで、この補助金を使えば実質的な自己負担を大きく抑えられます。たとえば300万円の機能追加に対して採択されれば、自己負担が半分以下になる場合もあり、これが投資に踏み切る決め手になっています。
補助金活用の事例から学べるのは、「補助金の対象になる機能追加を、申請スケジュールに合わせて計画的に進める」という発想です。小規模事業者持続化補助金（採択率60〜65%）など、自社が使える制度を事前に把握し、それに合わせて要件をまとめておくと、採択の可能性が高まります。追加開発は新規開発より費用が安く収まりやすいため、補助金の上限内に収まる規模で計画できることが多く、中小企業との相性が良いのです。事例を読むときは、この「補助金を前提に追加開発の範囲を設計する」という視点を持つと、自社でも再現しやすくなります。
小さく足して成果を積み上げた段階的追加事例
中小企業の成功事例に共通するのが、「一度に大きく作り変えるのではなく、効果の大きい機能から小さく足していく」という段階主義です。既存の業務システムに対して、まずもっとも手作業の多い帳票出力を自動化する機能を足し、その効果を確認してから、次に在庫連携、その次に取引先向けのWeb画面、というように段階的に機能を追加していきます。一度に全部を作り変えるリプレイスと違い、各段階で投資対効果を確認しながら進められるのが、追加開発の大きな利点です。
この積み上げ型の進め方は、予算が限られる中小企業にとって特に有効です。最初の機能追加で現場が「これは楽になる」と実感すれば、社内の理解が得られ、次の投資の稟議も通りやすくなります。費用の約8割は人件費が占めるため、追加する機能の規模をコントロールすれば、予算も予測しやすくなります。なお、こうした段階的な追加開発でも、既存システムへの影響範囲を見誤ると思わぬトラブルにつながります。リスクの詳細は『追加開発の失敗・課題・注意点・リスクについて』もあわせてご覧ください。
データ移行・並行稼働を伴うリプレイス型追加事例
追加開発の中でも難易度が高いのが、老朽化した既存システムの一部を新しい仕組みに置き換えながら、機能も追加していくリプレイス型のプロジェクトです。長年使ってきたシステムには大量のデータが蓄積されており、それを新しい基盤に移しつつ、業務を止めずに切り替える必要があります。ここでは、データ移行と並行稼働を伴う追加開発の事例から、成功のポイントを読み解きます。
業務を止めずに並行稼働で切り替えた事例
リプレイス型の追加開発で最大の山場となるのが、新旧システムの並行稼働です。既存システムを動かしたまま、新しい機能を別の環境で構築し、一定期間は両方を同時に動かして、新システムが正しく動くことを確認してから完全に切り替えます。成功事例では、いきなり全部を切り替える一斉移行ではなく、機能や拠点を区切って少しずつ移す段階移行を選んでいます。これにより、万一新システムに問題が起きても、既存システムに戻せる安全策を確保しています。
データ移行も、リプレイス型追加開発の成否を分ける重要な工程です。長年蓄積されたデータには、表記ゆれや重複、古い形式のデータが混在しており、そのまま移すと新システムで不整合を起こします。成功事例では、移行前にデータの棚卸しと整理（クレンジング）を丁寧に行い、移行のリハーサルを複数回繰り返してから本番移行に臨んでいます。改修は新規開発より安く収まりやすいとされますが、このデータ移行の工数を甘く見積もると予算が膨らむため、要件定義の段階で移行対象データの量と品質を把握しておくことが重要です。
既存ベンダー以外に発注して刷新した事例
追加開発で意外と多いのが、「これまで開発を任せてきたベンダーとは別の会社に、追加開発を発注する」というケースです。既存ベンダーの対応が遅い、見積りが不透明、新しい技術に対応できない、といった理由で、別のパートナーに乗り換える企業は少なくありません。成功事例では、新しいベンダーがまず既存システムのソースコードや仕様書を読み解き、影響範囲を把握する「現状調査」に十分な時間をかけています。
既存ベンダー以外への発注で重要なのは、引き継ぎの設計です。既存システムの仕様が文書化されていない、いわゆる属人化した状態だと、新しいベンダーは手探りで進めることになり、追加開発のリスクが跳ね上がります。成功事例では、発注側が既存システムの仕様や過去の改修履歴をできる限り整理して新ベンダーに渡し、不明点は旧ベンダーにも協力を仰いで埋めています。この丁寧な引き継ぎがあれば、別会社への発注でも安全に機能追加を進められます。乗り換えを成功させる鍵は、既存システムの情報をどれだけ正確に新ベンダーへ渡せるかにあります。
大企業のモダナイズ・機能追加の実例
大企業の追加開発事例は、規模こそ違っても「既存資産を活かしながら段階的にモダナイズする」という発想において、中小企業にも応用できる学びが詰まっています。ここでは、公表されている代表的な実例を取り上げ、追加開発をどう設計し、どんな成果を出したのかを見ていきます。具体的な数値とともに読み解くことで、自社の計画に活かせるヒントが得られます。
ANAのAPIゲートウェイ化（約5か月）の事例
大企業の追加開発で参考になるのが、ANAが既存システムをAPIゲートウェイ化したプロジェクトです。約5か月という比較的短い期間で、既存の仕組みを外部や他システムから呼び出しやすいAPIとして整備しました。既存システムをまるごと作り直すのではなく、外部との接点となるAPI層を追加することで、既存資産を活かしながら拡張性を高めたのが特徴です。これは追加開発の理想形のひとつと言えます。
この事例から学べるのは、「既存システムを土台として残し、その上に新しい接続層や機能層を足す」という発想です。古い基幹システムであっても、いきなり全面刷新するのはリスクとコストが大きすぎます。代わりに、外部連携や新サービスに必要な部分だけをAPIとして追加すれば、既存の安定稼働を守りながら、新しいビジネスニーズに応えられます。約5か月という期間も、全面刷新と比べれば短く、投資対効果を早期に検証できます。中小企業でも、既存システムに連携用の窓口を追加するという発想は十分に応用できます。
デンソーの社内アプリ（5か月で1,700ユーザー）の事例
もうひとつの参考事例が、デンソーの社内向けアプリ「yuriCargo」です。約5か月の開発で1,700ユーザーが利用する規模にまで広がりました。既存の業務や仕組みを踏まえて、現場が本当に必要とする機能を素早く形にし、短期間で多くの利用者に届けた点が成功要因です。大企業であっても、最初から完璧な大規模システムを目指すのではなく、必要な機能から素早く追加し、利用者の反応を見ながら育てるアプローチが有効だと示しています。
この事例の本質は、開発のスピードと現場密着にあります。5か月という期間で1,700ユーザーに浸透したのは、現場のニーズを起点に機能を追加し、使われながら改善を重ねたからです。大塚商会のフィッティングコンサルの事例でも、約5.5か月で40回弱の打ち合わせを重ね、開発費の5〜6%をコンサルに充てて要件を磨き込んでいます。追加開発を成功させるには、技術力だけでなく、現場と密に対話しながら必要な機能を見極める力が不可欠だと、これらの大企業事例は教えてくれます。
炎上プロジェクトを火消しして立て直した事例
事例の価値は、成功談だけにあるのではありません。むしろ、発注側がもっとも学べるのは「炎上したプロジェクトを、どう立て直したのか」というリアルな経験です。追加開発は既存システムに手を入れる分、思わぬ不具合や仕様の食い違いから炎上に至るケースがあります。そこから火消しして立て直した事例には、これから投資する企業にとって何よりの保険になる教訓が詰まっています。
影響範囲調査からやり直して立て直した事例
炎上した追加開発の多くは、既存システムへの影響範囲を正しく調べないまま機能を足し、リリース後に既存の処理が動かなくなる不具合（デグレード）を多発させたことが原因です。立て直しに成功した事例では、いったん開発を止め、既存システムのソースコードと仕様を改めて精査し、追加する機能がどこに影響するかを徹底的に洗い出すところからやり直しています。この影響範囲調査こそが、安全な追加開発の出発点です。
火消しに入ったチームは、既存の処理を壊していないかを確認するための回帰テスト（リグレッションテスト）を整備し、機能を追加するたびに既存機能が正常に動くかを自動でチェックできる仕組みを作りました。同じテストを3〜5回繰り返すなら自動化が採算に合うとされており、炎上案件の立て直しでは、この自動テストへの投資が再発防止の決め手になります。立て直しの本質は、新しい機能を急いで足すことではなく、既存システムへの影響を見える化し、安全に足せる土台を作り直すことにあります。
スコープ合意を再設計して泥沼を脱した事例
炎上のもうひとつの典型が、追加する機能の範囲（スコープ）が曖昧なまま開発を始め、「これも追加で」「あれも直して」と仕様変更が無制限に膨らみ、工数と予算が破綻するパターンです。立て直しに成功した事例では、いったん仕切り直して、何を今回の追加開発で実現し、何を次回に回すかをスコープとして明確に合意し直しています。このスコープ管理の徹底が、泥沼化を脱する鍵になります。
仕様変更をめぐる対立は、ときに訴訟にまで発展します。スルガ銀行と日本IBMの事件では、初期見積り約95億円に対し追加で127億円が要求され、最終的に高裁が約41.7億円の支払いを命じる事態となりました。訴訟記録は72冊に及び、打ち合わせの「箸袋」のメモまで証拠として扱われたと言われます。この極端な事例は、追加開発における仕様変更の合意と記録がいかに重要かを物語っています。立て直しに成功した企業は、議事録を丁寧に残し、追加要望が出るたびに費用と納期への影響を明示して合意を取り直すことで、泥沼を回避しています。
まとめ
追加開発の事例を振り返ると、成功も炎上からの回復も、結局は「既存システムへの影響範囲を正確に把握し、効果の大きい機能から段階的に足していく」という一点に集約されます。中小企業はIT導入補助金（採択率45〜55%）を活用して自己負担を抑え、ANAのAPIゲートウェイ化やデンソーの社内アプリのように、大企業も既存資産を活かした段階的なモダナイズで成果を出しています。一方で、影響範囲の調査やスコープの合意を怠ると炎上に至り、スルガ銀行と日本IBMの事件のように訴訟にまで発展するリスクもあります。
事例を読むときに大切なのは、「どれだけ大規模に作ったか」ではなく「なぜ既存を壊さずに足せたか」という視点です。自社の既存システムと予算に照らし、まずは効果の大きい機能の追加から、安全な一歩を踏み出してください。riplaはフルスクラッチ受託と国内開発を組み合わせ、既存システムの影響範囲調査から、現場に定着する安全な機能追加までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。