議事録がわかりにくいと言われるすべての人へ。議事録のプロが実践する5つのコツ

いきなりですが、この2つの議事録、どちらがわかりやすいでしょうか？

【A】
・田中さんから画面をレビューしていない、進捗報告も受けていないと言われた。
　　個別に報告する場を設けた方がよいか。（中山）
　　　→週次定例に出てもらって、Backlogにも追加する。
【B】
・A部の田中さんから画面をレビューしていない、進捗報告も受けていないと言われた。
　　個別に報告する場を設けた方がよいのではないか。（中山）
　　→週次定例に出てもらえばよいのでは。（A部 有田）
　　　★中山：田中さんに定例への出席を依頼しつつも、Backlogにて正式に画面レビューを依頼する

おそらくほとんどの人が【B】と回答するでしょう。

議事録はビジネスの基本でありながら、実はとても奥が深く、インプット力とアウトプット力が試される場所なのです。

今回は議事録作成の5つのコツを、初級・中級・上級にわけて紹介していきます。

初級：【1】2パターンの議事録を使い分ける

実は、私たちプロジェクトマネージャーが作成する議事録には2つのパターンがあります。一つが、発言録レベルで書く「しっかりパターン」と、もう一つがポイントのみを書く「シンプルパターン」です。

どのように違うかは、サンプルをみて頂くのが早いので、実際の議事録をご紹介します。

【しっかりパターン】
・A部田中さんから画面をレビューしていない、進捗報告も受けていないと言われた。
　　個別にレビュー・報告する場を設けた方がよいのではないか。（中山）
　　　→週次定例に出てもらえばよいのでは。（A部 有田）
　　　★中山：田中さんに定例への出席を依頼しつつも、Backlogにて正式にレビューを依頼する
・サブシステムYについてはまだ正式な見積もり依頼はいただいていない認識（山田）
　　★江原：12/11までにサブシステムYの正式見積もり依頼をN社に出す
・運用場所をどうするかを12月中に決める必要があると認識している（A部 有田）
　　→■運用場所の決定は、開発会社がすべて決まっていない中では決めきれない。
　　　本番環境構築が4月ころを予定しているのでその前までに決めればよい（山田）

しっかりパターンでは、誰が何を発言したのかまできちんとまとめます。

一方、シンプルパターンでは、決定事項やToDo、課題をシンプルにまとめていきます。

【シンプルパターン】
★中山：A部田中さんに定例への出席依頼と、画面Rv依頼をBacklogで出す
★江原：12/11までにサブシステムYの正式見積もり依頼をN社に出す
■来年4月に向けて運用場所を決める必要がある

この2つの使い分けは、クライアント側からの条件やプロジェクトの環境によって決定します。基本的にはシンプルにしたほうが効率的なので、シンプルパターンを作成することが多くなります。

以下のようなケースのみ、しっかりパターンを選びます。
・大企業のプロジェクトで議事録も納品物になる場合
・ステークホルダーが多い場合
・顧客や開発会社のコミット度が弱い場合

ステークホルダーが多い場合、会議に出席したりしなかったりする人が増えるため、出席していない人のためにも細かめな議事メモが必要です。また、ステークホルダーが多い＝縦割りになっていることが多いので、どの部署の誰が発言したかが重要になってくることもあります。

顧客や開発会社のコミット度が弱い場合もしっかりパターンを使用します。コミット度が弱い顧客は、簡単に前言撤回したり、忘れていたりするもの。後々問題にならないように、「こう発言しましたよね？」という証拠として議事録が役立つのです。

初級：【2】ToDoと課題にはマーキングする

先ほどのサンプルにも★が出てきましたが、私はいつも「★はToDo」「■は課題」と、必ずマーキングをしています。これは、一目でToDoとわかりやすくするための工夫です。そうすることで、★マークを追えば議事録内で簡単にToDoを把握でき、■を見れば「今起きている課題」がわかるようになります。

マーキングの無いものと有るものを見比べてみてください。

【マーキング無し】
・サブシステムYについてはまだ正式な見積もり依頼はまだいただいていない認識（山田）
　　江原：12/11までにサブシステムYの正式見積もり依頼をN社に出す予定
・運用場所をどうするかを12月中に決める必要があると認識している（A部 有田）
　　→運用場所の決定は、開発会社がすべて決まっていない中では決めきれない。
　　　本番環境構築が4月ころを予定しているのでその前までに決めればよい（山田）

【マーキング有り】
・サブシステムYについてはまだ正式な見積もり依頼はまだいただいていない認識（山田）
　　★江原：12/11までにサブシステムYの正式見積もり依頼をN社に出す予定
・運用場所をどうするかを12月中に決める必要があると認識している（A部 有田）
　　→■運用場所の決定は、開発会社がすべて決まっていない中では決めきれない。
　　　本番環境構築が4月ころを予定しているのでその前までに決めればよい（山田）

