今更聞けない【システム開発の流れ】
9'sパネル
プロジェクト マネジメント 上流工程
プログラミング システム開発 下流工程
要求分析 受入テスト 納 品
システム開発の流れ
上流工程と下流工程って？
システム開発全体の流れ
システム開発における上流工程を確認していく前に、システム開発の各ステップを確認していきましょう。
システム開発の各ステップの呼び方は、会社や資料によって多少の表現などに差異がありますが、一般的に良く使われる開発のV字モデルでは、大きく分けて、
上流工程
（１）要求分析
（２）要件定義
（３）機能設計
下流工程
（４）詳細設計
（５）コーディング
（６）各種テスト
（７）納品
以上のように分かれます。
システム開発における上流工程
このフェイズのうち、要求分析、要件定義、機能設計までを上流工程と呼ぶことが多いです。
それぞれどういったステップかを上から順番にお伝えします。
①要求分析
最初の要求分析とは要求を分析する、つまりこんなシステムを作って欲しいと思っています、というのをはっきりさせるステップです。
「流行っている稼げるシステムが欲しい！」と言われてもどういうことを開発していくのかが開発者側が困ってしまいます。
そこで、「こんなことができると嬉しい！」だとか、「今、使っているシステムのここが使いにくい！」といったことを具体的に整理し、どういったシステムを欲しているのか、どんなにシステムのことがわからないくらいのひとでも誰が見ても分かるドキュメントを作るステップです。
この誰が見てもどんなシステムが欲しいのか分かるドキュメントは、システム発注側、システム開発側双方が合意する必要があります。
これを重点的にしていないと後々トラブルが起こるフェーズでもあるので、発注側と開発側の間で認識がズレないようにしていくことが大事です。
思い描いていたものと納品されたものが全く異なっていた、という事態になってしまい払いたくない。予定以上のコストが上がったなどが発生してしまいます。
資料としては、要求定義をドキュメント（Wordで一覧でかいておくことがいいいですね。特に会議の際で、フワッとした回答だった場合は、次回までに発注側に確認をしてもらうこと。フワッとしたことがないようにそれぞれにチェック項目を入れておくことが大事かもですね。）
②要件定義
次のフェーズとしては、要件定義です。要件定義とは、要求分析で出てきた要望をもっとシステム的に具体化するフェイズです。
要求定義と要件定義の違いに関しての記事
例えば、現在、利用しているシステムのレスポンス(応答時間)が遅いので、改善して欲しい、という趣旨の記載が要求分析にあったとしましょう。
要件定義では、現在のレスポンスタイムを調べて、その、現在のレスポンスタイムを調べて、その妥当性を検討した上で、新システムではレスポンスは、現在のシステムの3分の1以下にする、といった表現をされます。
また、要件定義には要求定義で出てきた「あると便利な機能」について、本当に実装するべきかどうか確認するステップという側面もあります。
要求全てを実装し、システムで実現できれば良いですが、予算の兼ね合いなどから難しいかもしれないですが変更箇所が増えることで、予算がかかることは素直に告げましょう。
OS側においては、バージョンアップ、特にAppleの意向によって、バージョンアップするタイミングがあるので、その旨も事前に相談しておくといいです。
どの機能をシステム化するのか検討し、必要性が認められた機能のみ、要件定義の結果をまとめたドキュメントとして、要件定義書で表現するのです。
要件定義書もシステム発注側、システム開発側の双方が合意する必要があります。
お金を出す側としても、このシステムの要件定義書通りに作る方針でいくので後々追加する場合などに関しては、ここでしっかりと決めておかないと後々ずるずると関係性が崩れていくので、ここのフェーズはしっかりと詰めておくことをお勧めいたします。
③機能設計
三つの機能設計とは、要件定義で実装することが確定された機能について、詳細を固めるステップです。
例えば、ショッピングサイトの会計機能は、ユーザーから見るとどのサイトも同じように見えますが、実は在庫管理の仕組み、カード会社や銀行口座との連携部分でショッピングサイトごとに異なる仕掛けがあります。
この仕掛けは、ショッピングサイトの運営会社ごとに異なるので、よくよく発注側と開発側とで内容を詰めておかないと、「使えないシステム」になるリスクがあります。
システム開発のV字モデルにおいての上流工程ステップは以上になります。なので、案件を進める上でこのフェーズがもっと重要な要素があります。
それは、計画立案と構成管理です。
システム構築以前を行う前に、そもそも企画としてのシステム開発の計画を作成し定めることが必要。
システム開発を行う事になった経緯やスケジュール感、予算などが明らかになっていないと、システム開発は始められません。
中途半端な状態にしてしまうと後々言った言わないの無駄な争い事になってしまうのでここも上流工程として、しっかりと決めておかないといけません。
システム開発における下流工程
システム開発における下流工程とは
上流工程と対となるシステム開発の下流行程とはどういったものか簡単に確認していきましょう。
下流行程のステップの１つ目はコーディングです。つまり実際にシステムを構成するプログラムを作っていくステップになります。
次の各種テストとは、システム作成途中での各ポイントで行われる単体テストや結合テスト、そして、システムテスト、運用テストなどのことです。
単体テスト
UT（Unit Test）コーディングで作成されたシステムのパーツたるプログラムの確認テスト
結合テスト
JT（Join Test）コーディングで作成されたシステムの複数方面から各パーツを合わせて確認するテスト
システムテスト
ST（System Test）プログラムを組み合わせて、システムに求められている機能が提供できるかの確認するテスト
ここでは、上流工程での要件定義とすり合わせて、確認しておくことが重になってきます。品質を上げる場合は、ユースケーステスト、シナリオテストも重要になります。
参考資料：ユースケーステストとシナリオテストのちがいについて
主なシステムテストの種類
システムテストは検証する内容でいくつかの種類に分かれます。その中から代表的なシステムテストの内容と項目を解説します。
●確認テスト
＜回帰テスト（リグレッションテスト）＞
システムに修正を加えたとき、変更していない部分に影響が出たり、別の箇所に新たな不具合が発生したりしていないかを確認するテストです。システムを修正する度に、必ず実行します。
＜デグレードチェックテスト＞
システムに修正を加えたとき、前のバージョンに戻ったり、修正済みのバグが再度発生したりしていないかを確認します。
●評価テスト
＜セキュリティテスト＞
外部からの不正アクセス防止や情報漏えい防止など、セキュリティに関する機能が仕様書通りに動作しているかを確認します。不特定多数の利用者が想定されるシステムでは、不可欠です。
＜ユーザビリティテスト＞
システムの操作性や学習性、見やすさ、わかりやすさなど、ユーザーにとって使いやすいかどうかを確認します。利用したユーザーの満足度にもつながります。
＜障害許容性テスト＞
障害が発生した際に最低限の機能が維持され、システムが動作することを確かめるテストです。例えば、ハードウェアの故障やデータベースサーバのダウンなど、擬似的な障害を発生させて、障害対応や復旧手順について確認します。
●負荷テスト
＜性能テスト＞
システムの性能要件に基づいて、処理能力が仕様を満たしているかどうかパフォーマンスを評価・判定します。システムの時間効率や資源効率など条件ごとにレスポンスタイムを測定し、最適化を行います。
＜ロングランテスト＞
一定の期間、システムを連続して稼働させます。それによりパフォーマンスが落ちたり、停止したりしないかを検証する、システムの信頼性を確認するテストです。
＜ストレステスト＞
一度に大量のアクセスを行い、過負荷状態でシステムが正常に動作するかを確認します。排他制御、競合条件、メモリーリークなどを検出し、高い負荷がかかった場合の状況を検証します。
＜ロードテスト＞
システムの通常時の動きとピーク時の動きを測定し、ピーク時の稼働に耐えられるかを確認します。
＜キャパシティテスト＞
パフォーマンスを落とさずに稼働できる最大のトランザクションを測定します。ユーザー数やデータ量が増加した場合、どのようにシステムを増強するかを考慮するためのテストです。
その他システムテストの進め方はこちら が参考になります
そして開発側の確認が終わり、システムに問題がなければ、いよいよ納品です。
通常、納品時に発注側が主体となって受入テストが行われます。
受入テスト
UAT（User Acceptance Test）とは、しばしば、ユーザー受け入れテストや検収テスト、承認テストなどと呼ばれています。この受入テストでは、システムが想定通り動くかの確認はもちろん、設計の段階で作られたドキュメントや取扱説明書などに問題がないか、そして受注側の要望通りの使いやすいシステムになっているかを確認します。
場合によっては、修正が行われることもあります。
さて、次にシステム開発の上流工程がなぜ重要なのかについて見ていきましょう。
プロジェクトマネジメント
システム開発の上流工程がなぜ重要なのか？
簡単に言ってしまえば、下流行程は、実際にシステムを作る段階なのに対し、上流工程は、システム開発の方針を決める段階になります。
上流工程で定めた方針に欠点、法律や当事者の予期するような状態や性質が欠けていると、その欠点が原因となって、システム開発に支障ができてしまい、スケジュールが大幅に遅延していくことがあるかもしれません。あるかもというかあります。仮にスケジュールで、フロントチームができていたとしても、エンドチームができていないと結合テストが予定通り進めることができなかったりします。
また、受注側と開発側との認識に相違があることに気が付かないまま下流行程へ突入すると、完成したシステムが思っていたものと異なり、使い物にならないという事態になってもおかしくないのです。
上流工程に失敗したシステム開発は、プロジェクト全体が失敗へと進む可能性が極めて高いといえます。
上流工程に失敗するとシステム開発が多くの事情によって物事がスムーズに進まず（紆余曲折）し、失敗する可能性が高いことをお伝えしましたが、具体的にはどういったリスクがあるのか整理します。
上流工程が引き起こす可能性のあるリスク
要件定義のミス
要件定義の段階でミスがあり、後から実装機能の追加や、機能の動作修正を行った結果、追加費用が発生するリスクです。
当初予定になかったものを追加するとなると、それだけ労力が増えるわけですから、当初予定より時間がかかったり、その追加実装をコーディングするITエンジニア分、当初より人件費が増加するかもしれません。
機能追加によるバグ
また１度、途中出来が変わって、機能の追加を認めると、後から後から機能の見直しを求められてシステムの構成が奇々怪々になり、結果、バグが大量に包含されたシステムになってしまい、納品できる、できない、という話になることもあります。
システム開発に関係する訴訟問題の多くが、このような経緯で事実上開発に失敗してしまったプロジェクトの発注側と開発側の費用負担の問題で争われます。
では、なぜ上流工程で失敗してしまうのでしょうか？
上流工程でこける最大の理由
結論から言えば、上流工程が上手くいかなかった原因は、特に関係者のコミュニケーション不足によるものです。
システム開発側とシステム発注側のコミュニケーション不足だけでなく、システム発注側内部の発注部署とシステム利用部署・ユーザーとのコミュニケーション不足も考えられます。
前者の問題は、下流行程でも影を落とし、進捗スピードの低下や行き違いとなるかもしません。
後者の問題は、システム納品後、実際の利用者が思っていたのと異なっていた、という問題に繋がることでしょう。
システム開発側が発注側のことを素人だと思って邪険に扱わないことが重要です。どういったシステムを求めているのか親身になって密に確認することも大切ですが、発注側も素人だからと開発する側に任せておいたままにしないことが重要です。そのためには、発注側もシステム開発において必要なことを理解しておくことが非常に重要なのです。
そんなシステム開発の上流工程を成功させるために必要なスキルを5つ紹介します。
システム開発の上流工程を成功させる4つのスキル
顧客のニーズや要望を引き出すヒアリング能力（コミュニケーション能力）
上流工程では、顧客とコミュニケーションをとる機会が数多くあります。
そして、そのコミュニケーション不足が、システム開発の失敗を招いてしまうと言うのは先ほどもお話ししました。
そこで、上流工程担当者にとって必須なスキルは、顧客の要望やニーズをうまく引き出すヒアリング能力、コミュニケーション能力です。
多くのクライアントは、開発側の業務を理解することが難しく、どのようなシステムが欲しいのか、理想なのかを漠然としたイメージで伝えることができません。
そんな中で、クライアントの想定しているであろうシステムを、話しを聴きながら自分でイメージし、ある程度、具体的な形にする力が必要があります。
さらに、相手はエンジニア用語とは無縁な世界でビジネスをしている場合も多いので、専門用語をなるべく使わず、わかりやすく説明をする必要もあります。
ドキュメント作成スキル
上流工程の段階では、様々なドキュメントを作成する必要があり、そのドキュメントはそのプロジェクトにおいて大変重要な役割を担います。
具体的には、要件定義書、基本設計書、詳細設計書、などがあり、そのプロジェクトを推進するための道しるべとなります。
他にも言葉の定義やインフラ側、データーベース側、システム側などの各種仕様書、コーディング規約などもあると大きいプロジェクトの場合だと、どの開発者がいざ抜けても大丈夫なような状態を作っておくといいでしょう。
そのドキュメントは、誰がみても、どんな時に見ても理解できるような構成と文章で作成しなければいけません。
例えば、目次を作成して、一目で自分の情報がどこにあるかわかる構成にしたり、5W1Hを意識して文章を作成したりと、簡単なところから始めるだけでも、誰もが理解できるドキュメントを作成することができます。
要件定義の進め方については、以下の記事をご参照ください。
マネジメント能力
上流工程になればなるほど人は少なく、下流工程になればなるほど、メンバーは多くなります。
そして、その下流工程に携わる人たちを取りまとめるのも、上流工程に関わる人の役割であり、必要なスキルになります。
チームとして動き成果を上げるためには、チームワークもそうですが、個々あってのチーム力ですので、一人ひとりの仕事に対する意識とその働く環境などが重要になってきます。
メンバー同士がいがみ合ったり、尊重し合えない環境では、良い成果はあげられませんし、仕事に対する意識も低くなってしまいますよね。
その環境を整え、メンバーの意識を高く維持させるチームマネジメント能力は必須でしょう。
キャッチアップ能力
先ほども述べましたが、上流工程担当の人は、多くのクライアントと話す機会があります。
その人たちは、医療業界だったり、ファッション業界だったりと様々です。そんなクライアントに対してヒアリングや、コミュニケーションをとっていく上で、ある程度クライアントの業界を理解する必要があります。
そうすると、ヒアリングも楽ですし、想定しているシステムの想像もしやすくなりますし、システム開発の成功に繋がるでしょう。
いいなと思ったら応援しよう！
