ジモティーエンジニアのビジネスとの関わり

お久しぶりです。バックエンドのチームで活動している阿部です。

前回投稿からおよそ2年、前回の時にはAndroidエンジニアとして活動していましたが、1年ほど前にバックエンドのチームへコンバートし現在ではRuby on Rails を中心としてバックエンドの領域で活動しています。

思えば、iOSエンジニアとして入社してさまざまな領域での経験をさせてもらえていますね。

今回は、少し毛色を変えてジモティーエンジニアの現在のビジネスとの関わりについてお話ししていきたいと思います。

こちらの記事でビジネスと近い距離で要件や仕様に関われるというお話をしていました。

現在ではエンジニアもビジネス側としてプロダクトの成長のために企画のフェーズから担当するようになりました。

その様子を自分の経験談を交えながら話していければと思います。

エンジニアとビジネスの関わり方

先で記載した通り、現在ジモティーのエンジニアも企画フェーズからプロジェクトに入りプロダクトをどのような方向に開発・変更していくべきか、分析・議論し日々業務にあたっています。

以前の記事で弊社の開発フローは大きく次のような流れがあるとお伝えしました。

ビジネス要件定義
システム要件定義
開発
テスト
リリース

また、分析のデータ出しはエンジニアの得意分野なので、ビジネス要件定義からエンジニアも関わっていることをお伝えしていました。

現在もそこは変わらないのですが、このビジネス要件も含めエンジニアが主担当として案件を進めていく様に変化してきました。

そのため、分析・議論だけでなく画面のワイヤーをFigmaで作成して、自分でディレクションを行い、実装するエンジニアも存在します。

このようにエンジニアの活躍できる場が広がっているのが現在のジモティーです。

ジモティーのビジネス領域

現在のジモティーではユーザーグロース(UG)とマネタイズでチームが分かれており、ここにエンジニアも半々で所属して各Gで企画から携わっています。

UG：サービス成長のため、ユーザーが使いやすいサービズにするためのグループ
マネタイズ：事業を推進するために売り上げを構築するために動いているグループ

私はマネタイズの方に所属しております。

マネタイズグループでは、ジモティーの売り上げ構成としては以下の4つになっておりそれぞれの売り上げを伸ばす施策の検討を行なっています。

広告：アドネットワークを利用した広告をコンテンツ内に掲載。第三者配信型と自社広告型の２種類がある。
DB連携（成果報酬）：他メディアとデータを連携し送客。
機能課金：投稿を目立たせる機能を販売
その他売上：ネット決済時に発生する手数料課金、ジモスポでの商品売上及び業務受託売上、HRでの応募課金等がある

売り上げ構成など詳しく知りたい方は決算説明資料にも記載されていますので参照ください。

この中で私はDB連携を担当しており、売り上げ向上のため日々試行錯誤中です。

私が担当していること

私が企画側も担当していることはお伝えしていますが、それだけではイメージしづらいと思いますので具体的にどの様な働き方をしているかお伝えしようと思います。

ジモティーでは11カテゴリーの投稿が存在しております。

その中で5カテゴリーにおいて、様々な企業のデータを連携し、投稿を作成しております。

この連携のことを弊社では「DB連携」と呼んでいます。

この連携データのコンディションを確認し連携企業に対してできるだけ効果を返すために基盤の整理・ジモティーユーザーに人気のデータの特性を分析などを中心に私は業務にあたっています。

以下に普段の業務の一例を示しています。

業務	詳細
KPIのためのモニタリング基盤の作成	連携しているデータのコンディションを確認するためのモニタリングを整備してマーケティングでよく使われる指標であるimp1 ,CT2, CV*3をモニタリング可能にした
連携投稿の状況をモニタリング	実際にどんな連携データが存在しているのか、KPIに大きな変動はないのかをモニタリングする。悪化している場合は、各部署と連携しつつ調査を進める。
連携データ、CVデータ、ローデータを分析	連携データの中で実際にユーザーがCVしたデータから人気のデータの特性を調査し、コンテンツの配置を検討する。
施策立案	分析したデータを元に課題になっている部分の仮説をたて、検証する。その中で効果がありそうなものに優先度を振り分ける例) xxxカテゴリの連携投稿はimp数は十分に出ているはずだが、CTRが低いのでimpされてもユーザーマッチしない連携投稿が閲覧されやすくなっているのではないか？
要件定義	実際に課題は何か？システムで何を実現したいのか？を定めてKPIの目標値を決める。画面は改修するのであればモックを作成例) CV数を向上させることを目標として、閲覧されやすい箇所にユーザ志向に合わせた案件を配信する。これにより、CTR *4が上昇することが見込まれるため、結果としてCV数向上を実現できる。実際に実施するかどうかは費用対効果を見積もってROIから判断する。
設計・システム開発	実際に施策を実現するためにシステムをどう改修すればいいのか検討・実装(開発者の皆様には馴染み深いフェーズ)
施策振り返り	リリースしたロジックの効果を確認し、思った効果が出ていなければ切り戻し、原因を調査。主に作成したモニタリング基盤でKPIを確認する

ざっくりと上記を繰り返しながら連携してくださっている企業へ効果を返せるように改善を進めています。

面白さ or 苦労した

ビジネス側の企画から参加することで、今までのエンジニアリングとは異なるやりがいもみえるようになってきました。

実際に売り上げに直結することで今まで以上にメディアのコンディションに敏感になる
実際に自分が要件定義から実装まで上流から下流まで担当できる
- スピード感のあるPCDAを回すことでき、企画に必要なスキルをエンジニアでも身につけることができる
- ドメイン知識が深まることで設計の方向性が明確になり、エンジニアスキルの方も同時に成長できる
- 今まで諦められていた機能もエンジニアが主導だからこそ、さっと実装してプロダクトの成長に貢献できる

一方で、エンジニアリングという領域から外に出ることでその分苦労したこともあります。

ビジネス知識0の状態からチャレンジ
- そもそも売り上げを上げることをKGIとするときに、何に対して効果がある案件が良さそうなのか判断がつかないため効果がある案件を進めることができない
  - ドメイン知識が豊富な方に壁打ちをお願いすることで思考が整理されていき、自走することができるようになってきました。
まだまだ課題がたくさんある領域だった
- 広告業界でよく目にするCTR、CVRをモニタリングできない状態だったので施策の効果がわかりづらい状態でした。実際に設計から入りモニタリング可能な状態にするという面白さを経験できました。

この苦労も一人ではなく伴走してくださったり、サポートしてくださる環境があったからこそ成長を感じられています。