IoTでも業務管理でも。所謂システム開発設計において重要なのはレビューです。別記事で要件定義が非常に重要と言うことを記しましたが、さらに実際の開発フェーズにおいて重要なのがレビューになります。

レビューに関しまして、結構学問的に、理論的に記述された文献などはあるのですが、意外なほど開発設計現場に密着した形で書いているものが少ないので、この記事では、できる限り現場目線で、開発の各フェーズでレビューをどのように行なえば良いのかについて解説していきたいと思います。

開発設計全体で重要なのはレビュー

これから記すレビューというのは開発において開発発注側、委託先側両方行なうものになります。その役割分担含めて解説していきます。

まず、開発設計全体において、開発委託先側、発注者側それぞれが行なうことを記します。

開発委託先側が行なうべきこと

開発スケジュールにおいて、要件定義⇒基本設計（システム設計）⇒詳細設計⇒実装⇒単体テスト⇒結合テストまでは間違いなく開発委託先側行なうべき業務となります。

開発発注者側が行なうべきこと

初めの要求仕様の提示から始まり、要件定義内容の承認を経て、最終的にシステムが出来上がってきたときの総合テスト、出荷などが開発発注者側の役割で有ることは間違いありません。さらには要件定義～結合テストにいたる工程において丸ごと開発委託先にお願いして何も行なわないのでなく、開発委託先が行なう設計やテストの内容についてレビューを実施し、その工程の成果について検収することが極めて重要になります。

開発発注側がその分野の専門家でなかったり経験が浅かったとしてもレビューを行なうことが重要

開発発注側は実はシステム開発の詳細について知識・経験が無い場合も多いと思います。それでもレビューを行なうべきと言うのが筆者の考えです。レビューにおいてたとえ技術的な内容、設計詳細内容について指摘できなくても構いません。ユーザー目線での指摘、実際にシステムが使用されることを想像しての指摘で構いません。　レビューを行なうことによって開発委託先の設計者に、誤りなどの”気づき”を促すのが極めて重要になります。

そもそもレビューとは？

レビューは一般に開発設計においてはデザインレビューと言われます。（テストに関するレビューは、テストレビューで良いと思いますが・・・）

デザインレビューとは、書き発設計フェーズにおいて各フェーズ毎に、そのフェーズで行なうべき作業が完了したかどうかを、設計ドキュメントなどに基づいて設計者から説明を受け、その内容について質問や指摘をしてた上で、次のフェーズに移って良いかを見極めることです。

ただしデザインレビューはそれぞれの工程の最後のみで行なうわけでは無く、工程の途中段階で行なうこともあります。その場合は、上記のような”完了見極め”をするのが目的では無くて、途中段階の設計完成度を見極めることが目的になります。

検収とは？

レビューの結果として行なうのが検収になります。ここでは検収とはどういう作業であるかを記します。

検収とは、発注に応じて委託先から納められた品を、注文の際の品質条件、数量、仕様に合っているかどうかを確かめた上で、受け取ることを言います。

システム開発設計においては、仕様通り出来ているかをチェックすることが非常に重要になります。

最終的に仕様通り出来ていて問題無いと　OKを出すことが重要です。

デザインレビュー自体、検収のアクションに含まれるともいえます。

無料相談会希望

関連記事はこちらです

⇓

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

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

ハートテクノロジーズ株式会社では、この記事にあるような要件定義の仕方、さらには要件定義含めてシステム開発を行なうためにはどのようなステップを踏んだら良いかなどについて御社の課題に即してご説明したり、具体的なプロジェクトを回すご支援もしております。ご興味・ご関心ある方はお問い合わせいただければ幸いです。

お問い合わせはコチラをクリックください！