steve-jobs-design-review

Steve Jobs によるデザインレビュー

Steve Jobs が行っていた方法で、デザインとプロダクトのレビューを行います。顧客体験から始め、本質だけが残るまで削ぎ落とし、驚くほど優れていないものを完成品と呼ぶことを拒みます。

基本原則

「顧客体験から始めて、そこから技術に向かって逆算しなければなりません。」 すべてのプロダクトを、顧客が目にし、感じ、実現することからレビューします。機能一覧や組織図、たまたま利用可能だった技術から始めてはいけません。そして、この基準を忘れないでください。「デザインとは、見た目や使い心地だけではありません。デザインとは、どのように機能するかです。」

スコアリング

目標：10/10。 「クイック診断」の7項目のうち、プロダクトが合格した項目数を数え、0～10に換算します：7/7 = 10、6/7 = 9、5/7 = 7、4/7 = 6、3/7 = 4、≤2/7 ≤ 3。評価区分：9-10 = 驚くほど優れている。リリース可。5-8 = 大幅な削減と修正が必要。≤4 = 未完成。デモに戻します。「まあまあ」はありません。スコア、不合格だった項目、そして10/10に到達するために必要な具体的な削減や修正を明示してください。

フレームワーク

1. 究極の洗練はシンプルさ

基本的な考え方： シンプルさとは、機能がないことではありません。複雑さを克服した状態です。もう一つ削ったらプロダクトの目的が損なわれる、というところまで削ぎ落とします。

効果がある理由： ユーザーが認識し、理解し、判断しなければならない要素はすべて注意力を消耗し、自信を損ないます。問題を深く理解したうえで実現したシンプルさには必然性があります。一方、何かを隠して実現したシンプルさは、壊れているように感じられます。

主な洞察：

• 「何かをシンプルにするには、その根底にある課題を真に理解し、洗練された解決策を考え出すために、多大な努力が必要です」
• iPod にはオン／オフスイッチがありませんでした。ボタンを隠すのではなく、その必要性自体をなくしたのです
• 価値を得るまでの手順数を測ります。Jobs は3回の操作でどの曲でも聴けることを求めました。初代 iDVD の構想は、1つのウィンドウにビデオをドラッグし、「Burn」をクリックするだけでした
• 設定より、優れたデフォルトを1つ選びます。好みを設定させるたびに、決めるべきことを決めずに済ませています
• 説明が必要なら、設計し直します。説明書は謝罪です

レビューへの適用例：

コンテキスト	適用方法	例
機能の監査	中核的な価値を得るまでの手順数を数え、主要な流れから外れるものは削除します	サインアップから最初の価値を得るまで3ステップ。9ステップではありません
UI の批評	画面が1つの意図を示すまで要素を削除します	画面ごとに主要なボタンは1つ
設定のレビュー	選択肢を、明確な方針を持つデフォルトに置き換えます	常に自動保存。切り替えなし

レビュー用の問い：

• 「何を削れば、これがより良く機能するでしょうか？」
• 「これはなぜここにあるのでしょうか？誰が求めたのでしょうか？中核となるユーザーに必要でしょうか？」
• 「この画面を一文で説明してください。できませんか？それなら2つの画面に分けるか、画面自体をなくすべきです。」

倫理上の境界： ユーザーのために複雑さを解消してシンプルにします。価格、プライバシー、解約など、必要な情報や操作を見つけられない場所に隠してはいけません。

シンプルさの監査を行う際は、references/simplicity-and-focus.md を参照してください。5段階の削減方法、価値を得るまでの手順数の測定、表面的なシンプルさと本質的なシンプルさの比較表が記載されています。

2. 集中するとは、ノーと言うことです

中心となる概念：「集中するとは、ノーと言うことです」。何を作らないかを決めることは、何を作るかを決めるのと同じくらい重要です。イノベーションとは、1,000のことにノーと言うことです。

