『ユニコーン企業のひみつ ――Spotifyで学んだソフトウェアづくりと働き方』を読んで

『ユニコーン企業のひみつ ――Spotifyで学んだソフトウェアづくりと働き方』をほそぼそ読んで読み終わった。

ユニコーン企業のひみつ

最近ダラダラ怠惰な日々を送っているので、ダラダラと読んでいたが、ピクニックしながらとかカフェとか朝コーヒー飲みながらで、概ね2時間弱で読み終わった。そのくらいあっさりと薄い分量の一冊。

一方で、内容はそれ自体をめちゃくちゃ参考にする、というよりかは多かれ少なかれ同じような事を考えて日本企業でも実践していることが多かったと思う。

Spotifyがスウェーデン企業で国民性的な文化面が比較的北米企業よりも近いことも由来するだろうか。

スクワッド

少人数の必要な権限を持った小さなチームをスクワッドと呼んで運営している。

スクワッドは職能横断型で、デリバリーするプロダクトに責任を持ったメンバーが揃うチーム。NetFlixのフルサイクル開発者の語彙を参考にして弊チームであるBASE BANKは「フルサイクル開発チーム」と呼称しているが、それに近い子の印象を持った。あくまで自分の視界で近く見えるだけで組織設計視点とか労務視点とか別の視点では違うものでもあるのだろうが。

Full Cycle Developers at Netflix

スクワッド成立に当たり、分離されたアーキテクチャがあるという。ダニエル・ピンクのモチベーション論におけるモチベーションの３因子である「自立」・「熟達」・「目的」において、個人的な考えとして大きなモノリスでオーナーシップを持って熟達できないシステム上では、いくら自立・目的を満たしてもモチベーションの行き場を失ってしまう、と考えている。

やる気に関する驚きの科学

やっかいなのが、大きなモノリスがすぐにそれぞれの自立した「スクワッド」単位にばらせるかというと、そう現実は甘くはないという課題が立ちはだかる。

各チームが熟達、つまりコード・DevOpsに責任を持てる単位にリアーキテクチャしていくには、人リソースを一定レベルそこに張るという決断が求められる。

ちょい耳が痛い話としては、ユニコーン企業はその技術的決断について「非技術者にわかりやすいように」説明するまでもなく素早くやってのけるという。そこにリソースを貼ることの意義について理解がある経営陣、みたいなのは一つの要因としてあるのだろうが、経営会議等に参加したことがある役割ではないので、そこについては特に言及を飛ばす。

プロダクトマネージャーはエンジニア出身が多い

テック企業におけるプロダクトマネージャーはエンジニア出身が多いという。弊チームのPdMもエンジニア出身だった。たしかにエンジニア出身ではない場合にある程度翻訳が求められるし、技術的負債の解消についてのコミュニケーションを行うのは少しだけ骨折りかも知れない。

トライブ、チャプター、ギルド

SquadはTribe内であればわりと行き来しやすいっていう特徴に「いいな」と思った。ソフトウェアエンジニア職は飽きるので、トライブ内であればいききしやすのは個人にとっても柔軟だし、トライブ内で優先順位の変更がありリソースの集中が必要な際に、特定squadへ寄せるとかの柔軟性もある。

もう一点Chapterもいいな。トライブ内で同じ専門性を持つグループを指すようだ。この中に専門性についての理解のあるチャプターリーダーがいるという構造。このような目的に対してフォーカスしたチームは、専門性の近い職域通しのコラボレーションや各個人の給与策定等における専門性の評価が問題になるが、この構造はピープルマネジメントを職域とするようなEngineering Managerをsquadごとに多数増やさないといけないわけではない点で現実に即しているのではと感じた。

くわえて、語彙を自身のチームで定義することの有用性もSpotifyから学べる点かもしれない。完全に他社や一般的な職種定義では表しきれないが、マッチするロールがあったときに、それに自身らで「色眼鏡なし」で役割名を定義するのはよい。

一方で、役割となったメンバーはぐぐっても出ないものを担うことになるので、しっかり組織内で言語化しきったり、その言語化された役割が当人のキャリアに対して有用であることもモチベートおよびマッチングすることが不可欠だろう。