デシジョンログ:トップデザイナーが誰にも聞かれない判断を記録する理由

シニアデザイナーとミドルレベルのデザイナーは、同じ画面を出荷できます。シニアは「なぜ」を覚えています。ミドルは「何を」しか覚えていません。

その差は、ひとつの成果物です。すべてのデザイン判断を、理由つきで、日付入りで、構造化して残した短い記録。それがデシジョンログです。ほとんどのデザイナーは持っていません。学校では求められず、前のチームにも存在しなかったからです。この習慣は、放っておいて自然に広まりません。

2026年に基準を引き上げているチームは、すでに運用しています。Linear にはデザインRFCがあります。Vercel はエンジニアリング仕様と並べてプロダクト仕様を出します。Anthropic はリサーチノートを公開しています。Stripe はデザインレビュードキュメントを回しています。Brian Lovin は個人サイトで公開しています。Jordan Singer は小さなプロダクトに公開のデザイン日誌を添えて出荷します。どの現場にも、同じ成果物があります。

これがそのプレイブックです。ログとは何か、なぜ採用担当者が最初に読むのか、この習慣の由来、6項目のテンプレート、保管場所、実例、失敗パターン、そして明日からの始め方を扱います。

ほとんどのデザイナーが持たない成果物

デザインで最も過小評価されている成果物は、デシジョンログです。ケーススタディでも、Figma ファイルでも、スライドでもありません。すべてのデザイン判断を、理由つきで、日付入りで、構造化して残した短い記録。しかも、作業が出荷される前に書かれたものです。

書かないコストは、静かに現れます。半年後、フォームのフィールドがなぜインラインでなく縦積みなのか、誰が決めたのか、何が削られたのか、デザイナーは説明できません。3年後、ポートフォリオには6つのプロジェクトがあっても、擁護できる判断はゼロ。そのデザイナーは一生ミドルレベルのままです。

デシジョンログとは実際に何か

デザイン上の選択、検討した代替案、効いていた制約、判断の根拠、担当者、結果を構造化して残した記録。6項目、日付入り、具体的で、成果物にリンクされている。定義はこれですべてです。

ケーススタディではありません。ケーススタディはあらゆる選択を必然であったかのように見せます。ログは、選択が下された時点の姿を見せます。テーブルにあった代替案、それを退けた制約、そしてデザイナーがいま引き受けている結果です。

議事録でもありません。ログは、判断が30秒のSlackメッセージで下されたとしても、何が決まりなぜ決まったかを記録します。ロードマップは前を向きます。ログは、すでに下したすべての判断を振り返ります。日付が入り、署名され、いつでも擁護できる状態で。

採用担当者がモックアップより重視する理由

磨かれたモックアップが見せるのはアウトプットです。デシジョンログが見せるのは判断力です。2026年のシニア採用担当者は、まずログを読みます。アウトプットはAIで安くなり、判断力はそうではないからです。

モデルは8分で洗練されたランディングページを出します。そのページを見ても、採用担当者は制作者について何も分かりません。同じモデル、同じプロンプト、同じ Dribbble のリファレンス。AIによって磨き込みがコモディティ化しても、ログだけは生き残ります。ログはアウトプットではなく、他の18案ではなくこのアウトプットを生んだ選択の軌跡だからです。

読むのに2分かかります。採用担当者はログを開き、5つのエントリーを流し読みして、そのデザイナーの考え方を知ります。具体的な代替案、名指しされた制約、具体的な根拠、引き受けた結果、そして「いまならこうは決めない」と書く姿勢。面接のすべてが、1つのドキュメントに圧縮されています。

この習慣の由来

デシジョンログはソフトウェアより古いものです。Christopher Alexander のパターン・ランゲージは、建築スケールのデシジョンログとして読めます。すべてのパターンに日付と名前と根拠があり、代替案も記されています。建築家は何世紀も前からデザインブックをつけてきました。

ソフトウェアはRFC文化を通じてこれを受け継ぎました。IETF は1969年から Request for Comments を発行しています。Spotify、Pivotal、Thoughtworks の ADR(アーキテクチャ決定記録)は、同じ成果物をより小さな規模にしたものです。最近の継承先はリサーチラボです。Anthropic が公開するリサーチノートは、モデルレベルのデシジョンログとして読めます。

