POLでのプロダクトづくりの捉え方を解説します

はじめに

こんにちは。
現在、理系学生のためのスカウト型就活サービス【LabBase】、オープンイノベーションや新規事業を推進したい企業と、大学・研究者とをつなぐナレッジプラットフォーム【LabBaseX】を運用・開発をしているPOL（ポル）で執行役員兼開発責任者として働いている @kenokada です。この記事は「POL Advent Calendar 2019」の4日目の記事になります。今回はPOLでの「プロダクトづくり」という抽象度が高いものを、どう捉えているかを書かせてもらおうと思っております。
プロダクト開発に携わっている多くの人の目に触れられることを願っています。

よいプロダクトづくりとは

これはプロダクトに関わるメンバーにとっては永遠のテーマであり、正解がない。プロダクトづくりをしていく中で、機能開発を言及することに留まるケースが多いが、ユーザーさんに体験という価値を提供するミッションを追ったチームは、プロダクトづくりそのものを俯瞰的に捉え、仮説検証の繰り返しが求められている。俯瞰的観点と現段階での仮説を提示することで、現状のPOLのプロダクトチームの方向性を示す。

良いプロダクトとは

ここでいう良いプロダクトとは以下のようなイメージ。BASEのCTOいいこと書かれていました。
参考 : https://devblog.thebase.in/entry/2018/06/12/110000

サービスクオリティ : 達成したいUXをユーザーライクな形で提供できているか
プロダクトクオリティ : 高い開発品質か。落ちたりせず安定しているか
スケーラビリティ : ユーザー規模の拡大や用途の拡大など変化に対応できるか
信頼性 : 改善を続けられているなど、ユーザーの期待を裏切っていないか
セキュリティ : ダーティハックされない！！！！

プロダクトづくりを構成する要素

現状僕が考える、プロダクトづくりは「チーム」、「開発手法・プロジェクトマネジメント」、「マインド」の３つでおおよそ構成されている。

チーム

• メンバー構成
• チーム構成

開発手法・プロジェクトマネジメント

• プロセス
• プロジェクト改善

###マインド

• 事実に基づく判断
• カルチャーとしての課題解決
• UXドリブンチーム

チーム

プロダクト開発におけるチームとは、専門性を有したメンバーの集合体である。
成果物としてのプロダクトに責任を持つものであり、全員がそれに貢献できるものである必要がある。
結果としてプロダクトチームは以下に貢献するものと思っている。

• UXの最大化
• 事業/経営の最大化

メンバー構成

プロダクトの質を高めるにあたり、２つのミッションが存在する。
それは、圧倒的質を出すハイプレイヤーと、それをチームにて最大化するマネジメントであり、相互作用する体制になる。

• PM
  • マネジメント
  • プロダクトマネジメント
  • プロジェクトマネジメント
• エンジニア
  • テックリード
  • サービスリード
  • マネジメント
• デザイナー
  • ディレクション
  • UI/UX
  • グラフィック
  • マネジメント

チーム構成

チーム構成は少人数による開発を基本として、事業とチーム機能が密接に紐づくものがいい。

• 開発チーム
  • 全員がイノベーションのプロセスに貢献でき、意思決定に参加できているかどうか。が指標
    • メンバーが働くインセンティブが、ネガな方向に向かず、素早い意思決定と実験の繰り返しに向くことが重要。
    • そのため、多数決での意思決定はNG。
    • そのため、チームのリーダーには全員の声を吸い上げるスキルを求める。

Strategy×R&D×CSR

• POLは科学の発展にたいする課題を基点としていることを踏まえると、CSR（社会的責任）という観点は必要不可欠な要素となる。
• そのため、Strategy/R&D/CSRのベン図の共通部分に属するチームである必要がある。
  • Strategy : 中長期戦略に紐づくUXを明確にし、持続的に価値向上する戦略。
  • R&D : 技術/サービス開発への資源配分。
  • CSR ： 社会含む広義のユーザーの課題発見と解決を立案/推進する機能。利益追従を行うという考え方における、CSRへの予算投下は、投資ではなくコストになる。
