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

記事内容をなんとなく箇条書き化して転載しましたinajob
アクティブ読書などご自由にどうぞ

定例ミーティングの準備、どうしていますか?
多くのエンジニアがそうであるように、私inajobの所属するチームで毎週定例のミーティングをしています。
多いのかyosider
確かに自分もしているyosider
これに加えて朝会してるチームもありますねinajob
この記事は、この定例ミーティングに向けてどのような準備をしているかという話です。
私の所属するチームは私を含め3人と非常に小規模なチームです。そのため、チーム運営のための実験も比較的簡単に行うことができます。

以前のやり方
この方法にする前は、各々が今週の進捗や、話したい内容を、手元にテキストで用意しておいて、定例ミーティングでSlackにガッと投稿して、それを見ながら報告をするという手法でした。
この方式には以下の問題点がありました
まぁ重大な意見であれば後日改めて伝えればよいのですが、ちょっとした疑問や、アドバイスのようなものは機会を逃すと「伝えるまでもないか・・」となってしまい、せっかくのチームのシナジーの機会を逃してしまいます。
また、ミーティングで話題になった内容について、即座に自分の意見を練って主張するというのはある種の特殊なスキルが必要な行為であり、そういうものをあえて求める必要はないだろうと考えました。

事前に議事録を用意するやり方
以前のやり方を改善するために、まずは社内にHedgeDocを用意しました。
これはHackMDのオープンソース版で、リアルタイムに共同編集できるWikiです。
週の初めに、このHedgeDocにテンプレートを作成し、その週のうちミーティングで話す内容を記載するという方式にしました。
弊社では似たようなツールとしてQiita:TeamやGitHubのWikiがあったのですが、今回は「リアルタイム編集」を試したかったのでHedgeDocを利用することにしました。
リアルタイム共同編集の無いWikiの一つのページに複数人が編集しようとすると、どうしても編集のコンフリクトが起きます。
まぁ3人のチームでそれがどれだけ起きるのか?という話ではあるのですが、
大体のコンフリクトは(同じ場所を書いてるのでない限り)自動解決しますよbsahd
コンフリクトを恐れるあまり、一気に書こうというモチベーションが高まってしまい、
結局MTGギリギリにまとめて書き込むことになり、以前と同じく、ミーティングのタイミングで早押しクイズ的に内容を確認し意見するような状況になってしまうのを避けたかったのです。

この方式により生まれた効果
議題をみんなでゆっくり読む時間が不要となりました。
もちろん重要な内容や込み入った内容については、立ち止まって読みますが、意見がなさそうな「確認事項」的なものは読んでいる前提でサクサクと進め、本当に議論が必要なトピックに時間を割けるようになりました。
実際に事前に読んでるんだろうかyosider
自分なら結局ミーティング始まってから読んだりしそう
自分が書くときに既に書いてあったら読む感じでやってます、他の人は知らないけど、、inajob
疑問形で議題を書いておくと、ミーティングより前にメンバーがそれを見て、その答えや、さらなる問題の深堀りのための質問を書き込むことができるようになりました。
Scrapboxみたいに箇条書きに割り込んで書けるのだろうか?yosider
(そもそも箇条書きじゃない?)
Scrapbox的に箇条書きですね、まぁ初手の会話だけなので浅い階層ですが、、inajob
システム的には、そこで何往復もテキストでやり取りすることも可能ですが、多くの場合は1~2往復のやり取りとなっています。
議事録に書くことで解決する問題や、予めその内容について、調べてからMTGに臨むことができるようになり、ミーティングの時間のやり取りが、より実のあるものになったと感じます。

雑談コーナーの設置
ミーティングの議題とは別になにか話したいことがあれば書き込める「雑談コーナー」というのも用意したところ、定形のトピックとは違った、チーム運営のための意見や、チームメンバーの関心のネタについての書き込みなども集まるようになりました。
コーナーというのは、大きな文字で「雑談コーナー」と書いてあってその下にスペースがあるような感じだろうかyosider
YESinajob
先日は「節分ですね」とか書いておいた
メンバーの皆さんはまじめなので、乗ってくれないけど・・w
うーん、答え方が難しい気も、、wyosider
家族で豆まきする人とかがいれば乗れるかもしれない
答える内容はないけど和んでる人はいそうyosider
ハモ的なコメントをなるべく書くようにしている
また、時間に余裕がある週などは、業務でよく扱うGo言語のTipsの共有など、ちょっとしたLTのようなものも行う機会となっています。

