こんにちは、 @daitasu です。

今年7月にPERSOLグループという人材系の企業を離れ、STORES.jp(hey)というECのサービスを作っているスタートアップに転職しました。

ちょうど今週(2019/7/15)で3ヶ月が経ちますので、振り返りも兼ねて入ってみての感想を並べようと思います。

私はいま、STORES.jpのフロントエンドチームに属しています。3ヶ月間で行ってきた開発内容や技術的な話などは別途お話しする予定(後述)なので、この記事ではheyグループの制度について、企業文化やチーム体制などの説明と感想をお話していこうと思います。

heyってなに？

そもそもheyってなんでしょう？

STORES.jpはheyグループという組織に属しています。

heyは、STORES.jpとCoiney という2つの組織の持株会社です。現状オフィスも同じ場所でお仕事をしていますし、会社としての制度や文化などは基本的に共通と考えて良いです。

STORES.jpってなに？

STORES.jp は、誰でも簡単に、本格的なネットショップを作成できるサービスです。プログラミングやマークアップ(HTML, css)、サーバの知識などは一切必要なく、会員登録から販売する商品の登録、公開まで2~3分程度でできます。

STORES.jp社はこういったサービスを通じて、自分の活動を本格的に行いたい個人やスモールチームの方々に、より自分らしいお商売を続けてもらうことを大事にしています。

STORES.jpのサービスについて、そのテーマや世界観については以下の記事が分かりやすいのでよければ見てみてください。

本題

さて、ここからはそんなSTORESで過ごしてみた3ヶ月間で感じた文化、heyグループとしての制度など参考になりそうな話を述べていこうと思います。

STORES.jp(hey)のオンボーディングプログラム

STORES.jp(hey)には、入社時からおよそ3ヶ月間のオンボーディングプログラムがあります。中途入社で入られた方々に、よりスムーズに業務の中に入ってもらうためのプログラムです。

先に言いますが、heyのオンボーディングはしっかりしている、と言うのが率直な感想です。

自己紹介

入社するとまず、Qiita:TeamとSlackのワークスペースへの招待が届いているので、それぞれ参加して自己紹介を書いたりします。

そうすると、一杯祝福リアクションがきます。めでたいです。お昼時なのでおにぎり絵文字を入れてみました。みんなノッテくれます。お茶目です。

また、詳しい自己紹介はQiita:Teamにまとまっています。初めての場所って緊張してしまいますし、誰が同じチームかも分からずちょっと怖いですよね。でも、右の人は「餃子つくり職人」、左の人は「週末必ず越谷レイクタウンにいる」、みたいな何でもいいので情報の色がつくと、馴染みやすさがぐんと上がります。

入社キット

最初の色々な説明を聞いた後、自分の机に移動すると、1枚の紙が置いてあり、PCのセットアップから入社日に行うことが分かりやすくまとまっています。

また、Qiita:Teamに参加後、「一番初めに読む入社キット」と言うQiita記事に飛ぶのですが、ここには、勤怠管理や各窓口、福利厚生など必ず目に通して欲しいもの、各種環境のセットアップ方法(チーム別)、ここから3か月のオンボーディングの流れが一通りリンクとしてまとまっています。

このページを一通り見るだけで必要な情報は正直網羅できた気がします。

リーダートーク、社長トーク、ランチ

入社して1ヶ月以内に、STORESの各チームのリーダー、Coiney/STORES/heyの社長からのお話を聞いたり、一緒にランチする時間があります。

各組織体制や今までどんなことをやってきたか、これから何をやっていくかなどを直接聞けるため、組織の全体像の大枠をなんとなく捉えられます。あと、直接サービスや今後への熱意とか聞けるのもいいなと感じました。

1 on 1

1 on 1 がたくさんあります。各チームでやっている1 on 1と別に、オンボーディングとして、人事との1 on 1(入社1週間)、CTOとの1 on 1(入社1か月)、社長1 on 1(入社3ヶ月)。最近の近況確認であったり、やってみたいことであったり、割とカジュアルに話すことができます。

ただ、1 on 1の前に自分の中で話したいことや聞きたいことなどをもう少しまとめておけばよかったなと思いました。それぞれ1時間程度なので、カジュアルとはいえ、話題の整理から入ると勿体無いような気がします。

いずれにせよ、オンボーディングプログラムについて、しっかりした設計と手厚さ、何よりドキュメントの完成度を感じ、これはつよつよだなと思いました。

STORES(hey)の制度や文化

次はheyでの制度や文化についてお話ししていきます。

まずは制度について。

顔認証

heyには社員証というものがありません。執務室の出入りには顔認証システムを利用します。

こんなものが扉の隣についており、正面に立つと1~2秒程度で認識して扉が開きます。これは地味に嬉しいです。社員証を首から下げることでの肩こりも減りますし、忘れてはいけないものリストから1つでも除外できることは心理的負担が大きく下がります。

