ZEALS TECH BLOG

チャットボットによる会話広告『fanp』を開発する株式会社ZEALSのテックブログです。技術やエンジニア文化について情報を発信します。

ZEALS第2回エンジニア開発合宿に行ってきました!!@三浦海岸

f:id:zeals-engineer:20190521171954j:plain

皆さんこんにちは!
サーバーサイドエンジニアの阿久津です!

5/11(土)〜5/12(日)の2日間、ZEALSで2回目となる「 エンジニア合宿 」に参加しました。
私は今回から初参加だったのですが、今回の合宿の様子を紹介させていただきます。

  • 概要
    • 開発合宿の目的
    • 合宿場所
    • 開発テーマ
  • タイムテーブル
    • 5月11日(土) 1日目
    • 5月12日(日) 2日目
  • 開発の様子
    • 1日目
    • 2日目
      • ダイエットアプリ
      • 顔認識
  • 良かったこと・反省
    • 良かったこと
    • 反省
  • 最後に

概要

開発合宿の目的

今回の開発の目的は以下3点です。

  • 普段の業務で触れることのできない技術に触れることで、組織全体の技術スタックの幅を増やす
  • 非日常でのコミュニケーションを取り、メンバーの結束を強くする
  • 今後、個人で勉強を進めていくきっかけを掴んでもらう

技術力の底上げはもちろんですが、普段できないような深いコミュニケーションも1つの大きな目的でした。

合宿場所

合宿の場所はモチベーションを左右する大切な要素ですよね!

社内の事前アンケートの結果、オフィスからのアクセス1時間以内の近場ということでマホロバ・マインズ三浦さんに決定しました!

開発は室内なのでどこでもよい派だったのですが、考え改めました。。
綺麗な海を間近で見ることができる環境最高!

f:id:zeals-engineer:20190521172338j:plain

開発テーマ

前回の開発合宿では、皆が持ち寄ったテーマをもとにチームに分かれて行うメンバーが多かったのですが、今回は以下のゴールのいずれかを満たせればテーマは自由でした。

  1. プロダクトに跳ね返る
  2. 外部に情報発信できる
  3. 技術の有用性を伝えられる

合宿に参加するにあたり、各自テーマを決めて合宿前に事前に共有してから開発をスタートさせます。

開発スタイルは個人でもくもくスタイルでも、チームでワイワイスタイルでも特に制限はありません。
各メンバーが一番開発しやすいスタイルで開発します。

今回のテーマは自由だったこともあり、バラエティーに富んでいましたが、大きく分けるとこんな感じでした。

  • 社内のアセット整理
  • これから学ぼうとしている言語を使ったアプリ開発
  • 社内のプロダクトに活きる新しい技術の深掘り
  • 開発の効率化ツールの導入

私自身は画像認識に前々から興味があったので、OpenCVを使った顔認識とモーションディテクションにチャレンジしてみました。

タイムテーブル

5月11日(土) 1日目

  • 12:00〜: 現地集合
  • 13:00〜:オープニング開発スタート
  • 19:30〜: 夕食
  • 21:00〜: 自由行動

5月12日(日) 2日目

  • 8:00〜: 朝食
  • 9:00〜: 開発スタート
  • 11:00〜: アウトプット発表
  • 13:00〜: 現地解散

開発の様子

1日目

開発場所はホテルの9階、眺めはバッチリです。 f:id:zeals-engineer:20190521172831j:plain

テーマは事前に決めていたため、簡単なオープニング後すぐに開発スタートです。 f:id:zeals-engineer:20190521172858j:plain

各々好きな場所で開発中。海を見ながらの開発は最高に気分がいいですね。 f:id:zeals-engineer:20190521172928j:plain

19:30に中間報告感を行い、待ちに待った夕食タイムです f:id:zeals-engineer:20190521172954j:plain

食後はフリータイムです。近場の海を散策したり、持ち寄ったゲームで楽しんたり、引き続き開発を楽しんだりしました。チームメンバーの距離感が一気に縮まる貴重な時間でした。僕自身普段あまり聞かない、エンジニアになるきっかけとなった話や仕事に対す熱い思いを聞くことができる、ある意味最も濃い時間でした。 f:id:zeals-engineer:20190522105150j:plain

2日目

朝食後いよいよラストの追い込みです。
みんな開発に集中しすぎて写真が一枚もない。。

11時から各自のアウトプットを全員に向けて発表です。

