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

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

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

判断は関数

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

ドキュメントは書けるベースじゃなくて欲しいベースで

こんばんは。
大掃除は仕事納めの後にと思っているのですが、とてもアレルギーな私です。
これはまずいかもしれない。リスクヘッジは大事です。

さて、皆さんドキュメント書いてますか。
チームのナレッジが溜まっていかないんだと困っていませんか。私は困っています。

結局自分ひとりじゃ書ける量って限られてるし、できればメンバーの成長のために書いて欲しいし。
自分で書ける範囲でいいのでなるべく書いてねっていうんだけど、なかなか貯まらない。
うーん…。ちょっと発想を切り替えてみましょう。

欲しいドキュメントを探そう

書けるドキュメントじゃなくて逆に欲しいドキュメントをみんなで探してみましょう。
最初は特に思い浮かばないなと思っても、直近の仕事を振り返ってみたりすると、
「この概念実はまだよくわかってないんだよね」とか、
「ここのデータの流れってどうなってるかいつも混乱しちゃう」とか、案外欲しい物が出てきます。

で、出てこなくなったら今度は足りていないと思うドキュメントをみんなで書いてみましょう。
直近困ってはいないけど、これまとめておいたほうがいいよねっていうものが出てきます。
そして足りていないものはなんだってなると、今度ドキュメントがちゃんと分類されていないことに気づきます。

ドキュメントを分類・整理しよう

じゃあドキュメントをちゃんと分類して、どんなページ構成、ディレクトリ構成（使ってるツールによる）が正しいのかなって考えてみましょう。
整理できると更に足りないドキュメントが見えてきます。
ついでにいらないドキュメントもたくさん見えてきます。
思い切って全部アーカイブにしましょう。
もしかしたら見るかもと思って消すのをためらうくらいなら、とりあえずアーカイブにしておけば良いです。
明らかにいらないってなったら然るべきタイミングで削除すればOKです。

優先度と担当を決めよう

足りないドキュメントがわかったら、今度は優先度をつけましょう。
「すごく欲しい」「割と欲しい」「それなりに欲しい」などのどれくらい欲しいかを表すレベルと
「今すぐ欲しい」「なるはやで欲しい」「～までに欲しい」などのいつ欲しいかを表すレベルの2軸とかで考えるといい気がします。

優先度がついたら担当者を割り振りましょう。
特定の人しか書けないとか、○○さんに書いて欲しいとかいうのがあれば優先的に担当者を割り振ります。
量が多ければ最初から全部割り振らずに、ひとまず優先度が高いものにするなどの作戦もOKです。

担当者を割り振ったら担当者ごとに取り掛かる順番と期限を決めましょう。
期限は仮で構いません。全部の期限を守れるわけではないかもしれませんが、期限がないよりずっと良いです。
仮でも期限があると書かなくちゃという気持ちになります。
先に空のページとか作っておくのもありです。

更新のルールを決めよう

最後に更新のルールを決めましょう。
一回書いたら満足して放置となるとドキュメントの信頼度はどんどん下がっていきます。
どうやって更新するかのルールを決めましょう。

無難なのはドキュメントごとに棚卸し期間を設けることです。
このドキュメントは3ヶ月に1回、こっちのドキュメントは1年に1回チェックするよなど。
棚卸ししてみて更新が必要なドキュメントは更新が必要だよってマークと、何を更新してほしいかのコメントを付けます。
どうしても時間がかかってしまうので、棚卸しする人はマークとかコメント付けに専念するのが良い気がします。

というわけで

っていうのをやろうと思って取り組んでるよって話でした。
まだまだ志半ばではありますが、なんだかんだで充実し始めてはいるので効果はあるんじゃないかなって思いたいです。

ドキュメントのレビューとかをどうするかみたいな課題もあったりしますね。
とりあえず、「こんなドキュメント欲しいよ」「作ったよ」「ありがとう」っていって増えていったら嬉しいですね。

おひさしぶりです

とてもとてもおひさしぶりです。
なんと前回の記事が3年前です。

プライベートで大きなトラブルがあってしばらく離れていまして、
気がついたらコードを書く機会が殆どないような役割になってしまったので、
特にネタもないなと思ってご無沙汰になってしまいました。
なんやかんやあって、今はエンジニアの組織で管理職とかをやっています。

技術ネタばかり書いていたので、それ以外を書くのもなんかなと思っていたのですが、
アウトプットする場がないっていうのはあんまり良くない気もするので、
思いついたことをたまにつらつらと書くことを再開してみようかなと思います。

プログラムに限らず技術の話とか、読んだ本の感想とか、組織とかビジネスとか…？
いやまぁ別に今日の晩ご飯が美味しく作れたとかでもいいとは思うんですけどね。

ちょこっとだけでも気軽に書けたらいいな。