App Maker 触ってみた

こんにちは、データマーケター?の嘉松です。

データ活用推進室というチーム(1人なう)で、MAツールの導入から運用といったCRMの推進と、データ活用の推進や業務を効率化するためのツール作成など、現場に近い立ち位置で業務を行っています。

背景

社内のG Suiteが、Businessにアップグレードされたことで、App Makerを無料で利用することができるようになった。

目的

無料で利用できるApp Makerを使わないのはもったいない。
もったいないおばけが出る前に、

  • App Maker、どんな感じで使えるのか?
  • そのためには、どんなスキルセットが必要か? 

を、そこはかとなく捉えること。

Google App Maker とは

App MakerはGoogleが提供するとっても簡単にWebアプリケーションを開発することができるプラットフォーム。

ドラッグ&ドロップなどの操作で、Web上にフォームやテーブルなどのインターフェース、データベースを作ることで、Webアプリケーションとして公開することができる。

「非エンジニア職のビジネスマンにとってITスキルを磨く超ステキなきっかけの一つになるだろう」との意見も。

ExcelAccessVBAの代替手段になり得る。

App MakerのベースはGoogle Apps Script(GAS)

App Makerの特徴

HTML&CSSの知識が不要

ドラッグ&ドロップでページとUIを簡単に作れる。

Googleサービスとの連携

App MakerはベースはGASなので、様々なGoogleサービスとガッツリ連携可能。

データベースの作成が簡単

本格的なデータベースをクリックベースでGoogleドライブまたはGCP内に作成できる。

無料で強固なサーバーに設置できる

G Suite Business以上のユーザーであれば追加料金なしで利用可能。

サーバーの準備は全く不要。

App Makerの入り口

App Maker HOME

developers.google.com

Google Developers

appmaker.google.com

アプリ、作ってみた

作ったアプリ

ランニング計算機

1キロのペース(○分○秒)を入力すると、フルマラソンの完走タイムを計算してくれるアプリ。

f:id:enigmo7:20191209170733p:plain

ランニング計算機

作った感想

  • テキストボックス、ボタン、ラベルなどの作成は、パーツ(Widgets)から作りたいパーツを選んで配置するだけ(ドラックアンドドロップ)なので、スーパー簡単。

パーツの一覧

f:id:enigmo7:20191209170936p:plain

  • 処理、このアプリの場合はボタンを押した時の計算処理は、下のようなウィンドウ内のエディタにGASで記載する。このエディタの使いっぷりが良くない。ウィンドウ、小さいし。 

f:id:enigmo7:20191209171034p:plain

  • UIの見栄え(デザイン)は、基本的には最小限の変更しかできない。ガッツリ見栄えを良くしたいなら、CSSを使えばできる。

まとめ

  • G Suite Businessで無料で使えるApp Maker、どんなものかと触ってみた。
  • UIの作成は、パーツの一覧からドラック&ドロップするだけなので超簡単。
  • 実行したい処理はGASで記述が必要なので、普通にプログラミングが必要。
  • UIの見栄えのカスタマイズは最小限。その範囲だと結構ショボい。CSSでリッチにできるけど、そうすると本末転倒か?
  • App Makerは、G SuiteのBasicからBusinessにアップグレードすることで利用できる数少ないサービス。
  • Googleさんもきっと力を入れて、より一層使いやすくなってくると思う。
  • ということで、今後の進化に期待!!

株式会社エニグモ 正社員の求人一覧

hrmos.co

3年放置してた_variables.scssを整理したよー。

こんにちは、デザイナーの本田 です。 この記事はEnigmo Advent Calendar 2019 の2日目の記事です。

今日はエニグモが運営しているファッションメディアSTYLE HAUS の色管理方法について紹介していきます。

放置されていた_variables.scss

Sassファイルの中で重要な_variables.scssファイル。このファイルにデザインを管理する様々な変数を定義すれば、変数の値を編集するだけで全体的なデザインの更新ができるようになります。 ただ、最初に設計した後、放置されやすいのも事実です。

STYLE HAUS の開発はECサイトBUYMA の開発の空いた時間にちょこっと進めるスタイルなので、デザインの全体を見返すタイミングがなかなか作れず、3年ほど設計を見返せずにいました。

f:id:enigmo777:20191126205423p:plain
variable.scssを3年放置した図

また、変数も最初のうちは問題なかったのですが、繰り返し修正や変更があり、名前がわかりにくいものに。 メインカラーがピンクのサービスなのもあり、ピンクだけで9種類も増えていました。

$pink:         #d04589;
$pink-dark:    #c82676;
$pink-dark2:   #c3196d;
$light-pink:   #f5edf1;
$light-pink2:  #f2e2ea;
$light-pink3:  #f3dee8;
$light-pink4:  #f8f3f6;
$white-pink:   #FCF7FA;
$pink-neue:    #d77eaa;

ぱっと見では$light-pink4$white-pink の判別が・・・ とりあえず、色だけでも変数化すればサイト全体のデザイン見直しに役立つと思ったので、取り組みました。

やったこと

1. サイト上で使われている色の洗い出し

_variables.scssを使わない代わりに、カラーコードはベタ書きで運用していたため、実際に使われている色の洗い出しをしました。 全部で20色以上・・・あったのでこのあたりでストップ。

2. カラーパレットの作成

被ってしまう色がメインのピンクと無彩色だったので、2色のみ100〜900まで作成しました。

// Gray scheme
$color__white:     #ffffff;
$color__black:     #000000;

$color__gray--100: #f6f6f6;
$color__gray--200: #efefef;
$color__gray--300: #dddddd;
$color__gray--400: #bebebe;
$color__gray--500: #969696;
$color__gray--600: #888888;
$color__gray--700: #555555;
$color__gray--800: #3a3a3a;
$color__gray--900: #212121;

// Pink scheme
$color__pink--main:#dc4991;
$color__pink--100: #fcf7fa;
$color__pink--200: #faf6f8;
$color__pink--300: #f5edf1;
$color__pink--400: #f3dee8;
$color__pink--500: #feb4d5;
$color__pink--600: #d77eaa;
$color__pink--700: $color__pink--main;
$color__pink--800: #c3196d;

f:id:enigmo777:20191127100704p:plain
grayは綺麗なカラーパレットに。ピンクは無理やり作ったので若干バランスが...

3. 命名規則の統一

$red だけだと、どの赤なのかわからなくなるので、他の色も揃えました。 色自体はそのままですが、ソースコードを見たときに「カテゴリ指定の色が使われているんだな」ってことが伝わるようになると思います。

// Before
$beauty:     $pink;
$fashion:    $red;
$lifestyle:  #c2a20b;
$celeb:      $pink;
$children:   #d4669c;
$men:        #5a72c0;
$baby_kids:  #f07468;
// After
$category__beauty:   $color__pink--main;
$category__fashion:  #e82152;
$category__lifestyle:#c2a20b;
$category__children: #d4669c;
$category__men:      #5a72c0;
$category__baby_kids:#f07468;
$category__horoscope:#8765c5;

また、メインのカラーはいろんな場所で使いまわしているので、最初に使った変数を他でも利用すると関連性がぱっと見でわかるようになります。

$color__pink--main: #dc4991;
$color__pink--700:  $color__pink--main;
$category__beauty:  $color__pink--main;

4. 残す変数名を決める

2,で作ったカラーパレットは、全体のデザインを知っている場合は使いやすいのですが、アサインされたばかりの人やエンジニアからしたらどの色を使えばいいのかわかりづらいので、 わかりやすい変数名はそのまま残す方向にしました。

// Others
$pink:              $color__pink--main;
$pink-dark:         $color__pink--800;
$light-pink:        $color__pink--300;
$white-pink:        $color__pink--200;
$red:               $category__fashion;
$green:             #89d045;
$blue:              #4589d0;
$white:             $color--white;
$back-black:        $color__gray--800;
$light-gray:        rgba(239,239,239, 0.3);
$default:           $color__gray--800;
$text:              $color__gray--800;
$hr:                $color__gray--300;
$dark:              $color__gray--800;
$super-light:       $color__gray--200;

これをファイルの下に残すことで、「テキストってどの黒だっけ?800?900?」「ボーダーの色って何色だっけ?」と悩むことが少なくなるかなと思います。

5. ちょっとずつリファクタリング

あとはプロジェクト毎に少しずつリファクタリング・・・! ここのモチベーションを保つのは、結構むずかしいかなと思っていたのですが、 ソースレビューの際に、カラーコードをベタ書きしている箇所はレビュアーから指摘してもらえたので、毎回モチベーション高く取り組むことができました。

結果

_variables.scssに指定した色変数は38個あったのですが、全体を見直した結果49個になりました。 同じ色を重複して書いているので、実際の色自体は28と変化なしでした。

感想

プロジェクトにアサインされて、結構最初に取り組んだのですが サービス全体のデザイン理解にとても役立ちました。

最初にもうこれ以上色は増やさないぞ!!という気持ちで作ったので、UIを考えるときに、色について悩むことがなくなりました。 1回も使ってない色ももちろんあります。($color__pink--400 とか)

おそらく今後も使わないですが、この変数名を残すことによって$color__pink--300-2 とかめちゃくちゃな命名規則が発生しなくなると思うので残しています。

ソースコードからデザインデータまで徹底して整備すると、色だけじゃなくフォントや余白も統一したくなって、デザインデータもかなり整理することができました。

