戻るシステム開発の上流工程とは？下流工程との違いやポイント・SEの必要スキルを解説
システム開発における上流工程とは？
システム開発の上流工程とは、システム開発の流れにおける実践前の段階のことです。つまり、システムの企画から詳細設計にあたる工程を指します。
上流工程はシステムの基盤になる部分ともいえるでしょう。この段階の作業で手を抜いた場合、開発が失敗する傾向があるため注意してください。上流工程では問題がなくても、下流工程にフェーズが移った後で問題が起こるケースもあります。例えば、機能に仕様変更が入っても反映できているか分からない、作成する画面の項目名や桁数の判別を行えないといったトラブルが挙げられます。
「上流工程」と「下流工程」の違いとは
前述したとおり、上流工程とはシステム開発における前半の段階です。一方、下流工程とは上流工程に続く段階となります。
下流工程では上流工程で作成した設計に従って、システムの構築を行い、完成までの各種作業を行います。
大規模な企業の場合、下流行程を担当する社員は開発チームを行っている人たちと接する機会がほとんどで、顧客と実際に接する機会がないケースも珍しくありません。
上流工程管理の重要性とは
上流工程のSEは開発における初期の段階を担当します。そのため、開発においてミスがあった場合など、システムの不具合にもかかわる問題になるため注意が求められています。
上流工程では要件定義や設計、予算作成といった開発の基盤となる部分を行うことが一般的です。この部分でミスをしてしまうと、実際の作業が成り立たなくなることもあります。
顧客の要求をきちんと分析し、システムに落とし込めるように正確な設計が求められます。
システム設計における上流工程の内容と流れ
システム設計における上流工程は要件定義、アーキテクチャ設計、機能設計、内部設計の順で行います。
システム設計における上流工程の業務内容と流れを見ていきましょう。
①要件定義
システム開発と同様、必要な機能と性能をきちんと定義するうえで要件定義を行う必要があります。要件定義ではクライアントの要求や課題を解決に導けるよう、必要な機能の検討を行います。
要件定義においてまとめた情報は設計段階の資料、もしくはルールとして参照します。これらは下流工程の開発を行う際や、テストケースを作成する際にも参考になる情報源です。プロジェクトにおいて一貫して利用するためには正確に作成しなければなりません。
②アーキテクチャ設計
システム全体の構成を決定する設計をアーキテクチャ設計といいます。アーキテクチャにはソフトウェアのみならず、システムの実行環境、あるいはハードウェアも含みます。どの技術を使用すべきなのか検討を行うのもアーキテクチャ設計の段階における重要な業務です。
アーキテクチャでテストケースや、開発環境を決定することも多いです。開発状況に合わせて追加の作業や修正も行いますが、下流工程の方針の基盤になる不可欠ともいえる設計です。
③機能設計
機能設計は機能を実装するうえで具体性のある方法を決める設計全般をいいます。データの管理方法やプログラミングなど、開発をスムーズに行ううえでの重要な行程です。
その他にも、機能設計にはユーザーファーストの設計もあります。例として、ボタンや操作画面、リンクの配置などのシステムを快適に使うための設計が挙げられます。
④内部設計
内部設計とはシステム内部の実装についての設計です。作業を行う範囲にはシステムに存在する全処理が含まれています。機能間で連携を行うことはもちろん、書き出し速度やデータの送受信まで含まれます。
また、プロジェクトや開発現場ごとに内部設計の扱いが異なります。内部設計では機能の細部まで設計するため、機能設計の段階であわせて行われることも多いです。そのため、開発粒度の事前確認後、設計書の作成が一般的です。
システム開発における上流工程の内容と流れ
システム開発における上流工程はシステム企画、要件定義、基本設計、詳細設計、見積作成の順で行います。
システム開発における上流工程の業務内容と流れを見ていきましょう。
①システム企画
システム企画では企業が掲げているIT戦略に基づいて、関係部署で方針に適した情報化の企画書の作成を行います。
システム企画は完全に内製化を行った社内開発を除き、ほとんどが開発をアウトソース化します。委託先である開発ベンダー側から見ると要件の源泉になる部分です。
②要件定義
要件定義とはシステム開発を推進するにあたって要望を整理する工程です。要件定義で整理するポイントは次の3つです。
・顧客が欲しているシステムはどのようなものか
・システムで実現したいことは何か
・実装したい機能／求めている性能は
要件の定義は顧客側で行うことが一般的です。しかし、顧客がシステム化するうえで必要な情報の一覧を作成できない場合は、開発ベンダーが代わりに行うこともあります。
また、要件定義の段階で顧客の要求について実現性の検討も行います。工程の後半における作業を円滑に進めるためにも、トレーサビリティマトリクスの作成がおすすめです。トレーサビリティマトリクスとは、要件がどの工程でどういった成果物に落とし込まれていくのかを可視化した資料です。
③基本設計
基本設計ではシステムの土台となる基本的仕様をまとめます。例えば、業務フローや前工程で作成した要求の一覧に基づき、システム化を行う部分の必要機能の一覧化や、入出力についての項目です。
他システムとの連携項目がある場合、他システムインタフェースも入出力項目に含まれます。後の工程に要件がきちんと反映されるよう、各要件がどの画面、あるいはどの帳票に反映されるのか関係性のチェックを行います。
④詳細設計
詳細設計では基本設計で作成した設計をベースにして、機能の実現性を考慮してプログラム単位の設計書を作成します。
例えば、商品名の入力で検索できるECサイトを作成したい場合、Webサイトのトップページに加えて、検索結果ページの画面や商品の在庫を管理するデータベースが必要です。
そこで、一覧や画面イメージ、あるいはデータベースのテーブル基本設計を作成します。詳細設計の段階では、トップページで検索語句を入力後、検索ボタンをクリックした時のプログラムの動きを設計できるようにします。
⑤見積作成
システム開発の概要が決定したら、予算と開発期間を計算して見積もりを出します。クライアントから同意を得られたら契約は成立です。下流工程での開発業務が始まります。
また、見積もり作成は上流工程における最終段階の業務です。スケジュール、開発現場の状況などの判断も必要ですので正確に行わなければなりません。
システム開発での上流工程のポイント
システム開発における上流工程のポイントを見ていきましょう。
クライアントとのコミュニケーション
クライアントはシステム開発について専門的知識を持たないことも多いです。クライアントは思うように説明できないケースも少なくないことを念頭に置き、認識の齟齬が生じないようにヒアリングを行わなければなりません。
開発側とクライアント側の理解に違いがある場合、開発の後戻りが必要になりコストや業務負担の増大が予想されます。また、仕様変更が必要な場合、納期の遅れの原因にもなります。
クライアントとのコミュニケーションはプロジェクト成功とトラブル回避のためにも不可欠なフェーズです。
各項目でのテスト
システム開発の上流工程では下記の3つのテストを行います。
1．要件定義⇔システムテスト
システムテストで機能要件や非機能要件に着目したテストを行うことで、顧客の要望に合ったシステムであるのか確認できます。
また、要件定義では顧客の業務に従った要望がきちんと出し切れているか点検しなければなりません。
2．基本設計⇔結合テスト
結合テストで入出力項目や他システム連携項目、画面表示に着目してテストを行うことで、基本設計に従ってシステムが完成しているか確認できます。
基本設計では業務フローから落とし込まれた必要画面や、他システムとの連携項目に欠如がないか点検しなければなりません。
3．詳細設計⇔単体テスト
単体テストでは単一機能として要件から落とし込まれた内容が組み込まれているかテストします。
また、詳細設計において要件の内容がトレースされているか、適切なエラーハンドリングが想定されているかなども点検します。
設計の標準化
設計フェーズは上流工程において重要なフェーズです。しかし、近年では、設計書の作成で共通の基準はありませんので、作成を行うシステムエンジニアごとに作成方法や表記、仕様は異なります。
こうした状況は属人化を招く原因となるため注意しましょう。内容が分かるのは作成者のみとなってしまうと、業務が一人に依存してしまうことになります。その結果、プロジェクトの進行に遅れが生じることもあります。
システム開発のプロジェクトをスムーズに進めていくためには、設計書の標準化や、各種設計書の作成方法、品質の統一が重要なポイントです。
実現性
クライアントはシステム開発についての知識がないことも多く、実現性のない要望を伝えてくることもあるでしょう。この場合、クライアントとコミュニケーションをきめ細やかに取っていても、要求された要件に従えないこともあります。
上流工程を担当する場合、依頼を受け付ける前にクライアントの要求は実現可能なのかきちんと検討しなければなりません。実現できそうにない場合、クライアントには理由とともに難しい旨を伝える必要があります。
上流工程でよくある失敗と課題
上流工程でよくある失敗やリスク・課題を見ていきましょう。
顧客からの要望を受けきれていない
顧客からの要望を受けきれていないケースとして2つのパターンがよくあります。
・顧客の要望を誤って理解している
・要件に変更が加わったものの、コントロールができていない
顧客の要望を誤って理解している場合、完成したシステムを受け取った顧客からクレームが入ることもあります。また、顧客との信頼関係にもかかわる問題ですので気をつけましょう。
その他にも、要件に変更があったものの対応しきれないというケースもあります。
これらはトラブルを防ぐための用意ができていないために起こることも少なくありません。管理台帳を作成する、顧客に繰り返し確認するなどの工夫が必要です。
顧客の要望を受け入れすぎている
顧客の要望を受け入れすぎることもトラブルにつながります。繰り返しになりますが、顧客のなかにはシステム開発の知識がなく、開発の実現性を考慮せずに希望のみを伝えてくる人もいます。
こうした顧客の場合、全ての要望を聞き入れてしまうと、想定していたシステムから乖離して立ち行かなくなってしまうでしょう。
変更点のコントロールや管理不足
変更点が追加された場合、従来の範囲に関係することなのか、それとも追加の要望であるのかといった影響範囲を明確にする必要があります。
顧客から変更点の追加を伝えられた場合、手戻りの必要性や料金、納期などの相談が再度必要になるケースも多いです。
また、要件が明確になっていない状態で推進している場合は、プロジェクトを一旦ストップすることも重要です。
不具合の発生による納期の遅れ
上流工程でミスが生じた場合、このフェーズで修正などを行い解決しておく必要があります。不具合を解決しないと、下流工程にも受け継がれることになります。結果として、修正が必要になり納期が遅れることにもなりかねません。
上流工程での不備や遅れはプロジェクト全体に影響を与えるため、期限を守りつつ、正確に作業しなければなりません。
見積もりの設定ミスによる開発コストの増大
見積もりでミスがあると、開発コストの増大につながります。クライアントと予算の上限について必ず話し合い、設計は予算に余裕がある範囲で行うことが重要です。
また、見積もりにおいて詰めが甘いと、思ってもいなかった機能を追加しなければならなくなるケースもあります。それに伴い、予定外の修正も多々出てくるでしょう。
リリース後のトラブル
システムのリリース後、トラブルが発生するケースも少なくありません。クライアントが仕様にない動作を行ったためにミスが生じるケースもありますが、間違った処理が行われた状態で納品していたことが原因で起こるトラブルも多いです。
開発が原因のトラブルは、下流工程での作業不備によるとは言い切れません。上流工程で想定し、防止できるケースも多いです。
上流工程でのトラブルを防ぐためにSEに求められるスキルとは
上流工程を担当するSEはトラブルを防ぐために、業務に直結する技術や専門知識以外にも求められるものがあります。
ここでは、上流工程を担当するSEに求められるスキルを見ていきましょう。
ヒアリングスキル
クライアントのニーズを汲み取ったシステムを開発するには、クライアントの要望を引き出すためのヒアリングスキルが重要です。要件の洗い出しを行い、課題を解決できるような設計に結びつけます。
ヒアリングスキルがない場合、クライアントが想定している内容とは異なるシステムを開発してしまうことにもなりかねません。
また、クライアントのなかには要望を上手く伝えられない人もいるため、クライアントの立場になってニーズを憶測する力も必要です。
マネジメントスキル
下流工程のメンバーと上手く連携し、開発を進めていかなければなりません。
また、特に、年齢を重ねるとメンバー全体をまとめるマネジメントスキルが重要になります。スケジュール調整やタスク管理の他、開発がスムーズに進むよう指揮を執る必要があります。
設計スキル
設計を行う際は下流工程をよく考慮します。実現可能な道筋と目標の設定はもちろんですが、ミスが起こらないよう設計することも重要です。
設計の段階で不備があるとプロジェクト全体が上手くいかず、手戻りなどが必要になるので注意してください。
ハイブリッドテクノロジーズのシステム開発
ハイブリッドテクノロジーズでは上流工程で起きやすい問題への対策を徹底しております。
開発前は日本人PMがクライアント様と要求や機能のすり合わせを密に行い、開発チームマネージャーが見積もることで、見積もりの精度を担保します。また企画チームがリリース後の運用を考慮した提案をすることで、リリース後の問題発生を抑制します。
開発中はアジャイルスクラムに則り、スプリントごとに成果物や開発予定物の確認を行うことで予算、機能、品質、スケジュールなどのコントロールを行います。
弊社には開発前から開発後まで、クライアント様に寄り添う体勢が整っています。
＜ハイブリッドテクノロジーズが選ばれる理由＞
弊社ではクライアント企業様及びエンドユーザー様の声を聞き、UIUXを意識したビジネスデザインを行なっております。 テーマを決めて分析し、仮説を立ててビジネスデザインを行い、プロトタイピング、検証、フィードバックを受け、再度分析から始める。 この一連の流れを、アジャイルスクラム開発に精通した500名以上のエンジニアが光速で回していくことにより、最速でより良いものを実現していきます。 ハイブリッドテクノロジーズには市場の声を現実にするための仕組みとメンバーが揃っています。
システム開発の成功事例
システム開発での成功事例をご紹介します。
見守りサービス (株式会社otta)
サービス内容
位置情報履歴を、無料スマホアプリやメールを通じて保護者様に伝えるサービス
サービス上の課題/目指したいサービス
課題
共働き世帯や高齢者の増加など、社会構造の変化により、子どもや高齢者の見守りへのニーズが急速に高まっている。一方で、見守る方々の高齢化や地域コミュニティの変化により担い手は減少方向にあり、この需給ギャップを埋めるには、見守りの仕組みの生産性を大幅に向上させなければならない。
目指したいサービス
IoTを活用した見守りサービスのパイオニア企業として、見守り活動の生産性の飛躍的な向上に貢献するとともに、従来のサービスでは困難であった、多くの方々にご利用いただける料金体系を目指すこと。
クライアントの課題/要望
・追加開発体制のリソースが不足している
・既存ベンダーの開発チームと組み合わせながら、チームを構築したい
・事業状況に応じて柔軟にリソースを調整したい
当社を選択していただいた理由
キャピタル案件であり、HTからの投資次第で開発も頼みたいという理由から
当社ご提案内容
業界ラボ型（ストック）開発＋保守にて提案
toB向け見守り管理システム開発
・今後の基盤変更も意識しながら登園バス管理システムの管理画面を作成し、サービス展開をしていきたい
・今後の開発体制構築も視野に入れつつまずはスモールに体制を構築しつつ今後の足掛かりとしたい
リソース活用し柔軟に対応できることと、javaを中心に進めていたが、よりモダンな言語を基盤に開発を進めたいという要望に対し、得意分野であった。
学習履歴データの可視化システム(放送大学学園)
サービス内容
学習履歴データ可視化システムの開発
サービス上の課題/目指したいサービス
課題
オンライン授業システムのデータベースには多量の学習履歴データが蓄積されており、このデータを学内の担当者が活用できるよう整備し、学生指導のためのヒントとして、あるいは学生に受講を促すための情報源として活用したいという意向があった。
目指したいサービス
・学外に開示する「サービス」ではなく、学内担当者用の「ツール」であること
・コマンドラインで操作可能なツールであること
・追加機能の実装をできるようにすること
クライアントの課題/要望
・社内で開発体制を保持していないこと
・金額をミニマムに抑えながら安定的な運用を実現したい
当社を選択していただいた理由
充分に仕様を満たす提案内容と他社と比較して最も安価な金額で入札提示したため。
当社ご提案内容
学習履歴データベースとBIツールの開発
オンライン授業システムのデータベースに蓄積された学習履歴データを活用するにあたって、実運用されているDBの処理とバッティングしないように、MongoDBに格納する処理にて開発を進めました。またMongoDBにデータを格納する際、他データとの連携も考慮し、汎用的なExperienceAPIに準拠したデータ形式を採用しました。
個人情報の扱いにおいては、開発人員含め、学生の個人情報の漏洩を防ぐため、学生の識別子を匿名化しての実装を実施しました。
DocIT (株式会社ドキットメディカルサービス)
サービス内容
働き口を探す医療従事者と、働き手を求める病院をつなぐマッチングプラットフォーム
サービス上の課題/目指したいサービス
課題
高額な紹介料がネックとなりスポットで人が必要な際に苦心をする病院の課題解決
目指したいサービス
休日や長期出張の空き時間を有効活用したい医師と、長期連休などで一時的に人手が必要となる病院をマッチングすることで医師の働き方の多様化を実現するサービス
クライアントの課題/要望
・サービス構想はあるが、実現させる開発パートナーが必要
・上流工程からの開発サポートが必要
当社を選択していただいた理由
開発にあたってサービス設計から本開発まで、一緒に伴走し考えながら開発してくれるパートナーとして安心感を感じて頂き、当社を選ばれました。
当社ご提案内容
ラボ型（ストック）開発にて提案
1.医療求人の性質を鑑みた機能提案、システム設計・開発
本サービスでは失敗の許されない医療系求人を取り扱うため、求人マッチングをする前に信頼のできる医師・病院であることを確認できることが重要となります。 そこで、実際に求人マッチングした医師・病院による相互レビュー機能を実装することで、信憑性の高いレビュー情報を蓄積することを提案・実現しました。 また、求人マッチング前に病院担当者と直接チャット出来る機能も実装することでレビューでは分からない定性的な情報確認も可能としました。 アジャイルスクラム手法の開発を取り入れることにより、システム開発の進捗報告を実際に動くシステム画面をお見せしながらデモンストレーション形式で毎週行いました。
2.定期的なスプリントを繰り返し、顧客と一緒に品質を高めるプロセスにて進行
実際に動くシステムを毎週見ていただくことで、開発進捗についての安心感やお客様も気がついていなかった新たな改善点がを発見でき、それを修正して再度デモンストレーションを行いました。この一連の流れを回すことで、お客様の求めるものを高い品質でご提供しました。
3.デザインを用いた視覚的なアウトプットで、具体的なシステムイメージを共有
Webサービス開発に初めて挑戦するお客様のため、お客様が思い描くビジネスを実現するためのシステムイメージを具体化していくデザインサポートも担当。求人情報サービスという特性上、さまざまな情報要素が混在する中で、目に見える形でデザインを整理・提案し、お客様からのフィードバックを受け、再提案を繰り返すことで、よりユーザーにとっての最適なWebサービスのための設計・提案・実現を行いました。
THINK, Reviewers (株式会社スパイス ボックス)
サービス内容
独自の「ソーシャルリスニング」手法をもって、企業と生活者の 間に生きたコミュニケーションを構築するサービス
サービス上の課題/目指したいサービス
課題
インフルエンサーの評価指標としてフォロワー数とエンゲージメント数が重要視されているケースが多いが、商品販売施策においては保存数が重視される。保存数を把握した上でインフルエンサーと企業のマッチングを行うプラットフォームが存在していなかったため、新たなサービスとしてスピード感を持ってサービス開発を行いたい。
目指したいサービス
・サービス名「THINK」：Twitter調査における既存システムの安定的かつ継続的な運用を維持しつつ、インフラコストを削減すること。
・サービス名「Reviewers」：インフルエンサーマーケティングで投稿保存数という指標を重要視するインフルエンサーマッチングプラットフォームの新規立ち上げをすること。
クライアントの課題/要望
・開発が発生した際に、都度RubyonRailsの対応人員を増やすのが難しい
・インフラ周りに強いメンバーがいない
・金額をミニマムに抑えながら安定的な運用を実現したい
・追加開発が発生した場合には、知見を維持した状態で取り組める体制がほしい
当社を選択していただいた理由
・開発リソースの柔軟性とインフラなど対応範囲の幅広さが先方ニーズにマッチしていたこと
・定常運用の際にもコストを抑えて対応できること
当社ご提案内容
受託型開発（フロー）にて提案
インフラ知見を持つディレクション人材をアサインメントすることで、インフラ周りの調整や業務対応にスピード感を持って対応できる体制を構築
インフラ/保守/開発を幅広く対応可能、かつ、コストミニマイズなオフショア体制をご提案しました。
ディレクション人材がインフラの知見を持ち、定常作業はベトナム側で行えるようにマニュアル化を行い、コストミニマイズしながらも幅広い知見を活かせる体制提案を行いました。
新規の開発が発生した際に、既存チームの知見を活かしながら適宜開発者を追加して、素早く開発を実行できる体制を実現しました。
まとめ
システム開発の上流工程は開発における基盤ともいえる部分です。フローの流れにおいては設計や予算案の作成など、実際の開発に入る前の段階を指します。
上流工程でミスがあったり、あいまいな設計しかできなかったりすると、下流工程でミスやトラブルが発生することもあるので注意しましょう。
上流工程を担当するSEには設計する力だけでなく、顧客と円滑にコミュニケーションを取る力や顧客の要望を正確に理解する力、さらにはマネジメント力も求められます。
