ユニークビジョンが提供するシステムやサービスは、多くの大手企業の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の同時進行での開発、お疲れ様でした。北村さんにとって、ユニークビジョンのエンジニア組織はどのようなものだと感じますか？
北村さん：ありがとうございます。そうですね、入社して改めて感じるのは「レベルの高いエンジニアが集まっているな」ということです。少し具体的にいうと、レビューの際の視点の鋭さはもちろんなのですが、どの技術分野であっても、必ず誰か一人はめちゃくちゃ詳しい人がいるんです。しかも、チームの垣根に関係なく、誰にでもいつでも質問できる関係性なのがとてもありがたいですね。
エンジニアだけでなく、複雑な要望もしっかりとシステムに落とし込むためにシステムの要件としてまとめてくれるディレクターさんやそのほかの社員の皆さんもすごく優秀な方が揃っているなと感じます。それぞれが強みを生かしながら一丸となって良いプロダクト作りに一緒に向かっていける。心強いなといつも感じています。
改めて北村さん、そして関わった社員の皆さん、新機能の開発お疲れ様でした。これからたくさんのお客様に使っていただけることを願っています。
今回開発した機能につきましてはこちらで詳しく紹介されています。
「なんとなく」ではなく、根拠のある設計を追求したい。優秀な先輩たちの刺激を受けながら成長したい。そんな向上心や探求心をお持ちのあなたと、一緒に開発できる日を楽しみにしています。
