システム開発の要となる上流工程の流れや下流工程で失敗しないためのポイントを解説

システム開発の成否を決める上流工程

上流工程ではクライアントとのヒアリングを通して「どのようなシステムを開発したいのか」など、仕様や要件を決めることになります。

基本的に、上流工程の決定に従ってコーディングなどの下流工程は進められます。下流工程でシステムの不具合といったトラブルが生じた場合、上流工程に原因があることがほとんどです。

例えば、クライアントが要求した機能やシステムと連携が取れていないなどの性能が不足している問題の原因は、上流工程でクライアントとのヒアリングが足りていない、もしくは要件定義での不備などにあります。

クライアントの要求を汲み取れないままシステム開発を進めると、手戻りや作り直しといった事態を引き起こします。その結果、コストの増加や納期の遅れが生じ、最悪の場合、プロジェクト自体が頓挫してしまうかもしれません。それだけに、上流工程はシステム開発の成否を決める重要な工程の一つといっても過言ではありません。

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

システム開発全体の方向性を決める上流工程では、開発全体をフロー化したときに前半部分(システム企画～詳細設計)にあたる工程を指し、システムの構想や開発計画・設計を行うフェーズです。

クライアントへのヒアリング、要求をまとめてドキュメントを作成、システム開発にかかる予算の見積もりといった作業が行われます。この土台をしっかり作っておかないと、組込みをした際に品質が維持できなくなります。

下流工程にフェーズが移ってから作成する機能に仕様変更が入ったとしても反映できているかどうかが不明となり、該当の機能が正しく動いているかの品質の保証が不可能になります。

クライアントが実現したい要件の洗い出しや抱えている課題を解決するために必要な機能など、システムの全体像を把握する工程になります。

全機能の設計や機能を実現するために必要な部分機能のアーキテクチャ決定、入出力画面やDBの設計など、方針や方法を決定するシステム開発の基礎となる部分なので、これを基にこの先の下流工程は各種設計を参照し、コーディング(準備を含む)と動作確認のための各種テストへ進んでいきます。

下流工程では上流工程で固められた仕様や要件に従い、開発から納品までを担いますが、仕様や要件を形にしなければならないことから、次のようなスキルが求められます。

• プログラミング能力
• コミュニケーション能力

プログラミングがメインの作業となるため、コミュニケーションは不要と思われがちです。しかし、多くの場合、ひとりで作業をするわけではないので、最低限のコミュニケーション能力は身につけておく必要があります。

システム開発における上流工程の主な流れ

システム開発の上流工程について、基本的な流れを確認しておきましょう。上流工程は、次のような5つの流れで行われます。

1. システム企画
2. 要件定義
3. 基本設計
4. 詳細設計
5. 見積作成

以下でシステム開発における上流工程の流れについて解説します。

1.システム企画

システム企画では、クライアントがシステムに何を求めているのかを洗い出す作業が行われます。

• 既存システムの何が問題なのか？
• 新システムに何を望んでいるのか？
• どのような問題や課題を抱えているのか？
• 新システムはどのように業務に使われるのか？

など、などの要求を洗い出し、どのようなシステムが求められているのか、クライアントのニーズをドキュメントに盛り込み、可視化します。

ここでクライアント側のニーズを正確に把握するためにヒアリングをしっかり行い、システム化の対象となる業務を分析し、システム開発の方向性を決定していきます。システム企画はシステム開発プロジェクトにおける最初の工程です。

一般的に、システム企画は以下の流れで進められます。

1. システム開発の計画を立てる
2. 解決すべき問題の洗い出し
3. 現状の調査と分析
4. システム開発の目的を設定
5. システム企画書を作成・決裁
6. 提案依頼書（RFP）の作成
7. システム開発会社の選定・契約

どのようなシステムを求めているかを明記した「提案依頼書（RFP）」を作成することで、開発側とクライアント側の認識のすり合わせがしやすくなります。

このシステム企画の工程中に、概算スケジュールやコスト計算を同時に行うケースも多いです。クライアントの要求や課題を正確に把握し、望ましいシステム方式や目標品質といった開発方針決定、システム開発にかかる予算や期間をまとめるといった作業が行われます。この段階で失敗すると、以降の工程に多大な影響を与えるため慎重に行われなければいけません。

