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

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

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

前職について

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

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

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

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

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

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

転職について

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

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

入社後

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

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

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

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

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

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

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

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

一番の思い出は？

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

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

伊藤:
もうやらないんですね（笑）

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

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

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

変わったこと

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

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

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

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

現在の業務内容

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

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

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

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

最大の失敗は

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

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

エニグモのいいところは

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

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

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

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

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

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

改善ポイント

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

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

一緒に働きたいひとは

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

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

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

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

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

夏目:
そうですね。

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

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

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

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

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

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

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

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

趣味は自作キーボード

伊藤:
では、気を取り直しまして（笑） 趣味はなんですか？

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

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

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

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

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

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

伊藤:
パーツを買いたいだけですか？（笑）

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

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

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

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

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

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

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

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

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

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

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

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

夏目:
そうですよ。

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

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

小澤:
やめちまえ（笑）
それ仕事遅くなってるんじゃない？

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

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

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

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

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

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

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

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

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

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

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

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

夏目:
暇なんですね、羨ましいです（笑）

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

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

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

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

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

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

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

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

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

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

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

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

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

最後に

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

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

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

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

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

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ですよって言ってたんですよ（笑）

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

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

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

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

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

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

エンジニアインタビュー 第2回 山本さん編

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

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

前職について

伊藤： 前職は何をされていたのですか？

山本： パチンコの開発をしていました。パチンコって真ん中に液晶あるじゃないですか。あれを制御する組み込みソフトの開発です。 デザイナーさんがAfterEffectsで動画をたくさん作るんですよ。それを組み合わせて表示します。 あとは音を鳴らしたりランプを光らせたり役物を動かしたり。

小澤： 最近パチンコやってないからわからない、、 言語や開発環境は？

山本： C言語ですね。フレームワークはないです。

転職について

伊藤： なぜそこからWebの会社にきたんですか？

山本： 開発をしているので、開発について調べるじゃないですか。Webで調べるんで、Web開発の情報が多いですよね。 そうしているうちに興味を持って、勉強会ってのがあるんだとかわかってきて、2014 年の Github Kaigi というのに行ってみました。 そこでWeb開発たのしそうだなぁと思いました。

伊藤： Githubを使ってたんですか？

山本： 前職ではGitはおろかSubversionも使ってなかったんですけど。Rebuild.fmの公開収録があったり面白そうだなとおもって行きました。 それでWeb開発をやってみようと思って、RailsとReactをやってみました。

小澤： Railsはわかるんですが、なんでReactやったんですか。

山本： JavaScriptもやらないとなと考えて調べると、ちょうどそのころはjQueryからReactへ、というような記事が多くて、やるなら流行っているものをやろうと思いました。

小澤： パチンコのUIをやっていて、もともとUIが好きでReactやったわけではないんですか？

山本： そうでもないですね（笑）

エニグモに決めた理由

伊藤： エニグモの決めたのはなぜですか？

山本： 自分でやっていたRailsとReactが使えるところに行こうとおもって応募しました。 そしたら書類審査がはやくて、面接も早くて、内定が出たので決めました。

小澤： それだけですか？

山本： そうですね。 とにかく書類も面接の結果もどんどん返ってくるんですよ。こんな感じで仕事ができるのかっ、というスピード感が決め手でしたね。

入社後の印象は

伊藤： 入社してみての印象はどうでしたか？

山本： 自由だなぁと思いました。あれやれこれやれ言われないし。 もちろんタスクは振られるのですが、あとよろしくってかんじで。 小澤さんが自由なんですかね。

小澤： 私が自由ってどういうことですか （笑）

山本： 細かいこと言わないですよね。

小澤： そうですね。

山本： あとは、社員の人がキラキラしていてビビりました。 エンジニアだけじゃないし、前職に比べたら女性もいっぱいいますし。ファッションの会社ですし。 みんなおしゃれな店でランチしてそうで、コンビニ弁当なんか食べてたらちょっと恥ずかしい、みたいな。ちょっとした恐怖感はありました。エンジニアは関係ないですけど。

小澤： そういえば、ファッションの会社ってことでエンジニアに敬遠されることもあると思っているのですが、入社前に、おしゃれじゃないとだめかなとか不安はなかったですか？

