Will Larson のスタッフエンジニア本（日本人向けインタビューも拡充した日本語版）を読みました。補章にて 組織の情報流通はマネージャーを中心に設計されている とあり、そのとおりだと思いました。
GitLab のように、非同期ファーストかつ SSoT であらゆる情報を共有できる組織は稀です。通常は上層部の中で内密な会議が行われ、その決定事項が必要に応じて中間層や現場層にも落とされます。要は会議という原始的な手法を使っているせいで、どうしても伝達が人伝になってしまう。これは 構造的な問題 なのです。
この構造における肝がマネージャーです。中間管理職と言ってもいい。なぜ肝かというと、経営層と現場を繋ぐ存在だからです。あるいは経営層が絡まない現場の意思決定においては、事実上の王様です。彼らが情報を降ろさない限り、現場層は情報を知ることができない。
すべてのマネージャーではありませんが、たいていのマネージャーは情報を出し惜しみます。もしくは渡さないこともある。
これも構造的な問題であり、情報共有≒会議として伝える、と思い込んでいるからです。会議にはコストがかかります。仮にメンバーが 5 人いるとして、5 人との会議を毎回設定するのでしょうか？
よくマネージャーの立場の人から言われるのは「聞いたら答えるからオープンだ」ですが、そんなものはオープンではありません。いつでも誰でもアクセスできるように公開して、はじめてオープンと言える のです。
エンジニアリングマネージャー含むマネージャー向けに、情報の出し方をお教えします。
これにより、マネージャーであるあなたは定期的に、負担をかけないやり方で情報を共有できるようになり、メンバーの信頼を勝ち取れるでしょう。また、メンバーは情報に基づいた行動がしやすくなるので、純粋にプロジェクトも回りやすくなります。一見すると、定期的な共有の手間に顔を歪めてしまいますが、それだけの価値があるのです。
定期的で非同期的な情報共有(Regular Asynchronous Information Sharing) とは、その名のとおり定期的に、しかし非同期的に情報共有を行うことです。*RAIS と略します。
パラメーターを決めて、実践するだけです。
パラメーターは 3 つあいます。
詳しく見ていきましょう。
頻度については毎日、週一、月一などがあります。
私は DWMY と呼んでいますが、手元で日次で整理し、週次では日次の整理内容をもとに整理し、月次では週次の整理内容をもとに整理します。もちろん年次では月次の整理内容で整理します。このように積み上げていくことで、整理の負担が現実的になります。
逆に考えてみてください。日次や週次の整理なしに、いきなり月次で共有するとしたら？おそらく 30 日分の振り返りが必要です。大変すぎます。これが、DWMY を心がけていると（週次で整理した分を見ればいいだけですから）4～5 個で済みます。
基本的には あなたが会議して得たことのすべて です。このすべての情報からどれだけ引き算するか、と考えてください。
どの情報が誰の役に立つかはわかりませんので、あなたの意思で選定するというよりも、なるべく広く情報を出すことを心がけてください。
内容のつくりかたですが、DWMY をおすすめします。特に日次で――つまり毎日 その日行った会議で得たことを整理する ことです。5 分のスロットをつくって箇条書きするだけでも構いません。無理にすべての会議について書かなくても構いません。
仮にその日 7 個ほど会議をしたのなら、理想は以下のようなリストですが、
- 会議1
- 要約
- 要約
- ...
- 会議2
- ...
- ...
会議4と5はプライベートすぎて出せないから書かない、でも別に良いのです（むしろこのような会議の内容を共有する方が問題です）。また、2-3行でもいいのです。
さて、実際に共有する内容ですが、週次がバランスが良い と思います。しかし週次の分をつくるためには、日次で毎日こまめにつくっておいた方がやりやすいです。人によっては週次のタイミングでまとめて振り返った方がやりやすい人もいるようです。細かい運用は各自調整してください。あなたが行うことなので、あなたがやりやすいやり方で良い。
少なくともチームの動線となっている場所に流します。おそらく Slack などのチャットでしょう。プロジェクトによってはメーリングリストもありえるかもしれません。
チャットだと書きづらい場合は、ウィキやノートやリポジトリ（に置いた Markdown）でもいいですが、その URL を動線に流すことも忘れずに。