プロダクトマネジメントとソフトウェアエンジニアリングについての覚え書き

この文章は自分のプロジェクトマネジメントとエンジニアリングに対する理解のダンプです。自分はソフトウェアエンジニアなので、ソフトウェア=プロダクトという前提です。なぜエンジニアリングがくっついてくるかと言えば自分はプロダクトマネジャーではないので、プロダクトマネジメントと関わり方としてはプロダクトマネジメントという世界観の中でエンジニアリングをするというスタイルが多いから。
なぜ書いたのだろう。なぜ書いたのでしょうね。多分プロダクトマネジメントが体系化されておらず一人一派な状況なので自分のメンタルモデル持っておきたかったんだと思う。1年後見たときずいぶん考え方変わったなとか実践した結果考えが精緻化されたなとか思えればいいと思ってる。関連: メンタルモデルを作り込むという遊び - 下林明正のブログ

プロダクトマネジメントとはなにか

プロダクトマネジメントとはなにか?に対する自分の理解は、プロダクト開発の各アクティビティをプロダクトとその顧客を中心にした統合する手法ないし価値観である。プロダクト開発のアクティビティとはエンジニアがコード書いたりデプロイしたり、ビジネスの人間がマーケティングしたり、デザイナーがワイヤフレーム作ってたりと、プロダクトを成立させるためのすべてのアクティビティのことを指している。事業部でやること全部というイメージに近い。そういったあらゆるアクティビティをプロダクトとその顧客を中心に統合することないし統合を可能にしていく組織作りをプロダクトマネジメントだと理解している。
したがって各アクティビティは既存の概念でも登場するものばかりになる。プロジェクトマネジメントだったりマーケティングだったりデザイン思考だったり。プロダクトマネジメントに特有のアクティビティというのは特に存在しないと思っていて、あるのは今まで語り尽くされているような個別のアクティビティを、どういう価値観をコアにするとうまく統合できるかという話だと思っている。で、そのコアとなるのがプロダクトと顧客である。

プロダクトと顧客

良いとされる価値というのは無数にある。アジャイルでもDevOpsでもXPでもどういう価値が良いとされているかはそれぞれ決まっている(大体どれも同じことを指しているのだが *1 )。プロダクトマネジメントの場合はプロダクトと顧客が最も重要という価値判断をしている。この価値判断を受け入れないとプロダクトマネジメントは始まらない。この価値判断を正しくないと思うのであれば他の価値判断をすればいい。自分たちのやっているビジネス次第では他の価値を重視した方が良い場合もあるだろう。正しいと思っているがうまく浸透しないというのとそもそも正しいと思っていないというのは異なる。
プロダクトと顧客を最重視するとは一体どういうことか。これはプロダクト(が提供したい)の価値と顧客(の求めている)価値の一致を重視するということだと理解できる。プロダクトの価値を顧客に押しつけるわけでもなく顧客の価値を無条件に受け入れるわけでもなく、その一致を指向するということ。一致のさせ方はいろいろあると思う。顧客さえ気づいていなかったニーズを発見できる場合もあれば、顧客のニーズからプロダクトが変化していく場合、プロダクトによって顧客のニーズがより鮮明になる場合。いずれにせよ、これらの一致を指向すること。現状一致しなくても良いが不断の努力で一致させていくこと。それがプロダクトマネジメントのコアになっている。
自分はプロダクトとはその組織の価値観の結晶的側面も持っていると思っている。プロダクトの価値観を顧客の価値観に近づけるというのは組織の価値観を変えていくという意味でもある。

アクティビティを統合する

プロダクト開発に必要なアクティビティは広範囲でありそれぞれに深い知識を要する。よほど規模か小さくなければ一人で全部まかなうことはできない。専門家も異なれば使うツールや言葉も異なるだろう。だからともすればバラバラに動き始めてしまうだろう。そういった性質の違うアクティビティをまとめ上げるのがプロダクトマネジメントである。エンジニアリングの価値観でもビジネスの価値観でもなく、中心をプロダクトとする。プロダクトを中心にそれぞれの価値観がブレイクダウンされ統合しなくてはならない。

