「誰もがビジネスを楽しめる世界」を探索するコーポレートマガジン
エンジニアとして、いつまでも現役で開発を楽しみたい(2021年新卒入社 Uzabase Product Division ソフトウェアエンジニア 松元翔矢)

エンジニアとして、いつまでも現役で開発を楽しみたい(2021年新卒入社 Uzabase Product Division ソフトウェアエンジニア 松元翔矢)

ユーザベースの歴代新卒メンバーにインタビューする「New Generations」、第3弾は2021年4月入社、Uzabase Product Division ソフトウェアエンジニアの松元翔矢さんです。

松元 翔矢

松元 翔矢SHOYA MATSUMOTOProduct Division ソフトウェアエンジニア

2019年8月にProduct Divisionにインターンとしてジョイン。SPEEDAへの企業データの取り込みプロジェクトなどを経て2021年4月入社。現在はSPEEDAの...

MORE +
ユーザベースに入社したきっかけを教えてください。

高校からの先輩である平山さん(平山 遼/Product Division ソフトウェアエンジニア)の紹介をきっかけに、大学の長期休みにユーザベースで数週間のインターンをしていました。一番長かったときが、2019年の夏休みで6週間ぐらいですね。その後の春休みに1ヶ月、短かったですが2020年の夏休みにも2週間ほどインターンをしていました。

最初のインターンでは、サプライヤーの中国系企業データをSPEEDAに取り込むプロジェクトに関わっていました。嬉しいことに、インターンという立場関係なくプロジェクトの立ち上げから、ファーストリリースまで携わることができました。候補者が1次面接に進むべきかの採用判断を一緒にやらせていただく機会もあり、僕がやっていいの? と思っていました(笑)。

ユーザベースのProduct Divisionは、かなりめずらしい開発手法を採用しているんですよ。最初にインターンをしたときは、僕にとって新鮮というか、感動というか......もはや衝撃でした。

アジャイル開発を導入している企業はいくつもあるんですが、ユーザベースはその中でもエクストリームプログラミング(※1)と呼ばれる開発手法を採用しているんです。ウォーターフォール(※2)の経験しかなかった僕からすると、エクストリームプログラミングって、それまでの開発と全く違うんですね。だからこそProduct Divisionの開発環境に、ものすごく興味を持ったんです。

1 エクストリームプログラミング:細かなリリースやペアプログラミングなどにより、変化する顧客要求への対応力とソフトウェア品質の両立を目的としたソフトウェア開発プロセス

2 ウォーターフォール:開発を各工程に分けて進める手法。各工程を順序立てて進め、基本的に並行せず逐次的に1サイクルで終わらせる

その後CTOの林さん(林 尚之/B2B SaaS Business 執行役員 CTO)に「Product Divisionの開発環境に興味があって、一緒に働いてみたい」と思いを伝えました。その時林さんから、「インターンで経験したと思うんだけど、ユーザベースやProduct Divisionのカルチャーは受け入れられますか?」という質問をされたのを覚えています。

Product Divisionは「権限委譲」という形で、本来であれば林さんがやる仕事を、メンバー全員でやるカルチャーがあるんですね。採用担当やチーム運営、細かいところで言えば経費精算など。僕としてはいろいろ挑戦してみたかったので、全く懸念はなかったです。そのやりとりを経て入社することが決まりました。

ターニングポイントがあれば教えてください。

エンジニアを目指したことですかね。7才ぐらいの時からパソコンに興味を持ち始めて、しょっちゅうWindows XPで遊んでいました。遊んでいるうちに少しずつパソコンの操作に慣れていき、中学生の頃には親や友人から頼られるようになっていました。それをきっかけに、パソコンを使う仕事に就きたいという夢を持ち始めたんです。

エンジニアにありがちだと思うんですけど、僕はゲームが好きで。論理回路をベースにしたゲームが流行った時があったんです。ANDとか、ORとか、XORみたいな。そのゲームにハマっていたこともあって、家の近くにあった情報工学を学べる高校に進学し、ソフトウェアなどに興味を持つようになりました。それ以降は、ソフトウェアエンジニアになりたいと明確に思うようになりました。

Product Division のソフトウェアエンジニアとして仕事内容とやりがいを教えてください。

少し前まではSPEEDAのセグメント比較資料をExcelとしてダウンロードできる機能を開発していました。今開発中の内容はリリース前なので秘密です(笑)。Product Divisionのソフトウェアエンジニアは、フロントエンド・バックエンド関係なしに開発を進めるので、幅広い技術を使っています。最近ではフロントエンドに「Svelte」というProduct Divisionでは触れたことのない技術も導入しました。 

僕は個人開発が結構好きなんですけど、そこで感じていた楽しさ、喜びと似た体験がProduct Divisionではできているんです。個人開発では機能として何を優先させて開発するのかは自分で決定するし、技術選定に関しても全て自分自身で選択します。この個人開発でしか得られない自由度が僕は好きなんですね。

一方で、大規模開発でしか得られない経験・技術スタックもあります。個人開発と大規模開発では、そもそもチームの規模が違うし、使用する言語など技術スタック(開発環境)が違うんです。そこが個人開発では得ることができない部分だと思います。

ユーザベースの場合は、自社プロダクトがあるおかげで大規模開発の経験を積めるだけでなく、自由と責任をもてるので個人開発と似た楽しさ・やりがいがある──大規模開発と個人開発の良いところ取りなんですよ(笑)。