f:id:enigmo777:20191126215502p:plain
シンボル化されたデザインパーツ(Sketch)

参考URL

Sassの色管理方法について考えてみた | 株式会社インディバル

変更に強いSassの色管理プラクティス - Qiita

株式会社エニグモ 正社員の求人一覧

hrmos.co

OSS 初心者が初めてのコントリビューションを通して学んだ3つのこと

こんにちは、 サーバサイドエンジニアの伊藤です。

新卒Rubyエンジニアがオススメする実務で役にたった技術書5選 この記事を書いた時から、ちょうど1年が経ちました。 本当に、時が経つのは早いですねー。。。

そんなこんなで、今年もこの季節がやって来ました。12月と言えば、そうAdvent Calendar の時期ですね!!!

ということで、Enigmo Advent Calendar 2019 を公開します!!!

Enigmo Advent Calendar 2019 記念すべき1日目は、

私、伊藤が 「OSS 初心者が初めてのコントリビューションを通して学んだ3つのこと」 をお届けします。

そもそものきっかけ

弊社では、EC サイトのBUYMA だけではなくSTYLE HAUS というファッションメディアの開発も行なっています。

STYLE HAUS の開発時、記事パーツのアイコン画像をYaml で管理するため、zilkey/active_hash というgem を導入しました。

基本的には ActiveHash*1 を用いることで、スムーズに開発を行うことができました。 ただ、ActiveHash で生成したデータを、sort しようとした時ActiveHash::Base.order が存在しないことに気がついてしまいました。

確かに、ActiveHash を利用して生成したデータは Array なので、Enumerable#sort_by を用いることで、sort は可能です。

↓こんな感じ。

w/ Enumerable#sort_by
Image.all.sort_by(&:title)

ただ、RailsActiveRecord にどっぷりハマった身としては、どうしてもActiveHash::Base.order を使いたい。。。

↓こんな感じ。

w/ ActiveHash::Base.order
Image.order(:title)

そこで、隣の席の先輩エンジニアに相談してみました。

伊藤:
なんで、ActiveHash::Base.order ってないんですかねー? ActiveHash のREADME にもActiveRecord-like model って書いてあるのに。。。

隣の席の先輩エンジニア:
そんなの知らん。無ければ自分でメソッド生やしたらいいやん。

伊藤:
ヒィィィィィ(゚ロ゚;ノ)ノ

当時の私にはメソッドが無ければ自分で実装するとう言う発想はなく、 まさに青天の霹靂でした。

と言うわけで、

やったこと

  1. 本家 ActiveRecordorder メソッドの実装を読み込む。
  2. TDD を意識して、RSpec を実装する。
  3. (2) で実装したテストをパスさせるように、ActiveHash::Base.order を実装する。
  4. PR を作成する。
  5. 祈る。そして、待つ。

何だかんだ最初は OSS と聞いてビビっていましたが、 基本的にやった事はこれだけです。

パッチを投げてからActiveHash の戻り値を chainable にするため ActiveHash::Relation が導入されたので、 実際は(4)と(5) の間でレビューを受けてorder をcahinable に対応する処理を追加実装しました。

今回実装の内容は割愛しますが、ご興味のある方はこちらをご覧下さい。

github.com

学んだこと

ソースコードへの抵抗がなくなった。

恥ずかしながらこれが私にとって初めての OSS コントリビューションでした。*2

こちらで ActiveRecordソースコードをがっつり読み込むまでは、どちらかと言うとネットに落ちているブログ記事や公式ドキュメントを読むだけで終わっていました。 それで理解できなければ、先輩エンジニアのところに泣き込んでいました。。。*3

しかし、今回ソースコードを読み込んだ事で、ソースコードに対しての畏怖の念は無くなりました。 現在では公式ドキュメントはもちろん、それでも分からなければソースコードを読み本当の仕様を確認できるようになりました。

OSS への PR の出し方、所作を学ぶことができた。

PR のコメントの文面は OSS ごとに特有のものがあると思います。 すでに、当該の OSS でマージ・クローズされている PR のフォーマットを参考にしました。 内容に関しては、MECE を意識しました。*4

MECE とは、

  • Mutually(お互いに)
  • Exclusive(排他的に)
  • Collectively(集合的に)
  • Exhaustive(余すところのない)

要は、「内容に漏れがなく、重複がないように。」と言うことです。 レビューしてくれる方が実装内容および、 PR コメントを見ただけで全てが理解できるように意識しました。

OSS を身近に感じることができた。

以前は OSS コントリビューターさんやメンテナーさんは、雲の上の存在。 いや、むしろその存在すら意識していなかったかも知れません。。。

今まではどこかで OSS はあって当然のように思っていましたが、微力ながらのコントリビューションを通してその考えを新たにすることができました。

私たちが OSS の恩恵を受けられるのは、多くのコントリビューターさん、メンテナーさんのお陰なんだなぁと。

本当に感謝です。

今後も機会があれば微力ながら OSS に貢献していきたいと思います。

本日はこの辺で、 最後まで読んでいただきありがとうございます!

株式会社エニグモ 正社員の求人一覧

hrmos.co

*1:ActiveHash は、Ruby のHash をActiveRecord-like のモデルとして使用するためのbase class です。

*2:レビューを受けてマージされるまでの間に他の OSS に投げたパッチがマージされてしまいましたが。。。

*3:良くも悪くも弊社のエンジニアは良い方ばかりなので、基本的に質問すれば親切に教えてくれます。

*4:これに関しては一回の PR で学んだと言うよりは、いくつかの PR を経て学んだと言う感じですが。。。

エンジニアインタビュー 第5回 伊藤明大さん編

エニグモBUYMA の中のひとを知ってもらおうと、エンジニアへのインタビューをしてみました。
第5回は、2018年2月入社の検索エンジニア、伊藤明大(通称:めーだい)さんです。

インタビュアー
小澤:2011年4月入社。部長。
伊藤翔:2018年5月入社。新卒2年目。

interview01

職種は?

伊藤翔(以下、翔):
明大さんのポジションは、検索エンジニアですか? Webエンジニアですか?

伊藤明大(以下、明大):
検索エンジニアですかね、わかんないけど(笑)
Webエンジニアってのもよくわからないけど、検索をメインでやっているエンジニアですね。

前職は?

翔:
前職ではどんなことをやられていたんですか?

明大:
前職はSolrやElasticSearchを使った検索だけをやってました。
そのまえはFastっていう製品を使っていましたが、それからOSSに置き換えようという話になってSolrやElasticSearchを利用するようになりました。

翔:
大学卒業してからはずっとエンジニアをやられているんですか?

明大:
前職は2社目で、その前は新卒でSIerに入社してそこに10年ぐらいいました。

翔:
その時も検索を担当されていたんですか?

明大:
全然やってないです。どちらかというとインフラよりで、サーバーをラックに載せたり、ケーブル配線もしてました(笑)
本当になんでも屋みたいな感じでした。

小澤:
開発もしてたんですか?

明大:
開発は開発部隊が別にいたのでほとんどやってないです。お客さんと開発部隊の間を取り持つ窓口みたいな立場ですね。

小澤:
いわゆる「SE」ですね。

interview07

明大:
そうです、まさに「SE」でしたね。
開発部隊が作ったものをお客さんの環境にインストールするわけですよ。それようのツール作ったりとか、手順書を作ったりとか。
いまからは想像できないような作業内容ですね。
お客さんの環境で作業するときは、1人がオペレーター・作業するひとで、1人が手順書読み上げと、、、

小澤、翔:
読み上げ!!

翔:
読み上げっていうのはただ手順を読むんですか?

明大:
そう(笑)
基本的にはコピペ作業なんだけど、コピペしたことが手順書とあっているよね、っていう確認をして、その人が確認して「OK」っていったらオペレーターが「Enter」していいっていう手順ですね。
1年に2回しかリリース作業がないのですが、そこまでやる?っていう作業をしていました。

翔:
それを10年間やってたんですか?

明大:
そうなんだけど、6年目ぐらいかな、あまり進歩ないなと思って別のところを希望したんですよ。そしたらもっとひどい環境でした。
リリース間際のプロジェクトに開発のスペシャリストがくるっていう触れ込みで配属されてしまい、お客さんが期待していろいろ質問してくるんですが全くわからない。
これは地獄だと(笑)。ということで、もとの環境がよく見えて(笑)、戻って3年ぐらい過ごしました。
まあでもやっぱり違うなと思ってWeb業界に転職しました。

翔:
転職したときは検索に携わりたいと考えていたんですか?

明大:
いや全然(笑)
一番は自社サービスを持っている会社を希望していました。
それは1社目で感じたしがらみ、たとえばサーバーを導入するのもいいと思ったものじゃなくて会社が売りたいものを売る必要があるんですよ。
自社サービスだと自分でスペックも価格も考えていいものを選べるだろうなと考えました。
それと、1社目もWeb関連がやりたいと希望してできる部署に配属してもらいました。ですが、仕事がなさすぎて(笑)
配属されて5,6ヶ月仕事がなくて自習していました。そしたら別のところから仕事あるよって話がきたのでそこに行きました。

翔:
1回目の転職ではどういうことをするか決まって入社したんですか?

明大:
もともとは検索というよりはデータ、ビックデータが流行り始めた時期でやりたいなと思っていました。
それでHadoopとかを運用している部署で、そこに検索のチームもありました。それで入ったんですが、検索を担当している人が少なかったので自分が担当することになりました。
自分が希望して検索ってことではないです。それでもやったことがなかったのでやってみたかったです。

