誰も読まない議事録が量産される現場
プロジェクトの定例会議が終わると、必ず誰かが議事録を作成します。私がPMOとして関わってきた10年以上の経験の中で、議事録ほど「書かれているのに読まれない」ドキュメントはありませんでした。
中堅企業のシステム開発プロジェクトでよく見る光景があります。毎週の定例会議後、担当者が数時間かけて議事録を作成し、関係者全員にメール配信する。しかし、その議事録を実際に読んでいる人は参加者の半分もいません。次の会議で「先週決まったあの件ですが」と話を振ると、「え、そんなこと決まってましたっけ?」という反応が返ってくる。議事録には確かに書いてあるのに、です。
この状況、あなたのプロジェクトでも起きていませんか?
形だけの議事録が生まれる背景
なぜ議事録が読まれないのか。多くの現場では「議事録を作ること」が目的化してしまっているからです。ISO認証やプロジェクト管理規定で「会議には必ず議事録を作成すること」と定められているため、とりあえず作る。内容が伝わるかどうかは二の次になっています。
私が新人PMOだった頃、上司から「議事録は会議の録音みたいなものだ」と教わりました。当時は素直にそう信じて、会議で話された内容をできるだけ詳細に、時系列で記録していました。2時間の会議なら、A4で5〜6枚の議事録になることもありました。
私はPMOとして10年以上、多数のプロジェクトで議事録の作成と運用を担当してきました。若手時代は『会議で発言があったことを全部書く』ような時系列型議事録を作っていました。30ページに及ぶ議事録もありましたが、誰も読みませんでした。経験を積んで気づいたのは、議事録の目的は『会議を再現する』ことではなく『関係者を動かす』ことだということ。今の私の議事録は、冒頭に『決定事項』『アクション項目(担当・期限付き)』を配置し、議論の経緯は後半に簡潔に記録。1〜2ページに収まります。この形にしてから、驚くほど『読まれる議事録』になりました。20年以上かけて磨いてきたスタイルです。議事録は『書く技術』ではなく『関係者を動かす技術』だと、痛感しています。
そのプロジェクトでは、毎週金曜の定例会議後に私が議事録を作成し、月曜朝に配信していました。ある時、重要な決定事項について関係部署に確認したところ、「そんな話は聞いていない」と言われました。慌てて先週の議事録を見返すと、確かに決定事項として記載されています。でも、それは議事録の3ページ目、会議の中盤で出た話題として、他の議論に埋もれるように書かれていたのです。
「書いてある」と「伝わる」の深い溝
この経験から、私は議事録に対する考え方を根本的に変えました。議事録は「会議の記録」ではなく「プロジェクトを前に進めるためのツール」であるべきだと。書いてあるだけでは意味がない。読まれて、理解されて、行動につながって初めて議事録の価値が生まれるのです。
実際、読まれない議事録には共通点があります。時系列で議論が並んでいる。決定事項と検討事項が混在している。誰が何をいつまでにやるのか不明確。これでは読む側に「解釈する負担」を押し付けているようなものです。
忙しいプロジェクトメンバーは、5ページの議事録を精読する時間などありません。流し読みして、自分に関係ありそうなところだけ拾う。その結果、重要な決定事項を見落としてしまうのです。
読まれない議事録が生まれる構造的な理由
なぜ多くの現場で「読まれない議事録」が量産されるのか。10年以上PMOとして様々なプロジェクトを見てきて、私はいくつかの構造的な問題に気づきました。
「記録すること」を目的にした教育
多くの企業では、議事録の書き方として「5W1Hを明確に」「発言者を記録する」「時系列で正確に」といった「記録の作法」を教えます。これ自体は間違いではありません。しかし、記録することが目的になると、「誰に何を伝えたいのか」という視点が抜け落ちるのです。
私がPJM-A(プロジェクトマネージャー資格)の勉強をしていた時、議事録は「コミュニケーションマネジメントの一部」として位置づけられていました。つまり、議事録の本質は「記録」ではなく「コミュニケーション」なんですよね。でも、現場ではこの視点がすっぽり抜けています。
「議論の過程」への過剰なこだわり
金融系や公共系のプロジェクトでは特に顕著ですが、「なぜその結論に至ったか」を詳細に記録することが求められます。後からトレーサビリティを確保するためです。これは重要な要件ではあるのですが、すべての議事録でこれをやると読みにくくなります。
私が以前関わった大手企業のシステム刷新プロジェクトでは、議事録のテンプレートに「議論の経緯」という項目がありました。ここに会議での発言を時系列で記録するのですが、結果的に本当に重要な「決定事項」や「次のアクション」が埋もれてしまうのです。
議論の過程が必要なケースもあります。重要な意思決定や、将来の設計変更に影響する判断などです。しかし、日常的な定例会議まで同じフォーマットで書く必要はありません。ここに気づくまで、私は無駄に詳しい議事録を量産していました。
「完璧な議事録」を目指す完璧主義
真面目な担当者ほど陥りやすい罠があります。それは「すべてを漏らさず記録しよう」という完璧主義です。会議中に飛び交うすべての発言をメモし、後で整理して議事録にまとめる。この作業に2〜3時間かかることもあります。
でも、読む側からすれば、そんな詳細は必要ありません。知りたいのは「何が決まったのか」「自分は何をすればいいのか」「いつまでにやるのか」の3点だけなんですよね。
私も若い頃は完璧な議事録を目指していました。でも、ある先輩PMOから「議事録は新聞記事と同じだ。見出しだけ読んで内容が分かるようにしろ」と言われて、目から鱗が落ちました。新聞は忙しい読者のために、見出しと最初の段落で結論を伝えます。議事録も同じであるべきなのです。
伝わる議事録の3つの条件とツール活用
10年以上の試行錯誤の末、私は「読まれる議事録」には3つの必須条件があると確信しています。そして、現代のツールはこれらを実現するための強力なサポートをしてくれます。
条件1:結論を冒頭に置く「逆三角形」構造
読まれる議事録の最重要ポイントは、結論を最初に書くことです。会議の時系列に沿って書くのではなく、重要度の高い情報から順に配置する。これだけで議事録の価値は劇的に変わります。
私が20年以上かけて磨いてきた議事録のフォーマットは、必ずこの構造です。冒頭に「今日の決定事項」を箇条書きで3〜5項目。次に「アクション項目」を担当者・期日・内容の表形式で。その後に「検討事項」「次回議題」と続きます。議論の詳細は最後か、必要なければ省略します。
このフォーマットなら、忙しいメンバーも最初の1ページを見るだけで必要な情報が手に入ります。詳細が知りたい人だけ後半を読めばいい。読む側に選択肢を与えるのです。
Notionは、こうした構造化された議事録を作るのに非常に適しています。私が現場で使うなら、Notionのデータベース機能を活用します。会議ごとにページを作り、決定事項とアクション項目をデータベースのプロパティとして持たせる。こうすると、プロジェクト全体のアクション項目を一覧で見たり、担当者別にフィルタしたりできます。
Notionの良いところは、テンプレート機能で議事録のフォーマットを標準化できる点です。私がPMOとして参画するプロジェクトでは、必ず議事録テンプレートを作ります。「決定事項」「アクション項目」「検討事項」のセクションを予め用意しておけば、誰が書いても同じ構造の議事録ができあがります。
条件2:決定事項とアクション項目の明確な分離
読まれない議事録の典型的な問題は、「決まったこと」と「やること」が混在していることです。議論の流れの中に決定事項が埋もれていたり、誰が担当するのか曖昧だったり。これでは読む側が自分で情報を抽出しなければなりません。
私の議事録では、決定事項とアクション項目は必ず独立したセクションにします。そして、アクション項目は表形式で「担当者」「期日」「内容」「ステータス」を明記します。この4項目があれば、誰が読んでも自分のタスクが明確に分かります。
ここで重要なのは「書かない技術」です。会議で出た話題すべてを書く必要はありません。情報共有だけで終わった話、結論が出なかった議論、雑談に近い会話。これらは思い切って省略します。議事録の役割は「プロジェクトを前に進めること」であって、「会議の完全な記録」ではないのです。
Microsoft TeamsやSlackのような チャットツールと議事録を連携させるのも、現場で効く方法です。私が実践しているのは、議事録の「アクション項目」だけをチャットに転記する方法です。会議後、すぐにチャンネルに「今日のアクション項目」として担当者をメンションして投稿する。
これには2つの効果があります。1つは、議事録本文を読まない人にも確実にアクションが伝わること。もう1つは、公開のタイミングが早いことです。議事録の完成を待っていたら翌日になってしまうこともありますが、アクション項目だけなら会議終了後30分以内に共有できます。私が30年見てきた経験から言えるのは、情報は鮮度が命だということです。
条件3:当日中の公開と差分管理
議事録の公開タイミングは、多くの現場で軽視されています。でも、これが実は非常に重要なんですよね。翌日に公開される議事録と、当日中に公開される議事録では、読まれる確率が全く違います。
私は可能な限り、会議終了後2時間以内に議事録を公開することを目指しています。そのために、会議中にリアルタイムで議事録を作成します。決定事項が出たらその場で記録する。アクション項目が決まったらすぐに表に追加する。会議が終わる頃には、議事録の8割が完成している状態です。
この「リアルタイム議事録」を可能にするのが、クラウドベースのドキュメントツールです。Google DocsやNotionなら、会議中に書きながら、参加者全員がリアルタイムで内容を確認できます。間違いがあればその場で修正できるし、会議終了時には全員が内容を承認済みという状態になります。
私が現場で使うなら、Google Docsのコメント機能を活用します。議事録の内容に対して参加者が「ここは違う」「補足が必要」とコメントを残せる。これを会議後24時間以内に反映して、最終版を確定する。このプロセスなら、議事録の精度も上がるし、参加者の当事者意識も高まります。
ツール選定の判断軸:現場の文化に合わせる
ここまで3つのツールを紹介しましたが、「どれを選ぶか」は現場の文化と既存のツール環境で決めるべきです。私が30年見てきた経験から言えるのは、最高のツールよりも「使い続けられるツール」を選ぶことが重要だということです。
Notionは構造化と一覧性に優れていますが、初めて使う人には学習コストがあります。Google Docsはシンプルで誰でも使えますが、アクション項目の管理機能は弱い。Teams/Slackは即時性に優れますが、議事録としての体系性には欠けます。
私のお勧めは、これらを組み合わせることです。議事録の本体はNotionやGoogle Docsで作成し、アクション項目だけをSlack/Teamsに転記する。こうすれば、各ツールの強みを活かせます。完璧なツールはありません。現場の実情に合わせて、柔軟に組み合わせることが大切です。
議事録は「プロジェクトの血流」である
10年以上PMOとして議事録と向き合ってきて、私が最も強く思うのは「議事録はプロジェクトの血流である」ということです。血液が体中に酸素と栄養を運ぶように、議事録は決定事項とアクション項目をメンバー全員に届ける役割を担っています。
完璧な議事録より、続けられる議事録を
若い頃の私は、完璧な議事録を目指していました。すべての発言を記録し、議論の過程を詳細に残し、誰が読んでも分かる文章に仕上げる。でも、それは自己満足だったのかもしれません。読む側が求めているのは完璧さではなく、必要な情報に素早くアクセスできることなのです。
あなたのプロジェクトで議事録が読まれていないなら、まず「結論を最初に書く」ことから始めてみてください。次回の会議後、いつもの議事録の冒頭に「今日の決定事項」を3つだけ箇条書きで追加する。たったこれだけで、読まれる確率は確実に上がります。
中小企業こそ、議事録で差がつく
私が関わってきた中小企業のプロジェクトでは、議事録の品質がプロジェクトの成否を左右することがよくありました。大企業と違って専任のPMOがいないため、兼任の担当者が片手間で議事録を作っている。結果、情報が共有されず、認識のズレが生じ、手戻りが発生する。
でも、逆に言えば、議事録をきちんと運用すれば中小企業でも大企業並みのプロジェクト管理ができるということです。NotionやGoogle Docsは無料プランでも十分使えます。高額なプロジェクト管理ツールを導入しなくても、議事録の書き方を変えるだけでプロジェクトの透明性は劇的に向上します。
明日からできる小さな一歩
もしあなたが議事録の担当者なら、次回の会議でこれを試してみてください。会議中、決定事項が出たらその場でメモする。アクション項目が決まったら担当者と期日を確認してメモする。会議終了後、この2つだけをまとめてチャットに投稿する。詳細な議事録は後回しでいいです。
これだけで、あなたの議事録は「読まれる議事録」に変わり始めます。完璧を目指す必要はありません。プロジェクトを少しでも前に進める議事録を、まず一本書いてみることが大切です。
私も30年かけて、ようやくこの境地にたどり着きました。あなたはこの記事を読んで、明日から変えることができます。議事録という地味な仕事ですが、プロジェクトの成功を支える縁の下の力持ちです。一緒に、読まれる議事録を作っていきましょう。
コメント