課題
機械生成コンテンツと人間のコメントが混ざった文書の更新
ミーティングでの進捗報告は基本的にはGitHubのIssueをベースに行うため、テンプレートは一括で作成します。
その方法については以下の記事で紹介しました。
ちゃんとIssueにして管理してるのえらいなあ…yosider
(自分のところがおかしいだけかもしれない)
ここは割と徹底してて、作業してるけどIssueが無いというのはかなり稀ですねinajob
しかし、チームのメンバーが担当するIssueは時々刻々と変化するため、これを一度生成しただけだと、定例ミーティングの開催時には情報が古くなっており、記載漏れのあるIssueが発生してしまいます。
現状ではそういうIssueで、大事なものは、それぞれが手動で書き足すか、大して重要でないものであれば、なにもせず、翌週に確認するようにしています。
もし、機械生成コンテンツに人間のコメントが混ざった文書に、再度機械生成のコンテンツの差分をパッチする事ができれば、このような問題は起きず、新鮮な進捗状況を文書にできると考えています。

結局ギリギリに用意する
この方式も、はじめは目新しく早めに用意したり、雑談コーナーに色々書いたりするのですが、段々とそういうことも減ってきて、結局ギリギリに用意することになったり、雑談コーナーも寂しくなってしまうことがあります。
まぁ、これは別に悪いことではなく、いつでも雑談に書き込める状況を維持すること、早く書くことは強制ではないので、そこのハードルを上げずに、選択肢を増やした状態を維持することが大切なのかなと感じています

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

inajob
意外と長い歴史があった
井戸端に来たのが2022/01
この手法を始めたのが2022/06
この手法について記事を書いたのが2023/02
ここからScrapboxの導入に持っていけるかどうか様子をうかがっている
まぁScrapboxの導入が目的ではないのだけれど・・
ブラケティングありがたい
意外と赤リンクばっかりだな
これは他のコンテンツをScrapboxに持ち込む際に有効なテクニックに見える
コメントしやすくなった
機械的にできるか?
親子構造を構成するところは難しそう
Scrapboxに記事に対するメタページを用意するの面白いな
お手製はてなブックマーク的な
Veinを思い出したsta

