ユニークビジョンが提供するシステムやサービスは、多くの大手企業のSNSマーケティングを支え、日々多くのエンドユーザーに利用されています。その信頼性を支えているのは、エンジニア一人ひとりの高い技術力と、妥協のない品質へのこだわりです。

今回は、新卒2年目のエンジニア北村さんに密着し、「Belugaキャンペーン forTikTokの新機能開発プロジェクト」を例に、キックオフからリリース判定までのプロセスをご紹介します。業務の裏側にある技術への情熱とリアルな開発の現場をお届けします。

どのようにサービスを生み出すのか？「機能開発」と「案件構築」

開発プロセスを紐解く前に、まず知っていただきたい前提があります。ユニークビジョンには、大きく分けて「機能開発」と「案件構築」という2つの起案ルートが存在します。

1．機能開発：クライアントからの要望や社内のエンジニアやディレクターが起点となり「プロダクトをより良くするために、このプラットフォームの新機能に対応しよう」「将来のためにシステムの基盤を強化しよう」と、長期的な視点でサービスを成長させるための開発。

2．案件構築：クライアントの「こういうキャンペーンをやりたい」「こんなマーケティング課題を解決したい」という具体的なニーズを受け、特定のキャンペーンを唯一無二のブランド体験に昇華するためのカスタム開発。

今回の機能開発は、まさにこの両方が交差する場所から生まれました。クライアントからの具体的なニーズ（案件）を想定しつつ、TikTokというプラットフォームの可能性を広げるための共通機能（開発）として、ディレクターとエンジニアが一体となってプロジェクトを推進します。

キックオフ・要件定義：ユーザー目線で「なぜ？」を突き詰める

プロジェクトは、プロジェクトリーダー（PL）、テックリード（TL）、担当エンジニアの3名による目線合わせからスタートし、まずは大まかな開発工数やタスクの優先順位・開発の方針などを決めていきます。 今回は、TikToikのキャンペーンに使う新機能「DMでの画像返信・配信」「ボタン付きテンプレートメッセージ投稿」の2つのissueを同時進行で開発することになりました。

大まかな概要とかかる時間を出したのち、キャンペーンディレクター職のメンバーと細かい要件をすり合わせます。お客様と直接やり取りをしているディレクターは、お客様の要望をシステムの要件としてまとめ、エンジニアと一緒に良いプロダクトを作るための架け橋となってくれます。そんなディレクターからのニーズに対し、エンジニアは「なぜその機能が必要なのか？」を考え、認識をすり合わせます。

ーー北村さんに質問：要件定義で重視している点やこだわりはありますか？

北村さん：単に言われた仕様をそのまま形にする作業にしないことですかね。要件定義では「今ある機能と組み合わせれば、より効果的な機能として活用できそう」のような提案や期日までにどこまで実装可能か、どんなリスクがあるかなど、様々な観点から技術的に考察する必要があります。中でも私が特に意識しているのは、ユーザーの使いやすさ（UX）です。すでに他プラットフォームで似た機能がある場合は、この段階からユーザーが迷わないよう仕様を統一する、直感的に分かりやすい画面構成にするなど、ディレクターさんと話し合って決めていきます。

設計レビュー：もしもを徹底的に潰す第三者の視点

要件が固まると、具体的なシステム設計へと進みます。ユニークビジョンでは、設計段階から二重のチェック体制を敷いています。

1．基本設計レビュー
まずは案件開始までに何を優先的に行うべきかを整理します。設計レビューでは自チームのPLとTL、さらに他チームのTLやシニアエンジニアから選抜された品質レビューメンバーが2名程度同席します。ここではプラットフォームの仕様に沿っているかどうかのほかに、これから行う開発の方針として致命的な抜け漏れがないか、このまま詳細設計に移行して問題がないかという観点で「こんな場合どうする？」「そうならないためにどうしたらいい？」という、徹底的な例外系のディスカッションが交わされます。

