【CTOインタビュー】"泥臭さ"と"瞬発力"で成長し続けるユニークビジョンの技術 | ユニークビジョン
個性豊かなユニークビジョン社員の入社に至るまでの経歴や、どんな想いをもって日々の仕事に打ち込んでいるのかなどをご紹介する「ユニークビジョンではたらく仲間」。 今回は、ユニークビジョンの創業メンバーでありCTOを務める青柳 公右平に話を聞きました。 ...
https://uniquevision.co.jp/recruit/cto-aoyagi
個性豊かなユニークビジョン社員の入社に至るまでの経歴や、どんな想いをもって日々の仕事に打ち込んでいるのかなどをご紹介する「ユニークビジョンではたらく仲間」。
今回は、ユニークビジョンのエンジニアとして活躍し、2021年の年間MVPにも選ばれた山本 一将に話を聞きました。
前職では、鉄道会社で組み込み・制御系のシステム開発を含む運行管理を行っていました。社会的なインパクトの大きい仕事ということはもちろんありますが、鉄道がどのように動いているのかという裏側が知れることや、大きなシステムを動かすこともとても面白かったです。
品質管理は本当にすごくて、それが全てとも言えるほどのものでした。ユニークビジョンでも品質にはかなり力を入れていますが、テストにかける期間や熱量はやはり人命が関わることもあり、文字通りけた違いでしたね。
ただ仕事の進め方には前時代的な部分も多く、それを改善しようとしているのは伝わってきましたし、何か言えば聞き入れてくれる会社ではあったのですが、なかなか流動的に変わっていける規模感ではなかったので変化はあまりなかったです。研究開発に関わらせてもらっていたので社内では比較的新しいことに触れられていたポジションではあったのかもしれませんが、30年くらい動いているシステムの保守や品質維持がメインの業務だったので、新しいものを作ったり新しい技術に触れたりしたいという気持ちが大きくなってきていました。6年ほど働いて、一通り経験できたかなというタイミングで転職を決意しました。
転職を考え始めたときに組み込み・制御のようなローレイヤーの部分ではなく、もっと広い世界を見てみようと思って本格的な転職活動ではなくいろんな会社を見ている段階のときに、ユニークビジョンに出会いましたね。
ユニークビジョンはSNSマーケティングの分野で主にweb系の開発をすることが多い会社ですが、僕はもともとSNSをよく触る方ではなかったですし、web系も興味はあったものの実務経験はない状態でした。なのでカジュアル面談で話した代表の白圡が何を言っているのか当時の自分には全然理解できなかったのですが、逆にそれが面白そうと思って入社を決めました!
一次選考のプログラミング試験の中ではある定義についてCTOの青柳とかなり議論になったのですが、入社試験でそのような事が起きたのは後にも先にも自分だけだと聞いています...その後の面談も、疲れ果ててヘロヘロになっていましたね(笑) さすがに落ちたと思っていたのですが、内定をもらって無事入社となりました。
個人的には、仕事とは別にコンピューター将棋もやっています。元々は大学で将棋のAIを研究していたのですが、卒業後も個人で開発を続け、2015年には世界コンピューター将棋選手権で9位まで行きました。
ユニークビジョンに入社して最初は、Twitter上で自動返信を行うキャンペーンを中心とした仕組みのBelugaキャンペーンのチームに在籍し、次はセルフサーブ型でお客様に事後抽選のキャンペーンを使っていただく機能などのあるBeluga簡単キャンペーンのチーム、そしてBelugaキャンペーンをLINE上で実施するBelugaキャンペーンfor LINEのチームと移ってきて、現在もこちらで開発にあたっています。
Beluga、Belugaキャンペーン、Belugaキャンペーンfor LINEは弊社の主要サービスとなっていますが、これら3つをすべて経験してきている人はほぼいないですね。
この中で一番長いのは、数年目になると思いますが現在も在籍しているBelugaキャンペーンforLINEです。このチームには最初から関わっていたわけではなく、LINEさんとの関係を強化し始めたくらいのタイミングで開発も強化していくということで、参加することになりました。LINEの案件は最近急速にお話が増えてきているところなのですが、最初の1年は数件ほどしか案件がなくて、開発は進めるもののなかなか使われない期間もありましたね。
業務としても1エンジニアとしても、作っているシステムはキャンペーンを動かすためのもので、どうやってお客様に使ってもらうのかをディレクターと一緒に考えながら、正しく理解・説明することは強く意識しています。
僕はエンジニアとして、「技術者倫理」というものを大事にしています。エンジニアは専門職なので本気で他の職種の人をだまそうと思えば可能ですし、もっと簡単に作ることができるのに難しいものと偽ってしまうこともできます。ですが専門職の領域だからこそ真摯に責任を持ち、自分の専門分野に誇りをもって関わっていたいと思っています。
今はチームの中でも技術の判断をしたり、エンジニアから出てきた工数の妥当性をPLと相談したり、コードレビューを行って全体を見渡せるようにしたりなど、いわゆる開発リーダーとしての業務も行っています。
何を作るのかというところはディレクターと一緒に考えますが、どう作っていくのかというところはエンジニアがきちんと考えていかないといけない領域です。今作ろうとしているこの機能だけ満たせれば、というだけの思いで作っていると先々で手を加えることが大変になってしまうので、システムが今後どう維持されていくのかということも考えながら開発しています。
1エンジニアではありますが開発リーダーとして、関わるサービスの成長や他のメンバーのことも考慮して全体を見たときに整合性が取れるように、技術的なところはすべて関わるようにしていますね。山本一将がいれば開発側は大丈夫だな、と思ってもらえるように仕事をしているつもりです。
僕はメインの開発業務以外に、ワーキンググループにもいくつか参加しています。現在参加しているのは、エンジニア勉強会、開発方法論、SQLユーザーグループ、レビュー改善の4つです。
エンジニア勉強会のワーキンググループは、エンジニア全員参加で業務時間内に毎週行っている、勉強会の運営チームです。みんな業務をしながら日々勉強していますが、エンジニアの勉強はアウトプットをしてこそ身になってくると思いますし、勉強会は開発チームが異なるエンジニア間の技術的な交流の場にもなっています。
また、社内だけの勉強会ももちろん良いのですが内輪の話ばかりになりがちなので、最近は週一回の勉強会の中でも月に一度は社外向けの開催もしています。社外向け勉強会だとやはり普段より緊張感があるので、インプットの質もアウトプットの質も上がると感じています。勉強会で発表したことは出せる限りではQiitaにも掲載してもらっているのと、12月にはエンジニア全員でアドベントカレンダーも書いているので、ユニークビジョンとして世に出しているコンテンツ量も増えてきていますね。
開発方法論のワーキンググループでは、特定の言語にフォーカスするのではなく、会社全体の開発スキルを向上させるためにもっと抽象的な部分から議論をしていきます。ユニークビジョンでは常にベストな開発手法を目指していますが、それでも品質が上がりづらかったり現状に即していなかったりした時には、手法自体を適宜見直すことで開発スピードの改善を行っています。最近では、システムを作るための構造自体をどのように決めていくべきなのかということを議論しています。
どのサービスでも開発を始めるときに構造をしっかり考えていますが、その時の議論は目に見える形で残っていないことが多いため、後から開発に参加した人がどうしてこの構造になっているのか分からないこともありました。それを明確に文書として残し、その議論の進め方のベースを決めることで、なるべくみんな同じ視点をもって開発に入れたらと思っています。
SQLユーザーグループは厳密にいうとワーキンググループに満たない有志の集まりみたいなものなのですが、こちらではSQLの知識をチーム横断で共有するための活動をしています。ユニークビジョンではSQLを使うことが多いのですがそのノウハウを共有することがあまりなかったので、みんなが躓きがち、苦しみがちなポイントを中心に、全社で知見を溜めていっています。SQLはサービスに関わらずどの開発チームでも使う技術なので、偏らず共有できるよう、SQLユーザーグループのメンバーが各開発チームに1人はいるようにしています。
レビュー改善のワーキンググループは、自分の中で今一番力を入れているところです。ユニークビジョンではコードレビューの文化をかなり重視しており、そのレビューがより意味のあるものになるようにと活動しているチームです。コードレビューはもちろん会社としての品質を担保するためという面が大きいですが、同時に教育的な側面も大きく持っています。
それもその時その時の学びだけでなく、若いエンジニアたちがこれからどんどん知識を吸収していくにあたって、正しい方向で身に着けていけるようにと考えてコードレビュー制度を大切にしています。ユニークビジョンではコードレビューを成長のためのツールとしてガンガン使ってもらえたらと思っているので、怒られてしまうとか怖いとかではなくカジュアルにコードレビューを受けて、みんなが良い知識をいろんな人から受け取っていけるように改善を続けています。
ユニークビジョンには、良いエンジニアが沢山います。現状のサービスで弱い部分を改善しようとしたときにしっかり話を聞いてくれることはもちろんですし、みんな改善しようと思ってくれているのがいいなと思います。おかしなやり方になってしまっているところがあっても今は問題ないからとそのまま進んでしまうのではなく、きちんと変えていかないとという意識があるエンジニアばかりです。ユニークビジョンの全てのサービスが品質的にとてつもなく優れたソースコードだけで作られているというわけではないのですが、エンジニアたちはそのままではいけないという思いを持っていて嬉しいです。
フロントエンドの領域に強みを持つエンジニアのおかげもあって、フロント側はすごく綺麗になってきています。元々フロント側はユニークビジョンの中でもなかなか統率が取れておらず酷い状態の時もあったのですが、先ほどのSQLユーザーグループのようにフロントでもユーザーグループを立てて改善を進めたことで、劇的に変わっていきました。今はとても良い状態ですがこれがまた段々と汚くなってしまうのではなく、改善意欲の高いユニークビジョンのエンジニアたちならこれからも改善し続けていってくれると思えることも嬉しいですね。
品質に対する意識の高さも、ユニークビジョンの大きなアピールポイントです。web系だと何かあってもすぐに直せてしまうこともあり、web業界というのは品質に対する意識の差異がとりわけ大きい業界だと思っています。その中でもユニークビジョンは意識をとても高く持っており、それはエンジニア一人ひとりがしっかり考えられているからだと思います。
きちんとチェックを重ねて完全な状態で世に出すことはもちろんですが、戦略としては素早く作って世に出してからしっかり整えていくこともあるかと思います。どちらにしても、品質を気にしないで作るのではなく、より良い品質で使ってもらおうという意識がエンジニア一人ひとりにあるのとないのでは出来上がるサービスは全然違うものになります。その意識づけがしっかりとできる環境が、ユニークビジョンにはあると感じています。
そういったサービスとしての品質とは別に、コードの品質もかなり意識されています。動きはするものの、こんなコードではシステムに取り込めません!という品質的な下限もあるので、それはコードレビューの際にきちんと指摘されます。ですがコードレビューの一部として進め方の相談フェーズである「方針レビュー」もあるため、事前にきちんと話し合ってから着手できるのでそういったことは減っているのかなと思います。
サービスの品質とコードの品質は別物で、どちらに対しても意識できているのがベストです。お互いに無関係ではなく、コードの品質が保たれると新しいことにスピーディに取り組めますし、それによりサービスの品質にも繋がっていきます。
僕が入社してから見てきたユニークビジョンの変化で言うと、もともとCTOの青柳一人で行っていたレビューを分散させて、文化としてもかなり定着したことでしょうか。レビュアーが青柳一人だった時代は、1日1回はレビューに行くという決まりがありつつも行かない人もいましたし、世に出るコードのすべてがレビュアーの目を通したものかという保証は今ほどありませんでした。
そこから先述したレビュー改善ワーキンググループを中心にレビュー制度の改善と推進を行ったことで、今ではレビュアーが8人にも増えましたし、プロジェクトによってはコードレビューを受けないとコードが取り込まれないように仕組みを作っているところもあるくらい、ユニークビジョンでは当たり前に存在する文化として定着しました。
ユニークビジョンのレビューは、今や他社に比べてもカジュアルな存在だと思います。なんなら新しく入ってきた人の方がしっかりレビューを使っているように感じますね。新しい人でも気軽に相談しやすいというのは、エンジニアにとってとても良い環境だと思います。
今ではもちろん、CTOのコードも他のレビュアーが確認しています。書いた本人だけでなく他人の視点を入れた方がいいというのはCTOでも変わらないですし、そういったスキルの高い技術者のコードを見せていくことにも意味があると感じています。
あとは、以前は開発プロジェクトごとに独自の進め方やルールのような文化があったものを、「UVコマンド」という新しい規格で統一できてきていることも大きいですね。それまではプロジェクトを移ると文化ががらりと変わってしまったり、開発環境の立ち上げにおいてもそれぞれのやり方があったりしていたので、既存メンバーから口頭で教えてもらってReadmeをしっかり読み解いて、といった必要以上の手間が多かったんです。さらに様々なプロジェクトに関わってくるサービスの開発があった際、複数プロジェクト横断で同じものを動かす必要が生じたことで、この状況をどうにかしようと各プロジェクトで使われるコマンドの規格化としてUVコマンドが作られました。
今年の4月頃から動き始め、今では14程のリポジトリを配下に持っています。最初に提案していろんなプロジェクトと折衝しながら規格を作ってくれたエンジニアは本当に行動力があって素晴らしいと思いますし、今では各プロジェクトからいろんな人がメンテナンスにあたってくれて、どんどん便利になっていっていますね。
言語の面では、動的型付け言語が中心だったのが静的型付け言語に移り変わってきています。言語のブーム的な要因もありましたが、やはりコードの品質を考えたときに他の人が見て分かりづらいコードを書きたくないという思いから、型のある言語を使おうという流れで変わってきました。
ペアプログラミングも以前より増えてきていますね。ペアプロは正しく使えば開発効率が上がる手法ですが、そうでなければただ二人分、倍のコストがかかってしまうだけです。どうすればペアプロがうまくいき、どういう時に使うとより効率的なのかをみんながしっかり考えた上で、必要な時に提案されるようになってきたのはとても良いですね。
どの変化についても、みんなが改善意欲をもって日々の業務にあたっているからこそ良くなっていっているものです。良い変化を起こして、きちんと運用して、それにより開発速度を出していけているのは、いろんな人の努力のおかげですね。
やはり、改善意欲の高い人に仲間になってほしいですね。技術力が高い人や知識のある人はもちろん素晴らしいのですが、それで改善していく気がない人よりは、常にインプットをしていて改善点を持ってきてくれる方が先につながるのでありがたいです。
今ユニークビジョンにいるエンジニアは改善意欲の高いメンバーが多いですが、ユニークビジョンに入ってそうなったというよりは、もともとそういう人達が集まっているのだと思います。新しい技術がどんどん出てきていて、ソースコードは何もしなくても陳腐化してしまうものなので、そういった意識はとても大切です。
自分の仕事だけを効率的に進めていこうとするよりも、会社全体のことを考えてそれを広めて提案していってくれる人がいいですね。そういう気持ちの人の話はみんな真剣に議論してくれますし、同じ意見の人が集まれば一緒に進める仲間も見つかります。
ユニークビジョンは階層や役職もなく、提案した改善案が検討されやすい環境なので、どんどんアイデアを出してもらえたらと思います!