結論
ドメイン知識のある人というのは、気象予報士みたいなものだと思っている
ドメイン知識は持っているだけでは役に立たない。
どう使うか。気象予報士のように使う。
気象予報士はなにをする？
気象予報士は天気図を見て、未来の事象である明日の天気や気温を予測する。
これは、明日の事象に影響する変数要素や数式を理解しているからだ
気象予報士のように使う、とは？
ある特定の、未来の事象を変数要素や数式で予測できること。
また、天気予報に含まれる要素(気温、天気、降雨確率、降雨量)のように「事象を表す要素として何を発表すればいいか」を無数の要素のなかかから選択できること。
未来の事象を数式で予想できること
数式に必要な変数要素がわかること
事象を表す少数の要素を選択できること
この３つが重要
昔大規模イベントの分析を行ったことがあって、イベントを表す要素として「推定参加者数、推定売上、１行説明」を入れた。これで読んだ人が大体わかるだろう、っていう要素がこの３つ。
推定に当たってはいずれも私が担当した分野では公式発表されないことが多い数値だが、いくつかの要素がわかればこれは簡単に推定できる。
例えば参加者数は消防法のからみで推定できる(詳細は秘密)。
事象を予測できると何がいい？
現実味のある企画書が書ける。
企画書には２種類ある。
現実性のある「プラン」と数字に現実味のない、極彩色の妄想である「ドリーム」だ。
後者は企画者の脳内にある現実歪曲空間でだけ通じる法則に基づいて作られている。
ドリームの何がまずい
ドリームだと判明しなければそのままサービス開発してしまい、３年たって赤字垂れ流しで撤退判断みたいな目にあう。
(2013年くらいのソシャゲやそのあとの新規事業でよくありましたね)
OSSのコミッタークラスが素晴らしい技術開発したプロダクトでも、現実味のない企画にもとづいて作られれば、それは「すごい技術で作られたガラクタ」にすぎない。
(うっ、心当たりが・・・)
開発し始めた当初は「ソシャゲでぶいぶい言わせた俺たちが作るんだからヒット余裕っしょ」という砂糖に蜂蜜かけたような甘い目論見は、３年間パッとしない現実の前に押しつぶされる。
ドリームをやめるには
ドリームの検出は役員チェックあたりで検出されることが多いが、役員チェックの前に企画のコストがかかっていることを考えると、企画者自身の目で「これドリームなんじゃね」っていう判断をすることが望ましい。
そのために企画者がドリーミーな企画書を書かないことが必要。
ドリーミーな企画書を書かないために、企画者自身のドメイン理解が必要だと思っている