こんにちは。エンスポーツの田窪です。
「フルスタックエンジニア」という言葉が一部の採用界隈ではタブー視されていることを知って、戦慄しています。
「どこまでいったらフルスタックなん?」というのが会社によっても個人によっても解釈が違う上に、人それぞれ技術や経験におけるプライドがあるために、採用の現場においてマウント合戦が繰り広げられる火種になりかねないと。
あるいはスタートアップなどの人員リソースの少ない現場では、「フルスタックエンジニアならなんでもできるよねぇ。もちろんこんなこともできるよねぇ」というテクハラ(テクノロジーハラスメント)が常態化しており、怖くてフルスタックエンジニアなんて名乗れないと。
このような世間的な背景の中、バックエンドとフロントエンドが触れるエンジニアのことは「ソフトウェアエンジニア(SWE)」と呼ぶのが良いだろうという着地があるようですので、自分も今後はそう呼ぼうと思っています。
そんな中で今回エンジニアやカスタマーサクセスのメンバーを募集していますので、エンスポーツの開発現場でおこなっていること、求められていることをあらためて整理しておこうかと思います。
エンスポーツの開発現場でおこなわれていること
ざっくり説明すると、下記のようなフローが回ることになります。
- ペインポイントの調査
- 要求仕様の作成
- デザイン
- 仕様作成・開発
- レビュー・修正
- デバッグ・リリース
一通りまとめましたのでご覧ください!
1)ペインポイントの調査
ここはおもにPdM、カスタマーサクセスの日々の仕事ですが、エンジニアにもぜひ参加してほしい領域です。
売上やKPIの状況を見て改修が必要な部分(ペインポイント)を整理する
↓
ペインを解決できる機能案を考える
2)要求仕様の作成
ここは主にPdMの仕事になります。
「これはGOだな」と判断した機能はタスク化して優先順位を決定する
↓
優先順にそって要求仕様を作る
優先順の決め方としては、基本的にUX(≒売上)へのインパクトの大きさと開発の重さを重視しています。
3)デザイン
ここはデザイナーの仕事です。基本的にはPdMがチェックします。
要求仕様をもとにデザイン
↓
チェック
↓
修正が必要なら戻して修正。要求を満たしていたら完了。
3)仕様作成・開発
ここはエンジニアの仕事です。
スプリント計画でタスクが割り振られる
↓
仕様作成&開発
↓
開発者がテスト
↓
オッケーだと思えばプルリク
タスクは機能単位で割り振られますので、フロントエンドとバックエンドの両方をほぼ確実に触ることになります。
あとぶっちゃけ僕の作る要求仕様は詰めが甘いので、PdMやデザイナーへ色々と確認しながら開発してもらうことになります。デイリースクラムで確認することが多いです。
4)レビュー・修正
機能のレビューはリードエンジニアが。最終的な表面的な動きが要求を満たしているか否かはPdM含めてスプリントレビューでチェックすることになります。
リードエンジニアがレビュー
↓
修正が必要な場合、リードエンジニアあるいは開発を担当したメンバーが修正
↓
完了
↓
スプリントレビューでチェック
↓
要求を満たしていればタスク完了
スプリントは2週単位で切っていますので、2週で一機能の開発が終わるのが理想的ではありますが、なかなか難しいことも多いのでその辺りはフレキシブルに対応するような体制です。
5)デバッグ・リリース
基本的にはリードエンジニアがマージやリリース準備を担当しつつ、全員でデバッグをして、OKになればストア審査に出してリリースへ向かいます。
(アプリですので、Apple/Google両ストア絡みのなんやかんやな手順も挟まれます)
リリース分のマージ作業
↓
ステージング環境へテストアップ
↓
デバッグ
↓
本番の内部テストへテストアップ
↓
ストア審査出し
↓
審査完了
↓
必要に応じてメンテナンスを挟んでリリース
メンテナンスを挟む必要がある場合は、早朝にメンテ時間を取ることがほとんどです。なのでリリースを担当するエンジニアは、その日は早朝から働いて昼過ぎに終わる感じになります。
万が一やばいバグが出たら必死で対応する必要がありますが、基本的にはヤバいバグを出さないためにリリース前のテストやデバッグを頑張っています。
エンジニアメンバーの尽力のおかげで、これまでにそんな大きな問題は起こったことがありません。
エンスポーツの開発現場はこんな感じです
というわけでこんな感じで働いています。
たぶん「決められたタスクだけやってお金がもらえたらいいや」という感じの人にはエンスポーツは全然合わない反面、ビジネスやサービス運営の全体に興味がある人なら楽しい環境じゃないかなと思っています。
というわけで、興味のある方はぜひカジュアル面談でお話ししましょう!