worst-idea

最悪のアイデア

この手法でできること

最善の解決策ではなく、最悪の解決策を考えてもらいます。確実に状況をひどくする解決策を考え、それぞれを分析して、何が悪さをしているのか、その仕組みを正確に見つけます。その仕組みを反転させれば、機能につながります。この手法がうまくいくのは、「最善のデザインは何か」と尋ねると、誰もがためらいを経由して無難で当たり障りのない答えにたどり着く一方、「どうすれば確実に失敗するか」と尋ねれば、間違いを恐れる気持ちが取り除かれ、思っていることを口に出しやすくなるからです。そして、名前を挙げた失敗のパターンはどれも、正反対の形をしたデザイン原則です。

出典：リバースブレインストーミング。1950年代のHotpointの製品開発手法に由来するとされ、d.school／IDEOのファシリテーションツールキットでは「Worst Possible Idea」として標準的に使われています。

ワークフロー

Step 1: 対象を確認する

有効な対象とは、設計または再考するものとして示された、具体的な創造的課題です。オンボーディングのフロー、料金ページ、ランディングページ、ネーミングの方向性、チームで行う習慣などが該当します。対象が明確でない場合は、「何を設計するのですか。また、『良い』とはどのような状態ですか？」と、焦点を絞った質問を一つだけします。

デバッグ、コードレビュー、変更の実装など、分析作業を実行する依頼は断り、代わりに分析的なアプローチを提案します。そのようなプロセスを再設計したり、新しいアイデアを考えたりすることは、有効な創造的課題です。「コードレビューミーティングを再考する」は対象になりますが、「このPRをレビューする」は対象外です。

Step 2: 本当にひどい解決策を生み出す

問題を悪化させる解決策を5～8個提示します。基準は厳しく、それぞれ、どこかで誰かが実際にリリースしたことがあると思える程度に現実味がなければなりません。漫画のような悪意（「ユーザーのファイルを削除する！」など）では簡単すぎて、何も学べません。役に立つひどいアイデアとは、実際のチームが理屈をつけて採用したもの、つまり、会議でほとんど正当化できそうに聞こえるものです。

率直に提示します。表現を和らげたり、先回りして謝ったりしないでください。

Step 3: 何が悪いのか、その仕組みを特定する

悪いアイデアごとに、なぜ悪いのかを一文で述べます。症状ではなく、その仕組みを説明してください。「いらいらする」ではなく、失敗する構造上の理由を示します。

例：「このアイデアが悪いのは、製品ではなくユーザーに価値を証明させるからです。」

仕組みこそが、この手法の核心です。仕組みを明確に説明できない悪いアイデアは、ただの悪いアイデアです。

Step 4: アイデアではなく、仕組みを反転させる

その仕組みを正反対にします。これは「悪いことをしない」というだけではありません。それでは中立の状態に戻るだけです。仕組みを反転させることで、前向きなデザイン原則が生まれます。

悪いアイデアの仕組み：「ユーザーに製品の価値を証明させる。」 反転：「ユーザーに何かを求める前に、製品が価値を証明する。」

表面的に反転させて「つまり、ユーザーに価値を証明させなければよい」とするのは、よくある失敗です。根底にある力学を反転させてください。

Step 5: 反転した仕組みを発展させる

最も有望な反転を2～4個選び、それぞれを具体的な方向性へと発展させます。実際の機能、レイアウト、フロー、または文言に落とし込みます。反転した仕組みは原則ですが、方向性は月曜日から作り始められるものです。

Step 6: メタパターンを探す

悪さを生む仕組みには、共通するまとまりがあります。並べて読み、共通項をはっきりと言葉にしてください。それは、これが決してしてはならないことを示す地図です。ひどいアイデアが3つか4つあっても、実際には、同じ根本的な問題が異なる形をしているだけだとわかることがよくあります。その問題を明示してください。たいてい、それがセッション全体で最も鋭い成果になります。

Step 7: 正直に順位づけし、結論を急がせない

残った方向性に順位をつけます。有望なもの、弱いもの、それぞれの理由を伝えます。次の進め方として、一つをさらに発展させる、新たにひどいアイデアを出す、手法を切り替える、またはここで終えるといった選択肢を提示します。ユーザーに決断を迫ってはいけません。

誠実さを保つ仕組み

実は賢い案の失格。 ときには、「最悪のアイデア」が、実はひそかに優れた案、つまり本物のビジネスモデルや、正当な機能を別の形で表したものだとわかることがあります。その場合、そのアイデアは「最悪のアイデア」として失格なので、失格にして、本当にひどい案に差し替えます。はっきりそう伝えましょう。

「バグ報告ごとに課金する」は、実はサポートプランの料金モデルを別の形で表したものです。優れすぎているため、差し替えます。

これにより、アイデア群の誠実さを保てます。どの案を見てもひるまないなら、そのアイデア群は作り物です。

行き止まりのメカニズム。 すべてのメカニズムが、有用なものへと反転するわけではありません。ありきたりで自明なものや、すでに従っている原則、あるいは何にもならないものに変わることもあります。少なくとも1つは行き止まりの例を示しましょう。反転させ、結果を見て、無理に飾り立てずに行き止まりだと宣言します。すべてのメカニズムから宝物が生まれるアイデア群は、答えから逆算して作られたことを示す兆候です。

アイデア群そのものがうまくいかない場合。 ほとんどのメカニズムが、すでに従っている原則へと反転するなら、この手法から実質的なことがわかりました。つまり、この問題は想像力不足で失敗しているわけではなく、もっとひどいアイデアを出しても役に立ちません。診断結果を伝え、ユーザーの次の手として適した手法を提案し、そこで止めましょう。自分でその手法を実行してはいけません。

• 反転したものがすべて、すでに実践していること → 設計は妥当で、問題は別のところにあります。正しい問題を解決しようとしているか確認するために、concept-fanを提案します。
• 誰かが実際に採用するようなひどいアイデアを生み出せない → 対象が小さすぎるか、抽象的すぎるため、失敗の形を想像できません。発想の幅を広げるために、random-stimulusを提案します。

やってはいけないこと

• ひどいアイデアを無難なものにしないでください。 ひるむ感覚がシグナルです。悪いアイデアが本当に不快なものなら、その不快さを保ちましょう。和らげた案からは何も学べません。
• 表面だけを反転しないでください。 「Xをしない」はXの反転ではなく、Xがない状態です。Xの根底にあるメカニズムを、前向きな力へと反転させましょう。
• メカニズムの段階を飛ばさないでください。 悪いアイデアから良いアイデアへ直接飛ぶと、機能する唯一の部分を飛ばすことになります。メカニズムこそがこの手法です。これがなければ、機能を当てずっぽうで考えているだけです。
• すべてのメカニズムに成果を求めないでください。 行き止まりは、行き止まりとして示しましょう。
• ユーザーに決断を促さないでください。 この手法は発散のためのものです。収束するかどうかはユーザーに委ねます。

参考資料

• ./references/worked-example.md — 行き止まりのメカニズムと失格になったアイデアを含む、全体の流れがわかる実際のセッション