今さら聞けない！SEの上流工程と下流工程の違いを解説！
システム開発にあたっては、いくつもの工程を踏まなければなりません。大きく分けて、上流工程と下流工程があり、それぞれに細かな工程が含まれます。
SEとして活躍するならば、これらの工程は当たり前の知識として待たなければなりません。認識齟齬があると、トラブルにつながりかねないのです。今回はSEが今更聞けない、開発における上流工程から下流工程について解説します。
SEの携わる上流工程とは
最初にSEの携わる上流工程とはどのようなものであるのか理解していきましょう。
上流工程の概要
ソフトウェアエンジニアリングにおいて上流工程とは、ソフトウェア開発プロジェクトの初期段階を指します。定義は曖昧な部分がありますが、一般的には要件定義と設計が含まれます。
要件定義では、クライアントやステークホルダーからの要求を収集し、設計の準備をしなければなりません。これからシステムが達成すべき目的や機能要件・非機能要件の特定などが中心です。要件定義の内容が明確でなければ、開発チームが具体的に作業することができません。
また、設計では要件定義で収集した情報を基に、システムの詳細を定義します。システムの全体像を理解し、各部分がどのように連携して動作するかを詳細かつ明確にしなければなりません。設計フェーズの結果は、開発チームがどのようにシステムを構築すべきかを理解するための道しるべとなります。
上流工程のタスク例
続いて上流工程のタスク例を紹介します。
コンサルティング
コンサルティングは、クライアントのニーズを把握して、それに適したソリューションを提供する工程です。クライアントの状況を詳細まで把握して、課題を効率よく解決するためのツールやシステムを特定します。また、必要に応じて、クライアントがビジネスで成功するためのアドバイスを提供しなければなりません。
また、コンサルティングには、ソフトウェア開発プロジェクトの管理を含むことがあります。例えばリスクを評価したり、進捗状況を把握したりするのです。プロジェクトを成功させるために、必要な工程全般をコンサルティングと呼ぶこともあります。
なお、この専門的な作業は、SEではなくコンサルタントが担当するかもしれません。プロジェクトの規模に応じて、役割分担があると考えましょう。
要件定義
要件定義は、ソフトウェア開発において特に重要な工程です。これから開発するシステムが、どのような目的で作られ要求を満たすものであるのかを明確にします。また、クライアントのニーズが曖昧なものである場合、要件定義中に明確にしなければなりません。
また、要件定義の内容は後から参照する機会が多いものです。そのため、一般的には文書化されて、ステークホルダーの承認を得なければなりません。要件定義が不十分である場合、開発工程に悪影響を与えるため、責任の所在が重要視されます。
なお、要件定義では機能要件だけではなく非機能要件の洗い出しも必要です。こちらも、最終的には品質評価の指標となるため、事前に洗い出しておきましょう。
基本設計
基本設計は、要件定義で明確になった要件を踏まえて、システム全体の構造や主要なコンポーネントの設計をおこないます。例えば、システムアーキテクチャやデータベース、ネットワークなどの大まかな設計が基本設計に含まれるのです。
また、単体の設計だけではなく、既存システムとの連携なども定義されます。例えば、新しいシステムから既存のシステムに情報を連携する予定ならば、それについて設計しなければなりません。要件定義で明確になったすべての内容を網羅できるように、基本設計が進められます。
なお、基本設計についても最終的には文書化が必要です。後から見返せるように整えておかなければなりません。
詳細設計
詳細設計は、基本設計の内容をさらに細かく展開する工程です。具体的には、各コンポーネントの内部構造や動作を細かく定義します。アルゴリズムやデータ構造、インターフェースの設計などです。詳細設計まで済ませることで、それぞれのエンジニアは具体的な作業へ取り組めるようになります。
なお、詳細設計は実装するエンジニアが参照するものであり、ここに誤りがあると品質の低下を招きかねません。具体的な指示を含む部分であるため、抜け漏れがないように確実な設計が求められます。
見積もり
上流工程では、いくつかの場面で見積もりが求められます。ソフトウェア開発のコストや期間を予測して、クライアントと合意しなければなりません。
一般的に「見積もりはプロジェクトの最初に提示されるもの」と思われがちです。しかし、システム開発の現場では、フェーズごとに見積もりが実施されることがあります。これは要件定義や設計の過程において、見積もり内容が変化することがあるからです。
ただ、上流工程でどの程度見積もりするかについては、事前に合意しておきます。例えば、要件定義と設計で2回の見積もりをするなどです。
SEの携わる下流工程とは
続いてはSEの携わる下流工程について、どのような作業があるのか解説します。
下流工程の概要
ソフトウェアエンジニアリングの下流工程とは、開発ライフサイクルの後半部分を指します。例えば、開発やテスト、本番リリースなどです。本番リリースをしてからの保守についても、下流工程と呼ぶことがあります。
開発では、上流工程で作成された各種設計書を活用し、ソースコードなどを完成させます。また、ネットワークやミドルウェアの設定など、システムに必要な物は全般的に対応しなければなりません。
続いて、テストでは、作成したソースコードを中心に設計通りの動きであるかを確認します。テストの中にも細かな工程があり、それぞれの工程をすべてクリアしなければなりません。
システム全体でテストが完了すれば、最後は本番リリースです。開発するだけではなく、リリースまで済ませることで、やっとユーザーが利用できるようになります。
下流工程のタスク例
続いて下流工程のタスク例を紹介します。
開発
開発の工程では、エンジニアが設計書に基づいてソースコードを記述しなければなりません。適切に設計されていれば、使用するプログラミング言語やアルゴリズムなどが設計書に示されています。ただ、プロジェクトの進め方によっては曖昧な部分があるため、エンジニアがその都度フォローしなければなりません。
また、複数のエンジニアで開発することが多いため、開発に関するルールを定めることが一般的です。例えば、変数の命名規則や改行の使い方などが挙げられます。開発に参加するエンジニアは、必要に応じてこれらのルールを把握しておくのです。
さらに、開発の状況をトラッキングするために、バージョン管理システムを導入するケースがあります。Gitなどのツールが利用されるケースが多く、これらの使い方についても理解が重要です。単純なプログラミング言語のスキルだけではなく、関連するスキルも求められると考えましょう。
テスト
開発と関連の深い作業としてテストがあります。コーディング作業よりもテストに時間が取られるケースも多く、品質を担保するために避けては通れないものです。設計書の内容を踏まえて、その通りにプログラムが動作するかどうかを評価します。
テストにはいくつかの工程があり「単体テスト」「結合テスト」「総合テスト」「受け入れテスト」などと呼ばれます。ひとつのモジュールだけでテストすることから始め、最終的には全体のモジュールでテストしなければなりません。単体のテストでは問題がなくとも、複数を組み合わせることで問題が生じる可能性があるからです。
また、テストを実施するにあたっては、事前にテストケースの作成が求められます。設計書に沿ったテストケースを作成し、それに全て合格することでテストが完了したと判断するのです。最終的には、発見されたバグの数やその対応、総評などをレポートにまとめなければなりません。
本番リリース
本番リリースでは、テストが完了し問題がないと確認されたソフトウェアがクライアントに提供されます。リリース前には、リリースノートの作成や最終的な確認作業などが必要です。また、リリース管理ツールを使用して、リリースのスケジューリングやトラッキングが求められることもあります。
リリース後は、ユーザーからのフィードバックの収集と分析が必要です。そして求められる場合には、バグ修正や機能改善、新たなリリースの準備などにも対応しなければなりません。
運用
厳密にはシステム開発の工程には含まれませんが、本番リリースが終わった後には運用作業が待っています。システムは、定期的にメンテナンスしなければ問題が発生しかねません。そのため、本番リリースだけで終わることはほぼなく、運用も求められるのです。
とはいえ、具体的な作業内容は状況によって大きく異なります。ほとんど作業がないこともあれば、定期的にデータ登録などの作業が発生することもあるでしょう。ユーザーからの問い合わせが多く、細かな運用が求められる可能性もあります。
運用には、開発やテストで作成された資料や運用手順書などが必要です。これらの作成も、システムの開発プロジェクトに含まれていることが大半です。上記でタスクとしては紹介していませんが、エンジニアは運用も意識しなければなりません。
上流工程と下流工程の違い
上流工程と下流工程には大きな違いがあります。具体的な違いについて3つの観点から解説します。
作業の実施時期
上流工程はソフトウェア開発プロジェクトの初期段階でおこなわれます。例えば、要件定義やシステム設計などは、開発プロジェクトの初期に実行される作業です。
それに対して、下流工程はプロジェクトの後半部分で実施されます。例えば、コーディングなどの実装、テスト、保守などです。これらのフェーズでは、上流工程で設計されたシステムを具体的に実現することが求められます。実施時期も内容も大きな違いがあると理解してください。
また、下流工程の作業は、運用など開発プロジェクトが終わった後にも影響を与えます。時には、運用が始まってから問い合わせが来ることもあり、そのような意味でも作業の実施時期や影響範囲が違うと考えて良いでしょう。
目的
上流工程の目的は、システムの要件を明確にし、設計書を作成し完成させることです。これにより、開発チームは何を開発すべきか、どのように開発すべきかを理解できます。また、上流工程では、システムの概念的な構造や動作を定義しなければなりません。
一方、下流工程の目的は、設計されたシステムを具体的に実現することです。また、その品質を継続的に確保することも求められています。システムの継続的な改善や更新についても、下流工程の目的だと考えて良いでしょう。
成果物
上流工程の成果物には「要件定義書」「設計書」「プロジェクト計画」などがあります。これらの文書は、システムの目標や設計を明確にし、開発チームが共通の理解を持つために重要な資料です。
一方、下流工程の成果物には、ソフトウェアのコード、テストケース、テスト結果、バグレポート、リリースノートなどがあります。これらの成果物は、システムが設計通りに機能し、品質が確保されていることを示すものです。また、これらの成果物は、システムの継続的な改善や更新にも役立ちます。
まとめ
SEが理解しなければならない、上流工程と下流工程について解説しました。働き方によっては、一部の工程にしか携わりませんが、SEとして全ての工程を理解しておきましょう。
上流工程と下流工程には大きな違いがあり、これが時期や成果物などに影響を与えます。認識を誤っていると、大きなトラブルに繋がりかねないため、必ず正しい認識を持ちましょう。
なお、ここでは全ての作業をSEが担当するように表現していますが、開発については「プログラマー」が担当するケースが大半です。SEとプログラマーは、別の役割であると考えることもあるため、その点は注意するようにしてください。
