今日はこのへんで

プログラミングやプロダクト開発について。もしくはただの雑記。

エンジニアリングとプロダクト、その役割の違い

今の職場に移ってから何度か組織の変更があって、少し思うところもあったので、自分の中でのエンジニアリングとプロダクトの違いについて少し整理をしておこうと思う。

さて、ITを生業とする組織では、VP of Engineeringとか、VP of Productとか、はたまたCTOとかいう役職の人がいる。それなりの組織でも3つとも役職がある場合は少なくて、CTOだけだったり、各VPを兼務していたりする場合が多いような気もするのは、それぞれの役割が各組織で定義され、共通認識が曖昧だからなのかもしれない。

自分の中では、端的にいうと、「正しいプロダクトを正しくエンジニアリングする」という分担がしっくりきている。顧客が何を価値をとしているのかを掴み、どういった機能を作るかを考える、つまりWhatの部分はプロダクトの仕事であり、それをどうやって実装して顧客に届けるかのHowの部分はエンジニアリングの仕事である、と思う。

プロダクトのリーダーにとって、最も大切な指標はユーザの継続率だろう。継続率こそ、ユーザがそのプロダクトにお金を払うだけの価値を見出しているかどうかの判断基準であり、この数値が企業の黒字化、はては存続を左右するからだ。

対して、エンジニアリングのリーダーにとって最も大切な指標は、おそらくチームの生産性だろう。どれだけ早く新しい機能をユーザに提供し、どれだけ早く学びを得られるかによって、企業の生死が決まる。エンジニアリングにおいては、その原動力となる生産性を最大化することが至上命題といえる。

そうした役割の違いがあるなかで、組織のメンバーとしてのエンジニアは、プロダクトとエンジニアリングの両方の役目を担うことになる。新規の機能を実装し届けるにあたって、デザイナーやプロダクトマネージャーも含めたチームを構成するのは当然の判断だが、エンジニアはプロダクトチームに属して機能開発をしながら、同時にリファクタリングや様々なフローのシステム化のようなエンジニアリングを行う。組織が大きくなってくると、QAエンジニアのチームや何かしらの基盤チームなど、エンジニアリングを専門とするチームも必要になってくるのが自然な組織の成長のように思う。

組織全体としては、プロダクトとエンジニアリングに書ける時間比率は半々くらいが健全だと思う。とはいえ、これは企業のフェーズによって変わってくるもので、ユーザへの提供価値が薄い初期のプロダクトでは、多少効率が悪くても(例えば手の温もりのあふれるデプロイフローを使ってでも)プロダクトの機能開発を優先させなければならないかもしれないし、ユーザを大量に抱えるプロダクトでは、SREチームなど先に述べたようなエンジニアリングを専門に行うチームが必要になるかもしれない。

自分の組織に最適な比率を知ることは難しいかもしれないが、組織が健全かどうかを知るのはそれほど難しくない。メンバーの声を聞けば、たいてい何かしらのアラートが出ているはずだからだ。例えばプロダクトマネージャーが、エンジニアが何をやっているのかさっぱりわからないと言えば、それはおそらくそのエンジニアのエンジニアリング比率が高いことを表す。その上で、継続率やそれに結びつく指標が伸びていないとすれば、その組織はおそらく早すぎる最適化によって、時間を無駄にしている。逆に、エンジニアがバグの修正に時間を取られ、日々のベロシティも上がらないようなら、おそらくリファクタリングが必要な状態なのだと言える。

時として、エンジニアリングに時間を割くのは無駄ではないかと、プロダクトチームにおけるエンジニアリングの比率が軽視されることがある。これはおそらくエンジニアリングの専門性が理解されないことが原因だと思うのだが、例えそれが理解されなくても、大事なのはプロダクトとエンジニアリングにかける比率をお互いに最大限尊重しあい、領域を侵犯しないことだろう。エンジニアリングのリーダーは、次々と新しい言語やライブラリに挑戦したがるエンジニアの手綱をひき、常に早すぎる最適化に注意を払いつつ、必要な技術投資をして競争力を維持しなければならない。プロダクトのリーダー・メンバーは、エンジニアリングの内容がブラックボックスだったとしても、それに時間を割かないことが際限のないバグを生み、ユーザの信頼を損ねる結果となることを理解しなければならない。エンジニアリングを怠れば、最悪プロダクトの作り直しを迫られることになる。年季の入ったプロダクトの作り直しには長い時間がかかるし、その間、ユーザへの新しい価値提供は止まる。

さて、それではCTOの役割はなんだろう。個人的には、プロダクトとエンジニアリング両方の組織を、メンバーの強みに合わせて上手く組成し、育てることが一番の役割のように思う。各エンジニアの強み、志向を理解し、力のあるものをリーダーに任命するのがCTOの役割だ。技術に明るいリーダーがいるのであれば、プロダクトのリーダーはマーケティング出身の者やデザイナー出身の者でも良いかもしれない。プロダクトマネージャーが足りなければ、プロダクト志向の強いエンジニアの役割を転換させるのも手かもしれない。事業の価値をさらに強化するために、機械学習の専門チームが必要かもしれない。経営の方向性と照らして、そうした組織の組成における意思決定を行い、メンバーを監督するのがCTOの役割のように思う。とは言いつつも、エンジニアの少ない初期のチームではCTO自らががりがりコードを書くことで周りを鼓舞し、事業を前に進めていくことが求められるし、フェーズが変わってもそういうスタイルの人もいる。どこかのタイミングで創業者とプロ経営者が交代するように、技術に強いが人には興味がないような人から、組織作りに強い人に、CTOという肩書きや役割が移譲されることもよくあるようだ。

というのが、今のところの自分なりの理解だった。なんにせよ、メンバーの強みに合わせて、組織は変わっていくものであり、また持てるものを最大限活かすために変わっていくべきものでもあると思うし、「正しいプロダクトを正しくエンジニアリングする」ということが組織としてできていれば、役職やラベルはどうでも良いのだけど。


ピープルウエア 第3版

ピープルウエア 第3版