プロダクトマネジャーは何をするか

プロダクトに関すること全部。といっても実際に全部やることは不可能である。だから、根本となるプロダクトと顧客価値に関することを主に行う。具体的には以下のようなことだ。
1つめはプロダクトの価値の同定とその展開。マーケティング手法や仮説検証を繰り返して顧客の価値を推定しプロダクトが実現すべき価値を決める。これはプロダクトの根本になるためプロダクトマネジャーが自らやるしかない。
もう1つはビジョンや戦略の共有。進むべき方向をチームに共有する。指針さえ共有できていれば実行については任せればよい。最小の労力で最大の成果をあげるアクティビティがビジョンや戦略の共有である。ここさえちゃんとできていれば後はチームに任せれば良い。逆にいえばビジョンも戦略もなければチームは自律的に動けなくなるので、1つ1つにプロダクトマネジャーの判断が必要になりいずれプロダクトマネジャーはボトルネックになる。

エンジニアリング、ビジネス、デザイン

プロダクト開発に必要な3分野としてエンジニアリング、ビジネス、デザインがでてくる。自分はこれらをアクティビティのカテゴリではなく視点として理解している。つまりある一つの現象でも視点によって解釈が違う。例えば締め切り一つとってもビジネス的視点とエンジニアリング的視点では解釈が違う。エンジニアリング的視点で言えばそもそも締め切りというものは原理的に設定できない。ソフトウェア開発は学習プロセスであって生産ではない。だから締め切りをコミットメントしてるわけではなく、見積もり(と不確実性)という事実を提示しているだけという立場をとる。一方でビジネス視点ではリリース日を後ろにずらされては困ってしまう。コミットメントとして締め切りがほしいのである。これらの溝を解消する手段はいくらでもあるはずが、困るのは各々の視点があると理解せず、自分たちの視点からの解釈に意固地になることである。
街を眺めるのに、南から眺めるか北から眺めるかみたいな話だと思う。南から眺めるとビルが邪魔になって北の方がどうなっているかわからないが決して存在してないわけじゃない。また同じ建物も南側から見るか北から見るかで印象がずいぶん変わる。全体を眺めたいと思って航空写真を見ると立体感は失われるし、街の中を探索しているだけでは全体はつかめない。*2

エンジニアリングがなにをすべきか

まず確固たるエンジニアリング目線として機能。エンジニアリング視点でプロダクト全体を見渡して解釈をつけるする。次にその解釈を他の視点とすり合わせる。エンジニアリング的視点ならば是なことでも他の視点では非なことはいくらでもあるはず。見ている角度が違うのであれば解釈が食い違うのは当然で、逆に言えば異なる解釈を提供できないのであればエンジニアリング視点をプロダクトの意思決定に反映させる必要がない。それらの視点を統合して方針を決める。統合の際に指針となるのがプロダクトの価値となる。プロダクトの価値という共通目標があるからこそそれぞれの視点が統合できる。最後に統合された視点を持って技術を適用する。
技術駆動については否定しない。やってみなければわからないことはいくらでもあるし、単なるツールの導入がプロダクトの方針自体も変わっていく可能性もある。エンジニアの感覚でそれらが行われることはポジティブだ。ただしいつかはプロダクト全体と整合させていかなければならない。
エンジニアリング的視点に関連して1つ補足。エンジニアリング視点では可視だが他の視点では不可視なもの、つまりもっとも注意しべきものはなにかといえば技術的負債*3になると思う。技術的負債はエンジニアリングだけではなくプロダクト全体で対応していくべきものであるが、もっとも技術的負債に近く肌身を持って感じているのはエンジニアである。だからこそ技術的負債に関してはエンジニアリングが占める責任が大きいと思う。