2． 詳細設計レビュー
基本設計がしっかりとできれば、次は詳細設計を行います。詳細設計のレビューも基本設計のレビュー同様、 プラットフォームの仕様に合わせられているかはもちろん、第三者のシビアな視点から、想定されるケースに漏れがないかを確認します。

●エラーが発生した時、ログはどこまで残るか？（障害時に原因を突き止め切れるか）
●大きなファイルをアップロードした時、挙動や負荷はどうなるか？
●自分自身での技術検証（プロトタイプ作成など）の裏付けは取れているか？

ーー北村さんに質問：設計レビューの際、ユニークビジョンならではのレビューの文化はありますか？

北村さん：働いて強く感じるのは、全ての設計に「なぜそうしたのか」、つまり意図が求められるということです。例えばログの有無一つをとっても意味を持たせる。経験年数に関わらず「なんとなく」を許さないレビュー体制が、起こりうる障害を未然に防いでいるんだなと感じます。

開発・コードレビュー：2週間で60回！ルーレットが育む学びの文化

設計レビューを通過したのちは、いよいよ実装フェーズです。今回は途中で先輩社員も合流し、2人体制でスケジュールを調整しながら期日通りに開発が進むようスケジュールを調整しました。ユニークビジョンでは、コードに変更を加える場合は必ずコードレビューが必要です。驚くべきことに、今回の約2週間の開発期間中で行われたコードレビューは合計60回にのぼりました。

実はこのレビューの仕組みにも、ユニークビジョンならではの面白い工夫があります。自チームのメンバーからランダムに選ばれる「ルーレットレビュー」という制度です。 基本はGitHubを通じた非同期でのレビューですが、必要に応じて顔を合わせて同期的に行うこともあります。
こうしたレビューも単なる検証ではなくコミュニケーションや学びの一環として行うことで組織全体での技術力の向上を図っているのです。

ーー北村さんに質問： ルーレットビュー、実際にやってみてどうですか？

北村さん：先輩のコードをレビューすることも多いのでとても勉強になります。内容をきちんと知って理解していないとできないですし、なぜこのコードが良いのか/悪いのかを言語化する力もつきます。優秀なメンバーが集まっているからこそ成り立つ独自の制度だと思います。

ーー北村さんに質問： コードレビューはすべてルーレット形式なのでしょうか？

いえ、もちろん場面によっては開発者がレビュイーを指定するタイプのものもあります。ワークフローでレビュー依頼を送るのですが、その際に「この修正はシステムの深い知識が必要だから詳しい人に投げよう」「この件はすでに口頭で説明しているからこの人に投げよう」みたいな感じで、場面によって使い分けています。私の体感としては半々くらいですかね。

リリース判定：手順書に沿った、厳格な審査

開発とテストを終え、いよいよリリース判定を迎えます。ここにはPLだけでなく、品質レビューメンバーも同席。用意された「リリース手順書」に沿って、本当にリリースできる状態になっているかどうかを一項目ずつ厳格に判断します。
すべてのプロセスにおいて議論を尽くし、全員が納得した状態でなければ、プロダクトが世に出ることはありません。この厳格さこそが、複雑なキャンペーンシステムを安全に実施するためのインフラとしてお客様からの信頼性を支えています。

開発を終えて：どの分野にも「詳しい誰か」がいる、心強さ

ユニークビジョンの開発環境は、若手のエンジニアにとって圧倒的な速度でプロフェッショナルとしての地力をつけられる場所です。入社直後から、ただ言われたコードを書くのではなく「例外系への配慮」「チームを巻き込んだコードレビュー」「ユーザー目線のUI/UX提案」といった、ハイレベルなチーム開発を日常的に経験できます。

ーー北村さんに質問： 2つのissueの同時進行での開発、お疲れ様でした。北村さんにとって、ユニークビジョンのエンジニア組織はどのようなものだと感じますか？

