こんにちは、虎の穴ラボのH.Kです。
この記事は虎の穴ラボ・夏のブログ企画の一環として、今週のテーマである「マネジメント」について記載しています。
22日目はH.Hさんによる『Trelloを使った自動タスク管理 』が投稿されました。 24日目はY.Fさんによる『開発者も学ぶべきマネジメントのことと、参考書籍紹介』が投稿されます。
この記事で言いたいこと
- こまめな情報開示を行おう！
- 自分だけが持っている情報をなくそう！
かと言ってすべてを開示したら問題のあることもあるので、そのあたりの線引やメリットについて紹介します。
こちらが本記事の目次です。
筆者の立ち位置
私は1つのプロダクトチーム（以降チームA）のメインプログラマと、いくつかの小規模なプロダクトを統括するチーム（以降チームB）のエンジニアマネージャを兼任している状態です。
マネジメントという観点では、以下の3つの立場を持っています
- メインプログラマ（1開発者）としてのセルフマネジメント
- チームAのプロダクトマネジメント
- チームBのエンジニアマネジメント
「チームAのプロダクトマネジメント」についてですが、虎の穴ラボではエンジニアが提案し、サービスのことを考え開発を進めていくことを重視しています。
そのためメインプログラマですが、積極的にプロダクト自体の方針や新機能の仕様策定、開発以外の全体的なスケジュール管理も行っています。
また、虎の穴ラボでは2020年の春からリモートワークを始めており、今後もリモートワークを続けていくことを決定しています。
prtimes.jp つまり「雑談」「察する文化」「覗き見」による情報共有が難しい状況にあります。
情報開示手法
虎の穴ラボではコミュニケーションツールとしてSlackを使用していますので、Slackで情報開示を行うことが多いです。
他にも情報量が多い場合はGoogle ドキュメントやGoogle スプレッドシートを利用します。
意識的に開示している情報
私が意識的にメンバーに開示している情報は以下の通りです。
- 個別で実施したミーティング内容の議事録
- 設計時の選択肢
なぜ、上記のようなことを積極的に開示しているかを説明します。
個別で実施したミーティング内容の議事録
個別で実施したミーティング内容の議事録を開示する理由は大きくわけて3つです。
- 自分が振り返るため
- ミーティング相手との認識相違をなくすため
- 他のメンバーが何話していたか気になるだろうから
個別実施のミーティングは虎の穴ラボでは主にGoogle Meetを使って行われます。
相手の時間を使わないように可能な限り非同期コミュニケーションを利用しますが、コンテキストの共有に大きく時間がかかりそうな場合や、ある程度の質疑応答が必要で同期的に双方向のコミュニケーションが取りたい場合に使用しています。
ざっくり言ってしまえば、同期的なコミュニケーションのほうが結果的にお互いの作業に集中できそうなケースです。
自分が振り返るため
こちらに関してメリットは自明かと思います。
決定事項について、言った言わないはもちろん、結局どうなったのだっけということを振り返ることができます。
また、何かあったときの引き継ぎ工数を削減できます。
いわゆるトラック係数を下げることができます。
※トラック係数
急にメンバーがいなくなった場合の冗長性の指標のようなもの
ミーティング相手との認識相違をなくすため
自分が振り返るためとかぶりますが、話しているうちに結論が二転三転することがあります。
その際に議事録を提示することで結論のみを効率よく確認することができます。
同期コミュニケーションによる不都合を議事録という非同期コミュニケーションで解決しています。
他のメンバーが何話していたか気になるだろうから
こちらは一長一短なります。 まずはメリットについてお話します。
例えば、数名でミーティングを行い、終了時に「話したいことがCさんだけ残ってください」みたいな形で話があると内容気になっちゃいますよね？
「私、気になります！」とはなるものの直接聞くのも……とちょっとはばかられますよね。
私は公開して差し支えない情報であれば公開してしまえという方針でいます。
もちろん、プライベートな内容や社内でも機密になっていることは公開しません。
デメリットもあります。
関係のない情報が入ること自体がノイズになる可能性です。
個別に残って会話しているということは、会話の内容は主にその人にしか関係のない話題になることが多く、他の人がその内容を読む時間的コスト、もしかしたらさらに反応してしまうコストがかかる可能性があります。
これを最小化するために適切なチャンネルで書くことは常に意識しています。
ただ、反応してしまうコストはメリットになることもあります。
2人での会話では抜けていた観点やより良いアイデアが生まれる可能性に繋がります。
このようにメリット・デメリットはありますが、最終的にチームとしてどちらが健全かを考えると情報を共有してしまったほうが良いと判断しています。
設計時の選択肢
ここからは設計時の選択肢について、なぜ情報開示しているのか説明します。
「個別で実施したミーティング内容の議事録」の開示と基本的に重複します。
重複しない部分の理由は大きくわけて2つです。
- 意見を聞くか悩む微妙なところの意見を聞くため
- 自分の思考フローを共有するため
自分が悩んだところは他の人も悩む可能性があるという視点で共有を心がけています。
このときの共有内容はかっちりとしたフォーマットではなく、「こうしたいんだけど、こんな感じでよいかなー」のように口語体ベースで書くことが多いです。
これは返答不要な独り言であることをベースにしているためです。
虎の穴ラボでは各プロダクトごとに分報チャンネルという、ある程度自由につぶやける場所があります。
設計については分報チャンネルにつぶやくことが多いです。
もちろん、決定事項については設計資料に検討した内容とともに記載します。
意見を聞くか悩む微妙なところの意見を聞くため
設計や実装について他の観点からも見てもらえることを期待して共有するパターンです。
例えば「少し冗長なコードだけど可読性の高いコード」と「短いがやや可読性に欠けるコード」どちらがいいかみたいなのを、自分がそれぞれで良いと思った根拠を踏まえて開示します。
これに対するリアクションのパターンとしては、
- 誰も反応しない
- どちらかを支持してくれる
- 新しいパターンを提案してくれる
などが考えられ、誰も反応しなければ、自分の意見で進め、その他であればチームとして良い方向に進むことができます。
細かい実装についてミーティングで直接聞くまでもないレベルの確認は情報開示で済ませることで、効率的に進められます。
もちろん検討結果は設計資料に反映します。
設計資料はDesign Docsの形式で記載しており、「どうしてこうしたか」の下書きのような扱いとしてそのまま利用することができます。
コードレビュー時には資料を見てもらえれば、悩んだところと最終的になぜそうしたかが明確になるので、やりやすくなっています。
自分の思考フローを共有するため
思考フローの共有の意義としては相互での成長です。
リモートワークになって、他の人がどのように仕事を進めているのかが、わかりにくくなってしまいました。
幸いなことに各メンバーは独力で仕事を進めるだけの能力を持っています。
しかし、「より良く進める」となると個人で成長していくことは用意ではありません。
そのため、自分は「こうやって進めている」「こう考えている」ということを共有することで、問題があれば指摘してもらい、良いところは真似できる環境を作っています。
情報開示時の注意点
当然ながら、情報開示することにもデメリットはあります。
開示する際に気をつけていることは以下のことです。
- 開示内容
- 開示範囲
- 開示タイミング
前述していますが、プライベートな内容や社内でも機密になっている情報は開示しません。
また、開示する対象のチャンネルは考える必要があります。
プログラミング設計の情報をシステムに触らないメンバーが多い場所で情報開示をするとログが流れてしまったり、メンバーが余計なことを考えてしまうことがあります。
そして、開示タイミングも重要です。
「他のメンバーが何話していたか気になるだろうから」や「意見を聞くか悩む微妙なところの意見を聞くため」のような理由で情報を開示するときは早いほうが良いです。
これは他のメンバーがもやもやする時間を減らすことや、やや独善的ではありますが、自分が一人で悩む時間を減らすことに繋がるためです。
逆に他の場合は、チャンネルの流れや自分の作業状況を見て行ったほうが良いです。
まとめ
本記事では私が実施しているチームメンバーへの情報開示について書きました。
メンバーの習熟度やチーム規模にもよるので一概に情報開示したほうが良いとは言いにくいところはあります。
しかし、出社していたときのコンテキストの共有具合を想像するとこのくらいはやっても良いのではないかと私は考えています。
皆さんもこんな基準でメンバーに情報を下ろしているよ、みたいなのがあれば教えていただきたいです。
P.S.
虎の穴ラボでは、私たちと一緒に新しいオタク向けサービスを作る仲間を募集しています。
詳しい採用情報は以下をご覧ください。
