こんにちは、NewsPicksエンジニアの大森です。
今回はNewsPicksの姉妹メディア『JobPicks』を昨年立ち上げた際の裏側をエンジニア視点で振り返りたいと思います。NewsPicksのプロダクト開発の雰囲気や新規サービスでやって良かったことや次回への反省点などを共有したいと思います。
サービスについて
JobPicksはNewsPicksの編集者が企画立案したサービスで
- もともとNewsPicksで人気があったキャリア系の記事
- ユーザーに投稿して頂く職業経験談
この2つをコンテンツとしたCGM(Consumer Generated Media)です。
企業の口コミサービスは多数ありますがその職業版がJobPickで、実際その職業に就いた人にしか書けないリアルな経験談を提供し、就職、転職、副業、社内異動などの仕事探しに役立てて頂くサービスです。
アプリはなくWebサービスのみ展開しています。
チーム構成
チーム構成は
- Product Manager：1人
- 編集者：2人 (ローンチ後はもう少し体制が厚くなってます)
- デザイナー：1人
- マーケター：1人
- インフラ・サーバーサイドエンジニア：2人
- フロントエンジニア：1人
という感じで書き連ねると多く見えますがエンジニア以外は兼務だったりするので最低限の構成かなと思います。
プロダクト設計フェーズ
プロダクトデザインの最初の工程はコンセプトの企画やMVPの整理から始まると思いますが、今回エンジニアはMVPが仮決定した直後くらいのタイミングでプロジェクトに入り始めました。
- 企画立案
- MVP（Minimum Viable Product）を定義
- --- ここからエンジニアも参加 ---
- カスタマージャーニーを整理
- AARRR戦略を整理
- ユースケース（≒ 機能）を整理
- 情報設計
- UIデザイン
上記でいうとユースケース辺りからエンジニアとデザイナーがメインのフェーズになりますが、上記工程がすんなり上から下に流れるはずもなく、「やっぱりこうしたほうがいいんじゃないか」等と行ったり来たりでビジネス的な議論にエンジニアも混じって意見を交わしていました。
操作感が重要だったり動きのあるサービスの場合はモックを作成したほうがいいと思いますが、今回はそういう訳でもなかったのでデザイナーがFigmaで作成したデザインで完成イメージをもとに議論していました。
エンジニアがビジネスに近い部分にどれだけ関わるかは個々人の興味や得意分野に応じて個人の意思を許容するのがNewsPicksの目指している文化です。我々のチームではこういったフェーズを経験できる機会も少ないのでエンジニアチーム全員がプロダクトデザインから積極的に参与していましたが、プロダクトデザインの傍ら技術選定や基盤開発を並行して進めていたのでそれに専念するエンジニアがいても機能していただろうなと思います。
実装フェーズ
実装というかシステム設計において最初に考えたのはどこにシステムを構築するかでした。サブドメインで開発することが決まっていましたし、NewsPicksの基盤に載せて開発をすると色々な部品が揃っており工数削減できそうだなどと一瞬考えましたが、やはり根本的に別サービスですし触れたことのない言語で開発したいという思いもあり別で作ることになりました。
詳細を決めるに当たっては
- 高速にリリースできること
- 設計への影響度という観点でみた重要シナリオの要件(アプリなしWebのみ、記事+ 動的コンテンツ等)
- 性能・処理能力要件(SEO重要、NewsPicksのアプリ通知でスパイク等)
などを観点として、APIサーバーはKotlin + Fargate、SSR用のWebサーバーはExpress + Fargate、WebフロントはReact + TypeScriptを採用しています。
その他やってよかった点をあげて行きます。
やってよかった点
デプロイやリリースの自動化
新規サービスにおいてプロダクトを作ることが最優先になりその他の事はその場しのぎをしがちですが、CI/CDの構築は機能よりも最初に作っています。全体的にインフラをAWSで構築しており採用したFargateとCodePipelineの相性がよく比較的容易にパイプラインを構築できました。Cypress を利用したE2Eテストもローンチ直後に構築していたりと、初期段階にしては十分な環境だったと思います。
結果として
- プロダクト開発に集中できた
- プロダクトマネージャやデザイナーとプロダクトを見ながら会話できた
- 開発初期段階でも落とし穴になりがちなシステム間連携部分を本番環境同等の状態で結合テストが行えた
ことで順調にプロジェクトが進んだ一つの要因になったと思います。
Contentfulによる運用コストの低減
JobPicksでは記事の入稿をContentfulというヘッドレスCMSで行っています。ContentfulではModelとそのModelが保持するフィールドを自由に定義し、Modelの更新時のWebhookで自サービスのAPIを実行することが可能です。
JobPicksでは記事本文の他、記事の配置場所やバナーとその配置場所などもContentfulで管理しており、運用管理システムを作るコストを抑えられています。
登録に辺り複雑なバリデーションが必要な場合や、複雑なモデルを管理するのは逆にコストがかかりますが、サービス初期にはかなり助かるサービスです。
TypeScriptの型定義ファイルを自動生成
ts-generatorというツールを用いてAPIサーバーのResponse/RequestのクラスファイルからTypeScriptの型定義ファイルを生成して、APIの中身を実装する前にこれをPRに出すことにしています。
PR上でサーバーとフロントのエンジニアがAPI仕様について認識を合わせる作業工程がそのまま型安全に開発できるというメリットに繋がっており、設計書がコードになるようなイメージで非常に良かったなと思います。
また、新規サービス開発の際に多発する仕様変更にも気付きやすく、変更分の仕様把握の手助けにもなりました。
リリース後
Webメディアはエンジニアと非エンジニアの協力体制が特に大事
私自身Webメディアを作成するのは初めてですが、特にWebメディアはエンジニアと非エンジニアの協力体制が重要だなと痛感しています。というのはWebメディアにおいてSEOが重要だからです。
昨今のCore Update（Googleが検索アルゴリズムを見直して、検索結果を大幅に改善するためのアップデート)ではコンテンツの質とユーザービリティが重視されており、ユーザーのニーズ(検索ワード)に対して適切なコンテンツを適切とUIとプラットフォームの上で提供する必要があります。
「ユーザーのニーズ」はマーケターが、「適切なコンテンツ」は記者・編集者が、
「適切なUI」はデザイナーが、「適切なプラットフォーム」はエンジニアが作り出します。
それそれぞれが連動した施策になって初めてSEOの対策となるため、チームワークが非常に重要です。
協力体制をどのように作り上げているのか
一般的なスクラム開発の通り、スプリントレビューやレトロスペクティブを行ったり、KPIダッシュボードを見ながら次の施策について議論をする場が週2回ほどあります。
それとは別に2ヶ月に一回ほどプロダクト全体を見直す改善合宿を行っています
(合宿といっても物理的に集まるわけではなくリモートです。その他のMTGもすべてリモートですし1年以上会社には出社していません)
関係者全員参加で2~3日かけて行い、その時々に応じた議題でブレストで課題と打ち手を洗い出します。やっていることとしては
- ゴール設定 →「オーガニックの流入をもっと増やすには」
- 問題の発見(起きている現象) → 「狙っている検索ワードで流入していない」
- 問題の原因の分析 → 「記事の見出しに検索によく使うキーワードがない」
- 打ち手の発案 → 「記事をリライトする」「H2の見出し機能を作る」
- UIデザイン → その場でFigmaを修正してパターンを出し
- デザインの磨き込み → 全員で意見だし
- プロトタイプ検証、ユーザーヒアリング → デザインベースでユーザーヒアリング。ここは合宿とは別日。上記の例はSEO関連なのでヒアリングは行わないです。
スプリントレビューでも似たことはしていますが、スプリント内で開発したサービスの一部について議論しており時間も十分ではありません。
この改善合宿を定期的に実施することで
- 刻々と変わるプロダクトのメイン課題について時間をとって議論する
- 部分ではなくサービス全体を俯瞰して問題を洗い出す
- プロダクト全体の向かうべきベクトルを方向修正する
といったことができます。何より、全員共通の問題認識をもつことで一体感が生まれるのも大きなポイントかなと思います。
新規サービスを作ってみての振り返り
まとめとして全体振り返って反省点をいくつか。
商標
今となっては話のネタですが、使おうと思っていたサービス名が既に商標登録されていることに気づきやむを得ずサービス名を途中でJobPicksにで変更しています。幸いリリース前に気づいたので事なきをえましたが、商標とドメインは抑えておかないと駄目ですね。
MVPを文字通り最小限に絞り込むこと
実はプロジェクトの最初の方に決めたMVPの一部は実装時間が足らずに削ってローンチをしています。しかし、ローンチして半年ほどたった今も削った部分は実装していなかったりします。リリースして実際のユーザー行動を分析した結果、後でいいという判断になっています。
具体的にいうとユーザーが投稿してくださった経験談のSNSシェア機能と動的OGPです。SNSによる流入を期待しての機能でしたが、リリースしてわかったのは実名で投稿された他人の経験談をSNSで共有するのは、晒し上げているような感覚になりシェアする側としても体験が良くなく利用されないという結果でした。
自分たちの思惑どおりマーケットがプロダクトを評価することなんて稀で、当たり前のことですが誰のどんなニーズを満たすのか、ニーズを満たすために必要最小限は何なのかをよく見つめ直すことが大切ですね。
今回はNewsPicksの新規サービス開発を通じてプロダクトチームの雰囲気と学びを共有させて頂きました。事業としての成功しているとはまだまだ言えないサービスですが、日々改善を重ねまた何か共有ができばと思います。