北村さん：ありがとうございます。そうですね、入社して改めて感じるのは「レベルの高いエンジニアが集まっているな」ということです。少し具体的にいうと、レビューの際の視点の鋭さはもちろんなのですが、どの技術分野であっても、必ず誰か一人はめちゃくちゃ詳しい人がいるんです。しかも、チームの垣根に関係なく、誰にでもいつでも質問できる関係性なのがとてもありがたいですね。
エンジニアだけでなく、複雑な要望もしっかりとシステムに落とし込むためにシステムの要件としてまとめてくれるディレクターさんやそのほかの社員の皆さんもすごく優秀な方が揃っているなと感じます。それぞれが強みを生かしながら一丸となって良いプロダクト作りに一緒に向かっていける。心強いなといつも感じています。

改めて北村さん、そして関わった社員の皆さん、新機能の開発お疲れ様でした。これからたくさんのお客様に使っていただけることを願っています。
今回開発した機能につきましてはこちらで詳しく紹介されています。

「なんとなく」ではなく、根拠のある設計を追求したい。優秀な先輩たちの刺激を受けながら成長したい。そんな向上心や探求心をお持ちのあなたと、一緒に開発できる日を楽しみにしています。

【プロフィール】矢光（yako）

2020年に新卒でユニークビジョンに入社。エンジニアとして「Beluga スタジオ」「Beluga Campaign for LINE」などの主力プロダクトの開発に携わり、数々の大規模案件を成功に導く。現在はテックリードとしてチームを牽引するほか、社外カンファレンスへの登壇など、技術発信にも積極的に取り組んでいる。

「プログラムが書けるようになりたい」から始まったキャリア

――矢光さんは学生時代、数学を専攻されていたそうですね。エンジニアを目指したきっかけは何だったのでしょうか？

大学は情報系でしたが、プログラミングをバリバリ書くよりも数学寄りの研究をしていました。仕事を探す段階になって「手に職をつけたい」「自分の手でプログラムを書けるようになりたい」という憧れから、エンジニアとして働くことを決意しました。
ユニークビジョンを知ったのはスカウトがきっかけでした。技術力の高さや自由度の高いカルチャーに惹かれ、一度話を聞いてみようと思いエントリーしました。最終的には面談で社員と話し、技術に対して真摯で、非常に雰囲気がいいなと感じたことが入社を決意した決め手になりました。

――入社直後は、慣れないWeb技術やリモート環境でのスタートで苦労もあったとか。

当時コロナ真っ只中で、入社4日目からフルリモートでの研修が始まりました。しかも、当時は今より研修制度が整っていない過渡期。入社してすぐに6冊の本を渡され「2週間後に内容について発表して」という課題が渡されました。講義やシステム構築実習の合間を縫って本を読み、プレゼンの準備を進めるという超特急のスケジュールでした（笑）。Web系の概念が全くわからず苦戦しましたが、メンターの先輩にサポートしてもらいながら必死に食らいつきました。

着実に確実に。努力で身につけた技術力と業務遂行力

――最初はどのような業務を任されたのでしょう。

研修後に「Belugaスタジオ」チームに配属となり、まず管理画面の簡単な改修を任されました。分からないことだらけだったのでコードベースを読んだり、ヘッダーの色を変えてみたりして実際に動かしながら技術要素の理解を進めていました。当時はまだまだ方針相談も開発も下手で、テックリードの遥さんにライブラリを使うべきと指摘されていたのですが、結局ライブラリを使わず実装し、それによりバグを埋め込んでしまったんです……。
この経験から、先輩方が技術的な根拠を一つひとつ丁寧に確認し、密度の高いフィードバックをくださるのはすべて品質への責任感からくるものなんだと学びました。あの時の経験が、今の自分のプロフェッショナルとしての土台になっています。

