【エンジニア初心者向け】プロジェクトの意味・目的・流れについて

IT企業に入社し仕事をしていると「プロジェクト」という言葉が日常的に使われております。


しかし、
プロジェクトの意味・目的・流れを理解して仕事される方は以外と少ないのではないでしょうか?

本コンテンツでは初心者向けにプロジェクトの意味・目的・流れについて説明いたします。

プロジェクトとは

プロジェクトとは特定の目的(企業が抱える課題や問題の改善等)を達成する為の計画の事です。

例えば、IT業界のプロジェクト例を出すと、お客様の業務システムの老朽化に伴う再構築プロジェクトなどがございます。

※補足:プロジェクトマネジメントの標準的な知識体系を纏めているPMBOK(Project Management Body Of Knowledge)によると、プロジェクトには以下の2つの特徴がございます。

▼プロジェクトの要素▼

  • 独自性
定型化された業務でない事
事前に手順が確立されている作業や日常業務ではない事
  • 有期性
計画に明確な開始・終了の期間がある業務である事

プロジェクトの目的とは

プロジェクトの目的は「特定の目的(企業が抱える課題や問題の改善等)」を達成する事です。

上記の文書から分かる通り、特定の目的とは曖昧な言葉であり人ぞれぞれ解釈が異なってしまう為、各プロジェクトで必ず「特定の目的」を具体的に定義する必要がございます。

ポイント
目的が曖昧ということはプロジェクトの「成功の定義が曖昧」という事になります。そのような事にならないように、プロジェクト発足時に決めることが非常に重要です。一般的なIT業界のプロジェクトではお客様の業務システムの老朽化に伴う期日内での新システムの納品やドキュメントの納品・自社への利益貢献になるケースが多いです。

プロジェクトチームとは

プロジェクトの目的を達成する為に構成されたチームをプロジェクトチームと呼び、プロジェクトチームの人員をプロジェクトメンバーと呼びます。

プロジェクトメンバーは大きく分けると3つに分ける事ができます。

▼プロジェクトメンバーの種類▼

  • プロジェクトマネージャー
  • プロジェクトリーダー
  • プロジェクト担当者

上記のプロジェクトメンバーに関する詳細は以下にて1つずつ解説いたします。

プロジェクトマネージャーの役割

プロジェクトマネージャーはプロジェクトチームの責任者であり、プロジェクトの期日までに完遂させる責任を負います。
その為、プロジェクトマネージャーはプロジェクト全体の意思決定・予算管理・進捗管理・課題管理・リスク管理・品質管理・人員管理など実施し、プロジェクトを成功に導く必要がございます。

ポイント
プロジェクトマネージャーはPMと略される事が多く、プロジェクトの大黒柱です!

プロジェクトリーダーの役割

プロジェクトリーダーはプロジェクトマネージャーの補佐役であり、自担当領域の現場リーダーです。
一般的にはプロジェクトマネージャー配下には領域毎にチームを設ける事が多いです。

例えばネットワークチーム・サーバチーム・保守チームといったようにイメージです。
そのチームのリーダーがプロジェクトリーダーに該当します。

その為、プロジェクトリーダーは自担当領域の進捗管理・課題管理・リスク管理・品質管理・人員管理など実施し、定期的にプロジェクトマネージャーへ報告する必要がございます。

ポイント
プロジェクトリーダーはPLと略される事が多く、プロジェクトの縁の下の力持ちです!

プロジェクト担当者の役割

プロジェクト担当者とはプロジェクトリーダーの指示に従い、業務を遂行するメンバーです。

その為、プロジェクトリーダーより割り振られた各タスクを期日内に対応する必要がございます。

プロジェクトを成功させる為には

プロジェクトの目的を達成する為にプロジェクトマネージャーが筆頭となり、プロジェクト内のメンバーが同じ方向を目指し一致団結し、1つのゴールに向かうことが重要です。

プロジェクトの流れ

IT業界のプロジェクトの流れは以下の通りです。

▼プロジェクトの流れ▼

  1. 提案
  2. 要件定義
  3. 基本設計
  4. 詳細設計
  5. 開発・実装
  6. 試験
  7. 移行

上記の各フェーズに関する詳細は以下にて1つずつ解説いたします。

①提案

まず最初にお客様側が自社のITインフラの導入を外部のシステムインテグレーター(Sler)へ業務委託時に提案依頼書(RFP)を作成し、発注先候補のシステムインテグレーターへ提示いたします。

RFPにはITインフラ導入の目的・要件・条件が記載されており、システムインテグレーターはRFPをもとにお客様の要望を把握し提案書を作成します。

※提案書にはITインフラの提案内容・プロジェクトスケジュール・プロジェクト体制・費用などが記載しております。
その後、お客様側は各システムインテグレーターからの提案内容に基づき業務委託先を選定いたします。

提案フェーズのポイント

