ストレスなく開発に没頭! UNCOVER TRUTH 流・開発環境の改善法【エンジニア対談】

こんにちは。採用担当の中野です。
今回は、UNCOVER TRUTH の開発環境について、エンジニアの熊谷さんと金子さんにお話を聞きました。

足元の業務に追われて開発環境の改善まで手が回らない…というもどかしさを抱えているエンジニアの方は少なくないそうですが、当社のエンジニアに聞いてみると「 UNCOVER TRUTH ではそういったストレスを感じることがないよう、意識的に開発環境の改善をおこなっている」とのこと。

実際、どのように取り組んでいるのかインタビューしてきました。

「環境を最新に保つ」「変化に柔軟に対応」を実践

――まず、開発環境の改善に対して、チーム・個人としてどのような考えを持っているのか教えてください。

熊谷: チームとしては「ライブラリなどを常に最新の状態に保っておく」「変化に柔軟に対応していく」というのがベースの考え方ですね。
ライブラリのアップデートは、自動で更新をチェックしてくれるサービスを利用して恒常的にチェックしています。あとは、アップデートの状況に応じてツールを入れ替えたり、便利そうなツールを見つけたら取り入れてみたり。この状態を常にキープするように心がけています。

個人としては、開発環境を構築する手順を、なるべくシンプルに整えるように意識しています。
例えば、フロントエンドとサーバーサイド両方の環境が必要な人もいれば、そうじゃない人もいる。それぞれが必要とする環境を用意する際の手順が煩雑なのはナンセンスですよね。なので、手順上きちんと分けて、少ない手数で環境構築ができる状態にしました。チームメンバーからも「作業が楽になった!」と言ってもらえました。

――金子さんはいかがでしょう?

金子: UNCOVER TRUTH はリモート勤務 OK ということもあって、「どこでやっても同じ手順で開発できるようにしておく」というのはチーム全体で意識していますね。
これまでの経験上、本番環境・検証環境・個人端末の環境の中で、一部の環境向けにコードが書き換えられている、というケースも少なくありませんでした。個人としても、ローカルで開発環境を作る際にはその点に気を付けています。

あとは、開発環境をわざと消して再構築する、というのを手が空いたタイミングでやるようにしています。そうすることで、PC のデータが飛んでしまった時にすぐに戻せますし、新しく入ってきた人が開発環境の構築でつまずくことも回避できるので。手が空いた時に作り直して、手順を更新しておくようにしているんです。

熊谷: 僕もちょくちょくやってますね。避難訓練みたいな感じで、いざという時に自分が困らないために、みたいなイメージですかね。
OS やライブラリの更新があった時に、以前作った環境だとうまく動いていたものでも、まっさらにして作り直したら動かなくなるケースもあるんです。
いつ誰の環境が壊れるか分かりませんし、UNCOVER TRUTH はコンスタントに人が入ってくるので、手順が古いままにならないよう気を付けています。

kumagai

「最初の1人が地雷を踏み抜く」をチーム全体で徹底

――おざなりになりがちな開発環境の改善を継続してやっていくために、意識しているポイントはありますか?

熊谷: 「コンピューターはいつ壊れるか分からない」という意識は常に持っていますね。
例えば、自分の環境が壊れてしまったとして、古いままの手順に沿ってやったら環境が構築できないこともあるんです。不具合を探して取り除いて…というのが忙しい時期に起きてしまったら、開発にも影響が出ますよね。
そうならないように、「今だったら壊しても大丈夫」というタイミングで意識的に壊して、手順を新しくしておいた方が効率的なんですよ。

金子: すごく共感できますね。あと、躊躇せず開発環境を壊せるのは、しっかりバックアップがあるからできることだとも思いますね。
ドキュメントだけじゃなく手順としてきちんと残すことをチームとして徹底しているので、安心して壊せるというか。

熊谷: チームによっては、秘伝のタレのように同じ環境を使い続けているところもあると思うんですよね。
OS のバージョンアップがあった時はチームみんなで開発環境を作り直すようにしているんですが、業務端末が Mac なので、バージョンアップに伴って作り直す頻度が比較的高いのかなと思います。

