アイデアを、解ける課題に変える

多くのアイデアは解決策の形でやってきます。「顧客に自動で回答するシステムがほしい」。自然な言い方ですが、プロジェクトが三か月目で行き詰まる最大の原因でもあります。課題が定義されていない解決策は動く的です。同じ会議にいる全員が別のものを思い描き、意見の対立を決着させる手段がありません。

文章で答えを出すべき三つの問い

誰が、一日のどの瞬間に。「顧客」ではなく、問い合わせを開いてから資料を八分探し続けるサポート担当者です。記述が具体的になるほど、システムが何をすべきかが明確になり、それ以上に、何をしなくてよいかが明確になります。

今の解決策は何か。 どんな課題にも、たとえ稚拙でも既存の解決策があります。表計算ファイル、グループチャットでの質問、みんなが頼るベテラン。それが本当の比較対象です。

成功を数字で表すと何か。 対応時間、人手を介さず完了した件数の割合、週あたりの削減時間。指標を言葉にできないなら、そのアイデアはまだ感覚の段階です。それ自体は問題ありませんが、次の一手は開発ではなく調査になります。

一枚の資料

最初の一行を書く前に、次を書き出します。対象者とその瞬間、今の解決策とその弱点、成功指標、入力と望ましい出力の実例を三つ、そして最初のバージョンに入れないものの一覧。

重要なのは三つの実例です。抽象的な議論を具体的な事例の話に変えてくれます。書きづらいのであれば、それ自体が発見です。システムが何を返すべきかについて、まだ合意がありません。