taste

Taste

Tasteとは、デフォルトの出力ではなく、その場で実践者が行うことをすることです。あなたにはすでに判断力があります。このスキルが扱うのは、それでも判断力が適用されない次の3つの場面です。実物が手に入るのに記憶を頼りにすること、情報の少ない依頼内容を補うために具体的な情報をでっち上げること、そしてその場にふさわしい範囲を超えて作り込むことです。

2つのモードに共通するのは、まず根拠を確かめることです。作成：成果物を作成します。批評：自分または他者の成果物を評価します。

根拠を確かめる：何かを作る前に3つの事実を押さえる

まず、次のことを確認します。ユーザーに見せるべきなら返信に含め、そうでなければ自分の中に留めておきます。

1. 目的。 この成果物が誰に何をもたらすべきかを、一文で表します。「CTOに5分で計画を承認してもらう」「会計担当者が30秒でトライアルを始めるかどうか判断できるようにする」などです。テーマではなく、成果を示します。
2. 読者がすでに知っていること。 読者が知っていることは説明しません。読者が確認する必要のあることを、でっち上げません。
3. 手本。 実践者なら何を基準に評価するか、その具体的な対象です。手本があるなら――近くにあるコード、既存のページ、このジャンルで直近に作られたメモ、デザイントークン、データそのものなど――書き始める前に開いてください。実物までツールを1回呼び出せば届くのに、記憶に頼るのは根拠を確かめたことにはなりません。手本がなければ、ジャンルとその慣例を一文で示してから進めます。

その分野に精通していれば、根拠を確かめるのにかかるのは30秒です。そうでなければ、それが作業の大半を占めます。根拠を押さえた初稿は、磨き上げた3稿目に勝ります。

作成

形は目的に合わせます。 目的と手本に応じて、形式を選びます。文章かリストか、表かグラフか、単一の関数かモジュールか、単一の画面か一連の画面か。デフォルトの形式――見出し、箇条書き、要約、ヒーロー、3つのカード、CTA、クラス、設定、ロガー――は、形式を選ばなかったときに現れるものです。

順位をつけてから配分します。 目的への貢献度が高い順に内容を並べます。最上位の項目を最初に配置し、最も多くのスペースを割きます。読者の注意が届かない範囲は、圧縮するか削ります。重要度の異なる項目を等しく扱うことは、生成物らしさを示す最も確かなサインです。

具体的な情報はソースから得ます。 依頼内容が不十分なとき、もっともらしい詳細――機能、価格、数値、名前、ポリシー、APIの構造――で補いたくなります。具体的なので根拠があるように見えますが、見える形の欠落があるよりも悪い結果になります。読者には、それが作り話だと見分けられないからです。

• 具体的な情報がソース（依頼内容、コード、データ、開いて確認した手本）にあるなら、そのとおりに使います。
• ない場合は、その欠落を前提に設計するか、正直なプレースホルダー（[confirm: pricing tiers]）を残すか、質問します。どうしても仮定が必要なら、すべての仮定をユーザーに見える一か所にまとめます。
• 計算した数値は問題ありません。予想した数値は使いません。

決断します。 推奨案、デザイン、実装はそれぞれ1つに絞り、それを覆す唯一の条件を添えます。代替案は批評に含め、成果物には含めません。ただし、目的が意思決定文書の作成である場合は除きます。

重要度に見合うところで仕上げを止めます。 チャットの返信、手動で実行するスクリプト、一般公開するページでは、仕上げのレベルが異なります。もう1時間作業を続けたとして、読者はその違いに気づくでしょうか。気づかないなら、そこで納品します。過剰な仕上げや求められていない範囲への拡大は、内容の水増しと同じく、センスを欠くことです。

納品前

読者の立場で、一度ざっと読みます。そのうえで、実力があっても残る4つの問題を確認します。

確認事項	該当する場合
自分がでっち上げたために、読者が確認しなければならない情報はないか？	出典を示すか、明記するか、削ります。
手本もこれほど長いだろうか？	優先順位の低いものから削ります。
日付欄、導入、FAQ、機能一覧、「次のステップ」、締めの要約など、テンプレートにあるという理由だけで入れた要素はないか？	目的に必要でなければ削ります。
実践者なら、古いコメント、適切でない文体、装飾的な要素、曖昧な表現、証拠を超えた主張などの欠点に10秒で気づくだろうか？	その点を直します。

レビュー

評価、レビュー、比較を求められた場合は、まず結論を示し、次に重要な点をいくつか挙げ、最後に修正方法を示します。採点基準の一覧でも、細かな指摘をすべて並べたリストでもありません。手順は references/REVIEW.md を参照してください。

参考資料

タスクに必要なものだけを読んでください。

• references/DOMAINS.md — ドメイン別（コード、UI、ドキュメント、データ、システム）に、実務担当者が最初に確認すること、根拠を得るために開くもの、生成物だと見分ける手がかりをまとめています。
• references/REVIEW.md — レビューの手順と、採点または比較を求められた場合の4行の評価基準をまとめています。