STORES で EC の開発をしているバックエンドエンジニアの @rry です。
今年の1月に入社してから、もう半年になります（早い）
最近はオフラインでの勉強会も開催されず、他社のエンジニアさんと話す機会がめっきり減った今日このごろです。
STORES では毎日わいわいプロダクト開発をしているのですが、普段どんな風に開発を進めているのか、オンボーディングの視点から書いていこうと思います！
※ STORES ブランドは STORES (EC) と STORES ターミナルの2つのプロダクトがあります。今回は STORES (EC) のほうのオンボーディングについてのご紹介です。
オンボーディングの様子
入社してから今までを振り返ると、比較的スムーズに開発プロジェクトにジョインしていけたなと感じます。私の場合はこんな流れでオンボーディングしていきました。
- 入社 〜 1週間
- 簡単な PR を出してデプロイまでの流れをつかむ
- 入社キットやその他ドキュメントを読んで慣れていく
- 入社 〜 1ヶ月
- 小規模な機能開発を一人で行う
- レビューやスクラムに参加する
- 2ヶ月 〜 4ヶ月
- バックエンドチームの開発プロジェクトに参入
- 運用などにも取り組む
- 5ヶ月 〜 半年
- 職能横断型チームで開発プロジェクトをやっていく
- チームや開発に慣れてくる 🙌
ドキュメントを書く文化
STORES には「入社キット」「入隊キット」なるドキュメントが存在していて、オンボーディングの助けになっています。
- 「入社キット」
- 入社してからの開発環境構築や見ておくといい資料などをまとめたもの
- 「入隊キット」
- 各プロジェクトごとに進め方や仕様書まわりなど、途中からプロジェクトに加わったときに見ておくといい内容をまとめたもの
ドキュメントは esa で管理していて、記事の数だけでいうとすでに16,376記事もあります（すごい量）
日報や会社の大事な会議の議事録、技術 Tips や技術仕様など、全て esa でオープンに管理しているため、何か分からないことがあると真っ先に esa で検索するクセがつきます。
私は esa の気軽にアウトプットに繋げられるところが大好きです。情報をドキュメントにまとめるときの心理的ハードルが低いので、ドキュメントを書く文化が醸成されていくのだと思います。
モブプロやレビュー
STORES は約8年くらい続いているサービスで、その分レガシーコードも少なからず存在します。
レガシーコードを改修しつつ、より良い設計をしていくために欠かせないこととして、モブプロやレビューでのディスカッションがあります。
とくに入ったばかりでドメイン知識がない中、どういう経緯の実装なのかを知ったり、未来に向けてどんな設計にしていけば良いのかを話し合ったりする機会は大事です。
私のチームでは主に、
- デイリースクラムの昼会で相談・検討したいことをあげる
- 時間をきめてモブプロをする
- レビューで分からないことがあったら Slack で雑に質問や、call がすぐにできる
- 仕様を決める際には他チームの人たちにも共有してディスカッションする
という流れでやっています。
モブプロについては、EM の @Katsumata さんの資料がわかりやすいので参考までにどうぞ。
COVID-19 の影響とリモートワーク
2月頃から、COVID-19 の影響で全社的にリモート推奨になりました。
私は3月から完全フルリモートで会社に出社していないので、当初はチームメンバーや別チームとの連携など、新しいプロジェクトをやっていく中で、うまくやっていけるか不安を感じていました。
開発を進めていく上で、これはコミュニケーションにおける不確実性を減らす上で役に立ったな、と思う取り組みをいくつかあげていきます。
オンラインドラッカー風エクササイズ
新しいチームで、オンラインでもコミュニケーションを円滑にやっていくために ドラッカー風エクササイズを miro というツールを使ってやってみました。
※ ドラッカー風エクササイズとは何ぞや？という人はこちらの記事が参考になります
「ドラッカー風エクササイズ」で期待をすりあわせて安全なチームに
バックエンドチームだけのプロジェクトから、新たに職能横断型チームでの開発プロジェクトになったタイミングで、バックエンド・フロントエンド・EM・PM のメンバーで行いました。
プロジェクト初期の段階にやることで、お互いが何を考えているのか、自分の役割はどんなものかが分かりやすくなってきて良いです。
オンラインで社内勉強会
COVID-19 でオフラインの勉強会が軒並みできなくなった鬱憤を晴らすかのように、オンラインの社内勉強会や読書会が増えてきました。
フロントエンドチームもバックエンドチームもそれぞれどんなものをやっていたか一部紹介すると、
- 「Web API: The Good Parts」読書会
- 「はじめての GraphQL」読書会
- バックエンド勉強会 Sentry 編
- スキーマ駆動開発（OpenAPI）勉強会
- 「Vue 3 解体新書」読書会
- 「実践 TypeScript」読書会
- MongoDB 勉強会
このほか技術ネタ以外にも「みんなの生活発表会ランチ」とか、「開発環境共有会 教えて！みんなのリモート環境」とか、色々あります。
モブプロや勉強会を支えるテレカンツール
オンラインのテレカンで使うツールは
- Google Meet
- Slack call
- Discord
- Zoom
と、その時の状況やコンテキストに合わせて使い分けています（社内の情報をやりとりする場合は Meet を使うようにしています）
Slack call はペンツールが使えるので少人数モブプロ向きだったり、Discord はゲーム配信に特化しているだけあって、Input Sensitivity が調節できたりとディスカッションしやすい読書会向きだったりします。
オンボーディングを終えてこれからやっていくこと
オンラインでも、工夫をしながらオンボーディングがやってこれている中で、今後さらにやっていきたいことについて考えてみました。
技術チームから職能横断型チームへ
STORES のエンジニアリング組織も大きくなってきて、エンジニアの数も30人を超えてきました。
大まかにフロントエンド・バックエンド・SRE というように各技術チームで分かれていますが、プロジェクトを進めていく上では小さな職能横断型チームを組んで開発を進めていくのが効率的です。
開発を促進していくために今意識していることは、スキーマ駆動開発です。
開発チーム内で認識を合わせてスムーズに開発を進めたい
コミュニケーションを増やしたり、ドキュメントを充足させたりする取り組みも大事ですが、フロントエンドとバックエンドの認識を合わせてスムーズに開発を進めていくために、OpenAPI を用いたスキーマ駆動開発を進めています。
開発の仕様が決まった段階で OpenAPI のスキーマを定義し、フロントエンドとバックエンドが共通の情報を見ながらやりとりができるのが理想の状態です。
※ そこら辺のお気持ちは @morihirok さんが記事を書いています
OpenAPI(Swagger)がYAMLを書かなくてよくなっていたのでSTORES.jpでも導入しました｜morihirok｜note
まだまだ OpenAPI が充足しているわけではありませんが、今後開発していくうえで RSpec 並みに「当たり前だよねー」と言えるようなものになっていくと良いな、と思っています。
開発チーム外との設計や知見の共有を深めたい
STORES の技術について隅から隅まで完璧に理解するのはとても難しいことです。
ですが、開発チームで設計していることを別チームと共有したり、フロントエンドの知見や SRE の知見を教えてもらったりすることは、今後もっと多くのタイミングで必要になってくることだと思います。
そういう知識をアウトプットしていく手段は色々あります。
例えば STOERS の月1で行っている Dev レビュー会では、LT 枠があり誰でも気軽に登壇できます。
また、新しくはじめたこのテックブログも、今後いろいろ充実していくと面白そうです。
STORES のエンジニア陣はみんなつよつよで、普段いろいろ教えてもらってばかりなのですが、これからは自分も学んだことをきちんとアウトプットしていけるような良いエンジニアになっていきたいと思いました。
