f:id:shinyorke:20211202204140p:plain

入社前に想定していた以上に毎日が楽しいです*1.

それはさておき, つい先日に前職の同僚であるエンジニアリングマネージャーの@jazzsasoriさんとサシ飲みしたのですが,

「エンジニアリングマネージャーとかテックリードとかになると, 議事録（的なメモ）」を取る力無いと辛いよね, 案外言及されてないけど

という話題になりました, 酔っ払ってあんまり覚えてないけど🍻*2

で, どれぐらいの方がこの話題に興味あるのかな?と気になり,

昨夜、久々に前職エンジニアリングマネージャー氏と飲んでて、何かの拍子に「エンジニアがビジネスな力をつける訓練の一つとして議事録書くのがいいんだよね」的な話をしたのですが

「エンジニアのための議事録書き入門」とかいうブログ記事って需要あると思いますか皆さん🤔
— Shinichi Nakagawa / 中川伸一 (@shinyorke) 2021年12月2日

なんて, 試しに呟いたところツイートに対するリアクションから察するに需要がまあまああったので

自分がよくやってるミーティング・メモ（いわゆる議事録）の方法を紹介
ミーティング・メモを取るために使ったほうがいいサービスとかツール（後者は主にVSCode）
ミーティング・メモを書き慣れてみよう（読み慣れてみよう）

というメモをしたいと思います.

TL;DR

「メモを取る」作業と「メモを整理する」作業を分業化してミーティング・メモを作ろう
「メモを取る」作業はSlackなどのチャットツールのチャンネルやDMを活用
「メモを整理する」作業は予めmarkdownでテンプレを用意&チャットのメモから整理しながら作成
Google Docsなど, クラウドの共同編集ツールを活用しよう（ただし使い方には注意）

このエントリーを書いてる人

@shinyorke
コンサル企業のエンジニアで, マネージャーをしております
ミーティング・メモはよく書きますし, よくレビューします

私の「ミーティング・メモ」メソッド

理屈の説明はあとにして, まず自分がどうやってミーティング・メモを取っているか紹介します.

「メモを取る」 - チャットに書き込む

ミーティング中のメモの基本中の基本として,

誤字脱字は気にしなくていいので, ひたすらメモを取る！

だと信じています, ミーティング中の発言・議論はフロー情報（≒時系列で流れる）モノなので記録が大事です.

誤字脱字は後で修正が聞きますが, 聞き漏らしは挽回できません.

もちろん, 録音している場合は聞き直せば良いのですが, 毎回録音はできないでしょうし, 何よりもフローな情報なだけに, その場の温度感の記録・スナップショットを取るのが大事かと思います（後者は私のオピニオンですが）.

ひたすらメモをとる
フロー情報で時系列

この目的にあったツールが存在します, フローな情報を記録するのにSlack等のチャットは超便利です！

f:id:shinyorke:20211202202243j:plain — Slack DMでメモをとる（実際使ったやつ）

個人的なミーティング・メモ（上のスクショは数年前に某社の面接を受けた時のメモです）はSlack DMをよく使います&仕事のときは会社・チームのルールで使ってOKなチャットサービスを使います（Slackのときもあれば, teamsなときもある）

普段使い慣れてるチャットであれば躊躇なくかけると思いますし,

専用のチャンネルを作って複数人でつぶやきながらメモ*3
気になる論点があればその場でスレッド化して重ねてメモ*4
そして何よりも, 書き込んだらタイムスタンプが残るので時系列に残せる！

なんてことができるのですごく便利です.

「メモを整理する」 - markdown + VSCodeで読み書き

ミーティングが終わったあと（もしくはミーティングの後半）に, 正式なミーティング・メモ, いわゆる議事録に仕上げる作業をします.

作業的には,

チャットに書き込んだ「フロー情報」としての議事メモを, 意味ある単位の「ストック情報」として「メモを整理する」

事になります. 「決まったこと」「決まってないこと」「次のアクション」が整理されていることが最低条件です.

ミーティング・メモや議事録のテンプレートがあればそれに当てはめる作業になるかなと思いますが私はよく,

「自分が情報を構造化しやすいテンプレートをmarkdownとして用意してチャットのメモを貼り付けながら整理」という手段を取っています.

ちょこっと公開するとこういうノリです.

# MTGのタイトル+日時

## アジェンダ

