背景

転職クチコミサービスの転職会議を開発するプロダクトチームは2014年頃には6名ほどの小さな組織でした。

2017年現在は30名強と、徐々にメンバーを増やしながら成長してきました。

今回はこのチームで作り上げてきた文化の話をしたいと思います。

Team Geekとの出会い

僕たちが成長する上で強く影響を受けた書籍がTeam Geekです。

HRT（謙虚・尊敬・信頼）などで有名な名著ですが、チーム文化についても重要な項目として語られています。

この文化というのは非常に捉えづらいものではありますが、文化を意識してチームを作る事が非常に大切だったなと感じています。

Spotify engineering cultureとの出会い

文化について意識的に作り上げる段階において、強く影響を受けたのがSpotifyの資料です。

前後編合わせて30分程度の短い動画ながら、Agileの精神、Leanな開発、上手な「失敗」の仕方など、非常に濃い内容が含まれています。

2014年の資料であるにもかかわらず、今でも共感できる内容がたくさん含まれています。

皆が同じ目標を向き、自律的に動く組織文化

Spotifyの資料の中で特に影響を受けたのが「高いAlignmentかつ高いAutonomyな組織」のモデルです。

少々馴染みの薄い言葉なので、それぞれ意味を訳してみます。

Alignmentは、「整列」や「同調」「一致性」「団結」など、一方向へ向かう様子を表しています。

Autonomyは、「自治」・「自律」という意味になります。

つまり「同じ方向を向いた状態」でかつ「自律的である」という事になります。

この2つの概念は、それぞれ相反するような概念に思えるかもしれません。

しかしSpotifyの資料においては、むしろ「高い一致性こそが高い自律を可能にする」とも語られ、どちらも高い状態であることを理想であるとしています。

もう少し深掘りすると、理想像はこのようなことと言えます。

明確なミッションを持ち、メンバーとリーダー全員が、同じ方向を向いて同じ目標に向かって進む
メンバーは「どう解決するか？どれが最適か？」の部分を考えて実行する。
リーダーは「何が課題か？解決のために何が必要か？」に責務を持つ

Team Geekでもミッション・ステートメントの重要さや、サーバントリーダーなど類似する考え方があり、これらの重要さが語られています。

この「明確なミッションを高いレベルで共有し、高い一致性を持ち高い自治性があるチーム」という理想像は、転職会議のチーム文化へ強く影響を与えてくれました。

高い一致性と自律性を持ったチームで何が出来るか？

それでは高い一致性と自律があるチームは何が良くて、何が出来るのでしょうか？

ここからは僕たちが理想像のチームだからこそ出来たと感じていることを紹介していきます。

とりあえずやってみる → 上手く行ったら残す/駄目ならすぐ捨てる

新しい仕組みやツールへのトライアル・施策は様々な懸念があったり、障壁が高いなどがあり、どうしても腰が重くなりがちです。

転職会議では「とりあえずやってみよう」を合言葉に、フットワークを軽くアクションを起こす文化を推奨しています。まず小さくやってみる→運用してみる→上手く行ったら残す / 駄目なら修正するか撤退する、という流れです。

Spotifyの資料では、Part2の「Waste-repellent Culture」という項目で類似の事が紹介されています。また、Lean Startupの考えともほとんど同じです。

当然、各々が何も考えず無作為にいろんなものを取り入れてしまえば混沌としてしまう可能性もありますが、各自が責務と自由のバランスの上で行えているので今のところ適切にワークしています。

標準化(Standalization) より異花受粉(Cross-pollination)

リブセンスではPHPやRuby on Rails、Go、Reactなどがよく使われています。

これらはすべて誰かが決めたわけではなく、自然発生的に広まっていきました。

Spotifyの資料においては異花受粉（Cross-pollination）という呼び方で、この徐々に良いツールがチームからチームへ伝播してデファクトスタンダードとして広まる現象を説明しています。併せて、一貫性と柔軟性が保たれる効果をもたらされる利点も説明されています。

新しい言語やツール、ライブラリを一つのチームが取り入れて、それが良いものであれば隣のチーム・リポジトリにも使われるというフローは、開発にはよくあるごく自然な現象です。

しかし、その現象に対して「足並みをそろえて標準化するより、より良いものが自然に伝播していく文化には利点がある」ということをしっかり認識することで、「とりあえずやってみる」の精神をより加速させて来ることが出来ました。

今日まで、良い温度感で技術の新陳代謝を進めることが出来ていると感じています。

「とりあえずやってみる」の部分でも懸念として上がりましたが、こう聞いてしまうと「いろんなライブラリが入って、学習コストが高くなってしまうのでは？」と感じる方もいるかもしれません。

こちらも同様で、各自が正しく目的を捉えた上で適切な技術選定を心がけているため、極端に突飛な選定はされず、各自の責任の持てる範囲でのチャレンジがなされています。

Internal Open-Source Model

