組織運営でやって良かったこと

組織運営でやって良かったこと
=====

おはようございます。フルスタックエンジニアの @sinpaout と申します。

## 体制
エンジニア：20名
PO（管理）：4名
デザインナー：3名
QA：5名

■ エンジニアの内訳
バックエンド：15名
フロントエンド：5名

## 技術スタック

ウェブアプリの開発

Rails + Vue.js
Mysql
AWS
Codebuild（使っている現場初めて）

## 課題

人が多いのでコミュニケーションコストがかかる。

 1. 決めたことを共有
    - 当時のメンバーで決めたけど暗黙的なルールになっていて共有もれ
    - コンフルとかに書いて残すけど多すぎると読まれない
 2. 仕様を分かる人がいない
    - POも全部知らない
 3. 人の依存が激しい
    - 難しいバグは昔からいる人が対応
 4. 異なる契約形態
    - フリーランスはドライ
    - SIerは社畜精神満載
    - イケてる会社からの出向はわがまま
    - プロパーはエネルギッシュだが分かる人が少ない
 5. インフラチームの暴走
    - バグ出まくっているのにKubernetes入れたがる
 6. DX（Developer experience）が低すぎる
    - 環境構築チームがよしなにCIタスクをやってくれるが開発は行わないのでズレがよく生じる
    - フロントバック関係なく全ての30分かかるテストが終わらないとマージできない
    - 触っていなくてもテストが失敗することがしばしば

## チームのマイクロ化

チームを大きく2つに分けて新規開発と既存メンテチームで回していた。
スクラム開発をしてたためその週のことしか考えてなかった。
メンバーはタスクが終わらないと表向きは責められないが
KPTで深掘りされて嫌になってしまう。
その不安からちゃんと設計するより終わらすことを優先してしまう。

うまく回らないのでスクラムを廃止しウォーターフォールに戻す。

## チームの分割
バックとフロントチームを分ける。
バックは新規実装チームと既存バグ修正チームと2つに分割。
フロントは5人チームになって回しやすくなった。

気づき：
全員同じ職種のチームになると一人で責任を背負わなくても良いという安心感がうまれる。

## 長い会議とはおさらば
フロントからはリーダークラスか関係者のみ出席するようにした。
内容をチーム内で朝会などで共有。

気づき：
会議は全員出る必要ない。
チーム内の共有がうまく伝わらないときはコミュニケーション方法が問題である。

## フロントエンド会
フロント会というカジュアルな定例を毎週30分だけ開催。
主にフロントで直したい部分、入れたいツール、運用方法を修正などを議論する。

気づき：
カジュアルで少人数の縛りのない会だとみんな本音を話してくれる。

### モブプロ
フロント会でモブプロを実践。
Jest導入してテスト書いてみる。
これは意外と盛り上がってチーム感が強まる。

気づき：
自分より経験が少ない人からでも学べるものがたくさんある。
実装の問題はスキルよりほとんどナビゲーターとドライバーのコミュニケーションに問題がある。

### 運営の当番制
毎週責任持って開催する幹事を当番制にする。
幹事の仕事：
 - 場所と日にちを選定
 - 議題のピックアップ
 - 宿題（後述）の管理
 - 議事録

気づき：
ドライなフリーランスもどんどん問題を提起してくれる
当番制だから部外者として立ち回れないので積極性が高まる。

### 議題を思いついた時点で書く
Slackのスレッドでとにかく書く。
やる、やら、大きい、小さい関係なくとにかく書く。

気づき：
自分の上げた議題がとにかく議論に上がるので、組織へ貢献している気持ちになる。

### 宿題化
議論でやること決まったら全員に宿題としてタスクをふる。

宿題の例：
1. eslintのルールを追加
2. Sentryのエラーとソースマップ連携
3. Webpackのチューニング
4. TODOコメントの除去

など具体的な作業に落としてから宿題にする。

#### 宿題が終わらない問題
抽象度が高い問題は終わらない。
タスクを洗い出して簡単かつ具台的になるように工夫。

例：
VuexのstrictモードをONにしたことによるアラートを解消。

これには下記のタスクが必要：
1. エラーが出ているかどうかを知る
2. すぐ直せるものと直せないものを分ける
3. 直せるものをリストアップして対応していく
4. 直せないものはリストアップして議題に上げる
5. QAチームに直したところ連携する

などやることが多いので、軽く始めるには気が重くなり、やらなくなる。

解決策としては

先ずエラーが出ている画面一覧だけをリストアップすることだけを宿題にする

と言った簡単なタスクまで分解する。

## フロントがオアシス化

フロントメンバーが自身で環境構築を行う。

1. Docker(Raisl + mysql) を捨て独自のモック環境を構築
   - [Node.jsのみで開発環境を立ち上げられるようにした](https://qiita.com/sinpaout/items/034fdef9773e62764feb)
2. E2Eレベルのテストの導入
   - [インテグレーションテストとしてCypressを導入](https://qiita.com/sinpaout/items/4313ed75e603508696b1)
3. デザインナーと揉め事を減らすため部品の管理を統一
    - [デザイナーとStorybookをS3上で共有
](https://qiita.com/sinpaout/items/a9f2913d8b8b9110a84d)

3. CI設定もフロントのメンバーが行う
   - バックエンドのLinterと分割
   - Codebuild辛いが記事書くねたになりそう（笑）
4. Webpackerを捨てる
   - 将来的にRailsのerbで書き出すのをやめてS3に静的HTMLを展開する予定


フロントチームが管理しやすいように設計したので、他チームへの依頼やバックエンドやインフラチームの都合にさいなまれることがなくなり、パーフォーマンスが向上し、モチベーションが上がった。
他にもエンジニアの正社員を巻き込んだことが、大きく前進できた理由でもある。
エンジニアじゃない正社員だと改善の価値が分からないのでほとんどの意見が通らない。

## 今後の活動
 - erb + coffeeをなくす
 - UTの拡充（モブプロ開催予定）
 - 管理しづらいページを再設計（誰がやっても嫌になる画面があるのでそれを捨てる）
 - ソースコードを読めば全ての経緯が分かる仕組みを導入（模索中）
 - バックエンドへ侵食（みんな別のスキルを欲しがっている）

## 改善Day

チーム全体で改善Dayを設けることになった。

### 特徴
 - エンジニアがやりたいと思っている改善作業をやる
 - 内容の制約はプロダクトの改善につながることのみ
 - 基本やることについては指図を受けない
 - 全員強制参加する、任意だど自然消滅の懸念があるため
 - 改善Dayの退社前にやったことをチケットに報告する
 - できなかったこともやった内容気づきなどを残す

これでエンジニアのモチベーションは多少回復するようになった。

## 総括

人が多いと余計なコミュニケーションコストがかかるのは間違いない。
カジュアルな空気を読まなくても良い場がないと本音が聞けない。
正社員のエンジニアを巻き込むことの大切さがわかった。

基本的にドライな人も社畜の人もわがまま人も、よくしたい気持ちは同じなので、それをうまくブレンドできる仕組みを構築できると、希望が満ちてくることに気づけたのが今回の一番の収穫であった。