はじめまして。開発部のマネージャーをやっている mizushimac です。 流行りに乗ってみてペロリも開発ブログを始めたわけなのですが、エンジニアやデザイナーからの面白い開発ネタのエントリーをお待ちいただく間（とプレッシャーをかけてみる）にペロリの開発部についてちょっとご紹介したいと思います。
何を開発しているのか
詳細は 、株式会社ペロリの最新情報 - Wantedly 等を見ていただくとよいのですが、ペロリは、⼥の⼦のなりたいオシャレがみつかるキュレーションプラットフォーム「MERY」とその関連サービスを開発、運用しています。Rails で開発された Web 版から順調にユーザー数を伸ばし、昨年末からローラのCMでご存知の方もいらっしゃるかと思いますが、アプリ版も順調にユーザー数が伸びていまして、Web も アプリ対向の API もかなりのトラフィックを捌くサービスになってきました。
昨年の9月からは、ECの機能も立ち上げ、10月からは、「MERY PASS」という、3000円でなんどもネイルサロンのサービスが受けられる月額サービスも新規に立ち上げ、ユーザー数もサービス、機能のボリュームも２次元的に増えていて、みんなヒャッハーって言いながら、その中でも、サービスと会社の成長と個々人の成長を日々実感しながら開発をしています。
開発部の雰囲気
開発部の人たちを一言で言うと、若くて、自由で、ストイックな男子が多いです。一部おっさんもいますので安心してください。女性エンジニアは残念ながら一人もいません、MERY なのに。。。でも開発部の周りはもちろん女子ばっかりです。しかし、何故か全然女子力は上がってきません。課題です。
ペロリのエンジニアは主体性のあるメンバーばかりですので、チーム毎にやりやすい形で自由に働き方や使うツールを決めてますし、それぞれの個性やスキルに応じて責任範囲や立ち位置も自然と決まってくるような感じです。
一見すると開発部という組織としては未熟に見えるかもしれませんが、その自由さが逆に個々人の主体性と開発のスピードを維持することに繋がっていている部分が多々ありますし、完成された組織というのが逆に似合わないのがペロリだと思っているので、このスタイルは当面維持したいと思っています。
そんな感じだったので、今までは、開発部というものが名刺に印刷されるだけのものだったんですが、最近ではメンバーからの要望もあって、技術的な情報のシェアとかエンジニアならでは活動も活発になってきました。このブログもその一環であります。
- 会議室でお酒を飲みながら、LTをするTech Beer
- 気軽に技術的な相談ができるエンジニア限定のTech Lunch
- 11時出社でいいんだけど何故か意識の高い人が勝手にやる朝活ハッカソン
- だんだんつらくなってくる輪読会とそのリマインドbot
- 障害の振り返りから始まる開発部定例で技術ネタとかトピック共有
- 各種飲み会
などなど、エンジニア同士で盛り上がる、語る、刺激し合う、こういう横のつながりを大切にしよう、その象徴として開発部があるんだな、という認識になってきました。
チーム構成とか開発の流れ
その時々の事業戦略や優先度に応じて柔軟にチームは編成していて、時には少人数の新規立ち上げチームを作ったりしますが、今は、
- MERY Server Team（Media）
- MERY Server Team（EC）
- MERY Server Team（Common）
- MERY App Team
- MERY PASS Team
で、構成しています。 それぞれがスクラムっぽく、Daily Stand Up や ストーリーポイントベースの Sprint 計画とベロシティー計測、KPTの振り返りから WA の更新などをやっていますが、これもスクラムありきではなく、各チームのやりやすい形に必要なことだけを必要なツールを使ってやっています。そしてその取組は、開発部定例などで共有します。
インフラも専任の人は今はいません。絶賛募集中ではあるのですが、アプリケーションとインフラの垣根も低く、アプリケーションの機能開発もしながらインフラの構築、メンテもやってしまうサーバーエンジニアが仮想インフラチームのように振る舞っています。すげー人たちです。
MERY の PO 的な立ち位置としては、Web 全般を取締役の河合さんがみていて、App 全般を私がやっています。社長のあやたんを含めた他の事業部の人達とのディープな議論の末に、企画の要件や開発ロードマップ、プロダクトバックログを整理して、担当のエンジニアとデザイナーがすぐに設計、デザインできるレベルまでいい感じにばっくり仕様を決めていきます。そして、担当のエンジニアがナイスなツッコミを入れながら仕様がさらに洗練され、爆速で PR を仕上げてしまう。そんな感じです。
河合さんについて詳しくはこちらを。 thebridge.jp
「的な」「っぽく」「ばっくり」「感じ」というキーワードが多いですが、決していい加減にやっているわけではありません。エンジニアがしっかりとした思考力を持っていてコミュニケーション力が高いからこそ、決めすぎずに伝えたほうが、いいものが出来上がるのでそういう「感じ」にしています。
デザイナーとの距離が近い
フロントエンドエンジニアとアプリエンジニアのすぐとなりにはクリエイティブ部のデザイナーが座っています。これはすごく効率が良くて、ペロリの特徴でもあります。デザインだけ外注という世界とは真逆の環境です。
MERY はおしゃれじゃなきゃ成り立たないので、全社的にデザインにはとてもこだわっています。デザイナーが最高のデザインを作り、それをエンジニアが UI/UX としてプロダクトに魂を吹き込むためには、デザイナーとエンジニアが F2F でモノを見ながら作っていくことがとても重要なのでそうしています。こだわり過ぎて進捗が見えなくなることもありますが、ある程度許容して妥協せずにやりきってしまうのもペロリの良さです。
他にも SEO のチーム、EC の事業部の近くの席がいいと言ってくるエンジニアも多く、日々細かい席替えみたいなことが起きていますが、それだけコミュニケーションの効率を大切にしている証でもあると思います。
尖ってからちょっとバランスとる
個人的な経験則なんですが、ペロリに来るまで、
- ユーザーのニーズだけを鵜呑みにして失敗したケース
- 事業計画の数字だけ追って失敗したケース
- エンジニアが作りたいものだけ作って失敗したケース
をたくさん見てきましたし、自分もやらかしてきました。 失敗は悪いことではないとも思うのですが、
- ユーザーの視点
- 事業や経営の視点
- 作り手の視点
があるとすると、何かそれらのバランス感覚が欠けていたように思えるのです。
なので、ペロリの開発部は、この中でも作り手としての視点を第一に持ってその領域で尖る、というのは大前提としてあるのですが、一方でペロリ全体やそれぞれの開発チームが作り手の視点だけに偏っていないかを常に自省することが出来る存在になりたいと思っています。
MERY はサービスとしてとてもうまく成長しています。反面、今までのペロリは、作り手としての視点が弱かった、声を上げていなかった、少し軽視されていた側面があったかもしれません。
なので、このブログはそんなペロリのエンジニアやデザイナーの個性や尖った部分を存分に表現、お伝え出来る場になったらいいなと考えています。
そして、その内容が世の開発のエコシステムに取り込まれて何処かで役立つことを、結果として、ペロリの開発現場に興味を持っていただけることを願っています。