一般的なシステム開発のプロジェクトは、上流工程と下流工程といった2つのプロセスに分けられます。上流工程とは、簡単に説明すると、開発を受注してから作成するシステムの全体像を決定する工程です。
システム開発では上流工程の質が、下流工程の効率を大きく左右します。しっかり上流工程で決めておくべきことが決められていないため、下流工程で大きな手戻りが発生してしまい、採算やスケジュールに大きな影響を与えてしまった、なんてことは少なくありません。当記事では、そんな上流工程の概念・業務の流れ・業務のポイント、ならびに下流工程との違いやその概要について解説しています。
上流工程について理解を深めたい方は、ぜひ参考にしてみて下さい。
上流工程とは
上流工程とは、一般的なシステム開発で採用されているウォーターフォール・モデルにおいて、初期段階に位置する工程のことです。ウォーターフォール・モデルとは、開発までの工程が、上流から下流へ流れるように進んでいることが名称の由来となっています。
上流工程では、作成するシステムの内容・スケジュール・予算といったプロジェクト全体に関わるプランニングを行います。
上流工程は、プロジェクト全体の推進や成否から、システムのクオリティをも左右するため、非常に責任が重く重要な役割を担っていることが特徴です。
下流工程との違い
システム開発の上流工程と下流工程では、具体的にどのような違いがあるのでしょうか。以下に、上流工程と下流工程の違いについてまとめました。
|
上流工程の流れ
ここでは、システム開発の上流工程が行う業務の流れと、それぞれのプロセスで行われる業務についてご紹介します。上流工程がどのように進められるか、確認しておきましょう。
コンサルティング（企画）
上流工程では最初に、システム開発を行いたいクライアントに対して、コンサルティングを行います。現状の課題や、システムに求めるニーズをヒアリングします。
クライアントの課題を整理し、解決するための方針をまとめていくのがコンサルティングフェーズですが、クライアントの細かい要求まで理解したり、専門的な内容をかみ砕いて説明したりする必要があるため、知識・経験が豊富なITコンサルやITエンジニアがコンサルティングを担当するのが一般的です。場合によってはコンサルティングに特化した企業に依頼することもあります。
システム開発では、クライアントニーズを満たすことが最も重要です。いくら高品質・高機能なシステムを開発しても、顧客視点が抜けていては意味がありません。そのため、初期段階のコンサルティングでは、きめ細やかな折衝を行って持ち帰った情報を基に、クライアントが満足するシステム開発の提案を行うことが重要なポイントとなります。
提案内容についてクライアントの合意を得たら、次の要件定義のフェーズに移ります。
要件定義
要件定義とは、システムに求められる要求を実際に実現できるように、必要な要件や範囲を明確に決定していく工程のことをいいます。
要件定義では、システム・ソフトウェアに搭載する機能を網羅した機能要件と、性能・使用性・メンテナンス性などの非機能要件について、予算との兼ね合いを考慮しながら要件定義書に記述します。
要件定義を基にシステムの設計が進められるため、要件定義書が完成したらクライアントの合意を取る必要があります。
基本設計
基本設計とは、要件定義で決定した内容に基づき、システムの全体像を設計することをいいます。具体的には、ソフトウェア・ハードウェア・インフラ・データベース・ミドルウェアの構造・構成やシステムに搭載する機能・仕様や操作・入出力に関する要件などを設計します。
システムの操作画面・操作方法・データ出力方法などユーザーから見える部分を主に設計することから、外部設計とも呼ばれています。
基本設計のフェーズと次の詳細設計のフェーズは、システムの完成度・品質・有用性から実際にシステムを構築する下流工程の業務推進にまで大きく影響するため、上流工程の中でも、特に重要度が高いフェーズです。
基本設計については、以下の記事でも詳しく解説しております。
外部設計書と内部設計書の違いとは？作成ポイントまで解説！
見積り
上流工程では、システム開発プロジェクト全体のコストを見積もることも重要な業務のひとつです。システムの規模・仕様・要件・開発工程などから、専門的な手法も活用しながら正確なコストを導き出します。
要件定義を行い、基本設計で作るシステムの全体像について合意が取れた段階で、詳細設計以降の費用を再度見積を行います。要件定義や基本設計は作るものを決める工程なので、これが終わらないとその後の工程を見積もることができません。
ですので、提案時点では概算金額を提示し、正式な開発費用は基本設計後の再見積もりで決定します。
見積もりを見誤ると、想定外のコストが発生して予算オーバーをしたり、追加コストの負担を巡ったトラブルが発生したりする恐れがあるため、なるべく正確なコストと工数を見積もることが重要となります。
詳細設計
詳細設計は、内部設計とも呼ばれています。基本設計で決定した内容に基づき、ユーザーからは見えないシステムの内部まで、詳細に設計を行う工程です。
詳細設計では、システム内部の細かい機能・動作に至るまで、実際にプログラミングができるレベルまで詳しく設計書に落とし込みます。後のコーディング作業やシステムのクオリティに大きく影響するため、完成度の高い設計を行うことが非常に重要となります。
システム開発の詳細設計については、以下の記事でも詳しく解説しております。
【内部設計について徹底解説！】設計要素やポイントは？
下流工程の流れ
下流工程とは、上流工程で完成された要件・設計を実際に形にする工程です。下流工程の基本的な流れは「開発」「テスト」「納品」となります。
大規模な開発プロジェクトでは、Sler（システムインテグレーター）に該当する大企業が上流工程を行い、外部の中小システム開発会社が下流工程をSIerから請け負うケースが多く見られます。
ここでは、下流工程で行う「開発」「テスト」「納品」という工程についてそれぞれ解説します。
開発・製造
開発プロセスでは、上流工程が決定した要件定義書・仕様書・設計書に基づき、実際にプログラミングを行うコーディングの工程です。コーディングは多大な時間とリソースが必要な作業であるため、多くのプログラマが分業・協業して、スケジュールに従いコーディングを進めていきます。
開発プロセスは下流工程の中心とも言える業務であるため、上流工程が求める要件をいかに忠実に再現できるかが重要なポイントです。
テスト
テストのプロセスは、開発工程で作成したシステムが機能要件を満たしているか、仕様・設計通りに正しく動作するか確認を行なうプロセスです。テストには、大きく分けて以下の3種類があります。
|
システムテストを済ませた段階で納品可能な状態であれば、クライアント主体の受け入れテストへと進むのが一般的な流れです。
納品
納品のプロセスは、テストを済ませて納品可能となったシステムを、実際の稼働環境へ移す作業が行われるプロセスです。
既存のシステムを新しく開発した場合は、旧システムから新システムへの切替を行い、完全に新規開発したシステムの場合は用意された環境へシステムの導入を行います。
納品の手順には、特定のタイミングでシステム全体を一気に移行する方法や、機能単位ごとに徐々に移行する方法など複数の方法があるため、上流工程の指示に従って納品を実施します。
上流工程のポイント
システム開発のプロジェクトの成否や完成するシステムのクオリティなど、上流工程の作業はプロジェクト全体に影響するため、その責任は重大です。
ここでは、クオリティの高い上流工程を行うためのポイントについて解説します。上流工程の成功、ならびにプロジェクト全体の成功を目指すためにも、ぜひ参考にして下さい。
クライアントと綿密なコミュニケーションをとる
システム開発は、先述した通り、クライアントの要求をできる限り実現することが目的です。まずは、クライアントと綿密なコミュニケーションを取り、確実かつ詳細に要件を汲み取ることが重要といえます。
クライアントは、システム開発の専門家では無いため、上手く説明できない要件があることにも留意して、可能な限り認識の齟齬が無いようにヒアリングを行うことがポイントとなります。
仮に開発側とクライアント側に認識の齟齬があった場合は、開発の後戻りや意図しない仕様変更の発生を招き、納期遅延・コスト増大・関係悪化などさまざまなリスクが発生する恐れがあります。
そのため、プロジェクト成功とリスク回避のためにも、プロジェクト着手前のコミュニケーションでは絶対に妥協してはいけません。
上流工程を担当する企業は、ヒアリングした内容を基に要件を整理して、クライアントニーズを最大限満たせる上質な提案を行いましょう。
実現性を考える
いくらクライアントときめ細やかなコミュニケーションを取ってヒアリングを行っても、要求された要件が実現不可能な仕様である場合があります。
このようなケースは受注段階では珍しくなく、安易に受注してプロジェクトを立ち上げてしまうと、大きなトラブルやプロジェクト失敗の原因となります。
上流工程を担当する企業側は受注を決定する前にクライアントの要求を慎重に精査する必要があり、実現性・適合性が無いと判断した場合は、クライアントにはっきりと伝えるべきです。
上流工程は、敢えて伝え難い内容をクライアントに伝えることも、システムのクオリティ担保やプロジェクト成功のためには必要であることを認識しておきましょう。
設計書の標準化を図る
設計フェーズは上流工程のなかでも重要なフェーズですが、現代においても設計書の作成には共通の基準が存在しないため、作成するシステムエンジニアによって作成方法・表記・仕様はバラバラです。
このような状況は属人化と呼ばれており、作成者しか内容が分からなかったり業務が人に依存したりといった問題を引き起こすため、プロジェクト進行を阻害する大きな原因となっています。
そのため、不要なトラブルを提言してシステム開発のプロジェクト全体をスムーズに進行するには、設計書の標準化を行い、各種設計書の作成方法や品質を統一することが非常に重要なポイントとなります。
幸い、近年では設計フェーズの業務標準化・業務効率化に役立つ優秀なツールがリリースされています。設計業務の効率化や属人化解消の課題を抱えている場合は、専用ツールを導入して設計書の作成・管理を行うことで、多くの課題を解決することが可能です。
まとめ
システム開発のプロジェクトにおいて、上流工程はシステムのクオリティやプロジェクトの成否を左右する重要なポジションであることをお伝えしてきました。上流工程のプロセスのなかでも、要件定義で決定した内容から各種設計書を作成する設計フェーズは特に重要であり、下流工程を担当するメンバーの業務内容から成果物にまで影響を与えます。