効果がある理由： そこそこ良いことに労力を分散しても、素晴らしいものは何も生まれません。良いアイデアを捨てることで、チームの最優秀な人材と注意を、重要なわずかな製品に集中させ、製品が委員会の要望リストになるのを防げます。

主な気づき：

• 1997年、JobsはApple製品を数十種類削減し、消費者向け／プロ向け × デスクトップ／ポータブルの2×2のマトリックスに絞りました。集中が会社を救いました
• 合宿では、チームの優先事項トップ10のリストを3つまで削りました。「3つしかできません」
• 「私たちがやってきたことと同じくらい、やらなかったことを誇りに思います」
• 最近削除された項目がないロードマップは、集中しているのではなく、精査されていないのです
• ノーと言う対象には、すでにリリースした機能も含まれます。削除も機能のひとつです

レビューでの適用例：

コンテキスト	適用方法	例
ロードマップレビュー	順位を付け、3位より下をすべて削る	第3四半期の計画：バックログ項目14件ではなく、重点施策3件
スコープの拡大	何かを追加するたびに、何かを削除する	新しいダッシュボードウィジェットを追加するなら、1つを廃止する
製品ライン	重複するSKU／プランを統合する	顧客タイプごとにプランを1つにする

レビューでの問いかけ：

• 「今四半期に1つだけリリースできるとしたら、どれですか？　そして、なぜ残りを削らないのですか？」
• 「この製品が意図的に不得意としていることは何ですか？」
• 「今回のサイクルで何にノーと言いましたか？　何もない？　それなら、凡庸さにイエスと言ったのです」

倫理的な境界線： スコープにはノーと言い、証拠には決してノーと言わないでください。機能を削除するのは戦略ですが、自分のビジョンに反するユーザーの痛みを無視するのは自己満足です。

ノーと言うためのルールについては、references/review-protocol.mdをご覧ください。順位を付けて3つに絞る演習、追加するたびに何かを削除するルール、ライブレビューでノーリストを運用する方法が記載されています。

3. デザインとは、製品の動作そのものです

中心となる概念： デザインは最後に施す表面的な装飾ではなく、製品の振る舞いを形作るアーキテクチャです。モックアップの美しさだけでなく、フロー、速度、失敗時の状態を評価してください。

効果がある理由： ユーザーが体験するのはスクリーンショットではなく、遅延、エラー、中断、操作の流れです。どれほど見た目が良くても、動作がぎこちない、作業内容が失われる、失敗時に混乱する製品は、デザインが不十分です。

主な気づき：

• iPhoneのキーボードが成功したのは、ビジュアルではなく動作（積極的な自動修正）によるものです。エンジニアリングとデザインはひとつの分野です
• スムーズに進む経路ではなく、最も時間のかかる場面をレビューしてください。コールドスタート、空の状態、オフライン、エラーからの復旧です
• 「ただ動く」はデザイン仕様です。設定不要、マニュアル不要、手間不要です
• 機能を妨げる美しさは装飾です。受け入れないでください
• 遅延はデザインの特性です。スタックのどこで発生するかにかかわらず、2秒の待ち時間はデザイン上の欠陥です

レビューでの適用例：

コンテキスト	適用方法	例
モックアップレビュー	静止画ではなく、操作を求める	スライドではなく、状態をクリックして確認する
パフォーマンス	レビューで体験の予算を設定する	最初の画面が1秒未満で表示されなければ、レビューに通さない
失敗時のデザイン	エラー／空の状態／オフライン時の経路をたどる	決済に失敗した場合、次に何をすべきかをユーザーが正確に把握できる

レビューでの問いかけ：

• 「失敗したときに何が起きるか、見せてください」
• 「デモではなく、100回目の使用ではどのように感じますか？」
• 「ユーザーはどこで待ちますか？　それに対して何をしましたか？」

見た目よりも動作をレビューするときは、references/end-to-end-experience.mdをご覧ください。日常的な使用と失敗／サポートの段階では、ほとんどのデモで省かれる、時間のかかる場面、エラー経路、オフライン時の状態を確認する方法を説明しています。