interview02

エニグモへの転職について

翔:
2社目からエニグモへ転職されたときの考えはなにかありますか?

明大:
2社目では検索しかできなくて飽きていました。それと、複数のサービスを持っている会社でしたが、各サービスからくる検索案件をさばくだけで終わっていたので、自分からこうしたいってことができていませんでした。
次はサービスに入り込んでサービス提案もできるようなところ、それと服が好きなのでファッションのサービスがいいなと思っていました。

翔:
たしかに、明大さんおしゃれですよね。

明大:
え、(笑)
ありがとう。

翔:
小澤さんと2大ファッショニスタ的な存在と思っていました(笑)

明大:
え、そうなの(笑)

小澤:
私も「服好きですよね」って聞くだけ聞いたことがありますね。
「調子乗って俺より上にでるんじゃねーぞ」って意味でね(笑)

入社後の印象

翔:
入社後の会社の印象はどうでしたか?

明大:
すごく自由だなと思いましたね。いい意味でね。あとはみんな若いなと思いましたね。
前の会社もエンジニアが依頼してくる部署なので、エンジニア以外と働くことがほとんどなくて、エンジニア以外が近くにいるっていうのが新鮮でしたね。
なんかいいなって(笑)

翔:
入社してからの一番の思い出は何ですか?

明大:
開発合宿かなぁ。
開発合宿が初めてでしたし。

翔:
え、そうなんですか。Web業界ってどこも合宿やっているイメージでしたけど。。。

明大:
前の会社はなかったですね。やっているところが発信しているだけですからね。
普段の業務で関わらないエンジニアと関われたし、なによりリフレッシュになりました(笑)

翔:
他の部署の人を含めて合宿やりたいなって明大さんが言っていたと聞いたんですが本当ですか?

明大:
そうですね。ブレストするだけとかの合宿、たとえば経営層で合宿やりましたとかたまにありますけど、そういうのをエンジニア以外も含めてやっても面白いかなと思って言いました。

翔:
なるほど、検討します。

明大:
え!翔くんが仕切るの(笑)

翔:
決裁権はないですけど、提案はできるかなと(笑)
ちなみに業務で思い出に残っているものはありますか?

明大:
業務だと、直近でやっていた検索システムの更改ですかね。
アーキテクチャーからやり直して、6ヶ月ぐらいやって最近リリースできました。
エニグモに入って一番でかくて、やりきったなと。

翔:
やりきったって、大丈夫ですか?(笑)

小澤:
燃え尽きたんじゃなく?(笑)

明大:
そういうわけじゃないです(笑)
当初やりたいと思っていたことを妥協なくやりきりました、という意味です(笑)

interview03

入社後に変わったこと

翔:
エニグモに入ってから変わったことはありますか?

明大:
もともとはスケジュール管理をしっかりしてたんですけど、そんなにやらなくなりました。
良いとも悪いとも思ってないですが、振り返ると変わったなぁと思います。

翔:
スケジュール管理しなくなったと聞くと悪いことに思いますがどうですか?

明大:
なぜかというと、締切りの決まっている作業をほとんどやらなくなったからですね。
先程の検索システム更改は出品リストのリプレイスと一緒にやったので期限は決まっていましたが、それ以外はいつまでってほとんどないですね。

現在取り組んでいる業務

翔:
直近は何をされているのでしょうか?

明大:
検索システムリプレイスが一旦落ち着いたので、在庫のある商品の検索をできるようにするっていう施策をやっています。

翔:
普段の業務はどういうチーム構成ですか?

明大:
ほとんど1人ですかね。
もうひとりいたこともありましたが、別のチームに移ってしまいましたし、上司の木村さんに手伝ってもらうこともありますが、基本は1人ですね。
1人でやるのはいろいろ良くないので誰かいるといいなと思っています。

翔:
一緒にやる人は検索の経験がないとだめですか。経験がなくても大丈夫ですか?

明大:
検索やってましたって人はだいぶレアだと思っているので経験は期待していないですね。
検索やりたいですって人がいればいいですけど、もともとインフラやってたけどもうクラウドの時代だからアプリよりに行きたいなって人、そういう人がSolrのようなミドルウェアから入るのが、入り口としてはよいかなと思っています。
逆に開発ばかりやっていたけどインフラへって人でも入り口としてはいいと思いますね。
間口は広いですよ(笑)

開発について

小澤:
もしかして3社あって一番プログラミングしてますか?

明大:
いま一番書いています!
前職でもAPI担当者と検索インフラって別れていたので、ツールは作っていましたけど、ゼロから検索APIを作ったのは今回初めてですね。

翔:
そうなんですか?!

明大:
既存のAPIの修正をしたりはありましたが、フレームワークから選んで開発もしてって初めてですね。
いまめちゃめちゃ成長してます(笑)

小澤:
シロウトか!(笑)
下から入ってきていま上に登っていますって感じですね。

明大:
最近は自分のことを晩成型なんだなって思っています(笑)

翔:
大器晩成ですね。僕も負けないように頑張ります。

interview07

失敗

翔:
入社後に失敗したことがあれば教えて下さい。

明大:
細かい失敗はあると思うんですが、失敗を失敗と思っていない、反省点として捉えていますね。
直近でいうと、出品リストのリプレイスで、もともとデータベースでやっていたものをSolrに乗り換えますってなったんですよ。
そうすると、Solrのインデックスを作るまでのタイムラグが絶対にあるんですが、それを伝えきれてなかったなと反省しています。

小澤:
なれている人からすると当たり前のことですからね。

明大:
そうですね。検索を長くやっていたせいで見落としてしまいましたね。

エニグモのいいところは

翔:
ではエニグモのいいところを教えて下さい。

明大:
これまでの経験を踏まえると、エンジニア以外との距離感が近いのが一番いいなと思います。
以前の職場ではエンジニア以外が普段何をしているのか全くわからなかったんです。
それがわかるようになってそこから課題感を見つけられたり、エンジニアとしてどうしたらよいかと、そういうことができるのがいい環境だなと思います。

翔:
僕は新卒として入社しているのでこれが当たり前だと感じているのですが、そうではないんですね。

明大:
恵まれてるんだよ(笑)
でも、どっちがいいかはわからないですけどね。もしかしたらエンジニアの世界だけでやりたい、ソッチのほうがいい人っていうのもいるでしょうし。
結局は本人にフィットするかどうかってことなので、いいかどうかはその人次第ですね。

翔:
逆に改善点はありますか?

明大:
入って最初に思ったのは、ドキュメントが少ないですし、メンテナンスされてないのが辛かったですね(笑)
でもそのバランスって難しい、すべて残す必要はないと思いますし、効率よく必要最低限を残したいので、整備したいなと思っていますね。
それと1人で作業することが多いので、作業上の相談、グチ(笑)を話せる人があまりいないですね。
木村さんは協力はしてくれますが一緒のタスクはやっていないですからね。

翔:
一人ぼっちなんですね(笑)

明大:
それは言い方がよくないけど、作業レベルのことって細かいことじゃないですか、それを話す相手がいないのがちょっとつらいですかね。
まあそれはエニグモ全体の話じゃなくて自分の置かれている立ち位置の話ですけどね。

翔:
話し相手が欲しいと(笑)

明大:
それはおかしいだろ!そこまで一人ぼっちじゃないよ(笑)

今後について

翔:
マネジメントとかは興味ありますか?

明大:
1社目が一番マネジメントしていました。それは管理職に上がるかどうかっていうキャリアパスしかないので、それをするしかないという環境でしたね。
それが嫌でやめたので、マネジメントと技術と半々ぐらいがいいかなと思っていますね。

interview05

一緒に働きたいひと

翔:
どんな人と一緒に働きたいですか?

明大:
向上心のある人、立ち止まらず常に走り続けている人ですかね。自分なりの考えを持っている人がいいですね。
逆にいうと、言われたことしかできない人はいやですね。
意見のぶつかり合いがあったとして、それが言える人、そういう環境がいいと思う人がいいですね。

翔:
いろいろ新しいこととか挑戦していく人ですかね。

明大:
新しいこともそうですし、いま抱えている問題を自分で見つけて、それをどうするか考えられる人ですね。
あとは刺激しあえる関係性がいいですね。技術的なことや考え方で刺激しあえて、一緒に楽しく仕事ができる人がいいですね。

翔:
経験は関係ないですか?

明大:
経験はおまけぐらいで、やればできるでしょと思っていますね。

ヤンキー感

翔:
体育会系な感じですか?(笑)

明大:
そうじゃなくて、そういう考え方の人なら経験がなくてもやればできるでしょって、おまけぐらいに思ってます。

翔:
情熱的な感じですね。もともと体育会系ですか?

明大:
体育会系の定義がわからないけど(笑)

翔:
ずっとスポーツをやってたとか、

明大:
スポーツはずっとやってたけどね。

翔:
いやなんか、話しかけるときに「は?!」「あ?!」みたいな反応するじゃないですか(笑)

小澤:
そうですね、こわいですね(笑)

明大:
そう? 本当に?(笑)

翔:
最初話したときヤンキーなのかなと思いましたよ(笑)

interview04

小澤:
完全にヤンキー感出てますよね(笑)

明大:
いやそれ、この会社はいって初めて言われるようになったんですよ(笑)
「あ?!」とは言わないし、声が大きいだけだよ。

