【第12回】システム開発フェーズ(設計・開発・テスト)の秘訣は何か
◆この記事の要約
本記事では、基幹システム刷新におけるシステム開発フェーズ(設計・開発・テスト)の進め方と、品質を左右する勘所がわかります。ERPを前提に標準機能設計からアドオン/インターフェース(IF)、単体・結合・システムテスト、システム環境構築までを、ユーザー部門主導の視点で整理します。
- システム要件定義で決定した機能要件・非機能要件をERPに実装し、各種テストで検証する「システム開発フェーズ」の位置付けを解説。
- 標準機能設計(パラメーター/マスタ、権限・ロール)で、変更管理の瑕疵による設計書と実装の差分を早期に潰すポイントを整理。
- アドオン設計・インターフェース設計(基本設計/詳細設計、IPO)をスクラッチ同様の方法論で進め、実装・単体テストにつなげる流れを提示。
- 単体テスト/結合テスト/システムテスト/運用テストや本番移行に影響する品質観点、開発環境・テスト環境・本番環境のシステム環境構築の要点を集約。
システム開発フェーズは、一般的にシステム部門とERPの導入ベンダーが中心となり進めますが、主管部門であるユーザー部門がその内容を理解しておくことが、プロジェクトをスムーズに進めるうえで重要です。なぜならシステム開発フェーズの品質が、ユーザー部門が行う運用テストや、本番移行に大きな影響を与えるからです。
そこで今回は、「クラウド時代!ユーザー主導のERP導入とは」として、基幹システム刷新におけるシステム開発フェーズの秘訣をご紹介します。
システム開発フェーズとは
システム開発フェーズの位置付け
システム開発フェーズでは、システム要件定義できまった要件をシステムとして実装するとともに、システムの品質を確保するための各種テストを行い、それらを検証する重要なフェーズです。
【図1】システム開発フェーズの位置付け
システム開発フェーズの進め方
システム開発フェーズとしては、システム要件に基づきERPの標準機能設計(マスタ設定やパラメーター設定等)を行う標準機能設計、アドオンやインターフェース(IF)の基本設計と詳細設計を行うアドオン・インターフェース設計、これらについてシステムに実装しシステム機能を検証していく開発テスト(実装単体テスト、結合テスト、システム)、開発環境、テスト環境、本番環境を準備するシステム環境構築があります。
【図2】システム開発フェーズの内容
標準機能設計とは
標準機能設計では、システム要件定義をもとに、ERPをチューニングするためのパラメーターやマスタなどの設定を行う標準機能設計書(パラメーター設計書など)を作成します。
システム要件定義の中で、実機検証と設定変更を繰り返している場合、システム開発フェーズの初期段階で標準機能設計が概ね完了し、実装されている場合もあります。しかし、変更管理の瑕疵から標準機能設計書と実装内容が異なっていることもあるので、再度この段階で設計内容を検証することが重要です。
また、ERPを実際に利用するユーザーについて、それぞれ権限・ロールについても設計します。権限・ロールの設定については、ERPで異なるため、システム要件定義時に確認が必要です。
アドオン設計・インターフェース設計とは
アドオン設計・インターフェース設計では、アドオンやインターフェースについて、画面・処理・帳票などを具体的に決める基本設計と、それらシステムへの実装方法を決める詳細設計(プログラム等の仕様を決める)を行います。また、アドオン開発とインターフェース開発については、一般的なスクラッチ開発と同様の開発方法論に基づき実施することが標準的です。
アドオン設計
基本設計
基本設計では、業務フローやシステムフローを踏まえて、アドオンにて開発対象となる機能について、画面および帳票のイメージや機能の処理について案を作成します。各開発する機能単位にごとに、IPO(インプット、プロセス、アウトプット)を定義し、開発する機能について基本設計書を作成します。
詳細設計
詳細設計では、アドオンにて開発対象となる機能について、基本設計書を元に詳細設計書(画面設計書、処理設計書、帳票設計書、インターフェース設計書、データベース設計書など)を作成します。
インターフェース設計
基本設計
基本設計では、インターフェースのシステムフローを踏まえて、インターフェースに必要な機能について、画面および帳票のイメージ(エラーメッセージ画面やエラーログリスト等)、処理について案を作成します。各開発する機能単位にごとに、IPO(インプット、プロセス、アウトプット)を定義し、開発する機能について基本設計書を作成します。
詳細設計
詳細設計では、インターフェースに必要な機能について、基本設計書を元に詳細設計書(画面設計書、処理設計書、帳票設計書、インターフェース設計書、データベース設計書など)を作成します。
※ETLツールを使ってインターフェースを行う場合は、ETLツールの設定仕様に基づいて設計します。
開発・テストとは
開発・テストでは、標準機能設計書、アドオン詳細設計書、インターフェース詳細設計書に基づいてシステムに実装するとともに、システムの品質を確保するための単体テスト、結合テスト、システムテストを行います。
開発テストの種類
開発テストは、単体テスト、結合テスト、システムテスト、運用テストがあります。
【図3】テストの位置付け
- 単体テスト
個々の機能やプログラムが仕様通りに動作するかを確認 - 結合テスト
複数の機能やモジュールが連携して正しく動作するかを検証 - システムテスト
システム全体としての動作確認を業務フローに沿ったテストで検証 - 運用テスト
実際のユーザーが業務シナリオに基づき操作し、要件が満たされているかを検証
導入ベンダーが主体的に行うのは一般的にシステムテストまでです。運用テストはユーザーが主体的に行うため、ここでは業務運用整備フェーズとして扱います。
開発・テスト ①実装・単体テスト
実装・単体テストでは、下記を行い、それぞれ設定やプログラムが設計書通りか単体テストで検証し、ERPの標準機能について標準機能設計書に基づきシステムに実装(設定など)します。
また、アドオン開発では、アドオン設計書(画面設計書、処理設計書、帳票設計書、データベース設計書)に基づき、プログラム開発やデータベース設定を行います。インターフェース開発では、インターフェース設計書に基づき、プログラム開発や連携基盤(ETLなど)の設定を行います。
実装・単体テストの具体的な手順
実装・単体テストは、下記の手順で実施します。
【図4】実装・単体テストにおける主な手順
開発・テスト ②結合テスト
結合テストでは、アドオン開発やインターフェース開発の個々のプログラム間の連携、ERPの標準機能とアドオン機能・インターフェース機能との連携が、設計通りに正しく機能していることを検証します。
結合テストの内容
内部結合テスト(プログラム間連携)
アドオンプログラム間の連携を検証します。例えば、アドオンで開発した受注分割処理と、それを実行するバッチプログラムとの連携など、複数のアドオンプログラムを連続して実行し、データの受け渡しを検証して、ERP標準機能とアドオンの連携を検証します。
例えば、ERPの標準処理(例:検収登録)を実行した際に、それがトリガーとなって動作するアドオン機能(例:支払期日設定処理)が設計通りに呼び出され、正しく結果を返すかを検証します。
外部結合テスト(インターフェース連携)
- ERPと外部システム間の連携検証
例えば、ERPと連携元・連携先の既存システムや外部サービスとの間で、定義されたインターフェース仕様に基づき、データ連携が行われているかを検証します。 - データ送受信検証
例えば、連携ファイルやAPIを通じてデータが欠落なく、指定された形式で適切なタイミングで送受信されているかを検証します。 - エラーハンドリング検証
例えば、連携データの形式を意図的に壊したり、通信を中断させたりして、エラー処理ロジック(データの再送、エラーログ出力、通知)が設計通りに動作するかを検証します。
結合テストの具体的な手順
結合テストは、下記の手順で実施します。
【図5】結合テストにおける主な手順
開発・テスト ③システムテスト
システムテスト(総合テスト)では、開発された標準機能、アドオン機能、およびインターフェース機能が、連携を含めて設計通りに動作することを、システム全体として検証します。また、性能(パフォーマンス)、負荷、セキュリティ、可用性(バックアップ・リカバリ)などの非機能要件について、システムが実運用に耐えうるかを検証します。
システムテストの内容
機能テスト
- 業務シナリオテスト
実際の業務フローに基づいた大規模なテストデータとシナリオを使用し、システムが業務要件を完全に満たすかを確認します。 - 入出力/インターフェーステスト
外部システムとの連携(連携データ、ファイル形式、タイミング)が、総合的な業務プロセスの中で機能するかを検証します。 - 権限/セキュリティテスト
ユーザーの役割(ロール)に応じたアクセス権限が正しく設定されており、機密データへの不正アクセスができないことを確認します。
非機能テスト
- パフォーマンステスト(性能試験)
特定のトランザクション(例:月末の請求書発行処理)の応答時間が許容範囲内かを確認します。
将来のデータ増加やピーク時のアクセス量を想定した負荷テストを実施し、システムの限界を把握します。 - 運用・継続性テスト
バックアップとリカバリ手順を実際に実行し、データが完全に復旧できることを検証します。
障害発生時の切り替え(フェイルオーバー)や、監視機能が設計通りに動作するかを確認します。
システムテストの具体的な手順
システムテストは、下記の手順で実施します。
【図6】システムテストにおける主な手順
システム環境構築
開発フェーズのシステム環境構築では、開発環境、テスト環境(結合テスト環境、システムテスト環境、運用テスト環境)、本番環境を準備します。
システム環境構築の内容
開発環境の構築と管理
設計書に基づいてプログラム開発やデータベース設定などが行える開発環境を構築します。
開発したプログラムや設定変更をテスト環境へ移行するための手順(トランスポート管理など)を確立・実行します。プログラムのバージョン管理を行い、開発が維持・継続できる状態を確保します。
テスト環境の構築と維持
結合テストやシステムテスト、運用テストが行えるテスト環境を構築します。
テスト環境のデータをリフレッシュ(巻き戻し)して、テストの再現性確保なども行います。
システムテストにおける負荷テストに対応できるよう、一時的にハードウェアリソースを増強したり、設定を最適化したりします。
本番環境の構築と初期設定
確定したサイジングに基づき、クラウドまたはオンプレミスの本番サーバー、ストレージ、ネットワークを構築し、セキュリティ設定(ファイアウォール、アクセス制御)を適用し、本番環境を構築します。
ERPをインストールし、システム要件定義で確定した基本パラメーター・マスタ(言語、会計期間、組織構造など)を設定します。
システム環境構築の具体的な手順
システム環境構築は、下記の手順で実施します。
【図7】システム環境構築における主な手順
まとめ
今回は、「クラウド時代!ユーザー主導のERP導入とは」として、基幹システム刷新におけるシステム開発フェーズの秘訣をご紹介しました。今後の基幹システム刷新は、情報システム部門やベンダーへ丸投げはできません。ユーザー部門が主導して、ERPを Fit to Standardで導入していくことが成功の秘訣といえます。詳細な Fit to Standard でのERP導入のポイントについては、是非レイヤーズ・コンサルティングにお問い合わせください。


ソリューションに関するオンライン相談問い合わせる メルマガ登録
最新情報をお届け! メルマガ登録
この記事の執筆者
-
村井 泰三経営管理事業部
バイスマネージングディレクター -
山本 晶代経営管理事業部
ディレクター -
飯田 稜大経営管理事業部
シニアマネージャー
職種別ソリューション





