ハートテクノロジーズ株式会社 & メタバースアカデミー

システム開発設計全体の流れ~要件定義、設計、実装、テストまで~および発注側と開発委託会社の役割分担について

Pocket

所謂システムというものは、それがIT寄りの業務系、事務系のシステムであろうと、組み込み機器といって商品の中にプロセッサが搭載されている商品(世の中のかなりの商品が今や組み込み機器になっていますが)も”システム商品”といえますので、そういう商品であろうと、システム開発設計をする流れ、セオリーというのがあります。

 

この記事では、そういったシステム開発設計の流れの基本を紹介すると共に、システム開発においては一般に発注側と開発委託会社に別れると思いますので、それぞれの役割分担について解説します。

システム開発設計の流れ

この図がシステム開発設計の基本的な流れを示しています。

 

 

この図はV字型モデルと言うことも有り、実際には一番左上の要求仕様から始まり、要件定義、基本設計、詳細設計、実装と進んだ後、単体テスト、結合テスト、総合テスト、受入テストといったテストのフェーズを経て商品を出荷するというのがシステム開発設計の一連の流れになります。

 

その中で、何故V字型で表されているかと言えば、要求仕様を反映したテストとして受け入れテストがあり、別の例としては、基本設計を反映したテストとして結合テストがありというように、設計フェーズを権証するテストフェーズがどの設計のフェーズを反映したモノかを表す図になっています。

 

そしてよく言われることとしては理想としては、例えば要件定義を行なったときに、総合テストの仕様書を作るのが良いと言われています(実際にはそのようには行かないのが常ですが・・・)

 

V字型モデルで無く、それぞれの工程を下へ下へと表す開発設計の流れ図もあります。それは滝のように流れる、という意味でウォーターフォールモデルと言われており、このモデルの方が一般には有名です。

 

 

開発発注側と開発委託会社の役割分担について

 

次に上記V字型モデルに即してシステム開発設計における開発発注側と開発委託側の役割分担について解説します。次の図をご覧ください。

 

 

図に示すとおり、発注側の役割は要求仕様を作ることと、総合テスト、受入テストを行なうのがメインとなります。

 

それでは要件定義、設計、実装、単体テスト~結合テスト については何も行なわずに開発委託会社に任せっきりで良いか?と言えばそんなことはありません。

 

必ず開発委託会社と各フェーズの完成度がどうなのかレビューすることが非常に重要です。

レビューの仕方に関しては以下の別記事をご覧ください。

システム開発の要件定義~開発設計におけるレビューの具体的なやり方について

 

開発委託会社側の姿勢として有りがちな事例

 

一つ前の項目で開発発注側が開発委託会社側と各フェーズでレビューを行なう事が重要という話をしましたが、実はあまり行なわれていない例が多いので、レビューの重要さを強調させていただいております。

 

これまでの経験でありがちな事例を図で解説します。

 

改めて文章で説明しますと、

・要求仕様の作成が曖昧で、要求仕様自体を開発委託先に丸投げする場合がある

・設計レビューを全く行なわない、または行なったとしても表面的な進捗確認で終わり、各フェーズの完成度のチェックを殆ど行なわない

・テストのフェーズにおいてもどのようなテストが行なわれ、どういう結果だったかのレビューを行なわない。

・総合テストや受入テストは発注側の役割なのにもも関わらず、あまり行なわず、委託先側に任しているケースもある。

 

こういった姿勢でシステム開発設計が”完了”して商品出荷をすると、

結果として、出荷後市場トラブルになり、商品回収などを行なわねばならない場合が出てきます。

実際この数年の様々な会社支援におきまして、こういうケースを幾つか見てきています。

 

発注側が作成する要求仕様書はシステム開発設計において極めて重要

 

良くシステム開発設計において、要件定義が重要と言われています。要件定義の重要性については以下の記事をご覧ください。

要件定義とは何か?MECEとの関係や、要求定義との関係を解説します

 

要件定義は、システム開発委託側が初めに行なう大変重要な作業になりますが、

システム開発発注側が初めに行なう大変な重要な作業が要求仕様書の作成になります。

 

要求仕様書とは?

要求仕様書とは、開発発注側が、開発委託先(委託会社)に対して、開発設計委託する内容を文書にしたものです。

 

発注側のシステムに対する考え方、思想が盛り込まれているのが要求仕様書になります。

発注側の会社において、商品企画書、商品提案書などが要求仕様書のベースになります。

開発委託先は、発注側から提示された要求仕様書に基づいて要件定義を行ないます。

開発発注側は、開発委託先が作成した要件定義の内容を入念に精査・レビューをして内容合意を行なうことが大変重要になります。

 

まとめ

この記事では、システム開発設計の一連の流れと 発注側と委託先の役割分担について解説をしました。

 

ポイントとしては、発注側も委託先に全て丸投げをするのではなく、一番初めに要求仕様書をきちんと作って提示した上で、委託先が作成した要件定義書を良くレビューして合意形成をした上で、委託先に設計、実装、テストなどを行なって貰い、

 

その各フェーズにおけるレビューをきちんと行い、その後の総合テスト、受入テストは発注側できちんと行なう事により品質の高い商品、システムを世の中に提供することが出来ると思っています。

 

 

ハートテクノロジーズ株式会社では、システム開発・要求仕様・要件定義・設計などについてのお困りごとをお聞きする30分~60分くらいのオンライン無料相談会を実施しております。

もしご希望の方は、以下の問い合わせフォームの”問い合わせ”欄に【無料相談会希望】と書いていただき、かつ可能であれば現在のお困りごとを書いていただければ幸いです。折り返しご連絡させていただきます。以下をクリックしてお申し込みくださいませ。

 

無料相談会希望

 

関連記事

 

RFPと要求仕様、要求仕様と要件定義、要件定義と基本設計それぞれの違い

RFPと要求仕様の関係とは?似ているところと違うところを解説!

要件定義の成果物の作り方をわかりやすく解説!

要求仕様と要件定義の違い

要件定義の歴史と現状の課題

コメントは受け付けていません。

Pocket

IoT関係でお悩みの企業様、独立して顧問へなりたい方、経験豊富な当社がサポートいたします!

お気軽にご相談下さい お気軽にご相談下さい arrow_right
PAGE TOP