その後はシステム間連携が必要なログインサービス連携機能や、ライブラリバージョンアップなどを経験しました。一人で任される範囲が広がっていくと同時に、影響範囲が大きい開発においては特にチームのコミュニケーションが重要だと学びました。また、社外の知見を必要とすることも増え、コードと向き合いながらキャッチアップして取り組みました。どんな開発タスクが来ても時間をかけて調べれば取り組める、という自信がついたのがこの時期ですね。

――テックリードにはいつから？

入社してちょうど1年が経ったあたりでテックリード業務を任せていただくようになりました。この頃からより難しい開発が増えました。例えばXのトレンドデータを回数制限付きで帳票として出力できる機能や、投稿時の複数承認機能追加などですね。特に複数承認機能の追加開発は、Belugaスタジオがお客様から選ばれる主な理由にもなる重要な機能で既存のコードに横断的に手を入れる必要があったので苦労しました。このあたりから「手戻りの少ない安定した開発を行うためには設計時にどうしたらいいのか」という逆算を意識できるようになりました。

3年目にはBelugaキャンペーンの新機能開発に抜擢いただき、初めて0からプロダクト開発を行いました。開始時には不確定要素も多い状態でしたが、他社のサービスの仕組みを調査して綿密な詳細設計を作成して何とか形にすることができました。これまでは目の前の開発に熱中していましたが、このプロジェクトを一緒に進めた優秀なメンバーに感化されたこともあり、強いエンジニアとはなにか、自分はどうなっていきたいのかをこの頃から考えるようになりはじめました。

1秒に300アクセスという高い負荷に挑む

――現在、主力のサービスや機能の多くで矢光さんが開発に携わっていたとか。

ありがたいことに、実はそうなんです(笑)先ほどお話しした新機能も、のちに主力サービスのもととなりましたし、他にもweb認証機能やマイレージ機能など、お客様によく使っていただいている機能の開発に携わってきました。プロジェクト単位で言うと、新サービスとなるBelugaキャンペーン for TikTokの設計・開発に初期段階から携わりましたし、今はLINEキャンペーンのオンライン入稿管理システムをPLと二人三脚で立ち上げ、機能化を全力で進めているところです。

どんな開発も思い出深いのですが、特に痺れたのは、当時としては史上最大の負荷対策です。秒間100アクセスでも多いと言われる中で「1秒止まるだけで300人が離脱する」という緊張感です。どこにボトルネックがあるかを特定し、既存のアーキテクチャを変えずに、実装レベルでの細かなチューニングを積み重ねて最適化することで負荷を押さえました。普段、開始確認と呼ばれるキャンペーン開始直後のエラー監視はディレクターさんが行うのですが、この時はあまりに気になって僕も張り付いてみていました。インシデントなく無事にキャンペーンが動いた瞬間の安堵感と達成感は非常に大きかったです。ちなみに今、社内では秒間1000アクセスという負荷を想定した案件開発も行われています。今後もさらに高負荷なキャンペーンを安全稼働させられるよう、僕たちエンジニアが頑張らないとなと思っています。

――かなり順風満帆にキャリアを歩まれている印象ですが、逆にうまくいかなかったことはありますか？

入社2年目でBelugaキャンペーンの個別通知設定の開発を行った際「これで行けるだろう」と甘く見積もったタスクが気合ではどうにもならなくなり、多大な時間を費やしてしまいました。「慣れた時が一番危ない」というのは、今も自分への教訓として刻んでいます。それ以来、お客さんや他のメンバーに迷惑をかけないためにもタスクの見積もりは常に慎重に、悩んだ際は大きめに見積もるよう徹底しています。

――苦い経験もされたんですね。これまでのご経験の中で、特に印象に残っている仕事はありますか？

Belugaキャンペーン for LINE（BC4L）チームでの案件です。サンプルのマイレージ作成を、フロントエンド中心に進めました。当時LINEのキャンペーンはまだまだ機能が充実していない中で、2週間というタイトなスケジュールをスピード感を持ってやり遂げたことが印象に残っている理由です。短い期間での実装でしたが完成度をクライアントさんにもほめていただけたのも嬉しかったです。この時に築いた信頼関係が、のちの受注や今の良好な関係につながっているのではないかと、実は密かに思っています（笑）

