記事の概要
リモートワーク組織は一人で作業を進めることも多くなり、認識の相違が起こりがちです。そこで生産性を高めるポイントの一つとして、「ノウハウの文字起こしやその活用をいかにうまくやるか」という点があると考えます。今回はその実現を目的とし、転職後配属されたチームでアクションを起こしたことについてまとめます。内容としては「議事録を書く」というシンプルなものですが、狙いや工夫、よかったこと・悪かったことについて共有するので、なんらかの生産性の向上に役立てていただければ幸いです。
背景
2024年9月に今のチームに入った
2024年9月に転職しました。入社後は、データマネジメントグループに配属され、株式会社リクルートのSaas事業領域のプロジェクトに参画し、今はそこで働いています。
当組織はプロダクトに関わるデータ分析環境のデータマネジメントをするグループで、具体的な仕事内容としては次のようなものがあります。
- 分析に必要な事業DBやその他のデータを分析環境に連携する。
- 分析のために必要なデータを抽出したり、SQLをレビューしたりする。
- 分析用のBIダッシュボードを作成したり整備したりする。
- データマートの開発保守や品質保持、メタ情報更新などを行う。
技術要素はいくつかありますが、基本的にはGoogle BigQuery上のデータをSQLを使って処理していることが多いです。
チーム体制・運営
参画したチームの運営状況です。
- 規模：9人（参画当時は7人でした）
- 稼働形態：フルリモート
- タスク管理：JIRA（チケット管理ツール）
朝会が毎日あります。オンラインミーティングでJiraを投影しながら、メンバーが一人ずつ自分の進捗を一人ずつ共有していくという形式です。
チケットは1人あたり10件くらい持っていたりしますし、アクティブに進行しているチケットも3件くらいあったりするので、かなりの報告量や相談量があります。会議は30分に設定されていますが、相談があったりすると1時間以上かかる時もありました。
問題点
参画時点では特に会議のレコーディングや議事録はとられていませんでした。つまり「かなりの報告量や相談量があるのに、それが情報として残らない」という問題点がありました。
議事録を取りはじめた
自分はこの点にかなり問題意識を感じました。というのも、特にリモートワークではカジュアルな確認が取りづらく、認識の相違も生じがちです。そのため、「基本的に何かしらの合意や議論、報告が生じた時には文字にして残しておくべきだ」という考えがありました。
このような背景から議事録（=ログ）を取り始めることにしました。そこからほぼ毎日続けて3ヶ月余りが経ったので、当初に考えていた狙いや良かったこと、悪かったことについてまとめてみたいと思います。
狙い
議事録をはじめた背景については少し触れましたが、詳しい狙いについて以下にまとめます。
①チームの生産性向上のため
②自分自身の成長・貢献のため
①チームの生産性向上
チームへの貢献として、3点の狙いがありました。
- コミュニケーションコストの削減
- 認識相違を減らす
- オンボーディングの促進
・コミュニケーションコストの削減
議事録を残すことで、報告内容を忘れてしまうことや聞き逃してしまうこと、認識の相違を対策し、コミュニケーションコストの削減を狙っていました。（「なるべく忘れないようにする」「なるべく聞き逃さないようにする」というのも大事ではありますが、完全に徹底するのは難しいので、それを補佐する仕組みは重要だと考えています。）
また、議事録を残しておけばあとから検索したり参照したりということもできるようになります。同様の問題に対処する際の迷いを減らすことや、繰り返し同じ質問が出ることを防ぎたいという意図もありました。
・認識相違を減らす
会議内で報告した内容でも、意外とメンバー間での認識のずれは起こります。自分の報告内容や認識をアウトプットすることで再度確認をとり、認識の相違を減らしたいという意図がありました。
・オンボーディングの促進
他のメンバーの業務内容や詰まっているポイント、報告内容、相談の論点をまとめることで、業務理解を深めてオンボーディングをスムーズにできるようにすることを狙っていました。
②自分自身の成長・貢献のため
チームへの貢献だけでなく、自分自身の作業効率や良いフィードバックが得られることを意識して取り組みました。
- 自分の理解やアウトプットの品質を周囲が確認できるような情報提供
- 会議への集中
- 重要なポイントを押さえるトレーニング
- 良い印象を与える
・自分の理解やアウトプットの品質を周囲が確認できるような情報提供
既存メンバーの目線に立ってみると、新しくメンバーが入ってきた中で、どういう仕事を任せたら良いかということを把握することはすぐには難しいものだと思います。このことは効率的に連携できるようになるまでの1つのハードルになると考えました。
そのため新規メンバーである自分が議事録を投稿することで、「自分の理解がどれくらい及んでいるのか」「自分のアウトプットがどういう品質のものなのか」についての情報を伝え、アサインやフォローをしてもらいやすくするという意図がありました。
ちなみに、入社してからWorking Out Loud（WOL）という考え方があることを知り、これは自分が考えていたものに通じる考え方だなと思いました。またこの考え方はすごくリモートワークで生産性を高めるために重要な考え方だなと感じ、不明点や考えていることについてもどんどんSlackなど他の人に見えるところで投稿するようにしていました。
・会議への集中
当組織の朝会に参加してみて、他の人の報告を聞く時間が長くなることがわかりました。また特に最初はチームに入ったばかりでわからない言葉が飛び交うことがあり、手を動かさずに聞いていると集中力が下がるなと感じていました。議事録を書いてそれをオープンな場で共有することを自分にルールづければ、下手に情報を聞き逃せなくなりますし、集中して聞くことができるだろうとも思っていました。
・重要なポイントを押さえるトレーニング
すぐれた議事録を書くためには、省略された背景情報を後から見てもわかるよう適切に補ったり、議論の流れを正確に掴んだり、論点を抽象化して正確に記述したりといったことが求められます。それを達成するためにはドメイン知識やビジネス理解、言語処理能力、論理性など、様々な技術がきっちりと必要になるものだと考えています。
つまり要約がちゃんとできることは重要なポイントを押さえることに直結し、それはビジネススキルとしてもかなり重要なポイントだと思うので向上させたいという気持ちがありました。
・良い印象を与える
前職の上司に「育成コストは奪い合いである」という教えをいただいたこともあり、特に最初は意欲や主体性を少しでもアピールすることが、「この人には色々と教育の手間をかけてもそれに見合う働きをしてもらえそうだな」と思ってもらうために必要だと思っていました。
最初の印象が「そんなに活躍してもらえるイメージがつかないな」「そんなに難しい仕事は任せられなそうだな」など好ましくないものになってしまうと、あまり教育に手をかけてもらえず、余計にオンボーディングがうまくいかなくてチームに貢献できなくなってしまう、という悪循環に入ってしまうことを恐れていました。
ただ少し時間が経ってみて、入ったチームは「ミスしたらすぐに見放されて脱落する」というような苛烈な環境ではないことがわかってきました。そのため、このあたりは少々恐れすぎなところがあったように思います。
具体的な運用
共有場所
会議中にメモを取って、終わったら会議用のTeamsチャットに共有しています。
ボリューム
いくつか直近の議事録の文字数をカウントしてみたのですが、大体1日で2000〜3000字くらいになっているようです。
進捗報告する人数が8名（リーダー除く）のため、平均すると一人あたり250字〜375字くらいでまとめていることになります。
工夫していた点
特に議事録について体系的な原則やルールを勉強したわけではないのですが、今回のケースでは以下のような点を工夫していました。
・聞き逃した点もわかる範囲で書いておく
例えば期日を聞き逃してしまったとしても、「期日は〜日」という情報だけは残しておくようにしました。こうすることで、具体的な値はなくても「会議内で期日について言及された」という情報は残せるようになります。
・担当者を明示する
例えば、報告者が「確認しておきます」みたいに言っていた場合、「〇〇さんが確認する。」と書くなど、担当者情報を補足していました。
・すでに参照できる情報の再記述を減らす
同じ情報が複数の場所に存在する状態を避けていました。これは情報の更新の手間が増えたり認識の相違につながるためと考えたためです。ただし、「議事録だけ読んでざっくり状況が理解できる」という状態を作りたい気持ちもあるので、必要そうな情報は再記述することもありました。
・チケットIDを明示する
チケットのIDを書いておくことで、具体的にタスクの詳細が気になったときにはJiraでタスクを見に行けるようにしていました。
・できるだけ会議の温度感を残す
以前読んだビジネス書に以下の内容が記載されていました。
会議で生み出される「材料」は発言だけではない。
文字に落とすわけではないが、ある発言に対して「対面にいる社長は怪訝な顔をしていた」とか、ある発言に対して「間髪入れずに発言した」など、その場の「空気感」を合わせて伝えないと、議事録を読んだ人に正しく伝わらない場合があります。
この内容を読んでみて「熱量や温度感のようなノンバーバルの部分を伝えられるかどうかは、言葉選びやまとめ方によって左右されるんだな」と感じ、議事録はすごく奥深いものだなとすごく感心しました。なので今回もこういった点は意識していました。
・完璧にこだわらない
ざっくりしたログとはいえあるに越したことはないだろうと考え、聞き逃しが多くあった時も共有するようにしていました。
・時間をかけすぎない
ログの正確性を重視するならレコーディングを取るべきですし、議事録は「ざっくりと知りたい時にパッと概要だけ見ることができるもの」という位置付けで考えていました。そのためクオリティを優先し過ぎないようにして「朝会が終わったら遅くても10分以内くらいで共有する」というスピード感を目標にしていました。
よかったこと
会議で決めた方針を後から見返すことができた
「会議中に方針や進め方を確認したものの、実際に作業を進めることは1週間くらいあとになってしまう」みたいな時には決まったことを忘れてしまいがちなので、議事録を見返すことができて助かりました。
他メンバーのタスク量をざっくり把握することができた
SQLのコードを書く場合などは、他のメンバーからレビューをもらう必要があります。ここで、「他の人がどういうタスクをしていたっけ？」ということが確認できたので、比較的抱えているタスク量が少なめのメンバーにレビュー依頼をすることができました。そのためタスク配分の適正化にもいくらか貢献できたのではないかと感じました。
あとから情報を参照・検索することができた
狙いの通り、という感じの内容にはなりますが、あとから「どういう経緯でこう判断にしたんだっけ？」「前に似たタスクをやった時どういう判断になっていたっけ？」などの情報が欲しい、ということがよくありました。このような場合に議事録を検索することで必要な情報に辿り着けるケースがありました。
思っていたよりも読まれていたり使われていたりすることが分かった
「お休みなど朝会に出られない場合でも、ある程度会議の内容が把握できる」ということで感謝されることがありました。また、朝会に時々聞く専で参加されているマネージャー的なポジションの方がいて、特に自分はお話ししたことがなかった方だったのですが、「参考にしている」と声をかけていただきました。他のメンバーにも有効性を感じてもらえたことはすごく良かったと思います。
あとはメンバーのタスク量を把握するためのデータとして二次的に使われることもありました。議事録の内容が進捗管理の材料として使われるようになるのは予想外のことでした。
間違っている言葉を指摘してもらえた
議事録の中で理解が間違っている箇所や言葉が間違っている箇所について、チームリーダーの方からコメントをいただけることがありました。これは狙いとしていた「自分の理解がどれくらい及んでいるのか」を発信することで、自分に足りていない情報を既存のメンバーに気づいてもらうことができ、結果として自分の理解を進めることができたケースだと感じました。非常にありがたいことであり嬉しいことでもありました。
悪かったこと
やめるタイミングを失ってしまった
配属から少し時間が経ち、状況も変わってきました。具体的には段々とわかることが増えてきたので、話を聞きながら議事録を取るというよりも、タスクの詳細・チケット上のやり取り・行われているテストなど、詳細な情報に目を通すように切り替えていきたい、という気持ちが出てきました。
ただ、いかんせん自主的にはじめて、多少なりとも他の人に使われていることもわかってきたので、いきなりやめてしまうことも、誰かに引き継ぐこともしづらいなという気持ちがあります。交代制で議事録を取る、というような運用にすると他の人の仕事を増やしてしまうことにもなるので、それもどうなんだろうという思いがあります。
自分が思っているよりも確かな情報として受け取られがちだった
人手の議事録で会議の全ての情報を残すことはできないため、情報のカットも生じますし、どうしても一定量ミスも含まれてしまいます。そのため議事録については「100％正確だとは考えないで、70%-80%くらい正しいものだと思ってください」と伝えるようにしていました。ただ、あまりこのあたりは浸透していなさそうだと感じています。つまり、「本来の議事録の正確性」と「それを受け取るメンバーが思っている正確性」にギャップがありそうだなと考えています。
個人的には、議事録は「間違いも含まれている可能性のあるログ」ぐらいに受け取ってもらって、誤りや細かい点の欠如があり得る前提で対応を判断する材料として使ってもらえれば、と思ってはいるのですが、なかなかそういう認識を持ってもらうことも難しいのかもな...。と思っています。
チャットを遡りづらくなった
毎日長い文章がTeamsのチャットに投稿されるので、チャットを遡りづらくなったと感じることがあります。もしかしたら別で議事録専用にドキュメントファイルを設けて、そこに書き溜めていく、といった運用の方がより適切だったかもしれません。
しっかりルールを決めて始めたわけではないので、運用上の改善の余地はいくつかあるだろうと思います。
まとめ
そんなに深く考えず始めたところもありましたが、概ね良い試みだったと評価できるのではないかなと思います。
議事録を書くことは原始的で小さな取り組みですが、品質や使い方次第で思っている以上に軽視できない重要なデータや資産になり得るなと思っています。今後は引き続き自分の方で気づいた部分をデータとして残していくだけでなく、「ログを残すといいよね」という雰囲気の醸成に意識を置いてできることを考えていき、組織的にノウハウの文字起こしやその活用を推進していければ良いなと思っています。