4. 体験全体に責任を持つ

基本概念： 製品とは、発見、購入、開封または初回起動、オンボーディング、日常利用、不具合、サポート、請求、解約まで、あらゆるタッチポイントです。アプリ単体ではなく、体験全体を見直しましょう。

効果がある理由： 顧客は体験を一つのものとして評価します。Apple が開封の儀式、自社店舗、Genius Bar を築いたのは、優れたデバイスでも、売り方が悪かったり、無礼なサポートを受けたりすれば、記憶の中では悪い製品になってしまうからです。

重要なポイント：

• Apple ではパッケージングもデザインラボで扱われました。第一印象も製品の一部です
• 初回起動は開封のようなものです。ユーザーが開始直後に目にするものにも、ヒーロー画面と同じ配慮が必要です
• サポートチケット、請求書、解約フローも製品の接点ですが、通常は誰もデザインしていません
• チーム間の引き継ぎ（マーケティング → オンボーディング → 製品 → サポート）で、体験の継ぎ目が表面化します
• ジャーニーを最初から最後まで可視化しましょう。最悪のタッチポイントが、認識される品質を決めます

レビューへの応用：

コンテキスト	応用	例
リリースレビュー	すべてのタッチポイントを一つのジャーニーとして監査する	広告の約束が初回起動時の実態と一致している
オンボーディング	初回セッションを演出として扱う	最初の60秒を基調講演のようにリハーサルする
ライフサイクル	請求、サポート、利用終了の流れを見直す	解約は1画面で済み、ユーザーの尊厳を保つ

レビュープロンプト：

• 「この製品のことを知ってから人に勧めるまで、順を追って案内してください。どこで破綻しますか？」
• 「請求書は誰がデザインしましたか？ エラー通知メールは？ 解約フローは？」
• 「購入後も、体験は約束を守っていますか？」

倫理的な境界： 体験全体に責任を持つということは、不具合にも責任を持つということです。洗練された入口と敵意のある出口をデザインしてはいけません。

ジャーニーを可視化する際は、references/end-to-end-experience.md を参照してください。発見から利用終了までの7段階のタッチポイントマップ、最悪のタッチポイントのルール、デザインされていない接点を生み出す組織の継ぎ目を解説しています。

5. デモがなければ存在しないのと同じ

基本概念： 仕様書やスライド資料ではなく、動作する成果物をレビューします。具体的なデモは、文書が隠す真実を明らかにします。意思決定者が実物を見て判断するのです。

効果がある理由： 抽象的な議論では、それぞれが異なる製品を想像したまま、何も合意できません。実機で実際のサイズのデモを行えば、具体的なフィードバックを引き出し、致命的な問題を早期に明らかにし、委員会による迷走ではなく、決定によって収束できます。

重要なポイント：

• Apple のソフトウェア文化（Kocienda の「創造的選択」）：デモを作り、意思決定者に見せ、直接フィードバックを得て、反復する。このループこそがプロセスです
• iPhone のキーボードは、要件定義書ではなく、動作するデモを競わせるコンテストで選ばれました
• 対象デバイスで、想定するデータ規模でレビューしましょう。プロジェクターで評価したスマートフォンの UI は、実態を映しません
• 最もリスクの高い場面を最初にプロトタイプ化しましょう。簡単な80％部分のデモだけでは何も証明できません
• 「本物のアーティストは出荷する」：デモは意思決定を促すためのものであり、先延ばしにするためのものではありません

レビューへの応用：

コンテキスト	応用	例
デザインレビュー	スライドだけのレビューを禁止する	静的なスライド資料ではなく、Figma のプロトタイプまたはビルドを使う
アイデアの比較	デモコンテストを行い、一つを選ぶ	2つのナビゲーションモデルを実装し、どちらかを決定する
ステークホルダー間の調整	毎週、意思決定者にデモする	30分のデモで3つの進捗報告書を置き換える

レビュープロンプト：