システム企画は完全に内製化した社内開発でない限り、多くが開発をアウトソースしていくため、委託先の開発ベンダーとの認識すり合わせが大切です。

2.要件定義

要件定義では、主に次のことが行われます。

• 開発側とのヒアリングでニーズの調査と分析
• クライアント側の要求を実現可能な形で落とし込む
• 機能要件・非機能要件をまとめる
• システムの構成を決定する
• 要件定義書を作成する

クライアント側はシステム開発を依頼する際、開発側に自社の業務を理解してもらう必要があります。どのような業務で使われるかを明確にすることで、開発側もシステムの全体像をイメージしやすくなります。 クライアント側で、「システム化するために必要な情報の洗い出し」ができない場合、開発ベンダが代行することもあります。

この段階で、クライアントの要求に対してシステム化の実現性の判断や交渉も検討し、各機能ごとに詳細を細分化し、それらを実装してもシステムにバグや不具合が生じないように実装する機能を定義づけします。

▼要件定義については、下記の記事もぜひ参考にしてみてください。
→https://www.co-well.jp/blog/system_dev_RequirementDefinition

3.基本設計

基本設計では、要件定義書をもとに機能要件と非機能要件を決めます。ユーザーインターフェースやセキュリティ面など、ユーザーの目に触れる部分の設計であるため「外部設計」とも呼ばれています。

要件定義の段階で作成したドキュメントをもとに、システム化に必要な機能の一覧化、項目定義やデータベースのERやテーブル定義など入出力に関する項目をまとめるといった、システムの基礎となる仕様が決められます。

4.詳細設計

これまでの工程で定義されたシステムの機能等を、さらに詳細に定義する工程です。基本設計とは違い、クライアントの目に見えない部分の処理になるため「内部設計」とも呼ばれます。 内部設計では、実装する機能にバグや不具合等が生じないように、慎重に確認しながら進める必要があります。

基本設計で作成されたドキュメントを基に、クライアントの要求通りの機能の実現性を検証し、実装可能かを判断し、プログラム単位の詳細設計書を作成します。

このフェーズで、ユーザーが開発側の意図しない動作をシステム上で行った際のエラーハンドリングも考慮しておきます。

▼詳細設計は、こちらを参考にしてみてください。
→ソフトウェア設計に欠かせないスキルや設計の工程、設計書に必要な項目まとめ

5.見積作成

要件定義の時点でクライアントがシステム開発にかけられる予算との兼ね合いについても認識合わせを行う必要があります。主に開発コストはシステムの規模と必要工程によって決まります。

開発するシステムの仕様や要件などから、どの程度のコストがかかるかを算出し、基本設計や詳細設計でシステムの全体像を明確にした段階で見積を作成し、クライアントの合意を得られたら下流工程に進みます。

見積では開発環境や工数によって「類似法」「WBS法」「LOC法」といった手法が使われます。スケジュールや開発現場の状況などを総合的に判断します。

当初の見積り金額と実際の見積り金額に差が生じると、コストオーバーなどからトラブルを引き起こす恐れがあります。そのような事態を防ぐためにも、正確なコストや工数を見積もる必要があります。

システム開発の下流工程でトラブルになりやすい上流工程の失敗パターン

システム開発において、上流工程は重要な位置づけにあります。上流工程を疎かにしたためにシステム開発の下流工程でトラブルが生じやすいのは、「顧客から要件を出し切れていない」という根本的な理由以外では、以下のことが原因であるケースが多いです。

• クライアント側の要望を聞き入れすぎしまい、当初予定していたシステムからズレ収集がつかなくなる
• 開発中の頻発する仕様の変更や要件の追加で制御が効かなくなり、相当の手戻り工数などが発生する

これらのトラブルは、トレーサビリティマトリクス（要件が各工程のどこで実装され、該当するプログラムがどれであるか、一目でわかるようにまとめられたマトリクス表）を活用することで回避が可能です。仮に変更が生じたとしても、要望の追加なのか、もともと追加予定の機能だったのかなど、影響の範囲も明確にすることができます。