今回テーマを絞らなかったことで、アウトプットの形も様々で、聞くだけでワクワクしました。
そんな中から、いくつかアウトプットをご紹介します!

ダイエットアプリ

Reactの技術深掘りと本人のニーズがマッチしたプロダクトです。
開発期間短い中でもしっかり動くプロダクトをアウトプットとして出すところにプロ意識感じます!

f:id:zeals-engineer:20190522111609p:plain

顔認識

精度はまだまだですが、顔の認識ができるようになりました。
画像が荒くなってしまいましたが、PCのカメラからiPadで表示した弊社CEO、CTOをしっかり認識してくれています。

f:id:zeals-engineer:20190521174312p:plain

github.com

合宿を通して個人としては小さな成功体験を何度も感じることができました。
そして、新しい言語を学び始めたメンバーはこの合宿をきっかけに、学びが深まり業務にダイレクトに還元されています!

良かったこと・反省

合宿終了後、参加メンバーで振り返りを行いました。

良かったこと

  • 掲げていた目標はすべて達成できた
  • 開発環境が良かった
    • 海が見える開放的な場所でリフレッシュもできた
    • 片道1時間のため、移動で疲れることがなかった
  • コミュニケーションが取れた
    • 普段話せないメンバーと話したり、深い話をすることができた
  • テーマを事前に決めていたので、すぐに開発に取り掛かることができた
続きを読む

復活のGotanda.jsに運営&参加してきました!

f:id:zeals-engineer:20190516184449j:plain

皆さんこんにちは! 
ZEALSでVPoE兼サーバサイドエンジニアをやっている福本です!

5月10日に行われました五反田のJavaScriptコミュニティGotanda.js』が約1年振りに復活することとなりました!

gotandajs.connpass.com

今回は再始動イベントに参加してきましたので、そちらのイベント模様と今後のコミュニティ活動について簡単にお伝えできればと思います。

ちなみに、私福本が今回からGotanda.jsのOrganizerに加入させていただいており、イベントやコミュニティ運営をメインとして行っておりました!

github.com

再始動のご挨拶

今回の会場は五反田東口にあるモバイルファクトリーさんの会議室をお借りして実施しました!

f:id:zeals-engineer:20190516175829j:plain

こだわりを感じるキレイなオフィスでした

30名の参加枠に対して43名の方から申し込みが殺到し、さらに当日も申し込みをされた方がキャンセル無しで全員参加されるなど、相当な盛り上がりぶりでした!

JS界隈の盛り上がりやエンジニアの勉強意欲の高さを改めて感じましたね!

再始動にあたるご挨拶をufotsuboiさんに行ってもらいました!

かつてのOrganizerの方が五反田を離れられたのをきっかけに運営が止まってしまっていたのですが、今回約1年ぶりの復活となりました!

LT大会

ここから先はメインプログラムであるLTの実施が続きました!

JS周りのフレームワークやインフラとの兼ね合いについて、自社での取り組みや開発において気づいたことなどを思い思い発表していきました!

(それぞれのLTの簡単な内容は、モバイルファクトリーさんのテックブログで書いてくれておりますので、そちらをご覧ください!)

tech.mobilefactory.jp

LTを聞いて&懇親会でいろんなエンジニアの方の話を聞いての感想なのですが、GatsubyやNuxt.js, Next.jsなどのSSR(サーバサイドレンダリング)周りの話が非常に多かったと感じました!

プロダクトやサービスによってはSEOが非常に重要な要素になっていて、使っているフロントエンドのフレームワークがReactだと、サーバサイドでJSがレンダリングされずGoogleのクローラーがページを上手く読み込んでくれない...

medium.com

そのような背景もありつつ、SSRに迂闊に手を出すとコードが複雑になり開発工数が増大になるという悩ましさがあるため、SSR界隈は独自の盛り上がりを見せているなと感じました。

それ以外にはAWS(CDK)やDockerなど、低レイヤーな領域を絡めた話も多かった印象です!

JS周りはトレンドの移り変わりが本当に激しいので、こういったイベントに参加して最新のトレンドをキャッチアップするのはすごく重要なことだと改めて感じまいした!(もっとJS書こう...)

続きを読む

ZEALSのSlack Public率を覗いてみたら結構おもしろかった件

f:id:zeals-engineer:20190426201205p:plain

はじめに

エンジニアチームの味わい深い領域を担当しているKodyです!
タイトルにもありますが、弊社SlackAnalyticsが激動すぎて面白かったので記事にしてみました...!!