翔:
はじめのころは話しかけるのにビクビクしていたんですけど、最近はこれが明大さんなんだなって慣れました。 でも他のメンバーも怖いって言ってますよ(笑)

明大:
だから結局1人で作業しているから、あいつ何やっているかわかんねーし、話しかけると怖いしって印象になってるんですよ。

小澤:
でも明大さんは明確に上と下で言葉を分けますよね。それがたぶんヤンキーっぽいと思いますけどね(笑)

明大:
ハハハッ(笑)
でも僕は年上の人に敬語で話されるのがいやなんですよ。気を使ってしまうので。
なので翔くんにはタメ口で話しますし、上の人には敬語で話しますね。

小澤:
そんな上じゃないけどね(笑)

明大:
でも僕が小澤さんにタメ口だったら変じゃないですか?

小澤:
そうかなぁ(笑)

翔:
基準は年齢だけですか?

明大:
年齢と社歴かなぁ。木村さんには敬語だし、、、キャラもあるかな。たとえば山本くんにはタメ口だけど、木村さんと年齢はそんなに変わらないですしね。

応募を考えている人へのメッセージ

翔:
応募を考えている人になにかメッセージはありますか?

明大:
まずは気軽に話を聞きにきていただければいいなと思っています。
いきなり書類応募、面接って重たいじゃないですか。話聞きたいなっていうのでいいと思いますね。カジュアルな感じでいいと思います。

新人にアドバイス

翔:
毎回聞いているんですが、新人、主に私になにかアドバイスいただけますか?

明大:
新人にかぁ。最初は浅く広くやってみて、楽しいと思うことがあったらそれを深めてみるのがいいかなと思います。
いまの所属はあるけど、ある程度したら別のことをやってみて、たとえばインフラでも、検索でもいいですし、別のことやらせてくださいってやってみるといいと思いますよ。
やれとは言わないですけどね(笑)

翔:
ミドルウェアはいいかもしれないですね。

明大:
検索やる?

小澤:
でも怖いからね。伊藤くんビビってんじゃん(笑)

翔:
子鹿のように震えてます(笑)

趣味

翔:
趣味の話をしたいんですが、明大さんよくランニングされていますよね。

明大:
ランニングは、趣味っていうよりは健康のためかな。走ってて楽しくないですしね。
健康って、身体的な面と精神的な部分と。その2つでやっています。

翔:
?! 精神的なって、やっぱり体育会系な発想ですね(笑)

明大:
そんなことないよ。運動して汗かくが一番のストレス発散だと感じていますね。

翔:
あー、ストレス発散ですか。鍛錬なのかなと思いました(笑)

明大:
修行じゃないよ。

翔:
フットサルもやりますよね。

明大:
フットサルも趣味だったけど最近全然やらないですね。
趣味は、、スノーボードですね。昔からずっとやっていて、子供が生まれてから2,3年やれてなかったんですけど去年からまた行き始めてスノーボード熱が熱くなってますね。

翔:
出身が雪国なんでしたっけ?

明大:
生まれは静岡で幼稚園までいて、小学校からはずっと神奈川です。
スノーボードが盛んなところに住んでいたわけではないです。

翔:
Androidっぽい時計をつけていますが、ガジェットも好きですか?

明大:
これはランニング用に買ったアマズフィットっていうブランドで、日本では売ってなくて買ったんですが失敗したと思ってますけどね。
でもランニング用にはあまり使えなくてファームウェアアップデートを待ってますね(笑)
ランニング以外は良くて睡眠の質や健康状態がわかったり、ライフトラッキングに良いツールかなと思ってます。

小澤:
Apple Watch買えばいいんじゃないかと思いますけどね(笑)

翔:
はい、ではこんなところですかね。ありがとうございました!

明大:
ありがとうございました!

interview06

株式会社エニグモ 正社員の求人一覧
https://hrmos.co/pages/enigmo/jobs?jobType=FULL

エンジニアインタビュー 第4回 夏目さん編

エニグモBUYMA の中のひとを知ってもらおうと、エンジニアへのインタビューをしてみました。
第4回は、2017年3月入社のインフラエンジニア夏目さんです。

インタビュアー
小澤:2011年4月入社。部長。
伊藤:2018年5月入社。新卒2年目。

f:id:enigmo777:20191021182121j:plain

前職について

伊藤:
まずは前職について伺いたいのですが、前職では何をされていたのでしょうか?

夏目:
前職はSIerをやっていまして、新卒研修後に配属先を決めるときに開発とインフラどっちが良い?と聞かれて、インフラを選びました。

伊藤:
なぜ開発じゃなくてインフラを選択したんですか?

夏目:
みんな開発を選ぶんですけど、インフラってコントロールしている感があって良いな、と。力を持ちたかったんです(笑)
それで官公庁とか金融系のインフラ構築・設計をやっていました。

小澤:
ということはインターネットじゃなくてイントラネットですか?

夏目:
たぶんそうですね。
正直言うと自分が構築したシステム上でどんなアプリが動いているか知らなかったんですよね。
知らなくてもなんとかなりますし、そもそもあまり興味がありませんでした。
こういうアプリが動くからこういうサーバを作ってくれ、という流れじゃなくて、こういう要件のサーバ一式、計何百台作ってくれみたいな依頼で作っていました。
「そもそもこれって誰が使ってるのかな?」って思っても、それが見えることはありませんでした。

転職について

伊藤:
そこからなぜエニグモへ転職されたのですか?

夏目:
自分の関わっているシステムを、誰がどういうふうに使っているかということを知るすべがあまり無くて。
なんのために作っているのかわからないのに、ただただスケジュールに追われてシステムを作ってるのが嫌だなと思って、自社サービスをやっている会社に転職を考えてエニグモを選びました。
エニグモは面接がサクサク進んだ印象があって、面接の中でもこれといって引っかかる点がありませんでした。
他社だと、実際のところ何をやっているんだろうと疑問に思うことがあったんですが、エニグモにはそういう疑問はありませんでした。

入社後

f:id:enigmo777:20191021182126j:plain

伊藤:
入社後のエニグモの印象はどうでしたか?

夏目:
前の仕事ではバッファの全く無いスケジュールが引かれて、それに追い立てられてしまって目が死んでる人がたくさんいたんですが、Web系はそういうことが無さそうだな、と想像していて。
概ね思っていたのと同じで、自分でやりたいことをやっていく、っていう感じでしたね。

伊藤:
じゃあだいたい想像通りだったんですね。

夏目:
そうですね。ただ、Web系の企業って良い意味でやり合うというか、ここの作りって変じゃないですか?みたいな指摘をバシバシする感じがあると思っていたんですが、
そんなに皆そういった感じのことを言わないですね。みんな優しいなぁ、平和でいいなと思いました。

小澤:
なんだこのクソコードは、みたいな(笑)

夏目:
冗談交じりでもクソコードっていう人いないですよね。
変な期待を抱いていました(笑)

伊藤:
エンジニアに対してはそうですかね。エンジニア以外はどうですか?

夏目:
自分が今まで持っていた「自分の勤め先にはこういう人がいる」っていうイメージと全然ベクトルの違う人がいっぱいいますね。
同じフロアにエンジニアじゃない人がいっぱいいるっていう状況をまったく想像できなかったので。
なので最初の頃は「なんか皆すげーシュッとしてるな…」って思いました。
企画のみなさんは数字を追うために頑張っていて、そういう仕事をしている人をそもそも見たことがなかったので斬新でした。
エンジニアだけの環境だとそういうのはあまり見えないので、いろいろ見えるのはいいですね。

一番の思い出は?

伊藤:
入社してからの一番の思い出を教えて下さい。

夏目:
まったく業務外なのですが、2年前ぐらいにみんなでスカイダイビングをしたことです!
普段は全然アクティブなことはやらないんで、こういうタイミングじゃないと一生やらないなと思ったんで思い切ってやってみました。
せっかくだからって余計にお金払って普通のコースより高いところまで行ったんですが、落ち始めた瞬間に気圧で耳が痛くなって。早く降ろしてくれーって。
ある意味その経緯がすごい面白かったんですけど、もう二度とやらないですね。。。

伊藤:
もうやらないんですね(笑)

夏目:
これまで旅行ってゆっくりするのがメインで、身体を動かして楽しむっていうのがあまりなかったんですけど。
アクティブにみんなで体験して、っていうのが自分の中では新しかったのでいい思い出です。

伊藤:
ちなみに業務で一番思い出に残っていることはなんですか?

夏目:
業務では、大きなことはなくて少しずつをたくさんやっているので、来るものをひたすら打ち返していたら2年が経ったって感じですね。

変わったこと

f:id:enigmo777:20191021182210j:plain

伊藤:
入社後に変わったと思うことはありますか?

夏目:
さっきの話のように、イベントごとのときはアクティブになろうと頑張るというか、意識するようになったことですね。
根っこはあまり変わっていないかもしれないですが、比較的人と絡むようになったかなと思います。
あとは、前職だとお客さんがいて、その間に入っている大元のシステム会社がいて、それを自分の会社が受けて、の下に三次請け、四次請けってかたちで、コミュニケーションを取らなきゃいけない人がムチャクチャいっぱいいたんですよ。ほとんどの場合に間に入っていることが多くて、板挟みでとにかく辛い。色々な方向に対してイライラしていたんですが、今はそういうのが全く無いです。

小澤:
まったくない?ホントですか?

夏目:
自分にしかイライラしないです!
なのでストレスが減りましたね。

現在の業務内容

