LiBz Tech Blog

LiBの開発者ブログ

LiBのプロダクトの作り方

はじめに

はじめまして、LiBのCTOの水上です。LiBに入社して2年半になります。 気がつけば10年女性向けのプロダクトに携わっています。

今回はLiBのサービス運営の全体的なプロダクトの開発フロー「ロードマップ編」についてお伝えしたいと思います。 ロードマップ設定後の開発のフロー編(企画からリリース前)なども書いていこうと思います。

開発フローを考える上での思想

昨今のスタートアップ企業では当たり前となっていますが、 LiBとしても水上個人の意志としても、各メンバーが命令に従って動く組織ではなく、それぞれが自走できる組織を目指しています。 そのために、下記の3点が実現するべく開発フローを設計しています。

  • 管理すべきはスケジュールではなく、KPI(目標数値)の達成確度としたい
  • 開発だけではなく、企画・分析にも関与しサービスを成長させる未来の事業担当者を育成したい
  • 施策担当には上司を含めて他の誰よりもその施策に対して深く思考してもらえるようにしたい

LiBにおけるKPI(目標数値)設計の考え方

ユーザーへの価値貢献とKPI

サービスが存在する理由は使ってくれるユーザに価値を返せているか? この「価値」を計測するに際して、人の感覚値ではなくサービスの数値(UU/PV/アクション数など)を見て判断しています。 ユーザーへのアンケートやヒアリングなどの定性的な価値貢献の確認も大切ですし、LiBでは転職決定者の方にご協力いただきユーザーインタビューも 頻繁に行っていますが、日々確認が可能という点で主にサービスの数値をKPIとして追っています。

例えばLiBzCAREERは転職支援サービスなので、大切な指標は下記のようなものになります。 (実際はもう少し細かい粒度での目標値となります。)

  • 企業様:採用人数
  • 求職者様:転職決定数

KPI設定での注意点

数字だけを追うと、数字の達成だけがゴールになってしまうため、常にユーザーに提供する価値はなんなのか? 提供したい価値をどの程度提供できているのかを測定する数値がKPIという認識を揃えることが大切だと考えています。 指標として数値の確認はするけれど、あくまでもその先にあるユーザへの価値を提供できているかを考えることが重要です。 あくまでも、目標数値はユーザーへの価値提供がきちんと行えているかの「ものさし」に過ぎません。

エンジニアの担当領域

LiBではプロダクトを開発する上でのスキルを大きく下記の5に分類しています。

  • 企画
  • 分析
  • デザイン
  • ディレクション
  • プログラミング(開発)

上記の中でエンジニアは主に企画、分析、プログラミング(開発)の3つを担当しています。

※上記の中でも開発に集中したい、企画を中心としたいといった本人の思考に合わせてチーム構成や担当割振をしています。

開発フロー

では実際の開発フローについて説明していきます。 LiBでは、エンジニアが企画から分析・開発と一貫して行う事もあり、各施策の主な担当者=各施策の責任者となります。

LiBでの職種別の役割

LiBのプロダクトチームは下記のようなメンバーで構成されていますが、 上述した各施策の責任者は職種にかかわらずに責任者をすることがあります。

  • プロデューサー:全体の整合性確認・調整やロードマップの作成
  • エンジニア:各施策の企画、分析、ディレクション開発
  • デザイナー:各施策の企画、デザイン、ディレクション
  • ディレクター:各施策の企画、分析、ディレクション

プロデューサーと各施策の責任者の役割を整理すると下記のようになります。

  • プロデューサー(サービス全体の責任者)
    • サービス全体の統一感、各施策の質の向上
    • 各施策が部分最適な施策とならず全体最適となるように調整し、よりよいサービスを作る
    • 各施策の目標が達成されたときに、サービス全体としての目標が達成できる状態を作る
  • 施策責任者
    • 担当領域については誰よりも深く思考をまわし、施策の目標を達成する
    • 1人の場合もあれば、複数人の場合もある

サービスのロードマップの作成手順

全体的な流れは以下のような形となります。 f:id:gac777:20181026131457p:plain

  • プロデューサが全体のロードマップを作成
    • 各施策ごとの数値目標と大まかな施策内容の立案
    • 施策担当の割り振り
      • ◯◯の施策はAさん、◇◇の施策はBさんとCさん
  • 各施策担当が全体のロードマップを受けて施策ごとのロードマップを作成
    • 目標数値に到達するための施策内容・施策数の検討
    • 施策のスケジュール調整
      • 1個の施策で達成するならQで1個リリースのスケジュール
      • 10個の施策をリリースしないと達成しないならQで10個の試作リリーススケジュール
  • プロデューサーが各施策のロードマップを確認して全体の調整・強化
    • 各施策から出てくるロードマップは部分最適になりやすいので全体の整合性を整える
    • 各施策が相乗効果を得るような状態にして1つのサービスとしてのロードマップを完成する

日々の働きかた

サービスのロードマップが出来たら後はそのロードマップを達成するために日々やりきります。 プロデューサーと各施策担当者でやる事が違うので挙げていきます。

プロデューサー

  • 週次で上記に記載したロードマップから数字進捗を確認
  • 達成が難しそうな場合は不足分について議論し解決策に導く
  • 施策レビューを行い、ユーザの価値を毀損しないか、目標に届かを確認

各施策担当者

  • ロードマップに沿った開発
  • ロードマップから日々の数字進捗を見る
  • 週次でロードマップの表に実績を記載してプロデューサーとネクストアクションを議論する
    • 予定通りか?予定と乖離していたらどうするか。

週次の具体的な振り返りチェック

ロードマップが完成したら、担当ごとに下の画像のように一覧に落とし込み、 目標数値と開発・リリース内容が記載し週次で振り返りを行います。 f:id:gac777:20181026132622p:plain

まとめ

  • サービスに一貫して関わる
  • 開発してリリースが終わりではなくリリース後が勝負
    • 成果はリリースではなくユーザへの価値貢献

という考えの元、この開発フローで開発を行っています。 そして、各施策担当が成果を上げて、別のサービスの責任者になったり、 1人でもサービスを作って、成長させる事が出来るスキルを取得し、 市場価値を上げられる状態になっていればいいと思っています。 また、このフローを正解とするのではなく、サービスがユーザにより多くの大きな価値を提供出来るよりよいフローがあれば どんどん変えていこうと思っています。 日々改善!!

※LiBでは現在、エンジニア・デザイナーを募集しております。ぜひ興味のある方は以下のリンクからエントリーをお願いします!