解決すべき課題を明らかにする、というのはとても大事なことなんだけど、見落とされることがある。解決すべき課題、意識高くいうとイシューというやつだけど、イシューを特定せずにアクションを起こすと、たいてい無駄になる。課題が解決しないからだ。

＊　＊　＊

顧客が技術的な質問を、私の同僚の営業担当社に問い合わせる。その営業担当が、私にその質問を渡す。ということがよくある。それは私が受けるべき仕事のひとつだ。

答える前に、質問のコンテクストを知りたくなる。なぜその質問が出てきたのか。「顧客が知りたいって言ってるんだから、知りたいんでしょうよ」と思っているであろう同僚と、会話が滞ったりする。

自分が意地悪をしたり、仕事を嫌がっているように見えてる気がして、とても嫌だ。なんだか自分がバカみたいに思えてくる。

よくある問い合わせなんですよ、とも言われる。そうだと思う。だからこそコンテクストを知りたい。

たとえばだ。API を提供していると、おそらく聞かれるであろう質問。「このレートリミット（1秒間にサービスにアクセスできる回数の上限）を上げてもらうことは可能ですか？」

提供側の答えは、ほぼ「いいえ」だろう。レートリミットが問題になり、かつ、それをなんとか解決する必要があると提供側が認識していれば、提供側から何か申し出ているはずだ。それだけの（売上なり、名声なり、戦略なり）のインパクトがあるなら検討する。でも、そうじゃない。だから答えは「いいえ」だ。

しかし問い合わせをした人は、そんな回答は期待していない。たぶん次のメールでこう言う。「上げてもらうにはどうしたらいいですか？」だ。

そして回答は多くの場合「上げられません」だろう。

で、コンテクストである。

たぶんなんだけど、質問者は「自分のサービスの可用性を確保したい」という動機があって、レートリミットがボトルネックのひとつになると考えているんだろう。レートリミットは簡単に上げられない。でも、質問者の問題を解決する方法はあるかも知れない。

キャッシュで用を足せることはよくある。あるいは、突発的に予測困難なアクセススパイクがあるなら、キューに突っ込むとかして非同期処理とかどうですか。

複数のAPIコールの結果の組み合わせで条件分岐するならば、ド・モルガンの定理を使って、レートリミットが高いAPIを先に呼び出して、短絡評価で回避できるかも知れない。

ところが、常にコンテクストを知りたいわけではない。わりと明確に分かるときもある。どんな場合でも通用するようなチェックリストや質問リストを用意しても、ほとんどの項目は無駄になるだろう。

毎日100件とか問い合わせが来るなら気合を入れて、条件分岐するようなスクリプトを作ってもいい。でも、2日に1回の問い合わせなら、効率が悪い。2日に1回なら対応しなよって言われそうだけど、一旦顔を出すと、問題解決の安価な外注先として使われがちで、それはちょっとなーと思ってしまう。

↑この資料では、よいブログ記事の条件のひとつが「課題設定が明らかなこと」とある。とても大事だなと思う。課題設定が明らかでないと、そこから導かれる結論はもうだいぶつらい。

＊　＊　＊

「行動を始める前に、解決すべき課題を明らかにすること、そして相手にもそれを求めること」を自分に強制するしくみを作ることで、問題解決のスループットが上がるのでは？

が、私にとってのイシューだろう。このイシューが最初に明らかにしていれば、こんなにだらだら書かずに済んだはずだ。

(Photo by Olav Ahrens Røtne on Unsplash)