株式会社はてなのマンガ投稿チームでエンジニアリングマネージャーとして働いている 
id:shimobayashi です。
普段はジャンプルーキー！やマンガノといったマンガを投稿するサービスの開発に携わっています。
先日社内でリモートワークに関する読書会を完走し、最後には監修者の方々と質問会を開催させていただきました。 本記事では、それらの過程で分かったことなどを共有します。
読書会をどのように実施したのか
今回の読書会ではこの本を選びました。
選んだ理由としては、様々な参加者がリモートワークについて学ぶことで、はてなの働き方をより良いものにしたい、技術以外のスキルがあることも知っているエンジニアを増やしたい、という意図でした。
予定の調整については、部署・職種横断で最大参加者21名で開催したこともあり、その中でなるべく多くの人が参加できそうな時間を都度抑える形で行いました。
読書会のやり方については発表会方式やABDなど様々な選択肢がありましたが、読書会の意図や同期的に使える時間などを勘案して、今回はジグソー法をベースに1回1時間で全9回を開催しました。
読書会の進行例
試行錯誤については後述しますが、ジグソー法をアレンジをして基本的には以下のように進行しました。
- 事前準備
- 主催者が事前にグループウェアにて会場を、準備しておいたテンプレートから作成
- このとき、各グループの担当範囲も決定(基本的に3グループに分けて運用)
- 主催者がカレンダーにてなるべく多くの人が参加できそうな時間を抑える
- 参加者が読書会までに担当範囲を読んでくる
- 主催者が事前にグループウェアにて会場を、準備しておいたテンプレートから作成
- 読書会当日
- 参加者が各グループごとに別々のビデオ会議に参加し、20分でグループウェア上に要約を作成
- 全員がひとつのビデオ会議に集まり、グループごとに代表者から6分で要約を共有
- ランダムにブレイクアウトルームに分かれ20分の議論。議事録はグループウェア上に作成
- そのまま流れ解散
開催中に試行錯誤したこと
当初この読書会の呼称はストレートに「GitLabに学ぶ 世界最先端のリモート組織のつくりかた 読書会」としていたのですが、長すぎて呼びにくかったり、情報をまとめているページをブラウザでタブを開いているときにタイトルが見切れてしまうという問題がありました。 そのため、早い段階から「Gリモ会」という略称を正式な呼称としました。 各所のリネーム作業に手間がかかったので、最初から短い呼称にしておけば良かったと反省しています。
各グループの担当範囲の長さについても何回かやってみて適正な長さがだんだんと分かってきました。 担当範囲が短すぎると要約作成の時間が余ってしまう、長すぎると要約作成が間に合わなくなってしまう、という問題がありました。 ただ、時間が余る分にはその間にグループ内での議論などに充ててもらうこともできるため、慣れないうちは短めにしておくことをおすすめします。
また、部署・職種横断であるがゆえにどうしても参加者が安定せず、場合によっては各グループでの要約の共有に必要な参加者が揃わないこともありました。 対策として、要約の共有までは全員が同じ場に集まって各グループの代表者が行い、その後の議論は都度ランダムに分けたグループで行うように進め方を変更しました。
グループウェアに要約や議論の議事録をまとめるようにしていたので、参加できなくてもあとから追いつきやすくなっていたのも良かったと思います。
各参加者の喋る機会が減ってしまう、議論に必ずしも全パートの参加者が揃わないなどのデメリットもありましたが、総合的には調整コストを減らして継続的な開催がしやすくなったメリットの方が大きかったと感じています。
完走して感じたこと
当初の意図である「様々な参加者がリモートワークについて学ぶことで、はてなの働き方をより良いものにしたい」という点については、当初の目論見通りGitLab社とはてなのリモートワークの差分を知ることができました。 自分が直接本を読んでいない箇所についても、サマリの発表を通じてある程度把握できた感覚があります。 読書会各回での議論も活発に行われ、本中に登場するチェックリストなどは分かりやすい指標になりました。
GitLab社の評価システムや仕事の考え方についても書かれており、特にDisagree and Commitの考え方などは読書会の中に限らず社内での議論も盛り上がりました。 総じて、リモートワークに限らず働き方全般について考え直す良いきっかけになったと考えています。
また、「技術以外のスキルがあることも知っているエンジニアを増やしたい」という点に関しては、元々そういったスキルに関心を持ったエンジニアの参加に留まった面もあるかと思いますが、各々の見識をより広げることができました。
本の内容が若干トップマネジメント寄りの印象があったため、開催する前は参加者がどれだけ集まるか不安でしたが、蓋を開けてみればエンジニアに限らず部署・職種横断で、役員や社長まで含めて様々な参加者に集まってもらえたのもうれしい誤算でした。
普段は直接話す機会の少ない参加者とも議論することで、同じはてな社内でもお互いの状況の違いを知ったり、共通言語を醸成する良い機会になりました。
一方で、主催した自分に毎回準備する負担は継続的に発生していました。途中で準備の交代を申し出てくれる参加者もいて大変助かりましたが、今回のようなやり方であればある程度方針が固まった時点で複数人での実行委員会を組むなどすれば良かったと反省しています。
監修者との質問会はどのような内容になったのか
GitLab社に勤められており本の監修もされた伊藤俊廷様と佐々木直晴様のご厚意により、読書会参加者との質問会も開催させていただきました。
とあるイベントにて弊社の 
id:onk から「社内で読書会をやるんですよ」という雑談がきっかけで機会をいただくことができました。
質問会では、まずこの資料を用いてポイントを紹介いただいたうえで、一問一答を繰り返していくという進行をしました。
ざっくばらんに質問させていただき、GitLab社での実際をお聞きできたり、理解が曖昧だったり間違っていた部分を訂正いただくなど、貴重な機会となりました。
一問一答の一部
以下に、一問一答の一部を抜粋して紹介します。
- Q: Disagree and Commitの考え方は、実際どれくらい使われていますか？
- A: 実際にこの方針を運用できている
- 同意しないことに対しても建設的に意見を言うことが重要で、立場などは関係ない
- ただし、言えるメンバーと言えないメンバーはいる。特にビデオ会議ではミュート解除でワンテンポ遅れるなどが起こりやすい。言えるような意識付けをファシリテーターやリーダーを中心に行っている
- 発言に対して否定から入らないなど、発言したことを後悔しないような進行をすることも大事
- A: 実際にこの方針を運用できている
- Q: 良質なリアルタイムフィードバックを行うために気をつけていることなどあれば教えて下さい
- A: メンバーの貢献をチャットツールなどで共有する「公開称賛」を、マネージャーを中心に意識的に行っている。これを行うためには観察が必要で、観察が良質なフィードバックにつながっている
- 1on1などでフィードバックの場を多く持つというのも重要
- A: メンバーの貢献をチャットツールなどで共有する「公開称賛」を、マネージャーを中心に意識的に行っている。これを行うためには観察が必要で、観察が良質なフィードバックにつながっている
- Q: チーム外のメンバーともインフォーマルなコミュニケーションを活発にするためにしている工夫などあれば教えて下さい
- A: Coffee Chatという仕組みがある。英語の練習も兼ねて活用しており、Donut for Slackというアプリがあって勝手に相手を決めてくれるので、ランダムに選ばれたチーム外の人との会話が中心になっている。また、チャットツール上の雑談チャンネルなども有効
- オフラインの場に集まるときは名札に名前とロール名を書いておくとすぐに誰か分かって話しやすい
- A: Coffee Chatという仕組みがある。英語の練習も兼ねて活用しており、Donut for Slackというアプリがあって勝手に相手を決めてくれるので、ランダムに選ばれたチーム外の人との会話が中心になっている。また、チャットツール上の雑談チャンネルなども有効
- Q: すべての同期的な会議にはアジェンダが必要ということですが、アジェンダの準備にはどれくらいのコストをかけていますか？また、会議の冒頭が資料の読み上げになってしまうことに回避策などはありますか？
- A: 議題を1分くらいで箇条書きすれば十分にアジェンダとして使える。アジェンダが用意されていない会議には「アジェンダは何でしょうか」と返信し、その後に用意されたら初めて「参加」にすることは意識して行うことがある
- 資料の読み上げになることについては、読み上げになっても問題は感じていない
- A: 議題を1分くらいで箇条書きすれば十分にアジェンダとして使える。アジェンダが用意されていない会議には「アジェンダは何でしょうか」と返信し、その後に用意されたら初めて「参加」にすることは意識して行うことがある
- Q: GitLab Handbookは実際に遵守されていますか？遵守されていなかったらどうしていますか？
- A: もちろん守られていないこともあるし、守られていないときにどう振る舞うかもGitLab Handbookに書かれている。やさしくお手本を見せる、ということを個人的にも実践している。何回か見せれば分かってもらえることが多い
- 完璧を目指さない。多様な人々が数千人居る中で、すべてを徹底するのは難しい
- A: もちろん守られていないこともあるし、守られていないときにどう振る舞うかもGitLab Handbookに書かれている。やさしくお手本を見せる、ということを個人的にも実践している。何回か見せれば分かってもらえることが多い
- Q: 非エンジニアをGitを使った運用に巻き込む際に、工夫していることなどあれば教えて下さい
- A: オンボーディングプロセスでプロフィールを更新する機会があり、そこで覚えているのかも知れない。Gitを使った運用は万人向けではないと思う。今回の本の続編でも、完璧なツールはなくそれぞれにメリット・デメリットがあると整理している。使い慣れたツールで、ハンドブックをつくるのが良いと思う
個人的には、GitLab Handbookを六法全書に例えられていたのがおもしろかったです。 全員が常にすべての最新の内容を把握しているわけではないが、問題があったときに参照できる、というのは適切な扱いだと感じました。 一般に公開されているのでGoogle検索やChatGPTからも参照できて便利、という点も言われてみればたしかに！となりました。
まとめ
当初はうまくいくか不安になりながら読書会を企画していましたが、工夫しながら継続することで当初の意図を達成することができました。
また、読書会を開催したことが社内での議論や質問会にもつながり、一人で本を読んだだけでは得られなかったであろう知識を得ることもできました。
もしこの記事を読まれている方が読書会の開催を検討されているのであれば、その一助になれば幸いです。