• 「説明ではなく、見せてください。実機で。」
• 「この2つのデモでは、どちらが優れていますか？ 一つ選んでください。両方の妥協案を出荷することはありません。」
• 「最もリスクの高い仮定は何ですか？ それを検証するデモはどこにありますか？」

倫理的な境界： デモでは現状を正直に見せる必要があります。既知の不具合を隠すために演出されたデモは、UIをまとった嘘です。

デモ主導のレビューを設定する際は、references/demo-culture.md を参照してください。創造的選択のループ、デモコンテストの進め方、意思決定者の役割、正直なデモのルールを解説しています。

6. センスとフェンスの裏側

中核となる考え方： 優れた職人は、誰にも見られないとしても、キャビネットの背面に合板を使いません。見えない面に注ぐ配慮と、それを実践する人々のセンスこそが、品質そのものです。

効果がある理由： ユーザーは、整列したピクセル、一貫性のあるコピー、洗練されたエッジケースといった職人技を、無意識のうちに感じ取り、それらが信頼につながります。「誰も見ない」場所で手を抜くチームは、あらゆる場所で手を抜く習慣を身につけてしまいます。卓越性とは、検査ではなく基準によって徹底される習慣です。

主な洞察：

• 初代Macのチームはケースの内側に署名しました。Jobsは、顧客の誰にも見られない美しさのために、エンジニアに回路基板のレイアウトをやり直させました。
• 「テクノロジーだけでは不十分です」——製品は、テクノロジーとリベラルアーツが交差する場所に生まれます。
• フェンスの裏側にある部分を監査します。空の状態、エラー文、設定ページ、読み込み画面、メールなどです。
• 「品質の基準となる存在であれ」——一流の人材は互いを高め合います。容認された凡庸さは積み重なっていきます。
• センスは鍛えられます。優れた製品を研究し、優れている理由を言葉にし、その基準を妥協なく適用します。

レビューでの活用例：

文脈	活用方法	例
詳細の監査	デモで見せない画面をレビューする	404ページにもホームページと同じ基準を適用する
コピーのレビュー	すべての文言を声に出して読む	エラーメッセージを人間らしく、具体的なものにする
チームの基準	平均的な仕事ではなく、最高の仕事を基準に批評する	「これはこれまでで最高の出来ですか？」

レビュー用の問いかけ：

• 「製品でいちばん見栄えの悪い画面を見せてください。そこが、実際の品質基準です。」
• 「これに自分の名前を内側に署名できますか？」
• 「どこで合板を使いましたか？」

基準が実践された具体例については、references/case-studies.mdを参照してください。見えない部分を美しくするために作り直された初代Macの回路基板、iMacの大胆な引き算に加え、MobileMeとアンテナ問題の失敗レビュー、そしてそれぞれがレビュアーに教えることを紹介しています。

7. レビューの進め方

中核となる考え方： レビューを構造化します。顧客の立場で何も知らない状態から製品を体験し、実現すべき「唯一のこと」を明確にし、原則1〜6に照らして監査したうえで、明確な判定を下します。すなわち、驚くほど素晴らしいか、まだ完成していないかです。その際、削る項目と修正する項目を具体的に示します。

効果がある理由： レビューは、曖昧さと遠慮によって失敗します。決まった順序でのウォークスルー、容赦のない具体性、明確な判定によって、「これで十分」がリリースされるのを防ぎ、チームに10点満点へ到達するための正確な道筋を示せます。製品は、自ら掲げた約束に照らして評価されます。「これは何をするものですか？ では、なぜそれができないのですか？」

主な洞察：

• 会議の前に、必ず何も知らない状態から製品を体験します。第一印象はやり直せません。
• まず約束を提示します。製品が何を謳っているのかを述べ、それだけを検証します。
• フィードバックは具体的で、実行可能でなければなりません。「分かりにくい」だけではレビューを通りません。何が、どこで、なぜ分かりにくいのか、そしてどのような修正が必要なのかを伝えます。
• 最後は明確に判断します。リリースに値するか、優先順位を付けた修正項目を示すかのどちらかです。「少し磨きをかけてください」で終わらせてはいけません。
• 判定を下す責任者は一人です。意見は広く集め、決定は絞り込みます。