• 上記の3つの要素に対して、コストではなく投資をしていくことにより、結果として品質の高いプロダクトを世の中に提供していく。

開発手法・プロジェクトマネジメント

プロセス

プロセスの設計は、言い換えると開発案件の起案からリリースまでどのように担保するか。
重視したいのは以下の２点な気がしている。
これは本当に気がしているレベルなので、他にももっと重視したほうが良いことがあると思う。もっと詳しい人いるからその人の知識と経験を教えて欲しい。

開発インセンティブ

• 例えば、開発担当のミッションは「システムに新しい機能を追加すること」だが、運用をしていくと「安定させること」というミッションが生まれる
• 運用ミッションに強くコミットしている担当はシステムの変更を嫌がる
• ミッションによる利益のズレが生じることは多々あるため、ポジティブインセンティブが相互に働くような開発手法や体制の構築が求められる

品質設定と担保

• 当たり前品質と魅力的品質をどこに設定するか（SRE）
• 当たり前品質の基準を高く設定し、ガチガチなQA体制を敷くこともできるが、速度感は落ちる
• 法律周りなど担保しないといけない点と、事業の速度感を維持することが求められる

プロジェクト改善

状況は変わりつづけるため、絶えずプロジェクトが円滑に進み、QCDを担保できるように改善を続けていく必要がある。
特にDeliveryに関しては事業と開発の足並みを揃えるという観点で重要な点と認識している。
改善が必要という状況下において、機械的な改題解決によって解決できる範囲と速度は微々たるものであるため、プロダクトチームのカルチャーの重要性を増すと捉えている。
これに関しても以下の点は守りたいと思っている。きっと他にも守りたいものはあるが・・・

局所最適的改善は極力避ける

• 深く考えない課題解決型の設計をしてしまうと、将来的に作り直しや意味のない改善や、過剰機能開発が発生する
• 将来的展望を読み切ることは難しいので、stepを刻む改善や、作り直すところまで設計する意識と考察が必要

自己領域の制限をしない

• 自身の業務範囲を限定することで、本来は気づけた問題にも気づかないケースが生まれる
• 最悪なのは、気づいても誰かやってくれるだろう精神

マインド

僕らのプロダクトはアートではないため、直感ではなくきちんとした仮説や調査に基づく意思決定が求められると思っています。

事実に基づく判断

• 良いもの。が示すものは人によってイメージが異なるし、いくら言語化したとしても共通認識を取り切れるわけではない
• そのため、何かしらの判断をする際に、空想で判断しないようにする必要がある
• このマインドセットの上で、KPIを重視したい

カルチャーとしての課題解決

• かつての正解や成功が、明日のそれとは限らない世界であることは自明で、改善行動をしない＝時代遅れ。だと認識する
• それは、小さいプロジェクト上の課題解決にも言えることだし、このような小さいものですら改善できないチームに未来はない
• 仕組みで解決。という魔法の言葉が解決してくれることはないので、仕組みだろうがなんだろうが関係なしに、課題を解決していくという根っこのマインドが求められる

それでもUXドリブンのチーム

• KPIだ課題解決だと言ったが、プロダクトづくりをしていく上で必要なのは、品質に拘ること
• その品質を評価してくださるのはユーザーの皆様なので、ユーザーに刺さるプロダクトを作ること
• すなわち、UXを追求して作り上げていくことがすべての根源であり、プロダクトづくりの始まりだと思っている

おわりに

現状のPOLのプロダクトづくりの捉え方について書かしていただきましたが、まだまだ僕らは未熟なメンバーの集まりです。現在、熱量の高い仲間とともにLabTechという事業領域に挑戦してくれる方を絶賛募集しております。興味のある方は、ぜひお気軽にオフィスに遊びに来てくださいね！

ご興味のある方は以下のURLから！！
フロントエンドの方はこちら
バックエンドの方はこちら