――開発環境の点で、UNCOVER TRUTH のココが良い!というところを教えてください。

熊谷: 開発対象のソースコードやアプリケーションのプログラムなどの履歴が、ワンセットで全部残っているところですね。
どのライブラリがいつバージョンアップされたか、どうやって開発環境を作ってきたのかなど、全ての履歴を残すように徹底しています。
ドキュメントとして残すのは他社もしていると思いますが、変更後の手順で動かなくなった時にも履歴があれば前の手順にすぐ戻れるので、そこは良いところだと思いますね。

あとは、開発環境をゼロから作り直す場合、スムーズにいかなくて最初の1人は地雷を踏んで痛い目に合う…というケースは結構ありますね(笑)。
でも、チーム全体として「最初の人がとことん地雷を踏み抜いて問題点を洗い出しておく」というメンタリティが浸透しています。なので、自分が問題にぶつかった時に Slack で質問すると誰かしらがすぐにコメントをくれるんです。そこも良いところだなと思いますし、自分もなるべく率先して地雷を踏みにいこう!という意識でいますね。

金子: 自分が地雷を踏む最初の1人になるケースもありますが、誰かしらが先に試して回避策を残してくれていることも多いので、行き詰まることは少ないですね。
リモートのメンバーが多いこともあって、業務にまつわることは全て Slack 上にログを残すよう徹底しているので、問題にぶつかった時は Slack を見れば、他の人が試した方法を確認することもできます。

hirokinko

理想的な今の状態をキープしつつ、より「楽になる仕組みづくり」を

――金子さんは以前、開発環境を整える時にOSSに貢献したそうですが、その時のことを教えてください。

金子: 入社したばかりの頃でしたが、開発環境を整える時にどうしても OSS を直さないと動かない状況になったんです。一般的には、諦めて別の方法を探すケースの方が多いと思うんですが、周りに相談したらさらっと「じゃあプルリクエスト送っといて」と言われて、「まじか!」と思いましたね(笑)。
Homebrew でインストールしたパッケージの一部に1行追加するだけだったんですが、初めてだったのでかなり緊張しましたね。コントリビュートのお作法もよく分からないし英語力にも自信がない、でもこれをやらないと動かない…と、かなりプレッシャーでした。でも、送ってみたら意外とすんなり受け入れてもらえました。

熊谷: 確か、Mac OS のメジャーバージョンアップのタイミングだったかな。そこが直らないと OS が古いまま開発を進めないといけなくて、手順も大きく変える必要があったんです。なので、すごくありがたかったですね。
会社として開発元への貢献を推奨しているので、仕事の中でオープンソースに貢献して対外的なアピールをしたい人にとっても良い環境なんじゃないかなと思います。

――今後、「こんな風に開発環境を改善していきたい」と考えていることはありますか。

金子: 今が理想的な状態なので、この状態をキープしたいですね。
エンジニア全員が「開発環境を整えておく」という意識を持っていて、きちんと実行もできているというのは入社前の段階で聞いていて、そこが入社理由の1つでもあったんです。他のメンバーも、そこに対してフラストレーションを抱えていた人も多いんじゃないかな。

熊谷: こだわらない人もいるので人によると思いますが、UNCOVER TRUTH には「開発環境を整えておきたい」という人が比較的多いと思いますね。

僕個人としては、開発環境を作った段階で、「 USERDIVE 」の動作検証に使うダミーデータを手軽に入れられる方法がないかな、と模索中です。
現状は、機能開発を担当した技術者本人が模擬画面を操作して手動でデータを溜めていて。このやり方だと開発環境を新しく作り直した時に、手動でデータを溜め直す必要があるので毎回同じ手間がかかるんですよね。そこがもっと楽になるような仕組みづくりを、今年中にやりたいと思っています。

――熊谷さん・金子さん、ありがとうございました!

two

同一カテゴリの関連記事