伊藤:
現在の業務内容を教えて下さい。

夏目:
これまではずっと細かいことをたくさんやっていたのですが、夏ぐらいからショッパーの方のためのシステムを開発するプロジェクトが動いていて、そのインフラを担当しています。
BUYMAの本体ではなくて、AWSにマイクロサービスで、Kubernetes で作りましょうというプロジェクトをやっています。
k8sを使っているプロジェクトは今までGCPを使ってアプリの人がやっていたので、インフラチームはあまり関わっていなかったんですが、今回はAWSで、EKSで作りましょうとなったので初めてk8sをしっかり触っています。

伊藤:
じゃあk8sは今回が初めてですか?

夏目:
そうですね。テキストをなぞったことはありますが、業務では初めてですね。
AWS化やインフラの構成管理だったり、既に規模が大きいタスクがいろいろとあるので、k8sにまで手を出したら他がおざなりになるなと思って積極的には関わっていませんでした。
ですが実際にやってみるとそんなに敬遠するほどでもなかったです。実務でやってみないとわからないですね。

最大の失敗は

伊藤:
入社後の最大の失敗を教えて下さい。

夏目:
自分が推し進めたいこととして、GitLabやRedmineのバージョンアップを定期的にやっているんですが、
RedmineをオンプレからAWSに移行してみたら3時間ぐらい使えなくなってしまいました。
あくまで社内ツールで、BUYMA のサービスに影響することではないのですが、社内の皆さんにはすごく迷惑をかけました。
私の基準では「この時間でメンテナンスします」と宣言した時間内で終わらないというのはすごくダサいと思っていて、自分にイライラしました。

エニグモのいいところは

f:id:enigmo777:20191021182213j:plain

伊藤:
エニグモのいいところを教えて下さい。

夏目:
先程言ったようなバージョンアップなどの作業をやろうとしたときに、今普通に動いてるんなら無理にやらなくていいじゃん、という人がいなくて、抵抗なく新しいものを受け入れてくれますね。
サーバの構成管理にChefを使っていたのですが、自分が入社して使ってみたときに辛いなと思ってってAnsibleを提案してみたら「やってみれば」と言われて、スッと受け入れてくれました。

伊藤:
Ansibleを導入したのは夏目さんなんですか?

夏目:
そうですね。
まだ中途半端でChefもあってややこしいんですけどね。

小澤:
色んなものが2つずつありますよね。
アプリだとRailsPHPもそうですし、ResqueとSidekiqもそうですし。いい加減整理整頓しないとね(笑)

夏目:
導入は容易なんですよね、やりきる力が弱い(笑)

改善ポイント

f:id:enigmo777:20191021182218j:plain

伊藤:
いま少し話に出たんですけど、改善ポイントはありますか?

夏目:
初めの方に言った、皆あまりバチバチやり合わないというか。遠慮しているのとは違うと思いますが、今動いているものでもこれって変じゃないですか?ってことを言う人がもっといてもいいかなと思いますね。
ぜんぜんやっていないわけではないですが、もっといたらいいなと思います。

一緒に働きたいひとは

伊藤:
どんな人と一緒に働きたいですか?

夏目:
インフラチームで考えると、多方面から様々な依頼がありまして。
運用保守、障害対応、新しいアプリ用のサーバー構築、などジャンルを問わず依頼がきます。もちろんインフラチームとしてもやりたいことがあります。
そういったときに、優先順位をよしなにつけて柔軟に対応できる人がいるとありがたいなと思います。
まあそれはやっていくうちにできるようになるので、すぐにできなくてもいいんですけどね。
あとは空気を読まないで言いたいことが言える人ももっといたらいいですね。

伊藤:
では応募を考えている人へメッセージはありますか?

夏目:
自分もWebのインフラは未経験で入社してやれているので、経験ないとか、知識がないとかで尻込みしないで、雰囲気にマッチすれば馴染みやすいしやっていけると思います。
自分が今持っているスキルだけ考えて、自ら門を閉ざさないでほしいですね。

小澤:
そもそも今のインフラチームでWebのインフラをやっていた人っていないですもんね。

夏目:
そうですね。

唐突にインタビューアーにダメ出し

小澤:
伊藤さんがただ聞いてるだけだなぁと思って隣で聞いていたんですが、どうですか?

夏目:
そうですね。合いの手が弱いですね(笑)

小澤:
インタビュアー交代かなぁ(笑)

夏目:
事前のアンケートを読むなって言われたんですが読むしかないですよ(笑)

小澤:
もう少し、なんだろう、深く聞くというか。

夏目:
それってこうなんですか?具体的にはどうですか?とかね。
他の会社のインタビュー記事とか、雑誌のインタビューとか読まないですか?

伊藤:
インタビュアーってあまり喋らないほうがいいのかなと思いまして。。。

趣味は自作キーボード

f:id:enigmo777:20191021184044j:plain

伊藤:
では、気を取り直しまして(笑) 趣味はなんですか?

小澤:
ここからはインタビュアーっぽくできるかな(笑)
仕事の話だとインフラはまだ良くわからないから深く聞けないよね。

夏目:
自作キーボードですね。

伊藤:
キーボードはいつぐらいから作っているんですか?

夏目:
日本国内のブームになっているのがこの1〜2年ぐらいで、自分もそれで盛り上がっているからはじめました。なのでこの1年半ぐらいです。

伊藤:
自作キーボードの醍醐味ってどういうところですか?
自分の使いやすいキーボードを作りたいんですか、作るのが楽しいんですか?

夏目:
はじめは自分の体、手の大きさ、指の長さにあったキーボードを作るのが目的でした。
以前ErgoDoxというのが既製品で流行っていいなと思ったけど高かったので買えなくて。
最近ブームになってきて、手頃な価格のキットが出るようになったので購入して分割キーボードを作りました。
今はキーボードを作りたいから作っています。というかパーツを買いたいから買っています。

伊藤:
パーツを買いたいだけですか?(笑)

夏目:
キーボードを作りたいからパーツを買っているんじゃなくて、パーツがほしいから買うんです!(笑)

伊藤:
パーツって結構な値段しますよね?

夏目:
でも趣味の世界ってカメラとかオーディオとか、上には上にありますから、そこまではかからないですよ。

小澤:
パーツって何を買うんですか?軸を買うんですか?

夏目:
そうです、そうです。軸っていうかスイッチを買うんです。
スイッチを買って軸にかぶさっている上と下のパーツがほしいんです。軸はいらない!

小澤:
それはなんていうんですか?

夏目:
ハウジングです。
この会社のスイッチはだめだけどハウジングはいいから。みたいなパーツ取りをしたいんです。

伊藤:
ハウジングだけでは売っていないんですか?

f:id:enigmo777:20191021182228j:plain

夏目:
売ってないです。スイッチごと買ってハウジングだけほしいんです。
それで他社のスイッチの軸とバネにハウジングはこのパーツでって。自分の作りたいスイッチを作るんです。

伊藤:
それは自分にあった良いものなんですか?

夏目:
良いです、良いと思い込んでいるんです(笑)
グリスを塗って滑りを良くしたりとか、音がカシャカシャ言わないとか。

伊藤:
それっていま会社で使っているキーボードですか?

夏目:
そうですよ。

伊藤:
自作キーボードを使っていて困ることはないんですか?

夏目:
タイピングがめっちゃ遅くなりました。いまだに打ち間違いが多い(笑)

小澤:
やめちまえ(笑)
それ仕事遅くなってるんじゃない?

夏目:
なってないです!! 満足感が、やる気が出るんで、結果的にはプラスになっていると思います。

伊藤:
タイピングに慣れてきたらどんどんプラスになっていくと、、

夏目:
でもそれより先にまたキーマップを変えてしまうんで、

伊藤:
なんと! キーボードは一緒でもキーマップを変えるんですか?

夏目:
そうですよ。例えば今は人差し指の位置に「-」があるけど、ここじゃないんじゃないかって、どんどん変えています。
打ち損じが多いと、ここじゃないってまた変えて、そしてまたわからなくなるっていう遊びです。

伊藤:
じゃあ完成はしないんですね。

夏目:
キーボードもキーマップも完成しないです!

小澤:
英字の部分はさすがに変えない?

夏目:
そうですね。変えるのは記号ですね。
Dvorakとかオリジナル配列に変えたりする人はいますが、普通のキーボードと併用できなくなっちゃうんで自分はそこは変えないですね。

伊藤:
マウスにこだわりはないんですか、トラックボールにするとか?

夏目:
トラックボールに興味はありますが、使ったことはないですね。
範囲選択してスクリーンキャプチャをすることも多いので、そういう微細な動きができるのかなぁ?と思っています。

伊藤:
暇なときコロコロしてると気持ちいいですよ(笑)

f:id:enigmo777:20191021182232j:plain

夏目:
暇なんですね、羨ましいです(笑)

伊藤:
暇じゃないですよ。怖い怖い。

夏目:
マウス、、すぐ壊れるんですよね。
自分が使っているメーカーがチャタりやすい。

小澤:
ちゃたりやすい??

夏目:
チャタリングって押しても反応しないとか。まあスイッチ変えれば良さそうなんですけど。
チャタるって一般用語じゃないんですか?

伊藤:
初めて聞きました。

小澤:
有線じゃないんですか?

夏目:
あーなるほど、無線だからかな、、、、

伊藤:
他に趣味はありますか?

