見出し画像

『プロダクトマネージャーのしごと』を読んで

nekonado

2023年末にアトラクタさんの書籍プレゼントキャンペーンに当選し、『プロダクトマネージャーのしごと』をいただきました。

年明けから読み進め、ようやく感想を書く決心がついたので、文章に起こそうと思います。

わたしは誰か

インターネットでは、ねこなど（nekonado）の名前で暮らしています。

2020年4月にNTT DATAグループのSIerにSEとして新卒入社し、その後転職をして現在はSasuke Financial Lab 株式会社という保険ドメインのスタートアップで働いてます。

現職ではコのほけん！というデジタル保険代理店サービスの開発にエンジニアとして参画しており、入社してからの1年半、主にフロントエンドのコードを書くことでプロダクト開発に携わってきました。ただし、直近では「スクラムの開発チームリーダー」のような名前で呼ばれるポジションにおり、業務のコードを自分で書く時間は少なくなってきている、そんな人です。

本書を読んで感じたこと

前提として、私はプロダクトマネージャーでもなければ、〇〇マネージャーという肩書きですらありません。ですが、本書はそういった名前を持たないエンジニアや、プロダクト開発に携わる全ての人にとって読む価値がある本だと感じました。

それぞれの章がどれも面白く、網羅的なレビューをすると正直時間がかかりすぎるので、ここでは個人的に刺さったパンチラインと、それに対する内省を書きます。今回書けなかったところは追って別のnoteとして投稿しようと思います。

プロダクトマネジメントを再現可能なベストプラクティスの適用にすぎないとみくびってしまえば、厄介で予測不能で絶対に回避できない人間の複雑さを洗い流してしまうことになります。（中略）どんな状況でも使えるベストプラクティスによる成功にとっては、ベストプラクティスに従わない物事や人はすべて敵に見えるようになります。

7章 「ベストプラクティス」のワーストなところ より

プロダクトマネジメントに限らず、ビジネスの現場には様々なフレームワークが溢れかえっているし、本屋に行ってもAmazon書籍ランキングを見ても「この仕組みに当てはめればなんとかなる」ような顔をした情報が世の中には溢れかえっているな、と感じています。

ただし、あくまでもそれは「過去のある時点で特定の組織、メンバ、条件でうまく行ったことがある」モデルケースです。当然のことながら自分たちの組織にそのまま適用してもうまくいく保証はありません。
（OKRを採用したら全ての会社がGoogleのような成長をするわけではないようにね、みたいな文章を書こうとしてやめましたが、そんな一歩引いてみたら当たり前なことですら、当事者であると自分が見たいもの以外ブラックアウトしてしまう状況ってあるよなと思います）

そのようなフレームワークに対して、本書では「有用なフィクションである」という立場をとっています。

私がいいなと思ったのは、「有用な」の部分です。世の中に流通する多くのフレームワークは全くの作り話であり、再現性のない無価値なものだと考えるのではなくて「フィクションだと捉えた上で自分たちにはどう活用することができるだろうか？」と内省することで、本当の意味でも「賢者は歴史に学ぶ」を体現できるのかなと思います。

継続的な改善の旅に乗り出すと、アジャイルソフトウェア開発の変えてはいけない正統性のようなものを変えつつあることに気づくでしょう。それで全く問題ありません。（中略）ユーザーは現実世界で生きるための行動指針に則っているだけであって、私たちがどれだけアジャイル方法論のルールに従っているか、バックログがどれだけ手入れされているかは知らないし、気にもしません。私たちの働き方がユーザーに届けるアウトカムを改善しないのであれば、その働き方に従うべきではありません。

8章 アジャイルについての素晴らしくも残念な真実 より

まず最初に補足しておくと、私自身はアジャイル嫌いでは決してありません。しかし、これまでの経験に照らし合わせてみても、誤解を恐れずにいえばアジャイルのコンテキストを「遵守する」ことに過剰に熱狂してしまう現場はまま存在しているのではないかと感じています。また、私自身にもそういう時期はあったような気もします。これは、アジャイルの考え方に魅了され、現場を顧みずに理想だけを求めてしまう「シャイニーオブジェクト症候群」のような状態に陥っているのかなと個人的には解釈しています。

とはいえ、教科書通りのアジャイルやスクラムができていないからといって現実は最悪だと嘆いていても状況が好転するわけではないので、「チームやプロダクトの現実にベストを尽くすこと」が根本的な行動指針であるべきだと感じました。

そして私の現実へ

本書の中にはADPRという役割が紹介されています。これは"Ambiguously Descriptive Product Roles"の略であり「プロダクト関連の曖昧に記述された役割」のことだそうです。「どの会社／チーム／プロダクトの仕事も少しずつ違うため、業務内容に明確な境界線を引くことよりも、周辺のADPRたちと協力してベストを尽くせ」という趣旨の記述がありますが、私にとってこれは希望の文章でした。

冒頭でも書いた通り、私は現在「スクラムの開発チームリーダー」という立場にいて、自分でプレイングするよりはシステムの設計を考えたり、（かなり）積極的にコードレビューをしたり、他チームとのコミュニケーションやチームビルディングなどに多くの時間をコミットしています。先週はステークホルダー側含めた会議体の見直し提案や、プロダクトバックログを再構築するためのテンプレート作成などもしていました。
これは自分がそう望んだからというより、チームの状況やこれまでの経緯を踏まえてそうなったという面が大きいです。一方で、スクラムガイドにも「スクラムチーム内 には、サブチームや階層は存在しない」とあるように、開発チームの自己組織化を阻害してしまう要因にもなるので、本来的にはそんな肩書は存在しない方が良いとすらと思います。

ですが、現実は現実です。
現職の批判をしたいわけでは全くないのですが、明日「私は今日限りでリーダー辞めま〜〜〜す！！」と宣言したところで、事態はきっと良い方向には向かわないでしょう。

だけど、本書を読んだからこそ、理想と現実のギャップは認識しつつ、今やるべきこと／やれることにベストを尽くそうと思えました。

あと、もしもフレームワークがフィクションだとしても、「その物語内のジョブで使える呪文の知見がないとロールプレイングゲームを楽しみきることはできないかな」と思ったので、本を提供くださったアトラクタさんのスクラムマスター研修を受けてみることにしました。今から楽しみ！

さて、ここまで書き殴ってきたけれど、今日は日曜日なので美味しいお酒を飲んできます。皆さんも良い週末を。明日からまた頑張ろう。

関係ないけれど

カバー画像は、お気に入りのフジマル醸造所さんのオレンジワインです。ワインに合う料理が美味しいのはもちろんのこと、ワイナリー併設で視覚的にも楽しいです。note文化を不勉強なので方向性間違ってたら教えてください。とはいえ、一覧ビューで見た時に楽しい気分になれそうなので、多分次回もごはんの写真を使うと思います。

この記事が参加している募集

仕事について話そう

108,489件

この記事が気に入ったらサポートをしてみませんか？