マーキング有りの方は、ToDoと課題が一目でわかりますが、マーキングの無い方は文章を全て読まなくては判断がつきません。議事録には文章がズラリと並ぶので、誰がいつ見ても見やすくわかりやすくしておくことが大事です。

また、発言内容→（発言者）→★ToDoの順に表記することで、どのような経緯でそのToDoが必要になったのかもわかるようになります。経緯がわかれば作業者もすぐに手を動かせるので、作業者に考えさせることなく、プロジェクトを円滑に進めることができるのです。

中級：【3】ToDoと課題を混同しない

実際に議事録を作成していくと、これはToDoとして記すべきなのか、それとも課題として記すべきなのか、迷うことがあります。

迷った場合には、
ToDo：誰がいつ何をやるか明確なもの
課題：紐解きが必要なもの、いつかやるべきこと
この基準で使い分けるようにしましょう。

それでも判断がつかない場合には、ひとまず全てメモを取っておいて、上司に確認するのが一番です。

繰り返しになりますが、「★はToDo」「■は課題」などのマーキングは忘れずに！

中級：【4】発言を、わかりやすく的確な日本語に変換する

話した内容をそのまま議事録に書いていく人がいますが、発言の言葉通りに記してはいけません。なぜなら、話し言葉と書き言葉は違うからです。話し言葉は言葉の倒置が起こりやすく、主語・述語・目的語が明らかになっていないことが多い。それをそのまま文章に起こしてみると、主語・述語・目的語の関係がバラバラになってしまい、間違って伝わってしまうことになりかねません。

議事録は、決定事項やそこに至る経緯を、関わる人全員と共有するためのものですから、間違って伝わってしまうのは絶対に避けたいのです。

そこで、聞いた内容を正しい日本語でわかりやすく記述し直すためにオススメなのが、一度、主語と述語だけにして文章をチェックすること。

文書が長くなってくると、主語と述語が離れてしまい、対応が不明瞭になりやすいです。主語と述語だけにしてみて、対応が正しいかチェックしましょう。

ここに具体例を挙げてみます。

【NG】
見積りはサービス費用の場合は、顧客がシステムからダウンロードし、製品設置費用の場合は代理店が提示する

この文章を主語と述語だけにしてシンプルにすると、「主語：見積り」「述語：提示する」となります。

ですからこの場合は、下記のように記すのが良いでしょう。

【OK】
見積の作成方法は以下の通り。
①サービス費用の見積もりは、顧客がシステムからダウンロードする
（主：顧客 述：ダウンロードする 目的：見積り）
②製品設置費用の見積もりは、代理店が現地調査を行った上で作成する
（主：代理店が 述：作成する 目的：見積り）

上級：【5】行間を読み、発言していない内容も記載する

このポイントは、かなり高度なテクニックですが、プロジェクトマネジメントに関わる人であれば、ここもしっかりスキルとして身につけておくべきでしょう。

プロジェクトを進行していくと、かなり多くの場面で複雑な話がてきます。会議では誰もが論旨をクリアに話してくれるわけではないので、「あれ？今の話は、どっちのことだろう？」となるシーンががよくあります。

そんな時にも、発言者の立場や文脈の前後関係から行間を読み、その状況を的確に把握し、議事録にアウトプットしなければなりません。

それでは事例とともに解説していきます。

【例】
会議中の会話：
「これって連携必要なのかな？」（クライアント 佐藤）
「はじめは連携数も少ないので、システム連携は不要でよいと思います」（開発会社Ａ 鈴木）
　→佐藤さんはほんのり頷き、このまま誰も何も言わず次の議題へ

このような条件があった場合に、多くの人は下記のように議事録に記すのではないでしょうか？

請求システムとの連携は必要か？（佐藤）
当初は連携数も少ないため、請求システムとのシステム自動連携は不要と考える（鈴木）

間違っていないように思えますが、これでは議事録としてNGです。

なぜなら、
・鈴木さんには意思決定権がないからです。

この場合、発言者の立場を考えて議事録を作る必要があります。

以下のような議事録を作成する必要があります。

【OK】
請求システムとの連携は必要か？（佐藤）
当初は連携数も少ないため、請求システムとのシステム自動連携は不要と考える（鈴木）
その認識で問題ない（佐藤）

「不要の認識」を頷きで返した佐藤さんのメッセージをテキストで書く必要があるのです。
このように、はっきりと発言しない人が多い会議の場では、あえて発言していないことも、文脈をとらえを議事録に落とし込む必要があります。

以上、私たちプロジェクトマネージャーが議事録作成の際に気をつけているポイントやコツでしたが、いかがでしょうか？

最後の「行間を読んで記載する」というのは非常に高度なスキルになるので、努力と経験が必要になってきます。逆に言えば、努力と経験で必ずできるようになるので、根気強く取り組んでください。

次回は、議事録作成で必ず抑えるべきポイントについて書きたいと思います。