こんにちは。
ココナラ 人事の泉谷（@Show_Iz）です。
今回は、余計な脚色無しの武骨なスタイルで弊社の『バックエンド/SRE』ポジションに興味をお持ちいただいた方が知りたいと思われるであろうことをまとめていきたいと思います（求人票を補填する意味合い）。
基本的には面談でご来社いただいた際に丁寧に説明している内容のエッセンシャル版的な内容になっていますので、もしこのへんを深掘りして聞いてみたいとかあればぜひお気軽にオフィスに遊びにきていただけると嬉しいです！
システム構成図
リアルさを追求して、ホワイトボードへの手書きスタイルでお送りします。
技術スタック
- 言語：Ruby、PHP、Go、JavaScript
- フレームワーク：Ruby on Rails、CakePHP、Vue.js、Nuxt.js
- データベース：MySQL
- ソースコード管理：GitHub
- プロジェクト管理：ZenHub
- コミュニケーションツール：Slack
- 情報共有ツール： esa、Confluence
- インフラ環境：AWS、Docker、GCP
最近社内的にHOTなのは、「Go、API Gateway、gRPC」らへんでしょうか。
もし、面談の機会をいただけたら、より詳細をエンジニアの口から説明させていただきます。
一般的な開発フロー
大小さまざまなプロジェクトが走っているのですが、一般的な開発フローをまとめました。読んでいただけると、弊社がどういった流れで開発しているか、多少解像度が高まるかと思います。
（1）仕様検討
- プロダクトオーナーがプロダクトの方針を決定する
- プロダクトオーナー・プロダクトマネージャーが仕様検討を行なう
（2）見積もり・設計
- 検討された仕様を元に、仕様の確認・すりあわせを行なう
- 仕様が決まった後、全体設計を行なう
- 設計時は使うべきものを使うということを意識する
- 決定された仕様と設計を元に、開発メンバー全員で作業量見積もりを行なう
- 見積もりにはストーリーポイントを用いる
- 見積もられたポイントをもって、プロダクトオーナー・プロダクトマネージャーと全体の開発スケジュールを決定する
（3）実装
- 最新の技術だけにとらわれない、その時点でのベストプラクティスを追求した実装を行なう
- 開発ツールはなるべく最新のものを使用する
- ソース管理にはGitHub、CIはCircleCIを使用
- コードレビューはPull Requestで行っており、2人以上にレビューしてもらい、LGTMをもらったらコードをMerge、あるいはリリース可能
- 毎日の朝会で躓いている箇所、困っていること、相談が必要なことなどを共有する
- 具体的な相談などは朝会後、関係者のみで集まって行なう
- 開発スケジュールに支障がでるレベルの「困ったこと」がある場合はプロダクトマネージャーと相談し、スケジュールの調整かアサイン調整を行なう
（4）テスト
- 開発が完了すると、プロダクトオーナー、プロダクトマネージャーとのレビューを繰り返し、機能をブラッシュアップする
- QAチームにテストを依頼し、フィードバックが無くなるまで修正対応を行なう（※大規模開発時）
（5）リリース
- レビューが通る & QAチームのGOサインが出たらリリースを行う
- 大規模開発時は必ずQAチームのGOサインが必要（小さな修正時は不要）
- 毎日リリース可（ただし休日前は時間制限あり）
- 緊急修正が必要な場合、グループの上長に承認をもらえた場合に限りリリース可能
（6）反映
- どの機能がどれだけ使われていて、それらがどのようにKPIに貢献しているかを測定
- 測定結果をプロダクトの開発計画や仕様策定に反映
中の人に聞いたココナラでエンジニアとして働く魅力
求人票には、以下のとおり記載しているんですが、実際にこのポジションのメンバーにヒアリングしたものを少し抽象化したものとなります。
バックエンド
- エンジニアリングを手段としてプロダクトづくりができる
- つくったものに対するユーザーの反応をダイレクトに感じることができる機会が多い
- 非エンジニアメンバーがエンジニアのことを理解しようとするスタンスのため、エンジニアと同じ会話ができる
- メンバーが自社プロダクトをちゃんと利用しているのでプロダクトを共通の話題として盛り上がることができる
SRE
- SREチームは発足したばかりで、仕事の幅はとても広く、様々なことにトライできる環境である
- アーキテクチャ改善をおこなったり、サービスやエンジニアの開発生産性にインパクトを出すことができる
- 新技術に積極的にトライするため、新しいことに感度が高い方にとっては楽しく働ける環境である
- 技術的負債をコントロールし計画的に管理し実行する力がつく
上記内容について、せっかくヒアリングしたので抽象化する前の生の意見（SREチームは発足したばかりのため、バックエンドを中心に）もこの記事ではお伝えしたいと思います。
- SQLやロジックなど、非エンジニアとも同じ会話ができる
- プログラミング的思考を持っているメンバーが多い
- 良くも悪くも数字で話す人が多い（感情で話さない）
- やることをきちんとやっていれば自由にできる
- 他の人の行動そのものに意見しないため、メリハリがある
- ユーザーが多いので反応が早い
- 業務システムをつくっていると良い機能なのか疑問がわく
- 他社はFBの機会があまりない
- 何をみてとかどこを目指して開発しているのかがわかりやい（ユーザーのメリットってなに？）
- 業務システムをつくっていると良い機能なのか疑問がわく
- ユーザーが多いので反応が早い
- ちゃんとみんなが自社のサービスを使ってFBし合うため、共通の話題になる
- 飯のタネ→話の種なので盛り上がりやすい
- 入り口がサービスや事業の人が多い
- 自分が使うものを作っている感がある
- エンジニアリングは手段
- 飯のタネ→話の種なので盛り上がりやすい
- 話したいことをちゃんと相談できる雰囲気がある
最後に
以上、システム構成や開発フロー、中の人の意見をまとめてきましたが、百聞は一見にしかずなので、少しでも興味をお持ちいただけましたら、ぜひオフィスに遊びにきていただけると嬉しいです！ www.wantedly.com