リモートワーク中心、2年で組織が4倍に拡大中のスタートアップのコミュニケーション設計
こんにちは。ヘンリー人事・広報の小山（@helene815）と申します。
ヘンリーは、社会課題の解決を目的に、現在は医療DXと向き合っている会社です。医療は法令規制と業務の複雑性・専門性が高く、ビジネスをする上でも難易度が高い領域の一つだと言えます。
私たちは「難しいからこそやろう！」というモチベーションで、2019年より医療現場のワークフローの中心である電子カルテを開発しています。2021年から販売を開始し、メンバーも社員30名、副業や業務委託の方も入れると80名を超える組織になってきました。
難易度の高い課題と向き合い続けるためには、チームで仕組み化していくことが重要であると捉え、社内コミュニケーションや情報共有についても日々試行錯誤しながら整えていっています。
今回は、リモートワーク中心な中で、ヘンリーが考えるコミュニケーションの設計について書きます。おそらく、多くのスタートアップで似ている悩みをもつ方がいらっしゃるのではないかと想像しています。よかったら、ぜひ情報交換しましょう😄
ヘンリーのコミュニケーション構造
ヘンリーでは、動的コミュニケーションをSlackで行い、情報の蓄積にはNotionを使っています。 Githubなど、チームごとに利用しているツールもありますが、使うツールを分散させすぎないようにし、なるべく欲しい情報が見つかりやすい環境づくりを心がけています。
日頃のコミュニケーションはSlackだけでなく、オンラインミーティングでも行われます。リモートワークが中心の組織の場合、「どういう経緯で決定が下されたのかがわからない」といった、ミーティングで話された内容の共有に課題が生まれやすいのではないでしょうか。
ヘンリーでは、経営情報を含め基本的にすべての議論をオープンにし、情報格差をなるべく無くすことで後からでも情報が追いやすく、メンバーが自ら情報を取りにいきやすい情報設計を心がけています。創業初期から、エンジニアがコミュニケーションガイドラインを作成しており、社内の情報共有・蓄積に対しての意識は一定あったものの、2021年に20名程度だったメンバーが現在80名を超えるまで規模が拡大し、初めはエンジニアとビジネスでざっくり2つの大きなチームだったのが役割ごとにチームが複数でき、「どこでどういった決定がされてそれを組織運営にどう反映するか」というフローが見えづらくなってきました。
そこで、社内情報共有の構造を以下の図のように定義し、運用してみています。詳しく解説していきます。
議事録の集約とフォーマット化
オンライン・オフラインに関わらず、Notionで”議事録”を作成するようにしています。これにより、ミーティングに参加していなかった人に議事録のURLを共有するなど、社内で情報を共有しやすくなります。この時、議事録に決定事項だけでなく背景にある課題感、決定の経緯をきちんと記載するようにし、「なぜそうなったのか」までが伝わるように心がけています。添付のような議事録のベースフォーマットをテンプレートで用意し、誰が書いても一定内容が読み手に伝わるように工夫しています。
ちなみに、経営会議など重要性が高い、あるいはメンバーに広く共有したい全社会などのミーティングは録画し、GoogleドライブやYoutubeでメンバーに共有しています。難易度が高い、あるいは抽象度の高い内容を多く話す場合、テキストだけでの共有に限界があると感じており、抜け落ちてしまいがちな決定の経緯を見返せるようにしています。
週次で各チームの動きを共有
週次で各チームの動きをNotionの”Weekly Report”にまとめています。昨年までは、目標に対する進捗やその週のトピックを主に共有していましたが、メンバーやチームがより目標を意識できるよう、共有の頻度やフォーマットをちょうど整理し直しているところです。組織が拡大すると、全体への適切な情報共有の難しさを痛感します。
ミーティング時間を最小限にしながら情報共有の質を高めたい
各チームの進捗や状況、グッドプラクティスなどは文字だけでなく口頭でも伝え、メンバーの認識合わせをするようにしています。去年までは、月に2回1時間のミーティングを設定していましたが、Weekly Report と同様にチームやメンバーが目標をより意識できる情報共有の仕方を模索しており、今年から毎週15分の事業進捗共有と、月に1回プロダクトや案件の進捗をメインに共有する時間を取る形式に変更してみています。
ちなみに、ヘンリーではミーティングが増えすぎないよう、定期的に開催しているミーティングを一覧にしてオーナーや目的を明記し、”見直しリマインド”を設定しています。「ミーティング時間を極力短くしたい！」という前提のもと、各ミーティングのオーナーを明確にし、基本的に事前に議事録が準備され議題が明らかな状態でミーティングを実施するようにしています。”見直しリマインド”は、定期的にそのミーティングの目的が現状のチームの状態とあっているかを見直すために設定しており、不必要になったミーティングは削除する、あるいはミーティングを再編成することで、情報共有の仕方や効率性を改善する意識付けの役割を担っています。
決定事項は掲示板に蓄積
ミーティングもチャットも、その場はメンバー同士でやりとりをして満足し、せっかく決めたことがチームにきちんと共有されておらず次の動きに反映されていない…みたいなことって意外とよく起きていませんか？あくまでチャットは動的コミュニケーションなので「Slackに書いたじゃん！見てよ」は中長期的に共有が必要な情報を蓄積したことにはならないと捉えています。ヘンリーではNotionで”掲示板”を作成し、チームあるいは全社で共有すべき内容を蓄積するようにしています。
コミュニケーション設計のベースとなる思想
メンバーの数が増えると情報量も増えるので、たとえば「掲示板に載せたから共有が完了した」ではないと思っていて、全社ミーティングの中でも掲示板の更新があった場合は口頭で共有するなど、特に周知したい情報はメンバーとの接点を増やすように心がけています。
たとえば、「名刺の発注ってどうしたらいいの？」など、常時知っている必要はないけれど時々必要になるといった情報に対して、「掲示板のここに載っているよ」とURLを共有できることは説明コストを下げ、指摘されたメンバーも「ここにいけばこういう情報がある」とちょっとずつ認識してくれるようになります。こういったやりとりを個別ではなく、どのチャンネルでどのような情報共有をするのかを明確にした上で、なるべくオープンなチャンネルでやり取りできると他のメンバーの意識づけにもなります。
何が言いたいかというと、「情報を共有したつもりでもメンバーが増えると漏れてしまうケースは一定あるのは仕方がない」という前提でコミュニケーション設計をしていく必要があるということです。全員に同じように情報を共有しているつもりでも、ミーティングに出席できなかった、あるいは通知を見逃してしまうこともあるし、その人のもともとの意識やその日の忙しさや状態で得た情報を取りこぼしてしまうことは多々あります。だって人間だもの！
なのでヘンリーでは「どこにどんな情報があるか」「どんなフローで情報を伝達するか」「決まったことをどこに蓄積するか」をなるべく明確にして社内コミュニケーションを設計し、運用しながらメンバーと一緒に改善していくスタンスをとっています。
おわりに
組織づくりに完成形は存在しません。メンバーが増えたり変わったり、事業のフェーズの変化など、様々な要因でそれまで伝わっていた方法では情報が上手く伝わらなくなることはよくあります。
今回書かせていただいたヘンリーでのコミュニケーション設計の例は、半年後にはまるっきり変わっているかもしれない…変わるのが当たり前という前提で最初から完璧なものをつくるというよりやりながら改善していくことを重視していければと思っています。
ヘンリーのメンバーは「前向きに改善しよう！」というマインドが強く、メンバーを支える側のイメージが強い人事ですが、様々なメンバーと一緒に組織をつくっている感覚で日々試行錯誤することができています。ありがたい！
この記事を読んで「ヘンリーってこういう組織なのかな」とぼんやりとでも輪郭が見えていたら嬉しいです。エンジニアもビジネスも絶賛採用活動を行なっており、まだまだ規模を拡大していくフェーズなので、少しでも興味を持っていただいた方はお気軽に連絡ください😄
最後までお読みいただきありがとうございました！！