以前SmartHR宮田さんSlackPublic率に関するツイート↓を見かけ、「なんて素敵なんだ...」と感じました。
それがきっかけで、SlackのAnalyticsを覗いてみることにしました!

ちなみにSmartHR社ではDM禁止、Privateチャンネル禁止みたいなルールで縛ることはやっていません。

この「ルールにしない」というところが、実にイケてますね!

shr_miyata_tweet_slack

オープンな文化がもたらす良い効果

「オープンな文化がもたらすいい効果」について、大きい効果が2点あると思ってます!

  1. 情報格差が起こりにくい
  2. 自然と建設的なコミュニケーションの取り方になる
情報格差が起こりにくい

Aさんは知ってるけどBさんCさんは知らないことがある事で

A「〇〇についてだけど...」 B・C「え、なんですかそれ?知らなかったです...」 A「あぁ、それはね....」

などというコミュニケーションが随所で生まれてしまいます。
不必要なコミュニケーションが生まれ、事業&開発スピードに影響が出てしまいます。

自然と建設的なコミュニケーションの取り方になる

publicな場所で誹謗中傷が起こらないなど、お互い気持ちいのいいコミュニケーションが促進されます。
誰に見られても恥ずかしくないようなコミュニケーションを、メンバーが自然と取るようになります。

ZEALSのSlackAnalyticsを見てみました

さて、それでは実際のZEALSのSlackの状況を見ていきましょう!

zeals_slack_public]

...移り変わりが激しいですね...笑
Active User の変遷は↓こんな感じです。

zeals_slack_active_user

大きく3つの動きが見受けられました!

ざっくり時期ごとに分けると、こんな感じで3つに大別できます。
時期ごとに詳しく見ていきましょう!

age_of_slack_pub_rate

秘密結社時代[ActiveUser:10名程度]

age_of_secret_company

ほぼ全てのやりとりがDMですね!
当時のZEALSは秘密結社か何かだったのでしょうか...笑

僕自身がこの時期にいなかったため推測ですが、

  • Slackって何?状態でとりあえず使っていた
  • 平均年齢がLINE文化世代なので必然とLINEのような使い方になっていた

というのが、DM率が高かった原因ではないでしょうか?

激動時代[ActiveUser:50名程度]

age_of_very_move

激しく人数が増え始めた時期ですね!
私自身この時期の後半にZEALSにジョインしました!

メンバーが増えてきたため、社内コミュニケーションの透明性に課題が生まれたのがこの時期だったと記憶しています。
この時期の後半には、ZEALSのValueの制定などもあり、オープンなコミュニケーションが文化として根付き始めました!

文化として根付かせるのは非常に難しいのですが、オープンな文化のメリットを説き続ける「味わい深い」ことができる人がいると進めやすいです。

安定時代[ActiveUser:70~80名]

age_of_stable

どんどんオープンな方向へと向かっていますね!
メンバーが増えているにも関わらずオープンになっているのは、文化として根付いた証ではないでしょうか?

個人的には、もう少しDMの割合下げていきたいと思っています!
今後もZEALSのオープンな文化を作っていくために、引き続き頑張っていきます!

大事なのは「変化する事」

改めてですが、SmartHRさんの例、本当に素晴らしいと思います!
(なかなか真似できないと思いますが...笑)

初めから理想形で運用できていれば良いのですが、全ての組織ですぐに実行するのは難しいのではないでしょうか。

理由は簡単で、「僕たちが人間だから」です!

完全無欠のロボットではなく人間なので、間違いは必ずと言っていいほど起こります。
なので、間違いがあったとしても組織としていい方向へ「変化」する事が大事だと思います。

ZEALSの例でいうと、よくない状況を着実に改善し続け「変わることができた」のではないかなと思っています!

行動の軸となる ZEALSのValue

変化しようと思ってはいても、なかなかうまく行動できないことがあるかもしれません。

そんな時は、行動の「」となるものがあると、メンバーレベルでの意思決定で統率が取れ、チーム一丸となることができると感じています。

ZEALSの行動指針であるValueの1つに「United Will」というものがあり、「時と志を共にする」とう意味を持っています。
(= 志を一つにすること。チーム全体のことを考え、行動すること。)

Slackの使い方が改善されたのも、メンバー1人1人がチームを良いものにしようと動き続け、Valueを軸に行動できた結果だと思います。