3つの系譜、同じ成果物。デザイナーは後発組であり、その基準は急速に上がっているので、遅れていること自体がジュニアに見え始めています。

6項目テンプレート、そのままコピーしてください

6項目です。Decision、Alternatives、Constraints、Reasoning、Owner、Outcome。テンプレートは意図的に短くしてあります。規律が宿るのは設計ではなく、書くことの中です。このブロックをコピーして、明日から使ってください。

Date: 2026-04-30 Project: Acme Onboarding v3 Decision Stack email and password vertically on the signup screen, no inline social login row. Alternatives 1. Inline social login row (Google, Apple, GitHub) above the fields. 2. Two-step flow, email first then password on screen 2. 3. Magic-link only, no password field. Constraints - Mobile-first, 360px min width, single column. - Engineering will not ship social OAuth this quarter. - Support flagged 14% of tickets as password reset confusion. - [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic. Reasoning Vertical stack ships fastest and matches the brand register. Two-step tested cleaner in 2024 but added a screen we cannot afford given the 38% drop on screen 2. Magic-link only blocks the password manager flow 22% of paid users rely on. Owner Maya Chen, design. Reviewer: Jordan Park, eng lead. Outcome (filled 2 weeks post-ship) Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate magic-link as v3.1 when OAuth lands in Q3.

Copy

実際の判断1つにつきエントリー1つ。プロジェクトごとに5〜10件。表紙は要りません。上のブロックこそが仕事です。

逃げずに各項目を書く方法

各項目にはルールがあります。ルールを飛ばすと、ログは茶番になります。

Decision。1文、現在形、具体的に。「メールとパスワードを縦に積む」。「縦が良さそうだと感じた」ではありません。判断がまだ下されていないなら、エントリーはまだ書かないでください。

Alternatives。番号付きリストで、実際にテーブルにあった選択肢を2〜4個。藁人形は不可です。検討したのが1案だけなら、そう書いたうえで、なぜ探索をやめたのかを説明します。

Constraints。箇条書きで、名前と出典を明記します。エンジニアリングの工数、ブランドルール、サポートチケット、アクセシビリティの下限、パフォーマンスバジェット。これがないと、ログは好みの正当化にしか見えません。

Reasoning。3〜5文、「感じた」は禁止。「なぜなら」を使う。「〜と比べて」を使う。決め手になった制約やデータを引用し、成果物にリンクします。

Owner。デザイナーの名前、レビュアーの名前を書く。匿名のログは、シニアレビュアーとの接触に耐えられません。

Outcome。出荷から2週間〜2か月後に、日付つきで記入します。指標がどう動いたか、何を見直したか、次回は何を変えるか。「マジックリンクを外した判断は間違っていた」と書ける姿勢は、ログの中で最も信頼されるシグナルです。

ログの保管場所

ログは、チームが実際に開く場所に置きます。ストレージの違いは、更新の頻度ほど重要ではありません。

Notion。チーム全体で最も立ち上げやすい選択です。データベース1つ、判断1つにつきエントリー1つ、6項目を列にします。多くのプロダクトチームがすでに契約しており、デザイナー1人で1時間あれば立ち上げられます。

Linear docs。エンジニアリングとデザインがすでにそこにいるなら正解です。判断は、きっかけとなったイシューの隣に置かれ、エンジニアリングRFCへの引き継ぎもワンクリックです。

リポジトリ内のマークダウンファイル。デザインエンジニアやデザインシステムの担当者に向いています。リポジトリのルート、または /docs/decisions/ 配下の decisions.md は、コードと一緒にバージョン管理されるので本格的に見えます。エンジニアはこの形式を一目で尊重します。

小さな非公開ブログや個人サイト。公開の軌跡を築く個人のデザイナーに向いています。Brian Lovin はこのやり方です。静的サイト、日付入りのエントリー、公開リンク。ポートフォリオの面と採用向けの存在感を兼ねます。

ひとつ選び、四半期のあいだ回してください。最初に失敗する一手は、ツールを選んだきり二度と開かないことです。

Linear のデザインRFCと Vercel のプロダクト仕様

Linear は、デザインRFCをドキュメントの中で第一級の成果物として運用しています。意味のあるデザイン判断はすべて、作業の前にRFCとして書かれ、デザインとエンジニアリングのリードがレビューし、プロジェクトとともにアーカイブされます。RFCは作業の一部であり、後から書く報告ではありません。

Vercel は、プロダクト仕様をエンジニアリング仕様と同じリポジトリで出荷します。デザインの判断とエンジニアリングの判断が同じドキュメントに載り、日付があり、担当者がいて、レビューされます。チームは仕様を契約として扱います。v0 が新しい面を出すとき、仕様はローンチ成果物の一部です。

どちらのチームも、書かれた根拠をクラフトの一部として扱っています。水曜午後の事後報告ではありません。任意でもありません。Figma ファイルが仕事であるのと同じように、その記録も仕事であり、それを持たずに現れるデザイナーは未完成に見えます。

Anthropic のリサーチノートと Stripe のデザインレビュードキュメント

Anthropic は、モデルレベルのデシジョンログとして読めるリサーチノートを公開しています。何を試し、何がうまくいき、何がうまくいかず、次の一手は何か。短く、日付入りで、担当者がいて、リンクされている。3本読めば、この習慣は明白になります。ノートは記録であり、脚色ではありません。

Stripe は、プロダクトサイクルをまたいで残るデザインレビュードキュメントを運用しています。Stripe Press が公開の顔ですが、社内の実践はそれより古いものです。レビューは書かれ、アーカイブされ、次のサイクルで似た判断に当たったときに見返されます。シニアデザイナーが去っても消えず、何年もかけて複利で積み上がる組織の記憶です。

これをチームのクラフトに組み込む支援が必要なら、Brainy に依頼してください。BrandBrainy は、AIには偽造できないクラフト層を出荷します。ClaudeBrainy は、ログを「規律」から「デフォルト」に変えるSkillパックとプロンプトライブラリを出荷します。

Brian Lovin と Jordan Singer は公開で続けている

Brian Lovin は、自身の仕事に関する公開デシジョンログとして読める個人サイトを長年運営しています。短いページ、率直な文章、デザインの選択がそれぞれ3、4文で説明され、日付が入り、稼働中のプロダクトにリンクされています。何年分ものエントリー。サイトはポートフォリオと採用向けの存在感を兼ねており、これはアンチポートフォリオのプレイブックが頼る二重用途です。

Jordan Singer は、公開のデザイン日誌を添えて小さなプロダクトを出荷します。各プロジェクトには、背後にある判断の記録が公開されており、「これはうまくいかなかった」と声に出して言う姿勢があります。日誌は、マーケティングであり、記録であり、採用向けの成果物でもあります。

2人のやり方は、現役のデザイナーなら誰でも今週コピーできるテンプレートです。静的サイト、6項目のエントリー、日付入り、公開、リンクつき。1エントリー15分、月に3本。1年後、公開ログは、どんな Behance のケーススタディにも出せないシニアらしさを放ちます。

注意点:後付けの合理化

作業が出荷され、結果が分かったあとに書かれたデシジョンログは、ログではなくセールストークです。シニアの採用担当者は、その違いを2分で見抜きます。

見分けるポイントは Alternatives 項目です。生きたログには、実際にテーブルにあった代替案が並び、その中にはしばしば有力な1案があります。後付けのログには、書き手が真剣に検討したことのない3つの選択肢が並び、選ばれた案を自明に見せるよう仕立てられています。採用担当者は同じ演習を百回やってきました。脚色がどう見えるか、知っています。

もうひとつの見分けどころは Outcome 項目です。生きたログには、予測と合わなかった結果が入っています。「コンバージョン向上を期待したが、テストは横ばいだった。何が悪かったか」。茶番のログには勝ちしか載らず、実際より良く見えるよう事前に丸められています。

解決策は居心地の悪いものです。作業が出荷される前にエントリーを書く。日付を入れる。反論してくるレビュアーに提出する。2週間後に、結果が悪くても必ず記入する。悪いときこそ記入する。誠実なエントリーは複利で積み上がります。

面接とレビューでログを使う方法

ログは2度、元を取ります。作業が出荷されるときと、デザイナーが採用担当者やシニアレビュアーに判断を説明して回るときです。

面接では、ログがケーススタディの説明に取って代わります。ドキュメントを開き、エントリーを3つ選びます。それぞれについて、判断を読み上げ、最も有力だった代替案を挙げ、決定的だった制約を挙げ、根拠を2文で説明し、次回何を変えるかを含めて結果を共有します。1エントリー5分、合計15分。採用担当者は、45分のケーススタディのスライドより多くを、判断力について知ることになります。

シニアレビューでは、ログが会話そのものです。レビュアーはエントリーを読み、根拠に反論し、最有力の代替案をなぜ切ったのかを尋ねます。その議論が、次の判断を下す前に研ぎ澄ませます。良いデザインレビューとはそういうものです。描画されたピクセルへのフィードバックではなく、その背後にある判断についての議論です。

ログを擁護できるデザイナーは、仕事を擁護できます。ログのないデザイナーは、何も擁護できません。

新しい基準:ログのないシニアの仕事はジュニアに見える

デシジョンログは、もはやシニアの「あれば嬉しい」ものではありません。デザイナーが出荷できる、シニアの判断力を示す最も安価なシグナルであり、持たないことのコストは上がり続けています。

公開ログのあるシニアのポートフォリオは、シニアに見えます。ないものは、シニアだったかもしれない仕事に見え、見分けがつきません。採用担当者は両方を読みます。折り返しの連絡が行くのは前者です。3つの小さなプロジェクトにログを付けたジュニアは、自分のレベルより先を行って見えます。完璧な Dribbble のショットを12枚並べてログのないジュニアは、1年前と同じジュニアに見えます。

2026年にテイストが最後の堀であるのは、制作がコモディティ化したからです。そしてログは、テイストが仕事の中に存在することを証明する公開の成果物です。デザインエンジニアリングのハイブリッドとして出荷しているなら、ログはデザイン層でのエンジニアリングRFCを兼ねます。新しいデザインキャリアラダーを登っているなら、ログはそのラダーが乗る成果物です。

FAQ

デザインのデシジョンログとは?

理由つきでデザイン上の選択を残した、短い構造化記録です。エントリーごとに6項目。Decision、Alternatives、Constraints、Reasoning、Owner、Outcome。日付入りで、具体的で、成果物にリンクされています。

ケーススタディとどう違いますか?

ケーススタディは、あらゆる選択を必然のように見せます。ログは、実際に下された姿のまま選択を見せます。テーブルにあった代替案、判断を縛った制約、引き受けた結果です。ケーススタディは売り込み、ログは記録です。

どこに保管すべきですか?

チームが実際に開く場所です。プロダクトチームなら Notion、すでに Linear にいるチームなら Linear docs、デザインエンジニアならリポジトリ内のマークダウンファイル、個人で公開の軌跡を残すなら小さな個人サイト。

1エントリーはどのくらいの長さにすべきですか?

短く。テンプレート全体が1画面に収まります。1エントリー15分です。

会社が導入してくれない場合は?

個人で運用してください。デザイナー個人のログは、転職をまたいで複利で積み上がります。Brian Lovin と Jordan Singer は公開で続けています。この習慣はあなたのものであって雇用主のものではなく、成果物はあなたと一緒に移動します。

今週、ログを始めましょう

3つの動きです。まずストレージを用意します。Notion、Linear、リポジトリ、小さなサイトから選び、30分で立ち上げます。明日開くものを選んでください。

次に、すでに下した判断について3つのエントリーを書きます。今四半期の実際の判断を、それぞれ6項目で。正直な代替案、本物の制約、逃げ腰の表現なし、日付つきで脚色のない結果。最初の3つが一番難しく、あとは速くなります。

最後に、ログをシニアレビュアー1人に見せます。根拠に反論してもらいます。その反論をシグナルとして受け取り、エントリーを更新します。最初のレビューが、ログが複利で育ち始める場所です。

デシジョンログの習慣をチームのクラフトに組み込む支援が必要なら、Brainy に依頼してください。BrandBrainy は、AIには偽造できないブランドとクラフトの層を出荷します。ClaudeBrainy は、ログを「規律」から「デフォルト」に変える Skillパックとプロンプトライブラリを出荷します。すでに運用しているチームは、引き離しにかかっています。基準は上がっており、今週始めたデザイナーこそ、四半期後に名だたるチームが読むことになる人です。