CTOがプロダクトマネジメントに本気で取り組んで見えてきたエンジニアリング組織のセオリー
CTOとしてプロダクトマネジメントに軸足を置いてから半年ほど経過し、エンジニアリングマネジメントの観点で新しい気付きがうまれてきたので、記事にしてみる。
この記事で述べること
この記事では、back checkでプロダクトマネジメントをする上で試行錯誤してきた内容を踏まえ、プロダクトマネジメントを遂行する上で必要な人のアサインとキャリアについて言及していこうと思う。
まずは「back checkがプロダクトマネジメントの観点でどういう課題に直面したか」を述べた上で、「組成した新規チームのミッションとアサイン」を述べ、そこから学んだことを述べる。
その上で、一個抽象化し、「プロダクト運営上発生する不確実性」を述べた上で、「適性をもとにしたエンジニアリングマネジメントのセオリー」を考えていく。
プロダクトマネジメントでやってきたこと
自分がback checkのPMとしてジョインしはじめたのは2021年10月ころ。なぜCTOの自分がPMをやることになったのか下記記事を見てもらいたいが、簡単に言うと、プロダクト主導のプロダクト運営ができるようになれば、よりこの事業は成長すると考え、またその知見がback check以外の事業を運営することになってもROXXとして重要なアセットとなると考えたというのが背景になる。
まずback checkのPMとしてジョインしてからやったことは情報収集と方針の打ち立て。
情報収集は事業部としての基本戦略に基づいて、ターゲット顧客に会いに行き、成功しているターゲット顧客とそうではないターゲット顧客の差分を認識するところからスタートした。
詳細は事業責任者の山田が下記の記事で詳細を述べているので参考にしてもらいたい。簡単に言うと「エンタープライズシフトのために必要な機能の定義を行い、ちゃんと使える状態を作る」ということをやっていた。
プロダクトの機能開発は大きく分けて2つ存在する
価値の創造
プロダクトのコアコンセプトそのものを実現するための機能
価値のデリバリー
プロダクトの提供価値を実際に届けるために業務上必要となる機能
この内エンタープライズ企業対応のための施策は価値のデリバリーを中心とした機能開発となる。「法務、コンプライアンス、情報セキュリティなどを鑑みた そもそも契約していい製品なのか? という問いに答えられるか」と「具体的な業務プロセスを鑑みた 運用に耐えられるか? という問いに答えられるか」という2つの問いに対して答えられるようにするものが必要である。
本記事では詳細は割愛するが、上記方針を打ち立て、適切なPMを採用し、「あとはやれば大丈夫」という状況まで持っていったのが、ジョインして最初の三ヶ月間で実施したことである。まだ実行中のものはあるが、適切なプロジェクトマネジメントを行っていけば主要価値における競合優位を強固にしていけると自信を持って言える状況にはなったかなと思う。
価値の創造への投資=ディスカバリーチームの組成
一方、価値のデリバリー施策でback checkそのものを使えるユーザは拡大し、事業戦略を達成していけるものにはなっていくが、back checkのミッションである「信頼が価値を持ち、信頼によって報われる社会の実装」という観点では、プロダクトそのものの価値がまだまだ不足している。
上記の図の通り、まずはユーザ対象をエンタープライズが使える状態にしたというところであり、今後はユーザ価値の深化・新たなユーザ価値の発掘が求められていく。それに応じたプロダクトバックログの作成がこれから求められるという状況になってきた。
back checkは幸いにも様々な方向で「今後はこういうところにも使えるのではないか」といった議論がなされており、アイデアの種はたくさんあった。しかし、アイデアがアイデアのままで終わっており、このままではプロダクトの機能として組み込むにはあまりにも荒いもので止まっており、バックログに入れられる状況にはなっていなかった。
その課題を解消するために、ディスカバリーチームという、不確実性が高いが、成功すると大きなインパクトのある施策を検証するチームを組成し、検証を行っている。
ディスカバリーチームはあまたあるアイデアを、適切な不確実性マネジメントを実施した上で、「この施策はこういうユーザのこういう課題を解決でき、このような数値の向上を見込めるのでやるべきだ」といえるような解像度に持っていくというミッションを担っている。
ディスカバリーチームをやり始めて見えてきた、ヒトの特性
ディスカバリーチームは前述の通り、不確実性の高いものに向き合うチームである。
転がっているアイデアは玉石混交であり（たいていは石のようにしか見えない）、適切な検証プロセスを経てもいいアイデアであるかどうかはわからない。
そういった暗中模索の中でも、新しく不確実なものに触れていることに楽しみを見出す人もいれば、より情報が揃ってから合理的に判断していきたいという人もいるというのがわかってきた。
当該チームの組成時は、まだROXX自身初めての試みであり、まだチームとしての存在が不確実な状態であったため、必要以上のメンバーアサインは控えていたのだが、このチームへのジョインを立候補してくれたメンバーがまさしく当該不確実性に対して楽しみを見出してくれる人であり、すでに案件を持って検証を回してくれている状態になっている。
back checkにも機能が搭載されているが、FFS（Five Factors & Stress）理論という個人の性格特性とストレス因子をもとにした性格診断のようなものをROXXでは活用している。
FFS（Five Factors & Stress）理論とは、「ストレスと性格」の研究において開発されたものです。人の思考行動特性を５因子とストレス値で定量化し、個人の潜在的な強みが、ポジティブに発揮されているか、ネガティブに発揮されているかわかります。さらに、人と人の関係性を客観的に把握・評価でき、チームを最適な編成にすることができる理論です。
こちらの記事にも記載されている通り、FFS理論で計測すると不確実性を好む人は拡散性が高く、そうではない人は拡散性が低いということが見えてきた。
これはこの記事にも書いてあるとおり「個性」であり、どちらが良い悪いという話ではなくその人のパーソナリティから出てくる長所として捉える事ができるかと思う（当然場合によっては短所にもなりうる。）
今回のチーム編成での学びは「ディスカバリーチームのような不確実性に対峙するチームのメンバー編成は個の適性にも依存する」ということかと思う。
プロダクト開発における不確実性とその解消法
スクラムを組成するという手段と目的を振り返る
話を一段抽象化してみる。昨今プロダクト開発する上でスクラム開発という手法を取り入れている開発チームは多いのではないかと思う。
ROXXは2事業運営しているが、双方ともに開発チームを有しており、スクラム開発がかなりしっかり回っているのが特徴。しっかりとチーム一眼となって一つのゴールに向かって進むということが実現できている。
なにか不明点があれば気軽にチームメンバーがサポートできる環境であるし、スプリントで決めたスプリントバックログを達成するために全体が責任を持って達成にコミットしていくという流れができ、振り返りも適切にアクションに落として改善に回せている。
一方で前章での学びの様な、「個性」が十二分に生きるような環境において適切なチーム配分であったのか、より適切な人材配置によって全体最適をより達成できる状況にできないのか？という問いに対しては、まだまだ改善する余地はあるのではないかというふうに考えている。
スクラム開発では通信不確実性を解決できる
スクラム開発は下記ブログで述べている中では通信不確実性の解消に寄与している
- 目的不確実性
- 何を作るのかという不確実性
- 方法不確実性
- どうやって作るのかという不確実性
- 通信不確実性
- コミュニケーション上発生する不確実性
スクラム開発でそれ以外の不確実性を解消できないかというとそうではないが、少なくともスクラム開発がそれ以外の不確実性を解消するためのフレームワークとは言い難い。
特に目的不確実性に関しては、事業特性やプロダクトチームに閉じない事業部全体の状況、設定する視座や時間軸に左右されることが多いため、「開発チームに閉じるスクラム」では対象とされづらいと考えている。
ディスカバリーチームは目的不確実性によりチームを分けた
では、ディスカバリーチームの編成はどういうチーム編成と言えたのか。それは目的不確実性の高低によって分割できたと言えるのではないかと考えている。
また、その目的不確実性の高低は個の適性を選ぶというのは、実感値として見えてきているものである。
現時点ではチーム組成そのものも検証段階であり、日々チームとしての進め方も試行錯誤しながら前に進んでいる状況ではあるので少人数チームで運営しているが、このチーム編成は誰でも良かったかと言われるとかなり疑問を感じる。
そうしたときに、エンジニアリングマネジメントの観点で、今回のチーム組成は学びがある事例だったように感じる。つまりその人の個性を考えた上で、全体最適のために適切なチーム組成を行い、結果新しい価値を創造できたといえるのではないか。
エンジニアとしてのキャリアの前に、人としてのキャリアを考える
エンジニアリングマネジメントの観点から当該学びを振り返ってみる。
人は誰しも得意なことと苦手なことがあるのかなと思っている。
キャリア形成を考えたときに、得意を伸ばしていくという方向と、苦手を克服していくという方向があるのかなと思っているが、個人的には必要最低限の苦手さえ克服できていれば、あとはいかに得意を伸ばせるかに注力するのが良いのかなと思っている。
得意なことをやっているときのほうが前向きな気持ちになり、その長所を伸ばしていくことを楽しんでやっていけるかなと思うのと、ジョブ型採用が加速していく中、明確な強みを持っているかどうか、それによって結果を出せているかどうかが今後市場価値が上がっていくだろうという見立てがあると思っているためである。
エンジニアリングマネジメントにおいては、その得意をどう伸ばすのか、また、その得意が集まったチームでどうやって相互作用を作り出していくのかを考えていくことが醍醐味なのではないかというふうに考えている。
その得意を伸ばすための環境は、当然個に向き合い、その人を引き上げるというアプローチもあるが、その個が有している特性をベースに、チームとしてのミッションレベルを分けるというアプローチもあるということが今回の学びといえる。
エンジニアマネジメントをエンジニアリングする
「得意を伸ばすこと」「得意同士を相互作用させること」はエンジニアリングの設計に抽象化できるのかなと考えている。
各コンポネントとそのインターフェースを設計し、そのインターフェースを意識しながらコンポネント内部をアップデートしていくという感覚。
そのインターフェースをどのように設計するのかというところに関しては、今回FFSを用いた不確実性に対する適性を一例にあげてみた。
それ以外にもインターフェースたる組織論は色々とあると思うが、このインターフェースこそが事業における成長因子であり、その成長因子を明確にしたうえで適切なチーム編成や環境を用意することと、その因子そのものをいかに向上させていくのかというのがエンジニアリングマネジメントにおけるセオリーなのではないかと考える。
ただ、当然人が関わってくるところなので、単純な設計論ではカバーしきれない。上記を達成するには個々のメンバーとの接点を増やし、柔らかいコミュニケーションが求められる。
仕組みを考えることに集中しつつ、柔らかいコミュニーケーションを実施するというのは時に相反することなので、自分ひとりでやるものではないと考えていて、もし一緒に実現してみたいという方がいらっしゃればカジュアルにお話できればと思っています。
また、この仕組み化はROXXのエンジニアリングマネジメントに閉じないと考えていて、HRtechを運営しているROXX社の新たな提供価値に昇華することもできる。そういった観点でプロダクト作りに興味のある方もぜひお話しましょう。
また、このようなイベントも開催予定なので、もしご興味あれば応募いただければと思います。