ZEALS TECH BLOG

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

復活の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貰えればマージできる」というルールにしました。その辺りは柔軟にやっています。

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

続きを読む

復活したGotanda.rbに参加&登壇してきました!

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

こんにちは、ZEALSでサーバーサイドエンジニアをやっております、あべです!
今回のブログは先日行われたGotanda.rb のイベントについてお伝えしたいと思います。

github.com

Gotanda.rbって?

有名な『Asakusa.rb』や、以前サーバサイドエンジニアのRyutoooooが記事を書いてくれた『Omotesando.rb』など、各地域にRubyコミュニティがありますが、実は五反田にもRubyコミュニティがあります!

tech.zeals.co.jp

正確に言うと、「あった」のですが、コミュニティを立ち上げたOrganizerの方が転職し五反田から離れてしまった、という理由からしばらく運営されておりませんでした。

復活のきっかけは、記事にある『Omotesando.rb』でした。

五反田界隈の方とお会いし、そこで意気投合。
Gotanda.rbのOrganizerを引き受けたトレタの中村さんとつながり、そこから再度立ち上げたという次第です!

今回のテーマは設計!

さて、そんなこんなで2019年3月20日に見事復活を果たしたGotanda.rb、個人的な感想になりますが参加してよかったです!!

今回のテーマは「〜設計について気軽に話そう〜」だったのですが、普段他社の設計の話ってそう気軽に聞けるものじゃないですよね。
その設計の話を、生々しく、時に楽しく、飛び込みLTありのゆるい雰囲気の中たっぷり聞けたのがとてもよかった、と感じました。

この「生々しい話」というのがGotanda.rbのコアなテーマになっていてます。
「正論だけではない、開発現場のあるある」な共感できる話が多いのが特長でした。

全体の雰囲気などはTogetterにもまとまってますので、ぜひ見てください!

togetter.com

前半戦:LT大会!

ZEALSの登壇

まずZEALSの福本がスタートアップにおけるRails開発のツラみ〜なぜ僕たちはRails wayを貫けないのかというテーマで登壇致しました!

speakerdeck.com

スタートアップでリソースが足りない中で小さな工夫をどう重ねていくか、ZEALS内で実際取り組んでいる例を含めて紹介しました。

この内容には含まれていませんでしたが、LTで少し話に出た「ServiceClass」というワードがこのあと一つ大きなテーマになっていました!
ZEALSにもServiceClassは存在しておりますが、やはり会社によって経緯や運用の仕方が違うこと、会社によって良し悪しも180度違っていると感じました。

ServiceClassについてどんな話があったか

  • 行数がやばい一つのファイルをServiceClassとユースケースに切り分けてみたら処理が明確になった
  • ServiceClassを実装したらコードもテストもスッキリしていろんなだるいがなくなった
  • 一人で作り上げたServiceClassが、作った本人にしかわからないやばいServiceClassになってしまっている
  • あとから違う人が作業しようと思っても何をどこにどうやって変更したらいいかわからない…

…など会社によってServiceClassのあり方にかなりの違いがあるようでした。
「じゃあ結局その差はなんなのか?」という話をdelyのjoeさんが飛び込みでLTをされていました。

結論:作っても良いけどルールがないサービスクラスはダメ

ServiceClassをどう作ってどう運用していくか、きちんと決めていくのが重要ということでした。

一方、実際チームでルール作ってちゃんと運用していくのはかなり難しそうだとも感じました。
うまくルールが作られ、良いServiceClassとして運用を心がけているLTに改めて感心しました。

後半戦:実際のプロダクションコードを見ながらの設計相談会

今回参加する前に聞いていてかなり楽しみにしていたトレタのプロダクションコードを見ながら聞けるLT
もちろん写真を載せることはできないのですが、実際にコードを見ながら質問に答えていく形式のLTで非常に盛り上がっていました!

プロダクトが育ってきた歴史を、設計周りやコメントから感じました。
私たちのプロダクト『fanp』は今の形になってから約1年半なのですが、トレタは6年と年季が入っていて、あらゆることが一筋縄で行かなくなるのだな、と感じました。

お話を聞いていた中で、個人的に特に興味を持った部分はデータ分析の話でした。

プロダクトを育てていく過程で、データ分析専門の部隊ができたらどんなことをやるべきなのか。
また、どんなテーブルにどんなデータを保存すればいいのか、何千万件もレコードがあるテーブルに変更を加えるときどうしたらいんだろう、など実際悩んだこともあったので色々と考える機会になりました。

やはり実際のプロダクトコードとのことで、みなさん時間ギリギリまで質問されていました!

さいごに

繰り返しになりますが、参加してよかったです!!

続きを読む