VALUS Engineer Interview|前編

バリュースの開発がレガシーから、
モダンに生まれ変わった時

Outline

アウトライン

バリュースの歴史は、2008年。代表の管野1人の会社として始まりました。
「仕事で喜ばれる喜びを感じられる会社をつくる」そう考え続けてきた菅野は、そのミッションを実現しやすいビジネスモデルを実現させるために、創業当初から続けてきた営業中心スタイルで、レガシー開発を行なっていた環境を改善。徐々にモダン開発を用いる、開発中心スタイルの会社へと転身することに成功しました。
インタビュー前編では、レガシーな開発環境を変えたきっかけ、そしてモダン開発の浸透度。当社開発体制の変遷の歴史をエンジニアたちが語ります。

モダン開発への移行の軌跡

山地僕が入社したのは2017年2月なんですが、それまでは今みたいな開発環境ではなかったと聞いています。どんな感じだったんですか?

飯田そうだね。僕が入社したのは2016年7月ですが、そこからでもだいぶ変わったと思います。

石川飯田さんが入ってきてから、かなり変わったと思いますよ。僕と坂本さんがこの中では古巣で、僕が2015年11月、坂本さんはその前からいますよね。

坂本そうですね。僕は2015年の1月に入社したのですが、その時はエンジニアが2人しかいませんでした。その頃から考えると、「体制」「環境」「技術」、すべて変わっていますね。(注釈:当時は2名。2017年8月時点で8名のエンジニアが在籍している)

左から、坂本・飯田・山地・石川

山地そうなんですね。レガシーな開発環境をすべて変えるってかなり大変だと思うのですが、どういう経緯だったのですか?

石川飯田さんが入ってから、一気に技術やツールの刷新をしたんです。そこから変化が加速して、一気にモダンになりました。

坂本こうへいくん(石川)もそれ以前から新しい技術、ツールの導入を積極的にしていたし、2人が揃ったのが大きいと思いますよ。

飯田変えすぎた感もありますが(笑) ドラスティックに、一気にモダンにしましたね。

石川僕が入ったとっきにSlackとBitbucketを導入したのと、esa.ioっていうナレッジを書き留めるQiitaみたいなものを導入しました。 飯田さんが入った時は、リプレイス開発だったので開発言語も変えましたね。Jsもvueに。モダン技術を全部入れました。インフラも今までVPS借りてたのをAWSで作るようにしたり。あとはエラーの検知やサーバー監視もMackereに。エラー発生通知もメールだったのをRollbarに変更しました。 CIがなくて、テストもなかったのでテストを書いてCIを作るようにしました。チケット管理はRedmineからJIRAに。メールサーバーも自前からSendGrid。デプロイも自動化して、通知は全てSlackに集約しました。

山地本当に一気に変わってますね(笑)

石川勤怠がメール管理だったんですが、それも自動化してSlackにしました。

坂本社シスも全部移行しましたね。

飯田僕が過去に在籍していた会社では、クラウドサービスを積極的に使って、業務が効率化されていたんです。そのワークフローをバリュースにも導入したかった。
なので、Office系も使うのをやめました。共同作業のしづらさや、どれが最新か分からない等の理由で、G Suiteのサービスを使うようにシフトさせたんです。(G Suite導入準備中)

石川それこそ設計の手法、テストの手法もモダンへ移行しました。DDDを導入したのもこの時ですね。

飯田リプレイスのタイミングでしかドラスティックな変更はできないので絶好のチャンスだと思いました。DDDは導入コストは高いけど、保守をしていく上では効果的な設計手法なんです。
以前の会社でも使っていたことがあって、後々効果が出てくるのが分かっていたので諦めずに頑張りました。それと人財採用にも有利になるし、バリュースの武器にもなると思ったのもDDDを採用した理由です。

山地僕自身、バリュースがDDDで開発をしていることを知って、興味を持ったので成功ですね(笑)

飯田あとは、Dockerの採用ですね。Dockerを使っている会社も増えてきてドキュメントも充実してきたし、また、開発環境構築にかかる時間が減らせたり、開発環境のガラパゴス化も防げるなどメリットが大きいので、Dockerを採用しました。

坂本Ansibleもですよね。

飯田コードでサーバー管理しないとサーバー職人ができちゃうんで、みんなができるように。Chefっていうのもあるんですが、学習コストが高くなるし、ちょうどよかったんです。
デプロイはPython製のFabricというデプロイツールを使っています。Ruby製のCapistranoも検討したのですが、Fabricに比べ学習コストが高い。それでFabricを採用しました。デプロイは今坂本さんにお願いしてますね(笑)

石川こう考えると、本当に劇的な変化でしたね。

飯田全とっかえでした。管野さんと話していて、開発体制を変えたいという感覚は共有できていた。なので、本当に一気に、ガッと変えました。最近はだいぶ定着してきたと思います。

山地僕が入ってきたタイミングで、ちょうど出来上がったみたいな感じですか。

飯田それ以前から仕込んでいて、リリースしてから定着して、効果が出てきたっていうタイミングに山地くんが入ったんです。昔よりかなり「エンジニアらしい会社」になりました。

坂本本当に変わりましたね。技術書を買うことも増えて、定期購読も始めましたし、技術的な会話も増えました。

飯田それに、受け皿としても、モダンな開発環境ができて、色々な人が入りやすくなったと思います。あとは実際のプロダクト開発のKPI管理や、目標達成に向かってどうするか。お客さんのためにどこまで誠実にプロダクトを作れるかという、考え方の部分があえば、エンジニアとして一緒に働ける。その間口は広がったと思います。

山地なるほど。これまでの経緯を知れてよかったです。思ったよりも劇的でした。

営業会社が生まれ変わった瞬間

