はてなブックマーク

どうもこんにちは。プロダクトからPMの強烈なエゴを感じるのが大好きな私です。 さて、今年の始めからVoicyパーソナリティとして「プロダクトマネジメントゆる反省会」というチャンネルで配信をしていたのですが、最近Voicyをやめる意思決定をしました。 Voicyそろそろ更新しようと思っていたのですがやめました。 もともと私のチャンネルは2倍速で聴くことを推奨していました。それが実質的にできなくなるのであれば私は聴いてくださる方への申し訳なさから別の手段について考えざるを得ません。 そのため当面は開店休業が続きます。 — Aki @『Noを伝える技術』著者 (@LoveIdahoBurger) October 9, 2025 私がなぜやめるのかをプロダクトマネジメントの文脈で解説したものをここに書きます。結構ちゃんと理由を書いている自信があるので特に関係者の方に読んでいただきたい気持ちはありま

これはデータドリブンな意思決定を否定するものではありません。ただ「データドリブンな意思決定」というHowに飛びつくことの危険性を伝えるものです。 データに基づかない意思決定は悪かソフトウェアプロダクトの大きな特長の一つは、様々な形式でデータを容易に収集できる点にあるといえます。ユーザーの属性や嗜好、行動履歴など、多岐にわたる情報が蓄積されています。このような利点を活用し、データに基づいて意思決定することが重要なのはもはや言うまでもないでしょう。データによって客観的な根拠が得られ、施策の効果を正しく評価・改善できるからです。 しかし、データはいつでも十分に揃っているとは限りません。そのため、私はデータに基づかない意思決定が必ずしも悪ではない、むしろデータに基づかないほうがいいケースすらあると考えています。たとえば新規事業や新しいプロダクトの立ち上げなど、まだ実績がない状況では必要なデータを用

※(注記)本記事での「大企業」とは、主に非IT系の、ソフトウェアプロダクトやその開発能力を売り物としない業種の大企業を指します。disる意図はなく、大企業の課題や伸びしろを理解した上で成長を強く願う立場からの提言です。 近年、スタートアップ発のSaaSで優れたものが増えています。「いずれSaaSの役割もAIに取って代わられるのでは?」という意見もありますが、現時点ではAIが完全に業務の意思決定を含めたプロセスを丸ごと代替できるフェーズには至っていません。むしろ最近のSaaSはAIが組み込まれる形で進化しており、そして企業はそのSaaSを活用して業務を最適化する流れが加速しているように感じます。つまりSaaS全盛期、あるいはSaaSスタートアップ全盛期は、まだAIの力を借りる形でしばらく続くと私は予想しています。 ところで、これらのSaaSスタートアップは最初のターゲットを中小企業にすることが多く、

はじめにこの文章は、技術書典にあわせて出版された「PMの日常」にゲストコラムとして寄稿したものです。そのまま公開する許可をいただきましたので公開します。 「PMの日常」は私のゲストコラム以外のコンテンツも素晴らしいのでぜひどうぞ。 PMと事業プロダクトを開発するからには、そのプロダクトが何らかの形で事業に貢献する必要があります。多くの人は、事業への貢献と聞くと「売上増かコスト減を実現すればいいんですね」と言います。これは間違いではないのですが、少し補足したいことがあります。 真に求められているのは、所属組織のビジョン達成のために事業を牽引することなのではないかと私は考えています。達成のために動けば結果的に売上やコストに効くということも多いとは思いますが、事業を牽引することを考えると、実は目先の売上を捨ててでもまずはビジョンを具現化することが重要であるというシーンもあり得ます。そういったトレ

以前勤めていたことのある会社が毎年数回大規模なセールをやっています。一度この大事な時期にオンラインストアの障害を起こしたことがあって、心に深い傷が今も残っていますがそろそろ時効だと思うので傷をさらけ出します。 障害の原因まず、障害の原因はどんな角度から見ても私であり、そこは深く反省しています。 回避は難しかったと思いますが、後から振り返った時に回避のためのごくわずかなチャンスが2度ありました。 実はそれでも回避できなかったかもしれなくて、もしかしたらただ発生時刻を遅らせるだけであって障害は発生していたかもしれません。誰がやっても回避のチャンスを掴むのは難しかったと思いますし、それを掴んだからといって必ずしも回避はできなかったと思いますが、いずれにしても、それを逃したのは私です。 この障害は夕方のニュースにもなりました。1秒たりとも残業をしたくない主義の私が、障害解消後も含めセール期間中は終

※(注記)この記事は、私の起業記念note二部作のうちの第一部(ポエムの部)です。第二部では事業にかける思いを真面目に綴る予定です。 起業します。突然ですが、この度キャディ株式会社を退職し、起業することになりました。 提供するのは、企業向けのDX推進サービスです。 私は10年以上にわたるプロダクトマネージャーとしてのキャリアを一旦ここで終えます。 もちろんプロダクト開発のバックグラウンドは私の強みですし、今後も時にプロダクト開発をすることもあると思います。ただ、「プロダクト開発」ではなく「DX推進サービス」と言っているのには理由があります。 私は企業のDXを長年にわたり間近で見てきて、DXを減速させる問題のひとつが作りすぎ(オーバーエンジニアリング)であると感じました。 私達は開発の能力を有します。しかし、時に「作らない」という決断をすることも重要です。私達は、作るものを最小限にしながら、本当に意

