##はじめに
2021年11月22日に経済産業省でシステム開発において重要な設計書・仕様書のレビュー工程のJIS規格が制定された。

JISC公式HPにてユーザー登録してJIS規格番号:JISX20246で検索すれば誰でも規格原文を読むことも可能です。
PDFにして40ページ程度なので苦労しないと読めないような代物ではありませんが、この記事では当該の原文を斜め読みした気分になれる概説を書いていこうと思います。

##概説

####序文
レビューの主な目的は要検討事項の検出・代替案の評価・組織及び個人のプロセス・作業生産物の改善である。
ソフトウェア開発において現場ごとに多種多様な開発手法やプロセスが採用されているが、そのような現場に対しても導入・適用が可能なレビューに関する汎用的なフレームワークについてこの規格で規定している。

######1.適用範囲、2.引用規格、3.用語及び定義、4.適合性は省略

####5.作業生産物レビュー
一般にレビューは作業生産物の欠陥を早期に検出することを主目的とし、参加者数やその役割・レビュー回数などのレビュー属性に応じて最適なレビュー種別を選択する。

※レビュー種別例

執筆者確認: 作業生産物の執筆者によって実施する非形式的レビュー
執筆者・レビュアによって要検討事項の検出と開発リスクの低減を目的とする
相棒確認: 執筆者の同僚によって独立して実施する非形式的レビュー
執筆者・レビュア・レビューリーダーによって要検討事項の検出と新規アイデアの発見を目的とする
インスペクション: チームの役割を定義した上で行う形式的レビュー
執筆者・レビュア・レビューリーダー・進行役・読み上げ係・記録係によって要検討事項の検出や品質評価、改善の動機付けを目的とする

####6.作業生産物レビュープロセス
基本のプロセスは下記の流れで進める。　

計画作業: レビュー目的・対象・終了基準・重点領域などを定義
レビューの立ち上げ: レビューリーダーからレビュー参加者にレビュー範囲・特性・役割を説明
執筆者が作業生産物を説明
個々人のレビュー: 各レビュアが作業生産物の要検討事項を識別するためのレビューを実施
要検討事項の共有及び分析: 識別された要検討事項を伝達
伝達内容が要修正か修正不要かを分析
要検討事項をチーム内で割り当て
修正作業及び報告作業: 修正を必要とする要検討事項に関するインシデント報告書を作成・チーム内に伝達
執筆者が要検討事項を対処
レビュー処置の完了を報告・確認

####7.レビュー手法
先述の個々人のレビューにおける手法は多岐にわたる。

●アドホックレビュー作業
進め方や指針を全く構造化・形式化していないレビュー手法で非常に一般的な手法である。
作業生産物を読み進めながら各レビュアがあらゆる種類の要検討事項を可能な限り見つけることが期待されているため、レビュアのスキルに大きく依存したり要検討事項の指摘内容が重複したりする。

●確認項目一覧に基づくレビュー作業
各レビュアに確認項目を割り当てて作業生産物を網羅的にレビューする手法である。
指摘内容の重複を防げる一方で、**レビュー対象の検討が確認項目一覧で挙げた内容に終始する傾向になるためその他の潜在的な要検討事項を見落とす可能性があり、**レビュアが確認項目のみに従ってレビューするのではなくより広くチェックする自覚を持つ必要がある。
また、確認項目が古くなり要検討事項の発見が少なくなる(見逃す)リスクもあるため、定期的に確認項目を更新する必要がある。

●シナリオに基づくレビュー作業
単純な確認項目一覧よりも詳細な欠陥検出のため読み取り指針をレビュアに周知させた上で、レビュアが対象の作業生産物を予想される使用法に基づいて予行演習し要検討事項を検出する手法である。
必要な機能そのものがレビュー対象に含まれていないなどシナリオによっては特に標的とされない部分の欠陥を見落とす可能性がある。

##まとめ

ハウトゥーではなくあくまで規格なので、特定のやり方を薦めるのではなく淡々と列挙している。
型張った文章なので明確な理解がしづらかった。
レビューを通しての本来の目的・ゴールの意識を持つ重要性が繰り返し説かれている。
現場の人数やスキル・開発期間などの要因から厳密に規格に則ったやり方を粛々と進めるのはやはり難しそう。定義された内容のいいとこ取りするために規格を利用するくらいの意識がちょうど良さそう。