会議の議事録をタスク化する手順｜決まったことを流さない
議事録はきちんと残っているのに、そこに書かれた決定事項が誰の手にも渡らないまま次の会議を迎える。会議の議事録をタスク化したいと考える人の多くは、この状態に困っています。原因は書く人の熱意でも、文章力でもありません。議事録という形式が、そもそもタスクを運ぶようにできていないという構造の問題です。この記事では、会議中に宿題を確定させてしまう進め方、担当と期限をその場で決める具体的な手順、そして議事録の置き場とタスクの置き場を分けるという考え方を、とりまとめる人が次の会議から実行できる粒度で整理します。
決まったことが翌週には誰の手にも渡っていない
会議は成立している。議論も噛み合っている。議事録も当日中に共有されている。それでも一週間後に「あれ、どうなりました」と聞くと、誰も動いていない。この現象は、進行を預かる立場ならほとんどの人が経験しています。
議事録は経緯の記録であって、指示書ではない
議事録の役割は、その場で何が話され、何が決まったかを後から辿れるようにすることです。目的は再現性であって、実行の駆動ではありません。だから議事録は時系列に沿って書かれます。「Aについて議論した」「Bという意見が出た」「Cで進めることになった」という順番です。
この並び方は記録としては正しく、後から経緯を確認したい人には最適です。ところが実行する側から見ると、必要な情報がばらばらに散っています。自分がやるべきことは3ページ目の中ほどに一行だけ書かれていて、その期限は5ページ目の別の段落に紛れている。読み手は文書全体を読んで、自分に関係する部分を自分で拾い上げる必要があります。
この「拾い上げる」という作業を、忙しい実行者に無償で押し付けているのが、タスク化されていない議事録の正体です。読み手が10人いれば、同じ拾い上げ作業が10回発生します。そして半分の人はやりません。悪意があるわけではなく、目の前の仕事が先にあるからです。
書き終わるころには会議の熱が冷めている
もうひとつの構造的な問題は時間差です。議事録は会議が終わってから書かれます。清書して、事実関係を確認して、共有するまでに半日から一日かかることは珍しくありません。
会議の直後、参加者の頭の中には「自分は何をすればいいか」がまだ残っています。この記憶が最も鮮明なのは、会議が終わって30分以内です。ところが議事録が届くのは、その熱が引いた後です。届いたときには他の会議や別の依頼が上に積み重なっていて、開かれないまま既読になります。
現場でしばしば聞くのは、「議事録を丁寧に書くほど読まれなくなった」という話です。丁寧に書くほど分量が増え、分量が増えるほど後回しにされる。書き手の努力が、読まれない理由を増やしてしまうという逆転が起きています。
会議そのものが労働時間として積み上がっている
会議の時間は、参加者全員の労働時間です。8人が参加する60分の会議は、組織としては8時間ぶんの工数を消費しています。決まったことが実行されなければ、この8時間はまるごと失われます。
労働時間とは、使用者の指揮命令下に置かれている時間のことをいい、使用者の明示又は黙示の指示により労働者が業務に従事する時間は労働時間に当たること。 出典: mhlw.go.jp
会議を減らそうという議論は、この工数の重さから出てきます。ただし、会議の数を減らしても、決まったことが流れる構造が残っていれば、残った会議の成果も同じように流れます。減らすより先に、決まったことを確実に手渡す仕組みを作るほうが、費用対効果は高くなります。
さらに言えば、実行されなかった決定は次の会議で再び議題に上がります。同じ話を二度するために、また8時間が消えます。議事録がタスクにならないことの本当のコストは、書く手間ではなく、この再議論の時間です。
会議中に宿題を確定させる進め方
議事録を後からタスクに変換しようとすると、必ず変換する人の手間が発生します。そして手間の発生する工程は、忙しくなると真っ先に飛ばされます。続く仕組みにするには、会議が終わった時点で宿題が確定している状態を作るしかありません。
議題ではなく「今日決めること」を先に並べる
多くの会議のアジェンダは、議題の名前だけが並んでいます。「新機能のスケジュールについて」「協力会社の選定について」といった形です。この書き方だと、話し終わったときに何が決まったのかが曖昧になります。話題としては扱ったが、決定には至っていない状態でも、扱った以上は進んだ気がしてしまいます。
そこで、アジェンダの書き方を「決めること」に変えます。「新機能を何月何日にリリースするかを決める」「協力会社を2社に絞る」という形です。動詞で終わらせるのがコツです。こう書いておくと、会議の途中で「まだ決まっていない」ことが誰の目にも明らかになります。
あわせて、決めることの横に「決まらなかった場合にどうするか」を一行だけ書いておくと、議論が長引いたときの逃げ道になります。「決まらなければ来週火曜に再度15分で判断する」と書いてあれば、無理に結論を出す必要がなくなり、逆に議論の質が上がります。
準備の負担は小さくありませんが、この作業はとりまとめる人が会議前に10分取れば終わります。会議中に全員が費やす時間と比べれば、明らかに割の良い投資です。
話が動いた瞬間に「これは宿題」と声に出す
会議の中で、宿題は予告なく発生します。「じゃあその数字、あとで確認しておきますね」という何気ない一言が宿題です。この瞬間を捕まえられるかどうかで、後の作業量が変わります。
やることは単純で、進行役がその場で「いまのは宿題ですね」と口に出すだけです。声に出すと、発言した本人が自分の宣言を認識します。認識されない宿題は、宿題として扱われません。「あとで確認しておきます」は、本人の中では独り言に近い温度で発せられていることがあります。
宣言と同時に、その場で記録に落とします。誰かがメモを取るのではなく、参加者全員が見ている画面に書き込むのが理想です。画面に出ている情報は、その場で訂正されます。「それ、確認するのは私じゃなくて営業側です」という修正が、会議中に入ります。後から議事録で回すと、この修正は入らないか、入っても数日後です。
ここで重要なのは、文章として整えないことです。「売上の数字、確認」で十分です。整った日本語にしようとした瞬間に手が止まり、会議の進行が遅れます。整えるのは後でよく、その場では取りこぼさないことだけを優先します。
最後の5分を宿題の読み上げにあてる
会議の終わり際に、確定した宿題を上から読み上げる時間を取ります。5分あれば足ります。この5分は、会議の中で最も費用対効果の高い時間になります。
読み上げるときは、「何を」「誰が」「いつまでに」の3点をセットで言います。「売上の数字の確認、営業の担当者、来週水曜まで」という具合です。ここで初めて気づく食い違いが必ず出ます。「その数字、水曜だと締めの前なので木曜以降になります」という調整が入ります。
この調整を会議中にやるか、後日メッセージで往復するかで、確定までの日数が変わります。往復にすると、返信を待つあいだに他の作業が積み上がり、初動が数日遅れます。読み上げは、その遅れを丸ごと消す作業です。
読み上げの時間が取れない会議は、そもそも議題を詰め込みすぎています。終了時刻の5分前にアラームを鳴らす運用にすると、議論を切り上げる基準ができます。切り上げられなかった議題は、決まらなかったこととして扱えば済みます。
決まらなかったことも、決まらなかったと残す
会議では、結論が出ない議題が必ず出ます。このとき、何も書かずに次の議題へ進んでしまうと、その議題は消えます。次の会議のアジェンダにも載らず、数週間後に問題として再浮上します。
決まらなかった議題には、「決まらなかった」という状態と、「次にいつ決めるか」を残します。さらに、決めるために足りなかった材料を書いておくと、次回の会議が一度で終わります。「見積もりが2社ぶんしか揃っていないため決定を保留、3社目の見積もりを来週金曜までに取得したうえで再度判断」という形です。
保留も宿題です。担当と期限を付けます。保留に担当が付いていない議題は、次の会議でも同じ理由で保留になります。現場では、保留が3回続いた議題は、そもそも決める必要がなかったか、決められる人が会議に出ていないかのどちらかだと言われています。どちらであっても、判断する材料になります。
担当と期限をその場で決める
宿題を書き出しただけでは動きません。書かれた宿題のうち、実際に動くのは担当と期限が入っているものだけです。ここを会議中に確定させられるかどうかが、議事録をタスク化する取り組みが定着するかどうかの分かれ目になります。
担当は部署名ではなく個人名で置く
「営業チームで確認」「開発側で対応」という書き方は、会議中は角が立たず、その場を収めるには便利です。ところが実行の段階では、ほぼ機能しません。チーム名で書かれた宿題は、チームの誰もが「自分ではない」と解釈できるからです。
担当は個人名で置きます。その場に本人がいない場合でも、「営業の誰に振るかを、営業の同席者が明日までに決める」という形で、個人名の付いた宿題に変換します。誰に振るかを決めることそのものを宿題にすれば、宙に浮きません。
複数人での作業になる宿題も、代表者を1人決めます。共同責任は無責任と同じ結果になります。代表者は作業を全部やる人ではなく、期限までに状態を報告する人だと定義しておくと、引き受けやすくなります。
とりまとめる立場の人が気をつけたいのは、担当が決まらないときに自分の名前を入れてしまうことです。その場は収まりますが、とりまとめ役の抱える宿題だけが増え続け、やがて全体が止まります。決まらないなら「担当を決める」という宿題にして、決める人を指名するほうが健全です。
期限は「今週中」ではなく日付で置く
「今週中」「なるはや」「落ち着いたら」という期限は、期限として機能しません。人によって解釈が違い、遅れているかどうかを誰も判定できないからです。判定できない約束は、守られたかどうかも分かりません。
期限は日付で置きます。「9月12日まで」と書けば、13日になった時点で遅れが確定します。この確定が重要です。遅れが見えるようになって初めて、手当ができます。
日付を決めるときは、担当者本人に言わせます。進行役が「金曜までにお願いします」と決めると、無理な日程でも断りにくくなり、結果として遅れます。「いつまでにできそうですか」と聞いて、本人が言った日を書く。本人が言った日付は守られる確率が明確に上がります。
期限が先すぎる宿題も要注意です。1か月先の期限が付いた宿題は、最初の3週間は誰も手を付けません。1か月かかる作業なら、途中に確認の日付をもうひとつ置きます。「9月12日までに叩き台、9月26日までに確定」という二段構えにすると、遅れが早く見つかります。
「持ち帰って検討します」を宿題の形に変える
会議でよく出るのが「持ち帰って検討します」という発言です。これは丁寧な表現ですが、そのまま記録すると何も残りません。検討には終わりの定義がなく、いつ終わったのかを誰も判定できないからです。
この発言が出たら、その場で3つを確認します。何を検討するのか、誰に相談するのか、いつ結論を持って戻るのか。「部長に確認して、来週火曜の定例で回答する」まで固まれば、それは宿題として成立します。
固まらない場合は、「いつ回答日を決められるか」を聞きます。相談相手の予定が読めないケースが多いので、「明日中に相談日を押さえて共有する」という一段手前の宿題にします。一段手前でも、日付が入っていれば追いかけられます。
持ち帰りが多い会議は、決裁できる人が出席していないという構造的な問題を抱えています。回数を数えておくと、会議の設計そのものを見直す材料になります。持ち帰りが議題の半分を超えるようなら、出席者の顔ぶれを変えるほうが早く効きます。
担当が決められないときの扱いを先に決めておく
その場で担当が決まらない宿題は必ず出ます。担当候補が忙しすぎる、そもそも誰の仕事か判断がつかない、部署をまたぐので調整が要る、といった理由です。
このとき、宿題を宙に浮かせないためのルールを先に決めておきます。よく使われるのは、「担当未定の宿題は、いったん進行役が仮の担当者になり、期限は3営業日後にする」という決め方です。仮の担当者がやるのは作業ではなく、担当を確定させることだけです。期限が短いのは、担当を決めるだけなら短くて済むからです。
このルールがないと、担当未定の宿題は一覧の下のほうに溜まっていきます。溜まった宿題は誰も見なくなり、一覧そのものの信頼が落ちます。一覧に嘘が混ざり始めると、チームは一覧を見ずに個別に確認を取るようになり、元の状態に戻ります。
議事録の置き場とタスクの置き場を分ける
会議の議事録をタスク化するとき、多くのチームがつまずくのが「どこに書くか」です。議事録の中にタスクの一覧を作る方式は、始めるのは簡単ですが、運用を続けると必ず破綻します。理由は、この2つが持っている性質がまったく違うからです。
議事録は増える一方、タスクは減っていくもの
議事録は、書いた時点で内容が確定します。あとから中身を書き換えることはなく、月に4回会議をすれば、4本の議事録が積み上がります。1年で48本になり、過去のものは検索して取り出す対象になります。
タスクは逆です。書いた時点では未完了で、そこから状態が変わっていきます。着手して、確認待ちになって、完了して、一覧から消えます。関心があるのは常に「いま残っているもの」で、完了したタスクは見返す必要がほとんどありません。
積み上がるものと減っていくものを同じ場所に置くと、どちらの見え方も悪くなります。議事録の中にタスク一覧を作った場合、先月の議事録に書かれたタスクの状態を更新するために、先月の文書を開き直すことになります。この操作を続けられるチームは、ほとんどありません。現場では、2回目か3回目の会議で更新が止まると言われています。
更新の頻度と、読む人がまったく違う
議事録を読むのは、その会議に出ていなかった人か、後から経緯を確認したい人です。読む頻度は低く、読むときには全文を通して読みます。更新はされません。
タスクの一覧を読むのは、実行する本人と、進行を追いかけている人です。読む頻度は毎日で、読むときは自分に関係する行だけを見ます。更新は頻繁で、1日に何度も状態が変わります。
読む人も、読む頻度も、読み方も違うものを1か所にまとめると、両方に不便が出ます。毎日見る側は、関係のない議事の記録をスクロールで飛ばすことになります。経緯を確認したい側は、更新され続ける一覧のせいで当時の状態が分からなくなります。
分けるというのは、単に置き場所を2つにするという意味ではありません。それぞれを、それぞれの読み方に合った形で持つということです。議事録は文書として、タスクは状態を持った一覧として持つ。この形が違うからこそ、分ける必要があります。
二か所に書くのではなく、片方から片方を指す
分けると聞くと、同じことを2回書く手間が増えると受け取られがちです。実際には、二重に書く必要はありません。片方からもう片方を指せば済みます。
具体的には、議事録には決定事項と議論の流れだけを書き、宿題については「別途タスクとして登録」とだけ書いてリンクを置きます。タスクの側には作業の内容と担当と期限を書き、背景が必要なら議事録へのリンクを1本張ります。相互に指し合う形にすると、どちらを起点にしても必要な情報にたどり着けます。
このやり方が成立するには、タスクの側に安定したリンク先があることが前提になります。板の上にカードとして置く方式のタスク管理では、カード1枚ごとにURLが割り当てられるものが多く、議事録から名指しで指せます。どの形式で持つと運用しやすいかは、できることで機能の並びを確認しながら、いま使っている道具と比べるのが早道です。
なお、リンクを張る作業も会議中にやってしまうのが理想です。会議後に回すと、この作業がとりまとめ役に集中し、負荷が偏ります。負荷が1人に偏る運用は、その人が休んだ週に止まります。
チャットは話す場所であって、残す場所ではない
会議の後、決定事項をチャットに流して終わりにしているチームは多くあります。速いので、その場では機能します。ただしチャットは時系列にしか並ばず、書き込んだ内容は翌日には過去になります。
3週間後が期限の宿題を、3分で流れる列に置くと、期限が来る頃には誰も覚えていません。チャットに流すこと自体は悪くありませんが、流したうえで、状態を持てる場所にも置く必要があります。流すのは「知らせる」ため、置くのは「追いかける」ためで、目的が違います。
チャットの検索に頼る運用も、規模が大きくなると限界が来ます。検索でヒットするのは発言であって、その発言の内容がその後どうなったかは分かりません。「対応します」という発言は見つかっても、対応が終わったかどうかは別に確認するしかありません。
判断の基準は単純です。後から状態を知りたくなるものは、状態を持てる場所に置く。その場で役目を終えるものは、チャットのままでよい。会議で出る発言のうち、状態を持たせる必要があるのは全体の1割程度です。
道具を見直すときに確かめる3つのこと
議事録のタスク化がうまくいかないとき、原因が運用ではなく道具の側にあることもあります。とりまとめる立場で道具を見直すなら、確かめる点は多くありません。
会議中に、その場で入力しきれるか
最も重要なのはここです。会議が終わってから入力する運用は、必ず途中で止まります。会議中の数秒で1件を登録できるかどうかを、実際に手を動かして確かめます。
確認するのは、宿題を1件登録するのに何回クリックが必要かです。タイトルを書いて、担当を選んで、期限を入れて、保存する。この一連が4回以内のクリックで終わるなら、会議中に運用できます。必須項目が多く、優先度や分類や見積もり工数を毎回埋めさせられる設計だと、会議の進行が止まります。
項目が多い道具が悪いわけではありません。後から埋められる設計になっているかどうかが分かれ目です。最初は「何を」「誰が」「いつまでに」の3つだけで登録でき、必要な人が後から詳細を足せる形が、会議での運用には向いています。
見る側が探さずに済むか
登録された宿題を、実行する人が自分で探しに行く必要がある形だと、実行率は上がりません。ログインして、プロジェクトを選んで、絞り込みの条件を設定して、ようやく自分の担当分が見える。この手数がかかる道具は、忙しい人ほど開かなくなります。
理想は、板を開いた瞬間に全体が見えることです。誰が何を持っていて、どこで詰まっているかが、一画面で分かる形です。板の形で並べる方式は、この一覧性のために選ばれています。列を状態にして、カードを縦に並べれば、確認待ちの列が長くなっていることが目で分かります。
一覧性の考え方は道具ごとに違い、文書の中に埋め込む方式もあれば、独立した板として持つ方式もあります。どちらが向いているかはチームの規模で変わるので、Notionとの比較のように、文書中心の道具と板中心の道具を並べて見ると、自分たちの使い方がどちら寄りかを判断しやすくなります。
使わなくなったときに、中身を持ち出せるか
道具を選ぶときに見落とされがちなのが、やめるときの話です。数年ぶんの議事録とタスクが溜まった後で、外に出せない形式でしか保存されていないと、乗り換えの判断そのものができなくなります。
確認するのは、書き出しの形式と、書き出せる範囲です。カードの本文だけでなく、担当や期限やコメントまで含めて出せるか。CSVやJSONといった扱いやすい形式で出せるか。この2つが満たされていれば、将来の選択肢が残ります。
逆に、取り込みの手軽さも判断材料になります。いま使っている道具から移すとき、手作業で1件ずつ入れ直すのか、まとめて取り込めるのかで、移行にかかる日数が変わります。取り込みの対応範囲についてはTrelloからの移行で、どこまでが自動で運ばれてどこからが手作業になるかが整理されています。自動で取り込めるのは限られた道具だけで、それ以外は書き出したファイルを使った移行になります。ここは正直に確認しておいたほうが、あとで慌てずに済みます。
板と文書、どちらで持つかで運用が変わる
議事録とタスクを分けると決めた後、次に決めるのは「タスクをどの形で持つか」です。ここは道具の思想がはっきり分かれるところで、比較の観点として整理しておく価値があります。
文書の中で持つ方式と、板として独立させる方式
文書の中にタスクを持つ方式は、議事録との距離が近いのが利点です。会議の記録を書きながら、その流れで宿題の行を作れます。文脈が同じ画面にあるので、後から読んだ人が背景を理解しやすくなります。
一方で、状態の更新には向きません。先に書いたとおり、文書は増える一方のもので、過去の文書を開き直して状態を変える運用は続きません。文書中心の道具でこれを解決するには、タスクだけを集めた別のデータベースを作り、各議事録から参照する形にします。設計の自由度は高いのですが、設計そのものを誰かが担う必要があり、その人が抜けると保守が止まります。
板として独立させる方式は、状態の更新に強い形です。カードを列から列へ動かすだけで状態が変わるので、更新の手数が少なく済みます。反面、議事録との距離は遠くなるので、リンクで結ぶ運用が前提になります。どちらが優れているという話ではなく、チームが更新を続けられるほうを選ぶという判断になります。板型の代表的な道具との違いはTrelloとの比較で整理されていて、板の考え方そのものを理解する材料になります。
誰がどこまで見えるかを先に決めておく
議事録には、社外に出せない内容が含まれることがあります。人事の話、金額の話、取引先の名前などです。タスクの一覧は関係者全員が見る前提で作るので、議事録と同じ権限で扱うと事故が起きます。
分けて持つことは、この点でも有利に働きます。議事録は限られた人だけが読める場所に置き、そこから切り出したタスクだけを全員が見る板に置く。切り出す段階で、外に出せない情報を落とせます。
外部の協力者を招くチームでは、この設計がさらに重要になります。協力者に見せる板と、社内だけの板を分ける運用が現実的です。権限の考え方や、どこまでを分離できるかは道具によって差があるので、安全性の考え方のような方針のページを先に読んで、自分たちの必要条件と突き合わせておくと判断が早くなります。
大規模な組織向けの道具は権限設定が細かく作られている一方、設定そのものに手間がかかります。細かさが要るのか、単純さが要るのかは、チームの人数で変わります。数十人までの規模なら、権限は板の単位で分けられれば足りることがほとんどです。Asanaとの比較やmonday.comとの比較では、こうした管理の細かさの違いにも触れています。
費用の見方と、続けられる形かどうか
道具の費用は、機能の数ではなく人数で決まる設計と、機能の段階で決まる設計に大きく分かれます。機能の段階で決まる設計だと、「この機能を使いたいのでプランを上げてほしい」という社内の交渉が発生します。交渉には時間がかかり、その間は運用が止まります。
機能で絞らず、区切るのは人数とボードの数だけという設計を採る場合、この交渉が発生しません。使い始めてから止まる場所が少ないぶん、定着しやすくなります。ただし人数が増えれば費用は素直に伸びるので、外部の協力者を多く招く運用では、招く人数の見込みを先に立てておくほうが安全です。数え方は道具ごとに違うので、料金で区切りの考え方を確認したうえで、自分たちの人数を当てはめて計算します。
国内の開発現場で使われている道具や、シンプルさを重視した道具にもそれぞれ設計の思想があり、比べると自分たちが何を優先しているかが見えてきます。Backlogとの比較やJootoとの比較は、その材料として使えます。複数の候補をまとめて見たい場合は比較の一覧から並べて確認するのが早く、判断に迷いやすい点についてはよくある質問に整理があります。
結局、続くかどうかを決めるのは手数
道具を入れ替えても、会議の議事録がタスク化されるとは限りません。決めるのは、会議中に宿題を確定させる進め方をチームが受け入れるかどうかと、更新の手数が十分に少ないかどうかの2点です。
とりまとめる立場の人ができるのは、この手数を実際に数えてみることです。宿題を1件登録するのに何回クリックしたか、状態をひとつ進めるのに何秒かかったか。数えれば、続く運用かどうかは会議を2回やる前に分かります。
そして、最初から完璧な運用を作ろうとしないことです。項目は「何を」「誰が」「いつまでに」の3つで始め、状態は着手前と進行中と完了の3段階で足ります。空欄の多い一覧は誰も信用しません。埋まる項目だけを置いて、埋まるようになってから増やす。議事録から宿題を取り出す作業は、この順番でしか定着しません。
Q1. 議事録を書きながら同時にタスクも登録するのは負担が大きくないですか？
同時に書くのではなく、宿題が出た瞬間だけ登録します。1件あたり数秒で済むように、最初は何をやるか、誰がやるか、いつまでか、の3つだけ入れてください。文章として整える必要はなく、後から本人が直せます。会議後にまとめて変換する運用のほうが、結果的に手間も遅れも大きくなります。
Q2. 担当がその場で決まらない宿題は、どう扱えばよいですか？
宙に浮かせないために、進行役が仮の担当になり、期限を3営業日後にする決め方が使えます。仮の担当がやるのは作業ではなく、本来の担当を確定させることだけです。担当未定のまま一覧に残すと下のほうに溜まり、一覧そのものの信頼が落ちます。決めることを宿題にすれば追いかけられます。
Q3. 議事録とタスクを分けると、背景が分からなくなりませんか？
二か所に同じ内容を書くのではなく、リンクで指し合う形にすれば解決します。議事録には決定と経緯だけを書き、タスク側には作業内容と担当と期限を書いて、背景が必要なときだけ議事録へのリンクをたどらせます。リンクを張る作業も会議中に済ませておくと、とりまとめ役に負荷が偏りません。
Q4. チャットに決定事項を流すだけでは不十分ですか？
知らせる用途としては有効ですが、追いかける用途には向きません。チャットは時系列にしか並ばず、状態を持てないため、対応が終わったかどうかを後から確認できません。流したうえで、状態を持てる場所にも置いてください。会議で出る発言のうち、状態を持たせる必要があるのは1割程度です。