STORES VISIT

heyでは、STORESやCoineyを導入しているお店での購買を、月5000円まで会社が支払ってくれます。これにより、どんなお客さんがいるのか調べる機会にもなりますし、自分たちのサービスをユーザとして触れるというのはエンジニアとしてもいい制度かなと思います。

参考程度に、こんなお店があるよ、という紹介を置いておきます。

フレックスタイム制度

フレックスタイム制を導入しており、コアタイム 12:00〜16:00となっています。私は朝弱いので、だいたい10:30~11:00くらいに出勤します。朝のテンションが低いと一日の生産性に関わりますので、自分が「よしっ！」と思えるタイミングで出社できるのはいいことです。

年棒制

heyのお給与は年棒制です。年俸の12分の1を毎月支給、毎年2回見直しとなっています。

これは賛否あるかもですが、個人的にはgoodでした。毎月これだけ頂けると言う数値が明確に分かるため家計簿に優しく、残業代という響きがもともと嫌いで、残業はえらい、みたいな目的と手段が入れ替わる風潮などは嫌だったので、今の方が伸び伸び仕事ができています。

週一リモート制度

heyでは、週に一回リモートを行うことができます。特に細かな申請はなく、以下を満たしていればオッケーです。

- チームに伝えている
- 前日にSlackで宣言する
- リモート日に「始めます」「終わります」を宣言する

週1と書きましたが、台風など緊急の際は上限はありません。人命第一です。以下は先日の台風19号の際に社長から届いたメッセージですが、こういう言葉があることも、いい会社だなぁと感じます。

休暇について

有給休暇と別に、バケーション休暇というものが付与され、年の好きな時に利用できます。私は先日、この制度でお休みをもらって那須に行ってきました。スケジュールが危機でない限りはいつでもラフに取れるイメージです。

その他にも、ベビーウェルカム休暇、キッズサポート休暇など育児に関する制度は充実しているようです。ただ実体験がないので、この辺は以下を見てもらった方が良さそうです。結婚したら語ろうと思います。

月1の全社MTG

「レビュー会」という、1ヶ月の施策の振り返りや数値としてどうだったか、目標値の再確認などを行う全社MTGを月1で開催しています。

エンジニアの仕事ってサービスの成長にどう繋がっているか見えにくい部分があると思うのですが、今なぜそれをしているのか、何を目指そうとしているのかなどを毎月振り返り、数値として見ていけるのはありがたいです。

個人的な印象ですが、STORES(hey)はビジネスサイドの情報がとにかくオープンなので、技術だけでなく、サービス自体やグロースの施策などについても関心があるエンジニアはより向いているのかなと思います。

さて、ここからは文化の話です。

褒める文化

heyでは、Unipos という成果給ピアボーナスを導入しています。

日常で何かしら感謝の気持ちをポイントとして送り、一定期間でポイントを区切り、合計ポイントの換算が賞与という形で渡されます。

こういった制度って、だいたいどこの企業も導入しているものの、形骸化していたり、一部の人しか使わないイメージがあるのですが、heyは非常に盛んです。

上はざっと拾ってきた最近の一例ですが、運用タスクや改善系のタスクを完了して褒められるだけでなく、議事録を取ったりSlackのチャンネル招待だけでも褒めてもらえたりします。嬉しいですね。

なんというか、投げたがりが多い印象です。投げてもらえると、自分も投げ返そうと思いますよね。心理学では「返報性の原理」って言うらしいです。盛んに投げ合ってるのを見ると、どんどん投げたくなります。そして新たな投げたがりが生まれてきます。

このサイクルがすでに醸成されており、褒め合うという点についてはしっかり根付いている気がします。

多趣味である

heyは多趣味な人が多いイメージです。Slackのチャンネルを覗いてみましょう。

漫画、アニメ、ボードゲーム、カフェ、キャンプ、ボルダリング、盆栽など様々な項目があります。インドアからアウトドアまで様々な趣味の方がいて、各々割と本格的だったりするので、文化祭とかやるとすごく盛り上がりそう、そんなイメージです。一方、体育会とかは苦手そうです(筋トレ好きは多そうです)。

Slackのリアクションが盛ん

Slackのリアクションが盛んです。Slackのカスタム絵文字が数百個入っていて、みんな絵文字を使いこなしています。

このように、絵文字で会話することも多いです。左から翻訳します。

Bさん(done)：「ポチッとレビュー終わったよ！」
Aさん(圧倒的感謝)：「即対応ありがとう！最高の感謝です！」
Aさん(unipos)：「あとでUnipos送りますね！」

このように、文字を使わず話をすることも割と日常です。

Docを書く文化

オンボーディングのところにも書きましたが、heyはDocがつよつよです。

何はともあれQiita:Team、されどQiita:Team、いつも心にQiita:Teamです。

