法人向け受発注サービスの基幹システム刷新

プロジェクト概要

ご相談の背景

今回の対象となったのは、事業承継に伴って現在の会社へ引き継がれた法人向け受発注サービスです。サービスの基幹システムは20年以上前に開発されたもので、現在では扱える技術者がほとんどいない状態でした。設計書や仕様書も残っておらず、継続的な保守や運用、機能追加を行うことが困難になっていました。

一方で、すでにサービスを利用しているユーザーがいるため、既存の受発注業務を止めることはできません。そこで、現在の機能や業務の流れを維持しながら、今後も保守・改修できる基幹システムへ全面的に刷新することになりました。

稼働中の画面から仕様を復元

旧システムには設計資料が残っていなかったため、実際に稼働している画面を確認しながら、一つずつ機能と操作の流れを整理しました。画面に表示される項目、入力内容、操作順、注文の流れなどを確認し、現行システムの画面を実質的な仕様書として扱いながら、新システムで再現すべき内容を整理しています。

既存機能を単に作り直すのではなく、現在の利用者がどのような手順で業務を行っているかを把握したうえで、要件と仕様を文書化しました。

全画面の操作可能なプロトタイプを作成

文章や静止画だけでは、完成後の画面や操作方法を具体的に共有することが難しいため、実装前にHTMLとJavaScriptを使用した操作可能なプロトタイプを作成しました。一部の主要画面だけではなく、対象となるすべての画面を用意し、発注者が実際に操作しながら完成後のイメージを確認できる状態にしました。

確認の過程では、カレンダー画面の表示や操作方法など、事前の説明だけでは見つけにくかった改善点も明らかになりました。指摘内容をプロトタイプへ反映し、再度操作してもらう流れを繰り返しながら、画面仕様と操作方法を具体化しています。

合意した内容は画面設計書や仕様書へ反映し、認識を合わせてから本実装へ進めています。

「改善しすぎない」ことを重視

今回の刷新で難しかったのは、単純に機能を増やしたり、操作方法を大きく変更したりすることではありませんでした。既存サービスにはすでに利用者がいるため、画面や操作の流れを大きく変えると、利用者の再学習や問い合わせの増加につながります。

そのため、初回リリースでは注文までの基本的な流れや操作順を維持し、新機能の追加は行わない方針としました。一方で、複数の目的が混在していた画面については、一覧・登録・編集などの役割ごとに分離しています。

従来の操作感を残しながら、1画面の目的を明確にし、利用者が必要な情報や操作を見つけやすい画面構成へ整理しています。新しい機能を盛り込むことよりも、既存利用者の学習コストを抑えながら、日常の注文・管理業務を継続できることを優先しています。

今後の保守と機能追加に対応できる構成へ

新システムはLaravel 13とMySQL 8.0を使用して再構築しています。旧システムの機能を維持しながら、画面、データベース、権限、業務処理を整理し、今後の保守や機能追加に対応しやすい構成としています。

開発規模は、35画面、11テーブル、76ルート、約400時間です。要件定義、画面設計、データベース設計、実装、テストまでを1名で担当しています。

複数企業のデータを分離

このシステムは、複数の契約企業が利用する構成です。企業間でデータが混在しないよう、すべての業務データを企業ごとの識別情報に紐付けて管理する設計としています。

データベースだけではなく、データを取得・更新する処理でも企業単位の分離を行い、利用企業が自社のデータだけを扱える構成にしています。また、企業内でも一般ユーザーと管理者の権限を分け、担当する業務に応じて利用できる機能を制御しています。

必要な情報だけを新システムへ移行

旧システムに蓄積された過去の受注履歴は、新システムへ引き継ぐ必要がないため、移行対象を今後の運用に必要なデータへ限定しています。移行する主な情報は、契約企業情報、登録ユーザー情報、ユーザーの権限情報です。

旧システムのCSVバックアップをもとに、新システムで利用できる形式へ変換して移行する予定です。新システムへの切り替えに合わせて、稼働サーバーとドメインも刷新します。

注文業務を止めないための切り替え計画

今回の刷新で最も重要なのは、運用開始後も利用者が問題なく注文を続けられることです。リリース前には、発注者による受入テストを実施し、実際の業務手順で注文や管理操作に問題がないことを確認します。

本番環境への切り替えは注文時間外に行い、日常の受発注業務への影響を最小限に抑える予定です。品質確認として、自動テスト、画面単位の動作確認、テスト仕様書に基づく確認、発注者による受入テストを予定しています。

納品後の保守と引き継ぎも考慮

発注者は、リリース後に自社でもシステムを把握し、可能な範囲でメンテナンスできることを重視しています。そのため、最新技術を多用した複雑な構成を優先するのではなく、発注者の運用体制に合った分かりやすさと保守性を基準に設計しています。

納品時には、画面仕様や業務ルールを整理した仕様書を提出します。また、ソースコードには、複雑な業務ルールや処理の意図が分かるようにコメントを残し、第三者が引き継いだ場合にも理解しやすい状態を目指しています。

リリース後の保守体制は現在調整中です。

現在の状況

2026年8月現在、要件定義とプロトタイプによる仕様確認を終え、本実装を進めています。2026年10月の運用開始を予定しており、リリース後は利用状況や要望を確認しながら、追加機能を段階的に検討していく予定です。

このようなご相談に対応します

• 古い技術で作られ、改修できる技術者がいない
• 設計書や仕様書が残っていない
• 現在の利用者や業務への影響を抑えて刷新したい
• 要件が固まっていないため、整理から任せたい
• 納品後も保守や引き継ぎができる状態にしたい

古いシステムを刷新したいものの、何から確認すればよいか分からない場合もご相談ください。稼働中の画面や現在の業務を確認し、残す機能、整理する部分、移行方法を一緒に整理します。