今回のように、組織全体で一丸となって改善し合えるのがZEALSの大きな魅力のひとつと言えます!!

さいごに

チームでSlackを使っていて気になった方は、ぜひSlack Analyticsを見てみるのをお勧めします。
チーム力改善のヒントが見つかるかもしれません。

もちろんSlackPublic率が組織としてのオープンさの全てを表すものではないので注意すべきですね。 ただ、よほどセンシティブな情報以外はオープンにすべきだと思います。

papix.hatenadiary.jp

続きを読む

ZEALSではリーダブルコード読書会を実施しています

f:id:zeals-engineer:20190424155226p:plain

こんにちは!
Railsエンジニアのtakakudaです。

今回はエンジニアチームで取り組んだリーダブルコード読書会についてご紹介します!

目的

  • 理解しやすいコードとは何かを知り[to know what is "readable" code like]
  • 実際にそのようなコードを書けるようになることで[and to learn how to write "readable" code]
  • 今後の開発効率を向上させ、バグや障害の発生を削減する[aiming to improve develepment productivity and reduce software bugs and system troubles]

以上のことを目的として、今回の読書会を実施しました。

実はこのリーダブルコードの読書会は3回目で、最初は「またやるの?」という気持ちでしたが、新しい発見がたくさんありました。

やはり『リーダブルコードは』何度読んでも良い名著ですね…。
自分のコードの質が上がったのではないかと感じています!

内容

読書会ですが、以下のような流れで進めました。

1. 座学

リーダブルコードを3章区切りで読みます。
読んだことがある人は、再度読み直します。

2. プルリク作成

リーダブルコードを参考に、改善できそうなコードを見つけてプルリクを作成します。

その際にセルフレビューのコメントで、

  • リーダブルコードのどの章を参考にしたか
  • 質問(ex..このように改善したが、もっと良い書き方はあるか?)
    を追記していきます。

3. ピアレビュー

自分以外の参加者のプルリクを、1人2つ以上レビューします。

レビューの際は

  • 良いと思った点
  • こうしたほうが良いと思った点
  • 質問
    をコメントとして追記します。

4. 議論・講評

  • 1 ~ 3が終わったら全員で顔を合わせるタイミングを作り、議論をします

f:id:zeals-engineer:20190419202758j:plain

講評

  • コードオーナーが全体を通して気づいたことを話す

質問

  • 直接プルリクに記載はなかったが、聞きたいことを質問する

議論

リーダブルコードに書いてある内容で、プロダクトコードに合わせて読み替えたほうが良い点などを話し合う

結果

この読書会は任意参加なのですが、ほぼ全員のメンバーが参加し、プルリクを送りあってくれています。

この取り組みはCTO自らが中心となり推し進めており、ZEALSでは3回目の実施となります。
初回から参加していたメンバーが、教えてもらっていた立場から教える立場へと変わっていく...、という良いサイクルが回っていて、とても良い文化だなと感じています。

ちなみに

実際に参加したメンバーからも良い反応をもらいました!

続きを読む

【初心者向け】fish shellの入れ方と、rbenvではまっている話

f:id:zeals-engineer:20190411141958p:plain

こんにちは!
インターンから新卒で入社した、サーバサイドエンジニアのkanacchiです。

突然ですが、新卒や新たな環境で働くことになったエンジニアの皆さん。
社用PCが供給されてまずはじめに行うことありますよね。

そう、環境構築です。

かく言う僕も先日環境構築を行ったわけですが、その際新たにfishshellを使うことにしたので、今回はfish shellの紹介とハマったポイントなどを残していければと思います。

※注)所々でsudo対応を連発したところ、ことあるごとにpermission errorが出るようになってしまいました。(現に今もsudoで臨時対応してます、、)
この記事を見ている人は安易にsudoを連発せず、コマンドが通らない場合はきちんと原因を解決してから進んだほうが後々楽になると思います(自戒の念を込めて)

fishのinstallにあたって、大まかにはこちらの記事を参考にさせてもらいました。

dev.classmethod.jp

fishって何?

"friendly interactive shell"の略でshellの1つです。
fishのいいところは沢山ありますが、僕がおすすめしたい点は3つです。

①ターミナルがかっこいい

無駄のない、シンプルなターミナルがデフォルトです。

~ >

そして僕のターミナルはこんな感じで、左にrubyのバージョンを表示させてます。

スクリーンショット 2019-04-09 21.26.51.png

ディレクトリを移動するとこう表示されます。
緑の部分は現在のブランチです。