以下では、システム開発の下流工程でトラブルになりやすい、上流工程の失敗パターンを解説します。

• 手戻りにより納期の遅れ
• 予算オーバー
• 要求通りに完成しない
• 運用後にトラブルを引き起こす

手戻りにより納期の遅れ

システム開発において手戻りが発生する多くの原因は、要件定義があいまいな状態で開発を始めてしまうことにあります。

例えば、次のようなケースが挙げられます。

• クライアント側が提案依頼書を用意していない
• 開発側がクライアント側の要求を勘違いしている
• 要件定義に漏れがある

このような状態で開発を進めてしまうと、下流工程でトラブルが起きる可能性が高くなります。

手戻りが発生すると、Quality（品質）Cost（コスト）、Delivery（納期）といった「QCD」に多大な影響を与えます。

予算オーバー

予算オーバーになるのは、次のような理由が挙げられます。

• 開発や設計で追加の作業が発生した
• 要件定義の時点で見積もりが甘かった
• プロジェクトのやり直しが発生した

システム開発で予算オーバーを招く原因の多くは、要件定義など上流工程の失敗にあります。

クライアント側とのヒアリングを十分に行わなかったために、下流工程になって機能が追加されたり、全て作り直しになることもあります。その結果、追加でコストが必要になり予算オーバーを招いてしまいます。

要求通りに完成しない

クライアントの要求通りに作ったはずなのに、システムレビューの段階になって「要求と違う」と言われてしまうこともあります。

要求通りに完成しない原因に、開発側がクライアントの要求を軽視していたというケースも少なくありません。

上流工程でクライアントとのヒアリングが不十分だと、クライアント側が本当に望んでいる要求を理解することが困難です。

運用後にトラブルを引き起こす

クライアントとのヒアリングを疎かにするなどすると、システムのリリース後にトラブルが起こるかもしれません。さらに、トラブルに対する対応を誤ると、より大きな問題が生じる恐れがあります。

開発側も予測できない動作をクライアントが行ったために、予期せぬ不具合が発生する場合もあります。しかし、大抵の場合は上流工程でのヒアリング不足が原因です。

システム開発における上流工程管理の重要性

システム開発は、クライアントにシステムを納品・自社システムを完成させれば終わりではありません。システムが稼働した後も、OSの更新や機材の入替等に合わせてシステムのアップデートが必要になります。また、トラブルが起きた際に、窓口として対応することも上流の役割です。損害を最小限に抑えられるか、適切に対処できるかといったスキルが求められます。しかし長期にわたって保守開発をしてきたシステムの再構築は、そう簡単ではありません。「現行業務仕様の理解不足」などによる再構築に特有の難しさという問題もありますが、開発プロジェクトの現場で実装する機能は要求を正しく反映させることが重要です。

上流工程で、特に気をつけたい「守秘義務」と「情報漏洩」

最後に、上流工程を担う中で、特に気をつけておきたい「守秘義務」と「情報漏洩」について触れておきたいと思います。

守秘義務

新規事業における業務の一部を外注する際や、一部の業務を外部に「業務委託契約」する場合、他社と製品の「共同開発」をする場合やシステム開発、Ｍ＆Ａの検討、WebサイトやECサイトの制作をする場合などは、「秘密保持契約書（NDA）」を交わす必要があります。

出典：https://topcourt-law.com/contracts/what_is_nda 

万が一、自社の企業秘密など重要情報が漏れた場合、そのプロジェクト自体が白紙になる、投入資金が回収できない、利益の喪失など多大な損害を受けます。それ以外にも自社の秘密情報・ノウハウが競合他社へ流用されてしまうリスクもあります。

これらのトラブルを回避するうえでも、一般的な契約書とは別に秘密保持契約書（NDA）を交わしておくことが重要です。

情報漏えい

情報漏えいやサーバー攻撃などに対して適切な対応が取られていなければ、システム開発会社や管理する会社が責任を取ることになります。

