今回はシステム構築フェーズの進め方の概要について共有します。
システム構築フェーズにてやることはどういうものか、簡単ではありますが経験のない方や全体像の把握をしたい方向けに概要をまとめてみましたので、参考になれば幸いです。
尚、会社によってそれぞれの呼び方や作業のまとめ方は異なりますので、唯一の絶対的な正解があるわけではありません。
それを念頭に、ここではその内のひとつの考え方である、と理解していただくと良いと思います。
システム構築フェーズはアプリケーション開発、インフラ構築、ユーザー教育、運用保守、移行、他システム対応の6つの領域に分類できる
システム構築フェーズのやることは、大きく6つの領域に分類されます。
- アプリケーション開発
 - インフラ構築
 - 運用保守
 - 移行
 - ユーザー教育
 - 他システム対応
 
アプリケーション開発は、プロジェクトのメインストリームであり、新しい業務やシステムの構築をする活動です。
インフラ構築は、新しいシステムが稼働する基盤となる、ハードウェア、ネットワーク、サーバー、クライアント、ミドルウェアを構築する活動です。
ユーザー教育は、ユーザーが新しい業務・システムをスムーズに利用できるように周知・教育する活動です。
運用保守は、システムリリース後のシステムに対する運用保守保守作業をスムーズに実施するための活動です。
移行は、システムや業務を現在のものから新しいものに切り替える活動です。
他システム対応は、新しいシステムとデータ連携を行うシステムとの連携を準備する活動です。
それぞれの領域に対して必要なスキルセットは異なりますので、メンバーは基本的には別の要員になります。
(ただし、複数の活動をこなせるスキルセットを持った優秀な人もいますので、そういう人がいる時は兼務できます)

それでは一つ一つもう少し詳しく見ていきましょう。
アプリケーション開発は要件定義からテストまでのメインストリーム
アプリケーション開発は、プロジェクトのメインストリームであり、新しい業務やシステムの構築をする活動です。
更に分類すると以下の4つに分けられます。
- 要件定義
 - 設計
 - 開発
 - テスト
 
要件定義は、新しい業務やシステムの機能に対する要件、つまりどんな業務・システムを作るかを決める活動です。
要件定義には大きく機能要件定義と非機能要件定義があります。
- 機能要件定義は、新しい業務はどんなものか、その業務を実現するため新しいシステムに具備する機能(画面・バッチ・帳票・インターフェース)は何か、を決めます。
 - 非機能要件定義は、セキュリティ、システムが使える時間帯、システムの処理速度、システム増強のしやすさなど、システムがどのように動作すべきかを決めます。
 
新しい業務フローを定義するまでの作業を業務要件定義、残りの作業をシステム要件定義と呼ぶこともあります。
設計は、要件定義で具備すると定義した各機能に対し、機能単位で詳細に仕様を詰めていく活動です。
例えば画面設計では、各画面に対するデザイン、画面で表示する項目、ボタンを押した時などの挙動などの仕様を決めます。
開発は、設計で定めた仕様を満たすプログラムを開発する活動です。
各機能を更にモジュール・プログラム単位に分割し、実装(プログラミング)し、モジュール・プログラム単位で想定通り稼働するかを検証します。
テストは、実装したシステムが仕様通りに稼働するかを検証する活動です。
テストは大きく、結合テスト、システムテストに分けられます。
- 結合テストは、モジュール間やシステム間を結合して、設計書通りに各機能が動作するかを検証する工程であり、システム内結合テストとシステム間結合テストに分けられます。
- システム内結合テストは、機能単位(画面・バッチ・帳票・インターフェース)単位でモジュールを連携させたり、各機能を順番に実行して連携させることで、設計書通りに動くことを検証します。
 - システム間結合テストは、他システム対応とのデータ連携が設計書通りに動くか検証します。
 
 - システムテストは、要件定義で定義した要件通りに新しい業務やシステムが動くことを検証します。具体的には、新しい業務に沿ってシステムを動かして想定通りに業務が実現できること、システムの性能に問題ないこと、セキュリティが想定通りに実装され悪さができないことなどを検証します。
 
インフラ構築はシステムが動く基盤をアプリケーション開発の活動の一歩前で準備する
インフラ構築は、新しいシステムが稼働する基盤となる、ハードウェア、ネットワーク、サーバー、クライアント、ミドルウェアを構築する活動です。
インフラは、アプリケーションを設計・開発する土台になるものなので、アプリケーション開発が設計に入る前に基盤の設計が完了している必要があるなど、アプリケーション開発の工程よりも一つ前を走って設計・構築する必要があります。

