この文章は自分のプロジェクトマネジメントとエンジニアリングに対する理解のダンプです。自分はソフトウェアエンジニアなので、ソフトウェア=プロダクトという前提です。なぜエンジニアリングがくっついてくるかと言えば自分はプロダクトマネジャーではないので、プロダクトマネジメントと関わり方としてはプロダクトマネジメントという世界観の中でエンジニアリングをするというスタイルが多いから。

なぜ書いたのだろう。なぜ書いたのでしょうね。多分プロダクトマネジメントが体系化されておらず一人一派な状況なので自分のメンタルモデル持っておきたかったんだと思う。1年後見たときずいぶん考え方変わったなとか実践した結果考えが精緻化されたなとか思えればいいと思ってる。関連: メンタルモデルを作り込むという遊び - 下林明正のブログ

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

プロダクトマネジメントとはなにか？に対する自分の理解は、プロダクト開発の各アクティビティをプロダクトとその顧客を中心にした統合する手法ないし価値観である。プロダクト開発のアクティビティとはエンジニアがコード書いたりデプロイしたり、ビジネスの人間がマーケティングしたり、デザイナーがワイヤフレーム作ってたりと、プロダクトを成立させるためのすべてのアクティビティのことを指している。事業部でやること全部というイメージに近い。そういったあらゆるアクティビティをプロダクトとその顧客を中心に統合することないし統合を可能にしていく組織作りをプロダクトマネジメントだと理解している。

したがって各アクティビティは既存の概念でも登場するものばかりになる。プロジェクトマネジメントだったりマーケティングだったりデザイン思考だったり。プロダクトマネジメントに特有のアクティビティというのは特に存在しないと思っていて、あるのは今まで語り尽くされているような個別のアクティビティを、どういう価値観をコアにするとうまく統合できるかという話だと思っている。で、そのコアとなるのがプロダクトと顧客である。

プロダクトと顧客

良いとされる価値というのは無数にある。アジャイルでもDevOpsでもXPでもどういう価値が良いとされているかはそれぞれ決まっている(大体どれも同じことを指しているのだが *1 )。プロダクトマネジメントの場合はプロダクトと顧客が最も重要という価値判断をしている。この価値判断を受け入れないとプロダクトマネジメントは始まらない。この価値判断を正しくないと思うのであれば他の価値判断をすればいい。自分たちのやっているビジネス次第では他の価値を重視した方が良い場合もあるだろう。正しいと思っているがうまく浸透しないというのとそもそも正しいと思っていないというのは異なる。

プロダクトと顧客を最重視するとは一体どういうことか。これはプロダクト(が提供したい)の価値と顧客(の求めている)価値の一致を重視するということだと理解できる。プロダクトの価値を顧客に押しつけるわけでもなく顧客の価値を無条件に受け入れるわけでもなく、その一致を指向するということ。一致のさせ方はいろいろあると思う。顧客さえ気づいていなかったニーズを発見できる場合もあれば、顧客のニーズからプロダクトが変化していく場合、プロダクトによって顧客のニーズがより鮮明になる場合。いずれにせよ、これらの一致を指向すること。現状一致しなくても良いが不断の努力で一致させていくこと。それがプロダクトマネジメントのコアになっている。

自分はプロダクトとはその組織の価値観の結晶的側面も持っていると思っている。プロダクトの価値観を顧客の価値観に近づけるというのは組織の価値観を変えていくという意味でもある。

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

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

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

プロダクトに関すること全部。といっても実際に全部やることは不可能である。だから、根本となるプロダクトと顧客価値に関することを主に行う。具体的には以下のようなことだ。

1つめはプロダクトの価値の同定とその展開。マーケティング手法や仮説検証を繰り返して顧客の価値を推定しプロダクトが実現すべき価値を決める。これはプロダクトの根本になるためプロダクトマネジャーが自らやるしかない。