夏目:
キーボードに似てますが、PCの自作ですね。高校生ぐらいから作ってます。
こちらもパーツを買って、余ったからそれを使うように別のPCを作って、って感じでやってます。
何か目的があって作るんじゃなくて、作りたいから作るんです。

伊藤:
高校生からPC作るって、大学も情報系だったんですか?

夏目:
いや全然、大学は広報メディアっていう文系の学科です。
高校は工業高校で情報系の学科で。そこでパソコンを弄っていて飽きました。
こんなことやってたらSEになってしまう、それはだめだと思って、雑誌の編集がやりたかったので、マスコミの勉強ができるところを探して行きました。
勉強したんですけど、マスコミは食えないなと思って、結局SEになっちゃいましたね。

伊藤:
話変わりますが、運動とかしますか?

夏目:
思い出したようにたまにランニングをしています。
秋に健康診断があって数値がやばいなぁ、ってなって、冬に走って3ヶ月ぐらいで飽きて、夏は暑いから走らないで、また健康診断で思い出すっていうルーチンです。

最後に

伊藤:
若手のメンバーに何かありますか?

夏目:
BUYMAのシステムって改善点がいっぱいあると思うんで色々触ってみて失敗して自分の経験にしていけばいいと思いますよ。
たくさん失敗したらいいんですよ。

伊藤:
ありがとうございます。
インタビューのやり方は勉強しておきます!

小澤:
はい、それでは以上で。
ありがとうございました!

伊藤・夏目:
ありがとうございました!

f:id:enigmo777:20191021182235j:plain

Draperソースコードリーディング

初めまして、19年新卒webエンジニアの平井蒼大です。

弊社では、昼休憩時間を使って、最近勉強したこと、 興味があること、最近行った勉強会やカンファレンスの内容などをLT形式で自由に発表するHacker’s Delightという場が設けられています。

私も先日、「Draperのソースコードリーディング」というお題で発表しましたので、その内容を掲載したいと思います。

動機

今回、Draperのソースコードリーディングに至った理由は以下の二つです。

  • Draperの仕組みを知りたい。
  • Ruby, Ruby on Railsについての知識を増やす。

Draperとは

DraperはPresenter層を提供するgemです。

draperを使うことで以下の利点があります。

  • モデルの肥大化を防ぐ
  • グローバル空間ににヘルパーメソッドが追加されることを防ぐ。

理解する部分

今回、ソースコードリーディングを通して理解するDraperの機能は以下の二つにしました。

また、今回、ArticleクラスをラップしたArticleDecoratorクラスを生成してDraperを使った状況を下に、説明したいと思います。

Decoratorクラスのインスタンス生成方法

下のコードのように、ラップされたクラス(Articleクラス)のインスタンスに.decorateすることで、Decoratorクラスのインスタンスが生成されます。この動きをソースコードを読んで理解しました。

Article.first.decorate

ラップされたクラスのメソッドの呼び出し

Decoratorクラス内でdelegate_allを呼び出すと、ラップされたクラスのメソッドを使うことができます。下の例では、delegate_allすることで、Articleクラスで定義されているpublished?メソッドを呼び出しています。

この動きもソースコードを読んで理解しました。

class ArticleDecorator < Draper::Decorator
  delegate_all
  def publication_status
    if published? 
      "Published at #{published_at}"
    end
  end
end

Decoratorクラスのインスタンス生成方法

Decoratorクラスのインスタンスが生成されるまでの流れを以下の二つのセクションに分けて、説明したいと思います。

  • Railtieによって、Draper::DecoratableモジュールがActiveRecord::Baseにincludeされる流れ
  • decorateメソッドの中身

つまり .decorateが呼ばれる前のDraperが読み込まれた際の処理と、.decorateが呼ばれた後の流れを分けて説明します。

Railtieによって、Draper::DecoratableモジュールがActiveRecord::Baseにincludeされる流れ

まずは、railtie.rbを読んで、どのような初期化ステップが設定されているかを見ます。

今回関係するソースコードは以下になります。

module Draper
  class Railtie < Rails::Railtie

   # 他の初期化ステップが追加されている

    initializer 'draper.setup_orm' do
      [:active_record, :mongoid].each do |orm|
        ActiveSupport.on_load orm do
          Draper.setup_orm self
        end
      end
    end

Draper::Railtieクラスは、Rails:Railtieクラスのサブクラスなので、Railsのブートプロセス時に呼ばれます。

initializerの働きは以下です。

  • ブロックの内容をdraper.setup_ormという名前の初期化ステップとして設定
  • 初期化ステップ自体はMyapp.application.initialize!が呼ばれた時に呼び出される

次に、initializerのブロック内の説明をします。

ActiveSupport.on_loadは activesupport/lib/active_support/lazy_load_hooks.rbで定義されています。

    def on_load(name, options = {}, &block)
      @loaded[name].each do |base|
        execute_hook(name, base, options, block)
      end

      @load_hooks[name] << [block, options]
    end

    def run_load_hooks(name, base = Object)
      @loaded[name] << base
      @load_hooks[name].each do |hook, options|
        execute_hook(name, base, options, hook)
      end
    end

    private
      def with_execution_control(name, block, once)
        unless @run_once[name].include?(block)
          @run_once[name] << block if once

          yield
        end
      end

      def execute_hook(name, base, options, block)
        with_execution_control(name, block, options[:run_once]) do
          if options[:yield]
            block.call(base)
          else
            if base.is_a?(Module)
              base.class_eval(&block)
            else
              base.instance_eval(&block)
            end
          end
        end
      end

今回の場合だとon_loadは、@loaded(:active_record)に対応するものがあれば、そのブロックを即時実行し、なければ@load_hooksに :active_recordというキーでDraper.setup_orm selfを格納します。

この@load_hooksに格納されたDraper.setup_orm selfはlazy_load_hooks.rb内で定義されているrun_load_hooksが呼ばれた時に実行されます。

run_load_hooksはActiveRecord::Base内で、以下のように呼ばれています。

ActiveSupport.run_load_hooks(:active_record, Base)

今回の場合、run_load_hooksメソッド内のbaseはActiveRecord::Baseです。@load_hooks[:active_record]にはload(:active_record) { Draper.setup_orm self } によって Draper.setup_orm selfが格納されています。

つまり、ActiveRecord::Baseで、run_load_hooks(:active_record, Base)が呼ばれると、lazy_load_hooks.rb 内のexecute_hook内でActiveRecord::Base.instance_eval{ Draper.setup_orm self } が実行されます。

Draper.setup_ormはDraperモジュールで定義されています。

def self.setup_orm(base)
  base.class_eval do
    include Draper::Decoratable
  end
end

instance_eval内のselfはレシーバーのオブジェクトなのでDraper.setup_orm self のselfはActiveRecord::Baseです。

つまり、Draper.setup_orm(ActiveRecord:Base)が呼ばれ、ActiveRecord::BaseがDraper::Decoratableをincludeします。

decorateメソッドの中身

先程説明した流れで、Draper::DecoratableがActiveRecord::Baseにincludeされます。

Article.first.decorate

のdecorateメソッドはDraper::Decoratable内で定義されているdecorateメソッドに対応します。

Draper::Decoratableは以下のようになっています。

module Draper
    module Decoratable

      extend ActiveSupport::Concern

      def decorate(options = {})
        decorator_class.decorate(self, options)
      end

      def decorator_class
        self.class.decorator_class
      end

      module ClassMethods
        def decorator_class(called_on = self)
          prefix = respond_to?(:model_name) ? model_name : name
          decorator_name = "#{prefix}Decorator"
          decorator_name_constant = decorator_name.safe_constantize
          return decorator_name_constant unless decorator_name_constant.nil?

          if superclass.respond_to?(:decorator_class)
            superclass.decorator_class(called_on)
          else
            raise Draper::UninferrableDecoratorError.new(called_on)
          end
        end

decorateメソッド内では直下のdecorator_classメソッドを呼びます。decorator_class内のselfはArticleのインスタンス(Article.first)です。

extend ActiveSupport::ConcernがあるのでClassMethods配下のメソッドはそのモジュールがincludeされたクラスのクラスメソッドになります。ですので、上のdecoratorメソッド直下のdecoratar_class内では、Decoratable::ClassMethods内のdecorator_classを呼び出しています。

このdecorator_classで、ラップされたクラス(Articleクラス)のDecoratorクラス(ArticleDecorator)を取得しています。

このdecorator_class内では、Articleのインスタンスがmodel_nameを持つか調べ、あったらprefixとします。そのprefixとDecoratorを文字列連結した変数とsafe_constantizeでDecoratorクラスを取得しています。

つまり、Decoratable直下のdecorateメソッド内のdecorator_classはArticleDecoratorになり、メソッド内ではArticleDecorator.decorate(self, options)を実行しています。

この時の、decorateは ArticleDecoratorクラスが継承しているDraper::Decoratorクラスのinitializeに対応しています。

module Draper
  class Decorator

    def initialize(object, options = {})
      options.assert_valid_keys(:context)
      @object = object
      @context = options.fetch(:context, {})
      handle_multiple_decoration(options) if object.instance_of?(self.class)
    end

    class << self
      alias_method :decorate, :new
    end

このような流れで、ArticleDecoratorクラスのインスタンスが生成されます。

ラップされたクラスのメソッドの呼び出し

Decoratorクラス内でdelegate_allを呼び出すと、ラップされたクラスのメソッドを使うことができる仕組みをソースコードを読んで理解したいと思います。