以前はサーバーをデータセンターや自社内に置くことが多かったですが、最近はクラウドがメインになってきていますので、ハードウェア、ネットワーク、サーバー、ミドルウェアはAWSやAzureなどのクラウドのプラットフォームを利用することも増えてきました。
ユーザー教育は本稼働後にスムーズに新しい業務が定着できるかのカギとなる
ユーザー教育は、ユーザーが新しい業務・システムをスムーズに利用できるように周知・教育する活動です。
ユーザーに新しいシステムに関する説明会を行う、ユーザーマニュアルを作成してユーザーが新しいシステムを迷わず使えるようにする、システムリリース前にユーザー受入テストにてユーザーに新しいシステムを触ってもらい新しい業務がきちんと回るかどうかの検証をしてもらう、ような作業です。

事前に要件定義や設計で決めたことは頭の中で思い描いたものなので、新しいシステムを触って実際に業務をやってみると「あれ?イマイチだな・・・」と気づくところが必ずあります。
その場合は、予算・スケジュールの範囲内で取り込み可能な要望を仕様変更という形で取り込むことで、ユーザーの満足度・業務効率アップに貢献します。
運用保守/移行は忘れがちだが重要なポイント
運用保守は、システムリリース後の運用保守保守作業をスムーズに実施するための活動です。
システム担当者が、システムの安定稼働のために必要な作業を運用業務メニューとして定義し、作業時に利用する手順書・ツールなどを用意します。
移行は、システムや業務を現在のものから新しいものに切り替える活動です。
移行にはシステム移行、データ移行、業務移行の3つがあります。
- システム移行は、現在利用しているシステムから新しいシステムへ切り替える作業
 - データ移行は、現在利用しているシステムのデータや新しいシステムに必要なデータを、新しいシステムに登録する作業
 - 業務移行は、ユーザーが現行業務から新しい業務に切り替える作業
 
を指します。

せっかく苦労してアプリケーション開発やインフラ構築を問題なく完了しても、移行で失敗するとユーザーをはじめ関係者にご迷惑をおかけし、新しいシステムに対する信頼を落としてしまいます。
なので、移行はとても重要かつドキドキする作業です。
運用保守/移行は、システムリリース後に早期に安定稼働させるために必要な工程ですが、実は小規模なシステムだと大仰過ぎて不要な場合もあります。
しかし、規模が大きくなってくれれば必須の活動であり、意外と忘れやすい活動でもありますので、注意することをオススメします。

これらの作業が計画時点で組み込まれていなかったせいで、プロジェクト後半でトラブルになって炎上するプロジェクトをいくつか見てきました・・・
他システム対応は連携先システムの担当者と足並みを合わせて進める
他システム対応は、新しいシステムとデータ連携を行うシステムとの連携を準備する活動です。
新しいシステムにおけるデータ連携(インターフェースと呼びます)の仕様をすり合わせ、新しいシステム・連携先システムそれぞれがその仕様に合わせてインターフェースを開発し、仕様通りにデータ連携ができるかを検証します。

システムリリース後もシステムトラブル発生時や機能改善の時に、連携先のシステムの担当者の方には協力していただく必要がありますので、この時から仲良くしておくとGoodです。
まとめ
システム構築フェーズのやることは、大きく6つの領域に分類されます。
- アプリケーション開発
 - インフラ構築
 - 運用保守
 - 移行
 - ユーザー教育
 - 他システム対応
 
それぞれの活動で必要なスキルや知見が異なるので、プロジェクトの体制を組閣する際は作業に合わせたメンバーの確保が必要になります。
より詳しいことが知りたい方は、私のバイブルである以下の大場さんの書籍を御覧ください。
この書籍にはプロジェクトをお客様視点・SIer視点両方から記載されており、全体像や具体的な成果物サンプル、運営方法が載っています。
私がプロジェクトマネージャー、統括プロジェクトマネージャーになった時もこの本の内容がとても役に立ちました。

より詳しく理解したい方にはおすすめです!
ゼッタイ失敗しない!驚異のプロジェクト実行術 準備編~始める前に押さえておこう(日経BP Next ICT選書) Kindle版
  
  
  
  

コメント