prism

1つの成果物を独立した視点に分け、それらが一致する点と一致しない点を返します。

目標

結果は、各視点が一致する点、意見が分かれる点、そして意見の相違を解消するための最小限の質問を示すものです。チェックリストではなく、決して平均を取ってはいけません。視点の平均を取ることこそ、このスキルが防ごうとしている失敗です。

ワークフロー

1. 視点を選ぶ前に、成果物を最初から最後まで読みます。
2. 真に異なる失敗モードごとに、視点を1つ選びます。正確性、セキュリティ、読みやすさ、コスト、敵対的なユーザーなどです。同じ失敗モードを共有する候補の視点は2つではなく、1つの視点です。実際には2～5個に収まります。2個未満では合意するものがなく、5個を超えると、重複する視点で水増ししていることがほとんどです。デフォルトの個数はありません。成果物に固有の失敗モードによって決まります。
3. 各視点を通して、最も決定的な理由を1つ添えた、1行の判定を出します。判定は「合格」「不合格」「不明」のいずれかです。理由を列挙して保留するのは禁止です。決定的な理由でなければ、削除します。
4. 判定を比較し、完全な一致、異なる理由による一致、意見の相違に分類します。
5. 意見の相違がある場合は、その答えによって意見が一致するか、担当者が明確な形で決着する、次の質問を1つ挙げます。出力するのはその質問であり、個々の判定ではありません。
6. すべての視点が一致する場合は、少なくとも2つの視点で決定的だった理由とともに、共通の判定を返します。

ルール

• 役割ではなく、独立した視点を使います。「セキュリティレビュー担当者」と「上級セキュリティレビュー担当者」は2つではなく、1つの視点です。
• 各視点の理由は、決定的なものを1つだけにします。理由を列挙する視点は、判断を保留しています。
• 意見の相違こそが成果です。すべてに同意するプリズムなら、実行する必要はありませんでした。
• 決して平均を取りません。2つの視点が分かれた場合、答えは意見を解消する質問であり、中間地点ではありません。
• その成果物に合わせて、視点を毎回新たに選びます。仕様に有効な視点が、移行には役立たないことがあります。成果物をまたいで視点を引き継いではいけません。
• 意見の相違を無理に作り出してはいけません。相違が見つからなければ、共通の判定を返して終了します。
• ユーザーが意図して呼び出す機能です。複数の視点を使うのは任意の追加コストであり、それらの収束を自動的な証明のように見せてはいけません。そのため、意図的に選ばれた場合にのみ実行します。

検証

結果はチェックリストではなく、各視点が一致した点、意見が分かれた点、重要な質問を1つ示す全体像になっています。読者はプリズムをもう一度実行しなくても、次に何をすべきか判断できます。次に何をすべきか知るために再実行が必要なら、ステップ5を省略しています。