システム開発における開発工程の中でも上流工程について解説していきます。
システム開発を外部委託にあたって、システム開発の全体の流れを理解し、その中でも特に重要工程である上流工程のことを理解することで、委託先の選定に役立つのではないでしょうか。
本記事を読んでいただき、システム開発の全体流れを把握する1つの材料になればと思います。
1.システム開発における上流工程とは？
1章ではそもそも上流工程とは、何ぞやを解説していきます。
1-1.上流工程とは、システム開発のプランニングをする工程のこと
簡潔に言うと、上流工程はシステム開発のプランニングする工程の部分を指しています。システム開発の開発工程は上図の通りで、その中でも茶色四角部分（要件定義～詳細設計）が上流工程と言われるところになります。とはいえ、システム開発の規模や人によって指している範囲が若干違うので、明確な定義付けがないのが正直なところです。
ただ、システム開発の中でも上の工程に近いほど上流工程と呼ぶと覚えておくと良いでしょう。
1-2.下流工程との違い
下流工程は、上流工程で決まったことに対して、作業していく工程になります。簡単に言うと、実際に手を動かす部分になります。それぞれの工程求められるスキルも異なってきます。
上流工程：責任の重さ、マネジメントスキル、クライアントとの折衝力
下流工程：プログラミングを書く技術力、黙々作業
2.上流工程が重要と言われる理由
上流工程は重要・重要と良く耳にすると思いますが、なぜそんな重要なのか、2章では解説していきます。
2-1.上流工程でプロジェクトの運命が決まる
上流工程では要件定義というフェーズが入ってきます（詳細は3章で解説）。要件定義ではクライアントが作りたいシステムをどうやったら実現できるか、クライアントがどんなシステムを作りたいかヒアリングして整理することになります。
仮にこの整理が曖昧だったり、意味不明だったりすると、その状態でプロジェクトが進んでいくことになります。完成品をクライアントがチェックしたときに「思ったものと違う…作り直し！」なんてことになりかねません。
そのため、この上流工程は慎重に確実に情報を整理していく必要があります。会社の信頼に繋がってきます。
2-2.上流工程は責任者が進める
そんな上流工程は当然ながら知識ゼロの人ができるようなものではありません。
プロジェクトを進めるにあたって責任が取れるポジションの人が責任を持って取り組むことになります。企業規模にもよりますが、部長や取締役がつくこともあります。
具体的には以下のようなスキルセットが求められます。
- ヒアリング力／質問力
- 論理的思考力／問題解決能力
- ドキュメント作成スキル
- 業界知識／ドメイン知識
- プロジェクトマネジメント能力
2-3.上流工程の進め方は会社（人）によって変わる
上流工程の進め方は会社によって異なります。
1章でも紹介した通り、上流工程の線引きが人によって異なることもあり、進め方も違ってきます。
クライアント側からしたら、自分たちが進めやすい会社（人）のところに発注したくなるでしょう。それもあって、クライアント側は依頼する会社を変えるというケースはなかなかありません。
初回取引で上手くいかなかった時や、受注側の受け入れが困難になった時、全くジャンルが異なるシステム開発をする時に変えることはあるかもしれません。
3.上流工程の流れと業務内容
3章では上流工程の流れと具体的な業務内容を紹介します。プロジェクトの内容によって、上下しますが上流工程に掛かる期間の目安としては、小規模：1～2ヶ月、中規模：3～6ヶ月となっており、要件定義：30%、基本設計40%、詳細設計：30%程度の配分になります。
3-1.要件定義前にすること
最初にクライアントが求めているモノをヒアリングします。細かいところまで要求を理解して、その要求の期待に応えるためにどのような機能が必要か、どのように進めていくか、プランニングしていきます。
ドキュメント化して、クライアントに提案して金額も含めて合意を取った上で要件定義に進めることになります。
クライアント側（発注者側）でも準備すべきことがあります。
- 本プロジェクトの社内体制の整備
- 決裁権者の積極的な打ち合わせの参加
- 業務フローの整理
- 予算／スケジュールの妥当性確認
3-2.要件定義ですること
これからどのようなシステムを、どのような開発手法で開発するのか決めていくフェーズです。一連の開発工程の中でも最も重要なフェーズであり、慎重に検討しながら決めていきます。
- 全体のスケジュール（何をいつまでに終わらせるか）
- 全体で掛けることができる予算
- 開発手法
- リリースする方法
- リリース後の運用方法 など…
システム開発は要件定義で決めた内容に沿って大枠は進んでいくので決裁権のある人たちも含めて話し合いを重ねていきます。クライアント側×開発側でPM,PLを交えて決めていきます。
要件定義については、「要件定義とは？基本設計／詳細設計との違いと進め方を解説」で詳細を解説しています。
3-3.基本設計ですること
要件定義で決めた内容をもとにユーザー側が見える部分を決めていく設計になります。基本設計書は機能ごとに作成するのが一般的です。ただ、プロジェクトの規模によって書き方は若干変わってきます。
基本設計書は開発側のエンジニアが書くことが多く、書いた内容をクライアント側と共有してディスカッションして詰めていきます。クライアント側が非IT系であれば、専門用語を少なめにして、誰でも分かるような書きぶりにします。
基本設計については、「基本設計とは？進め方と要件定義／詳細設計との違いを解説」で詳細を解説しています。
3-4.基本設計以降（詳細設計）ですること
基本設計の次は詳細設計という内部資料、エンジニアが開発するために必要な資料を作成していくことになります。一般的にはここから下流工程に入ります。※人によってその線引きが異なるので何とも言えませんが、、
詳細設計については、「詳細設計とは？進め方と要件定義／基本設計との違いを解説」で詳細を解説しています。
4. 上流工程の失敗事例と教訓
上流工程の重要性を理解するために、実際に起こりがちな失敗事例とその教訓を紹介します。これらの事例を知ることで、同じ過ちを避け、プロジェクトを成功に導くヒントが得られるでしょう。
4-1. 失敗事例①：要件定義の曖昧さが招いた大幅な予算超過
<事例の概要>
ある企業が在庫管理システムの開発を依頼した際、「使いやすいシステムにしてほしい」「できるだけ多機能に」といった抽象的な要望だけで要件定義を進めてしまいました。開発会社側も具体的な機能要件を詰めずに開発をスタートさせた結果、以下の問題が発生しました。
- 開発途中で「この機能も必要だった」と次々に追加要望が発生
- 当初の見積もりから予算が1.5倍に膨張
- 納期が3ヶ月遅延し、ビジネス機会を逸失
- クライアントと開発会社の関係が悪化
<教訓>
要件定義では「何を作るか」を具体的に文書化することが不可欠です。以下のポイントを押さえましょう。
- 機能要件を具体的にリスト化し、優先順位をつける
- 「Must（必須）」「Want（欲しい）」「Nice to have（あれば良い）」で要件を分類
- 予算とスケジュールの制約を明確にし、その範囲内で実現可能な機能を決定
- 要件定義書をクライアントと開発側で署名・合意する
4-2. 失敗事例②：コミュニケーション不足による認識のズレ
<事例の概要>
ECサイトのリニューアルプロジェクトで、クライアントは「デザインを今風にしたい」と要望していました。開発会社側は最新のトレンドを取り入れたモダンなデザインを提案しましたが、納品後にクライアントから「イメージと全く違う」とクレームがありました。
原因を調べると、以下のことが分かりました。
- クライアントの「今風」は「シンプルで落ち着いた」デザインを意味していた
- 開発会社は「今風」を「派手で動きのある」デザインと解釈していた
- デザインのモックアップ確認が1回のみで、詳細な擦り合わせをしていなかった
- 結果、デザインを全面的に作り直すことになり、コストと時間が無駄に
<教訓>
言葉の解釈は人によって異なります。コミュニケーションでは以下を意識しましょう。
- 抽象的な言葉（「使いやすい」「今風」「シンプル」等）は、具体例や参考サイトを用いて認識を合わせる
- ビジュアル資料（ワイヤーフレーム、モックアップ、プロトタイプ）を複数回確認する
- 定期的なミーティングを設定し、進捗と認識のズレを早期に発見
- 議事録を必ず作成し、決定事項を文書として残す
4-3. 失敗事例③：ステークホルダーの巻き込み不足
<事例の概要>
ある製造業の企業が生産管理システムの刷新を決定しました。情報システム部門と開発会社で要件定義を進めましたが、実際にシステムを使用する現場の製造部門や営業部門は関与していませんでした。
システム完成後、以下の問題が発覚しました。
- 現場で必要な機能が実装されておらず、業務が回らない
- 逆に、誰も使わない不要な機能に開発コストをかけていた
- 現場から「使いにくい」と不満が噴出し、システムの利用率が低迷
- 結局、追加開発で現場対応の機能を実装することに
<教訓>
システム開発では、実際の利用者を巻き込むことが重要です。
- 要件定義の段階から、エンドユーザー（現場担当者）をヒアリングに参加させる
- 各部門の代表者を集めたキックオフミーティングを開催
- 業務フローを現場で確認し、実際の運用に即した要件を洗い出す
- プロトタイプを作成し、エンドユーザーに触ってもらい、フィードバックを収集
4-4. 失敗事例④：非機能要件の見落とし
<事例の概要>
あるWebサービスの開発で、機能要件（どんな機能が必要か）は詳細に定義されましたが、非機能要件（性能、セキュリティ、可用性等）については「よしなに」という曖昧な指示で進めてしまいました。
サービスリリース後、以下の深刻な問題が発生しました。
- 想定以上のアクセスが集中し、サーバーがダウン
- セキュリティ対策が不十分で、個人情報漏洩のリスクが発覚
- システムのバックアップ体制がなく、データ消失の危険性
- 緊急対応で追加のインフラ投資とセキュリティ対策が必要になり、予算が大幅超過
<教訓>
非機能要件は見落とされがちですが、システムの品質を左右する重要な要素です。
- 性能要件：同時アクセス数、レスポンスタイム、処理速度などを明確に定義
- セキュリティ要件：暗号化、認証、アクセス制御、個人情報保護の方針を決定
- 可用性要件：稼働率（99.9%等）、障害時の復旧時間、バックアップ方針
- 保守性・拡張性：将来的な機能追加やユーザー増加に対応できる設計か確認
5.上流工程で意識すべきポイント
4章では、上流工程の業務を進めるにあたって、意識しておきたいポイントを紹介します。
5-1.クライアントと密なコミュニケーションを
上流工程はいかにクライアントの要望を聞き出すか、が重要になってきます。クライアントとのコミュニケーションを密に取って、クライアントが思い描いているものを形にしていく必要があります。クライアントに苦手意識を持たせないようにコミュニケーションを取っていくことが大事です。
5-2.夢ではなく現実を見る
夢を語るのは簡単ですが、当然現実を見る必要があります。予算がある中で、その予算内でどうやったら実現できるか、どこを切り捨てていくか、クライアントと相談しながら進める必要があります。クライアントの言いなりで進めてしまうと、予算内で収まらずに、後々トラブルの原因にもなりかねません。
5-3.難しい言葉を誰でも分かるようドキュメント化する
IT業界は専門的な言葉も多く、非IT業界から見たらエンジニア同士の会話は、？？？の状態に陥ることが良くあります。クライアントの要望を聞いた後に提案書として、非IT業界の人でも分かるようにドキュメント化（提案書）する必要があります。話をまとめて優しい文字に置き換えて提案することを意識すると良いでしょう。
「上流工程とは」まとめ
システム開発の上流工程に解説してきました。システム開発は、リリースするまでに様々なフェーズを経てリリースすることになります。特に立ち上げ時期の要件定義が重要であり、要件定義が曖昧だと高い確率で上手くいかないケースがあります。
「要件定義から一緒に考えてくれる委託先が欲しい…」
「仕様が曖昧なままでも柔軟に体制を組んでくれる委託先が欲しい…」
「上流工程の部分だけお願いしたい…」
こんなお悩みありませんか？
弊社はシステム開発会社であり、お客様と一緒になってお客様の課題解決をシステムの提供という形で支援しています。また、様々な体制を組むことが強みでもあり、オフショア開発、ニアショア開発、オンサイト（常駐型）開発、受託開発など…お客様の状況に合わせてご提案いたします。相談は無料！なのでお気軽にお問い合わせください。