山地想像以上のレガシーな体制からの変革に驚きました。僕は少し触れましたが、DDDに関心があって入ったところもあるのですが、みなさんはどういうところが入社の決め手だったんですか?

坂本僕が入ったときは、開発環境も社内システムもレガシーで、営業会社的な文化も強かったですね。
でも管野が当時から言っている理念「喜ばれる喜び」に共感したんです。「喜ばれる喜び」って、相手のことはもちろん、関わる人たち全てが幸せになる働き方を目指す考え方なんですよね。
だから、お客さんのことを考えてしっかりといいものをつくる。その上で、提供する僕たちもお礼を言ってもらえたり、適正な報酬をいただける。
僕自身、仕事は等価交換がいいと思っていました。仕事をしたら、その分の報酬や喜びが返ってくる。いいものを提供して、喜んでもらえる。与えすぎも、もらいすぎもしたくないんです。その感覚を、企業で体現しようとしているところにとても共感しました。

山地入った当初から「喜ばれる喜び」の理念は社員に浸透していました?

坂本いや、正直なところ、最初は浸透しきれていなかったと思います(笑)ただ、管野はブレないんです。理念を信じて、曲げないで貫いていた。これなら確実に「喜ばれる喜び」を実現できる組織にしていけると思っていました。

飯田たしかに、その結果「顧客のための開発」や「正しい開発」ができてますもんね。

坂本そうですね。自然に理念に共感している人たちも増えて、目指していたものが形になってきたと思います。その過程のひとつとして、開発環境の刷新もあったと思います。

飯田なるほど。理念に共感した部分が大きいんですね。こうへいくんの入社の決め手は?

石川僕が入社したときも、開発環境はレガシーでした。ただ、僕は規模が小さくて、人数も少ない会社を探していた。というのも、エンジニア以外の役割、たとえば仕様設計やデザインなど、色々な業務ができる会社を探していたので、規模が小さい方がやりやすいだろうと考えていました。
そのときもバリュースは少数精鋭って感じでしたし、会社のビジョンにも共感したので、入社を決めました。

飯田エンジニア以外の役割ができるところが大きい。

石川そうですね。もちろんエンジニアリングは1つの武器ですが、デザインやビジネスに近い業務ができる環境がよかったんです。会社はまだまだ発展途上で、業務が多いけど、だからこそ自らの手で変えていけるところが魅力的ですね。

坂本本当に柔軟で、社員の意見が重視される文化ですよね。

石川そうなんです。「こういうのやりたいです」「いいね」っていう共感が、会社の制度や仕組みになることも多い。でもルールだから、制度だから、と厳格になりすぎないところも動きやすさと働きやすさにつながっていると思います。

坂本たしかに、働きやすいルールづくりは徹底されているし、そこにも理念が反映されているよね。

DDDを採用したバリュースとの出会い

坂本飯田さんの入社の決め手は、どういうところでしたか?

飯田僕はタイミングもありますね。当時在籍していたスタートアップがダメになったタイミングで、採用サービスで何度かアプローチされていたバリュースからちょうど連絡がきました。
話を聞いてみると、勢いもあるし少数精鋭。これからのチーム作りに貢献できる部分がありそうだなと思って、入社を決意しました。
あと、ユーザーさんとの距離が近くて、フィードバックを受けやすいんです。エンジニアとしては、ユーザーとの距離が近くて、声を聞きながら開発ができる環境ってとても魅力的なんです。

坂本本当に距離は近いですよね。直接話す機会も多いですし。そういうきっかけもあって、入社後はドラスティックな開発体制の刷新を行なったわけですね。

飯田山地くんは、さっきDDDに関心があったという話をしていたけど、やっぱり決め手はDDD?

山地そうですね。バリューオブジェクトの記事で知って興味がありました。
前職で開発していたプロダクトでは変更による障害が多いという問題があって、解決策を調べているとDDDに当たったんです。DDDを勉強すればドメインを忠実に再現した変更にも強い柔軟なプロダクトにできるのかと。
前職で使ってみようと思っていたのですが、なかなか開発環境を変えるのは難しかったんです。そこで、DDDを導入している、あるいは始めようとしている会社を探したらバリュースに出会ったんです。

石川坂本さんと話していて、すごくいい人がきたという話をしました(笑)

山地そうだったんですか(笑)面接では坂本さんのプロダクトに対する熱量がとても高く、プロダクトに向き合えるいい会社だなーと思いました。そのときにもDDDの話をして、実際のコードも見せてもらいましたね。

石川コードを見せてって言われたのは初めてでしたよ。

飯田ドメインモデルが一通りできたときに見せたんだね。ちょうどいい時期かも。

山地そうです。本当にDDDを導入し始めの時期、僕としても一番興味のある時期でした。こうへいさんからも技術の熱量も感じて、いい会社だなと。他の人たちも全員会って、安心して入社しました。
それにしても僕が入社したときにレガシーな感じは全くなかったので、これまでの話を聞いてびっくりしてます(笑)

飯田タイミングがすごくよかったですね。DDDって、普通に書くだけではなくて「どうやる?」という部分を考えないとダメなんです。理解は難しいし、色々な技術がある。僕も最初は嫌いだったんですが、後から効いてくるんです。
それに、採用に役立てたいと思っていた面もあるので、いきなり成果でてよかったです(笑)

山地DDDに釣られた感じですね(笑)

飯田でも、そもそも考えて書かないといけないし、難しい。優秀な人を採用するための施策なのでよかったかなと思いますよ。

前編では、バリュースの開発環境の歴史、そして技術環境について話したエンジニアたち。後編では、実際の開発の際にどのような姿勢、考えで開発を行なっているのか。エンジニアに託された裁量や、ビジネスへのコミットなど、チームとしての「バリュース」について語ります。

Interview Member

インタビューメンバー