山本： それは考えませんでしたね（笑）

一番の思い出

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

山本： 入社して一ヶ月ぐらいでお問い合わせのリニューアルに参加しました。 右も左もわからない状態で、レビューでもいろいろ指摘されたりもしましたが、すごく成長できました。

伊藤： レビューは厳しかったですか？

山本： 厳しいですけど、すごく丁寧で、親切に教えてくれたって感じですね。上から指摘されたりとか、怖いという感じではないです。 開発手法についても、スクラムでやろうってなってて初めてでしたし、データベースも個人で使った見たていどで仕事ではやったことなかったですし、Apache Solr（検索エンジン）なんて知らなかったし。 いろいろはじめてでわからないことがわからない状態でした。ただ、一緒のチームの齊藤さんと業務委託の方が二人共すごい技術力が高くて、二人の実装や設計スキルを見ながら勉強してました。

失敗

伊藤： 失敗したことはありますか？

山本： 定時後に大きめのリリースをしてBUYMAが止まってしまいました。

小澤： そんな事あったっけ。どのぐらい止まりました？

山本： 完全に止まったわけではないですが、2時間ぐらい不安定でした。まあ見えにくかったので、止まってしまっていましたね。 それまでJSやCSSをブラウザでキャッシュするようにクエリパラメータをつけていたのですが、SVNのリビジョンがついていたんですよ。それの仕組みがいやで変えたかったんです。 結構影響が大きいので、みんながリリースしない時間にやろうということになり、定時後にしてしまいました。 そしたら、原因の詳細は忘れましたが、ネットワークが不安定になってしまいました。

伊藤： 教訓はありますか？