テックリードになっても「書くこと」にこだわりたい

――現在はテックリードという立場ですが、マネジメントと開発のバランスはどう考えていますか？

正直に言えば、今も開発が大好きで、ずっとコードを書いていたいタイプです（笑）。テックリードは通常全体を円滑に進めるマネジメント要素も強いですが、自分が開発が好きというのを汲んでいただき、今も実装に携わることができています。同じ役割でもその人の個性や強みを理解して業務に反映していただけるので、そこは本当にありがたいですね。
最近では、エンジニアがいなくても運用が回るように入稿システムのUI/UXを改善したり、社内のコンポーネントライブラリを刷新したりと「いかに効率よく、誰でも簡単に設定できるか」という仕組みづくりに注力しています。

――これまでのお話から開発に対する熱意がすごく伝わってきました！そこまで熱意を注ぐ理由はあるのですか？

うーん……。小さい頃からプログラミングをしてたわけではないのですが、元々憧れはあったんです。手に職をつけたい、モノづくりに関わりたいという漠然とした憧れが、社会人になった今も自分の原動力になっているのかもしれません。実際、初めて新機能の開発を任されたとき、LLMがない時代だったのにLLMを使うようなスピードで開発を進める先輩の姿を見てものすごく格好いいなと感じたのを覚えています。今でも尊敬するエンジニアを聞かれた際には、その先輩が真っ先に思い浮かびます。

WGで取り組む、組織規模での品質向上と持続可能な開発の仕組みづくり

――開発プロジェクトだけでなく、社内のワーキンググループ（WG）にも積極的に参加されていますよね。

はい。僕自身は2021年1月ごろからWGに参加しています。最初に入ったのはプロジェクトマネジメントWGという、社内の開発フローの統一などを目指して活動していました。その後もコードレビュー、フロントエンド、バックエンド、AI開発など時代とともに目まぐるしく変わる技術課題に対して、様々な角度から解決策を模索しています。

中でも特に思い入れが強いのはコードレビューWGです。チーム内でルーレット形式でレビュワーが決まる制度や、レビュー量を可視化する仕組みなどを作り、全社的な開発品質の向上を目指してきました。一度は役目を終えてWGは解散したのですが、最近またレビューを強化しようとWGが立ち上がりました。今回は特に、生成AIを活用しながらも質の高いコードを作り続けるためのレビュー制度や組織の拡大に合わせて曖昧になっていたレビュー基準を今一度見直すところから動いていこうと考えています。

――矢光さんから見た、ユニークビジョンの開発組織はどんなものでしょうか？

ユニークビジョンの良さは「新しい技術を使いたい」というだけの提案ではなく「費用対効果があり、プロダクトを良くする」と判断されれば、新しい技術がフラットに採用されることにあります。先ほどのWGのように、現場が感じた課題をメンバーが様々な観点から会社に提案したり解決に向けて動いたりしているのも、その表れです。最近も、開発効率向上のためAPIのリプレースを提案しました。ユーザーへの直接的な価値がないため一般的には理解されにくいことだと思いますが、長期的な費用対効果を踏まえて採用されました。新しい流れになんとなく乗るのではなく、モノを見て判断する文化が、技術者としては非常に居心地が良いですね。

――昨年の年間表彰では技術賞を授賞されていましたね。

はい。昨年はありがたいことに技術賞に選んでいただきました。これまでお話しした社内ベースコンポーネントの刷新やCMSのUI構築など、フロントエンド領域を中心に「現場が本当に使いやすい仕組み」を模索してきた一連の取り組みを、賞という形で評価してもらえたことは大きな励みになりました。 

