レビューについて（ＳＥの方にとくにおうかがいします）

質問

こんにちは。
情報系の学科に通う学生です。
今度学校でソフトウェアの開発工程であるレビューについて話し合いをします。
連休中にいろいろと調べているのですが、私が想像していた以上に、
レビューには種類、回数があるらしく戸惑ってしまいました。

そこで、実際のＳＥの方は、どういった時にどのようなレビューをしているのか。
また、レビューの重要性や経験談など・・
なんでもいいので教えていただきたいなと思って質問させていただきました。

実際に開発などに携わったことのない学生なので、
とんちんかんな質問をしてしまっているのかもしれませんが、
身近にＳＥの先輩など、聞ける人がいないので困っています；

どうぞよろしくおねがします。

回答No.1

noname#94337 · ベストアンサー

はじめまして　jcg02524です。

※自分の会社でやっている内容を回答とします。

まずは前提・・・
以下の工程でソフトウェアシステムを作成します。
※各工程の意味については調べましょうね。
(1)要求定義
(2)要件定義
(3)システム計画
(4)基本設計
(5)詳細設計
(6)プログラム作成＋単体テスト
(7)結合テスト
(8)総合テスト
(9)リリース
※ビジネス上の工程は上記の倍くらいあります。取り合えず代表として書きます。
この各工程にレビューといわれるものが存在します。

さて、回答・・・
そもそも、レビューとは「批評し、論じること」ですから少なくとも一人でやるものではありません。
社内では基本的にＳＥ以外に「上司」「お客様（要求者）」などの複数の方の目で確認する場だと思えば良いでしょう。
※当然なのですが各工程の説明には資料が必要です。
ソフトウェアシステムの構築にあたり、出来上がったシステムが要求した通りのものを作ることが目的ですので確実に行う必要があります。
そのため、少なくてもレビューは各工程の「開始」と「終了」時に行います。
「開始」とは該当工程を始める際の「手順（計画）」「期間」等に関する要求者の承認を貰うことになっています。
また「終了」は「計画通りに終了したか」「やり忘れなどが無いか」を確認し、確実に該当工程が終了したことを証明し、要求者の承認を貰うことです。
※各工程の進捗を確認することもレビューの一つです。
この繰り返しを各工程で行い、リリース時に間違いなく要求に沿ったものが出来上がるのです。

失敗要因として・・・
「人の勝手な思い込み」などが失敗の要因のほとんどです。
ちなみに「期間」の遅延もレビューの甘さから要求者との問題になりやすいです。
少なくてもここを確認していけば良いでしょう。

こんな感じですが回答とします。

回答No.2

etc-etc

１番の方が素晴らしい回答をされているので、
少しだけ補足を、
レビューは各工程毎に行いますが、レビューの回数は必ずしも決まっていません、
例えば「要件定義」のレビューを行う場合、
予めチーム内での内部レビューを行う場合もあります、
（この必要性はシステムの難度や、開発要員のスキルにもよります）
内部レビューで問題なければ、次にユーザーレビューに進む、
という進め方です、
そして、レビューという作業においては必ず「レビュー報告書」が必要になります、
この報告書により、レビューで出た指摘事項や、仕様の再検討が必要な事案などを逐一記述します、
（再レビュー時に、この報告書を元にして、前回指摘分が解消されているかの確認に使います）

レビューの進め方については、案件毎（ユーザー毎）によっても違ってきますが、必要性については共通です。