山本： 定時後にリリースしないってことですね！(笑）

小澤 そうっすね（笑） 助けてくれる人も少ないですからね。調整して定時内にやりましょう。

変化

小澤： 入社してから変わったことはありますか？

山本： 変わったことですか？

小澤： 例えば、おしゃれになってますよね（笑）

山本： そうかも知れないですね（笑） みんなキラキラしてるし、おしゃれな人がたくさんいるんで、参考になる人がたくさんいるからですかね。入社前よりはだいぶ気を使うようになりました（笑） 変わったことかぁ。。。給料が上がりました！！

伊藤： そんなにですか（笑）

小澤： はじめが低かったからじゃないですか（笑）

山本： それもありますが、順調に上げてもらっていると思ってます。 給料を上げてくれるいい会社です（笑）

伊藤： 給料が上がって、おしゃれにもお金をかけられるようになったと（笑）

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

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

山本： レガシーな部分もいっぱいあるんで、自分で勝手に改善したり、新しい技術を取り入れてくれる人ですね。

伊藤： 勝手に作って、リリースしていいんですか？

小澤： リリースはだめだよ。上場企業には統制というのがあってだな（笑）

山本： リリースはだめだけど直前までは勝手にやって大丈夫ですよ。自由なんで。 リリースするには、ちゃんと承認をもらってリリースしましょう。

会社のいいところ

小澤： 開発・仕事じゃないところでエニグモのいいと思うところはありますか？ 例えば、コーヒー屋さんとか。

山本： コーヒー飲まないんですけど、ビールがあるのはいいですね。 世界のビールがおいてあって、18:30以降はのんでいいんですよ。 あとはリゾートスペースが好きですね。とくにコーヒー屋さんの前のリゾートスペースが好きです。 ここだけモニターがなくてミーティングで使えないんですけど、集中したいときにここに来ます。

たれこみ

小澤： そういえば先日、伊藤さんから「山本さんはずっとTwitterを見てる」とタレコミがありましたが仕事してますか？

伊藤： Twitter 見てて、仕事は外注してる疑惑ですね（笑）あんなにできるはずがない（笑）

山本： もちろんずっとTwitterを見てるわけではないですよ！ たまたま休憩するタイミングが同じなんじゃないですかね（笑） 伊藤さんは仕事しないで山本を見てるってことでしょ（笑） 弊社にはTwitterを見る自由はありますよ。

今後

伊藤： 今後やりたいことはありますか？

小澤： ずっとフロントエンドチーム作りたいって言ってますよね。できてなくてすみません。

山本： フロントエンドの改善したいですね。一人だと辛いんでチームでやりたいです。

小澤： 伊藤くんが小さく手を上げてますけど。

山本： サーバーサイドがもう少し強くないとまだ一緒にやるのはつらいですね（笑）

伊藤： なぜか毎回、私のダメ出しみたいになりますね。 マネージメントは興味ないですか？

山本： ありますよ。 これから先ずっと技術を突き詰めていくタイプかっていうとそうでもないと思っていて、タスクを細かくして人に振っていくのも自分にむいているかなと最近感じていますね。

小澤： えっ、そうなの。いいこと聞いた。

山本： 技術もまだやっていきますが、マネージメントもありかなと思っています。

若手に向けたメッセージ

伊藤： ぼくら若手に向けたメッセージはありますか？

山本： Webの世界はすごく広大なので迷うことも多いと思うのですが、色々触って自分の好きな分野を見つけて、そこを伸ばしていってほしいです。 今後は特定の分野に特化した人が活躍するんじゃないかなぁとなんとなく思っています。

小澤： それではこの辺で、ありがとうございました。

山本・伊藤： ありがとうございました！

エンジニアインタビュー 第1回 齊藤さん編

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

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

エニグモに入社した理由・動機

伊藤： エニグモに入社したのはなぜですか？

齊藤： 自社サービスがいいなと思って会社を探していました。
盛り上がっていたのでゲーム会社も面接に行ったのですが、すごい機械的で、MySQL 運用したことありますか、とか、そういう質問ばかりで。
エニグモは(前)部長とエンジニアの人と面接して、自分のできることに興味を持ってもらって、最終含めて3回面接しました。
EC に興味があったのと、どうしようかと思っているところで Stylist というサービスを公開しました、というメールがきたので、面白そうだなと思い入社を決めました。
残念ながら Stylist は今はクローズしていますけど。

小澤： エニグモの前はイギリスですよね。

齊藤： もうやめて来ていました。
前の会社は受託で、スクラッチ＆ビルドみたいなことを何回もやるんで毎回工夫できて面白かったんですが、自社でやっているサービスも見ていたのでソッチのほうが面白そうだなと思っていました。

現在担当している業務は

伊藤： 最近はどんな業務をされていますか？

齊藤： 4年前ぐらいにユニット化されてからは、自分たちでこれやったら良さそう、変えたほうが良さそう、面白そうだなって思うアイデアを提案してやっています。
自分で発案したものもありますし、浮いていて面白そうだなってのを拾ったりしてやってます。
その前はトップレベル会議みたいなのがあって、大きなテーマのものは誰がやるかみたいなのが決まっていました。

小澤： この3年ぐらい、主にパーソナルショッパー向けの機能の開発をしていますよね。

齊藤： そうですね、それが僕の担当しているロールっぽくて、

小澤・伊藤： ぽくて （笑）

伊藤： ぽくてって認識なんですね。

齊藤： お問い合わせリニューアルぐらいからそうですね。
お問い合わせ機能が、データベースの設計から見た目までひどかったんですよ。でも、それまでは機能しているものをあまり見直さなかったんですよね。
でもあれは、なんで変えていいってなったんですかね？

小澤： 3年ぐらい言い続けたからじゃないですかね。
お問い合わせでなにかしたいという要望はあったんですが、お問い合わせは触っちゃだめだってエンジニアはみんな思ってたんですよね。

齊藤： 改修内容が大きすぎるから触れなかったんですかね。データベースから見た目まで全部やりたくなっちゃうから。。 結局そのときは全部やり直しましたね。
初めてメイン以外のデータベースの導入を決めて、データベースを設計して、既存データの移行を考えて。 UI はそのとき React が盛り上がっていたので、やったことはなかったけどやるでしょってなって、Redux の設計も勉強して導入しました。

伊藤： どのぐらいかかったんですか？

齊藤： 最初は3ヶ月ぐらいかと思ってましたが、半年ぐらいかかりました。

小澤： 当初計画の3ヶ月ってのは、もう長いからそれ以上考えられないっていう、漠然とした3ヶ月です。

齊藤： それまで3ヶ月もかかるのはなかったですからね。大体長くて1ヶ月みたいなものが多かったですね。 性能検証もあとから追加したり、見積もりが随時変わっていったっていうのも理由としてありますね。
それからこのとき山本さんが入社して1ヶ月ぐらいでプロジェクトに参加して、1ヶ月ぐらいですでに何ヶ月も一緒にやっているような存在感で、インクリメンタルな実装を相互にレビュー・マージしていく作業フローもすぐにスムースにこなしていて驚きました。
そのプロジェクトのあとは、商品画像の差し替え、、、画像枚数からルールに従って URL を生成する処理になっていたので、画像が並べ替えられなかったんですよね。ショッパーや社内からも画像を変更したり並び替えたいという要望はずっとあったんですが、それも手を入れるのが大変だからってやってなかったんですよ。
ちょっとした改修では済まないものをそこからやるようになりました（笑）。
これも半年ぐらいかかりました。 管理画面（BUYMA 本体とは別の Java の Web アプリ）をいじらずに管理画面を改修するのもこの頃からやってます（笑）。

小澤： それもお問い合せ改修からですかね。

齊藤： そうですね、管理画面の変更（Java）がめんどくさかったんで。
画像の差し替えは半年メインラインと並走して開発したのでリリースでたくさんしくじりましたね。
今みたいに Git じゃなくて SVN だったという要因もあったり、商品画像はサイトのいろいろなところに出ているので色んな人が修正するんですよね。それでリリースマージが難しくなってしまって。。
お問い合わせ改修も半年かかったんですが、色んな所に表示される機能ではないので影響が小さかったんです。
余裕持ってやるつもりだったんですが、マージに労力を取られすぎて、マージ終わったらもうメンテじゃんていう感じで出してしまいました。
そのときはメンテ明けは普段は朝に帰るんですが、24時間ぐらい会社にいました。

小澤： その後にフィーチャーフラグとか、どんどん出していくように実装をしましたよね。

齊藤： そうですね。
その後はCSVでの一括出品機能でした。機能としてはあったんですが、100品しか更新できない、下書きにしかならない、変更できない項目があるとか、使いにくいところがいっぱいあったんですよ。
1万件を上限にしたので、一つのバグでショッパーさんの全商品が壊れてしまうようなリスクがありました。
これはテストを入念にしたので時間がかかりましたね。
大変でしたけど、商品数の多いショッパーさんにすごく使われているので良かったです。

伊藤： 直近は何をされていますか？

齊藤： 直近はとある機能をやっているんですが、これまで BUYMA はモノリスなアプリなので改修自体が必要以上にめんどくさいなと感じていて、良い機会なのでマイクロサービスな設計で作ろうと思っています。 Kubernetes とか使ってインフラのメンバーにも協力頂いて進めたいです。

エニグモに入社してからの一番の思い出

伊藤： 入社してからの一番の思い出ってなんですか？社員旅行でハワイに行ったりしてますよね？

齊藤： 一番か、難しいですね。。。。ハワイも思い出ですけど、 僕はメンテナンスが好きで、

小澤・伊藤： え、そうなんですか！

齊藤： メンテナンスでリリースするのって、サービスをコントロールしている実感が強いじゃないですか。
深夜にサービスを止めて、ソースコードをリリースして、明け方徐々に使われだしていくその現場にいる感じが好きですね。
最近はリリースでサービスを止めるような機会は減ったのであまりないですけど。

伊藤： 一番の思い出はメンテナンス。

齊藤： 長期間開発してリリースしたメンテナンスは印象にとても残ってます。
頻繁にできる仕事ではないですけど、その分区切りにもなるし、達成感になりますね。

どういう人と働きたいですか

伊藤： これから、どういう人に来てほしいですか。どういう人と働きたいですか。

齊藤： アイディアがある人が良いですね。自分だったらこう変えるとか、これは良くないとか、自分の意見が言える人がいいですね。
あとは、人の変更見て、塩梅を汲み取って柔軟に実装できる人がいいですね。
例えば「そんなに作り込まなくてもいいです」っていう感覚が分かる人。

伊藤： 一気にハードル上がりますね。

齊藤： 思っている塩梅で、書けてないというか、「工数削るためにユニットテスト書きませんでした」って来られると、そうじゃないよなと思いますし。

小澤： そうですね。

齊藤： チームで上手に動ける人がいいですね。不必要に足引っ張るようなレビューコメントで全体のリズムが悪くなることもあるので。
作業分担してても自分事になっている人がいいですね。
僕は年長者ですけど、経験者とばかり働きたいわけじゃないんですよ。
人のコードや動きを見て、良いと思うとか、これはこうじゃないですかってはっきり言える人がいいですね。

伊藤： 初心者とまではいかないですけど、あまり経験がなくてもいいと。

齊藤： そうですね。センスが良ければ関係ないと思います。

これまでにした一番大きなミス

伊藤： これまでにした一番大きなミスってなんですか？

齊藤： それは、画像差し替えプロジェクトのメンテナンス開けでバグがいっぱい出たときですね。

小澤： げんなりしたっていう。

齊藤： こんなに考慮漏れができるのかって思いましたね。
まあ、障害がでるとチーム感が出るというか、協力者が出てきてものすごいスピード感で解消していく過程はそれで楽しいですけどね。

小澤： すぐ直せっていうバグ修正はアドレナリンがでて楽しいですよね。

今後

小澤： 20年ぐらいプログラマーやっていて飽きないですか？

齊藤： 飽きないですね。

小澤： 次から次へあたらしい技術やアイディアが出てきてすごいなと思うんですよ。

齊藤： そうっすね。楽しい仕事です。

伊藤： ライバルはいるんですか？

齊藤： ライバル意識することはないですけど、、、、。 影響を受けるメンバーはいます。
小澤さんは調べるのはやいなと。バグがあったら「そこじゃない？」って速効性があってミニマムな修正を思いつくのが早いですし。

小澤： おぉぉ（笑）

齊藤： 浅香さんは作業の精度がずっと安定していてレスポンスも早いですよね。インフラ面から全体を見られていますし。 メンテナンスのバグ対応でもたくさん助けていただきました。
大川さんは無駄に作らないでツールがあるじゃんていって、新しいツールを使いこなすのも早いですし、考え方がスマートですね。真似できない。
木村さんも勉強熱心で、時代にそって変えて行くべきことを実行してますよね。最近マネージメントよりですけど。
皆さんとても良い刺激になります。

伊藤： みんな最近マネージメントよりな印象ですけど。
マネージメントには興味ないですか？

齊藤： 僕はミーティングがいっぱい入ってくると違うなって思ってしまいます。
リーダーシップはとりたいとは思いますけど、自分も動きたいですね。指示を出すようなロールではなくてメンバーでいたいです。
もっと上手な人が設計や案を出せばそれを実装したいってなると思います。
マネージメントするよりも、足を引っ張るようになるまでは開発を続けていきたいですね。

伊藤： オープンソースに貢献するのは興味ないんですか？

齊藤： そうですね、フォーカスしてやってみたことはないですね。
Rails とか開発しているのは楽しそうですけど、、ユーザーフェイシングな開発している方が面白いと思います。
あとは BUYMA ってレガシーなところがいっぱいあるから、新しいものに変えたいですね。

小澤： アイディアはいっぱい出てきますよね。

齊藤： 悔しいですけど「あれ、C社はできているのにうちはできていないなって」思うところがいろいろあって、そういう負債が消えていってほしいと思ってます（笑）。

若手になにかありますか

伊藤： 若手になにか思うことはありますか？

齊藤： 遠慮しないほうがいいと思います。なにか思うことがあったら提案しておいて、すぐにはできないことも多いですが提案すればだいたい自分がやることになるんで。
あとは障害とかあったら参加してみるとか。オンタイムに障害を克服することが開発者としてサービスに近づく一歩のようなところもあると思います。
うちの人って調べたことのログ張ったりするじゃないですか。それってここまでやったってのもあるし、他の人にもここ見ればいいって伝えたことになってて。

伊藤： 次同じことがあったらそれを見ればいいと。

齊藤： 思い出したらそれを真似してみれば良いんですよ。
昔はそうでした。人も少なかったんで誰もそんな親切には教えてくれなくて。見てればわかるっしょって感じでした。

小澤： 怖い会社ですね。

齊藤： はいったときからそうでした。 (※今も昔も聞けばやさしく答えてくれる優しい人ばかりです)

小澤： 齊藤さんのはじめのころのエピソードで面白かったのは、明日やろうと思ってたものが起きたらできていたって言う話。

伊藤： なんすかそれは。

齊藤： はじめのプロジェクトが二人でこんなサービスを作ってみてっていうのだったんですよ。
その人はやりましたとか言わないでしれっとプッシュしてありました。

伊藤： それは齊藤さんに割り当てられたタスクだったんですか？

齊藤： 今みたいに計画してやっていく感じじゃなくて、ざっくりしてたんですよ。
もうひとりの人は誰に頼らなくても一人でできちゃう人なんで、ついでにやっておきましたという感じです。
それで、やんなかったら全部作られちゃうなと思いました。

伊藤： そんなこともあったんですね。

齊藤： そうですね。それで折れてやめたいとは思いませんでしたが、頑張んなきゃなと思いました。

ちなみに

齊藤： 僕が一番目に指名されたのは（年長者なので）気を使ってですか？

伊藤： そうじゃないです。

小澤： そうじゃないですね（笑）。 誰に聞いてみたいって聞いたら、真っ先に齊藤さんが出てきました。

Enigmo 開発合宿2019 in 湯河原

こんにちは。気が付けば入社から一年が経ち、 新卒の肩書きを失った@sean0628_i です。

４月４日（木）、４月５日（金）の日程で開発合宿を行ってきました。 場所は前回と同じく、おんやど恵さんにお邪魔しました。

前回の開発合宿が2017年だったようなので、２年ぶりの開催ですね。

テーマ

今回は『チーム力のアップ』をテーマに設定しました。

前回は個人個人好きなことを行うスタイルだったようですが、 今回はテーマが『チーム力のアップ』でしたので、基本的にはチーム開発で取り組むことにしました。

参加者の希望を聞き入れつつ、実行委員が１-３人のチームに分けました。 そして、チームごと取り組む内容を決定し、合宿に臨みました。 合宿一ヶ月ほど前にチームを発表し、準備期間も設けました。

スケジュール感：

• ３月初 - チーム発表
• ３月中 - 内容決定・下準備
• ４月４日、５日 - 合宿開催

合宿でやったこと

内容に関しては、業務に関する範囲であれば基本的になんでもOK です。 最終的にそれぞれ以下の内容に取り組んでいました。

内容：

• １班：STYLE HAUS フロントの性能改善（画像リサイズ）
• ２班：BUYMA フロントの性能改善
• ３班：商品画像分類
• ４班：STYLE HAUS タグのサジェスト
• ５班：Jenkins のデプロイジョブのGitLab-CI 化
• ６班：GitLab Runner Autoscale on AWS

当日の様子

東京駅出発

皆さん遅れてくるかなぁと思い１５分前集合にしましたが、まさかの全員５分前行動。 出発の２０分前には全員集まりました、、、さすがです！！！

開発開始

湯河原駅周辺で昼食をとって、開発開始です。 テーブルはチームごとです。

キーボード作成が趣味のメンバーは、自作キーボード持参で合宿に臨んでいました。

BUYMA パーカーを着て開発するメンバーも！

夕食

夜は宴会！！！ テンションの上がったメンバーがコスプレをし、晩酌をしていると、、、 密告され、部長殿におこられてしまいました。。。

宴会の後は反省して、黙々と開発に励んでおりました。。。

記念撮影

宿の前でパシャり。 ２日目はお昼まで開発を行い、湯河原駅周辺で昼食を食べ帰路につきました。

まとめ

当日は大きく成果を出せたチーム、あまり成果を出せなかったチームとありました。 ただ、事前準備の期間をおよそ１ヶ月用意したこともあり、どのチームも最低限の成果は出せていたように思います。

また、通常の業務を離れて普段あまり関わることのないメンバーと開発を行うことができて、 参加者それぞれ新たな気づきがあったことと思います。

『チーム力のアップ』という点で見ても、縦・横両方の意味で向上することができました。

私個人としても一日中シニアエンジニアの方に手取り足取り教えていただき、 Serverless、Docker などの知識を深めることができました。

またとない貴重な時間を過ごさせていただきました。

今後も積極的に社内勉強会、開発合宿を開催していきたいと思います。

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

iOSアプリのデザインをしてみて

はじめまして。BUYMAのiOSアプリチームでデザインを担当しています。 この記事を読んでくださりありがとうございます。

2019年2月に、お問い合わせ機能をネイティブ化しました。 より使いやすくするために、Webviewからネイティブ化し、あわせてリデザインすることになりました。

Webとアプリを作業する上で、デザイナーとして苦労した部分を、新しいデザインと一緒に書いていきたいと思います。

まず、BUYMAのiOSアプリってどんな感じ？

BUYMAはショッピングサービスなので必要なページがたくさん。

現状、アプリの半分くらいが、Webviewです。

ネイティブ化されたページとWebviewのページが混在しているため、ページによってデザインテイストが異なっていることを課題のひとつとして感じています。 ユーザーがアプリを起動してから目的を達成するまで、気持ちよく使えるよう統一されたデザインにしていきたいと考えています。

実際にデザインするときに考えていること２つ

１・デザインのトレンドを押さえたユーザーインターフェース

古っぽいデザインは、扱っているコンテンツさえ古く感じさせてしまうのでもったいないです。特にBUYMAでは、日本未入荷のレアアイテムを揃えていたり、最新のトレンドを発信しているサービスのため、サービスブランディングの観点からも、とても大事になってくるポイントだと考えています。

そのためまずはとにかく他社リサーチに時間をかけています。国内外の人気アプリのデザインをチェックしてよく使われているUIを参考にしたり、海外のデザインギャラリーを漁ってアイディアの引き出しを増やしています。

よく参考にしている海外デザインサイト

２・ユーザーが目的を達成するためのデザイン

トレンドだけ追いかけて「とりあえず流行りのデザインを取り入れたけど、実は使いにくかった」となっては本末転倒です。そのため、ユーザーが目的を達成しやすいデザインかどうか、という視点が重要になってきます。

そのページではユーザーに何を達成してほしいのかを明確にすること、そしてそれを達成するためには、ユーザーにどういうアクションをしてほしくて、きちんとアクションしやすいデザインになっているか、ということを考えながらデザインを行っています。

お問い合わせ画面の目的

BUYMAはCtoCサービスです。注文がはいるとパーソナルショッパーが買い付けに行き、商品を送ってくれるサービスです。 商品によって、配送日数が異なっていたり、買い付けに行ったけど在庫が無かったというケースが発生する場合があります。

もしユーザーがBUYMAを、在庫を持つ一般的なECサイトだと思って使っていた場合、「想定よりも配送日数が長かった」「注文したのにキャンセルされた」といった体験はユーザーのペインポイントになりかねません。

このペインポイントは注文前に商品について事前問い合わせをすることで解消できます。 お問い合わせ画面では、このようなペインポイントを解消することを目的とし、2点を達成することが必要だと考えました。

1. BUYMAはCtoCサービスだと伝えられていること
2. パーソナルショッパーへ在庫や商品詳細についてお問い合わせがしやすいデザインであること

現状のお問い合わせ画面の課題

それでは本当にCtoCサービスということが伝えられているのか、お問い合わせがしやすいデザインになっているのかということを念頭におき、現在のデザインから改善できるポイントがないかを考えていきます。

▼現状のデザイン

▼現状の課題

• CtoCサービスということが伝えられているのか

→ 1 パーソナルショッパーへの問い合わせフォームだということが伝わりづらいため、CtoC感がなくハードルが高い印象を与えかねない。

• お問い合わせがしやすいデザインになっているのか

→ 2 商品ページからお問い合わせボタンをもっとタップしてもらいたいので、現状よりもボタンに気づきやすくしたい。

→ 3 お問い合わせ一覧ページは、なんのアクションをしてほしいページなのか分かりづらい。

以上の課題に対してリデザインしていきます。

課題に対するアプローチ

▼改修後のデザイン

▼課題に対する変更点

1 ・CtoC感がなくハードルが高い印象を与える。

• メッセンジャーアプリに寄せたUIで問い合わせのハードルを下げ、気軽さを出しました。チャット形式のUIは、サイトへの問い合わせではなく、パーソナルショッパーとの人対人のコミュニケーションであることを意識づけられたと思います。
• パーソナルショッパーのアイコンをナビゲーションバーの右位置に表示し、常に目に入るようにして、パーソナルショッパーの存在感を出しました。アイコンをタップすると、パーソナルショッパーページや出品アイテム一覧を見ることができます。
• 他人のお問い合わせ内容を見やすくしました。改修前はお問い合わせ内容がトグルに包まれて一文しか出ていなかったものを、全文出してひとめでわかるようにしました。他人のお問い合わせ内容が目に入ることで、BUYMAはCtoCサービスであり、在庫確認などの問い合わせが必要であることを伝えられたのではないかと考えています。

2 ・商品ページのお問い合わせボタンをもっとタップさせたい。

• 商品ページのお問い合わせボタンの領域を広め、件数を表に出すことで、他の人の活発なお問い合わせのやりとりに気づきやすくなるようにしました。結果、問い合わせボタンのタップ数を130%増やすことができました。

3 ・お問い合わせ一覧ページは、なんのアクションをしてほしいページなのか分かりづらい。

• 新規問い合わせボタンをアイコン化して視覚的に認知しやすいようにしました。また、スクロールしてもボタンを画面右下のポジションでフィックスさせることで、ユーザーがどのタイミングでも問い合わせフォームへ進めるようにしました。
• 新規問い合わせボタンと同レベルで目立っていた「指名リクエスト(※)」のボタンの優先順位を下げて奥へ場所を変更しました。指名リクエストボタンの優先順位を下げたことで、クリック数は減りましたがリクエスト数に影響は無かったため、ページで誘導したいアクションをよりシンプルにできました。

※「指名リクエスト」とは、自分が探している商品を世界中にいるパーソナルショッパーにリクエストすることで自分の代わりに欲しい商品を探してもらうことができるサービスのこと。

Webデザインとアプリデザインの違い

Webページのデザインの場合はPhotoshopでデザインし、コーディングまで担当しますが、 アプリデザインに関してはSketchで作成したデザインをZeplinにエクスポートして、エンジニアに実装してもらっています。

ちなみに、Webデザインの頭でアプリデザインをしてもエンジニアからの手戻りが発生することが多いです。 わたしはWebとアプリの違いを理解しないまま、アプリのデザインをはじめてしまったので修正対応に苦労しました。

たとえば…

・このボタンを押したときのボタンの挙動は？アニメーション入れる？ ・ここはページの遷移はモーダルなのか？プッシュなのか？ ・可変要素で無いパターンの場合、高さを詰めるか？ ・アラートやアクションビューの要不要 ・タブバー隠すか出すか ・なんか実装してみたらここの動きがヘン

Webページのデザインでは考慮しないようなポイントのため、アプリのデザインをするときはアプリの仕様をおさえておくことが必要です。 わたしは、モーダルとプッシュの役割の違いから勉強しなおしました。

わたしが今回特にお世話になった記事はこちらです。

• ユーザインターフェイスのデザインのヒント - Apple Developer
• iOS ヒューマンインターフェースの原則
• 初心者がアプリのUXデザインで押さえておくべき９つの原則
• [iOS版]アプリのUIデザイナーとして働き始める時に覚えておくと便利な用語

わたしと同じように、これからiOSのアプリデザインに挑戦するという人がいたら、ひとまずAppleのヒューマンインターフェースガイドラインは必読です。 アプリの仕組みを理解することで、エンジニアとの共通言語が増え、コミュニケーションもより円滑になります。

BUYMAのiOSアプリチーム

とこんな感じで、iOSエンジニアに助けてもらいながら、お問い合わせ画面を新しいデザインにすることができました。

Webデザインをするとき、HTMLやCSSのコーディングのことまで考えながらデザインしますが、 同じようにアプリデザインでもアプリエンジニアの実装のことも考慮してデザインできるデザイナーでありたいなと思います。

デザイナーだけでデザインをするというよりは、チームみんなで良いプロダクトになるよう日々ディスカッションしています。 BUYMAのiOSアプリチームのメンバー構成は、デザイナー・エンジニア・MDでアプリの改修やブラッシュアップをおこなっています。

わたしたちと一緒にiOSアプリをつくっていくメンバーを募集しています。 現在ディレクターが不在のため、特にディレクター職の応募をお待ちしています！

www.enigmo.co.jp