【１】 はじめに
本記事は、2000年代前半に作成した業務システム提案書を匿名化し、当時の開発体制や技術選定を振り返るアーカイブです。
2000年代前半、私はソフトウェアハウスの社員でしたが、開発業務以外に企業向けの業務システム刷新プロジェクトで、SE/PG業務のほかプリセールスとして提案書を作成する機会を多くいただいていました。
当時は、Access ベースの業務システムがデータ量や業務拡大に追いつかなくなり、
– 拠点間での情報共有
– 営業時間外の照会対応
– 将来のパッケージ化
といったテーマが、今と同じように重要な課題として浮かび上がっていました。
このページでは、当時作成した提案書を「匿名化・再編集」したうえで、
– どのような構成で提案していたのか
– どんな技術的検討をしていたのか
– 今の視点から見て何が普遍的で、何が変わったのか
を振り返る「アーカイブ」としてまとめています。
【２】プロジェクト概要とフェーズ構成
当時の提案では、いきなり全面刷新するのではなく、段階的にリスクを抑えながら進める構成をとっていました。
■フェーズ構成
図1：フェーズ構成（2000年代前半の業務システム刷新）
（１）フェーズ1：既存システムの安定化
Access ベースの業務システムが不安定化していたため、短期間での安定稼働を最優先としたフェーズです。
バージョンアップと軽微な改修で、日常業務への影響を最小限に抑えることを狙いました。
（２）フェーズ2：全体刷新（Web化）
拠点間でのデータ共有、顧客管理・実績管理・在庫管理などの機能拡張、外部システム連携を含む全体的な再構築を行うフェーズです。
将来のパッケージ化を見据えたアーキテクチャ設計も、この段階で検討しています。
（３）フェーズ3：パッケージ化
市場性・価格帯・サポート体制・流通などを含めて検討し、汎用パッケージとして展開することを目指したフェーズです。
20年前の資料ですが、「段階的に価値を積み上げる」という考え方は、今のアジャイル開発にも通じる部分があります。
【３】システム全体構成（Web化後のイメージ）
Access 単体アプリケーションから、拠点間でデータを共有できる Web アプリケーション構成へ移行するのが、このプロジェクトの大きな方向性でした。
■システム全体構成
図2：システム全体構成（Web 化後の刷新案）
・ 拠点（修理センター、取引先、小売店）から、インターネット／VPN 経由で Web アプリにアクセス
・Web アプリケーション層で、顧客管理・実績管理・在庫管理・外部システム連携・バーコード対応などを提供
・RDBMS（SQL Server / Oracle / Postgres など）を用いたデータベース層で、顧客・実績・在庫・ログを一元管理
・ 本社側では、修理部門・入出荷部門が内部ネットワークから利用
・ 将来的には、この構成をベースにパッケージ化を検討
今見るとクラシックな 3 層構造ですが、「拠点からのオンライン参照」「外部システムとの連携」「将来のパッケージ化」という発想は、今も変わらないテーマだと感じます。
【４】開発プロセス（ウォーターフォールモデル）
当時の企業向けシステム開発では、ISO9000 系の品質管理プロセスに準拠したウォーターフォールモデルが主流でした。
■開発プロセス
図3：ウォーターフォール開発プロセス
(1) 要件定義：業務整理、システム化範囲の確定、機能要件の明確化
(2) 基本設計：画面・帳票・システム構成・ネットワーク構成の設計
(3) 詳細設計：DB設計、API仕様、内部ロジックの設計
(4) 開発（実装）：プログラム実装、外部システムとのインタフェース開発
(5) テスト：単体テスト、結合テスト、総合テスト
(6) リリース：データ移行、本番切替、運用開始
工程ごとにレビューと成果物が定義されており、「プロセスで品質を担保する」という思想が強く表れていました。
【５】 開発体制
プロジェクトは、顧客側と開発側がそれぞれ役割を持ち、縦型の体制で進める構成でした。
■開発体制図
図4：開発体制図（顧客側＋開発側）
(1)顧客側
・ プロジェクト責任者：全体方針の決定
・ プロジェクトマネージャ：業務部門との調整、要件取りまとめ
・ 業務担当：業務フロー整理、仕様レビュー
・ インフラ担当：サーバー／ネットワーク構成、運用設計
(2) 開発側
・ プロジェクトマネージャ：進捗管理、品質管理、リスク管理
・ 開発リーダー：技術方針決定、設計レビュー
・ アプリ開発チーム：Webアプリ／API／I/F開発
・ インフラ構築チーム：サーバー構築、DB環境構築
・ テストチーム：単体／結合／総合テスト、品質保証
今のプロジェクトと比べると、役割はほとんど変わっていませんが、
コミュニケーションの手段や開発スタイル（ウォーターフォール vs アジャイル）は大きく変化しています。
【６】 今振り返って感じること
この提案書を20年ぶりに見返してみると、
・ 構成や図の置き方は、今でも十分通用する部分が多い
・ 一方で、技術選定や前提としているインフラ環境は、完全に「その時代のもの」
・ それでも、「課題を整理し、段階的に解決していく」という骨格は変わらない
ということを強く感じます。
このページは、単なる「昔の資料の再掲」ではなく、
・ 自分自身のキャリアの軌跡
・ 技術と提案スタイルの変遷
・ それでも変わらない本質
を残しておくための**アーカイブ**として位置づけています。
【関連記事】
【IT課題】電子カルテ導入はなぜ崩壊するのか｜現場SEが見た医療DX失敗の共通パターン
【IT課題】電子カルテ導入の現場で本当に起きる課題と、IT担当者が担うべき役割
ケーススタディ
最大傾斜角度算出
レイトロ棚計算
Powerd by MS-Copilot
