業務システムの刷新をオフショア開発パートナーに委託する際、「現行機能をすべて引き継ぐ」という方針は合意しやすく見えます。しかし、既存の画面一覧だけでは、今も必要な機能、重複している機能、利用者が明確でない機能を見分けられません。
SIer、CTO、DX推進担当者にお勧めしたいのは、開発範囲を確定する前に、機能を「再構築・暫定維持・追加調査・廃止候補」に整理した判断一覧をつくることです。
1. 画面ではなく、業務から確認する
機能ごとに、誰が、何の業務で、いつ使い、出力を誰に渡すのかを整理します。利用部門へのヒアリングに加え、既存資料、出力帳票、自動処理の実行予定など、確認できる情報を照合します。
一定期間アクセスがなかったことだけで、未使用とは判断できません。期末処理、年次業務、まれに発生する処理も確認します。別のシステムがその機能の出力を利用していないかも確認が必要です。
2. 判断の根拠と承認者を残す
一覧には、機能、業務責任者、利用を示す情報、依存関係、対応方針、承認者、見直し日を記録します。対応方針は次の四つに分けます。
- 再構築：業務上の必要性があり、維持すべき出力が明確になっている。
- 暫定維持：依存関係が残るため、維持する期限と運用責任者を決める。
- 追加調査：判断材料が不足しているため、確認事項、回答者、回答期限を決める。
- 廃止候補：代替手段がある、または必要性がなくなっており、業務責任者の承認を待つ。
開発側は技術的な影響を評価し、業務上の必要性はお客様側の権限を持つ担当者が判断します。回答がないことを、廃止への同意として扱わないことも大切です。
3. 想定例：似ている二つの売上帳票
あるSIerが、日本企業の受注管理システムを刷新すると仮定します。機能一覧には、よく似た二つの売上帳票があり、チームは開発範囲を絞るために一本化を提案しました。
経理部門に確認すると、一方は年次の照合に使われ、月次帳票とは取消注文の扱いが異なることが分かりました。この時点では、照合業務の要件を残し、ルールを明確にしたうえで、データソースの共通化を検討します。画面を統合できるかは別途判断します。これは説明のための想定例であり、TECHNESTの案件や実績ではありません。
4. 対象外とする機能も計画に記載する
廃止に合意した機能については、過去データの参照方法、問い合わせの担当者、判断を見直す条件を記録します。データの保管方針は別途決めます。機能の廃止とデータの削除は、同じ判断ではありません。
承認済みの一覧は、開発要件や受入基準とともに管理します。日本とベトナムのチームで共通の機能IDと判断記録を使えば、確認する対象をそろえられます。未確定事項は前提条件や調査項目として明示し、説明なく見積の対象に含めたり、外したりしないようにします。
5. TECHNESTとのご相談
TECHNESTは、日本市場向けの業務システム設計・開発、レガシーシステムの刷新に長年取り組み、日本のコンサルティングパートナーとも協業しています。まずは一つの業務フローと、対応方針を決めかねている機能の一覧をもとに、対話を始めることを提案します。
基幹・業務システムのサービスをご覧いただくか、TECHNESTへご相談ください。開発に入る前の調査範囲と、合意すべき成果物をご一緒に整理します。
