STORES.jp のフロントエンドチームがイイ感じなので紹介する

STORES.jp

今年の 7月末でリブセンスを退職して、8月からはフリーランスとして STORES.jp / hey という EC のサービスを作っているスタートアップで働いている。2か月半ほど働いてみた感想として、友人にも自信をもってオススメできる企業なので紹介したい。

できるだけ中立的な立場で書く

少し話が逸れるけど、以前 OLTA という企業にカジュアル面談に行ったときに、業務委託として OLTA で働いていた @ffu_ さんが中立的な立場で同席してくれて、とても助かった（発言が信頼できた）のを覚えている。可能な限りそういうスタンスで、友人に伝えるような感じで、良いところもそうでないところも書こうと思う。

あと、できるだけ印象ではなく、こういうことがあったなどのファクトベースで書いていくつもり。

なんか、みんな、ちゃんとしてる（語彙）

僕は正社員5名、業務委託4名、計9名という規模のフロントエンドチームに所属しているんだけど、ここで一番強く感じているのは（語彙がアレだけど）「みんな、ちゃんとしてるなぁ」ということ。

もう少し具体的に書くと、

一次情報を確認する
分からないことをなあなあにしない
課題に対する解決策として技術を導入する
週末、技術で遊んでいる

というあたりを日々感じている。

そういう人と一緒に仕事ができるということは、自分にとっては、どんな福利厚生よりも有り難い。ましてやチーム全員がそういう人だなんて、とても恵まれていると感じる。

(1) 一次情報を確認する

Qiita やブログなどの情報（言い方悪いけど野良情報）も参考にはすることは勿論あるだろうけど、Issue やプルリク上での議論においてそれらが貼られることは、ほとんどない。

貼られることがあるのは専ら公式ドキュメントやソースコードの該当箇所や企業が発表した公式情報などのリンクで、それらを基に話が進められていく。

(2) 分からないことをなあなあにしない

プロダクトに何かの不具合が見つかったとして、ひとまず特定のリリースを巻き戻す（Revert）することはあるけれど、その後、原因を（主にソースコードレベルで）特定して、対応する。

「何かググったらこのライブラリのバージョンを上げろと書かれていて、上げたら直った」とか、

A ライブラリと B ライブラリの「相性が悪いから」とか、

そういうゆるふわな（だけど、あるあるな）発言はここでは聞いたことがない。

(3) 課題に対する解決策として技術を導入する

技術を闇雲に導入したりしない。いま自分たちがどういう課題を抱えているか。課題をよく吟味して輪郭を把握したのちに、課題の解決策として適した技術を適切な方法で導入する。そしてその軌跡が Issue や Qiita:Team に残っている。

(4) 週末、技術で遊んでいる

Slack で「週末、〇〇（という技術）で遊んでたんだけど」とか、まだ業務に導入していない技術の話をしていても「こんなこともあろうかと！gas-clasp-starter ドン！」みたいな発言がちょいちょいある。

設計やテストの方針などのガイドラインがある

あと、うわ、いいなぁと感じたのは、例えば、コンポーネントの分割だったり、こういう箇所にはテストを書くとか書かないとかのガイドラインがあること。そしてそれが形骸化していないこと。

Qiita ドキュメントにそれが書かれてあって、更新もされていて、実際のコードと乖離していない。

技術的負債との付き合い方

週替わりで 1名、リファクタリングなどを含めたカイゼンタスクに専念する、という仕組みがある。小さなカイゼンはここで行われる。

また、例えば Rails と同じリポジトリにある AngularJS 1.x を段階的に切り離して Vue / Nuxt の SPA に移行するみたいなものは、複数人でプロジェクトとして進めていっている。

ドキュメントを書く文化

上の設計やテストの方針などのガイドラインにせよ、プロダクトの仕様にせよ、新しくチームにジョインした人のための資料（通称: 入社キット）にせよ、あらゆる情報が Qiita ドキュメントにまとめられている。

入社キットの手厚さにはまじ感動した。

詳しくはチームメンバーのひとり @daitasu が書いた STORES.jp（hey）に入社して3ヶ月が経ちました｜daitasu｜note に譲るが、フロントエンドチームのドキュメントだけで 1年間に 211件とか。

認め合う文化

誰かのファインプレー、ちょっとした親切な振る舞いなどを認め合う文化がある。Slack や Unipos でのやり取りにそうしたものを見ることができる。

対人リスクも取れる

居心地は良いがぬるま湯的な感じではなく、時には対人リスクをとって問題に向き合うことができる。

最近だと例えば「Jest の API を半分も使いこなせていない気がしている」という Slack での発言から端を発して、メンバーのひとりが「仕事で使う技術スタックの公式ドキュメント、チュートリアルは1度全部やるのが最低ルールだとおもっています」というような、つよつよの発言があって、内心、一瞬ヒヤリとしたんだけど。

なんかそのまま通っちゃって、アドバイスもらったほうも「じゃあとりあえず公式ドキュメントに全部目ェ通してみますわー」みたいな感じで会話終わって、次のスプリントレビューのときに「こういう API があることを知ってべんり〜だと思った」みたいなことを笑って話してて、ああ、なんかいいなと思ってた。

（念のため補足しておくと、上の Jest よく分からんと言ってた人も、普段から勉強熱心な人ですよ）

いわゆるあれだな、チームが「ラーニングゾーン」にいて、心理的安全性のポジティブな影響を享受できている状態だな（『エンジニアリング組織論への招待』Chapter 2 が詳しい）