93
51

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

事前に議事録を用意し何ならそこで議論を始めてしまう手法を試している

Last updated at Posted at 2023-02-03

定例ミーティングの準備、どうしていますか?

多くのエンジニアがそうであるように、私の所属するチームで毎週定例のミーティングをしています。
この記事は、この定例ミーティングに向けてどのような準備をしているかという話です。

私の所属するチームは私を含め3人に非常に小規模なチームです。そのため、チーム運営のための実験も比較的簡単に行うことができます。

以前のやり方

この方法にする前は、各々が今週の進捗や、話したい内容を、手元にテキストで用意しておいて、定例ミーティングでSlackにガッと投稿して、それを見ながら報告をするという手法でした。

この方式には以下の問題点がありました

  • ミーティングのその人のターンが来るまで、どのような内容が話されるか不明
    • 即座に意見があれば返す必要がある
    • ミーティングに出席できないと意見を出しそびれる

まぁ重大な意見であれば後日改めて伝えればよいのですが、ちょっとした疑問や、アドバイスのようなものは機会を逃すと「伝えるまでもないか・・」となってしまい、せっかくのチームのシナジーの機会を逃してしまいます。

また、ミーティングで話題になった内容について、即座に自分の意見を練って主張するというのはある種の特殊なスキルが必要な行為であり、そういうものをあえて求める必要はないだろうと考えました。

事前に議事録を用意するやり方

以前のやり方を改善するために、まずは社内にHedgeDocを用意しました。
これはHackMDのオープンソース版で、リアルタイムに共同編集できるWikiです。

image.png

週の初めに、このHedgeDocにテンプレートを作成し、その週のうちミーティングで話す内容を記載するという方式にしました。

弊社では似たようなツールとしてQiita TeamやGitHubのWikiがあったのですが、今回は「リアルタイム共同編集」を試したかったのでHedgeDocを利用することにしました。

リアルタイム共同編集の無いWikiの一つのページに複数人が編集しようとすると、どうしても編集のコンフリクトが起きます。

まぁ3人のチームでそれがどれだけ起きるのか?という話ではあるのですが、コンフリクトを恐れるあまり、一気に書こうというモチベーションが高まってしまい、結局MTGギリギリにまとめて書き込むことになり、以前と同じく、ミーティングのタイミングで早押しクイズ的に内容を確認し意見するような状況になってしまうのを避けたかったのです。

この方式により生まれた効果

ミーティング時に読み上げることが不要となった

議題をみんなでゆっくり読む時間が不要となりました。
もちろん重要な内容や込み入った内容については、立ち止まって読みますが、意見がなさそうな「確認事項」的なものは読んでいる前提でサクサクと進め、本当に議論が必要なトピックに時間を割けるようになりました。

ミーティングより前に話が進む

疑問形で議題を書いておくと、ミーティングより前にメンバーがそれを見て、その答えや、さらなる問題の深堀りのための質問を書き込むことができるようになりました。
システム的には、そこで何往復もテキストでやり取りすることも可能ですが、多くの場合は1~2往復のやり取りとなっています。

議事録に書くことで解決する問題や、予めその内容について、調べてからMTGに臨むことができるようになり、ミーティングの時間のやり取りが、より実のあるものになったと感じます。

雑談コーナーの設置

ミーティングの議題とは別になにか話したいことがあれば書き込める「雑談コーナー」というのも用意したところ、定形のトピックとは違った、チーム運営のための意見や、チームメンバーの関心のネタについての書き込みなども集まるようになりました。

また、時間に余裕がある週などは、業務でよく扱うGo言語のTipsの共有など、ちょっとしたLTのようなものも行う機会となっています。

課題

機械生成コンテンツと人間のコメントが混ざった文書の更新

ミーティングでの進捗報告は基本的にはGitHubのIssueをベースに行うため、テンプレートは一括で作成します。
その方法については以下の記事で紹介しました。

しかし、チームのメンバーが担当するIssueは時々刻々と変化するため、これを一度生成しただけだと、定例ミーティングの開催時には情報が古くなっており、記載漏れのあるIssueが発生してしまいます。

現状ではそういうIssueで、大事なものは、それぞれが手動で書き足すか、大して重要でないものであれば、なにもせず、翌週に確認するようにしています。

もし、機械生成コンテンツに人間のコメントが混ざった文書に、再度機械生成のコンテンツの差分をパッチする事ができれば、このような問題は起きず、新鮮な進捗状況を文書にできると考えています。

結局ギリギリに用意する

この方式も、はじめは目新しく早めに用意したり、雑談コーナーに色々書いたりするのですが、段々とそういうことも減ってきて、結局ギリギリに用意することになったり、雑談コーナーも寂しくなってしまうことがあります。

まぁ、これは別に悪いことではなく、いつでも雑談に書き込める状況を維持すること、早く書くことは強制ではないので、そこのハードルを上げずに、選択肢を増やした状態を維持することが大切なのかなと感じています

まとめ

まだ、探り探りですが、ミーティングの議事録を事前に用意することで、より効率的なミーティングの実現と、チーム内でのコミュニケーションを促進する方法について紹介しました。

93
51
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
93
51

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?