今後は社内だけではなく、社外にも誇れるエンジニアになりたいと考えています。最近ではVue Fes Japan 2025をはじめとしたカンファレンスでの登壇、テックブログの執筆など技術発信を行うことに注力しています。直近では、国内最大級のTypeScriptカンファレンスである「TSKaigi」に向けて、自分でプロポーザル（登壇提案）を書き、無事に採択されました。ノウハウのない中で手探りながらも検証して得た、開発しやすい環境づくりの知見を詰め込んだ内容なのですが、自分の意思で行動し、社外の技術コミュニティに評価してもらえたことは大きな自信になりました。 

過去に登壇したVue Fes Japanでの経験やテックブログの執筆も含め、こうした社外への発信を通してユニークビジョンの技術の面白さを知ってもらえると嬉しいです。また、こういった活動を社内にもどんどん還元していきたいです。自分が最前線で打席に立ち続けることで、会社の技術的プレゼンスを高めることにも貢献できればと考えています。こういった活動を通して世界に誇れる人になれると嬉しいですね。

技術を「どう使うか」を考え抜ける仲間と

――最後に、今後どのようなエンジニアと一緒に働きたいですか？

大前提として、僕と同じように「技術が好きな人」と話したいです。ユニークビジョンのエンジニアの仕事は、ただ言われたものを設計書通りに書くものではありません。クライアントの要望を実現するためにどんなシステムに落とし込むかはもちろん、フロントエンドからバックエンド・インフラまで一環して設計し実装する必要があります。例えばBelugaキャンペーンではどのような案件の負荷要件にも耐えうるアーキテクチャを多角的に考察して設計します。また、実装の際にも単純なサーバ増強ではなく、案件に最適化したパフォーマンスチューニングをコーディングで行うことでサービスの質とコスト最適化を図るなど、システムの裏側を深く理解して開発に取り組む能力が不可欠です。こうした難しさや挑戦を「楽しい」と感じられる人はユニークビジョンの環境を楽しんでいただけると思います。

一方で、技術へのこだわりが強すぎてオーバーエンジニアリングになってしまうのは良くない。技術への情熱はありつつも、目の前の課題に対して、技術をどう使うのが最適かを冷静に考えられる人が理想的ですね。これからも新しい技術をプロダクトに還元していきたい。そんな挑戦を一緒に楽しんでいただける方と、ぜひ一緒に働きたいです！

【プロフィール】 石原（Ishihara）
2021年、新卒でユニークビジョンに入社。1年目にしてテックリードに抜擢。開発業務のみならず、全社活動の領域でも圧倒的な当事者意識を発揮する。現在はCRM開発や技術組織の再編に携わる。

違和感がないことが、入社の決め手だった

――大学ではどんな事を学ばれていたのですか？
大学では材料工学を専攻していました。鉱石から金属を取り出したり、金属に様々な加工を加えて材料を作ったりするための方法を学び、それらの技術の基礎を成す、熱力学や流体力学などを勉強していました。実は、プログラミング自体はもちろん触ったことはあったのですが、Python2くらいしかきちんとやったことがあるものはなく、web開発もしたことがなかったです。

――材料工学だったんですね。そもそもなぜ新卒でエンジニアを目指されたのですか？
……実は、なぜエンジニアになったのか、明確な理由は自分でもよく覚えていないんです。卒業が見えてきて、いざ就職を考えた時に、自分の思考プロセスを活かせる場所を探した結果でした。ただ、企業選びの軸ははっきりしており、減点方式で自分に合わないものを排除していったんです。

――減点方式とは、具体的にどういうことでしょう？
例えばスーツ着用が必須だったり、全社運動会のような過度に盛り上がる文化があったり……。そういう「堅さ」や「ノリ」にどうしても違和感があって。ユニークビジョンは、面接でも等身大で変な虚飾がなく、選考を進める中で違和感なく自分がいられる場所だと感じたんです。