もう1つはビジョンや戦略の共有。進むべき方向をチームに共有する。指針さえ共有できていれば実行については任せればよい。最小の労力で最大の成果をあげるアクティビティがビジョンや戦略の共有である。ここさえちゃんとできていれば後はチームに任せれば良い。逆にいえばビジョンも戦略もなければチームは自律的に動けなくなるので、1つ1つにプロダクトマネジャーの判断が必要になりいずれプロダクトマネジャーはボトルネックになる。

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

プロダクト開発に必要な3分野としてエンジニアリング、ビジネス、デザインがでてくる。自分はこれらをアクティビティのカテゴリではなく視点として理解している。つまりある一つの現象でも視点によって解釈が違う。例えば締め切り一つとってもビジネス的視点とエンジニアリング的視点では解釈が違う。エンジニアリング的視点で言えばそもそも締め切りというものは原理的に設定できない。ソフトウェア開発は学習プロセスであって生産ではない。だから締め切りをコミットメントしてるわけではなく、見積もり(と不確実性)という事実を提示しているだけという立場をとる。一方でビジネス視点ではリリース日を後ろにずらされては困ってしまう。コミットメントとして締め切りがほしいのである。これらの溝を解消する手段はいくらでもあるはずが、困るのは各々の視点があると理解せず、自分たちの視点からの解釈に意固地になることである。

街を眺めるのに、南から眺めるか北から眺めるかみたいな話だと思う。南から眺めるとビルが邪魔になって北の方がどうなっているかわからないが決して存在してないわけじゃない。また同じ建物も南側から見るか北から見るかで印象がずいぶん変わる。全体を眺めたいと思って航空写真を見ると立体感は失われるし、街の中を探索しているだけでは全体はつかめない。*2

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

まず確固たるエンジニアリング目線として機能。エンジニアリング視点でプロダクト全体を見渡して解釈をつけるする。次にその解釈を他の視点とすり合わせる。エンジニアリング的視点ならば是なことでも他の視点では非なことはいくらでもあるはず。見ている角度が違うのであれば解釈が食い違うのは当然で、逆に言えば異なる解釈を提供できないのであればエンジニアリング視点をプロダクトの意思決定に反映させる必要がない。それらの視点を統合して方針を決める。統合の際に指針となるのがプロダクトの価値となる。プロダクトの価値という共通目標があるからこそそれぞれの視点が統合できる。最後に統合された視点を持って技術を適用する。

技術駆動については否定しない。やってみなければわからないことはいくらでもあるし、単なるツールの導入がプロダクトの方針自体も変わっていく可能性もある。エンジニアの感覚でそれらが行われることはポジティブだ。ただしいつかはプロダクト全体と整合させていかなければならない。

エンジニアリング的視点に関連して1つ補足。エンジニアリング視点では可視だが他の視点では不可視なもの、つまりもっとも注意しべきものはなにかといえば技術的負債*3になると思う。技術的負債はエンジニアリングだけではなくプロダクト全体で対応していくべきものであるが、もっとも技術的負債に近く肌身を持って感じているのはエンジニアである。だからこそ技術的負債に関してはエンジニアリングが占める責任が大きいと思う。

ちょっとした参考本リスト。

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

作者:マーティ・ケーガン,佐藤真治,関満徳
発売日: 2019/11/09
メディア: Kindle版

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

作者:Melissa Perri
発売日: 2020/10/26
メディア: 単行本（ソフトカバー）

プロダクトマネジメントの本を読んでも結局はプロダクトマネジメントってのはどこを指すのかがわからなかった。今は価値観とそれを実現するマネジメントと組織論だと理解してる。それ以外のところは各論(プロジェクトマネジメントとかマーケティングとかデザイン思考とか)を読んだ方がいいなと感じた。

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-

作者:ロジャーS.プレスマン
発売日: 2005/02/08
メディア: 単行本

ソフトウェア品質の経済的側面