スクリーンショット 2019-04-09 21.27.10.png

そしてそのテーマ設定などをブラウザで扱えます。

$ fish_config

スクリーンショット 2019-04-09 21.16.58.png

② 構文エラーがわかりやすい

無効なコマンドと有効なコマンドをわかりやすく表示してくれます。

無効なコマンド

スクリーンショット 2019-04-09 21.14.53.png

有効なコマンド

スクリーンショット 2019-04-09 21.15.05.png

③コマンドの補完機能が優れている

一度打ったコマンドを学習し、コマンドを補完してくれます。
(右側にグレーで表示されます)

スクリーンショット 2019-04-09 22.15.39.png

fishをインストール

それではまず、fishをインストールしていきます。
Homebrewを使ってfishをインストールしましょう。

$ brew install fish

インストール後はfishコマンドが使えるようになります。

$ fish -v
fish, version 3.0.2

次にデフォルトshellをfishするために、shellファイルを編集します。

$ sudo vi /etc/shells
.
.
.
/bin/zsh
/usr/local/bin/fish ← この一行を追加します。

そしてfishをデフォルトshellに変更します。

$ chsh -s /usr/local/bin/fish

fishermanというfish用のパッケージマネージャーをインストールします。
これはrbenvのパス設定をするためのものです。

$ curl -Lo ~/.config/fish/functions/fisher.fish --create-dirs git.io/fisher

fishermanをインストールすることで、 fisherコマンドが使えるようになります。

$ fisher -v

テーマ設定

次にテーマ設定をします。

まずtheme-bobthefishをインストールしましょう。
theme-bobthefishはoh-my-fishというパッケージマネージャー用のテーマです。

(※参考にした記事では fisher install となっていますが、version3以降はinstall → add にコマンドが変更されました。)

$ fisher add oh-my-fish/theme-bobthefish

多くのテーマはデフォルトで入っているのフォントで対応できないのでpowerlineをインストールします。

$ git clone https://github.com/powerline/fonts.git --depth=1

$ cd fonts

$ ./install.sh

設定 → フォント → 「Powerline」とついたフォントの中から、好きなものを選択してください。

f:id:zeals-engineer:20190410094255p:plain

プラグインをインストール

僕のおすすめのプラグインはfisher zコマンドです。

$ z (フォルダ名)

で一発でそのフォルダに移動します。
インストールも簡単です。

$ fisher add z

こちらの記事で、おすすめプラグインをまとめてくれています。

futurismo.biz

fishでrbenvを使えるようにする

(※Ruby/Rails使う人向けです。)

fishはconfigファイルの場所がbash,zshと異なります。
pathの通し方は調べてみると色々出てくるのですが、僕が参考にしたのはこちらの記事です。

tech-1natsu.hatenablog.com

最初に rbenvをインストールします。

$ brew install rbenv
$ brew install rbenv ruby-build

次にrbenv pathを通します。
fish.confingを置くディレクトリまで移動します。

$ cd ~/.config/fish/

fish.configがあればそこに、なければ作成してpathを記述します。

$ touch fish.config

$ vi fish.config

以下を記述します。

# rbenv
set -x PATH $HOME/.rbenv/bin $PATH
status --is-interactive; and source (rbenv init -|psub)
.
.
.

sourceコマンドで読み込みます。

$ source ~/.fish.profile

あとは、通常のrbenvのフローと同じです。
(ZEALSでは現在ruby 2.4.1を使っています。)

$ rbenv install 2.4.1
$ rbenv local 2.4.1
$ gem install bundler

実は、ここでなぜかpermissionエラーがでてしまいました。

ERROR: While executing gem ... (Errno::EACCES)
Permission denied @ rb_sysopen - ....

sudo使いまくった

(※ここから先は直接fishと関係ありません)

エラーの対応として、

$ sudo gem install bundler

を使うとエラーが出ず通ったのですが、以降はコマンドを使う際にほとんどpermission errorが出るようになってしまいました。

原因はroot userで無理やり gem install bundlerを行ったことだと考え、./.rbenv/versions配下になるファイルの権限を全て変更してもうまくいきません...
結局半日ぐらいかけても解決策が見つからなかったので、渋々sudoを使い続けることになりました。

続きを読む

【後編】元ドリコム/現メルカリの白石さんと語る、ZEALSコアテクノロジー対談

f:id:zeals-engineer:20190327005551j:plain

