白猫のメモ帳

C#とかJavaとかJavaScriptとかHTMLとか機械学習とか。

参照透過性のあるリーダーになれるか

あけましておめでとうございます。
お正月気分でいたいけど、この時期ってなんとなく忙しい気がします。

さて、リーダーになると意思決定をする場面が増えてくるかと思います。
自身が詳細を理解し、確認をしたり指示を仰ぎながらする作業とは異なり、メンバーから上がってくる(一部の)情報から物事を判断するのは簡単ではなく、とてもプレッシャーのかかる仕事です。

判断は関数

仕事において何かを判断するとき、与えられた情報と自身の持つ知識や経験をもとに結論を導きます。
情報(インプット)→あなた→結論(アウトプット)です。
そう、つまりあなたは関数です(暴論)。

同じことを聞いたときには同じ回答を貰えることをメンバーは期待します。参照透過性です。
毎回結果が違うと「あの人この前と言ってること違うじゃないか」と愚痴を言われてしまいます。

コンテキストって言葉難しいよね

毎回全ての情報の情報がインプットされるわけではありません。
以前聞いた話だったり、別の人や資料から得た情報、いま現在の状態など、物事を判断する材料は他にもたくさんあります。
これをざっくりとコンテキストと呼びましょう。(知識とは別物)

例えば「この仕事の締切は~までだ」などはオープンなコンテキストです。
一方で「今度~機能をリニューアルしようという話がある」などは、
リーダーは知っているけどメンバーは知らないというクローズなコンテキストである可能性は十分にあります。

後者の話で、もしその機能を最優先で改善しようみたいな話をしていた場合、
リーダーのコンテキストが更新されたタイミングで優先度を下げるという判断になることは普通にありそうです。
一方でメンバーにとっては知らない情報なので、単純にリーダーがこの前と言っていることが変わっているように思ってしまいます。

では、全ての情報をフラットに共有すればいいかというとそういう訳ではありません。
組織のレイヤーによって持っている情報が異なるというのはごく自然なことです。

ここで大切なことは、コンテキストによって判断が変わることがあるということをメンバーに理解してもらうことです。
そのためには逆に同じコンテキストであれば同じ判断をする人だと信頼してもらわなければなりません。

マクロな判断基準を伝える

判断に一貫性があるとメンバーはリーダーの判断基準がだんだんわかるようになってきます。
そのためには結論とセットでどうしてその判断をしたかという理由をちゃんと伝える必要があります。

AでBでCのときにDと言われたというただの結果だけを覚えても、少しでも条件が変わってしまえば判断ができません。
Aのときには〇〇を気にしないといけないからDなんだと認識してもらうことが大切です。

例えば、Webサイトの改修をしていて「このリンクの位置は良くないからここに移動しよう」という判断をしたとします。
特に理由も伝えなければ「あー、この人はここにリンクを置くのが嫌いなんだな」と認識されてしまうかもしれません。

一方で「この近くにあるリンクと誤認することによってユーザビリティが下がるかもしれない」という意図を伝えれば、
ユーザビリティの観点が甘かったから次回からもう少し注意するようにしよう」と考えてもらえる可能性は上がります。

メンバーのレベル感に合わせてにはなりますが、できる限り抽象的な(マクロな)視点を伝えられると良いです。
目的が何かというのを認識してもらうこともとても大切です。
このあたりはまた別の記事で書けたらいいなと思います。

まとめ

・同じ情報のインプットがあるとき、同じ判断ができることが好ましい(参照透過性、一貫性)
・常に情報の全量がインプットされるわけではなく、判断にはどうしてもコンテキストが紛れ込む
・コンテキストには共有されているものと共有されていないものがある
・コンテキストによって判断が変わることはメンバーに理解してもらったほうが良い
・ミクロな判断ロジックを数多く持つことはコストが高く、判断がぶれやすい
・マクロな参照透過性のある判断ロジックを持ち、伝えることでメンバーとのベクトルは揃えやすくなる

こういう内容ってあんまり書いてこなかったので、文章にまとめるのって難しいですね。
どんどん脇道に逸れていって着地地点がずれていってしまう気がします。
スラスラ書けるようになりたいものです。