bon now

2年ちょっと前、まだ僕がマネージャーなりたての頃初めて自分の部下を持ったのだが、そのときにこの「適切な情報とその量を、適切なタイミングで流すことは結構大事」というフィードバックを部下にしたことがある。(部下って書くとなんか気持ち悪いので今後はメンバーで統一する)
改めて自分の今の状況に鑑みつつ、このフィードバックってなんでやったんだっけということを考えてみる。

情報はすべて開示することが望ましいのはそう

まず色んな情報がまんべんなく社内・社外に公開されていているのはそりゃ望ましいよねっていうところから。
でもそれと 流量=情報をどれだけ流すか は同じではないかなと考えている。

例えば良いニュースと悪いニュースを同時に出すのは理に適っているとしても、 良いニュースを3つ、悪いニュースを1つ出すのが良いのか、良いニュースを1つ、悪いニュースを3つ出すのが良いのかは割とその時の雰囲気とか情報の鮮度・優先度にもよるところがあるよねっていう話。

同時多発的に開示することで、もちろん見る人は見るだろうけど、多すぎる情報を1日で伝えるのは食傷気味になりがち。 だからといってタイムリーさを失うと、共有の意味をなさないものもまれにある。
この言葉にできないというか状況によって変わってしまう見えざる価値をどういう視点で展開していくかってのがすごく大事…ということを多分言いたかったのかもしれない。

で、どうすればいいの？

僕に具体的な答えがあるわけではないけれど、例えばこのブログではよく名前の上がる名著と僕が思ってる HARD THINGS には、「悪いニュースはその日のうちに出す」ということは決まっているらしい。
他にも解雇通知や嬉しいお知らせとかはその場ですぐ全体共有というのを徹底するとかなんとか。これはBasecamp社も同じだったような気もしないでもない。
書籍化されてるようなアメリカ企業は、どこもこういう情報の流し方についてもノウハウを持っていて然るべきタイミングで然るべき内容を伝えるというのは型になってる気が個人的にはしている。

あと、情報という意味では他人へのフィードバックに対しても、GREAT BOSSやHARD THINGSには「クソサンドはやめろ」と書いてるように、褒めたいこと2つの間に悪いことを1つ入れるみたいなのは悪手とのこと。 これも結局は情報の伝え方について流量を制御していると言い換えることもできるんじゃないだろうか。良い→良い→悪い、あるいは悪い→良い→良いという感じに、情報の直列性に加えてstackされた情報をどれから流し込むかはマネージャーたる話し手にかなり委ねられている。

これが、いわゆる見えざるスキル……だと個人的には考えている。エンジニアにおいてはこんなこと考えて話してる人よりも、MECEか、構造的か、破綻していないかっていう論理的思考を優先して話してる人のほうが多いと思うので、多分これはエンジニア組織間で言語化されたスキルにはなってないはずだ。
なので代わりに僕がこれに対して一意な名前をつけるとすると、これを情報整理力と呼ぶことにしよう（そのまんまじゃん

言わなくていいものは捨てる

組織や企業の透明性っていう言葉から「公開すべき情報はすべて流す！」みたいな捉え方をしている人も一定数いるんじゃないかなーと思うので僕の考えをいうと、それはNoである。
もちろん個人のパフォーマンスについて社長が知っているに越したことはない。スティーブ・ジョブズは自分の知らん実装や仕様については、それを考えた本人に直接話しを聞くってことをやっていたというように、知る権利は誰にでも与えられている。
が、実際は開示する権利については定められていなければ義務でも必須要件でもない。

会社の善意のもとで成り立っている仕組みをあたかも当たり前品質のように捉えて「悪いことをなぜ今まで隠していたの！」だとか「会計処理をもっとオープンに！」とか言ってる場面はちょいちょい色んな会社でも起きると思う。
ではこれらがオープンになったからといって一体誰が喜ぶのだろうか。
ほとんどの従業員は、情報の波に飲まれて「わいは自分の仕事の周りで起きてることさえ知れたらいいや」になるのではないだろうか。Slackで別の課やチームがやり取りしている内容を四六時中監視しますか、っていうとしないよね。でもTwitterは頻繁に観測する……社内のことではないのに(笑)みたいな情報の非対称性が違う意味で発生してしまうパターンもあるだろう。

