上流工程はプロジェクト成功の要！SEなら押さえておきたい内容を完全網羅！

「システム開発は、プログラミング工程が一番重要！」と思っていませんか？たしかに、プログラムコードはシステムそのものなので重要なのですが、プログラミングの前段階の上流工程と呼ばれる工程も、非常に重要です。

ここでは、上流工程とは何か、上流工程ではどのような作業をおこなうのか、上流工程のポイントなどについて詳しく解説しましょう。

1.　上流工程とは

上流工程とは、プログラミングの前段階の、企画工程、要件定義工程、各種設計工程、計画立案などの工程を指します。その後のプログラミング工程とシステムテスト工程のさらに後の、ユーザーテスト工程、納品、運用・保守工程を上流工程と定義する考え方もあります。

システムそのものであるコードプログラミングが下流工程で、そこから離れてクライアント側に近いほうが上流工程という考え方です。システム開発は、システムそのものを作り込むプログラミング工程がもっとも重要と考える人もいるでしょう。

たしかにその考え方も間違いではありませんが、その前段階の上流工程がしっかりしていないとプログラミング工程はうまくいきません。わかりづらく抜けや漏れ、ミスがある企画書や要件定義書、設計書を作れば、当然プログラミング工程でバグを混入させてしまいます。

しかも、上流工程でバグを作り込んでしまうと、同じ処理を多くの個所で使うことが多いため、修正範囲が広くなり、影響が大きいため大問題です。もちろん、テストでバグを見逃したり納品時にミスを起こしたりすることでも、クライアントに与える影響は大きいものがあります。

このように、上流工程はシステム開発全体の品質を決めるうえで、非常に重要な工程といえるのです。次に、上流工程と下流工程は何が違うのかについて解説しましょう。

上流工程と下流工程の違い

下流工程とは、最初の上流工程の後のプログラミング工程や、システムテスト工程のことを指します。名前の付け方が上流、下流とありますが、上流のほうが上で下流は下などという上下関係などは、もちろんありません。どちらのほうが大事ということもなく、どの工程もなくてはならない重要な工程です。

ただし、親会社がクライアントから案件を受注して上流工程をおこない、下流工程のプログラミングは子会社、孫会社が担当というケースも多く見受けられます。この場合、元請け、下請けという意味では、上下関係があるケースも珍しくありません。

大規模システム開発の場合、上流工程と下流工程をわけて、それぞれ会社や担当者が分担して担当することが多いですが、これには大きな意味があります。

上流工程では顧客との交渉や問い合わせが必要ですし、開発全体の品質管理やスケジュール管理など、システム開発作業以外の作業も担います。これらの作業はプロジェクト全体を見通せる立場の担当者が上流工程としてまとめておこなったほうが、作業内容も近くやりやすいため、効率的です。

そして、プログラミング技術が高い会社や担当者が下流工程を担うことで、与えられた設計書を元にプログラミングに専念できます。このように、上流工程と下流工程に工程をわけることは、品質を高め生産性を向上するために、大きな意味をもつのです。

2.　上流工程でおこなう作業

上流工程でおこなわれる作業について、詳しく解説していきましょう。

①システム企画

クライアントから案件を受注し、どのようなシステムを構築するかを企画します。具体的な作業としては、クライアントからの案件をヒアリングして企画書を作成し、画面構成や入出力仕様、機能などについて詳細に詰めていきます。

システム要件の詳細が決まると、予算の見積もりを行います。システム要件の規模や難易度を元に、作業内容と必要人員、納期の見積もりをおこない、予算見積もりが決まります。

そして、システム要件と予算見積もりをクライアントに確認いただき、OKが出れば正式受注です。詳細な作業見積もりをして人員を集め、計画を立案します。ここで予算と納期、スケジュール、全体のシステム要件が決まるので、非常に重要な工程です。

②要件定義

企画書を元に、要件定義書を作成します。どのような画面にするか、ボタンやフォームはどこに置くかなどの画面設計、どのような入出力項目が必要かというデータ設計など、すべての要件を形にします。

たとえば、名前、電話番号、注文内容を入力してもらう注文管理システムなら、これらの入力項目やデータ項目が必要です。ここで定義した要件以外は、次以降の工程に降りていかないのでシステムとして形になりませんし、ここでミスすると、そのままシステムに混入します。

もちろん、どの工程でもミスが混入すれば後工程に影響をおよぼしますが、早い段階でミスを混入させるとより影響範囲が広くなってしまうので、要注意です。

③基本設計

要件定義書を元に、基本設計をおこないます。要件をシステムにするために必要な内部データの定義やデータベース設計、画面の内部設計などを決めます。たとえば上記の注文管理システムの場合、名前と電話番号を管理する顧客データベースと注文履歴データベースを定義します。

そして、内部データとして顧客のキー項目を定義し、顧客データベースと注文履歴データベースと紐づけます。このように、要件定義書を元に内部の基本設計を決めていきます。

④詳細設計

基本設計を元に、よりプログラムに近い詳細な設計を決めていきます。画面に入力した名前と電話番号をデータベースから検索し、どのデータ項目をもってきて画面に表示するのかなど、詳細な設計をおこないます。

ほぼプログラミングの流れや内容を言葉で表したものが、詳細設計書です。また、内部的なサーバー構成やネットワーク構成なども、必要に応じて設計します。

3.　上流工程でのトラブルを防ぐコツ

上流工程での作業は、非常に重要なものばかりであることがわかっていただけたと思います。そんな重要な上流工程でトラブルを防ぐためにはどうすればよいか、そのコツについて解説しましょう。

クライアントの要望を細かくヒアリングする

企画工程でクライアントの要望を細かくヒアリングするのは、非常に重要なポイントです。クライアントはITのプロではないので、どんなシステムが必要かぼんやりとはわかっていても、細かい仕様まで詳しく指定できません。

そのため、たたき台を作ってクライアントに見せる、細かい要望をヒアリングで聞き出すなどのヒアリング技術が重要です。作ってはみたものの、「この画面は使いづらい！あの機能が足りない！」などということになれば、大きな手戻りになってしまいます。

そうならないよう、クライアントの要件を詳細なヒアリングで最大限に引き出して仕様を細かく確認することで、システム開発全体の方向性が決まります。

仕様書には具体的な指示を示す

仕様書は、具体的に記述することが重要です。ぼんやりとした指示しか書いていないと、後工程の担当者が、そのぼんやりとした仕様書から好き勝手に解釈して作り込んでしまいます。その結果、「指示したかった内容と違う！」という結果になる可能性は高くなってしまいます。

たとえば、「顧客データを定義して格納する」という記述からは、顧客データとは名前と電話番号だけなのか、住所はどうなんだ、などという混乱を生みます。正解が「名前と生年月日と電話番号」なのであれば、そう記述すべきです。

システム開発には「後工程はお客様」という考え方があります。後工程の担当者がお客様だと思って、仕様書をわかりやすく丁寧に記述する必要があるのです。

4.　まとめ

この記事では、システム開発における上流工程とは何か、下流工程とは何が違うのか、上流工程で重要なポイントは何かについて解説しました。

上流工程はシステム開発全体を決める、非常に重要な工程です。下流工程ももちろん重要ですが、上流工程がしっかりできていないと下流工程もうまくいきません。上流工程の重要なポイントを理解することで、効率的に高品質なシステム開発につながるでしょう。