実際Product Divisionでは社歴関係なく、メンバー全員がユーザーストーリーを考えます。もちろん新卒であっても同じです。技術選定においても、林さんは「技術的な挑戦を入れてください」と日頃から言ってくれているので、非常に自由度が高く常に新しい学びを得ることができます。

自分事として責任をもって開発ができているっていうんでしょうか......技術選定における自由度が高く、ストーリー出しも僕らがやるので、そこにすごく自分事というか、つくり手として責任感を感じます。

いま悩んでいることはなんですか?

ユーザーストーリーに苦戦しています。Product Divisionのやり方で言う「アジャイル開発」は、まず実装すべき機能をユーザーストーリーに落とし込むんですね。たとえば、「ユーザーは計算された〇〇を見ることができる」というように、1つずつ必要な機能を書き出していくんです。そのユーザーストーリーに対する開発規模の見積もりを出して、ファーストリリースの期日を設定します。

もしこの見積もりを見誤ってしまうと、ファーストリリースの期日に間に合わなくなってしまうので、エンジニアとして非常に重要なスキルなんですね。プロとして期待値コントロールを誤ってしまうのは絶対に避けるべきですし。

進捗が悪く、どうしても何か機能を落とさなければならないとき、「何かを落とさないといけないのは、アジャイルじゃない」と林さんは言っていて。何かを落とすのではなく、ビジネスの変化に合わせて機能を前後させたり、追加したり、優先度を変えたりするのが、アジャイル開発なんですね。

アジャイル開発における1つ目のポイントは、ファーストリリースの期日を設定した後、どの機能から着手するか優先順位をつけるか。2つ目は、ビジネスサイドとのやりとりを経て、ユーザーのことを考え、急いで開発すべき機能などの優先順位を考えること。3つ目は、Product Divisionとしてのプロダクトの品質が担保され、かつ自分たちの知見を育てられるような開発を進めること。

これら3つのポイントを踏まえたうえで、開発速度が上がるようにユーザーストーリーの優先度を決定していくんですが、今の僕にとってはまだ難しいと感じています。

板倉さん(板倉 大輔/Product Division ソフトウェアエンジニア)のような、開発経験が長いシニアエンジニアの方々からも、「こういうやり方は違うんじゃない」など、いまだに指摘をいただきますね。

板倉さんをはじめ、先輩たちは僕みたいな新人に対して、「新しく入ってきたメンバーにこそ率先してスキルをつけてほしいから、もう少し考えてみて」と言ってくれていて。

Product Divisionって自己組織化(※3)されている状態を目指しているので、僕ら新人にそのスキルをつけさせようとしてくれているのだと思います。

3 自己組織化:チームメンバ一人ひとりがチームとして最適な方法を自ら判断し行動している状態

今後の目標を教えてください。

正直に言うと、中長期の目標は立てていません。でも何をやりたいことかは決めていて。現役のソフトウェアエンジニアとして、ずっと開発を続けたいと思っています。

ロールモデルとして、板倉さんのような人になりたいと思っているんです。板倉さんはシニアエンジニアにもかかわらず、新しい技術を積極的に取り入れる方で、なおかつソフトウェア設計の話になったとき、高い視座を持った意見を言うことができている人なんですね。

シニアエンジニアであっても、熱意が枯れていないというか......エンジニアとしても、アーキテクト(※4)としても能力のある方だと思っています。ちょっと上から言っているように聞こえたらごめんなさい。今もなお現場で開発しているところを尊敬しているんです。

4 アーキテクト:ソフトウェアエンジニアの中でも設計に長けた人たち

何より、板倉さんってすごく楽しそうに働いているんですよ。インターンの時から、板倉さん以外にも楽しそうに働くシニアエンジニアの方々をたくさん見てきました。いつまでも現役バリバリに開発をしている方々を見ていると、僕も将来そうなりたいなと思うようになったんです。

最後に、松元さんにとって「SPEEDA」の価値とは?

エンジニア視点で語ると、迅速なアップデートではないかと思います。アップデートのスピードの速さは、Product Divisionがアジャイル開発をうまく実践できているからだと思っています。自画自賛ですが(笑)。

アップデートがあるソフトって楽しいと思うんですよね。ゲーマー観点なんですけど、僕があるゲームをプレイしていて楽しいと思っていたのが、アップデートだったんです。アップデートのおかげで、ゲームに新しい要素が追加されたり、より快適に遊べるようになったりと、そういうソフトの進化に期待しつつ遊ぶのが楽しいと感じます。

なので、SPEEDAも頻繁なアップデートにより価値が高まり、楽しいプロダクトになってるんじゃないかと思っています。

編集後記

「尊敬する先輩が、楽しそうに働いている姿をみて、自分も将来ああなりたいと思った」と話す松元さんが印象的でした。仕事に誇りを持つことや、仕事を楽しむことは頑張ろうとして叶うことではないからです。

ソフトウェアエンジニアとして大きく成長した松元さんが、バトンを引き継ぎ、また次の世代のエンジニアメンバーのロールモデルとしての存在にきっとなれるはずだと思いました。

執筆:近藤 里衣 / 編集:筒井 智子 / デザイン:金子 華子
Uzabase Connect