この記事は「JCSQE全く分からなかったよね反省会を試験前からやるかなカレンダー」21日目の記事です。
21日目は問題32：リリース可否判定から、製品出荷判定の基本事項に関する問題です。
き、基本事項、、（^ω^;）（前もこの書き出ししたような
ええとすくぼっく v3でいくと、P119ですね。
＞リリースは、プロセスの次の段階または次のプロセスに進めることを意味し、リリース可否判定とは、これを判定することである。
なるほど、出荷だけではなく、プロセスの最後の判定ってことですね。
確かにこのプロセスまでおわったよー（＾＾）/という判定なしに次に進んでヤバい品質だと
「いったいこの前のプロセスでは何をみていたのか・・というかこの前のプロセスで拾った方が早かったんじゃ」となりそうです。
＞リリース可否判定は、これを通じてプロセス進捗が公式な形で明らかになるため、プロジェクトマネジメントにおいては特に必要なチェックポイントである
確かに。。プロセスが定義されていなかったらプロセスの始まりも最後もないですもんね。
種類は、開発の各工程の終了、製品出荷、本稼働があるとのこと。
問題32はこのうちの、製品出荷についての問題ですね。
ざっくりと「判定者の体制を決める」「合格基準を決める」「不具合の場合の対応をとる」に分かれています。
判定責任者はサービス提供の責任者などなど（すくぼっくを読んだ方が正確）
製品出荷判定や移行判定はステークホルダーや関係者も交えて出荷判定会議や移行判定会議が開催されるとのこと。
言われてみれば確かにそんな感じかもしれません。
そして合格基準については、残存障害がゼロになったは証明できないので
見える範囲で測定可能な感じの内容で「これで合格でよいよね」を定める必要があるっぽいです。
おおざっぱに、プログラム品質の合格基準、ドキュメント品質の合格基準、判断の前提基準。
特に「判断の前提基準」は、「すべて合格になっている」などでは測れないドキュメントの質やプロセスの状態、後部門（保守・サポートなど）へ連絡したかなど
結構複合的に判断する必要がありそうです。不合格の場合の対応もしかり（特別採用の考え方など）
プロセス化するにしても「これだけ合格すれば大丈夫」という判定の仕方ではなく
考慮しうる内容（テストの質、他部門への連絡、バグの収束状況など）を考慮して判定できるようにしておきたいですね。
どこ目線で話しているのかよくわからなくなってきたのでここまでで。。
参考：
初級ソフトウェア品質技術者資格試験（JCSQE)問題と解説【第3版】P19、P77～79
SQuBOK v3 P119～121