Twitterでの反応
>@konya: 雑談コーナー設けたらちょっとしたライトニングトークが始まるとかすげー良いな。うちじゃ読者もそういないブログすら全然かいてくんないもんな https://t.co/aon7KVkuVz
ブログの方がハードル高くない?基素
+1inajob
定例議事録に書いておけば、絶対見てもらえますしね
>@YukiharuYABUKI: 事前にやる内容が決まってない。だと、アジェンダを作って読んでから会議に参加しろってしないと、確かに無駄だよな。
>参加している人数*時間の工数を無駄にしないためにも。
>@mogmod: お。正しいな。
>@mogmod: 「反射神経を鍛える」という意味では定例報告聞いた瞬間からのコメントなり質問なり指示なりするのも悪くなかろうけど、必ずしもそうではないからなぁ。
セールスの人とか特に反射神経を鍛えたいという気持ちもあるのかもしれないと思ったyosider
>@yotiky: 概ね似たような感じではあるなぁ。やってることとか雑談減り気味とか。
>何度か事前にレス書き込んだことはあったけど、議事録で会話進めちゃってダメってこともないもんな。
>@yohe1981: うちのチームだと、エクセル用意して、担当セル内に進捗書くようにしてる。
>問題にある通り、同時編集で書けなかったり、ファイル破損したり、そもそも表計算ソフトに文字を書く気持ち悪さがある。
>こういうの探してみよう。
クラウド版だと共同編集できそう基素
>@Shaula0x0400: 雑談コーナーいいかも?
>チームメンバーによるか。
>説明文ゼロのMTG突っ込んでくるのを違法化したいので、こういうハックしてる人をとても尊く思う。。slackで作業依頼したらMTG入れさせて5分で終わるのとか物凄く不毛ーーーー
slackで作業依頼したらMTG入れさせて5分で終わるのってどういう意味だ…?yosider
Aさんに作業依頼したら、Aさんが「MTG入れさせて!5分で終わるから!」と言ってくる?
>@moguno: 事前議事録は大事。
>@bori_jp: テレワークが始まって3年ちょっと、未だ定例ミーティング決定版への道半ばな今日このごろ : 事前に議事録を用意し何ならそこで議論を始めてしまう手法を試している - Qiita https://t.co/9bobSPGBP9
>@9Satoooh: このやり方すき
>@7188162: なお弊社は HedgeDoc を立てずに MS365 で実現した(なお会議の際に障害で使えない
>まぁエンジニアにとって Markdown の方が書き味がいいのはそれはそう
>@yoshinon: 非同期的会議を共有議事録上でやったのちに会議か。
>ありだな、これ。


コメント
> うちは共有事項や課題を会議前に先に書いておいてもらって最初にみんなで黙読しながらドキュメントにコメントをつけてもらう、その後に必要があれば発言、質問の流れでやってます。Amazon がそんな感じだそうで真似てます。
> "アマゾンの会議は沈黙から始まる。「15分の黙読」の理由は? | Forbes JAPAN 公式サイト(フォーブス ジャパン)" https://forbesjapan.com/articles/detail/38226
忙しすぎて事前に読めなかった人のための時間?yosider
というかこの時間があれば全員この時間に読むか
以前読んだことがある記事だtakker
残念ながら、外部リンクは2 hop linkしないので以前読んだときの記録は掘り出されなかった
> それは議事録ではなくアジェンダでは
せやねinajob

> Qiitaのトレンドに入っても、はてブはそんなに付かないのね(内容の問題も大いにありそうだが、、)inajob
セルクマして他の人のブクマを促してみるinajob
はてブって世代交代起きてるのかな...基素
>(そうだけど。それって事前に議論する時間をとることを強要しているのでは問題。また、○日から○日までの間に読んでコメントしといてね、としても、早い者勝ち的な状況が生まれるのでは。)
特にそういう事は起きていない、議事録内で「決定」をしないからなinajob
> レジュメ作るなんて当たり前だろ 会議は始まるまでに8割方終わってないと
はいinajob
hai-smalltakker
(それが本当に当たり前かどうかは置いておいて)当たり前を書くだけで文句言われるのつらいなMijinko_SD
これに関しては自分も同意だなのでそこまでダメージ無いかなinajob
一旦ん?と思った後に冷静に字面を読み返す程度には気になるが・・
あたまに「そうだよな、」とか書いてあればそこまで文句にも見えない
明確に筆者をdisられるのが辛い(めったにないけど)
> “まずは社内にHedgeDocを用意。HackMDのオープンソース版でリアルタイムに共同編集できるWiki。共同編集の無いWikiの単一ページを複数人が編集するとコンフリクトを避けるため一気に書くため結局MTGギリギリ、を避けたい”
要約するタイプのブクマだinajob
> 自分は議題や主要論点があらかじめわかっているときはそうしてる。あと、ヒアリングとか調査報告書もまず最初に調査事項書いた報告書のテンプレ作ってから出かける。

> 自分はチームメンバーの進捗を大体把握してる体でメモを書いて、定例はその確認会にしてる。事前に書かせる方式だと書き方に凸凹があるんで統制とりにくい。
統制をとるという考え方inajob
統制=formatということだろうか?takker
+1sta
> どうやって実現するかはさておき方向性は健全

>そもそも、その議論が必要か?という点も前提にある。

> 資料を朗読してもらう場だと思ってる(と、認識すらしていない可能性も大きい)層が一定数居るので、会議は儀式だと思ってあきらめてる

> みんなで同時に編集できるドキュメントはオンラインでは無いとどうにもならないし、オフラインでもめっちゃ便利だよね。Google DocsもSpreadsheetもすごい助かってます。

log(下ほど新しい)
inajob
チーム振り返りをOffice365のWordの共同編集機能で似非Scrapboxみたいな感じで実施してみた
振り返り開始前に議論がある程度進んでいて良かった。参加者も好感触だった様子
Google Waveみたい、と言われた
Google Wave使ったこと無いまま終了してしまったが、どんな感じだったんだろう?
Office365は実績があるので社内で簡単に使えたのがこれを使った理由
次回はScrapbox(ScrapboxのBusiness planの体験版)でできないか聞いてみよう
ひとまずやりたいことは非同期MTGであってナレッジベースを作りたいわけではない
このとき、音声もありですか?それとも、音声無しでWordの共同編集のみで実施した感じですかね?meganii
先に非同期でやって、後から音声でもやりました
音声でやる時間が短くなりました
なるほどmeganii

会社でCodiMD使って、いままで同期でやってた毎週の進捗定例を半分非同期化してみた
今週動きのあったissueを列挙しておいて、そこに各々コメントを書く
このコメントは揮発するので、issueに書くよりより気軽に書ける
良さそう。こういうイメージですか?sta
ですです、今まではこのテンプレをGitHub Wikiに貼って、各々コメントをつけてSlackに投稿しつつリアルタイムでMTGしてました。
テンプレはこの方法で生成 GitHub CLIでチーム週報を生成する - Qiita
非同期で議論するのは抵抗がありそうだが、「初手の質問を非同期で書けるのが嬉しい」という反応を得た
今は同期会議も併設してるので、議論はそっちでやったほうが効率が良いという話
どこまでをIssueにちゃんと書いてすすめて、どこまでを非同期定例で話題にするかは明確な線引きが難しい
人によりそう
Issueを持っている本人がコメントするというより、他のメンバーが質問するケースが多い
「案があるんですけどどうでしょう?」みたいなのは既にIssueで非同期に実施出来ていて、わざわざ定例を待つ必要がない
よくわからないが止まってしまっていたり、議論が平行線になってしまっている物について定例に持ち込む
初手だけ非同期、いい感じの折衷案かも?yosider
CodiMDにした理由
本当はScrapaboxが良いが・・
ツールが乱立するのを避けたい
これも新しいツールなような…?基素
言葉足らずですね、契約などを少なくしたいみたいなニュアンスで書きましたinajob
が、ツールが乱立しているのは事実なので、あまりよくは思われてなさそう
データを外に預けるのに抵抗がある
一応社内にOffice365のWordがあるが、これはなんか使いづらい(一度試したが、やはりなんか使いづらい・・)
Google Docsの方が良い? 使わないのでdisableになっていたが、使いたい旨を上司に伝えてみた
Googleのツールは既に使っているので乱立とか外に預ける問題はクリア済み
社内に開発環境として好きに使えるマシンがあるので、勝手にCodiMDをインストールするのが、スモールスタートとしては楽だった
育休明けてから、「技術的な作業をやる人」ではなくて、「情報の交通整理をやる人」になってきたので、こういう試行錯誤ができるようになった
こっちの方がタスクの時間が読みやすく、育児しながらの仕事として相性が良い
なんだかんだで社歴が長いのでメンバーの中では、この作業に向いている
作業をあまりやらなくなって、だんだんチームメンバーが手段の面で何をやっているのか分からなくなってきているのがちょっと心配
それでもマネージは出来るが、現場に戻れなくなりそう
まぁ9か月育休しても戻れたので、その点はあまり心配ないのかも
技術的な手段の面での決断の精度が落ちる
育児の始まりと、コロナによる外出自粛の影響で、非同期コミュニケーションの価値に気付くことができた
もともとWikiが好きなので、ちょっとバイアスがあると思うが・・
井戸端を知ったのも大きい。Scrapboxを見ただけでは、ここまでできるツールであることのイメージがつかない
いい話基素yosider
Scrapboxの良さを伝えるには井戸端を見せればいいのか…?yosider
もう少しきれいな井戸端があれば()

毎週の定例の非同期化2回目。早く終わるようになった。良い。
同期会議で良くないと思うこと
トピックの共有がギリギリとなり、クイズゲームのような思考で質問する必要が生じる
アジェンダ用意しろ、という話なのだろうが、毎週の進捗定例なので、準備をおおごとにしたくない
瞬発力が求められるyosider
ファシリテーターがトピックを読み上げる時間が無駄
当然合意だろ、というような内容は素通りで済ませたいが、読み上げをみんなで黙って聞くことになる
たまに合意じゃないケースがあるのでファシリテータとしては読み上げないと行けない感がある
これは同期会議のままでも改善方法はありそう
非同期化、というのは色々誤解を生みそうだな、、  「事前に議事録を用意し何ならそこで議論を始めてしまう手法」 とかかな

ナレッジはたまらないが定例会が効率化できたのでひとまず良い
雑談レベルのQ&Aも文字で頭出しするのようにした

社内にScrapboxやNotionを導入しようかどうしようか、という話を少しした
すでに文書管理ツールがあるので、目的を明確にしないとツールが乱立するだけだよね、という話になる
リアルタイム共同編集を魅力に感じているが、それ以外を見ると機能の重複が多い
すでにある文書管理ツールのデータを引っ越すのは面倒そう
かといって新しい目的軸を立てるようなものかな・・
会社の文化をこのツールでこうしていくぞ!みたいな強いモチベーションも今のところないし、人を選ぶツールだと思っているので押し付けたいわけではない・・
ぬるっとHedgeDocを野良運用して、雰囲気をつかんでからもう一度考えようという流れに・・
Ctrl+iで自分の名前を入れたい気持ちになる・・
雑に書きまくって残しながらおしゃべりする、みたいな使い方に割り切る、というのはどうでしょうsta
私は雑談ならぬ雑残と呼んでいるのですが
「管理する必要はなくて、日常会話みたいにその場の適当なノリで良い」「ただ残るだけ」「この残るってのがミソで、後々楽しくなってくるのですよ~」みたいな
まずはこの使い方で慣れてもらう。そうすれば後続の活動(移行?)もしやすくなるかもしれないsta
いまは、週次定例MTGのアジェンダを事前に書いておこう、ということで1週間前からページだけ作ってます
「雑談コーナー」というのを用意しており、そこで業務と無関係の話題を書けるようにしている
一応小規模な雑談が繰り広げられているので目論見通り
ただ、雑談はSlackがあるので目的が食いあっているのが気になる
ああ、既にSlackで雑談場があるのですね。この認識を覆す(雑談場を変える or 増やす)のは大変そうsta

事前に議事録を用意し何ならそこで議論を始めてしまう手法のミーティング、最近結局事前に非同期コミュニケーションするのが減ってきたな
アジェンダが自然と事前にできるだけでもありがたいのだが、、
忙しいと面倒くさくなってくる?yosider

実は、中学一年生の時に無駄だと思って、先に紙にまとめてもらって、わざわざ報告しない、追加であるなら発言するというシステムを生徒会とその他委員会が集まる会議で導入したんですが、効率は上がったけど、会議そのものの必要性が問われ始めた記憶があるGorira Tatsu

この手法の良さというか、inajobさんの采配が改めてすげえなと思ってるsta
井戸端民から見ると「それくらい当たり前」なんだけど、現実では全然通じない
inajobさんの会社はエンジニアが集まってて通じそうなイメージあるけど、それでもおそらく通じてない
ましてstaのSIerや、その他大勢の組織で通じるはずがない
通じない人達に、ではどこまで通じさせるか?
ここが難しい
僕は他人の気持ちわからんので「こんなこともわからないの?」「ほら、丁寧に説明書いてやったぞ、読め」みたいなムーブをするんだけど、なぜか相手にされない(例。実際の口調や動きはもっと丁寧)
本ページの塩梅は「伝えやすい塩梅」なんだと思った