delegate_allメソッドはDraper::Decoratorクラスで定義されています。

module Draper
  class Decorator
    def self.delegate_all
      include Draper::AutomaticDelegation
    end

AutomaticDelegationモジュールをincludeしています。

AutomaticDelegationではmethod_missingが定義されています。

module Draper
  module AutomaticDelegation
    extend ActiveSupport::Concern
    
    def method_missing(method, *args, &block)
      return super unless delegatable?(method)

      object.send(method, *args, &block)
    end

    def delegatable?(method)
      return if private_methods.include?(method)

      object.respond_to?(method)
    end


# 他のメソッド

method_missingの中で使用されているobjectは、ArticleDecoratorクラスが継承しているDraper::Decoratorクラスのinitializeの中で定義されています。

def initialize(object, options = {})
  options.assert_valid_keys(:context)
  @object = object
  @context = options.fetch(:context, {})
  handle_multiple_decoration(options) if object.instance_of?(self.class)
end

このinitializeはDraper::Decoratableモジュール(ActiveRecord::Baseにincludeされた)のdecorateメソッド内で、.decorate(self, options)という形で呼ばれています。

module Draper
    module Decoratable

      extend ActiveSupport::Concern

      def decorate(options = {})
        decorator_class.decorate(self, options)
      end

この第一引数がobjectに当たるので、今回の場合のmethod_missing内のobjectはActicleクラスのインスタンスになります。

method_missingのソースコードに戻ります。

module Draper
  module AutomaticDelegation
    extend ActiveSupport::Concern
    
    def method_missing(method, *args, &block)
      return super unless delegatable?(method)

      object.send(method, *args, &block)
    end

    def delegatable?(method)
      return if private_methods.include?(method)

      object.respond_to?(method)
    end


# 他のメソッド

method_missingは呼び出さそうとしたメソッドが定義されていない時に、呼び出されます。引数のmethodには呼び出そうとしたメソッド名がシンボルで入ります。delegatable?では、プライベートメソッドを呼び出そうとしているか、また、Articleクラスのインスタンスが引数methodに入れたメソッドを呼び出せるかを調べています。

よって、method_missingの1行目では、呼び出そうとしているメソッドがプライベートメソッドまたは、Articleクラスのインスタンスメソッドでない場合、祖先クラス(objectクラス) のmethod_missingが呼ばれ、NoMethodErrorを発生させます。

そうではない場合、object(Articleクラスのインスタンス)にメソッドを渡して、メソッドを実行しています。このような仕組みでdelegate_allをするとラップされたクラスのメソッドを使うことができます。

所感

最初にも、記載させていただきましたが、今回ソースコードリーディングに至った理由としては以下の二つが挙げられます。

  • Draperの仕組みを知りたい
  • Ruby, Ruby on Railsについての知識を増やしたい

最後にこれらの理由に沿って、今回のソースコードリーディングの感想を書きたいと思います。

Draperの仕組みを知りたい

Draper全体の機能と比べるとかなり一部ではありますが、仕組みをソースコードベースで理解することができました。ソースコードリーディング前の仕組みを理解できていないモヤモヤ感が晴れた瞬間がソースコードリーディングの楽しみの一つなのかなと感じました。

Ruby, Ruby on Railsについての知識を増やしたい

railtieで、Railsの初期化処理を拡張したり、method_missingの使い方、その他のメソッドなど今回のソースコードリーディングで知識を増やすことができたと思います。ただ、railtieによって初期化ステップが設定される流れ、その初期化ステップが実際に実行される部分などは、さらに調べて理解度をあげたいと感じました。

また、 発表という形をとったため、Draperの仕組みについて言葉で伝えられる程理解する必要がありました。準備は大変でしたが、理解度をあげることができたのはとても良かったと感じています。

最後まで読んでいただきありがとうございます。

エンジニアインタビュー 第3回 庄子さん編

エニグモBUYMA の中のひとを知ってもらおうと、エンジニアへのインタビューをしてみました。
第3回は、2018年9月入社、データサイエンティストの庄子さんです。

インタビュアー
小澤:2011年4月入社。部長。
伊藤:2018年5月入社。新卒2年目。

これまでの経歴について

伊藤:
エニグモ入社まではどんなお仕事をされていたのですか?

庄子:
前職はデータ分析の受託ベンチャーで、その前は精密機器メーカーに10年近くいました。

伊藤:
大学ではなにをされていたのですか?

庄子:
大学は理工学部で、材料や物質工学の研究をしていました。研究室では物性物理です。金属の酸化物の粉をまぜて焼いて解析するような内容です。
それから大学院には進まずに就職しました。
研究所に配属されて、部品の異常検知アルゴリズムの開発などをして、その後、カメラの事業部に異動して、オートフォーカスアルゴリズム開発をしました。オートフォーカスがいかに早く、ピンぼけせずに、というような開発です。

伊藤:
そこからなぜデータ分析の道に進まれたのですか?

庄子:
アルゴリズムを開発して、仕様書にして組み込みソフトの部門に渡すんですね。検証のための開発はしますが、自分のコードは製品には載らないんで、自分の書いたものが製品にのるようなことがしたいなと思ったんです。検証だけでなく、最後まで自分で責任を持ちたいなと思いました。
それで転職活動していて、なんとなく機械学習とかビッグデータとかに関わることがしたいなと思い、データ分析の受託ベンチャーに応募しました。流行っていたってのもありますが、実装して問題解決にも関われそうだなと思い転職を決意しました。

エニグモ

伊藤:
エニグモに入社した決め手を教えて下さい。

庄子:
採用が早かったのが一番の決め手です。異例の早さだと聞いて、縁かなと思いました。
もちろんBUYMAのデータを扱えるのは魅力的ですし。

小澤:
たしかにあんなに早いことはないですね。

庄子:
それと、知り合いにエニグモに関わったことのある人がいて、人間関係が良さそうな会社という評判を聞いていたので安心して決めることができました。

入社後の印象は

伊藤:
入社後のエニグモの印象はいかがですか。

庄子:
聞いていたとおり皆さん人当たりがよくて、いい人が多いですね。お互いを尊重している感じがします。
他人を批判するような言い方をする人がいないですね。
なので仕事をすすめるうえで、解決すべき問題があって、それを真っ当な議論で進めることができています。
エンジニアでいうと、おしゃれへの感度は人それぞれですね(笑)

伊藤:
ファッションへのプレッシャーはありましたか?

庄子:
多少ありましたが、面接で大丈夫ですよと言っていただけていたので、プレッシャーはそんなになかったです。

入社してからの一番の思い出は

伊藤:
入社しての一番の思い出はなんですか?

庄子:
ランチにたくさん誘ってもらいました!

伊藤:
たしかなんか一時期バズってましたよね。

小澤:
「はじめてデータサイエンティストという人が来た!」って。

庄子:
最初に出したブランドのセグメンテーションがすごくキャッチーで、皆さんに刺さったんだと思います。
データサイエンティストは数が少なく、募集から採用まで時間がかかったと聞いていて、期待されているんだなと思いました。

伊藤:
プレッシャーは感じませんでしたか?

庄子:
入ったときはやれることをやるだけと思って、そんなに感じていませんでした。
施策を回す、実現することに意識が注力してしまって、、価値を出せているのかと、もっと手っ取り早くデータ分析できるところもあるはずなのに目が行き届いていないなとか、ビジネス的なインパクトを出せていないなと思って焦ったこともありました。

入社後変わったことはありますか

伊藤:
なにか変わったことはありますか?

庄子:
施策を課題からタスクに落として遂行するのが大事だとおもっていたのですが、組織づくりや採用にかかわれるようになって、人を増やして会社としてのデータ分析のプレゼンスを挙げたいという思いが強くなりました。

小澤:
一人目のデータサイエンティストということで困ったことや良かったことはありましたか?

庄子:
データの可視化や、アルゴリズムの手法に関して記事にしたり報告したりしたときに、反応が薄いというか、どれだけ伝わっているのかと不安に思った時期もありました。
こういうやり方に皆さん慣れていないんだろうなという感じで仕事をしていました。
歩み寄りや、認識を合わせることが必要なので、もし僕の伝え方が不十分だったとしたら、気軽に分かりづらいと指摘してくれても良いのにと思うこともありました。
でも分析を繰り返していくうちに、フィードバックを受けるようにもなり、だんだんキャッチボールをできるようになってきたと思っています。
データサイエンティストとして提案しやすい状況になってきていると思います。

現在の業務について

伊藤:
現在の業務を教えていただけますか。

庄子:
今やっているのはセール施策のA/Bテストとその効果検証と、セール対象のターゲットユーザーを判別するアルゴリズム開発もしています。具体的には離脱しそうな人の抽出するアルゴリズム開発ですね。
その他、マーケティング施策の効果検証もしています。

小澤:
伊藤くん、わかってる?

伊藤:
いや。。普段関わることがあまりないというか、(Webエンジニアなので)そもそもやっていることが全然違いますし、、、

庄子:
そうなんですよね。思ったよりエンジニアと関わらないんですよ。エンジニアとは普段、木村さん(庄子の上司のWebエンジニア)としか話さないですね。

伊藤:
最近だと、平井くん(2019年新卒Webエンジニア)と実装やってましたよね?