- hoge
- fuga
- bar

## 参加者

- @shinyorke
- @hoge
- @fuga

## 議事メモ

### Aの件

- a
- b
- c

### Bの話

- a
- b
- c

### Cについて

- a
- b
- c

## Next Action（宿題）

- [ ] Todoその1
- [ ] Todoその2
- [ ] Todoその3

これをミーティングの前に用意します.

あとはミーティング後にチャットから切り貼り&分類しながらやるといい感じになります

ちなみに先程のスクショみたいな例（自分の面接）のときはこんなノリです（架空の例です, 特定の会社を示すものではありません）

# X社最終面接 2019/7/1 19:00-20:00

## アジェンダ

- 自己紹介
- ディスカッション
- 条件交渉

## 参加者

- @a さん（CEO）
- @b さん（COO）
- @d さん（技術顧問）
- @shinyorke

## 議事メモ

### 自己紹介

- shinyorkeの紹介
- 他のメンバーの紹介
- 会社紹介

### ディスカッション

- 会社の事業
  - toCのアプリとtoBのSaaS
  - Webがメインでたまにアプリなプロダクト
- 現在の課題
  - 人がたりない
  - CTO候補ほしい
- shinyorkeに期待していること
  - まずはテックリード
  - ゆくゆくはCTOに...

### 条件について

- お給料
  - X万円
  - ストックオプション○株
- 福利厚生
  - 書籍購入
  - ○○使いたい放題
- 就業条件
  - オンライン・リモートの頻度
  - etc...


## Next Action（宿題）

- [ ] エージェントに感想を伝える shinyorke
- [ ] X社の人に連絡 shinyorke
- [ ] ストックオプションの件をCFOに確認 X社

会社やチームの議事録フォーマットが書きやすい（もしくは自由にしていい）というノリならここまでのメモはいらない可能性がありますが私の場合,

プロジェクトやチーム, もっと言えば会社が変わるたびにフォーマットに合わせるのは疲れる
言うてもMTGというものは「決まったこと」「決まってないこと」「次のアクション」が整理されていることが最低条件で, それが整ってさえいればフォーマットが変わってもどうとでもなる（コピペして体裁を整えて完成）.
何よりも, 自分の得意の型にハメてやったほうが生産性が高い！

雑に言うと, 「ひとまずWebアプリほしい今すぐ！」って言うときに得意な言語・Frameworkで開発しちゃうのと同じ感覚です.

ここはオレオレ・テンプレートを持っておくと超便利だと思います.

（これはミーティング・メモに限った話ではないですが）markdownエディターとして, 私はVSCodeを愛用しています.

動作が軽い
markdownのサポートが手厚い
addonを入れると, プレビューを眺めたり, サクッとPDFにできたりと超便利

この条件が揃ってる（かつフリー）な道具って意味でVSCodeは神だと思います.

anteku.jp

ググるとこういうノウハウが山程出てくるので, お好みで整理するといいでしょう.

ここまでできたら,

指定のテンプレに書き直す（コピペと整形）とか
特にテンプレなければPDFにして共有
Slackなどチャットの共有で終わるなら, markdownそのままで残す

などしたらおしまいです.

「ミーティング・メモ（議事録）はMTG後数時間, 遅くても当日中に出せ」なんてよく言われると思いますが,

この流れでいくと（慣れてくると）ミーティング終了後, 即レビュー可能なミーティング・メモが仕上がります！

注意すべきこと

以上が自分のメソッドの解説でした.

ここで自分が避けている・考えている事もちょこっと触れます.

議事録のテンプレを使うデメリット

これはその手の本やサイトでも言われてそうですが,

ミーティング・メモ（議事録）のテンプレにいきなり「議事メモ」書き込むのは原則NG

です.

これはついついやっちゃいがちですが,

WordやPagesなどのリッチなソフト・サービスだと段落やフォントなど気が散ることが多い*5
テンプレに合わせて書くみたいな事になるので作業スピードが落ちる
カーソルが上下左右に行くことになるので, 疲れる

など, あんまりいいことがありません, 「フロー情報」なうちはチャットで雑に書くほうが絶対いいです.

いきなりテンプレに書いてOKなパターンとしては,

日次・週次などの定例でテンプレが完全に決まってるかつ, 参加メンバーが慣れている
先ほど説明した「markdownのオレオレテンプレート」など, 自分が慣れている方法だったりする.

