プロスポーツチームを志向するNetflixの脱ルールのカルチャー「No Rules Rules」

今年読んだ本は今年のうちにレビューしてしまおうシリーズの第三弾「No Rules Rules」です。

No Rules Rules

自分が初めてNetflixを知ったのはDVD郵送レンタルサービスだったころで、当時と今ではビジネスモデルはまったく変わってしまっています。ピボットしながら外部環境の変化を上手く活かしてイノベーションと成長に繋げ続けた源泉となったのはその企業カルチャーで、「No Rules Rules」ではカルチャーの詳細や背景、どのような効果を生んでいるかについて書かれています。

中でも特に有名なものは「有給や経費を自分の判断で行使することできる」「市場トップの報酬を支払う」の2つだと思います。

有給・経費については従業員を信頼し、判断のスピードをあげ、結果としてビジネスを成長させるための仕組みです。できる人にはどんどん権限を移譲して自ら判断し成果を出してもらう。成果が出ない人には、チームから外れてもらう、つまりNetflixを辞めてもらう、という考えです。(ちなみに成果が出ない = 失敗しない、という単純なものではなく総合的に判断されるようです。) ちなみに、有給や経費は自分の判断で使うことができるとは言え、"best interests in Netflix"(Netflixのためになっているか)が満されているか、ということが事後にチェックされるようです。

報酬については、最高の報酬を出すことでトップタレントを引き付けるための仕組みです。定期的な昇給プロセスについても、市場価値で決めるため期ごとのパフォーマンスでは決めないポリシーとしており、パフォーマンスによって上げたり下げたりはせず、市場価値が上がれば上げる、上がっていなければ上げない、としているようです。

このようなカルチャーの元で、現場に権限移譲しempowermentする。そのためには、しっかりと従業員が会社の戦略とalignし、依存を減らす (Highly aligned, loosely coupled)ことが大事とされています(このあたりソフトウェアアーキテクチャの議論に通じるところがありますね)。また誰かがなにか失敗した際は、その人を責めるのではなく必要なcontextを共有できなかったことを問題とし改善を進めます。現場への権限移譲を進めることは一般的になってきていると思いますが、そのためにcontextでリードする、という考え方は参考になります。Netflixでは、全社でのalignを深めるためにCEOのReedが全VPとの1時間の1on1を毎四半期するために年500時間、全Directorとの30分の1on1を毎年するために年250時間、計750時間費やしている、とのことです。ここまで時間的コストをかけているのはすごいですね。

Netflixが志向しているのは、プロのスポーツチームのような組織で、最高のメンバーを育て最高のチームを目指しており、その状態を"High talent density"と表現しています。 そのためにもいわゆる“Brilliant Jerk”には居場所はない、としており、“難しい人”が1人入るとチームの生産性が30-40%低下するような状況ではその人は真っ先にリストラされることになるのでしょう。

これらのカルチャーはアメリカの解雇が容易にできる雇用契約(Employment-at-will)とセットとなっていると思われ、年間に辞めさせられる人は8%という数字が出ていました。自分から辞める人は3-4%で、計12%程度の離職率という業界標準的な数字となっているようです。この数字が多いか少ないかはいろいろな解釈が可能かと思います。(後半で日本やフランスのような解雇が難しい労働法の国に進出した際の話も出てくるのですが、このあたりの機微については特になにも記載がなかったのは残念でした。)

これらのようにNetflixのカルチャーはプロのスポーツチームのような状態を志向した一つの振り切ったモデルになっていると思います。これを見習うにせよ、見習わないにせよ、会社として目を見張る結果を出していることは事実であり、知っておくことは価値があると思います。(同時に一部だけ断片的にコピーするのは良くない結果を招くだけとも思いますが..)

これらのようにNetflixのカルチャーはかなり強烈なもので、なかなか真似をするのは難しいのですが、一つフィードバックのガイドライン(5A Feedback guidelines)はどこでも役に立ちそうなので紹介します。

  1. Aim to assist (その人のためになることを目的とする)
  2. Actionable (アクションに結びつけることができるようにする)
  3. Appreciate (フィードバックをする際に敬意を持つ)
  4. Accept or discard (フィードバックを受け入れるか受け入れないかは、受けた側が判断する)
  5. Adapt (結果を得るために、その場のカルチャーに合わせたフィードバックを行う)

