VALUS Engineer Interview|後編

理念とカルチャーの浸透が開発の肝。
ユーザーに愛されるプロダクトを開発できる理由

Outline

アウトライン

DDD、スクラムなどを用いてモダン開発を行うバリュース。前編では、レガシーな開発環境からどのように現代的、モダンな開発手法を導入したのかについて紹介しました。
後編では、主力事業のプライスサーチを開発するチームは、何を大切にして、どのように働いているのか。エンジニアチームとして、バリュースとして、どのような思想を元に開発を行なっているかを語ります。

責任のある「自由」を追い求める。

坂本バリュースの「働き方」についてはどう思いますか?

石川制度的な面で言うと不満はないですね。働き方、ワークフローの点でも不満はないかなと。フラットで、「自由」という感じはしますよね。

山地残業もほぼないですよね。プライスサーチのリニューアルをかけたタイミングではじめて残業が発生したけど、それも無理やりというよりは残りたい人が残っていたという感じでした。

飯田そうだね。基本は19時くらいには帰って、遅い時に21時になるくらい。最近はリニューアルも落ち着いたから早く帰る人が増えた。

石川モダン技術の採用やワークフローの整備が進んだこともあって、以前よりも働きやすくなっていると思います。

飯田リモートワークとか完全フレックスとか、今はまだ一部しか実現していないけど、基盤はできたと思っています。

坂本働き方もルールが決まっているわけではなくて、自分たちで作ることができますからね。

飯田ここからさらに自由度を高めるためには、チームを小さな会社に見立てて動けるように、予算をつけたりする。責任は増えるけどその分裁量は増えて、動きやすくはなるかなと。体制については色々思考中です。
ルールはなくても仕組み的に信頼しやすい、そういう状況をつくりたいですね。

石川自分たちが働きやすいように、自分たちで変えればいいっていうのがバリュースらしさですね。

山地制度がない、作りやすいっていう利点は、裏を返せば決まっていないことが多いということでもありますよね。

飯田そうだね。ただ、決まり切っていない部分にも最低限の雛形はできていると思っていて、それを実現すればいいなと思っています。自由はやっぱり難しくて、自由の中にも最低限のルールが必要。

坂本「自由」は、好きに遊んでていいという意味ではないですもんね。バリュースなりの自由を、共通認識として持つための何かは必要ですね。

飯田そうです。人が増えてきつつあるから、全くの制度なしは難しい。でも、縛りすぎるのもよくない。人が増えても共通認識を持つために、ある程度の基準を設けた自由であればいいのかなと思っています。
それが文化になっていくし、バリュースの文化は固まりきっているわけではない。新しい文化が生まれるといいですね。

石川それは面白いですよね。どんどん変化する受け皿はある。制度やルールとして固めすぎないでおく。受け入れることで変化して、何かが生まれる。

飯田制度やルールをBitbucketでバージョン管理して変遷を見るのも面白いかなと思っています。プルリクして承認されればそれが制度・ルールになるとかね。

山地そこの「自由」が、共通認識になればいいですよね。今は少人数だから、ある程度共有できている。増えてきた時が楽しみです。

坂本そうですね。一人一人が責任を持って成果にコミットした中での「自由」が、バリュースが理想とする形です。同意です。

開発フローも「バリュース流」に作り上げる

山地開発に管野さん(代表)はあまり絡まないですよね。

石川最初は開発MTGにもいたけど、モダン開発の導入の流れで、管野さんの意思決定フローも自動化されましたね(笑)

飯田基本ノータッチで、報告があれば聞くという感じですね。ずっと参加していて、エンジニア自身で意思決定ができること、報告ベース、共有ベースで業務を進めても問題が起きないことを把握した結果ですね。

坂本僕としては、管野が入らなくても大丈夫な体制を作るのがミッションですから、いいことかなと。本当にフラットな体制にしようと考えているんだと思います。

飯田ツールの導入などお金が絡むときはまだ相談が必要ですけどね。そこもある程度は予算を持って、自動化できるのが理想です。

山地技術選定にも、管野さんはやっぱり関わっていないですよね。

普段の開発も和気藹々と

飯田基本は現場のメンバーで相談しながら決めていくからね。今の技術選定はいいところに落とせたかなと思っています。バックエンドはJava8 + Spring Boot、フロントエンドはVue.js、最初はJavaではなくScalaを考えたけど、やはり導入コストや採用を考え、まずは無難にJavaにしました。今後必要に応じてScalaとかGoとか考えてもいいかなと思います。

石川いい選択だったと思います。そのときのメンバーが全員Javaができたということもありましたが、Spring BootやIntelliJ、Lombok等の良いツールが揃っていて開発効率も悪くない。バランスのとれた選択でした。

飯田あとES6など新しい技術を使っていたり。webpackっていう、SassをCSSにしてくれたり、ES6を汎用的に使えるJsに変えてくれたりするツールも。今まではGulpとかGruntでコードを書いていたのを、設定すれば自動でできるんです。
最近、RailsもwebpackをRailsの中に入れたっぽくてそこの選択は間違えてなかったなと思いましたね。

山地綺麗にいいところを取れた感じですね。

坂本開発フローもエンジニアで定義していますよね。

石川大枠は月曜にプランニングをして、その後は毎朝夕に何をやるか、やったかを共有。1週間でスプリントを回すので、そのための話を都度する感じですね。

飯田最近はプロジェクトが分割されたので、プロジェクトごとにスクラムを回してます。ただ、スクラムをやるには人数が少ないので、スクラムの良いところを活かし、アレンジしてプロジェクトに最適なやり方にカスタマイズしています。それに合わせて、ワークフローもバリュース流にしています。