「できない」ことで落ち込まない。できるための手段を探すだけ。

――未経験に近い状態でのスタートはいかがでしたか？
実践経験がないので正直分からないことだらけの状況でした。入社後の研修で、CTOの青柳さんから「本屋を便利にするシステムを作る」という課題を出されました。Web開発の経験もなかったし、普段仕事以外でそこまで電子機器を触らないので最初は「普通」が何かがわからない。でも、落ち込むことはなかったですね。

――それはなぜですか？
材料の研究と同じで、物理法則やルールが決まっている以上、必ず正解に辿り着けるからです。「100メートルを8秒で走れ」というような、身体的な限界を求められているわけではない。ルールを把握し、理屈を積み上げ、わからないことを一つずつ調べていけば、必ず正解に辿り着ける。そう考えて進めていました。

失敗を経て磨かれた、エンジニアとしての誠実さとその後の活躍

――「淡々と、でも確実に」という姿勢が石原さんの強みですね。でも、苦い経験もあったとか。
はい。研修後は、まずBelugaスタジオのチームに配属されたのですが、入社半年くらいのタイミングで帳票出力機能の設計で大きなバグを出してしまったことがあります。特定の操作をするとファイルが出ないという致命的なものでした。Belugaスタジオというサービスは、特に代理店さんなんかは一日中ログインして使ってくださるサービスなんです。自分のミスでお客さんに不便な思いをさせてしまったという思いがとても強く残りました。最終的に先輩が鮮やかに修正してくれたのですが、その時、品質の重要性を再認識すると同時に自分のロジカルシンキングの甘さを痛感したんです。「理屈に穴がないか」をMECE（漏れなくダブりなく）に突き詰める。もちろんテクニックとしてだけでなく、経験則で身に着ける部分もあります。

この一件以降は、設計の段階で理屈に穴がないかを自分の担当領域だけでなく、別のメンバーのレビューをするときにも特に意識してチェックするようになりました。今ではバードウォッチャーが鳥を瞬時に見つけるように、違和感のある部分が直観的に分かるようになってきました(笑)エンジニアとしての誠実さは、こうした経験の積み重ねで磨かれた気がします。

――1年目という若さでテックリードに抜擢された経緯を教えてください。
当時テックリードとしてBelugaスタジオチームを引っ張ってくれていた先輩が別のチームに移動することになったので、代理として役割を引き継いだのがきっかけです。その後、正式にテックリードとしてチームを引っ張る立場になりました。実は自分自身「これをしたい！」という業務へのこだわりや明確なイメージがあったわけではありませんでした。当時も今も、何か穴が空いているのが落ち着かない質で、気づいた仕事を片っ端から拾っていくという仕事スタイルなんです。そのおかげでできることがどんどん増えていったように思います。

激動のX API対応と、静かに燃えるリベンジ

――2023年のX（旧Twitter）APIの大規模な仕様変更への対応は、かなり過酷だったのではないでしょうか？
そうですね。かなり突然発表され、社内も大慌てだったのを覚えています。レートリミットもレスポンス形式もすべてが変わりましたからね。影響範囲を洗い出し、チームで丸1年かけて関連機能をすべて書き換えました。

――ずっと同じチームだったのですか？
いえ、入社して丸3年くらいでCRMのチームに異動しています。一か所を長くやっていたので「他のところも経験してみて」という感じで、当時そのチームのテックリードをしていた勝間田さんとスイッチする形でジョインしました。まだまだできたばかりでクローズに公開しているサービスだったので、サービスをここから大きくしていくぞというフェーズでした。Belugaスタジオとはまた違った経験ができました。

そのあとは少しだけBelugaキャンペーン for LINEのチームにも所属をしていたのですが、その時が一番まとめるメンバーの人数が多かったですね。しかも、実は同時に新しい開発プロジェクトの立ち上げと、ワーキング・グループの再編にも関わっていたんです。その後そのプロジェクトで正式にチームを作ることになり、今は代表の白圡さん直下で新規事業のテックリードをしています。