立場に関わらず正直なフィードバックをお互いにすることで、より良い状態を目指す、というのは成果を出すために大事なことで、この5A Feedback guidelinesは汎用性が高く有用なものだと思います。

Netflixのカルチャーについては、採用ページにも詳細が載っていますので、こちらからもどうぞ。

Staff EngineerとSenior Engineerの違いを知る「Staff Engineer」

今年読んだ本は今年のうちにレビューしてしまおう、の第二弾「Staff Engineer」です。

Staff Engineer

すこし前にTwitter界隈でIndividual Contributor(以下、IC)の話が話題になってましたが、そのICとしてのキャリアの先にある、日本ではあまり馴染みのないStaff Engineerについての本です。ちなみに本の内容は全て https://staffeng.com/ でも読むことができますので、紙が不要な人はこちらからどうぞ。

Staff Engineerは、会社ごとに、またおそらく部署ごとでも様々なバラエティのある役割の定義があり、この本は著者での経験に基づく記述と、各社のいろいろなStaff Engineerの人たちからのインタビューから構成されています。 著者の経験によると、Staff Engineerの典型例として、一つ、もしくは複数のチームをリードするTech Lead, 特定領域のアーキテクチャに責任を持つArchitect, 複雑で難易度の高い問題解決を担うSolver, シニアリーダー(経営層)のビジョンを実現するためのRight Handの4つが紹介されています(Staff archetypes)。その他、Staff Engineerとしてどのように活躍するか、Staff Engineerになるためにはどうすればよいか、Staff Engineerになるために転職する方法などについて記述されています。

個人的にもっとも興味深かったところはSenior EngineerとStaff Engineerの違いです。

多くの会社では、"Career level"という概念があります。これは、多くの人が到達する上限で、ほとんどの会社ではStaff engineerの下に位置するSenior Engineerとされています。つまり、Staff engineerになることは平均的なことではない、とされています(Getting the title where you are)。具体的には、Senior Engineerに期待されていたこと、例えば、コードを書くなどは、Staff Engineerには付属的なタスクとなります(What do Staff engineers actually do?)。 このあたりの話は、ICの役割をあくまでも手を動かすこと、と捉えていると期待値のギャップに繋がっていきそうです。

実際にCircle CIのCompetency Matricを見てみるとStaff Engineerの"Delivery / Self-organization / Reliability, delivery accountability"の項目では

Ensures expectations with their team and external stakeholders are clarified between all parties involved.

というような外部ステークホルダーの期待値の明確化が含まれています。このシート全体を"stakeholder"を検索すると、15箇所中13箇所がStaff Engineer以上に含まれており、チーム外とのコミュニケーションや期待値マネジメントが各所に入ってきています。

ここ最近では徐々にICのままでもキャリアを進められるように環境が整備されてきていると思いますが、その際にはStaff Engineerに求められる役割はなにか、という理解が世の中的にも浸透していくと、エンジニアとしても経営としても見通しが立てやすくなるんじゃないかと思います。

組織構造を議論するなら今後は「Team Topology」をお供に

今年読んだ本は今年のうちにレビューしてしまおう、ということで第一弾「Team Topology」です。

Team Topology

Team Topologyはソフトウェア開発の規模をスケールさせるために様々なチーム編成と、チーム間のコミュニケーションについてベストプラクティスについて書かれています。 基本的な考え方として、チームの認知負荷(Recognitive load)を一定以下に抑えることと、システムアーキテクチャと組織アーキテクチャを一致させること(いわゆるコンウェイの法則)を重視しています。 その考え方に基いて、チームの型を4つ(Stream aligned team, Enabling team, Complicated-subsystem team, Platform team)、チーム間コミュニケーションのモードを3つ(Collaboration, X-as-a-Service, Facilitating)に分類しています。