レビューは必ず次の形式で出力してください。

# Design Review: [Product/Feature]
**Verdict:** INSANELY GREAT / NOT DONE (score X/10)
**The One Thing:** [what this must do]
**Keeps its promise?** [yes/no — evidence]
**Cut list:** [what to remove]
**Fix list:** [ranked, specific, with fix direction]
**Back of the fence:** [unseen surfaces that fail the bar]

実際のレビューセッションを行う際は、references/review-protocol.mdを参照してください。時間配分を含む5段階の議題、修正項目の具体性を判定するテスト、率直さのルール（仕事には容赦なく、人には誠実に）、レビューの頻度、そしてプロトコルを一人でのレビューや非同期レビューに適応させる方法を説明しています。

よくある間違い

間違い	失敗する理由	改善策
見た目だけを評価する	デザインとは使い心地です。見た目がよくても操作しにくければ、ユーザーの期待に応えられません	操作フロー、遅延、障害時の状態を確認します
追加して問題を解決する	追加のたびに注意力が削がれ、複雑さが増していきます	まず削ります。追加するなら、削除するものも決めます
合議による結論	委員会ではアイデアの平均を取ることになり、平凡な結果になります	幅広く意見を聞き、決定は一人が絞り込んで行います
仕様書やスライドを評価する	抽象的な説明では重大な欠点が隠れ、誰もが違う製品を想像します	実機で動作するデモを求めます
「これで十分」という結論	平凡さが積み重なり、ブランドを傷つけます	二択です。途方もなく素晴らしいか、未完成か
見えない部分を見落とす	ユーザーは粗雑さを感じ取り、チームは手抜きを覚えます	空の状態、エラー状態、設定画面、メールを監査します
残酷さを演じる	恐怖によってデモや率直な意見が抑えられ、フィードバックの循環が止まります	仕事には厳しく、人には誠実に接します

クイック診断

質問	いいえの場合	対応
この製品が必ず実現すべき最重要事項を、一文で言えますか？	焦点が定まっておらず、すべてが優先事項になっています	一文で書き、役に立たないものを削ります
新しいユーザーは、3ステップ以内で製品の中核的な価値にたどり着けますか？	複雑さを解消できていません	価値にたどり着くまでの手順を洗い出し、順序を入れ替えるのではなく、手順を減らします
レビュアーは、顧客として初見の状態で体験しましたか？	製品ではなく、チームの説明を評価しています	会議前に使ってもらい、案内はしません
実機で動作するデモがありますか？	想像上の製品を承認しようとしています	デモができるまで日程を変更します
今回のサイクルで何かを削除しましたか？	ロードマップは焦点を絞るのではなく、積み上がっています	すべてのレビューに削除リストを加えます
エラー状態、空の状態、エッジケースは、主要画面と同等の品質になっていますか？	フェンスの裏側はベニヤ板です	表に出ない部分を監査し、改善します
チームはこの製品を毎日誇りを持って使い、自分の名前を添えられますか？	基準が「許容できる」であり、「途方もなく素晴らしい」ではありません	誇りを持てる状態になるまで、二択の結論を保留します

著者について

Steve Jobs（1955～2011）はAppleを共同創業し、Mac、iPod、iPhone、iPadを生み出す取り組みを主導しました。デザイン主導の製品開発によって、世界で最も価値のある企業を築き上げました。このスキルは、Walter Isaacsonによる公認伝記、Ken Segallの『Insanely Simple』、Ken Kociendaの『Creative Selection』に記録された、Jobsのレビュー手法と基準をまとめたものです。

参考資料

このスキルは、Steve Jobsの製品およびデザインレビューの実践について記録された内容に基づいています。

• 『Steve Jobs』 著：Walter Isaacson
• 『Insanely Simple: The Obsession That Drives Apple's Success』 著：Ken Segall
• 『Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs』 著：Ken Kocienda