なので、不要な情報は捨てて構わない。ただし、捨てる先はゴミ箱ではなく、ドキュメントであるとなお良いんじゃないかと個人的には思う。

ここ数年でコロナの影響によりリモートワークやら半出社やらという働き方が生まれたことにより、非同期コミュニケーションの重要性・捉え方がだいぶ変わってきたのではないだろうか。そこで僕が注目しているのは、ドキュメント文化である。

ドキュメント文化はアジャイルに非ず？

アジャイルをかじった人のなかには「アジャイルなんだから対話とコミュニケーションで補えばドキュメントは最小でええんやろ？」という人もいる。それはそうだ。 ただし、リモートワーク化におけるアジャイルは、対話を生むための仕組みを意図的に作らないとなかなか難しいというのは多くの人が体験したのではないだろうか。
それに、日本のエンジニア界隈は人材の流動性が割と激しい。後から入ってきた人をアジャイルチームにいかに早くなじませるか、パフォーマンス高く仕事してもらってモチベ上げてもらうかは離職率にも影響するのでやっておきたいというのがマネージャーの課題の1つだと思う。そういうときに対話ベースでやれることももちろんあるが、多くのアジャイルに関係のないプロダクト生産性に直接関連づかないが、間接的に影響を及ぼすようなものってのはドキュメント化しておいたほうがどう考えても効率が良いわけだ。

コードしか書かないエンジニアはドキュメントの日本語も怪しいところはあるし、生産性が著しく低下する人もたまにいる。まぁここは得意な人が書けばいい話で、適材適所である。 そんなことよりも、アジャイルチーム全体生産性を新規メンバー参入時、既存メンバー離脱時、組織再編時にいかに早く上げるかである。 言い換えれば発生し得るリスクをどういう方針で対応していくかということだ。
少しずつマネージャーっぽい仕事内容になってきたぞ。つまり、マネージャーがドキュメント文化について一定の考え方や方針を持っておかないと、 アジャイルがドキュメントを持たない文化として定着してしまうリスクもあるよということである。

マネージャーが情報制御やれ

ということで、情報の流量制御から始まった話は、なぜかドキュメント書け！に行き着くこととなった。
さらにそのドキュメントはマネージャーが書けばいいという話もした。
つまり情報を制御することも、そこからドキュメントをどう生み出すか、どういうチームにしていくかも全部マネージャーが考えろということだ。

口頭ベースで話したほうが良いめっちゃ優先度高く重要な情報 → 最悪でも全社メールかSlackメンション

文書でもいいし別に公表する必要もない → ドキュメントにまとめてSlackやメール通知(通知すらしなくて良いパターンも有)

数人で決まったなんかしらの仕様やオフィス内で会話した結果 → ドキュメントにしつつ関連チーム・メンバーにメンション　

こんな感じ。これを「やれ！」っていうんじゃなくて、マネージャーがやる。そうするとそれが会社の文化になっていく。
結果、「社長がなんか会社の売上や利益率も全部出したいっていってるねん」というのも、周りのマネージャー陣がそういう仕組を作って上げればいいわけで、 それを会社の文化にしたい・なりたい・やっていきたいっていう想いを皆が共有しているのであれば、やるしかないわけだ。

これを読んでマネージャーって意味のないことばっかやってるわけじゃないんだなーって思ってくれる人がいたら嬉しいし、 マネージャーの役割を担っているような人も、あなたのやっている、成果に直接つながらないけど実は文化を育んでる影の立派な仕事を評価してくれる人はどっかしらにちゃんといるということを知ってもらえると嬉しい。