page icon

BLUEPRINTのプロダクトチームについて

 
株式会社BLUEPRINT Founders(以下、BPFD)は、「起業を標準化させる」をミッションに、Vertical SaaS企業を量産するスタートアップファクトリー事業を展開してます。
本ページでは、BLUEPRINTおよびその投資先のプロダクトチームについてご説明させていだきます。
 
【目次】
 
 

Product Management Philosophy


  • BPFDグループでは、「どのようなプロダクトを提供するべきか?」について、BLUEPRINT Product Management Philosophyを定めています。
  • BP PMPは、4S ( Simple Solution + Simple UX + Simple Architecture + Stable )という形で表現しています。
 
Simple Solution
  • 顧客が本当に解決したい課題を定義し、それに対するシンプルなソリューションを提供する。
  • 顧客が「いつ何のために使うプロダクトなのか」を即答できるようなシンプルさがなければ、第一想起のソリューションとなりえず、熱狂的に使ってもらえる可能性もなくなる。
 
Simple UX
  • 少数のシンプルなデザインコンポーネントで画面構造を表現し、直感的に価値と利用方法が把握できる体験を提供する。
  • 適切な課題に適切なソリューションでアプローチしていても、細部のユーザーインターフェースに複雑さが増すほど、価値は失われていく。
 
Simple Architecture
  • 価値を実現できる範囲で、極限までシンプルなシステムを保ち続け、中期での開発生産性を維持する。
  • 立ち上げ初期のソフトウェアが変化に迅速に対応していくのは非常に容易。一方で中期的にも高速エンハンスし続ける難易度は非常に高く、プロダクトが事業成長を止める原因になるケースが多い。
 
Stable
  • 24時間365日、安定稼働するプロダクトでありつづける。
  • ソフトウェアが正しく動かないこと、その状態が長く続くことは、顧客が不信感を抱く最大の要因となる。ただし、高速エンハンスと安定運用がトレードオフとなり、どんなに注意を払っても障害を0にすることは不可能。不具合を素早く検知する仕組みを構築し、「不具合なのか」「想定外だが、仕様とするのか」を冷静に判断して、迅速に対処にあたる。
 
 
 
 
 

CPOの役割


  • BPFD投資先会社におけるCPOには、以下が求められます。
    • CXO共通要件:BLUEPRINT Value(本質主義、結果主義、変革主義)に従い、経営層として圧倒的な責任感を持って事業を牽引すること
    • CPO要件:BLUEPRINT Product Management Philosophyに沿ったプロダクト実現に責任を負うこと
 
  • BPFD投資先会社では、CEO/CSO/CPO/CFOという経営体制を採用しています。
    • CEO以下に、顧客接点(CSO)・プロダクト(CPO)・財務(CFO)を分ける体制をとっており、CPOにはプロダクト全体の経営責任を負っていただきます。
    • プロダクトを管掌するCXOとして、CTOとCPOの2名体制としている企業もあるかと思いますが、BPFDではCPOに集約する体制としています。
    • 営業サイド(CSO)とプロダクトサイド(CPO)のトレードオフに対してはCEOが最終決定する形となっていますが、プロダクトに関して仕様観点と技術観点がトレードオフになる場合は、CPOが最終決定するということを意図しています。
    • CPOという名称ですが、PdMからの任用だけでなく、先述の人材要件を満たす方であれば、エンジニア等の別職種からの任用も想定しています。
    • なお、CPOにはプレイヤーとしてプロダクトマネジメント・UX・エンジニアリングなどの全ての領域で高いレベルで求めているわけではなく、適切な組織を作った上で最終決定に責任を持つことを求めています。
    • 開発やPdMのマネジメント責任者として、VP of EngineeringやVP of Product Managementを、CPO配下のポジションとして設置するケースも想定しています。
 
 
 

プロダクトチームの体制


  • 原則として、必要以上に組織を大きくせず、CXOも手を動かして事業を牽引していくような少数精鋭のチームとしています。
  • 1プロダクトで、PdM/UX/Dev/QAを合わせて10人〜20人弱ほどの想定です。
  • これは、チームの全員がプロダクト全体の体験に視点を置いて業務に取り組むことで、1つのボタンデザイン・1行のコード・1つのテストケースといった細部のプロダクト品質を担保したいという意図を持っています。
  • なお、会社内に複数のプロダクトを持つ場合は、同規模のチームを複数保持していく想定です。
  • ユーザーが一つのプロダクトだと認識するまとまりを、チームの単位とします。