作者:Capers Jones,Olivier Bonsignour
発売日: 2013/12/10
メディア: 単行本

エクストリームプログラミング

作者:ＫｅｎｔＢｅｃｋ,ＣｙｎｔｈｉａＡｎｄｒｅｓ
発売日: 2017/07/14
メディア: Kindle版

要求工学知識体系第1版

発売日: 2011/07/04
メディア: 単行本

工学の歴史と技術の倫理

作者:村上陽一郎
発売日: 2006/06/15
メディア: 単行本

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

作者:ピートマクブリーン
メディア: 単行本

ソフトウェア要求と仕様（電子版）: 実践，原理，偏見の辞典

作者:マイケル・ジャクソン
発売日: 2014/10/14
メディア: Kindle版

この記事ではそもそもソフトウェアエンジニアリングとはなにか？については書いてない。あくまでプロダクトマネジメント下のエンジニアリングの立ち位置について軽く触れただけ。そもそも(ソフトウェア)エンジニアリング自体顧客の価値がスタートになっているし、結構あらゆるアクティビティへの言及がある。だからこそエンジニアリングに属するアクティビティという世界観ではなく、まずフラットなアクティビティがありエンジニアリングはあくまで視点だという理解がしっくりくる。

ソフトウェア品質知識体系ガイド (第3版) ―SQuBOK Guide V3―

発売日: 2020/12/14
メディア: Kindle版

マネジメントの世紀1901~2000

作者:スチュアートクレイナー
発売日: 2000/12/01
メディア: 単行本

価値についての変遷は結構興味深い。どういう社会情勢で企業はなにを求めているかを理解すると、どうしてそういう価値が重視されるのかが理解しやすい。

対話型組織開発――その理論的系譜と実践

作者:ジャルヴァース・Ｒ・ブッシュ,ロバート・Ｊ・マーシャク,エドガー・Ｈ・シャイン
発売日: 2018/07/04
メディア: Kindle版

社会心理学講義　──＜閉ざされた社会＞と＜開かれた社会＞ (筑摩選書)

作者:小坂井敏晶
発売日: 2016/07/22
メディア: Kindle版

全体論とかシステム論とか、現代の組織論の背景がわかるとスムーズなことがある。

プロジェクトマネジメント知識体系ガイド PMBOKガイド第6版(日本語)

作者:Project Management Institute
発売日: 2018/01/01
メディア: ペーパーバック

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

作者:エイミー・C・エドモンドソン,Amy C. Edmondson
発売日: 2014/05/24
メディア: 単行本

プロダクトマネジメントはプロジェクトマネジメントではないわけだけれど、プロジェクトマネジメントなしでプロダクトマネジメントはできないでしょう。アジャイル的世界観ではドキュメントよりコミュニケーションなわけだけれど、だからといってドキュメントで表現されていたことは不要になったわけではないし、コミュニケーションならば簡単にそれが実現できるわけでもない。チームのあり方の変遷をたどるのもおもしろい。

21世紀のビジネスにデザイン思考が必要な理由

作者:佐宗邦威
発売日: 2015/07/22
メディア: Kindle版

Design It! ―プログラマーのためのアーキテクティング入門

作者:Michael Keeling
発売日: 2019/11/25
メディア: 単行本（ソフトカバー）

THE MODEL（MarkeZine BOOKS）マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス

作者:福田康隆
発売日: 2019/01/30
メディア: Kindle版

他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)

作者:宇田川元一
発売日: 2019/10/02
メディア: Kindle版

実践のなしで本当に物事を理解できることはないと思うが、出てきたキーワードの本くらいは読んでおくと相互理解がはかどる。大体同じような考え方してるなとわかるはず。

*1:顧客の価値を実現することか、そのために変化へ適応すること

*2:同僚がCities: Skylinesやってるとき書いたのでこういうたとえになってる