ちょっとした参考本リスト。
  • 作者:マーティ・ケーガン,佐藤真治,関満徳
  • 発売日: 2019/11/09
  • メディア: Kindle版
  • 作者:Melissa Perri
  • 発売日: 2020/10/26
  • メディア: 単行本(ソフトカバー)
プロダクトマネジメントの本を読んでも結局はプロダクトマネジメントってのはどこを指すのかがわからなかった。今は価値観とそれを実現するマネジメントと組織論だと理解してる。それ以外のところは各論(プロジェクトマネジメントとかマーケティングとかデザイン思考とか)を読んだ方がいいなと感じた。
  • 作者:ロジャーS.プレスマン
  • 発売日: 2005/02/08
  • メディア: 単行本
  • 作者:Capers Jones,Olivier Bonsignour
  • 発売日: 2013/12/10
  • メディア: 単行本
  • 作者:KentBeck,CynthiaAndres
  • 発売日: 2017/07/14
  • メディア: Kindle版
  • 発売日: 2011/07/04
  • メディア: 単行本
  • 作者:村上 陽一郎
  • 発売日: 2006/06/15
  • メディア: 単行本
  • 作者:マイケル・ジャクソン
  • 発売日: 2014/10/14
  • メディア: Kindle版
この記事ではそもそもソフトウェアエンジニアリングとはなにか?については書いてない。あくまでプロダクトマネジメント下のエンジニアリングの立ち位置について軽く触れただけ。そもそも(ソフトウェア)エンジニアリング自体顧客の価値がスタートになっているし、結構あらゆるアクティビティへの言及がある。だからこそエンジニアリングに属するアクティビティという世界観ではなく、まずフラットなアクティビティがありエンジニアリングはあくまで視点だという理解がしっくりくる。
  • 作者:スチュアート クレイナー
  • 発売日: 2000/12/01
  • メディア: 単行本
価値についての変遷は結構興味深い。どういう社会情勢で企業はなにを求めているかを理解すると、どうしてそういう価値が重視されるのかが理解しやすい。
  • 作者:ジャルヴァース・R・ブッシュ,ロバート・J・マーシャク,エドガー・H・シャイン
  • 発売日: 2018/07/04
  • メディア: Kindle版
  • 作者:小坂井敏晶
  • 発売日: 2016/07/22
  • メディア: Kindle版
全体論とかシステム論とか、現代の組織論の背景がわかるとスムーズなことがある。
  • 作者:Project Management Institute
  • 発売日: 2018/01/01
  • メディア: ペーパーバック
  • 作者:エイミー・C・エドモンドソン,Amy C. Edmondson
  • 発売日: 2014/05/24
  • メディア: 単行本
プロダクトマネジメントはプロジェクトマネジメントではないわけだけれど、プロジェクトマネジメントなしでプロダクトマネジメントはできないでしょう。アジャイル的世界観ではドキュメントよりコミュニケーションなわけだけれど、だからといってドキュメントで表現されていたことは不要になったわけではないし、コミュニケーションならば簡単にそれが実現できるわけでもない。チームのあり方の変遷をたどるのもおもしろい。
  • 作者:佐宗邦威
  • 発売日: 2015/07/22
  • メディア: Kindle版
  • 作者:Michael Keeling
  • 発売日: 2019/11/25
  • メディア: 単行本(ソフトカバー)
実践のなしで本当に物事を理解できることはないと思うが、出てきたキーワードの本くらいは読んでおくと相互理解がはかどる。大体同じような考え方してるなとわかるはず。
*1:顧客の価値を実現することか、そのために変化へ適応すること
*2:同僚がCities: Skylinesやってるとき書いたのでこういうたとえになってる
*3:ここでいう技術的負債は時間なくて雑に作ったので〜みたいなやつではなく、作ったときとドメインが食い違ってきたので〜みたいなやつを想定してるけど、他の視点から不可視に近いという意味ではそう変わらない気がする