皆さんこんにちは!
ZEALSVPoE兼エンジニアの福本です!

こちらの記事は前編に引き続き、【後編】元ドリコム/現メルカリの白石さんと語る、ZEALSコアテクノロジー対談です。

後編では「ZEALSの文化」や「組織の雰囲気」などを中心にお話させていただきましたので、その対談の模様をお届け致します。

ちなみに、対談の前編記事はこちらになりますので、合わせてお読みください!

tech.zeals.co.jp

  • ZEALS組織の技術的な強み
    • 「間違いなくNo.1のプロダクトです」
    • パイオニアとして、素早いリリースを
  • どんなチームで開発しているのか?
    • VisionやValueが浸透している
    • 強い成長欲と裁量の大きさがある
    • 複数言語での開発に挑戦しやすい
  • 働くメンバーの思い
    • 多様性のあるエンジニア組織
    • どんな思いで開発しているか
続きを読む

【前編】元ドリコム/現メルカリの白石さんと語る、ZEALSコアテクノロジー対談

f:id:zeals-engineer:20190327002352j:plain

皆さんこんにちは!
ZEALSのVPoE兼エンジニア福本です! 

今回は、テクノロジーお師匠さんとしてZEALSにジョインして頂いている元ドリコム技術執行役員/現メルカリの白石さんを聞き手としてお招きし、プロダクト開発で用いているコア技術やエンジニア組織について、対談形式で語って頂きました!

tech.zeals.co.jp

どんな技術を用いてどうプロダクトを開発したか、どんなエンジニアがどんな思いで開発しているかetc...

今まであまりお伝えすることのなかった内容ですが、皆さんにZEALSのことをもっと知っていただきたかったため、今回の対談を行うに至りました!

その対談の様子を、テックブログの記事で皆さまにお伝えさせていただきます!

  • 関係者
  • なぜZEALSにジョインしたのか?
    • CTO島田とCEO清水との出会い
    • 小寺「ZEALSは楽しい」と聞いてジョインしました
  • ZEALS開発組織の”良さ”とは?
    • 「守るべきライン」を守る
    • 自ら課題を解決する姿勢を
    • ZEALSには”良い人”が多い
  • 過去の開発からの学び
    • DjangoからRailsにリプレース
    • 反省をプロダクト開発に活かす
  • ZEALSチームの技術的な”強み”とは?
    • 「テストをしっかり書く」を当たり前に
    • 意識して「自然とフルスタックになる」組織を
    • 技術的負債への取り組み
    • 前編はここまで

関係者

 株式会社ZEALS CTO 島田想

東京都出身。株式会社ZEALS CTO。同社創業時よりプロダクト開発に携わり、世界初の会話広告サービスfanpを開発。LINEやFacebook社の提供するMessaging API Platformを公開当初より叩き続けており、Facebook MessengerについてはMessaging APIを国内で最も多く叩いているであろう人間の一人。チャットボット以外にも、会話インターフェースであるVUIのアプリ開発にも知見がある。


株式会社ZEALS  リードエンジニア 小寺京祐

東京都出身。日本大学理工学部卒。前職の渋谷ICT教育ベンチャーではコース責任者 兼 Railsエンジニアとしてカリキュラム設計・講義運用・オンライン学習プラットフォームの開発など幅広く担当。2017年9月からZEALSへJOIN。開発チームの文化醸成・制度整備などに尽力。現在、チームリーダーとしてプロダクト「fanp」のプロジェクト管理・エンジニアチームのマネジメント、採用まで幅広い業務を管掌している。

(聞き手)元ドリコム技術執行役員/現メルカリ 白石 久彦

大学卒業後、さまざまなBtoB、BtoCのサービスやインターネットインフラ構築のプロジェクトに携わる。ソフトバンクグループ、 株式会社レコチョク等を経て、2012年ドリコムに入社、2014年には技術担当執行役員に就任。2018年より株式会社メルカリに参画、テックカンパニーを目指す同社のエンジニア組織の強化を担当。並行して株式会社スライストーンを創業、株式会社ZEALSを始めスタートアップから上場企業まで複数社の技術アドバイザーを務めている。

なぜZEALSにジョインしたのか?

CTO島田とCEO清水との出会い

白石:今日はよろしくお願いします。2人がどんな役割を担っているのか、簡単に紹介してもらえると。まず島田さんから。

島田:僕は創業当初からCTOをやっていて、去年一昨年は採用周りや組織のビルディングをやっていました。その頃、白石さんにお会いしました。

