はじめに
Wevoxでエンジニアをしている川村です。
アトラエに2014年に新卒で入社し、最初の2年ほどはGreenの開発チームにジョインし、その後当時新規事業だったWevoxの立ち上げに参画し、今に至ります。
なので、かれこれ5年以上Wevoxというプロダクトの開発に従事しています。
今回は、これまでほぼ異動や他事業の開発に関わってこなかった私が、 Yentaのweb版の開発にジョインして感じたことや学んだことについて綴っていこうと思います。
なんで他事業のプロダクト開発に参画したの？
Wevoxでモノリス → マイクロサービス化を進めるにあたり、とりあえずフロントエンドとバックエンドが密結合になっている部分をバッサバッサと断ち切る日々を送っていました。 そんな日々を送るなか、ふと以下のようなことを思ってしまいました。
「この日々を過ごした先に果たして、俺が思い描く、フロントエンドとバックエンドの分離は出来るのか？（自分が突き進んでいる方向性への不安）」
これまで業務以外にもいくつかSPAの類のアプリケーションを作ったことはあったが、ちゃんと本番運用したことがあるアプリケーション(Green / Wevox)はいずれもモノリシックなものでした。
「仮にフロントエンドとバックエンドが分離されたとして、今のようなチーム開発の進め方で生産性が上がるのか？（チーム開発のやり方の不安）」
これまで1人のエンジニアがフルスタック的に一気通貫で機能開発をするやり方に慣れてしまっていました。
それゆえに開発に必要な知識だったり、キャッチアップしないといけない情報が全て年次の高い人にのみ集約されてしまい、新しくジョインする人への共有がとにかく大変かつ、開発そのものが属人的になってしまい、人を増やしてもその分生産性が上がりづらい開発体制になってしまいます。
今のまま、フロントエンドとバックエンドを分離しても、開発のコミュニケーションややり方を変えないとアーキテクチャーを変更した時のメリットが少なそうという漠然とした不安を抱えていました。
「アーキテクチャーと一緒にチームも変わらねば」というざっくりとした課題感と 「Wevoxでの開発の仕方しか知らない」という自分の手札の少なさに対する危機感 「他の事業の開発チームがどういう風に開発しいるのか知りたい。。。！」という好奇心
が入り混じってました。
そうだ Yenta、いこう
「この日々を過ごした先に果たして、俺が思い描く、フロントエンドとバックエンドの分離は出来るのか？（自分が突き進んでいる方向性への不安）」
この課題感に関しては、どっちかというと技術的な課題なので、自分の勉強次第でいくらでも解決可能だが、
以下の課題感に関しては社内外問わず他のチームがどうやっているのか気になっていました。
「仮にフロントエンドとバックエンドが分離されたとして、今のようなチーム開発の進め方で生産性が上がるのか？（チーム開発のやり方の不安）」
悶々とこれらの課題感を抱きつつ、仕事をしていて「フロントエンドとバックエンドが完全に分割されているアプリ開発を真面目にやってみたいなー」と思いその機会を探していました。
そんななか、SlackでYentaのweb版開発の人手が足りてない的なやり取りを発見👀
そうだ Yenta、いこう
ジョイン前に感じていた不安
- 助っ人外国人の感覚でジョインすることになったが、果たして俺の技術力は他事業で通用するのか？！というエンジニアとして月並みな不安
- 健全にコミュニケーションして開発を進められるか不安
- Wevoxでのフロント開発のコミュニケーションと違うことで互いにやりづらくなったりしないかという漠然とした不安
ようはエンジニア的にもメンバー的にも貢献できるのかという不安
実際どうだった？
メンバーとして
- 楽しかった
- 普段お喋りはするけど、一緒に開発したことがないメンバーと開発をするのが新鮮でとても楽しかったです。
- Yentaはデッドラインへのコミットメントが高く、コミュニケーションもスムーズで気持ちが良かったです。(ワンチーム感があった)
- Wevoxだと1人1PJになりがちで、チーム戦というよりは個人戦の側面のほうが強い傾向にあります。(1人で完結できる開発が多いからというのもある。)
- Yentaは企画と開発がバキッと分かれている気がして、そのおかげで開発をするときにワンチームで迷わずに走れるのか？このあたりはもう少しYentaメンバーに話を聞いてみたいです。
エンジニアとして
- 既存アプリの新規web版開発ということもあり、既に仕様がFIXしているかつ、完全な新規開発ということもあり、ゼロベースからコードを書けたので、エンジニアとしてのジョインがかなりスムーズでした。(事前にキャッチアップする情報が少なかった)
- 新規でアプリ開発をするということで、アーキテクチャーパターンの検討や意見交換から議論に入れたのは勉強になりました。
- Wevoxでは採用していないアーキテクチャーパターンに触れることができて手札が増えました。
- プロトタイピング・UX/UI設計がfigmaで完結してるので、フロント実装段階で上がってくるfigmaの精度が高く、実装フェーズでの出戻りが少なさそう。個人的にはそれがとても新鮮でした。
- 各事業の技術スタックの共通化って大事だなと痛感しました。
- 今回Yentaにスムーズにジョインできたのは、TS×Reactという共通の技術を使っていたからというのも当たり前だけどデカイと思った。これがvueとかAngularだとどうしても学習コストがかさむので、即戦力化は難しかったと思う。
Wevoxプロダクトチームで活かしたいこと
- 企画と開発のメリハリ。
- openapi、Figmaの拡充。
- コミュニケーション、キャッチアップコストの削減 → 新しく人が入ったときにスムーズに開発に入りやすくなる → 人を増やしやすくなる → チームの生産性が上がる
アトラエの開発陣で活かしたいこと
- スポット開発でのリソースレンタルをもっと活発、もしくは手軽にできるようにしたい。
- シンプルに一定の技術力があれば、フロントエンドの新規機能開発とかは問題なく戦力になると思う。
- 受け入れる側・受け入れる側双方にとって良い刺激があると思う。
スポット開発でのリソースレンタルをもっと活発、もしくは手軽にできるようにしたい。
この仕組みを作ってみたいなー。
各事業でどういう開発をしていて、どういう人がいたら嬉しいとかそういうのをもう少し知れても良いかも。 今よりも簡易にエンジニアの流動性を高められると、アトラエの開発自体が盛り上がるかつ、みんなでナレッジシェアが進みそう。
まとめ
カジュアルにもっと柔軟に、PJ単位とかで事業を横断してエンジニアリソースを確保し、一緒に開発をすることで ナレッジシェアや、各事業のドメイン知識の理解、メンバー同士で良い刺激を与えられるなど、メリットしかないと感じました。
なにより楽しかったです。
こうした取り組みがしやすいようなエンジニア組織づくりや、技術ポートフォリオづくり、文化を作ることで、 アトラエのエンジニアのパフォーマンスを120%活かせるのでは？といった妄想をしてしまいました笑
今回の挑戦を通してアトラエのエンジニア組織の理想な状態の一例を垣間見ることが出来たので、それだけでもとても良い学びになりました。