*3:ここでいう技術的負債は時間なくて雑に作ったので〜みたいなやつではなく、作ったときとドメインが食い違ってきたので〜みたいなやつを想定してるけど、他の視点から不可視に近いという意味ではそう変わらない気がする

2021-04-08

n=1の事例をどうすれば一般化できるのか知りたくて「質的研究の考え方」読んだ

チームや組織、ソフトウェア開発の問題について考えたり、それについて議論したりするとき、自分の体験や相手の体験を参考にすることが多い。参考というよりはベースと言った方が正しいかも知れない。そういう個人の体験を語るとき「n=1」という批判が飛び出すことが多々ある。つまり十分にデータがないのに正当性あるのか、単なる個人の感想ではないのかと問うてる(問われてる)わけである。

客観的、定量的に考えるべき問題があることは認めるが、その一方で定量的には考えることのできない問題もたくさんあるはず。量的に問題を考えることだけが正解ではないとは思うが、いまいちこの辺の心構えというかメンタルモデルが構築しきれていない。つまり個人的な体験や経験はどのように相対化して普遍的なプラクティスを取り出せばよいのかという話。

この課題を考えるに当たり質的研究の考え方―研究方法論からSCATによる分析まで―を読んで勉強した。特に(アカデミックな)研究をしたいわけではないが、質的研究の知恵を借りることで、量的にアプローチできない問題の分析やそこから導かれる結論の質を高められると考えられると考えたわけである。

ちなみに質的研究とは量的研究の対比で、量的研究が「対象を測定することで数量化されたデータを得、それを処理して結論を得る研究」に対して

仮説検証を目的としない
実験的研究状況を設定しない
観察やインタビューから主に言語的記録を作成する
記録に基づいて分析し理論化する
記録以外の資料も総合して研究する
研究者の主観・主体的解釈を積極的に活用する
研究対象を有する具体性や個別性や多様性を通してい一般性や普遍性に迫る
心理・社会・文化的な文脈を考慮しデータ採取とデータ分析をする
そのようにして現象に内在・潜在する意味を見いだし研究参加者とともに人や社会の理解に努める

ような特徴をもつ研修手法である。

読んでみて、まだ消化しきれない部分はあるが、自分の中に一本筋を通すためのヒントが得られた気がする。

特に

質的研究の背景にある系譜やパラダイム
サンプリングサイズと「理論的飽和」の解説から、さらになぜn=1でも研究が成立するのか
研究者の主観をどう扱えばよいか
概念的・理論的枠組みをどのように分析にりようすればよいか、複数の枠組みを同時に利用してよいのか

あたりは参考になった。

またこの本では質的研究は「人間に対する理解と共感の重要であり、研究を通して自己の理解と受容も必要になる社会的行為」であるといっている。この態度は、自分の所属する組織について考え、組織やひいては自分を成長させていく際に大切な心構えでもあると感じた。

質的研究の考え方―研究方法論からSCATによる分析まで―

作者:大谷尚
発売日: 2019/04/10
メディア: 単行本（ソフトカバー）

しろうと理論―日常性の社会心理学

作者:アドリアン・フランクファーンハム
発売日: 1992/06/01
メディア: 単行本

測りすぎ――なぜパフォーマンス評価は失敗するのか？

作者:ジェリー・Z・ミュラー
発売日: 2019/05/10
メディア: Kindle版

しろうと理論と測りすぎは以前に読んでいたが、質的研究の考え方を経てもう一度読みたくなった。

最近暇すぎて本読むかAPEXやるかしかない。実際本読んでるかAPEXやってるかなのだから暇ではないはずなのだが、強制的にやらされることの時間が減ると暇と認識してしまうらしい。どれだけ読書(仕事のため/自分のために関わらない)しても、他人から締め切り設定されたわけではなく自分の興味でやっている限り暇と感じてしまう。

角待ちは対空

おもむろガウェイン

GWにちいかわをキャッチアップしたい人に送るまとめ

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