これは私が普段いかに労働から逃げているかを示すものです。 前提となる考え方私は働きたくない。実際には仕事にやりがいを見出すこともあるので必ずしも働きたくないわけではないが、基本的には常に働きたくないと言っている。 ことプロダクト開発になるとこの傾向は顕著で、「何も作りたくない」「何も作らずにお金を稼ぎたい」などとよく言っている。プロダクトは作った瞬間に負債になる。世の中は絶えず変化・進化していくので、作った瞬間から陳腐化が始まる。それを防ぐために継続的なメンテナンスや改善が求められる。 通常、その負債が問題視されないのは、そのプロダクトが負債以上に大きな果実つまり価値をもたらすからである。アジャイルの名のもとに incremental delivery などと言うと聞こえはいいが、要するに負債より多くの価値を生み出すための自転車操業をかっこよく言っただけである。少しトゲのある表現になったが

何となくこれを書くべき時がきた気がするので書きます。 プロダクトマネージャーの仕事プロダクトマネージャーの仕事はプロダクトマネジメントです。プロダクトマネジメントをしてほしいという期待があるからその人にプロダクトマネージャーというタイトルをつけているはずなので。 プロダクトマネージャーは誰でも好きなように名乗ったらいいと思うの、国家資格とかも必要ないし。 ただ名乗るからにはプロダクトマネジメントちゃんとしていこうな! — Aki (@LoveIdahoBurger) April 19, 2024 実際には組織構造によってはプロダクトマネジメントをしないプロダクトマネージャーがいるかもしれませんが、その場合も間接的にプロダクトマネジメントをしているはずです。いずれにしてもそれは例外的なので今回は一旦置いておきます。 プロダクトマネージャーはプロダクトマネジメント以外もやらなければならないと思

4年前、入社2日後に「入る会社間違えた!」と思い入社半年後から転職活動を開始した挙げ句に、その後「いつの間にか会社に惹かれていた私...」という少女マンガもびっくりな心情の変化に気づき全てのオファーを断り続けること3年以上。ついに転職することになりました。 どこへ?退職の話をしてからずっと次はどこなんだという話が出ていましたが、9月1日よりキャディ株式会社で働いております。最初にコンタクトしていただいたのがもう1年以上前で、その時は「いやいや全く転職なんて考えてないよ」と思っていたのですが、人生何が起こるかわからないものです。 ちなみにきっかけはTwitterでした。少しのやりとりの後、たけろーさんとマクドナルドのお店で初めて会って(言い出しっぺの柿澤さんがまさかの不参加)、気がついたら笹口さんとのカジュアル面談がセットされていて、その後も寿司につられてオフィスにお邪魔したりなどしていて、そん

2020年初頭、開発チームとアジャイルコーチと話し合ってレトロスペクティブのフォーマットを変更しました。約1年運用して、フォーマットを変更してよかったと感じているので、どのように変更したのかを紹介します。 解決したかった課題それまでレトロスペクティブにはKPTを使っていました。KPTはフォーマットとして優れており、振り返るべきものがこの3つできちんと網羅されており、且つTの部分で次にどう活かすかを語ることができます。 一方で、KPTでのレトロスペクティブをしていて感じたのは、私のチームにおいては参加者がフォーマットにとらわれすぎて例えばKeepならKeepするべきだと感じたことを各自が淡々と発表するだけという形式になっていたという課題です。それも、各項目1人1意見のノルマをこなしているといった様子で。 出てくる意見はそれぞれ貴重ではあるものの、もっとたくさん思っていることがあるのではないか

退職します。 いわゆる退職エントリを書くと多分私はいろいろなことを思い出してしまって、いい思い出で終わらせたいはずなのにいつの間にか怨念のこもった文章を書いてしまいそうなので、ちょっと違うことを書きます。退職するにあたって私の後ろ髪を引きまくった男についてです。 私の上司(テクノロジー担当VP)のA氏です。 A氏なる人 相当やられていたので上司にSOSを出したところ、会議キャンセルのお知らせが来た。そしてその時間に1:1セットしてくれた。惚れる。そして1:1なのに私が別メンバー呼んで結局4人になってるのカオス。 — Aki (@AkiDebukatsu) December 8, 2021 思えばこの会社では非常に優秀な人に恵まれましたが、残念ながら私と合わない人に苦しめられたこともありました。合わない人のうちの1人が、A氏の前任者でした。なので正直、同じポジションにおさまるA氏にも私はあま

最近読んだ「プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける」という本から、ビルドトラップに思い当たる節があったので少し当時のことを思い出してみました。 ビルドトラップとは、機能を作ることばかりに集中してしまう状態のことで、本書の冒頭ではこのように説明されています。 ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。私が人生で一番ビルドトラップの深いところにはまっていたのは、2社目に転職したばかりの頃でした。そしてその時の記憶を紐解くと、設定されていたKPIのせいでビルドトラップから逃れられなくなっていたのだと気づきました。 悪いKPIの王道私の当時の担当プロダクトは、当時所属していた会社の公式アプリでした。私が入社した2013年の時点で、数百万のダウンロードがありました。 モバイルアプリの典型的な悪いKPIの代