Spotifyの資料ではInternal Open-source Modelというのが紹介されており、転職会議でもこの考え方を取り入れました。

これはチームで開発されるシステムを全て内部的なオープンソースと同じように扱い、特定のチームが特定のシステムだけ触るのではなく、必要になったチームがPull Requestをするというやり方です。

この方法はPayPalのInnerSourceも近いかもしれません。

転職会議は現在クチコミ関連の他にも・求人・会員情報・ログイン認証・企業向け管理画面など、大小幾つかのシステムが独立的に動いています。

これらのシステムに対し、専属のチームを設けるのではなくそれぞれのチームが自分たちのミッション・施策に応じて、各チームが必要なシステムに必要なだけPull Requestをしてリリースして作業を進めています。

一つのシステムに対して必ず一つのチームが改修する体制にしている場合、自分たちの施策が他のチームの優先度で左右されてしまったりということがありがちです。

Internal Open-Source Modelを取り入れることによって、各チームが他のチームに依存せずプロジェクトを進めることが出来ています。

リポジトリオーナー

通常のオープンソースにコアなメンテナが存在するのに倣って、各リポジトリに複数人のオーナーとサブオーナーを設けています。 *1 これはいくつかのリポジトリで試験的に行ってみて、うまくいきそうだったので現在展開しています。

オーナー・サブオーナーはOSSのメンテナと同じようにコードレビューを行い、リポジトリの品質や一貫性を担保することが主な責務で、その代わりにリポジトリのライブラリ選定やコーディング規約などもおまかせしています（先に説明したCross-pollinationによる伝播がチーム内でも適度に行われる事も狙っています）。

基本的にはそのリポジトリを頻繁に触るチームのメンバーや、そのシステムに詳しいメンバーから選出しています。システムを触らなくなってきたり、オーナー業務が偏ってきた場合には適切に交代や追加をしていく予定です。

品質の保持や一定の自由度が出来た上での副次的な効果として、コードレビューが一部のメンバーへ極度に偏ったり、逆にレビュアーが多すぎて緊張感の無い薄いレビューになってしまう問題が緩和出来る効果がありました。

また若手メンバーにもサブオーナーになってもらい責務を持った視点でレビューをしてもらうことで、育成の機会になるという部分も見られそうだと感じています。

「やってあげる」よりも「出来るようにする」（Self-serve Model)

転職会議がAWS化した時期を境に、SRE(Site Reliability Engineering)チームが設立されました。 *2

SREチームはサイトのパフォーマンス向上やセキュリティ向上、安定的な運用を目指しているチームです。

まだまだAWSに移行したばかりで、ノウハウが足りない、メンバーの学習が追いつかないなど、様々課題もあります。

新しいシステムの作成などAWSに触る部分が出てきた場合、慣れているSREチームのメンバーが作業をしてしまう方が素早く出来るのですが、どうしても作業が集中してボトルネックになってしまいがちです。

そのためSREチームが直接作業するのは極力減らし、どんどんメンバーが各自で「出来るようになる」という土壌を作ることを心がけています。

フロントエンドにおいても類似です。フロントエンドが得意なメンバーが作業を請け負うのではなく、できるだけ触ったことが無いメンバーをアサインしたり、勉強会を執り行ったりして「出来るようにする」ということを意識しています。

デザイナーとフロントエンドエンジニアのやり取りにおいても、CSSやテンプレート、JSXなどを全部フロントエンドエンジニアがやってしまうとボトルネックになってしまう事があるため、ある程度からはデザイナーだけでもどんどん作業が出来るようにしています。

どちらもInternal Open-Source Modelと同様、各自に信頼を置いてやれる領域を可能な限りで広げ、なるべく他のチームやメンバーがボトルネックになるのを避けるような取り組みです。

部分的なリモート勤務

リブセンスには今のところリモートワークなどの制度はありませんが、転職会議チームでは会社の規則に反せず、チームで適切に運用できる範囲でのリモート勤務を取り入れています。

導入にあたっては、オフィス出社を前提とした上で上手くリモートの自由度を取り入れているQuipperさんの記事を参考にさせていただきました

基本的にはこのようなルールで進めています。

基本的にはオフィスに出社するのが前提。対面の会話は大事にする
- 在宅勤務をするときはチャットでコメントする。
- 用事などリモート関係なく出勤時間がずれる場合もチャットでコメント
タイムシフトのためのリモートではないので、基本的に作業時間はずらさない
- だいたい11:00〜18:00でみんなが働いているので、そのぐらいを目安とする
体調不良を理由にしたリモートワークはナシ
- 低いパフォーマンスで仕事せず、しっかり休んで回復させる

朝や午後に数時間利用したり週に1度丸々リモートにするなど、利用の仕方はメンバーによって様々です。

数ヶ月やってみて今のところ混乱や問題は無く、快適に運用できています。これもメンバーが高い一致性と自律性を持って仕事に取り組めている文化があってこそ上手く行ったことではないかなと感じています。