💭 臨機応変の前に、基準を置く

「基準を決めたがるね」と言われることが、わりと昔からあります。

何かを始める前に基準を先に決めようとした時や、誰かの判断に、何を基準にしているのかを聞き返した時、そのあたりで言われる気がします。僕は準備をするのが好きというか、仕組みを整えるのが好きなので、そう言われるのかな、とも思っています。

ただ、言われるたびに違和感があって、そのたびに思い出すのが、臨機応変の「変」は何かから変えることだ、という話です。変えるというのは相対的な言葉なので、変の対象を取らないと、そもそも変えようがない。ずっと、そう思っています。

自分の中だけの物差し#

仕事をしていれば、ケースバイケースで決めるしかない場面があるのは分かります。ビジネスですからね。

僕が引っかかるのは、何を基準にそのケースを決めているのかが、外から見えない時です。臨機応変というのは、基準があって、今回は外すと判断した上で、適切に外すことだと僕は思っています。だから、外す元の基準が見えないまま「ケースバイケースで」と言われると、せめて、そう決めた感覚だけでも少し言葉にしてほしいんです。

人に行動を求めるなら、その物差しが自分の中にしかないのは、おかしいと思うんですよね。だから僕は、共通認識としてベースになる基準を、先に見えるところに置いておきたい。その上で「今回は特殊なケースだから、この情報をつけよう」と変える。僕の言う臨機応変は、そういう動きです。

報告と判断のあいだで#

基準が見えないままだと、いちばん困るのは報告の場面です。

僕は、判断を求める側と判断する側のあいだに立つことが多いです。報告をまとめてデータを出すと、判断する側から多いと言われます。そうかと思えば、これでは何を判断すればいいか分からない、とも言われます。過去に言われた視点を思い出しながら、その点を入れて詳しく書いたこともあります。足りないと言われた時に、「気になるから」と聞かれたこともありました。

たとえば、傾向を見て次のステップへ進む承認をもらいたい時です。マクロに見れば進めていいと思っているところへ、懸念として、今の段階でのデータの完全性を指摘される。悪く言えば、傾向だけで次のステップを深掘りしていこうとしたら、今の段階での完全性を指摘された、という感じなのかな、と思います。

完全性の指摘が細かくなっても、進むかどうかの答えが変わるようには、僕には見えません。いや、そう思っているのが僕だけかもしれない。それなら、やっぱり基本は全部出した方がいいのかな、となります。

でも、全部出せば今度は多いと言われる。

基準が見えないまま毎回リスクを考えると、結局は全部出すことになるんですよね。逆に、判断する側が何を大切にしているか、つまり基準が見えていれば、報告はこう分けられるはずです。

• 今、次のステップへ進んでよい根拠
• 何が出たら承認を止めるのか
• 今は答えを変えないけれど、次の段階で確かめること

データが完全でないことと、次へ進む判断ができないことは、同じではないと思っています。報告がこの三つに分かれていれば、足してほしいと言われた情報が今の判断に要るのか、次の段階で確かめればいいのかを、分けて考えられるはずです。分かれていないと、報告する側としては、全部を出すか、どこかを削るか、くらいしか選べない気がしています。

先に置いておきたいもの#

何を大切にしたいのかは、言語化されるべきだと思うんです。それをプロダクト開発に落とし込んだのが、インセプションデッキだと思っています。

チームでインセプションデッキを作ったことがあります。全部が活用されたわけではないんですが、その中のトレードオフスライダーで何を優先するかが決まっていたので、バグ修正の優先順位もそこから決まりました。その上で、「これは例外になってしまうけど、価値があるので」と提案することもできました。

例外を出すこと自体は変わらなくても、基準が先に見えていると、例外を例外として扱えるんだと思います。これこそが効率化だと思っていて、シンプルに僕が効率厨なのかもしれません。まあ、エンジニアは怠惰であることが美徳ですからね。

ほかに、基準の置き方として浮かんでいるのは、判断する側に「何が出たら止めるか」を先に言ってもらうこと。それから、過去の判断を並べて、そこに共通しているものを基準として言葉にすることです。「何が出たら止めるか」は、やったことがなく、例として浮かんでいるだけです。

基準の言語化といえば、体験を伴わないと意味のない言語化、みたいな話もあって、関係がありそうなんですが、その話は今回は置いておきます。

ケースバイケースそのものを否定したいわけではなくて、変えるなら、変える前の基準が先に見えるところに置かれていてほしい、という話です。