チームの特性についての記述で興味深いところは、ダンバー数をベースとした適切な規模(5ー8名)と、コードのオーナーシップについてです。 昨今では、チームが開発から運用までオーナーシップを持つことが一般的となりつつあると思いますが、コードのオーナーシップは排他的なものではなく、他チームを排除するべきではない、とされています。オーナーシップは悪くするとセクショナリズムに陥りかねないので、この考え方を浸透させることは重要に思います。

またコミュニケーションについて、コストの高いコミュニケーション、つまりX-as-a-Service以外のモードでは、事前にコミュニケーションが必要とされる期間を決めておくところは慧眼だと思います。 個人的な経験としても、チーム同士のコミュニケーションが当初ほどは効果的ではなくなっても、なんとなく継続されていて、気付いた時にはあまり効果はなくコミュニケーションのオーバーヘッドだけが残っていた、ということがありました。あらかじめ期間を決めておくことは、効率的なコミュニケーションを維持する上では有効そうです。 また、逆に開発チームが本来は自分のチームでやるべきタスクをSREやPlatformチームに依存してしまい、その状況がずっと続いてしまう、ということもよくあります。これを避けるためにも決められた期限までにX-as-a-Serviceのコミュニケーションに移行する、と合意しておくことも大事でしょう。

その他の内容も面白いですが、チームとチーム間コミュニケーションの分類が、自分の経験としてもかなり的を射ているように思われ、今後、チーム構造やコミュニケーションパターンを議論する際の共通言語とできると良さそうです。

邦訳も最近でたので読み易くなってお勧めです。

"A Philosophy of Software Design"がお勧め

今年の7月に第二版が出た"A Philosophy of Software Design"を読んだ。

本書では、ソフトウェアシステムの複雑性を最小化するための設計について、モジュール/クラス設計、インターフェイス設計、レイヤー設計、エラーハンドリングから、コードの書き方まで様々な側面から具体なコード例をあげつつ解説している。

ソフトウェア開発において、システムをシンプルに保ち複雑性が上がることを避ける原則は、KISS (Keep it Simple, Stupid), DRY (Do not Repeat Yourself)YAGNI (You Ain't Gonna Need It)などが昔から言われている。これらのフレーズ自体はソフトウェアエンジニアが取るべき行動は示しているが、その理由は示していない*1。 本書では「ソフトウェアシステムの複雑性」が上がることの課題を「コードやシステムの理解が難しくなること」「コードの変更が難しくなること」の2点と定義しており、複雑性という抽象的な概念を言語化し、課題として認識しやすくしている。

昨今のソフトウェアシステムは、複数のソフトウェアエンジニアが入れかわりながら、長期間にわたって継続的に開発、運用されていくことが多く、いかに複雑性を上げずに機能を追加していくか、がシステムデザインの大きな課題となっている。 マイクロサービスもそのための方法論の一つで、一つのチームが担当する領域の境界を明確にすることで複雑性を下げることを狙った設計と言える(もちろん成功している例もあれば、失敗してかえって複雑性が増してしまっている例もある)。 いわゆる「技術的負債」も、コードの複雑性が上がり、コードの把握と修正が難しくなってしまっている状態と考えることができ、複雑性をいかに下げるべきか、という観点でリファクタリングなりを行うことができる。

本書で挙げられている具体的なポリシー、例えばコメントをどのようにどれぐらい書くべきか、例外をどのように扱うべきか、については、チームによって賛否が分かれるところもあるだろうけれども、ソフトウェアをデザインする際に複雑性を下げる(上げない)設計を良い設計ととらえる考え方は汎用性が高く、本書でカバーされていない領域(例えばマイクロサービスの設計)でも応用が効く原則だろう。

残念ながら翻訳はまだのようだけど、それほど分量も多くなく英文も平易なので、一読をお勧めしたい。

ちなみに初版と第二版の差分は、 * Chapter 21 Decide What Mattersの追加 * Chapter 6 General-Purpose Modules are Deeperの改訂 * Clean Codeと意見が分かれるところ(コメントに対する考え方)の追記 となっており、差分分のpdfが著者のサイトから確認できる。

*1:これらの原則に対して理由付けをしている文書は多数あるけれども