エンジニアリングマネージャーの情報コントロール術
この記事はEngineering Manager Advent Calendar 2019の19日目の記事です。
久津（@Nunerm）です。CAMPFIREでプロダクトマネージャーをやっていて、CAMPFIRE Ownersという融資型クラウドファンディングのサービスを担当しています。
この記事では、エンジニアとステークホルダーの間で情報のINとOUTをコントロールする際に気をつけていることをまとめます。組織によってベストプラクティスは異なると思いますが、何かの参考になれば幸いです。
前提：情報はオープンにするべき
「情報のコントロール」とは情報を意図的に隠すことではありません。例えばSlackでのDMやプライベートチャンネルの利用率が高いと、情報の非対称性によって属人化が進み社内政治が蔓延ります。
※ EOF2019で登壇されていた@tokorotenさんの「チャットコミュニケーションの問題と心理的安全性の課題」は必見です。
もちろんそういう組織を目指したいのではありません。心理的安全性のレベルを高く保つためにも、またエンジニアチームの成長のためにも情報は可能な限りオープンにするべきです。
とはいえ全ての情報がオープンになることで生まれる弊害もゼロではありません。整合性の取れてない一時的な情報を受け取ることによって、エンジニアが必要のない思考や作業に時間を取られてしまったり、ステークホルダーに伝えたいことが変な形で伝わってしまって誤解を解くために奔走したり…
なのでマネージャーとしてその間に入り多少の情報加工を入れることで、チームの生産性の低下を防ごうと心がけています。
不要な周波数の音をカットしたり、目立たせたい音の周波数を強めたりする機能です。
エンジニアチームに情報をINする時に気をつけていること
不確実性の高い噂話はカットする
例えば今のタスクの優先度が大きく変わりそうな噂話が出たとします。トップダウンの組織だと「おい、〇〇さんが新しいことやるとか言い出したぞ…」みたいなw
それがもしエンジニアが作業中の開発に影響がある場合「あれ、これやめた方がいいのかな？」と勘繰ってしまいます。そしてその噂話の真相を確かめる動きをしてしまうかもしれません。これは生産性に大きく影響します。
もし本当に優先度が変わるのであれば早めに察知することに越したことはないので、噂が出たらほぼ確実にその通りになるような組織であればカットする必要はないですが、意思決定に調整が必要で時間がかかるような組織であれば、不確実性の高い状態で情報が渡ってしまうのを回避するべきだと思っています。
重要な情報をブーストさせる
逆にエンジニアに届けるべき情報はブーストさせる必要があります。
一例として組織変更の実施に関する情報を挙げてみます。過去によくあったのは、組織変更の内容は細かく説明されるのですが、その狙いが「ナレッジを展開できるようにするため」とか「意思決定を早くするため」とか抽象的なままで情報が渡ってしまうパターンです。これだと組織変更によって促進したい個人レベルの行動の変化は起こりにくいです。
その場合は、狙いの部分をより鮮明にし丁寧にインプットすることが求められます。具体的に日々のワークフローのどこを変えるのか、どういう新たな取り組みを始めるのか、そしてそれに向けでどういう行動をしてほしいのかなどを、補足・言語化/可視化して伝える必要があります。
また同様にエンジニアリングによる二次的、三次的な成果が出た時もブーストさせます。例えばクライアントからのリーチが増えたとか、ダッシュボードからは知ることのできない他組織からの情報で、エンジニアリングに関連するものはしっかりエンジニアに伝え、成果を実感してもらいたいです。もちろんネガティブな情報も含めて。
エンジニアチームから情報をOUTする時に気をつけていること
伝えたい情報を際立たせる（ふわっとしない）
経営層や他組織のマネージャーに、エンジニアチームや開発状況に関する報告をする際に気をつけていることです。時間も限られているので、どうしてもサマリでの報告となってしまいます。特にエンジニアリングに強くない相手には「細かいこと言っても伝わらないしな…」と思い、どんどん抽象度が上がってしまいがちです。
ただそれだといい信頼関係は作れないと思っています。特にネガティブ情報を伝える際に理由がふわっとしていると「誤魔化してる感」が出てしまいます。
なのでポジティブ情報もネガティブ情報も、その事象における本質部分は際立たせて話すようにしています。「開発が早くなった」ではなく「〇〇のこういう取り組みによって開発効率がN％上がった」とか、「開発が遅れているからリスケしたい」ではなく「前回の緊急案件によって生まれた技術的負債によって遅れが生じているため、リファクタリングの期間を設けたい」のように伝えるように心がけています。
これによってエンジニアチームへの信頼度を高めることができます。
このように情報を多少加工（イコライジング）をすることで、チームの生産性や環境を改善できると思っています。
終わりに
DTMや編曲に興味のない方はわかりづらいかったかもしれませんがご容赦くださいw
そして自分もそんなに詳しくないので例えが間違ってたらごめんなさいw
自分なりの工夫をまとめてみましたが、もちろんいつもうまくできているわけではありません。情報の加工の仕方を間違えて結果的に生産性を下げてしまったことも多々あります。また組織のフェーズによっても必要な加工の仕方は変わってくるので、日々チューニングしながらベストなやり方を身につけていく必要があります。
精進していきましょう。
おまけ
最後に担当してるプロダクトの宣伝をさせてください。
融資型クラウドファンディングのCAMPFIRE Ownersを担当してます。
既存の金融機関や金融サービスからの資金調達が難しい事業者（法人・団体・非営利組織）の方々を対象に、クラウドファンディングを活用した資金調達の手段を提供します。モノやサービスをリターンとする既存のCAMPFIREとは異なり、日々の経営で得た利益の中から資金を返済する方が相性の良い事業者に向けて、新規サービスを立ち上げました。
また同時に投資家が「応援しながら資産運用ができる」場を創っていきたいと思っています。自分の資産が誰かの挑戦のための資金になり、その結果として利息が返ってくるWin-Winな関係が多く生まれるサービスを目指します。
こちらにサービスに込めた思いなどを書いていますのでご一読いただけると嬉しいです。
また現在絶賛エンジニアを実施中です。一緒にこのプロダクトを作っていきたい、という方はTwitterでDMください！
