お客様：東海地方の販売・レンタル事業者

導入背景

お客様は、基幹システムの刷新を進めていました。販売・レンタル・工事・修理の管理を担うシステムです。一次開発は以前から取引のあるベンダーが担当しており、その後の機能追加や改善、保守については、別のベンダーに協力してもらう方針でした。

二次開発の領域は、主に次の4つです。

• 販売・レンタル・工事・修理管理の機能改善
• 画面の使いやすさの改善
• 検索や初期表示の速さの改善
• マスタの拡張や整合性チェックなどのデータ整備

ご相談のきっかけ

きっかけは、当社のブログ記事をご覧になってのお問い合わせです。刷新中の基幹システムの二次開発と保守を担う協力ベンダーを選んでいる段階で、システムの開発言語やデータベースが当社の扱う技術領域と一致していたことと、業務アプリ開発の実績を見てご連絡をいただきました。伺いたい点は三つでした。対応できるかどうか、進め方、概算費用です。一次開発の不具合の修正は既存ベンダーが続けて担うため、ご相談の範囲外でした。

進め方

役割は分けています。一次開発の不具合の修正は、本番環境の構築やデータ移行と同じく、引き続き一次開発のベンダーが担い、当社はソースコードの提供や、トラブル時のサポートを受け持ちます。

1. 開発の管理基盤づくり（2025〜2026年）：二次開発に入る前に、Gitでソースコードを管理する仕組みを整える
2. フェーズ1（2026年）：課題ごとに設計・開発・確認を行う。お客様が当社の品質を見て次の判断ができるよう、終わった課題から分けて納品する
3. フェーズ2（2026年）：お客様が必要な課題を約40件に絞り込み、その大半を当社が担当する。要件が複雑なものから先に着手し、モジュールごとに順に納品する
4. 三次開発の要件定義（2026年）：フェーズ2の後に予定している開発の要件を固める

フェーズ1で分かったことがあります。業務の運用を確かめないまま作ると、手戻りが出るのです。そのためフェーズ2からは、運用方法を先にうかがってから開発に入るようにしています。

フェーズ2では、現場の担当者の方が実際の業務に合うかを確かめるため、システムをビルドして各担当者の環境へ配布する手順を、お客様と一緒に準備しました。課題のやり取りはBacklogで行います。課題ごとに担当者も必ず決めています。どこで止まっているかを分かるようにするためです。

その後の支援

現行システムとの並行稼働で請求書などの出力が一致するかを確かめ、本番稼働に進む計画で、稼働後の保守についても現在ご相談をいただいています。

目指したこと

一次開発のベンダーと役割を分けながら、必要な機能から順に使える状態にすることです。納品は小さな単位で重ねています。お客様が当社の対応を確かめながら、次の発注を判断できるようにするためです。

お役立ち資料はこちら