庄子:
そうですね。でも具体的な実装については木村さんに指揮をとってもらって、僕の作ったAPIを平井くんが使っていましたが、平井くんのやっていることは直接見ていなかったです。
平井くんの実装でAPIの使い方を間違えていたところもあったので、もっと直接コミュニケーションを取ったほうが良かったと思っています。たとえばどういう目的でこの実装が必要で、といったところをちゃんと事前に共有していなかったなとも思っています。これからその施策の結果をちゃんと共有したいと思っており、準備をしています。

失敗

伊藤:
エニグモでの最大の失敗を教えて下さい。

庄子:
気づけば分析で数値的なインパクトを出せていなかったなと思っているのが最大の失敗なんですが、わかりやすい失敗でいうと、GCPインスタンスをポチッと消してしまいました。

伊藤:
それは結構重要なインスタンスだったんですか?

庄子:
まあそんなに重要じゃないというと言い過ぎですが、同僚の使っていた分析環境なので、BUYMAのサービスに影響はしないですが、分析には影響がでますよね。作り直すことはできるので消してもいいんですが、消してしまったと気づいたときは焦りました。

エニグモのいいところ

伊藤:
エニグモのいいところを教えて下さい。

庄子:
これも先程申し上げたとおり、人がいいなと思っていて、、、

小澤:
「先程申し上げたとおり、、」ってなんか硬いなぁ(笑) 面接みたい(笑)

伊藤:
そうですね、もっとラフな感じで大丈夫ですよ。

庄子:
(笑)
エニグモのいいところは、話していてストレスがないですね。オレがオレがって人がいないですし。
ファッション業界ってちょっと "うぇい" な人が多いとおもってたんですが、

伊藤:
そうですよね、僕もファッション業界ってイケイケな人が多いんだろうなと思っていました。そういう人がいないと。

庄子:
エンジニアもエンジニア以外もコミュニケーションが取りやすいと思っています。
あとは余計なことを言われないですね。細かいプロセスに関してのマイクロマネージメントはしないですね、やりたいことをやらせてくれます。

伊藤:
小澤さんが自由ということですね。

庄子:
それから、サービスとして売り手も買い手もどちらも有利にしたいというサービスですよね、エニグモじゃなくてBUYMAのいいところですが。そういうユーザー志向の強いサービスに関わりたい人はいい人が多いんじゃないでしょうか。

伊藤:
まとめると、エニグモの人はいい人ばかりということですね。

庄子:
あとは、意外とオフィスの立地がいいと思ってます。人が多すぎないですね。
たとえば、渋谷・六本木・新宿でランチにでると人とぶつかりそうになるんですよ。それが嫌だったんです。ここはランチの選択肢がメチャクチャ多いわけではないですが、十分なぐらいあって、人にもぶつからないのでいいですね。

伊藤:
お昼は外に行くことがおおいですか。青山でおしゃれランチ。

庄子:
あまりおしゃれな店には行かないですよ。ココイチとかよし牛とかですね(笑)

改善点

伊藤:
エニグモの悪いところ、改善点はありますか?

庄子:
エンジニアの雑談がへたですね(笑)
オレがオレがって自己主張する人がいないのの裏返しなのか、、、エンジニアはもともとおとなしい人が多いとはおもいますが、もうちょっと雑談があってもいいのかなとおもいますね。
雑に「こういうタスクを機械学習でできない?」とか、そっから仕事になったりするかなぁとか、誰がどのぐらいデータ分析や機械学習に理解・興味があるのかなぁとか、雑談から仕事をやる上でのヒントを得られると思っています。まあ、自分から雑談しに行ってもいいんですけど、、、

伊藤:
あんまり雑談するタイミングもないんですかね。自分の席で仕事して、終わったら帰る、ってしてたら雑談するタイミングがないですよね。
たとえばリゾートスペースでみんなでランチしますってやったら接点ができて雑談するかなとも思うんです。

小澤:
ランダムランチじゃないですか?
(以前に伊藤が開催していたランチイベント、いまは開催されていない)

伊藤:
復活ですかね(笑)
たとえば庄子さんがやっている Slack の times チャンネルに気軽に聞くのもありですか?

庄子:
そうですね、ぜんぜんありです。

伊藤:
ただ飲み会のときはみんな騒がしいと。結構飲み会は参加されてますよね。

庄子:
そうですね、お酒自体が好きですし、話すきっかけとしていい機会だと思っています。

伊藤:
飲み会に限らず、イベントにも積極的に参加されている印象があります。たとえば昨日のボードゲーム部にも一緒に参加しましたし。

庄子:
そうですね。
僕の信念というか方針があって、Webサービスに関わりたいという動機ともかかわるんですが、いろいろなポジションの人の話を聞いて、BUYMA全体のサービスができるまでの仕組みに一貫して関わりたいという気持ちが強いので、横のつながりができる場には極力出たいなと思っています。エニグモはまだ100人ぐらいの組織なのでそれができると思っています。

どんな人と働きたいですか

伊藤:
どんな人と一緒に働きたいですか?

庄子:
自分が興味を持っていることを積極的に発信しながら、どうやってBUYMAに使えるかなと考えられる人と仕事したいですね。
自分とは違った視点を持った人だと刺激にもなりますし、いろんな角度からBUYMAを見られるようになるかなと思います。

伊藤:
データサイエンティストと聞くとハードルが高い、経験がないとできないと思ってしまうのですがどうですか?

庄子:
ハードルが高いというのはやっていることが難しいそうってことですか?

伊藤:
はい、そうですね。

庄子:
もちろん機械学習の理論を詳細に知ろうとすると、数学ができないとだめだとか、知っていたほうがアルゴリズムのチューニングのやり方を思いついたりして優位になるということはあるのですが、難しいことをやろうと思わなければ、自分の得意な分野でデータ分析に関わっていくという職種だとおもっていて、たとえばビジネスに強いバックグラウンドがあればそれを生かしてデータ分析をしていくというキャリアもあると思います。また、機械学習を使うとなると、PythonやR等を使わないといけないのでプログラミングの知識も必要です。そういった意味で必要なスキルの幅が広いので難しそうとおもわれるのですが、ビジネス寄りの人や、エンジニアのバックグラウンドの人、理論や数学が好きというひとが、それぞれ得意なところを持ち寄って歩み寄っていけばいいと思っています。
なのでデータへの関心があれば誰でもなれると思っています。

伊藤:
最初からすべてのスキルを持っていないとなれないというわけではない、ということですね。

庄子:
そうです、すべて持っていなくても大丈夫です。実際のデータに触れて、何らかの意思決定に関わっていく経験が重要ですし、その過程で必要なスキルは身につけていけば良いと思います。

応募を考えている人へ

伊藤:
応募を考えている人になにかメッセージはありますか?

庄子:
ちょうど一年ぐらいたつのですが、やればやるほど掘り下げたいところが出てきます。
ユーザーの行動ログや、画像データもありますし、データ分析をやりやすくする基盤やダッシュボードを整えたり、やりたいことはたくさんあります。
課題がいっぱいあるので、解きたい課題から挑戦してくれる人がいいですね。

ご趣味は

伊藤:
唐突ですが、ご趣味は?

庄子:
趣味は、ない(笑)

伊藤:
映画鑑賞とか?Netflixとか?

庄子:
映画、漫画、動画を見たりしますよ。先日「天気の子」をみました。
旅行も好きですよ。

伊藤:
海外旅行とかはいかがですか?

庄子:
一昨年に新婚旅行でベトナムに行きました。
今度のリフレッシュ休暇で海外に行こうと思ったら、パスポートの期限が切れていて諦めました。
ヨーロッパも5カ国ぐらい行きました。中でも、クロアチアのプリトヴィッツェ国立公園に行けたことは一生の思い出です。

伊藤:
ヨーロッパは社会人になってからですか?

庄子:
そうです。学生の頃はあまり旅行に興味はありませんでした。
20代のころはテニスをしていました。1社目の会社にテニス部があってそこでずっとやっていました。
大学時代はスキーサークルに入っていました。
基礎スキーという分野がありまして、採点する人がいて採点されるんですよ。それをやっていました。
競技スキーはオリンピックの種目になっていますが、基礎スキーはそういうのじゃないですね。

伊藤:
(検索しながら)正確性・合理性によって競われる採点競技なんですね。
最近は基礎スキーをやっているんですか?

庄子:
基礎スキーはやらないですよ(笑)いまは年1回スキーに行くぐらいですね。

伊藤:
問題点は採点基準が明確ではないと。

庄子:
そう!
スキー場でスクールやっている人が採点するんですけど、その人の独自ルールになっていると思います。
同じ級でも受験する場所で違うと思います。
これを統計的にモデリングするのが僕の夢です。。。嘘です(笑)

伊藤:
最近は運動しますか?

庄子:
最近はしないです。ちょっと暗くなるんですが、ヘルニアで腰が痛くて。。。
あとは趣味、、、読書。技術書読むのも好きです。
Kaggleもやっているんですが、そんなに真剣にはやれていないです。

伊藤:
Kaggleは予想が当たりましたね。

庄子:
どういうことですか?

伊藤:
これまでのインタビューは仕事のことばかりでプライベートなことを聞いていないから聞いてみようと小澤さんと話していて、庄子さんまじめだからKaggleですよって言ってたんですよ(笑)

庄子:
まじめって(笑)
好きなことを仕事にしたいと思っているのでやりますよ。

小澤:
いいですね、趣味と仕事が一緒にできるっていいですよね。

庄子:
そんなに週末はまじめにやってないですけどね(笑)

小澤:
はい、それではこの辺で。

庄子:
ありがとうございました。

伊藤:
ありがとうございました!