エンジニアだからこそ作れた、ミーティングガイドライン策定までの道のり
これはなに？
primeNumber SRE の高塚 (@tk3fftk) です🙏
この記事はミーティングガイドラインをなぜ作成し、どのような流れで制定(社内公式化)に至り、これからどのように運用していくか、を綴ったものになります。
取り組み内容の共有と、エンジニア主導で会社のコミュニケーション文化を改善できるよ！という会社の雰囲気や文化的なところを知ってもらえると良いな、と思い書いてみています。
モチベーション
primeNumberに2022/07に入社してちょっと時間が経った2022/12月頃のことでした。
組織横断的なミーティングに呼ばれることも増えた一方で「目的やアジェンダの共有がない」ようなミーティングも見受けられました。
このようなミーティングは、参加是非の判断ができないなーとか、効率悪いなーといった課題を感じることが増えたタイミングで、Kyashのkonifarさんの Kyashミーティングガイドラインを公開しました - Kyash Product Blog が(少なくとも自分の中では)話題になりました。
ミーティングの準備や共有の文化を持っていなかったり、進め方について学んだり気にしたりしたことなかった方向けに、ミーティングガイドラインを提供することで、primeNumberのバリュー、8 Elementsの１つである「対話を力に」を強化することができるのではないか、と考えました。
エンジニアがどのようにミーティングガイドラインを作っていったか
ふりかえりドリブン
改めて当時のSlackなどを漁ってみると、上記のような課題感をSREチームの月次のふりかえりで議論し、Next Actionとして自分が作成を開始しました。
当時のSREチームは自分、兼務的に入ってくださっていたCTO鈴木さん、週3の業務委託の方という小規模チームだったのですが、無理やりにでも定期的にチームのふりかえりを実施していたからこそ始まった取り組みだと言えると思います。
「エンジニア」だからこその成分を取り入れる
「エンジニアは」と言うと主語が大きくなってしまいますが、少なくともエンジニアである自分はコミュニケーションが苦手です。
特に、その場で考えて話すことやアドリブで話すことが苦手だと自覚しており、苦手だからこそ「仕組み化」や「フレームワーク」でカバーしようという発想が生まれるのかもしれません。
(世界一流エンジニアの思考法で「ミーティングの準備をやめよう」と書かれていたりしますが、これは「準備に時間をかけすぎるな」ということであったり、今までは準備をしっかりやってきたという下敷きがあってこそだと思っています)
また、MUST, SHOULD, MAY はエンジニアにはおなじみ RFC から拝借したキーワードです。
(参考: RFC 2119 - Key words for use in RFCs to Indicate
Requirement Levels )
RFCとは、インターネット技術の標準化などを行うIETF(Internet Engineering Task Force)が発行している、技術仕様などについての文書群を指します。
といっても、意味合いが作成の過程でもはや英単語からも離れてしまったので、本当にキーワードだけ借りてきた感じになってしまっていますが「強制ではなく、みんなで守っていくものにしたい」というフィードバックを反映した結果となっています。
たたき台を作って素早くフィードバックをもらう
アウトラインや項目などはKyashミーティングガイドラインをベースに、自身の過去の経験に基づき、少なくとも今感じている課題を改善できるような内容を盛り込んだ「たたき台」を作成しました。
たたき台作成後、雑談チャンネルに投稿したところ、ポジティブなフィードバックや提案を多くいただけたので、作成の方向性としては間違っていなさそう、という確信を持てました。
なので、修正してまたフィードバックをもらって、、というのを何度か繰り返して初版の完成まで持っていきました。
なぜ社内公式化したか
ミーティングガイドラインの初版を作成したのは、2022年の12月です。
約1年半の時を経て社内公式化したのは、CTO鈴木さんからの発案がきっかけでした。
鈴木さんが公式化目的と課題感をまとめてくださった文章が良い感じに言語化できていると感じたので、そのまま貼ってみます。
ミーティングを効率的に実施し、会社全体の生産性を上げる
現状で効率的に運用されているMTGも多くあるが、今後入社されている方含めて共通認識を持ってMTGが運営されるようにしたい
課題感
MTGを通して対話を力に仕事を進めるのはとても良いことだが、一方で参加者の時間をブロックして他の仕事に割く時間を奪っているという側面もある。
事実として、アジェンダが事前に公開されていれば、非同期での議論で時間を短縮できたり事前に考えを整理して効率的に進められると思われる会議が、自分の参加している会議の中でもいくつかある（きっと皆さんが参加される会議でも少なからずあるはず）
社内の共通言語としてミーティングガイドラインを定義し、すべてのMTGがより効率的に運用される、運用されていない場合にガイドラインを参照することを是とすることで、より生産的に仕事を進められるようになるはず。
これからどのように運用していくのか
コミュニケーション本部と連携して、オンボーディング資料に盛り込んでいただいたり、定期的な見直しを行うような運用をしていく想定です。
公式化前に改めて色々な方にレビューを頂き修正していますが、かなり主観が入っているので、定期的な見直しは複数目線を入れられるような形で行っていきます (オープンソースのコミュニティっぽく運用できると理想かなーと思っていたりします)。
公式化するまで、ミーティングガイドラインは草の根活動的に「よかったら参考にしてみてね」くらいの温度感で共有されていました。
このような類のドキュメントは総じて「本当に届いて欲しい人」には届かないものだと思っているので、公式化されたミーティングガイドラインを共通言語に、より「対話を力に」していければと考えています。
(公式化、運用方針の調整はエンジニアリングマネージャーの秋田さんに尽力いただきました、ありがとうございます！ )
さいごに
ここまで記事を読んでいただき、ありがとうございました！
ガイドラインがミーティングに課題を感じている方の助けに少しでもなれば幸いです。
また、primeNumberに少しでも興味を持っていただけた方は、お気軽にカジュアル面談をお申し込みください！
エンジニアリングのみに留まらず、文化を一緒にimplementsしてくれるSREも絶賛募集中です👀
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？