コラム

  • 2021.08.26
  • 開発
  • #上流工程
  • #基礎知識

上流工程とは 4つの流れと下流工程を意識しておさえておくべきポイントについて解説

上流工程とは

システム開発をフロー化したときに前半部分(システム企画~詳細設計)にあたる工程を指す言葉で、システムの構想や開発計画・設計を行うフェーズです。
システムにおける土台の部分なので、ここでしっかりとした土台をつくっておかないと、組込みをした際に状態が維持できなくなります。
具体的には、下流工程にフェーズが移ってから作成する画面の項目名や桁数の判別ができなくなったり、機能に仕様変更が入ったとしても反映できているかどうかが不明になったりします。また、仮に機能が作成できたとしても、該当の機能が正しく動いていることの証明ができなくなり、品質の保証が不可能になります。

開発を行うにあたって成功のカギを握るのは、この上流工程にあるといっても過言ではありません。上流工程は主に次の4つの工程を含みます。

テスト計画入門動画

4つの主な上流工程

4つの主な上流工程のイメージ

システム企画

企業が掲げるIT戦略に基づき、関係部署において方針に適した情報化の企画書(またはシステム開発計画)を作成します。
「超上流工程」などと呼ばれることもあります。
完全に内製化した社内開発でない限り、多くが開発をアウトソースするため、委託先の開発ベンダー側から見ると要件の源泉になる部分となります。

要件定義

主に、これからシステム開発を推進していくうえでの要望を整理する工程です。

● 顧客がどのようなシステムを欲しているのか
● そのシステムでどのようなことを実現したいのか
● どんな機能を実装したいのか、どのような性能を求めているのか

顧客側で、「システム化するために必要な情報の一覧」の作成ができない場合、開発ベンダーやテスト会社が代行することもあります。顧客の業務フローが可視化されていない場合はここで作成しておきましょう。
また、この段階で要求に対するシステム化の実現性の判断や交渉も可能な限り行います。後工程の作業のために「トレーサビリティマトリクス」を作成しておくことをお勧めします。
※トレーサビリティマトリクスとは:要件がどの工程でなんの成果物に落とし込まれていくのかを可視化した資料。作成しておくと仮に要件の変更が発生したとしても、どの成果物に影響を与えるのかが明確になり、管理が容易になります。

基本設計

前工程で作成した要求の一覧や業務フローを基にシステム化を行う部分として必要になる機能を一覧化したり、入出力に関する項目(画面や帳票の一覧・遷移図・項目定義・データベースのERやテーブル定義など)をとりまとめたりします。
ここではその名のとおり、システムの土台となる基本的な仕様をまとめていきます。
他のシステムとの連携項目がある場合は、他システムインタフェースも入出力項目に入ってきます。あとの工程に要件がしっかりと反映されるよう、どの要件がどの画面・帳票に反映されるのか関係性のチェックを行うとあとの抜け漏れ対策になります。

詳細設計

基本設計で作成した成果物を基に、機能の実現性を考慮しながらプログラム単位の設計書を作成します。
例えば、
「商品名を入力して検索できるECサイトをつくりたい」
といった要件における基本設計では、
「TOPページと検索結果のページの画面や商品の在庫を扱うデータベースが必要」
になるため、一覧や画面イメージ・データベースのテーブル基本設計を作成し、詳細設計で
「TOPページで検索の語句を入力後、検索ボタンを押された時のプログラムの動き」
を設計するものになります。
検索の動きとして、2つの考え方があるとします。
①「全データを取得してプログラムの中で対象データを抽出する」と設計するのか
②「対象のデータをSQLで抽出してきて結果を画面に出す」と設計するのか
「結果の表示はどちらも変わりないが、求められる性能として①は〇秒以上レスポンスがかかることが想定される。そのため②の『対象のデータをSQLで抽出する』を設計する」といった考えが実現性の考慮の一例となります。
また、使用者が開発者の意図しない動作をシステム上で行った際のエラーハンドリングも、このフェーズで設計することが多いです。

テスト計画入門動画

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

上流過程にはクライアントが実現したい要件の洗い出し、全体機能の設計業務や全体機能を実現するうえで重要な部分機能のアーキテクチャ決定や入出力(画面やDB・他システム)の設計が含まれます。いわゆる方針や方法の決定です。
下流過程では決定した要件定義に基づき、落とし込まれた各種設計を参照し、コーディング(準備を含む)と動作確認のための各種テストを行っていきます。

ウォーターフォールモデルの説明図

(画像転載元:http://sysdev.sakura.ne.jp/development/169)

上流工程で押さえておきたいポイント

テストを視野に入れて、上流工程を考える際には押さえておきたいポイントがあります。
それは、「テストで確認できる期待値が明確になっているか」を基準に上流工程を見ることです。
改めておさらいすると、各工程においてテストを実行する際には「何を確認したいのか」を考えてみてください。
よく言われる「V字モデル」がわかりやすいと思うので記載します。

V字モデルの説明図

1.要件定義 ⇔ システムテスト
要件定義では顧客が業務(フロー)に沿って実現したいシステムの要望を出しました。
⇒システムテストで機能要件・非機能要件に着目しテストを行うことで、上記の要望どおりのシステムが完成しているかを確認します。つまり、要件定義では顧客の業務に沿った要望がちゃんと出し切られているかを点検する必要があります。
2.基本設計 ⇔ 結合テスト
基本設計ではシステムでの表示系項目やデータの連携を含めた入出力の設計を行いました。
⇒結合テストで入出力項目・他システム連携項目・画面表示に着目しテストを行うことで、上記の要望どおりのシステムが完成しているかを確認します。つまり、基本設計では業務フローから落とし込まれた必要画面や、他システムとの連携項目に過不足がないかを点検する必要があります。
3.詳細設計 ⇔ 単体テスト
詳細設計では単一機能における詳細なプログラム動作の設計を行いました。
⇒単体テストで単一機能として要件から落とし込まれた内容が含まれているかに着目しテストを行うことで、要望通りの機能ができているかを確認します。

詳細設計では要件の内容がしっかりとトレースされているか、適切なエラーハンドリングが想定されているか等を点検する必要があります。

テスト計画入門動画

下流工程でトラブルになりやすい上流工程の失敗パターン

上流工程が原因で進捗が滞る案件は、以下の理由が原因である確率が高いといえます。
●顧客から要件を出し切れていない
●顧客の要件を何でも聞き入れすぎて、当初想定していたシステムからの乖離が激しく立ち行かない
●要件に変更が加わった際のコントロールができていない
さらに、以下の内容が整理されていないことが多く散見されます。
●要件の管理方法や台帳
●変更に関する管理方法
いずれも事故を未然に防ぐ手立てがそろっていないせいで下流工程にて不具合が頻発し、相当の手戻り工数を強いられるパターンです。
上記でトレーサビリティマトリクスに触れましたが、その成果物をうまく活用すれば防げた可能性が高いものばかりです。また、仮に変更が発生したとしても、元々のスコープに関係する話なのか、追加の要望なのかといった影響範囲も明確にできるため推奨したいところです。
手戻りのコスト影響やシステムリリース影響、顧客の業務影響との相談はもちろん必須になりますが、要件が明確になっていないまま推進している時には、プロジェクトを一度ストップさせる勇気も必要になります。
当コラムの内容を踏まえ、こうしたことが起こらないよう、未然に防いでいくことが大事です。

資料ダウンロード/動画視聴

仕様書インスペクション 講座

ソフトウェアテスト入門動画

テスト計画入門動画

SHIFTサービス資料

関連サービス