提案フェーズは今後のプロジェクトの遂行の中でも最重要フェーズです。もし、提案フェーズで曖昧にしてしまうと、後工程でトラブルになりやすい傾向がございます。特に「費用」に関わるITインフラ構成・プロジェクトスケジュール・契約条件・保守運用条件などに関しては認識相違がないようにお客様と同意することが重要です。また、ある程度お客様の要件変更に対応できるように「リスク費用」を考慮する事が重要です。

②要件定義

要件定義ではお客様からの要望をどのような構成で実現できるか、どのような技術要素が最適であるかを機能性、機密性、可用性、拡張性などを様々な観点から整理し方向性を明確にするフェーズです。

その後、要件定義書にてプロジェクト概要(案件概要・工期・スコープ範囲・役割分担)や要件内容・各要件内容の実現方法(システム構成・利用技術など)をドキュメント化いたします。

また、要件定義書は後工程である設計フェーズのインプット資料になる為、設計者・開発者観点の要素を踏まえて作成する事も重要です。

③基本設計

基本設計では要件定義書を参考にシステムの基本的な設計を実施し、基本設計書にて整理いたします。
基本設計書にはシステムの全体構成・物理設計・機能設計・ユーザーインターフェース設計・保守設計などが含まれます。

※基本設計に記載する内容は構築するシステムにより大きく異なります。例えば、システム開発案件であれば、利用者の操作画面やデータの入力・出力の流れなどを整理する必要がございます。また、ネットワーク案件であれば、IPアドレス設計や各ネットワークプロトコル設計などを整理する必要がございます

基本設計フェーズのポイント

基本設計フェーズではお客様にも理解しやすいようにシステム全体の「可視化」し、認識相違がないようにお客様へ確認する事が重要です。また、お客様側が必ずしもITのプロフェッショナルではないので、視覚的に分かりやすい資料を作成する事を意識しましょう!

④詳細設計

詳細設計では基本設計書の内容の実現方法(システムの内部的な設計)を実施し、詳細設計書にて整理いたします。
詳細設計書にはプログラムのフローチャート・各機器のパラメータシート・各システムとの連携方法などが含まれております。

詳細設計フェーズのポイント

基本設計書と詳細設計書は整合性が取れている事が非常に重要なので、方向性が正しいか確認しながら進めましょう。また、詳細設計書の内容をインプットに次工程で開発(プログラミング)や各機器の実装を実施いたします。その為、詳細設計書の内容を確認すれば開発・実装が出来るようなレベルまで掘り下げて記載する必要がございます。

⑤開発・実装

開発・実装フェーズでは詳細設計書の内容の参考にプログラミングや各機器の設定を実施し、実際にシステムを構築していくフェーズです。

⑥試験

試験フェーズでは開発・実装フェーズにて構築したシステムが実際にお客様の要件通り実装されているか、試験するフェーズです。

試験内容には大きく分けると4つ試験があり、各試験に関する試験計画・試験項目・試験手順書を作成する必要がございます。

▼各試験内容について▼

  • 単体試験
機器単体やモジュール単体で要件通りに動作しているか確認する試験
※開発・実装フェーズの品質を確認する試験であり、システムインテグレーターが実施する試験です。
  • 結合試験
複数の機器や複数のモジュール同士で要件通りに動作しているか確認する試験
※詳細設計フェーズの品質を確認する試験であり、システムインテグレーターが実施する試験です。
  • 総合試験
システム全体として要件通りに動作しているか確認する試験
※基本設計フェーズの品質を確認する試験であり、システムインテグレーターが実施する試験。
  • 受入試験
お客様の業務を踏まえて要件通りに動作しているか確認する試験
※システム移行前にお客様が最終確認する試験であり、お客様が実施する試験。



試験フェーズのポイント

試験フェーズの善し悪し次第で、システムの品質が大きく左右されます。その為、試験項目に漏れが発生すると後々大問題になるケースがございますので、必ず第三者のレビューを実施し試験観点に漏れが発生しないようにする事が重要です。

⑦移行

移行フェーズでは構築したシステムを実環境へ切り替えるフェーズです。

切替時には少なくとも通信断(お客様への業務影響)が発生する事が多い為、念入りに移行計画・移行設計を検討する必要がございます。

その為、移行方法・移行条件・移行体制を移行計画書や移行設計書にて整理し、お客様へ説明し同意頂く必要がございます。
また、移行時の進捗管理方法や詳細手順を移行手順書にて整理し、移行後の正常性判断基準や切り戻し判断基準を明確する事が重要です。

移行フェーズのポイント

移行作業は少なくともリスクがある作業になります。その為、移行リスクを最小限にする為にお客様のビジネスインパクトを踏まえ移行設計することが重要です。(例えば、移行順序はバックアップ拠点→メイン拠点の順で切り替えるなど検討いたしましょう。)

まとめ

いかがでしたでしょうか?

プロジェクトの意味・目的・流れについて理解した上で、業務を遂行するとより理解が深まると思います。
では、みなさまのプロジェクトの成功を心から願っております。