ぐらいかなと思います.*6

共同編集は取り決めがあるといい

世の中のサービス・ツールで「共同編集に強い」良いサービスがめっちゃあります.

Google Docs
Notion
HackMD

あたりは自分も大好きで, 使える状況のときは積極的に使っています（特にGoogle Docsは）.

共同編集で複数人が書けるとすごく捗るので積極的に使っていいと思いますが,

書いてる内容のコンフリクト. 他の人が書いたやつを変更しちゃったり消しちゃったり
サービス・ツールのバグでメモそのものが消失する
ブラウザの挙動やキャッシュクリアでも悲惨な事故が...

といった問題もまあまあ存在します.

私の場合, 積極的に使いつつも,

メンバー間で役割や書く箇所を決めて, コンフリクトを減らす*7
markdownとかで手元に自分メモを残す
Slack ,teamsのチャットなど「とにかく書き込む」チャットも併用する.

といったことをしながら同時に書き込むなどしています.

便利なサービスに乗っかることも大事ですが, 起こり得るリスクに備えて併用するとより捗るし何かあっても慌てずに済みます*8.

結び

というわけで, 好きな人が少ないけど大事な話である「議事録」改め「ミーティング・メモ」のお話でした.

結びとして, 「必要な理由」「プログラミングと変わりませんぜ」って話をしておしまいにします.

なぜミーティング・メモが必要か

実務的な意味では,

「決まったこと」「決まってないこと」「次のアクション」が整理されてないと, 後々困ることがたくさんある

なのですが, 「エンジニアの成長戦略（not生存戦略）」という意味では,

エンジニアリングマネージャーやテックリードなど, 上のステージに進む時に困るやぞ！

っていうのが理由となります.

クライアント・お客様との商談や定例MTG
採用関連のドキュメント. オファーレターなど.
メンバーとの1on1, 評価とか査定

これらには必ずと言っていいほどミーティング・メモがついてきますし, 何よりもしくじった時のインパクトが非常に大きいものになります（責任ある人が残すアウトプットなので）.

この役割を書き手としてしっかりアウトプットするためにも, 「ちゃんとしたドキュメンテーション力」は必要ですし, 自分が書かなくてもメンバーなど他の誰かが書いたドキュメントを最終承認する事も増えるでしょうし...と考えると, 「ミーティング・メモぐらいは書けるようにならないと職務が務まらない」とも言えます.

これは私の感想ですが, ミーティング・メモや議事録の書き方って学ぶ機会を失ったままの方が多いと思っていて*9かつ, 必要になった時に覚えるだと遅いという一面もあるので, このエントリーを読まれた方はぜひ「自主的に」ミーティング・メモを取る訓練からやってみるといいと思います, コツを掴んで書き続ければ確実に身につくスキルなので.

プログラミングと一緒

これは自分の考えですが,

飲み過ぎて記憶が断片的ですが、

「雑に議事メモ書いてサマリーしたら最低限のやつできるし、きれいに書けと言われたらそこからリファクタリング」

とかなんとか話したんだよね

なんてことはない、プログラミングと同じ
— Shinichi Nakagawa / 中川伸一 (@shinyorke) 2021年12月2日

やり方としては「プロのプログラミング」だと思っていて,

Webアプリをさっさと作らないと！ってなったときにひとまずmain.pyなりindex.phpなりで動く雑なアプリを作る, かのように「フロー情報な議事メモ」を残す
↑でやったアプリがいい感じになったらちゃんとしたFW（DjangoなりCakePHPなりRailsなり何でも）で書き換える. これが「ストック情報としてのミーティング・メモ」にする作業
最後, SPA + Backendみたいなノリで完成形に. ミーティング・メモのテンプレに合わせるなり何なりして提出がこれ

対象がプログラミング言語か人間が読み書きする言語かの違いなんですよね, そう思うとミーティング・メモを取るモチベーションに繋がるのではないでしょうか.

というわけで「酔っ払って思いついた」ミーティング・メモのブログは以上となります.

最後になりましたが, このネタを書くために色々お話してくれた強いエンジニア仲間の皆様, とくにこのネタのキッカケとなった会話の相手になってくれた@jazzsasoriさん, ありがとうございました！

評判がよかったら, 「ミーティング・メモを読む技術」とか続編も書きたい...かも.