過去に情報漏えいやサイバー攻撃など、発生してしまった事件事故を発端として、システム開発や管理を行う企業の責任が問われた例が2014年の東京地裁の判決でありました。SQLインジェクションと呼ばれる、データベース操作の命令文を悪用するサイバー攻撃への対策を怠ったとして、システム開発会社に約2,000万円の損害賠償を命じた判決です。

参考：悪いのは開発会社、それとも発注者？情報漏えい事故の責任を巡る裁判から考えるhttps://tokiocyberport.tokiomarine-nichido.co.jp/cybersecurity/s/column-detail65

これによって、納品するシステムやWebアプリケーションのセキュリティを担保するのは開発会社の責任である、という判例ができた形になります。

しかし、現実問題として開発時にセキュリティを配慮するようなお金も時間も与えられていないことが多く、発注者にセキュリティの提案を取り合ってもらえないこともしばしば・・・。今後は発注者側のセキュリティへの理解も深めておく必要がありそうです。

「守秘義務」でも述べたとおり発注者としては、ソフトウェア開発業者からの情報漏洩には、注意しなければなりません。ただ、発注者としては、開発会社側でセキュリティに配慮するのは当然ですが、孫請け、下請けの情報漏えいにも注意する必要があります。

システム開発における上流工程の課題解決により、ビジネスに貢献

上流工程は、開発プロジェクト全体のプロセスの中で、プロジェクト全体の方向性を決める重要な工程です。上流工程の作業がどれだけ綿密に行われているかでプロジェクトの成否・出来上がったシステムの品質にかかわってきます。

上流工程で抜け漏れや不備があると下流工程にしわ寄せがいき、プロジェクトが炎上してしまいます。上流工程の重要性は、以前から指摘されています。しかしそのような中でも、上流工程を疎かにし、手戻りや開発プロジェクトの頓挫など、運用後の大きなシステムトラブルを招くケースは後を絶ちません。それどころか、システムが大規模・複雑化することで、トラブルの発生は増える一方です。システムが生活に深くかかわっている現代において、一つの不具合が社会に甚大な影響を与えかねません。

取り返しのつかないトラブルを防ぐためにも、上流工程においてシステム開発における問題への取り組みが大切になります。プロジェクトの上流工程を適切に行うことで、システム構築の効率およびシステム全体の品質向上が期待できます。

まとめ

当記事では今回、システム開発における上流工程について解説しました。

システム開発の上流工程とは、クライアントからのヒアリングや開発の方向性などを決める重要な工程です。

上流工程を疎かにすると、下流工程で手戻りなどが発生しかねません。その結果、納期の遅れや予算オーバーを引き起こしてしまいます。

無用なトラブルを防ぐためにも、上流工程を重視する必要があるでしょう。

ラボ型開発がおすすめ！

ラボ型開発では発注者専任のチームを編成し、固定金額で一定期間システム開発を行います。オフショア開発で多く取り入れられている開発法ですが、 請負型開発に比べ柔軟性があり、契約期間内であれば何度でも修正や追加が行える、追加料金が発生しないなど様々なメリットがあります。 
ラボ型開発を上手く進めるためには、最適な依頼先を選ぶことも大切です。自社が求めるコミュニケーション力、技術力に対応できる委託先かどうか判断し、確認することが必要です。
本記事を通じて、コウェルはお客様の課題やご検討状況に応じて、オフショア開発におけるラボ型開発やラボ型によるシステム開発をうまく進めるようご提案やご支援をいたします。システム化・業務改善の提案からインフラ構築、システム開発、ソフトウェアテストサービス、その後の運用・保守までワンストップで対応が可能です。ソフトウェア開発をご検討されている皆様、ぜひ一度ご相談ください。

■関連記事：

なお、コウェルに関する詳細資料は以下でダウンロードすることが可能です。

このほか、弊社の具体的なサービスや導入事例については以下をご覧ください。

コウェルのサービスメニュー＞＞＞
コウェルは、日本とベトナムから世界中のお客さまへ高品質なソフトウェアテスト・品質保証・オフショア開発サービスを提供しています。

コウェルの開発導入事例＞＞＞
コウェルは情報通信、金融、流通・小売サービス、医療・ヘルスケアなど、さまざまな業界のお客様の導入を支援しています。​​​​​​​