さくらインターネット研究所の坪内（@yuuk1t）です。最近は、大学院の博士課程が3年目の後半に入り、大詰めを迎えています。
さくらインターネット研究所では、研究所メンバーが地理的に分散して仕事していることと、研究所メンバーの専門性と参画プロジェクトが多様であることの2点を理由に、メンバー同士が物理的にも情報的にも孤立しやすい傾向にあります。孤立を避けるためには、特別な工夫が必要であると考え、メンバー間の結束を高め、よりよいコラボレーションを生むための施策をこの半年ほど取り組んできました。そこで、この記事では、コラボレーションを促進するための会をつくり、その会で独自に定義したコラボレーションの構造を表現する階層を提示し、その階層の基底部分の「同じ場にいる」と「互いを知る」ことに着目した施策を紹介します。これらの取り組みが、リモートワーク時代のチームビルディングの参考になれば幸いです。
研究所のチームとしての状況
地理的な多様性 研究所のメンバーの居住地は、北海道、埼玉、東京、京都、大阪、福岡と日本各地に分散していることから、COVID-19感染拡大以前から、各メンバーが出社するオフィスは分散していました。COVID-19感染拡大以後、オフィスにも出社することはなく、地理的により孤立することになりました。COVID-19感染拡大の影響がなくなったとしても、今後もこの状況は継続する見込みです。
プロジェクトの多様性 現在のさくらインターネット研究所は、専門性が多岐にわたることから、多数のプロジェクトが分立しています。論文を書いたり、技術調査を行うメンバーもいれば、プロダクト開発を行うメンバーもいます。論文を書くにしても、システムソフトウェア、SRE、機械学習、材料工学、臨床教育学など論文の分野が互いにかけ離れていることもあります。一方で、企業の事業部では、特定のプロダクトを開発・販売するためのチームや特定プロジェクトを実行するためのチームが組織されることが一般的です。事業部であれば製品やプロジェクトを通じた共通のコンテキストを前提とした上でコミュニケーションできますが、さくらインターネット研究所ではその多様性から共通のコンテキストが相対的に少ないと言えます。
このような地理的な多様性とプロジェクトの多様性により、自然とコミュニケーションすることが少なくなり、互いになんとなく孤立していくような感覚を持ち始めました。このような孤立が、以前と比べた顕著なパフォーマンスの低下といった明らかな問題を引き起こしたわけではありません。しかしながら、気づかないうちに、帰属意識が徐々に薄れていくことを感じていました。
この帰属意識の薄れやその結果起こるやりがいの低下を解決するために、主席研究員の@matsumotoryさんが、半年前に、研究所内の人事評価体制を再設計しました。その際に評価項目のひとつに「チームへの貢献」が追加されました。この評価制度の考え方は、次のスライドに公開されています。スライド p.16では、 Don’t Let Power Corrupt Youに記載されているMicrosoftの事例を参照した上で「チームビルディングやコラボレーションのサポートなど、協力しやすいチーム作りにどれほど取り組んでいるかの目標設定を必須にして全メンバーで取り組む」とあります。
企業における人事評価は、被評価者の仕事の成果と能力を以って測ることが一般的です。そのため、「チームへの貢献」を目標（さくらインターネットでは期待値と呼ぶ）として達成することに馴染みが薄いメンバーもいます。自分が同僚と雑談していたときに、チームへの貢献を一人で考えるよりは、チームで一緒にやったほうがよさそうだね、と話をしました。
そこで、「チームへの貢献」の期待値そのものを協働して達成するために、他のメンバーも巻き込んで、次で説明するコラボ会を発足しました。
コラボレーションを促進する会「コラボ会」
コラボ会は、「エンゲージメント（チームの結束）とインクルージョン（帰属意識）を向上させることによるコラボレーションを促進する」ことを目的としています。
コラボ会は、マネージャーを除いた現場メンバーで構成されています。これは、チームでの取り組みとなると、どうしてもマネージャーのみがリードすることを期待してしまうところがあるためです。全員でオーナーシップをもって取り組むからこそ、エンゲージメントとインクルージョンが高まるだろうと考えています。
@yuuk1t がファシリテーターとなり、毎週30分のコラボ会定例を設けて、コラボレーションに関する議題を共有し、解決をディスカッションしています。コラボ会の議論のなかで生まれたタスクをNotion上に作った簡単なカンバンで管理し、現在のタスク実行状況を可視化するようにしています。
コラボレーションの階層の定義
コラボレーションは様々な解釈がありえるため、そのときどきの議論と施策の視点が全員で揃えにくくなる可能性があります。そこで、コラボ会では、研究所でのコラボレーションの構造を定義する必要であると考えました。その構造を次にピラミッドとして図示します。
このピラミッド図では、コラボレーションの構造を次のような階層で表現しています。
- 第０層 「同じ場にいる」：チームメンバーが同じ場所にいる実感をもつことができている状態。これは全員がオフィスに出勤する際には当たり前のことでしたが、リモートワークでは当たり前ではないため、第０層としてあえて設定しました。
- 第１層「互いを知る」：互いの興味・関心・取り組みの内容を知ることができている状態。
- 第２層「つながる」：互いの興味・関心の共通点を発見できている状態。あるいは、共通点がなくとも、知ることで興味をもてている状態。
- 第３層「ともに創る」：共同で同じものを創ることができている状態。創るものは、論文でもソフトウェアでも組織でもなんでも構いません。この状態がコラボレーションが実践できている状態です。
この階層構造では、下位層の状態はより上位層の状態をつくるための土台です。したがって、第０層から土台をつくっていき、最終的には、3層のコラボレーションの実践状態へ至る道筋を仮定しています。第１層と第２層の「知る」「つながる」は、@yuuk1tの前職である株式会社はてなさんのミッション”「知る」「つながる」「表現する」で新しい体験を提供し、人の生活を豊かにする” （ミッション – 株式会社はてなより引用）を由来とさせていただいています。
前述した地理的な多様性に対しては、第０層の「同じ場にいる」、専門性とプロジェクトの多様性については、第１層以上の階層と対応しています。この階層の底から順に、問題意識を共有した上で、課題を発見・解決していけば、冒頭で取り上げたメンバー間の孤立の問題は徐々に解消されると考えています。
このように、独自の構造を新たに考えることは、その出来の良し悪しはさておくとしても、研究所らしいのではと自分は考えています。
個別具体的な施策
コラボ会では、まずは、コラボレーションの階層の第０層と第１層に対応する問題意識を共有し、課題を明確化した上で、解決のための施策を議論してきました。
ここでは、これまで取り組んできた個別の施策についてまとめます。コラボ会を立ち上げる以前に行った施策もリストに含めています。施策の詳細については、今後、この研究所ブログでそれぞれ紹介していけるとよいと思っています。
まず、第０層の 「同じ場にいる」に関する施策は次のようなものです。
- 研究所合宿の開催
- リモートワークで普段顔をあわせることがないことを踏まえて、菊地さん（@kikuzokikuzo）が中心となって研究所合宿を最近では半年おきに開催しています。
- 開催の負担を分散するために、直近の会では、コラボ会で手分けして準備するようになりました。
- 情報共有サービス Notionの導入
- 2020年から研究所ではNotionを導入しました。研究日誌、プロジェクトや人事評価に関するドキュメント、ミーティングの議事録や直近のイベント情報、イベント参加ログ、論文の査読結果、タスク管理のカンバンなどをNotionで共有しています。好きなSF作品の共有リストなんかもあったりします。
- バーチャルオフィス Gatherの導入
- Ubieのshikajiroさんの記事 僕たちはリモートワークに振り回されていた。Gatherを使うまでは。｜shikajiro｜note を読んで、すぐにGatherの試用を開始しました。今では、研究所メンバーのほぼ全員がGatherのスペースに常駐しています。
- 初期のルームのレイアウトは、@yuuk1tが作ったものですが、人数が増えたときにスケールしにくいといった課題がありました。よりよくするために、田村さん（@_tokibi）が中心となって、スケールする（以下の画像の右端に足していける）かつ、より会話が生まれやすいレイアウトに改善されました。
- Slackの複数チャンネルの活用
- 研究所内では単一チャンネルでの運用が基本であったのをプロジェクトごとにチャンネルを切るようにしました。
特にGatherの導入と改善により、みんなと同じ場にいる感が醸成されたように思えます。
次に、第１層の「互いを知る」に関する施策は次のようなものです。
- Coffee Chat: 週次の1対1の雑談タイム
- チームの絆を深めるための総当り1on1の実施と1on1のときに気をつけていること – さくらインターネット研究所 で紹介されている取り組みです。仕事のことでもプライベートのことでもなんでも話せる場です。
- 最近、Coffee Chatという名称になりました。この名称は、GitLabのカルチャーを参考にしています。（参照：Informal Communication in an all-remote environment | GitLab ）コーヒーでも飲みながら雑談しようよということです。
- これまでは、誰といつやるかは各メンバーが任意に決めていましたが、スケジュール調整や組み合わせ爆発により雑談タイムが増加していました。ごく最近、菊地さん (@kikuzoikuzo)により、全員で週の決まった同じ時間（週２時間分）に、ランダムで決められる組み合わせで、一斉にCoffee Chatを行うようになりました。
- 研究所合宿の開催
- 一人につき一つの時間枠が割り当てられ、最近の近況や研究状況を共有しました。
- メンバー同士で互いの価値観や性質を知るために、クリフトンストレングス（ストレングス・ファインダー）を全員で受けて、結果を共有・分析しました。（鶴田さん（@tsurubee）、田村さん（@_tokibi）、野田さん（@sonod00）、熊谷さん（@kumagallium））
- 研究所ビジョンについてディスカッションしました。（熊谷さん（@kumagallium）、@yuuk1t）
- 新配属メンバーのオンボーディング
- 新配属時のオンボーディングについて特別な取り組みはなかったのですが、今年の新卒の中田さん（@chiku_wait） と、他本部から異動されてきた朝倉さん（@pinnnnnnnnnn）が配属されたタイミングで、野田さん（@sonod00）さんが中心となったオンボーディングを実施しました。
- ナレッジ会の開催
- 鶴田さん（@tsurubee）と熊谷さん（@kumagallium）が中心となり、メンバーが専門的な興味や知識をカジュアルに他のメンバーに共有する、ごく最近はじまったばかりの会です。
今後しばらくは第０層と第１層の第2層以降の施策は将来取り組む予定です。
コラボ会の価値の振り返り
コラボ会を半年やってみてどうだったかを全員で振り返りました。朝倉さん（@pinnnnnnnnnn）のリードによる、臨床教育学の知見をとりいれたワークショップ形式の振り返りは、新鮮味あふれるおもしろいものでした。
課題解決より価値発見に焦点をあてた振り返りの結果、各人が感じるコラボ会の価値として次のようなものが挙げられました。
- メンバーが集って互いの存在を確認できる
- 個人の悩みや問題意識をカジュアルに相談できる
- 雑談で終わらず、実行までできる
- コラボ会自体がコラボレーションの場となっている
- コラボ会を通じて、チームへの影響（貢献）の仕方を学べる
前者の3点は、コラボ会のファシリテーターとしてもともと想定していた価値である一方で、後者の２点は良い意味で想定していない価値でした。今後は、これらの価値をより高められるように、コラボ会自体をより良くする余地をみつけ、改善していきたいと考えています。
後日この研究所ブログで、この振り返りに関する詳細な記事が公開される予定です
他組織への応用可能性
今回の取り組みがさくらインターネット研究所以外の他の組織へ応用できるかどうか、その一般性を考察します。
プロダクト開発チームのようにすでに共有されたコンテキストをもつ場合は、チーム内でのコラボレーションは自然と生まれやすいでしょう。そのため、それほど今回の取り組みは有効ではないかもしれません。
一方で、研究所組織以外にも、共有されるコンテキストが薄い、あるいは複数ある組織はありえます。このような組織では、今回の取り組みが応用できる可能性があります。例えば、一つのプロダクトやプロジェクトに１チームまるごと割り当てることが人員数の関係などで難しく、一つのチーム内にそれらが分立しているなどです。他には、チーム内のコラボレーションには課題はないが、チーム間のコラボレーションには課題をもつこともありえるでしょう。さくらインターネット研究所でも、視点を変えれば、研究所内に1,2人の少人数チームが多数あるとも言えます。
別の観点で重要な要件として、こうした目の前にある仕事以外の仕事に取り組む「余白」があります。社長の田中さんが余白の重要性を常々説いています。一週間より先の予定を入れないようにするライフハック｜田中邦裕｜note 余白を持たなければ、目の前の仕事に忙殺され、チームへの貢献どころではなくなるでしょう。結果的にそれではチームの結束や帰属意識を失ってしまう結果になりえます。
まとめ
地理的な多様性とプロジェクトの多様性から、疎になりやすいチームの結束を高め、コラボレーションを促進するための取り組みを紹介しました。具体的には、コラボ会の発足、コラボレーションの階層の定義、階層に対応する個別の施策（研究所合宿、コミュニケーションツールの導入と整備、Coffee Chat、新配属オンボーディング、ナレッジ会など）に取り組んできました。その結果、コラボ会は、カジュアルに相談できる上に施策の実行まででき、コラボ会自体がコラボレーションとなりえるような場になりました。
今後は、どの程度エンゲージメントとインクルージョンを高められていて、どの程度コラボレーションを促進できたのかを効果測定していきたいと思っています。また、この記事で想定しているコラボレーションの枠は現在のところ研究所内に閉じるものですが、社内の他の本部や社外の組織とのコラボレーションまでその枠を拡大することができるとよいと考えています。
付録：類似の階層
コラボレーションの４階層と類似の階層構造は他の分野にもみられます。マズローの欲求段階説では、「生理的欲求」を底として、「安全の欲求」「社会的欲求」「承認欲求」「自己実現の欲求」が積み重なる階層が提唱されています。これは、下位の欲求がより上位の欲求の前提となる構造をもちます。私の専門である、ITサービスの信頼性に焦点をあてるSRE（Site Reliability Engineering）分野にも類似の階層が定義されています。SREの代表的書籍 ”SRE サイトリライアビリティエンジニアリング”の図III -1 サービスの信頼性の階層では、サービスの信頼性について、「モニタリング」を底として、「インシデント対応」「ポストモーテム/根本原因分析」「テスト及びリリース手順」「キャパシティプランニング」「開発」「プロダクト」と続きます。また、これら2つの階層の類似性は、srepath.com に掲載されている次の記事で指摘されています。 Google’s Site Reliability Engineering hierarchy (Remixed) – SREpath for Site Reliability Engineers
