ドリルではなく穴が欲しい。穴が必要なシチュエーションは？

Go で作ったと話すと、「どうやってそれでOKもらったのか？」と聞かれることがある。具体的な内容ではなく、アプローチをメモしておく。

「顧客はドリルではなく穴が欲しい」とよく言われる。もう一歩進んで穴が必要なシチュエーションも考えてみましょう、と。そうすると穴が必要であることを自覚していない人を、ドリルの顧客にできるかも知れない。

むかーしむかし、職場の営業担当者向けの研修で仕様から便益、便益から機会を特定するというフレームワークを習った。営業候補だった頃が私にもあったのですよ。

製品やサービスには、仕様、機能といった事実に基づいた特徴がある。ここでは仕様と呼ぶ。まずはそれをリストアップする。たとえば Go 言語だと…

goroutine
チャンネル
シングルバイナリを出力
…

つづいて、各仕様によって得られる便益を挙げる。

仕様: goroutine
便益: 容易に関数/メソッドを並行処理できる
…

仕様: チャンネル
便益1: メモリを共有せずに、goroutine 間でデータを共有できる
便益2: goroutine の実行を同期できる
…

仕様: シングルバイナリを出力
便益: ランタイムライブラリのインストールなしで実行できる
…

それから、各便益が活かされるような機会を挙げる

仕様: goroutine
便益: 容易に関数/メソッドを並行処理できる
機会: 複数のクライアントが同時に接続するサーバーを作る
…

仕様: チャンネル
便益1: メモリを共有せずに、goroutine 間でデータを共有できる
便益2: goroutine の実行を同期できる
機会: 同期しながらの並行処理が必要（クライアントへのレスポンスをブロックするとか）
…

仕様: シングルバイナリを出力
便益: ランタイムライブラリのインストールなしで実行できる
機会: 実行環境の構築ができない/しにくい（特定の Python がインストールされてて、その環境分離をさせるのがだるい、とか）
…

で、潜在顧客の話を聞く。どんな課題があるのかとか、普段は何をしているのかとか。すると、複数のプログラムどうしでデータ交換したいだとか、ランタイムをインストールするときには別途承認があ必要でだるいとかの話が出てくる。これを聞き出すのは、またべつの技能なんだけど。

「なるほど。なるほどですね。実行環境の構築をしにくいとわけですね（機会の確認）。go ならシングルバイナリを吐き出す（仕様）ので、ランタイムなしで実行できます（便益）」という風に、製品/サービスを紹介していく。

もちろんこれは単純化している。go には他にも便益となる機能があるし、go fmt なんかの周辺ツールにも便益がある。「Google が、がっつり使っている」という事実が便益になるような機会もある（「実績はあるのか」問題）。あるいは go を使っている人を集められるのか、みたいなことが重要な場合だってある。

この方法が常にうまくいくわけじゃないし、必要なわけでもない。

手元にある仕様から分析するので、まずは机上で開始できる。そして、顧客と話すときには、顧客のシチュエーションから始めることができる、という点で実践しやすいフレームワークだ。あと、ここでは顧客と呼んでいるけど、実際に説得する相手が会社の上司、同僚、タイムラインで絡みたいある人であっても使える。