はてなブックマーク

タイトルから中身を想像した皆さん、違うんですよ。私はそういう話がしたいわけじゃありません。 AIによって人が減ること自体は起きるでしょうし、既に起きている組織もあります。調べる、まとめる、書く、作る、検証する、問い合わせる、壁打ちする。これまで人間が担っていた仕事のかなりの部分を、AIが代替し始めています。 ただ、私は「人が減るかどうか」の問題にはあまり興味がありませんし、それに付随する「AI時代のジュニアメンバー育成論」みたいな話もまぁ興味はありつつも喫緊の課題ではないと思っています。なぜなら、個人的にはもっとやばい問題をAIは組織に持ち込むと思っているからです。 私が組織論として考えたいのは、人間の代わりにAIが入ってくることではなく、AIという永遠に反論しないメンバーが組織の中に大量に入り込むことです。 AIは、指示すれば動くし文句を言わないし空気を読むし否定しないしこちらの意図を最

「生成AIが書いた文章は薄い」と思っている人は多いのではないでしょうか。私も大半のAI生成文章は薄いと思いますし、そもそも生成AI臭が漂って読む気をなくします。生成AIと生身の人間、どちらの文章を読みたいかと問われたら、よほど文章が下手な人の文章でない限りは私は生身の人間が書いたほうを読みたいものです。 ただ、「薄い」という点に関して言えば原因はAIではありません。AIに情報を渡していない人間が悪いと思います。自分の文体も、読者像も、判断基準も考え方も伝えず「いい感じに書いて」と頼んだら、出てくるものは当たり前に薄くなります。 最近、私は生成AIによる執筆環境を整え直しました。それにより記事を書くスピードは体感で3倍になり、品質は落ちていません。3倍と言っているのは、大体これまで3000字の記事を書き上げるのに要したのと同じぐらいの時間をかけると9000字の記事を書けるようになった、という

最近、データサイエンス経験歓迎のプロダクトマネージャー求人が増えているそうです。世の中的にはプロダクトマネージャーはもっとデータを活用するべきという流れなのでしょう。 しかし私の周囲では逆の流れ、つまりプロダクトマネージャーからデータエンジニアへのジョブチェンジを複数観測しており、そんなことをつぶやいたら思ったより多くの方に見ていただけました。 私の周りではむしろ、PMがあまりのデータの整ってなさにキレてデータエンジニアに転身する例を見る。何をもとに意思決定するかの勘所があるから非常にいい感じに整えてくれて助かる。 https://t.co/DXwPutgUE6 — Aki @『Noを伝える技術』著者 (@LoveIdahoBurger) November 4, 2025 私自身は相変わらずプロダクトマネージャーをやっているのですが、今回はプロダクトマネージャーからデータエンジニア（または

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

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

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

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

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

タイトルに全てが凝縮されています。 別の投稿でも少し触れたのですが、当社は絶賛Agile化中。但し経験者は少ない。ということで、数少ないAgile経験者である上司が始めたのが、部のDaily Standupです。 これまで3ヶ月、長いものに巻かれる主義で黙って参加してきたDaily Standupですが、そろそろ物申そうかなと思っています。 苦痛なポイントまず、15分で終わらない。この一点で私の苦痛の90%以上が説明できるのですが、30分ぐらいかかるのです。立ちっぱなし。辛い。 15分で終わらない理由は当然、 ・話が長いから ・議論が始まるから というありがちな2つ。 そして、いつの間にか予定シェアの会になっている。Yesterday/Today/Blockerのフォーマットに沿ってやっているのはよいのですが、YesterdayとTodayのところで予定表の内容を全部読み上げるのはやめたい

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