時には人の意見にも耳を傾けよう〜レビュープロセス
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
久しぶりだねー？みんなは元気にしてたかな？
色々とやりたいこと、やらなきゃならんことが増えてブログが絶賛、停滞中だったよー！
そして、再開一発目はレビュープロセスのお話だよ。
レビューって、個人的には人が作った成果物にちゃちゃを入れたりして心苦しさを感じることもある苦手なお仕事の一つだね。
では、苦手だけど重要なレビューのお話のはじまりはじまりー
レビューとは
ソフトウェア開発とかIT系のお仕事で
「レビュー」
と言えばソフトウェア開発の全てのプロセス（工程）で作成された作業成果物に対して行う静的テストになるよ。
静的テストについては休止前に書いたので忘れた人は読んでみてね。
レビューには、非形式的と形式的なものがあるんだ。
非形式的レビュー
定義した特定のプロセスに従わず、レビューの結果を形式的に文書化しないよ。
柔軟に対応できるけど文書化しないことで後々、言った言わないで揉めることもあるので重要なポイントはメモ程度でも残しておくのがいいね。
形式的レビュー
レビューを行う際の手順を文書化したりルールが作られたりしていて、その手順やルールに従いチームで参加して、レビュー結果を定められたフォーマットで文書化、記録するんだ。
チームでの参加やルールがあるので柔軟な対応はできないけど形式的に記録されているので後で見返したり再確認する時に有効と言えるね。
非形式的だけどルールがあったり記録を残す形式的に近いケースや形式的だけど内部で完結するからフォーマットが簡素化されているケースとか、組織やプロジェクト、目的によって形式的と非形式的を分けて考えるのが難しい場合もあるから、レビューする前にしっかりと確認しておくことをオススメするよ。
JSTQB FLシラバスでは以下の記述があるので、どんな要素があるか、レビューの焦点の違いを覚えておこうね。
レビュープロセスの形式は、ソフトウェア開発ライフサイクルモデル、開発プロセスの成熟度、レビュー対象の作業成果物の複雑さ、法律や規制から生じる必要性、そして/または監査証跡の必要性などの要素で決まる。
レビューの焦点は、レビュー目的として合意したこと(例えば、欠陥の発見、内容の理解、テスト担当や新しいチームメンバーなどの参加者に対する教育、協議での判断の合意)により異なる。
作業成果物のレビュープロセス
ここでは大まかなレビュープロセスとポイントを紹介するので詳しくはJSTQB FLシラバスを見てね。
計画
レビューの範囲、役割分担、開始/終了基準、工数の算出などレビューの進め方、方針を決めるプロセスだよ。
レビューの開始
作業成果物や他の資料の配布、レビューの範囲、目的、プロセス、役割など計画で決めた内容を参加者へ伝達、その後、参加者からの質問回答など行うプロセスだよ。
個々のレビュー(個々の準備)
配布された作業成果物のレビューを行い潜在的な欠陥、提案、質問を書き出していくよ。
懸念事項の共有と分析
潜在的な欠陥に対する議論や分析を行い、担当と対応状況を割り当て、品質特性の評価や文書化したりもするんだ。
また、レビューで見つけた欠陥を終了基準に対して評価し、レビュー判定を行うプロセスでもあるよ。
修正と報告
レビュー結果から欠陥の対処、方針を決定し修正や議論を通じて終了基準の到達、成果物の受け入れまでのプロセスになるよ。
形式的レビューでの役割と責務
形式的レビューではルールに従ってレビューを行うとされているけど、その中で役割とその役割が果たす責務が定められている場合もあるんだ。
JSTQB FLシラバスでは形式的レビューで一般的に含まれる役割として6つの役割が書かれているよ。
作成者
• レビュー対象の作業成果物を作成
• レビュー対象の作業成果物の欠陥を修正
マネージャー
• レビューの計画
• レビューの実行を決定
• 担当者、予算、時間を割り当て
• 費用対効果を継続的にモニタリング
• 不適切な結果が発生した状況に対してのコントロール
ファシリテーター
(一般的にモデレーターと呼ばれる)
• 効果的なレビューミーティングを運営(開催時)
• さまざまな意見の調整(必要な場合)
• レビューの成功を左右する重要な役割
レビューリーダー
• レビューに関して全体的な責任を持つ
• 参加者の人選、レビュー実施の期間と場所を決定
レビューア
• 成果物のレビューを実施する
（特定分野の専門家、プロジェクトの従事者、作業成果物に関心のあるステークホルダー、特定の技術や業務のバックグラウンドを持つ個人など）
• レビュー対象の作業成果物の欠陥を識別
• それぞれに異なる観点でレビューを行う
書記(記録係)
• 個々のレビュー活動の期間に見つかった潜在的な欠陥を照合
• (開催時に)レビューミーティングで見つかった新しい潜在的な欠陥、未決事項、決定事項を記録
レビュータイプによっては一人が複数の役割を担当することもあるんだ。
マネージャーとレビューリーダーを兼任したり、更にファシリテーターの役割も含めて一人三役になることも多いんじゃないかな？
レビュープロセス、役割と責務も既にお馴染みになった組織やプロジェクト次第だから実際の現場ではその違いを理解して取り組んでみてね。
ここではあくまでJSTQBをベースにした基礎知識として覚えておくことで自分の担当するお仕事の改善点が見えてくるんじゃないかな？
では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？