テック企業の文化とエンジニア組織における文化の大切さ

# はじめに

* 本記事は、**「テック企業の文化とエンジニア組織における文化の大切さ」ということでOreilly社より出版されている[ユニコーン企業のひみつ Spotifyで学んだソフトウェアづくりと働き方](https://www.oreilly.co.jp/books/9784873119465/)を基に話を展開しつつ、私の体験してきたエンジニア組織の文化という内容**をお届けしていきます。

## ユニコーン企業 / テック企業 とは

### ユニコーン企業

* ユニコーン企業というのは、評価額が10億ドルの企業でありながら、「未上場」で「創業10年以内」の企業をさしています。
(元ユニコーン企業の例 : Google, Amazon, Facebook, Spotify)

* 珍しい、希少性があることからユニコーンと言うそうです。

### テック企業

* テック企業というのは、ユニコーンになることを 目指しているがそこまで至っていない企業をさします。

## 文化の重要性

* 今までは、テック企業において文化とは勝手に育つものと思っていましたが、 その時代は終わったとされています。
* 現在だと多くのテック企業が文化に直接投資をしています。

**=> これは一体なぜなのでしょうか？**

**それは、優れた文化が可能にするのは優れたプロダクトを生み出すことだけでなく、 最高の人材の採用(ここで働きたいと思うことで)に繋がるためです。**

## ユニコーン企業 / テック企業での文化

* ユニコーン企業、テック企業は共通する文化があります。

**それは何か?**

=> ** フラットな階層や、権限の与えられた信頼のおける小さなチームとなっていることです。**


## 働きやすい文化
### 上司編

* Spotifyでは、CEOが従業員に対して直接、困りごとを質問し「助けを求める」文化があります。

![スクリーンショット 2022-06-24 2.36.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563635/018ccad3-1d70-0732-fc3e-ca23fcb1ae1f.png)

=> どの辺が働きやすい文化なのか？

それは、**「なんでもお見通し」と思われていた管理職の方々でも気軽に助けを求めてもいいという風習になるためです。**

### ミス編

![スクリーンショット 2022-06-24 2.41.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563635/ee20e0b7-7ae7-2150-27e3-80fb8d42795a.png)

* 例えば誰かがミス(本番環境でやらかす)をしてしまった時、メールとか社内のコミュニケーションツールで「気にしなくて大丈夫だよー。 よくあることだし。本番環境を壊すのは勲章でしょ!!。」と言われる環境って素晴らしいですよね。
* だって、 壊したのはその人が最初じゃないはずですし、最後でもないはずです。
*  それに壊せてしまうような本番環境だという事実自体、そのシステムにまだ改善の余地があることの証拠となるので、プラスと捉え**やらかした人を責めない文化**って重要だと思います。

## いい感じの職場にするためのTips

* スウェーデン(Spotifyの拠点)の人たちが職場で交流を 深めるのに活用している習慣 に「フィーカ(Fika)」と呼ばれるものがあります。

### フィーカって何？
* フィーカとは、チーム単位のコーヒーブレイクを指します。
* このフィーカには誰もが参加(参加しないのは文化的に非礼とされているようです。)
* また、参加者は好きな話題を自由に話せます。
* **このフィーカの目的は、みんなで集まり同僚のことを知り興味関心を 共有して絆を深める機会を作ることにあります。**

## 私の体験してきたエンジニア組織の文化

* ここからは、私の前職で体験してきたエンジニア組織の文化についてお話ししていきます。
* 前の会社は、フランスの会社ということもあり様々な国のエンジニアがいました。
* なので様々な文化が 混ざっているのが特徴的です。
* また、新人、ベテラン関係なくタスクが割り振られ対等に接してくれました。

### ここはちょっと面白かった

* １日で決まった時間(15分〜20分くらい)は、 チームのエンジニアで、カフェでコーヒーブレイクをしていました。
* また、イベントや勉強会、コミュニティの活動は、 プロジェクトの仕事より優先していいとされているのも驚きでした。
* ALL Hands meetingなどの全体会議では、すごい数の質問が毎回出てきます。 (日本だと会議やイベント時に「沈黙が金」的な感じがあると 前に言われたことがあります。)

### 組織の視点からの文化

* 組織としては、下記のような体制をとっており、それぞれのドメインごとにトライブというものが存在します。
* そのトライブごとにプロダクトオーナが存在します。
* エンジニアは、チャプタというエンジニアだけで構成されたチームに在籍し、それぞれのPOごとが持つチームにアサインされる形をとっておりました。

![スクリーンショット 2022-06-24 2.56.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563635/1edee0a2-271d-37a9-1eec-5c1babc29526.png)

### 社内におけるコミュニティ

* この組織において、技術的なコミュニティが複数存在していました。
* コミュニティは、Community of practice(CoP)として、チームを横断したメンバーが好きな時に参加/離脱できるものでした。
* 言うのであればこれが本来のギルドと呼ばれるものですね。

![スクリーンショット 2022-06-24 3.00.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563635/5da8acd9-e7f7-c393-63dd-3b0c16d768f4.png)

### Community of practice (CoP)とは？

* あるテーマに関する関心や問題、熱意などを共有し、 その分野の知識や技能を、持続的な交流を通じて 深めていく集団をCommunity of practice(CoP)と社内では呼んでいました。
* ちなみに私が在籍時に存在していたCoPは以下のものがありました。

  * フロントエンドCoP
  * Node CoP
  * Java CoP
  * スクラムマスター CoP
  * Git CoP
  * TDD CoP
  * などなど

#### CoPの面白いところ

* 開催頻度は、隔週に1回開催されていました。
* 参加は自由で、いつ入っても抜けてもOK  – 皆さん複数のCoPにだいたい参加していた印象です。
* 使用言語は、英語で、1時間の枠で開催し、前半後半で分かれ、発表やデモなどを見せ議論するのが一般的でした。
* また、プロジェクトの仕事よりも、CoPの活動が優先していいとなっています。  (ここについてはPOなども了承していました。)
* CoPのリーダは、自由 (四半期で代わり、挙手制、 なるべく若手にやらせるようにしていた。 先輩が手厚くフォロー)となっています。

# さいごに

* エンジニア組織における文化は本当に大切だと私は思っています。
* **文化が素晴らしければ優秀なエンジニアが集まりますし、何より仕事をしていて楽しいと思えるからです。**
* 今回書いた話が何かしらの参考になれば幸いです。
* 最後まで読んでいただきありがとうございました。！

# 参考

https://www.oreilly.co.jp/books/9784873119465/