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

おはようございます。フルスタックエンジニアの @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のみで開発環境を立ち上げられるようにした

2. E2Eレベルのテストの導入

   • インテグレーションテストとしてCypressを導入

3. デザインナーと揉め事を減らすため部品の管理を統一

   • デザイナーとStorybookをS3上で共有
     

4. CI設定もフロントのメンバーが行う

   • バックエンドのLinterと分割
   • Codebuild辛いが記事書くねたになりそう（笑）

5. Webpackerを捨てる

   • 将来的にRailsのerbで書き出すのをやめてS3に静的HTMLを展開する予定

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

今後の活動

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

改善Day

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

特徴

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

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

総括

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

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