白石:確か1年以上前だよね。「ドリコムに遊びに来てよ」という感じで、コミュニケーション取り始めたのが最初で。

島田:はい、そうでしたね。

白石:島田さんは創業時からCTOだけど、マサさん(注:代表の清水)と会ったきっかけは?

島田大学が一緒で出席番号順で前と後ろになったんです。当時から「コイツ(清水)むちゃくちゃだな」と思っていて(笑)、気がついたら手伝うことになってました。

小寺「ZEALSは楽しい」と聞いてジョインしました

白石:なるほど。コディ(注:小寺)はどんな感じでZEALSに携わったんだっけ?

小寺僕は以前はプログラミング教育の講師でした。そこの先輩エンジニアが元々ZEALSでやっていて...

白石:紹介された?

小寺そうです。僕が前職でくすぶり始めたときに、相談して「ZEALS来なよ、楽しいから」っていう話で。

白石じゃあ、マサさんもコディもくすぶるとこから始まってるんだね。

小寺:そういえば、僕は島田さんがCTOになった経緯を知らないんですけど...

島田:ZEALSがWebの受託開発を始めて、そこから徐々に中心的に開発をやるようになったのがきっかけでしたね。

白石最初は何で開発してたの?Rubyとか?

島田最初はPHPです。Wordpressとかですね。

ZEALS開発組織の”良さ”とは?

「守るべきライン」を守る

白石コディは最初からエンジニアとしてジョインしたけど、今は役割的にはどんなことをやってるの?

小寺僕は今、開発部全体のマネジメントをしています。一般的な言い方だと、プロジェクト管理に近いですね。メンバーにタスクを渡す見積りなどは僕がやっています。

tech.zeals.co.jp

白石なるほど。島田さんが技術選定で、コディがプロジェクトという感じに役割が分かれているんだね。

島田そうですね。そこはしっかり分けています。

白石:コディは、ZEALSにジョインした当初の技術レベルはどうだったの?

島田:小寺が入ってきた時はRuby、正確に言うとRailsが書ける人とは聞いてたんですけど、期待値よりは書けていた印象ですね。

白石:なるほど、一方コディはジョインしてZEALSに対してどう感じたの?

小寺コードレビューをすごいしっかりやってる、と感じました。自分たちだけで完結しないところは、業務委託の方にも協力を仰ぎながら。

白石:開発チームは既にそれなりの人数のエンジニアが居たんだよね?

小寺:はい。そんな中でも構文とかはもちろん、守るべきクオリティをしっかりと保つんだという意識がすごい見えました。

自ら課題を解決する姿勢を

白石:それで今、コディは組織のマネジメントをジョインして1年位でやるようになったけど、どういう経緯でそうなったの?

小寺:細かい話なんですけど、Slackの使い方やDocbaseの使い方とか、整備されてない部分が多かったんです。そこに勝手に課題感を持って、ゴリゴリと整備しました。

qiita.com

白石:環境を整えることを考えて進めた、という感じ。

小寺:主体的に自分で動き続けた結果、という感じですね。

白石:そういうのを見て、島田さんは何か思った?

島田:「ありがてえ...」と(笑)

白石:「めんどくさい人が入ってきた」とは思わず?(笑)

島田:はい(笑)

白石:全然整備されていない状況に対して、コディはどう考えて進めていったの?

小寺:僕が前職でそういった部分をしっかりと教えられていたので、そういった部分で貢献できればいいなと...

白石:なるほど、コディは教えたり整えたりと面倒見のいい感じなんだね。

小寺:そうですね、お節介な所はあります。

ZEALSには”良い人”が多い

f:id:zeals-engineer:20190327004419j:plain

白石:じゃあ、島田さんはそういう細かい部分は気にならないタイプなの?

島田:どちらかと言えば、プロダクトに集中したいタイプですね。

白石:良く言えば、役割がそこでいい感じに分かれているんだね。

小寺:僕はそこも含めて、会社をよくできる余地がたくさんあると感じる方の人ですね。

白石:そもそも、コディはZEALSのどこに惹かれたの?

小寺人が良いところです。本当に良い人が集まってて、偏屈な人がいないので...

島田:それはそうですね、素直な人が多いですね。

白石:なるほど、なるほど。

小寺:社長の人柄もあるかもしれませんが、すごく良い人が集まっている組織だと感じました。

過去の開発からの学び

DjangoからRailsにリプレース

