ステークホルダーウォークスルー
作者以外の誰かが実際にその作業をしようとしたとき、初めて表面化する要件があります。サービスをインストールするオペレーター、データを探す科学者、リポジトリをセットアップする同僚、午前3時にログを読むメンテナー。ウォークスルーは、変更の仕様化の前に、名前のあるペルソナと具体的なプロセスを用いて、机上でそれを行います。その成果物は設計ではなく、オーナーへの質問、ギャップ、そして仕様やテストで利用できる受け入れ例です。
感謝を込めて、二つの習慣を借用しています。一つは、MITライセンスのjeffallanによるFeature Forgeスキルが行うように、プロダクトハット（ユーザー価値、目標、成功）とデベロッパーハット（実現可能性、セキュリティ、エッジケース）という二つの帽子からのインタビュー。もう一つは、melodic-softwareのrequirements-elicitationスキルが行うように、シミュレートされたステークホルダーが「言った」ことを、実際のステークホルダーが言ったことよりも低い確信度としてマークすることです。
入力
ウォークを始める前にユーザーとこれらを確定し、出力の先頭に書き留めてください。
- ペルソナ。 誰なのか、このプロセスから何を望んでいるのか、何を知っていて何を知らないのか、マシンに何をインストールしているのか、絶対に読まないものは何か。アーキタイプよりも、実際の組織における役割を優先してください。あなたが尋ねられる場合は、あなたの推測よりも実際の人の回答を優先してください。
- プロセス。 彼らがやろうとしていること。最初のステップから、彼らが完了したとみなす瞬間まで。例：サーバーにクローラをインストールする；インデックスから先週の測定値を見つける；外部コレクションとして新しいファイル形式を追加する；エージェントによる開発のために新しいリポジトリを開始する；夜間実行後にクロールログを読む。
- 既存のもの。 ペルソナが出会うであろうドキュメント、コード、コマンド、ページ。これにより、ウォークが計画ではなく現実をテストすることになります。ペルソナがそれらを見つける順序で、ペルソナがスキップするであろうものをスキップして読んでください。
ウォーク
ペルソナの靴を履いて、プロセスを一度に一歩ずつ進めてください。各ステップについて、以下を書き留めてください。
- 彼らがすること、具体的に：入力したコマンド、開いたページ、読んだファイル、尋ねた人物。
- その時点で彼らが知る必要があること、そして既存のものがそれを伝えているかどうか。
- ここで実際に何がうまくいかないか：黙って失敗すること、誤解を招くメッセージ、デフォルトのない選択肢、持っていない権限が必要なステップ、フィードバックのない待ち時間。
- もしできればオーナーに尋ねるであろう質問、本人の言葉で。
その後、ウォーク全体に対して二度帽子を切り替えてください。プロダクトハットでは、ペルソナが何を望んでいたか、プロセスがそれを提供しているか、彼らにとって「完了」とはどのような状態か、彼らが何に不満を持つかを尋ねます。デベロッパーハットでは、何が実現不可能か、安全でないか、大規模で遅いか、ステップの順序が脆弱かを尋ねます。
ウォークがドキュメントでカバーされていない箇所に達した場合、答えを発明しないでください。それを質問として記録し、続行するために何かを仮定しなければならなかった場合は、その旨を述べ、ウォークの残りがその仮定に依存していることをマークしてください。
ステップが何か一般的なことを明らかにした場合は、一段上の視点に上がってください（なぜの5回）。「わかりにくいメッセージ」は一つのステップに過ぎません。「ツールは何をする前に何をするのかを決して言わない」は要件です。
出力
プロジェクトに設計ノートがある場合はそこに（例：design/walkthroughs/<persona>-<process>.md）、なければ docs/walkthroughs/ にウォークスルーを書き、返信に短い概要を添えてください。テンプレート：
# ウォークスルー：<ペルソナ>が<プロセス>を行う
ペルソナ：<誰か、目標、知識、環境>。確信度：<シミュレーション | 〜とのインタビューに基づく>。
既存のもの：<読んだドキュメント、コード、コマンド>。
## ステップ
1. **<ステップ>。** すること：<...>。知る必要があること：<...>。うまくいかないこと：<...>。尋ねるだろう：「<...>」。
## プロダクトハット
<彼らが望んでいたこと、彼らにとっての「完了」、彼らが不満に思うこと>
## デベロッパーハット
<実現不可能、安全でない、遅い、脆弱>
## オーナーへの質問
- <質問。ペルソナの言葉で、どのステップから来たかを添えて>
## ギャップ
- <存在しない要件、振る舞い、ドキュメント。それを必要とするステップ>
## 受け入れ例
- <具体的な状況>のとき、<観察可能な結果>となる。（仕様のシナリオやテストに使える）
ルール
- どの部分がシミュレーションかを明示してください。エージェントによるウォークスルーは、注意深い同僚が見つけるであろうギャップを見つけます。実際のペルソナが何を重視するかはわかりません。実際のステークホルダーがいる場合は、そこに質問を渡し、確信度の行を更新してください。
- ペルソナの立場を保ってください。システムの仕組みを知っているとしても、ペルソナは知りません。あなたが知っていることではなく、彼らが見るものを書いてください。
- 具体的にし、一般的にしないでください。「オペレーターが
modama-crawler crawlを実行し、2時間何も表示されない」は発見です。「フィードバックが改善される可能性がある」は発見ではありません。 - 質問、ギャップ、例こそが成果物です。ここで修正案を設計しないでください。何が要件になるかはオーナーが決定します。
- 新鮮な視点を考慮してください。既存のツールに対しては、ペルソナ、プロセス、およびユーザー向けドキュメントのみを与えられたサブエージェントに「ツールを実行せよ」と指示することで、作者がもはや知らないことを発見できます。それがこのプラグインの
hallway-testスキルです。ウォークスルーが「実際に試してみよう」に変わったときに使用してください。