質問と適用されるシナリオ
非エンジニアのステークホルダーに複雑な技術トピックを説明しなければならなかった経験について教えてください。相手は何を理解し、判断し、実行する必要がありましたか？相手の既存知識や優先事項をどのように把握し、重大なリスクを隠すことなく詳細を削ぎ落とし、相手が理解したことをどのように確認し、結果をどのように測定しましたか？
これは、現在の公開されている面接準備資料において直接文書化されている行動面接の質問です。2026年に更新されたAlgoMasterのページでは、候補者が複雑な技術概念を非エンジニアのステークホルダーに説明した経験を尋ねており、ストーリーをステークホルダーの意思決定に結び付けるようアドバイスしています。Qcardの2026年ソフトウェアエンジニアリング行動ガイドにも同様の質問が含まれています。Amazonの公式面接ガイダンスでは、行動質問に対する回答にSTAR形式を推奨しています。Googleのテクニカルライティングガイダンスでは、コミュニケーション方法を選択する前に、読者の役割、トピックとの距離感、既存の知識、専門用語への精通度を特定することを推奨しています。
この質問は、エンジニア、データアナリスト、プロダクトマネージャー、デザイナー、リサーチャー、テクニカルリードに該当します。ステークホルダーは、顧客、営業担当者、オペレーター、財務パートナー、弁護士、経営陣、または部門横断の同僚である場合があります。「非エンジニア（非技術者）」とは、その人が自分と同じ専門的コンテキストを共有していないことを意味し、能力が劣っていることを意味するわけではありません。優れた回答は、ステークホルダーに敬意を払い、技術的な事実を相手が業務を遂行するために必要な判断へと変換します。
リリースするかどうか、段階的ロールアウトを実施するか、リスクを受け入れるか、スコープを変更するか、リソースを承認するか、制限事項を顧客に伝えるかなど、実際の影響を伴うストーリーを選択してください。「プレゼンテーションを行って好評を得た」というだけでは、説明によって何が変わったのかが伝わりません。ストーリーは単なる話術以上のものを示す必要があります。何を残し、何を削ぎ落とすかをどのように判断したか、そして誤解をどのように発見し修正したかを明らかにしなければなりません。
この記事は特定の企業に帰属するものではありません。以下の回答例は完全に架空のものであり、構造を示すことのみを目的としています。期間、パーセンテージ、アカウント数、結果はすべてプレースホルダーデータであり、あなた自身の経験に基づく証拠に置き換える必要があります。
面接官が評価するポイント
1つ目のシグナルは読者モデリング（オーディエンスの把握）です。ステークホルダーの役割、既存の知識、意思決定権限、時間的制約、優先事項を把握しましたか？同じ認可システムであっても、説明内容は異なります。サポートリーダーには顧客への影響と復旧手順が必要であり、財務リーダーにはコストとリスクが必要であり、技術面の同僚にはデータモデルが必要になります。エンジニア相手と同じ語彙を繰り返すことは、内容を固定化された台本として扱っていたことを示唆します。
2つ目のシグナルは意思決定から始めることです。成熟した回答では、まず「この人物は会話の後に何を決定しなければならないか？」を提示し、そこから逆算して必要最小限の情報を導き出します。説明とは、すべての実装の詳細を5分間に圧縮することではありません。情報に基づいた判断力を持って、選択肢、結果、不確実性を比較できるようにすることです。
3つ目のシグナルは正確な単純化です。内部実装の名前、頭字語、無関係な経緯を削除したからといって、因果関係の連鎖まで削除してよいわけではありません。ある制限によって顧客の正当なアクセスが拒否される可能性がある場合や、移行に信頼できるロールバック手順がない場合、ステークホルダーはその影響、トリガー条件、緩和策を知る必要があります。責任ある単純化は、原因、結果、選択肢を保持します。無責任な単純化は「任せてください、リスクは管理されています」という言葉しか残しません。
4つ目のシグナルは言語化・翻訳です。メカニズムを、ステークホルダーが責任を持つ成果（顧客体験、収益コミットメント、コンプライアンス義務、運用負荷、納期、可逆性など）に結び付ける必要があります。たとえ話、図、具体例は参入障壁を下げるのに役立ちますが、それぞれ補助的な手段にすぎません。たとえ話が不完全な場合は、ステークホルダーが誤ったモデルに基づいて判断を下さないよう、その限界を明示してください。
5つ目のシグナルは双方向の検証です。「お分かりいただけましたか？」という質問には、通常、儀礼的な「はい」しか返ってきません。より適切な証拠としては、ステークホルダーにトレードオフを自分の言葉で言い直してもらう、選択肢を1つ選んでその理由を説明してもらう、実際の顧客シナリオに沿って確認する、停止条件と次のステップを共同で文書化する、などが挙げられます。相手の回答から誤解が明らかになった場合は、読者を責めるのではなく、説明を調整してください。
6つ目のシグナルは成果と貢献の帰属です。結果は「相手が頷いた」だけで終わってはいけません。面接官は、意思決定がより明確になったか、不正確なコミットメントが回避されたか、リスクが正しく受容または緩和されたか、下流の実行における手戻りが減少したかを知りたがっています。自分自身の貢献、ステークホルダーの意思決定、チームの納品を正確に区別してください。
最後に、面接官はあなたの態度を観察しています。相手を「技術を理解できない」と表現したり、「噛み砕いて説明しなければならなかった」と言ったりすることは、見下すような態度を示唆します。より強力なフレーミングは、ステークホルダーがビジネス、顧客、組織のコンテキストを保持しており、あなたはその場の意思決定に必要な技術モデルを提供していると認識することです。判断は共同で下されるものです。
回答前に明確にすべき質問
- ステークホルダーは何を決定しなければならなかったか？ 決定事項がなかった場合は、具体的な行動や行動の変化を特定してください。会話後の望ましい状態を書き出してください。
- なぜこの技術トピックに説明が必要だったのか？ ストーリーを複雑に見せるためだけに背景を追加するのではなく、顧客、コスト、スケジュール、コンプライアンス、品質、または運用に結び付けてください。
- 相手はすでに何を知っていたか？ 役職に基づくステレオタイプではなく、過去の会話、責任範囲、質問、既存の資料からこれを推測してください。
- 相手にとって最も重要だったことは何か？ コミットメントを守ること、リスクを可逆的に保つこと、リソースを管理すること、責任を割り当てること、あるいは別の決定がいつ必要になるかを知ることだったかもしれません。
- 削ぎ落とせなかった事実は何か？ 選択される選択肢を変える可能性のある前提、制限、不確実性、リスク、または復旧条件をすべて保持してください。
- どのような選択肢が存在したか？ 少なくとも2つの代替案と、スピード、スコープ、リスク、コスト、または可逆性におけるトレードオフを説明してください。
- 理解度をどのように検証したか？ 「質問があるかどうか尋ねた」だけでなく、観察可能な行動を用意してください。
- 自分自身は個人的に何を行ったか？ 読者をどのように調査し、資料を構成し、誤解に対応し、説明を変更したかを説明してください。「私たちはコミュニケーションをとった」という言葉の後ろに隠れないでください。
- 失敗したコミュニケーションの例を使用できるか？ はい。初期の誤った仮定、それをどのように発見したか、どのようにリカバリーしたか、そして事後に変更したルールを特定できるのであれば可能です。
- たとえ話を使用できるか？ はい。ただし、正確であり、その限界が明示されている必要があります。たとえ話が実際のトレードオフに取って代わることはできません。
このディシジョンカードを使用して、考えられるストーリーをスクリーニングしてください。最初の3行を記入できない場合、その経験はおそらく十分に具体的ではありません。
Stakeholder: [role and proximity to the topic]
Decision required: [specific choice or action]
Minimum causal model: [cause -> consequence -> choice]
Risk that cannot be omitted: [limitation or uncertainty that changes the decision]
Evidence of understanding: [teach-back, rationale, scenario, or next action]
Evidence of outcome: [decision quality, risk treatment, or downstream execution]30秒回答フレームワーク
意思決定を中心としたSTARチェーンを使用します。
「[状況]において、[非エンジニアのステークホルダー]は[具体的な事項]を決定する必要がありましたが、[技術的な仕組みや制約]のために選択肢の比較が困難でした。私の役割は、実装全体を教えることではなく、[時間やビジネス上の制約]の中で相手に十分な理解を提供することでした。私は[質問や根拠]を用いて相手のコンテキストと優先順位を把握し、説明を[最小限の因果モデル]に絞り込み、[図、例、または限定的なたとえ話]を用いて[選択肢とトレードオフ]を示し、[重大なリスク]を明示しました。[ティーチバック、シナリオ、または決定の根拠]を通じて[誤解]を発見し、修正しました。その後、相手は[決定]を下し、[検証可能な結果]につながりました。現在では、同様のコミュニケーションに[特定の新しいルール]を適用しています」
30秒バージョンは骨子を提供します。完全な回答では、行動（Action）に大半の時間を費やしてください。なぜその説明方法を選択したのか、正確さと簡潔さをどのように両立させたのか、誤解をどのように発見したのか、なぜ軌道修正したのかに焦点を当てます。回答の大半を技術的背景の羅列に費やさないでください。
ステップバイステップの詳細な回答
ステップ1: コミュニケーションによって意思決定が変わったストーリーを選択する
最も強力なストーリーには、4種類の証拠が含まれています。相手が特定の専門的コンテキストを真に欠いていたこと、重大な意思決定を行う必要があったこと、あなたに説明の設計や主導の責任があったこと、そして観察可能な結果が続いたことです。リリースのスコープ、メトリクスの定義、技術的負債のリスク、セキュリティ制約、インシデント復旧、顧客統合など、すべてが機能し得ます。決定は本物でなければなりません。
単なる一方的なデモンストレーションにすぎないストーリーは避けてください。ステークホルダーがどのような誤った判断を下す可能性があったか、説明後に何が変わったかを言えない場合、そのストーリーから得られる情報はほとんどありません。また、設問に「複雑な」とあるからといって、最も難解なトピックを選ぶのはやめましょう。複雑さは、読者、制約、トレードオフから生じるものであり、専門用語の数から生じるものではありません。
ステップ2: 意思決定から逆算する
まず1つの文を書き出します。「会話の終了時に、ステークホルダーはA、B、Cの中から選択し、どのような条件でその選択が無効になるかを知る必要があった」。次に、各技術的詳細を検証します。それは選択肢、リスク判断、または次のステップを変えるものですか？そうでない場合は、削除するか、補足資料として保持してください。
必要最小限の十分な因果モデルを保持します。なぜ問題が発生する可能性があるのか、誰に影響するのか、いつ拡大するのか、どのような選択肢が存在するのか、各選択肢で何を犠牲にするのか、チームは障害をどのように検知し復旧するのか。このモデルは、すべての技術的内容を削除するよりも信頼性が高く、アーキテクチャを上から下まで説明するよりも有用です。
ステップ3: 思い込みではなく証拠を用いて読者を評価する
会話の前に、「本日下さなければならない決定は何ですか？」、「すでにご覧になった資料は何ですか？」、「スケジュール、顧客への影響、可逆性のうち、どれを最も懸念されていますか？」などの質問を投げかけます。過去の質問や責任範囲も証拠となります。「Xをご存知ですか？」といった質問で会議をテストのようにするのは避けてください。現在のタスクを活用して、共通の出発点を確立します。
さまざまな読者が混在する場合は、共通の決定モデルを提示し、深度を階層化します。第1層には結論、トレードオフ、推奨事項を含めます。次の層にはリスクの根拠とシナリオを含めます。実装の詳細は、フォローアップのために参照可能な状態にしておきます。これにより、全員に同じ深度を強制することなく正確性が保たれます。
ステップ4: 仕組み、影響、選択肢を言語化する
内部用語を外部への影響に変換します。「キャッシュ無効化戦略」から始めるのではなく、「同じ顧客に2つの状態が一時的に表示される可能性があります。その不整合を許容するか、復旧手順が検証されるまで延期するかを決定する必要があります」から始めます。専門用語は必要な場合にのみ定義し、定義した後は一貫して使用します。
有用な順序は、1つの結論、1つの因果関係、2つまたは3つの選択肢、明確な推奨案、そして新たな決定を促すトリガー条件です。図には、現在の選択に関連するノードのみを表示する必要があります。たとえ話は短く保ち、その限界を明示してください。「このたとえ話は段階的な置き換えを説明しています。実際のシステムには自動継承もあるため、個別の認可チェックが依然として必要です」
ステップ5: 不確実性とトレードオフを明示する
簡潔さを理由に悪いニュースを隠してはなりません。確率が不明な場合は、不確実性の原因、それをどのように減らせるか、残りのリスクを誰が所有するかを説明します。チームが時間のかかる選択肢を推奨する場合は、追加の時間をそれが排除するリスクに結び付けます。推奨案が迅速なものである場合は、停止条件と復旧コストを明記します。
ステークホルダーは、あなたの推奨とは異なる選択肢を選択する場合があります。事実が理解され、権限が適切であり、リスクが許容範囲内にとどまっている場合、効果的なコミュニケーションは相手に自分の好みを押し付けることを必要としません。あなたの推奨事項、意思決定者の選択、そして実行をどのようにサポートしたかを述べてください。
ステップ6: 観察可能な行動を通じて理解度を検証する
「質問はありますか？」と尋ねるだけに頼らないでください。ステークホルダーに選択肢の比較を促します。「リリース日を変更できない場合、どの選択肢を選び、どのような残余リスクを受け入れますか？」。あるいは、シナリオに沿って確認します。「ある顧客が以前の権限モデルのままであると仮定します。その顧客には何が見え、どのようなシグナルで作業を停止しますか？」
言い直しが間違っている場合は、用語、因果関係のリンク、例、またはリスクの境界のどれが原因であるかを特定します。一部分を言い換えて、ステークホルダーに新しいケースへの適用を依頼します。検証はステークホルダーを試すためのものではありません。あなたのコミュニケーションが意思決定をサポートしているかどうかのテストです。
ステップ7: 意思決定の質と下流の成果を測定する
3つの層の結果を使用します。ステークホルダーは選択肢とリスクを正確に説明できましたか？チームは決定事項と停止条件を記録しましたか？実行によって不正確なコミットメント、手戻り、インシデント、または不必要な遅延が回避されましたか？ビジネスメトリクスが存在しない場合は、決定記録、改訂されたロールアウトスコープ、指名されたリスクオーナー、顧客コミュニケーション計画などの検証可能な成果物を使用してください。
因果関係を過剰に主張しないでください。あなたの説明は選択を可能にしたかもしれませんが、最終的な結果を生み出したのはエンジニアリングの納品、運用の準備状況、そして意思決定者の判断です。正確な貢献の帰属がストーリーの信頼性を高めます。
ステップ8: 再利用可能で具体的な振り返りで締めくくる
「コミュニケーションが重要であることを学びました」という言葉には何の情報も含まれていません。変更した仕組みを1つ挙げてください。以前は技術的な経緯から始めていたが、現在は決定に関する文から始めるようになった、以前は「お分かりいただけましたか？」で終わっていたが、現在はステークホルダーに停止条件の言い直しを求めるようになった、以前はたとえ話に限界の提示が欠けていたが、現在は各たとえ話がカバーしていない範囲を述べるようになった、などです。
最初の説明が失敗した場合は、リカバリーのアクションとコストを説明してください。真の自己修正は、誤解が一度も生じなかったと主張するよりも、往々にして高い能力を証明します。
高品質な回答例
以下は完全に架空の構造例であり、個人の経験として提示してはなりません。「3日」、「10% -> 50% -> 100%」、「120アカウント」、「認可インシデント0件」はすべてサンプルのプレースホルダーです。これらは真実かつ検証可能な証拠に置き換えてください。数値の証拠がない場合は、決定記録、スコープの変更、または指名されたリスクオーナーを使用してください。
「私は新しい認可モデルのリリース準備を担当していました。営業部門は顧客向けのリリース日を伝えていましたが、エンジニアリングレビューにより、一括切り替えを行うと、従来のロールが新しいルールに変換される間にアクセスの不整合が生じる可能性があることが判明しました。市場投入（Go-to-Market）リーダーは、直接切り替えで日程を維持するか、段階的ロールアウトを行うか、延期するかの選択を迫られていました。元の資料は、ロールの継承、マイグレーションスクリプト、キャッシュの更新に関する内部用語で埋め尽くされていました。
私の役割は、認可アーキテクチャ全体を教えることではありませんでした。どの顧客が影響を受ける可能性があるか、リスクがいつ発生するか、各選択肢で何を犠牲にするか、どのようなシグナルで停止が必要になるかを示すことでした。私はまず、その日にどの顧客へのコミットメントを確認する必要があるか、どの結果を最も懸念しているかを尋ねました。彼は、すべての顧客アカウントを同じ日に有効化することよりも、顧客が突然認可された機能を失うのを防ぐことの方が重要だと答えました。私はその優先事項を中心に、説明を1ページの決定文書として書き直しました。
私は結論から伝えました。直接切り替えは最も迅速ですが、復旧が最も困難です。段階的ロールアウトは運用の調整に[サンプルのプレースホルダー: 3日]追加されますが、影響範囲を観察可能なグループ内に抑えることができます。延期は技術的リスクが最も低いものの、すでに伝達された日程を変更することになります。私は1つの因果関係を保持しました。レガシーロールを新しい権限に変換する必要があり、変換または状態同期でケースが見逃された場合、同一アカウント内のユーザー間で異なるアクセス結果が生じる可能性があるという点です。
私は、占有中の建物でフロアごとに鍵を交換するたとえ話を用いて、なぜ段階的に行うと障害を発見しやすくなるのかを説明しました。また、その限界についても述べました。ソフトウェアの権限は自動的に継承されるため、各フロアを確認しても移行検証の代わりにはならないという点です。私は[サンプルのプレースホルダー: 10% -> 50% -> 100%]の段階を提案し、停止条件を明示的に記述しました。不正アクセス、正当なユーザーのブロック、または合意されたしきい値を超える復旧時間です。
最初の説明の後、私は『理解できましたか？』とは尋ねませんでした。重要な顧客の1社を想定してシナリオを確認してもらいました。最初のグループでアクセスの問題が報告された場合、何を一時停止し、顧客に何を伝え、誰が復旧を承認するのか。彼は『拡大の一時停止』を『すべてのアカウントの即時ロールバック』と解釈しました。私は、自分の図が一時停止とロールバックを1つのアクションに統合してしまっていたことに気づきました。私はそれらを2つの決定に分離し、すでにリリースされたアカウントはロールバック条件が満たされた場合にのみロールバックされることを説明しました。
彼は段階的ロールアウトを選択し、日程は維持されるもののアカウント群が分かれることを自ら営業部門に説明しました。エンジニアリング、サポート、営業は、停止条件とコミュニケーションの責任者を共同で確認しました。実際の回答で置き換える必要のあるプレースホルダー結果を用いると、最初の段階は[サンプルのプレースホルダー: 120アカウント]を対象とし、[サンプルのプレースホルダー: 認可インシデント0件]を達成し、次の段階の前に早期シグナルを通じてサポート文書の曖昧さを明らかにしました。
Go-to-Marketリーダーが決定を下し、エンジニアリングとサポートがリリース検証を実施しました。私の貢献は、実際の意思決定を特定し、最小限の因果モデルを書き直し、選択肢とリスクを提示し、シナリオを用いて自身の説明の不備を発見したことでした。現在では、部門横断的な技術ディスカッションの前に必ず1つの意思決定目標を書き出し、『全員理解できましたか？』を『実際のシナリオを1つ確認してください』に置き換えています」
この構造をカスタマイズする際は、認可モデル、リリース日、すべてのプレースホルダーを削除してください。まず、6つの事実に基づいた文を作成します。誰が何を決定しなければならなかったか、なぜ元の説明が失敗したか、どのように読者を評価したか、どの因果モデルを保持したか、理解をどのように検証したか、どのような決定と下流の結果が続いたか。次に、個人的に行ったトレードオフを1つ、会話後の修正を1つ追加します。
よくある間違い
- システムアーキテクチャから始める。 読者はどの詳細が決定に重要であるかを推測しなければならなくなります → 決定、結論、影響から始め、必要に応じて仕組みを展開してください。
- 「非エンジニア」を「能力が劣る」とみなす。 これは見下した態度や不正確な思い込みを生み出します → 役割、既存の知識、現在のタスクから必要な情報を特定してください。
- 簡潔さを保つためにリスクを隠す。 ステークホルダーが誤った前提に基づいてコミットメントを行う可能性があります → 決定を変更する可能性のある制限、不確実性、復旧条件を保持してください。
- 因果関係を説明せずに専門用語を言い換える。 「結果整合性（Eventual Consistency）」を「少し時間がかかる」に変更するだけでは依然として不十分です → 誰がどの違いを、どのくらいの期間確認し、それがいつ許容できなくなるかを述べてください。
- たとえ話を重ねる。 たとえ話が別の誤ったモデルを生み出す可能性があります → 現在の決定に役立つたとえ話を1つ使用し、その限界を明示してください。
- 会議を独白にしてしまう。 洗練されたスピーチでは誤解を浮き彫りにすることはできません → 決定ポイントで質問、選択肢の比較、またはシナリオの確認を促してください。
- 「お分かりいただけましたか？」と尋ねるだけにする。 儀礼的な確認は理解の証拠にはなりません → 言い直し、決定の根拠、または次のアクションを求めてください。
- 成功を「自分の推奨案への同意」と定義する。 十分な情報を持った意思決定者は、異なるリスクを受け入れる場合があります → 事実の理解、決定の明確さ、一貫した実行を評価してください。
- チームの成果を個人の行動に置き換える。 「私たちは図を作成してリリースしました」では、あなた自身の判断が隠れてしまいます → 自分が何を調査し、削除し、保持し、変更したかを述べてください。
- ストーリーを強化するために数値を捏造する。 フォローアップの質問ですぐに露呈します → 真実の証拠を使用してください。メトリクスが存在しない場合は、決定記録、スコープ、またはリスク対応アクションを使用してください。
- 「好評だった」ことだけを報告する。 感想は結果ではありません → 下された決定、回避された誤解、可能になったアクションを述べてください。
- 「もっと忍耐強くなるべきだった」とだけ振り返る。 これでは再利用可能な変化が生まれません → 現在使用している質問、資料の構成、または検証方法を具体的に挙げてください。
フォローアップの質問と回答
フォローアップ1: ステークホルダーが真に理解したことをどのようにして知りましたか？
観察可能な証拠を提示してください。相手が自分の言葉で選択肢と残余リスクを説明できた、モデルを新しい状況に適用できた、停止条件を書き出した、または決定事項を別のステークホルダーに正確に伝達できた、などです。頷きや「問題ありません」という言葉は十分な証拠ではないため、その旨を述べる必要があります。
フォローアップ2: ステークホルダーがあなたの推奨案に依然として反対した場合はどうしますか？
理解と同意を区別してください。事実、選択肢、リスク、意思決定権限が明確であることを確認し、反対の理由が目標の違い、リスク選好の違い、あるいは不足している事実によるものかどうかを尋ねます。証拠を追加し、適切な意思決定者に選択を委ねます。安全性、コンプライアンス、または認可の境界が越えられない限り、決定を記録し、実行をサポートします。
フォローアップ3: 何かの説明に失敗したことはありますか？また、どのようにリカバリーしましたか？
誤解を招くたとえ話、定義されていない用語、過度な詳細、省略されたリスクなど、具体的な失敗を1つ選択してください。問題を明らかにした相手の行動、資料をどのように再編成したか、そのミスが現在の決定にどのようなコストをもたらしたか、恒久的に変更した実践方法を説明します。相手が「十分に技術に精通していなかった」などと責めてはなりません。
フォローアップ4: 正確さを損なわずに単純化するにはどうすればよいですか？
決定を変更する可能性のある因果関係、制約、不確実性、復旧条件を保持し、内部名称や無関係な実装を削除します。知識のある同僚に事実確認を依頼し、その後、対象読者にシナリオを通じて説明を検証してもらいます。たとえ話の限界を明示し、不確実な要素を無理に確実なものとして埋めるのではなく、未知の事項がどのように解決されるかを説明します。
フォローアップ5: 技術者と非技術者が同じ会議に出席している場合はどうしますか？
階層化されたコミュニケーションを使用します。共通の層には決定、影響、選択肢、推奨事項が含まれます。次の層には技術的根拠が含まれ、詳細な実装は質問に応じて利用できるようにしておきます。定義のセットを1つに保ちながら、各読者にその責任に結び付いたエントリーポイントを提供することで、会議で事実のバージョンが2つ生じないようにします。
フォローアップ6: このサンプルをあなた自身の経験に置き換えるにはどうすればよいですか？
認可モデル、リリース日、すべてのプレースホルダー数値を削除します。3つの実際の経験をリストアップし、特定の意思決定、明確な個人の判断、理解の証拠、下流の成果があるかどうかをスクリーニングします。最も裏付けのあるストーリーを選択し、STAR形式で記述します。状況（Situation）とタスク（Task）では決定事項と制約のみを確立し、行動（Action）では読者の評価、コンテンツのトレードオフ、言語化、検証、調整をカバーし、結果（Result）では決定、実行への影響、および1つの具体的な振り返りをカバーします。