とにかくみんなDocumentを書きます。そして9割9分は覗けます。各チームの週報、日報、経営会議、経営陣の@naokoさんと @sato さんの1on1のメモとかもあったりします。

エンジニアとしては仕様や設計の過程などが気になるかと思いますが、この辺も充実しています。

私が所属するフロントエンドチームだけでも、現在211件のDocumentが存在しています。フロントエンドチームができたの自体がここ一年間の話なので、1年間で211件になります。だいたい調べたら出てきます。

Issueを書く文化

githubのIssueについても盛んです。気になったことや改善したいことなど、ひとまずIssueにしておくと、必ず誰かがコメントしてチーム内での審議へと上がっていきます。最速数秒でコメントがつきます(Slack連携通知でみられてます👀)。

運用週で改善文化

仮に、上記IssueがPJTの中で進められないようなものだったとしても、STORESのエンジニアは、運用週と呼ばれる「お問い合わせや不具合の対応」、リファクタリングなど含めた「改善タスク」などを一気に片付けていく週を設けています。

フロントエンドチームからは、週替わりで1人ずつ運用週に入ります。色々な課題がIssueとして並んでいるので、優先度高いもの、挑戦したいものなどから順に拾って倒していきます。

フロントエンドチームについて

さて、長くなりましたが最後に私が所属するフロントエンドチームについても軽く触れようと思います。

STORESでは、全社員でおよそ80名、エンジニアだけで30名弱います。

その中で、フロントエンドは現在正社員5名、業務委託4名の構成となっています。

STORESでは昨年より、AngularJSからNuxt.jsへの移行を行っています。

- 既存機能のNuxt.jsへの移行
- 新規機能や新プロダクトのNuxt.jsでの開発​
- フロントエンドにおける不具合や改善要望の対応
- プロダクトマネージャーと連携してのパフォーマンス改善やUI改善

などが主な業務となります。

この記事では、heyとしての福利厚生/制度や文化などについて話しましたが、技術面とかどうなの？って部分もエンジニアとして気になるとこだと思います。

フロントエンドチームがどのようなことをしているか、扱っている技術の大枠などは下記にまとまっているので、ご参考ください。

課題感

いいことばかり言ったみたいになりそうなので、課題感を感じたところも書いておきます。

Docが多い

さっきと言ってること逆じゃないか！と言われそうですね。Documentが多いことはそれだけ情報を多角的に見れますし、属人性を減らせるのでいいことです。

一方で、Docが多いと検索の難易度は上がります。

- 見つけたい記事にすぐにたどり着けるか
- その情報の鮮度はどうか

これらはDocが増えるほど雑多になってしまいますので、早くなんとかせんとなぁ、と言った気持ちです。そんな経緯があり、フロントチームのDocについては、最近順に整備/改善をどんどん進め始めました。真っ最中です。

人が増えると、よしなに、はダメ

STORESは、現在社員80名ほどですが、1年前までは20名でした。人数成長率4倍です、恐ろしいですね。

地元が田舎寄りの方は想像してほしいです。全校生徒20名の学校を卒業して、上京1年後に里帰りしたら生徒数が80名になっているんです。震えます。

人が増えるということは非常にいいことですが、課題も出てきます。

今までなんとなくそうだよね、と共通認識になっていた部分は、新規の方には通用しません。Docがあっても、書いた際の前提知識がずれてると読めない文章になってしまいます。

また、人数が多いと、これはあの人に聞けばいい、みたいな認識も分からなくなってきます。

そのため、この辺も整備真っ最中な認識です。再度組織や制度を見直したり、Docガイドライン、コーディングガイドライン、チームごとの新人教育をどうするかなど整えています。

OUTPUT不足

STORESには、Developers blogのようなものはありません。また、各々の個人ブログでheyについて書かれていたりはしますが、技術面の内容などはあまり外に出ていないイメージです。

とはいえ、STORESはRuby会議やVue Fesのスポンサーをしていて理解があったり、技術内容も

- Nuxt.js移行における課題
- コンポーネント設計をどのように行なっているか
- ECにおけるパフォーマンス改善
- Storybookでの共通コンポーネント整備
- reg-suitを用いたビジュアルテスト

など、だいぶ考えられて整備されているので、外に話すと結構面白いのではないか？といった点も多いのですが、現状そんな機会があまりありません。

ですので、そういった技術内容の発信も今後頑張りたいなと思っています。

宣伝

さて、長くなりました(6000字超えたようです)があと少しだけ。

最後に宣伝で恐縮ですが、STORESのフロントエンドに関するイベントをやります。

私はここ3ヶ月で、主に商品の登録/編集などを行うアイテム編集ページのNuxt.js移行に関わってきました。

その中での上記に書いたような、どんな設計で進められているか、Storybookやビジュアルテストをどうしているか、実施時にぶつかった壁などをお話しします。

この記事で、STORES(hey)への解像度が少しでも上がって頂けたら幸いです。