こんにちは、YOUTRUSTのWebエンジニア今井(YOUTRUST / X)です。
今回は同じくYOUTRUSTでPdMをしている竹中(YOUTRUST / X)と共同で執筆し、一緒に進めた大型プロジェクトについてエンジニアとPdMそれぞれの視点から振り返ります。
簡単に自己紹介
竹中優太(PdM)
- 神戸大学卒業後、YOUTRUSTに新卒入社。カスタマーサクセスやインサイドセールス、新規事業責任者を担当し、その後プロダクトマネージャーに就任。現在はキャリアSNSのYOUTRUST、採用担当者の管理画面、新規事業のPdMとして管掌している。
今井優佑(Webエンジニア)
- 2020年5月にYOUTRUSTの長期インターン生としてジョインしカスタマーサクセスに従事。新卒では日本IBM株式会社に入社した後、2023年6月にYOUTRUSTにWebエンジニアとして再度入社。現在は主に採用担当者が利用する管理画面の開発などに従事。
はじめに
YOUTRUSTでは先日、CL（クライアント）向けに「スカウトおよびリマインドの予約送信機能」をリリースしました。
「夜間・深夜に作業していても、相手に配慮した時間に送信したい」「タレント情報を詳細に把握したタイミングで、最適なリマインド文面を事前に用意したい」という多くのご要望に応えるために開発を進めました。
一方で、YOUTRUSTが大切にしている1to1の温度感やパーソナライズを損なわないようなバランスをどう取るか、仕様策定にはとても苦労がありました。
最終的には段階的リリースを採用し、先日のリリース後も現在に至るまで継続的に改善を続けています。
プロジェクト概要
- 期間： 約6ヶ月（構想〜リリースまで）
- チーム構成： メインアサイン合計4名(PdM1名、デザイナー1名、エンジニア2名)
開発経験2年目の若手メンバー2名（PdM：竹中優太 / エンジニア：今井優佑）が中心となってリードしたプロジェクトの成功体験や失敗談を「等身大」で共有することを目的としています。これから開発に携わる方々の参考になれば幸いです。
PdM視点の振り返り
ここからはPdM視点で、機能開発の要求定義・仕様設計・デザイン検討の進め方を振り返ります。
予約送信が必要だった背景
CL（クライアント）側のニーズ:
*「業務の合間に落ち着いてスカウト文面を作成しつつ、送信タイミングは翌朝または日中に設定できるようにしたい」という要望
*「スカウト文面を作成する瞬間が最も送付相手の情報を把握しているから、このタイミングでリマインド文面も用意しておきたい」という要望
YOUTRUSTとしての課題:
1to1の温度感を保ちつつ、自動化や効率化も推進したかった。しかし“自動”に寄りすぎるとスカウト文面が画一的になり、返信率や信頼感低下につながる恐れがあった
返信率を高める目的で、（カスタマイズを前提とした）送付相手へのリマインドを推奨しているが、CSからのアナウンスだけではリマインド送信率は上がりきらなかった
仕様検討の進め方・ぶつかった壁
1. 関係各所とのすり合わせ
予約送信機能の開発と並行して、エンジニアチームではフロントエンドコンポーネントの標準化を進めていました。標準化が完了した直後、予約送信機能の理想的なUXを実現するには、新たなコンポーネントの追加が不可欠だと判明し、調整が必要になりました。
そのため「標準化を優先したいエンジニア陣」と「理想のUXを実現したいPdM」という立場の違いから、一時的に調整が難航しました。(実際に深夜まで熱く語り合う日がありました)
最終的には双方が納得できる適切な背景や材料を見つけるため、コンポーネントの一部を既存の設計に合わせて再利用しつつ、新機能で必要なコンポーネントを導入する形で合意しました。これにより、開発コストとUX向上のバランスを保つことができました。
2. リリース順序
当初の案では、理想とするUXを同時に実装、リリースしようとしていました。しかし実装量が増えリリース時の不具合の発生リスクが高まると判断し、段階的リリースに切り替えることになりました。
まずデザイン上負債になる箇所から細かく分割してリリースし、デザインの改修完了後に予約送信の実装に着手しました。結果的にリリース段階が想定よりも増えてしまったものの、リスクを抑えつつ着実に機能を拡張していく形が取れました。
3. 複雑な仕様
今回の「スカウト＆リマインド予約送信」では、1通目の予約送信とリマインド送信を同時に登録できるという大きな要件がありました。これに伴い、以下のような複雑な仕様を検討する必要がありました。
- 送信順序の制御： 1通目より先にリマインドが送られないようにする
- 短期間での予約制限： あまりに間隔が短いと「連投感」が出るため、ユーザーへの不快感を招かないような設定を工夫
- エラー・イレギュラーケースへの対応： 一度のミスが「信頼感の低下」に直結するため、丁寧に設計・検証を実施
特に「一度でもミスが起きると信頼を失うリスクが高い」仕様変更であると認識し、必要以上に複雑なフローにならないようバランスを取りながら、徹底的なレビューとテストを実施しました。
4. 受け取り手であるユーザーの温度感に配慮したスカウトUX
YOUTRUSTでは、1to1の温度感やパーソナライズを重視しているため、予約送信機能を単に「自動化」するだけでなく、ユーザーへの配慮が行き届くUXを目指しました。担当デザイナーと議論を重ね、具体的には以下5点にこだわっています。
- 短期間の予約設定
- あまり先の日時を指定するより、プロフィールの変更による誤情報引用のリスクを下げて、リアルタイムに近い範囲で予約することで“人間味”が感じられるように調整
- 相手のプロフィールを見ながら文面作成
- 広い画面で相手のプロフィールを見ながら文面を作成できるUIにし、パーソナルでカスタマイズされた内容を盛り込みやすくする
受信側のプレビュー
- 「自分が受け取ったらどう感じるか」をチェックできるプレビュー画面を用意し、誤送信や無機質な文面を防ぐ
実際のプレビュー画面 相手の呼び方に対する配慮
- 名前の呼び方や敬称などを指定でき、複数の変更箇所を一括で置き換える体験を重要視。名前を失敗するという最大のリスクを軽減
分割送信
- SNSらしいカジュアルなメッセージ体験にできるようスカウトメッセージを分割して送信できる機能を用意
エンジニア視点の振り返り
PdMとデザイナーを中心に仕様をまとめていただき、設計/実装/QAを担当しました。ここから開発を担当したエンジニア視点で、今回のプロジェクトの中で苦労したことを振り返ります。
複雑なデザインを実現しつつ、可読性・保守性の高いコードを維持する
今回私にとって「複雑なデザインを実装に落とし込みつつ、可読性・保守性の高いコードを書く」ことが最大の課題でした。これまでバックエンド実装の割合が多く、複雑なフロントエンド実装は今回が初めてだったこともあり、とても苦労しました。
苦労したスカウト対象者の呼び方の変換処理
実装の中で最も苦労した開発が、呼び方の変換処理です。スカウト送信相手の呼び方を設定するフォームを新設し、フォームを更新するとスカウト文面の中にある名前が書き換わる機能を実装しました。
この機能を実装することのメリットは理解しつつも、実装上の課題もあったため、PdMとそもそもこの機能は必要なのか議論を重ねました。
この機能のメリット
- スカウト送信者の作業の一部をシステムが代替することで、作業効率を改善できる
- スカウト送信前に、お相手の呼び方を確認する作業がよく発生するのですが、こちらをシステムで解決する機能になります（苗字と名前/「さん」と「様」など呼び方が混在するケースを防ぐことができる）
システム上の課題
- 複雑な実装となるため、保守性の低いコードが生まれてしまう
- 採用しているエディタライブラリの仕様に依存するコードが生まれ、その結果、実装者以外のエンジニアが理解しづらいコードが生まれてしまう
最終的にはスカウト送信者のUXを最大化することを優先して、実装することになりました。ライブラリの公式ドキュメントを読み込み、最終的にはメンション機能の仕組み応用する形で本機能を実現しました。（具体的な実装方法は別のブログで記載しようと思っています）
その中で、可読性・保守性の高いコードを保つために、
- 肥大化して見通しの悪いファイルが生まれないように、責務ごとにファイルを分割
- 入念にコメントで補足を追加
- コメントだけでは理解が難しい箇所は、公式ドキュメントのリンクも追加
呼び方の変換処理の実装を終えてみて
個人的には難易度が高い実装となったので、とても良い経験となりました。一方で、かなり実装に時間がかかりリリースが遅れてしまったことは実装者として反省もしております。
この経験から、エンジニアとして要求を形にするスピードを上げるための努力は続けつつ、
それと同時に、「PdMやデザイナーのアイデア以外に、課題を解決するための代替案はないのか？」「もっとシンプルにできないか？シンプルにすることで、ユーザーさんへの価値提供の時間を短縮できないか？」といった視点を持ってプロダクトを作る重要性も学びました。
致命的な不具合になり得るエッジケースを考慮した設計
今回のプロジェクトにより「1通目スカウト予約」「2通目リマインド予約」という2種類のメッセージを同時に予約することが可能になります。その結果様々な条件分岐が生まれ、多くのエッジケースを考慮した設計が必要になりました。
- 想定されたエッジケースの一部
- 1通目の予約送信のジョブが失敗した場合の、同時に設定されている2通目の予約送信のジョブの取り扱い
- 予約送信設定中にお相手から返信が来た場合の、設定中の予約送信ジョブの取り扱い
上記以外にも設計上かなり多くのエッジケースの想定が必要でした。仮に採用担当者が意図してない予約送信が実行されてしまった場合、取り返しのつかない不具合となるので、「エッジケースの洗い出し」およびそれを防ぐための「バリデーションの検討」に最も時間を使いました。
エッジケースが多く存在するため、普段の他のプロジェクトと比較しても3倍以上のQA項目が生まれました。QAも私とPdMの竹中の2人で担当したのですが、大きな不具合なくリリースをすることができました。（ちなみに普段はQAエンジニアがQAを担当しているのですが、今回はリリース期日との兼ね合いで2人でQAを実施しています）
リリースしてからの反響、および成果の紹介
クライアントの皆様のご利用の甲斐もあり、
リリースした月のリマインド設定率が過去比の2倍まで上昇しました🎉
実際のクライアントの皆様からもご好評のお声をいただいております。
若手2人がプロジェクトから得た学び
小さくリリースして検証する重要性
- 機能リリースの単位を小さく分割し、早期に検証を始めることで余計な仕様の作り込みを防ぐだけでなく不具合のリスクも軽減できます
- 今回は結果的に分割した形にはなったが、最初から小さくリリースする想定であれば、エンジニアの負担をもっと軽減できたかもしれないと感じています
仕様はとにかくシャープに
- 「せっかくならばあれもこれも入れたい」とすると複雑さが増し、実装難易度と工数が膨れるだけではなく、保守・運用が大変になります
- 実際に使うユーザーの行動を改めて考え、最初の段階では最小限の要件に留める勇気も必要だと感じました
上位指標（返信率）を意識した課題設定
- 今回の機能は「予約送信数」を増やすことが第一のゴールだったが、最終的には「返信率」がプロダクト成長における重要なKPIとなります
- 今後さらに「どのようにスカウト体験を改善すれば返信率を引き上げられるか」という観点で、追加施策や改善を検討していきたいと思います
最後に
最後までお読みいただき、ありがとうございます。開発経験2年目の若手メンバーとして初めて大きな機能開発をリードする中で、多くの学びや苦労がありましたが、周囲の方々のサポートのおかげで無事リリースできました。
この経験を活かして、今後もYOUTRUSTの成長に貢献するとともに、よりユーザーに寄り添ったプロダクトづくりを続けていきたいと思います。 引き続き、YOUTRUSTのアップデートにご期待ください！