白石:ちなみだけど、『fanp』プロダクトの技術は今も昔と同じものを使ってるの?今は会話を作る管理画面がReact + Railsで、会話の送受信がPython、インフラがMicrosoft Azureだよね。

小寺:いや、昔は違いました。

島田昔はすべてPythonだけで、フレームワークはDjangoを使ってましたね。

qiita.com

白石:DjangoからRailsに変えた経緯は何だったの?

島田:スキーマが最適化されていなかったりとか、アーキテクチャ周りでアンチパターンな部分が多くなっていたので...

白石:プロトタイプでサービスインして、その後すぐ作り替えようと。

島田:そうです。

小寺:僕がそのリプレースが始まって4ヶ月あたりでジョインしたんです。

白石:そのリプレースでRails化するのに携わったと。

小寺:そうです。設計は決まっていたので、タスク量だけは膨大でした(笑)

反省をプロダクト開発に活かす

白石:なるほど(笑)フロントエンドは最初からReactで開発する方針だったの?

小寺:はい、リプレースのタイミングからReactで開発することを既に決めていました。

島田管理画面とボットが密結合じゃないようにしたい、という思いがありました。管理画面が落ちたと同時にボットも停止するとなれば、それは最悪じゃないですか。

白石:確かにね。Djangoで作った時は、全部一枚岩だったんですね。

島田:はい。その時の反省を活かして、疎結合に各パーツがモジュールとして動くようなイメージにしています。ゆくゆくはマイクロサービス化したいなと。

白石:今もメッセージの送受信機能をPythonで書いているけど、そういった経緯もあってRailsと共存している珍しいアーキテクチャになっているんだね。

島田:そうですね、何でもかんでもリプレースするのではなく、既存のPython資産を活用したほうが効率が良いと判断しました。

ZEALSチームの技術的な”強み”とは?

「テストをしっかり書く」を当たり前に

白石:その頃と比較して、技術的に良くなったと感じる部分はありますか?

島田:当たり前の話かもしれないんですけど、「テストをしっかり書くようになった」というのはすごく大事だと思ってます。

白石:そうなんだ。それは雰囲気的に?

島田:はい。明文化しなくても「テスト書いてね」という雰囲気があったんですよ。

小寺:明らかにバグが多い時期があって、リグレッションしてる時間が基準値を越えたとわかったので、そこからはテストを書こう、テストケースをきちんと決めようと意識づけました。

島田:「コメント入れましょう」とかも、細かいですけどちゃんとやってますね。

意識して「自然とフルスタックになる」組織を

白石:さっきPythonからReact/Railsまで話が広がったけど、チームの中でいわゆるフルスタックというか、PythonとReactとRailsを複数書けるエンジニアは結構いるの?

島田:基本は各技術スタックで分かれてるメンバーが多いですが、React/Rails書けるメンバーも2,3人居ますね。

小寺:RailsとPython書けるパターンは僕が最初ですね。そのうちReactも書けるようになりました。

白石:最初がコディだったんだね。だんだんそういう人が増えてって...

小寺:そうです。今度はAaronがPythonも書いて...

www.wantedly.com

白石:結構意識して技術の幅を広げてけるようにしているんだね。

小寺:そうですね。「やったことないけどやろう」みたいな...

白石:その方が会社にとっても層が分厚くなるもんね。

技術的負債への取り組み

白石:ところで、リファクタ要員みたいな役割のエンジニアは居るの?

小寺:居ますね。リファクタリング好きな人は結構多いので。

島田:ZEALSでは、インターンの子でもリファクタリングをゴリゴリ進めてたりします。

白石:リファクタリングする時も、当然コードレビューするんだよね?

小寺:もちろんします。コードオーナー制を採用していて、各リポジトリごとに設定しています。

help.github.com

白石:なるほど。メインでコードを見る人、つまりオーナーがいるんだね。

小寺:そうです。オーナーがいて、その人からのApproveは確実に貰うということをやっています。ただ、一部のリポジトリやファイルに関しては、コードオーナーが忙しくなるとレビューが止まるということが起きてしまって。

白石:うんうん、リアルな話だね。

小寺:そういう声が多い箇所だけは、「リポジトリに関連する開発スキルを持つエンジニアから2人以上Approve貰えればマージできる」というルールにしました。その辺りは柔軟にやっています。

島田:一般的な正論から良いものを取り入れて、合わない・悪いものは使わないという工夫をしっかりやっています。

続きを読む