『プロダクトマネジメント』原題: Escaping The Build Trap を読みました。
良書でした。同時にビルドトラップを生み出す組織構造にも興味が沸いてきました。
翻訳は安心と信頼の Ryuzee さん。 -> Ryuzee.com
原題にも書かれている ”ビルドトラップ” とは、プロダクトを作ることが目的化している状態のこと。
一見プロダクトを作るということは正しいように見える。だってプロダクトで儲けてるんだし。
でもビジネスの目的はプロダクトを作ることではなく儲けること。
儲けるということは顧客が対価を支払うということになる。
ここでプロダクトが差し出す対価とは顧客の問題がプロダクトによって解決され流ことになる。
この辺りはジョブ理論の影響を受けていそう。
ジョブ理論 イノベーションを予測可能にする消費のメカニズム (ビジネスリーダー1万人が選ぶベストビジネス書トップポイント大賞第２位！ ハーパーコリンズ・ノンフィクション)
つまりビジネスの目的は、顧客の目的を解決することであって、プロダクトを作ることではない。
一方で、プロダクトを作ろうとする圧力は必ず生まれる。
そしてなんのためにプロダクトを作るのか、という観点が失われると、機能の開発が目的化する。
機能が増えれば品質を確保するためのコストは上がり、使いやすさは低下し、ユーザー離れを起こしかねない。
この辺りは実はアジャイル開発が苦手にしている分野だと思う。
（解決しようとしていない、と言った方が正しそう）
スクラムで言えば、初めにバックログありき。でプロセスが描かれる。
バックログを価値に変換するためにスクラムを組んだりして価値を届ける。価値。価値がある、はず。きっと。
この辺りを明確にアジャイル開発は語っていないことが多い。
なんせアジャイル ”開発” だし。どちらかというとリーンスタートアップとかデザイン思考とかが色強め。
アジャイル開発は改善も組み込まれているので簡単にベロシティは上がっていく。
ベロシティが上がると嬉しいことに(罠)、機能がたくさん作れる。やったね！
でもアジャイル開発がなぜ必要なのか、という資料に9999％の確率で現れる Chaos レポートの、64％ の機能は使われていません！という事実。（ちょっと古いけど。）
ベロシティをあげると、これらのゴミ、もとい使われない機能を実装できることになる。本末転倒では？
”開発” というスコープに視野を狭めてしまうと、非常にこういった罠にハマってしまいやすい。
本書ではそうなってしまう理由を解説している。
要は顧客の問題を理解しないまま作ることが目的化してしまうという。
プロダクトマネジメントは顧客のないを解決しなければいけないのか、プロダクトの機能の Why に集中すべし。とのこと。
顧客に会って、顧客の行動を観察して、何を解決しなければいけないのか、また、今わかっていないことはなんなのか、次にやることはなんなのか、という型を提示し、事例で示している。非常にわかりやすい。
この型を通じて活動することで、Unknown unknowns が見えてくることになる。
この領域がないと断じて作り始めてしまうと、顧客が求めていないものを作ることになり、ビルドトラップにはまる。
（あれ、これってなんかウォーターフォールみたいだな。ウォーターフォールって究極のビルドトラップなのかも。）
また、この書は明らかにプロダクトマネージャ、プロダクトオーナー向けの本だが、同時にエンジニアやデザイナー向けの本でもあると思った。
イソップ寓話でいうところのダメなレンガ職人になっていないかを常に考えないといけない。
というか、「これを作って」って言われたら、いつだって、「なんで？」って聞き返さないといけない。
「何を解決したいからこれが欲しいの？」がわからないまま、表面的に言われたものを作ったところで、使い物になる可能性は低い。だってわかってないんだから完了条件満たしてるかわからないじゃない。
「完了条件は Acceptance Criteria に書いておいて下さい。」とか言い出す人もいる。きっといる。間違いなくいる。今脳裏に3人くらい浮かんだ。
その発想はおそらく、”個人との対話よりもツールやプロセスを重視” している。態度がプロダクト開発に向いてない。
Outside-in 志向で仕事をする。最終形から逆算して必要なものを作る、という発想でものを作らないと、言われたものを作る思考になりやすい。
会話が面倒だからって言われたものだけを作ろうとするといつまで経っても「仕様変更が多すぎてクソだわうちの客」とか愚痴り続ける人生になりそう。
少し触れられているが、「何をするか」を指示するのではなく、「何を解決したいか」を提示し、どうそれを実現するかは任せてしまえ、とある。
個人的にはチケットは状態で定義せよとスクラムチームに言っているのと同じ内容だったので安心した。
エンジニアとしても、Why を理解し要とすると最終的には顧客の何を解決するのか？に行き着く。結果、ドメインに踏み込んだ理解をする形になる。
ここまでくれば次にドメインの構造が見えてくるから、まともな設計もできるようになってくる。結果として変更しやすく理解しやすく、説明不可能なロジックが生まれなくて済む。割と。まあ勘違いしてたなら直せばいいし。
この本の面白いところは、組織としてプロダクトマネジメントを阻害する要因にも触れている点で、プロダクト企業の経営層にいる人は常に自分たちがこの状態に陥っていないか、PdM が顧客と話しているか、上司の顔ばっかり見ていないかを常に考えるべしという警鐘にもなっている。リーンエンタープライズにも少し近しいところはある。
組織として、戦略として、プロダクトマネジメントを据え置く上でどう構えるのか、どう構えるのが NG なのか、この辺りは組織論としても非常に興味深かった。
（ツリー構造の組織だと途端に顧客を見なくなるフォースが起動するから正直うまくいくのかなーという気はしなくもない。）
改めて、良いものを作るためには何を作るべきでないのか、を理解しないといけないなあと思わされる本だった。
----
この本を読んだ直後に社内で新サービスの話が出たときに、作る前からビルドトラップが生まれていてうーんこれは意識しないと本当に自然にハマってしまうんやなあと納得した。怖い怖い。
改めて考えてみると、「なぜそれを作るのか」を理解していないならそれは “エンジニア“ ではなく“コーダー“ なのかもしれない。（個人の感想です）
ｰｰｰｰ
思い返してみると、5年くらい前か？新しくチームを立ち上げると言うので PMO（という名の何でも屋）で PL サポートした際に、前任者は言われたことを言われた通りにやる人間でクビになっていた。後任として入ったら、頼んだことをそのままやってくれず質問を返してくるのに答えてると自分が理解してないことが分かったのでよかった、ってだいぶ長い付き合いになった案件があった。
ビルドトラップもあんなもんなのかもしれない。言われた通りやるのって楽なんだけど。
でも考えてみると、目的を理解して仕事をしましょう、って新人研修あたりで言われるよな・・・・・・・（オチなし）