「やる？」の一言から始まったワーキング・グループ（WG）への挑戦

――石原さんは開発プロジェクトにとどまらず、WGでも大活躍されていますよね。いつから参加されているのですか？
入社してちょうど1年くらいのタイミングでWGにも参加することになりました。今は複数のWGを掛け持ちしているのですが、最初に挑戦したのは技術広報のチームです。ある日オフィスを歩いていたところ突然、白圡さんから「やる？」と声をかけられたのがきっかけです。チームの立ち上げと同時にリーダーとしてアサインいただきました。

――今のラーニングＷＧのことですね！
そうです。UV Studyという社外勉強会の登壇者を能動的に集めたり、VueFesなどの技術イベントのスポンサーとして協賛したりするのを主導するチームですね。中でも大変だったのは初めてVueFesにスポンサー協賛した時のことです。

――VueFesの準備では、展示用のクロスの材質を確かめに実店舗まで行かれたそうですね。
ネットの情報だけでは手触りがわからなかったので（笑）。実はクロス以外の備品の名前もまったくわからない状況だったのですが、そんなこと言ってられないのでデザイナーにも相談しながら一緒に決めました。必要としているものが欠けているなら、自分の領域外であっても隙間を埋めるよう動いただけなんです。

――ほかに印象深いエピソードはありますか？
2023年にUV Studyで「競技プログラミング」をテーマにしたビアバッシュ形式のLT会がかなり盛り上がったことです。
いつもconnpassで告知して参加者を募っているのですが、このときは社内の競技プログラミング部のメンバーの力も借りて声をかけていきました。結果、オフラインで24名、オンラインで211名、計235名にご参加いただいたんです。普段は大体30名前後にご参加いただいていたので、大成功したと言えます。
他社の技術広報の方とお話するときも、この話題で盛り上がることがたびたびありましたね。

――200名を超える勉強会、すごいですね……！
ありがとうございます。でも成功ばかりではなく、失敗の経験もあります。他社との共催イベントで集客が全く振るわなかったことがあります。今思えばイベントページの公開が遅くなってしまったり、参加者のメリットをきちんと設計しきれていなかったり反省点はすごく明確なのですが。当時は社内だけでなく、向こうの担当者さんも巻き込んでいたのでかなり焦りましたね。
でも、失敗したまま終わらせるのは嫌だったので、4ヶ月後に別の共催イベントを企画して、きっちり成功させてリベンジを果たしました。

――石原さんが「WGをやっていてよかった」と感じることは何ですか？
開発プロジェクトとは違って、なくても会社がつぶれることはないけどあったらよりよいことに主体的に関われることです。先ほどの共催イベントを例に上げると、企画関係者の方とのやり取りやタスク管理などものごとの進め方を学ぶことができたのはWGに所属をしていたからこそだと思います。

社外だけでなく、社内でも関わる人の幅が広がります。特に技術WGの再編を任せてもらってからは、別職種の方とのやり取りも一気に増えました。社内に影響の輪が広がっていくのを実感できるのもWGに所属をしているやりがいの一つだと感じています。

求めるのは「粘り強く、探求し続けられる人」

――石原さんを突き動かす、青い炎の源泉は何なのでしょう。
……「流れ」ですかね。例えば本棚の順番がずれていたら直したいし、抜けていたら埋めたい。目の前にある課題があるべき姿になっていないのが、ただ落ち着かないだけなんです。

――最後に、今後どのような方と一緒に働きたいか教えてください。
ユニークビジョンは今、組織としても技術基盤としても大きな転換期にあります。そんな中でエンジニアに求められるのは、派手なパフォーマンスではありません。ただ、知識を深く、粘り強く探求していける。一つひとつの課題に誠実に向き合い、習得して進んでいける。そんな一緒に「本棚の隙間」を埋めていける方と働きたいです。