エンジニアの妄想を無くして、効率のいい開発を

石川開発のフローにもバリュースらしさが出ていると思います。

坂本そうですね。まずお客さんに提供する価値を共有。僕が用意しておいた外部仕様や実現方法の素案に対して、エンジニアと一緒に、ビジネス観点とエンジニア観点で意見を出し合って最適解を見つけていきます。

山地最適解が見つかった段階でタスクを明確にし、あとは各自で進める。終わればコミットして、各メンバーがプルリクを承認、その後CIが走って、ステージング環境にデプロイされ、坂本さんが確認して問題なければ本番にデプロイ。

飯田多い日だと、1日数回は本番にデプロイしてますね。masterマージ後にすぐに本番にリリースする、いわゆるGithub Flowです。今のところ事故はないです。まだリスクとかを考え本番へのデプロイは自動化してないので、リクスを取り除き最終的には自動化したいですね。

坂本デプロイのサイクルは短いと思いますね。自動化してさらに効率は上がったし、意思決定も早い。

飯田あと、開発フローでいうと、お客さんとの距離の近さも特徴かと。お客さんが直接来てくれて検証してくれるとか。

坂本検討中の新機能を一緒に見てくれたり、ユーザテストしに来てくれるお客さんもいます。

飯田かなり協力的ですよね。

雑談も仕事の話も真剣に、フラットにしている

坂本他にはリリース前の機能についてのアンケートやヒアリングにもかなり協力していただけています。このように協力していただけるのも、価値を届けることができているからなのかなと思います。

山地「価値がある」と思い込んで開発してみて、ニーズとの乖離があることがよくありますが、バリュースにはそれがないんです。全員が「お客さんにとって意味があるの?」という視点を持っているから、無駄な開発がないんですよね。

飯田作らない開発というか。エンジニアの妄想は意味ないし、シンプルにつくってリリースして、フィードバックをもらった方がいい。考えすぎたり、凝りすぎたりすると複雑になってしまう。技術的な負債はできるだけ作らないで、価値のあるものだけ作ればいい。

坂本あ、僕聞きたいんですけど、どういうときに「お客さんに価値を届けられた」って感じますか?

山地一番は数字が見えるといいなと思います。定量化ですね。

坂本ログイン回数とか契約数、解約数とかですかね。

山地でもそこは数値として出にくいですよね。to Cではないから、利用時間とか機能の利用度とかですかね。悪いものは使われないし、いいものは使われますから。

飯田改善要望も使われているからこそできる要望ですよね。そういうのも柔軟に受けいれられるのはいいところですね。

理念に共感しているからできる、最高のプロダクト開発

坂本バリュースの皆は、かなり顧客主義ですよね。

石川僕はバリュースの理念にはかなり共感しています。「喜ばれる喜び」という、お客さんに喜んでもらえる、価値を感じてもらえることが喜びになるという点です。至らないところもまだあるけど、みんなが共感していると思います。

飯田それに、バリュースは「お客さん至上主義」ではなくて、自分たちの環境や働きやすさも同列で、その上でお客さんにも価値を渡せる。win-win-winの構造で、それは昔から僕が考えていたことと同じでした。偶然一致しましたね。

石川みんなそうだと思うんですが、本質に向けて直接ソリューションを提供しているところもすごいなと思います。
お客さんの言葉をそのまま受け取って機能を増やすのではなく、本当の課題は何か?と裏側にあるものを考えて開発する。

飯田疑って作る、みんなで話し合ってから結論を出すことで、それが実現できていますよね。

坂本さっきの飯田さんの話、win-win-winって、管野もよく言っている「八方良しの経営」が軸にありますよね。お客さんにも社員にも経営者にも投資家にも、社会に対しても良い事業、会社を作ろうっていう。

山地そこが働きやすさとやりがいにつながっている面は大きいと思います。

坂本メンバーの雰囲気や考え方的な面はどう思いますか?

山地いい意味で頑固な人が多いですね。

石川プロダクトに対しての思いが強い。

飯田個性がありますよね。

山地自分の軸は絶対的だけど、人の話はちゃんと聞く頑固って感じの癖がある人が多い気がします(笑)

飯田すごい人だね(笑)

石川あーでも、そんな感じしますよね。

山地自分の考えがあるけど、周りの人と情報を合わせて最終判断は下す。でも揺らがないというか。中途半端な妥協、思考停止の妥協はないという感じ。周りと自分のラインを決めている感じで、投げやりには決してなりません。あと、曖昧なところは無くそうという文化がある。よしなに〜っていうのが絶対にないんです。

飯田あいまいがいろんな悪を生み出すから、そこは無くしたいですよね。お互いの感覚のズレが曖昧だとバグるし、見える化したいなと。

坂本新しい人が入ってくる時も、やっぱり「人の軸」は大切にしていますよね。全員会う採用をしますし。

石川そうですね。それぞれが違う視点で、バリュースで一緒に働けるかを見ている。

飯田そういえば、坂本さんは最初に面接をすると思うんですが、どういうところを見ているんですか。

坂本実行力は大切にしています。目的に対して行動を起こせる力。目的を実現する為に、もし技術や知識が必要であれば、勉強も自然にしていけるような。

前後編で、バリュースのエンジニアチームの普段の雰囲気から、開発の思想、バリュースの価値観を見ていただきました。
バリュースのエンジニアチームでは、バリュースの考え方、開発の思想、エンジニアたちの雰囲気などに共感してくれるメンバーを募集しています。ご応募は、RECRUIT欄からどうぞ。
また、バリュースは理念が浸透した組織も強みのひとつ。もしよろしければ、ビジネスチームインタビューなどもご覧ください。

Interview Member

インタビューメンバー