こんにちは、プロダクトチームのマネージャーの鈴木です。今回は公開前にプレスリリース公開前にOGPを確認できる機能を実装したので、この機能の開発背景や実装に至るまでを書きたいと思います。サブタイトルとしては「制約条件が多い時にどうしても機能を追加したい時はどうしたらいいの？」という内容を書きます。
機能の企画背景
まずはじめに、機能のご紹介から。今回は、プレスリリースをシェアする時にOGPとして表示される画像とその状態をプレビューできる機能を追加しました。PR TIMESでは画像アップロードメニューから「メイン選択」した画像がOGPに使われます。ただ、設定しても確認する場所がなかったので、今回表示をプレビューできる場所を追加しました。
SNSでシェアされているプレスリリースを見ていると
- 画像の縦or横が切れてしまっている
- メインの画像が透過されてしまっていて見にくい
- そもそも画像が設定されていない
ものがあります。透過に関しては、ダークモードも主流になってきているので透過の場合はOGPに使われるものだけ白背景を入れる改修も過去に実施したのですが、サイズや表示的なものは改善していく必要があり、今回事前に確認できる箇所をつくることにしました。
せっかくとっておきのプレスリリースを入稿して、いざ配信してシェア！という時に、シェア時の画像がうまく表示されないと残念な気持ちになってしまいます。「あっ、こんな表示される予定じゃなかったのに……！」と焦ってしまうかもしれません。（かくいう私も経験者）プレスリリースを配信する時の特別な気持ちを少しでも良い体験にしたい！という思いでこの機能をつくりました。
とはいえ、実はこの機能、企画時点でも開発時点でも様々制約条件や検討事項があったので、その壁を中心に今回はご紹介していきます。
制約条件や検討事項が複数ある状況
シェア時のOGPを解決したい！と思っていたものの、構想前からの状態や企画中に様々なフィードバックをいただきました。
1. 開発リソースの調整が厳しい
担当のエンジニアがいない状態からのスタートでした。他プロジェクトが多数進行している中で、リソースを調整していく必要があります。また、エディターは古いコードも存在していたり、お客様への影響が大きかったり、と少し機能追加するにもパワーが必要でした。（ただ、どうしてもやりたい……！お気持ち的には…..！）
最大限にコンパクトにしつつ、お客様には価値を担保できる状態にするために進め方の工夫をしました。
主に工夫したのは以下の3点です。
① まずは実現可能かどうか調査だけ依頼する
② 可能な改修範囲を仕様決定や企画詰め前にエンジニアとコミュニケーションする
③ 仕様をなるべく軽くする・軽くできるか検討する
まずは実現可能かどうか調査だけ依頼する
1〜2日だけお願い、と期間を明示し、近くの箇所を調査開発していたエンジニアメンバーに力を借りました。他のプロジェクトに影響が出ないよう、あえてスタート時点では調査したエンジニア＝実装するエンジニアをこだわりすぎないようにする事で初期の動きを早める事ができました。調査に入ってくれた方がかなり丁寧に調査毛かをドキュメンテーションしてくれていたので助かりました。
可能な改修範囲を仕様決定や企画詰め前にエンジニアとコミュニケーションする
実装ができそう、という段階で平行して詳細な設計詰めをしました。今実現できない要件を孤独に作りあげてしまうと、機能追加に携わるチームメンバー全員に多大なコストがかかってしまいます。なので、仕様詰めをする前に限られた期間とリソースで何ならできそうかをエンジニアメンバーにキャッチアップしておきました。今回のスコープで言えば、既存部分にはなるべく手をいれない、ユーザー操作など複雑な機能は本スコープで追加しないという制約を設けることで実現を可能にしています。
仕様をなるべく軽くできるか検討する
対象範囲が決まったら、細かい要件や仕様を詰めていきます。その際ポイントになったのが「ユーザーが便利！だけど開発が軽い！」状態です。具体的にはバックエンド処理が走るものは、仕様設計時点でなるべく排除し、フロントエンドも複雑な動きを入れないようにしました。
また、価値を損なわずに提供するためにCRチームやビジネスオーナーに意見をもらい、ここだけははずさない！を自分の中で定めていきました。取れる手段として文言の工夫が私たちには大きかったので、何の情報を出すのか何回も議論しました。
ちなみに、ここだけははずさない！機能ポイントは
- 主要なSNSと同じ表示イメージが出ること
- メイン選択が反映されていて、編集ができるようにすること
- ここでイメージを確認できる事に気づいてもらう事
でした。
2. そもそも論的な部分も多い
全段落では現場的な制約を紹介したのですが、機能を追加する意味や提供価値の部分でも壁がありました。機能を追加していく上で、関連する部分としてそもそもここ使いにくいよね、改善したいよね、という部分も広い範囲で見るとたくさん見えてきます。ここだけの改善、となると工数をかけてやる意味があるのか、価値が担保できるのか、という点に関して考える必要がありました。
特に以下の点は「たしかにその通り！」という箇所で改修していきたいのですが、今後の宿題として開発頑張っていきます！に泣く泣くしています。
アイコンが多すぎる
エディタにはいま、アイコンがたくさん並んでいるため「そもそもアイコンが多すぎて、さらに追加するのはわかりにくさが増す」という話も出ました。
この問題は、根本的に取り組むと長期プロジェクト化してしまう事が見えたため、悩みましたが今回はシェアイメージの課題に限って対応していく事にしました。日々プレスリリースは配信されていくので、少しでも早く機能を提供して残念な体験を防ぐために、この部分が解決していない事を心にとめながらも、まずは機能を出すことに決めました。
メニュー箇所にはツールチップがいままで入っておらず、別途「アイコンが意味しているものが初見だとわかりにくいかも？」という意見もあったので、担当してくれたデザイナーが主導してツールチップを入れてくれました。（話は少しそれますが、このプロジェクト起点でツールチップのコンポーネントをデザイナーチームで策定できたのも良かったです）
イメージを見ながら画像の編集や調整ができない
こちらもその通りで、本来であればイメージからメニュータブを切り替えずに調整ができたりすると体験的に便利なのですが、現状アップロードの仕組みが別のメニュー箇所にあるので、大きく変えると大プロジェクトになってしまいます。（開発時点での制約のほかの箇所を触らないというところにもありました）
まずは1つの「確認できるようにする」をお届けするために、相互に説明やリンクを工夫することでなるべく不便さを緩和するように努力しました。
予定してない改修でも諦めない
はっと気づいて、すぐにやった方が良いけれど、様々な条件で実現への道のり遠いな…….！という事が開発途中ではよく発生すると思います。私の場合は、非常に諦めが悪いので、それでもユーザーの方々に少しでも便利やプラスの価値を届けたい……！とできるチャンスを虎視眈々と狙っています。案外ずっと意識していたら、気付かぬところでできたりもします。
要件を減らすのは苦渋の意思決定でもありますが、コンパクトにある程度のスピード感を持って進めれば、トータルではスムーズに進む事もあると思います。 エンジニアメンバーの脳内リソース的にもエコだと思うので、夢は大きく、リリースは小さく、自分も意識しながら進めていきたいと思います。
