音声入力で、明確な受け入れ条件をすばやく書く
「下書きを保存できるようにする」。簡単に見える要望でも、タイトルが空欄だったらどうするのか、保存と同時に公開されるのかを聞かれると、説明が必要になります。口頭なら答えられるのに、タスクの説明欄はまだ空白、ということもあるでしょう。
音声入力なら、その説明から文章を起こせます。まず一つの場面を話し、受け入れ条件、つまり作業の受け入れに必要な、確認可能な結果に整理します。基本的な考え方はAtlassianの受け入れ条件の解説（英語）も参考になります。ここでは、音声で下書きを作る具体的な手順を紹介します。
1. 話す前にタスクと資料を開く
Macでタスクの説明と、関連するデザインや合意済みのメモを並べます。機能全体ではなく、小さな動作を一つ選びましょう。手動での下書き保存が対象なら、予約公開や自動保存は、範囲に含まれると決まっていない限り別の論点にします。
最初に「編集者が未完成の文章を保存し、後で作業を再開できる」のように目的を一文で書きます。利用する人の視点から説明しやすくなります。
2. 五つの問いに沿って話す
同僚に画面の動きを説明するつもりで、項目ごとに少し間を置いて話します。
- 誰が： どのような利用者や役割を想定しているか。
- 前提： 操作する前に、どのような状態になっているか。
- 操作： 利用者は何をするか。
- 結果： 操作後に何を確認できるか。
- 例外： 想定する失敗の場面では、どうなるべきか。
チームで決まっていない内容の前には「未決定」と付けて話します。編集時に別の欄へ移せば、思いつきを確定した要件として扱わずに済みます。
3. 話した内容を、確認できる条件に分ける
次は架空の機能を例にした下書きです。TypeFreeの機能説明ではありません。
編集者が、タイトルと本文のある未公開の記事を開いています。下書きを保存すると、保存完了の表示が出ます。開き直してもタイトルと本文が残っています。一般には公開されません。タイトルが空欄なら入力を求めて、保存はしないようにします。自動保存についてはまだ決まっていません。
音声入力の後で、レビュー用の案として整理します。
- 編集者がタイトルを入力済みの未公開記事を保存し、保存に成功すると、完了を知らせる表示が出る。
- 保存した下書きを開き直すと、その保存時点のタイトルと本文が復元される。
- 下書きを保存しても、記事は一般公開されない。
- タイトルが空欄のまま保存しようとすると、タイトルの入力を求めるメッセージが表示され、変更は保存されない。
「自動保存を対象に含めるか」は、条件の一覧とは別の未決定事項に残します。この例のルールはあくまで架空の機能に対する案です。実際の動作はチームで決めてください。
4. 表現を磨く前に、意味を確認する
「しない」「のみ」「空欄」「未公開」といった語を重点的に見直します。否定が抜けるだけで、要件が逆になることがあります。ボタン名の正確な表記は、音声認識だけに頼らずデザインからコピーしましょう。
次に、確認する人の立場で「何を操作し、何を見れば条件を満たしたと判断できるか」を読み取ります。「すばやく保存できる」と書いたなら、必要な時間と測定条件をチームに確認します。具体的に見せるためだけに数値を作ってはいけません。
話す途中で保存方式などの実装案に踏み込んだ場合は、技術的な検討メモへ分けます。利用者が確認できる結果と、内部の実現方法を区別しましょう。
5. 未決定事項も添えてチームで確認する
条件はまず案として共有し、残っている疑問も見えるようにします。合意済みの範囲として扱う前に、開発やレビューを担当する人と場面を確認してください。音声入力は説明を文字にする手段であり、合意や動作確認まで完了させるものではありません。
関連する作業には、音声入力でプロジェクト概要を書く方法とわかりやすいバグ報告を書く方法も役立ちます。
TypeFreeは、話した内容を編集可能なテキストに変え、文章をすばやく書くためのシンプルな方法です。まず一つの場面を選び、期待する動作を話してみましょう。文字になった内容を確認してから、タスクに追加します。