mikaji

テクニカルプロダクトマネージャー /🧑‍💻📷☕️ ※ 投稿はわたし個人のものであり、所属組織…

mikaji

テクニカルプロダクトマネージャー /🧑‍💻📷☕️ ※ 投稿はわたし個人のものであり、所属組織の立場、戦略、意見を表すものではありません

  • PM Insights

    怠惰で短気で傲慢なプロダクトマネジメントに関する記事をまとめています。

ソフトウェアエンジニアからプロダクトマネージャーへのキャリアチェンジを考えてみよう

私はソフトウェアエンジニアとしてキャリアをスタートし、7~8年ずっとコードを書いてきました。そんな中、なぜプロダクトマネージャーにキャリアチェンジしたのか、キャリアチェンジするにあたってどんな登り方が良いかを考えてみます。 ソフトウェアエンジニアからプロダクトマネージャーになれるのか結論、なれます。プロダクトマネージャーをやっている人のバックグラウンドはさまざまで、セールスやUI/UXデザイナー、ソフトウェアエンジニア（フロントエンド、バックエンド）など多種多様です。 私の

mikaji

    • ユーザーやビジネスの要望を汲み取る要求整理をやめよう

      ユーザーからのレビューやビジネス要望で営業からプロダクト改善が上がってくると、すぐその要求通り開発を進めていませんか？そのムーブばかりしているとプロダクトは終わります。 ここで大切なのは、 要望ではなく課題にフォーカスすること 要望を鵜呑みにしないこと プロダクトとしての方向性とビジョンを守ること です。あなたがPMなら、もしプロダクトの要望が出てきたときはあくまで一意見として、そして鵜呑みにせずどこに課題があるのかを考えることが重要です。その上で、プロダクトにとっ

      mikaji

      • まずはたたきを作って目線合わせをしよう

        よく、たたきを作るのが大事などと言いますが、なんで大事なんだっけ、ということを考えました。 たたきとはたとえば、新しい施策のために機能開発するとき、企画者はこのような機能が欲しいといったイメージが頭にある（orない）場合、それをメンバーに共有してもらう必要があります。 そこで必要になるのが、「たたき」です。 たたきのアウトプットイメージはケースバイケースで、テキスト箇条書きのページ1枚のときもあれば、ラフイメージを起こす場合もあります。たたきがあるだけで、イメージをチーム

        mikaji

        • メンタルを守るステークホルダーマネジメントをしよう

          ステークホルダーに翻弄されて疲れる自分にさよならバイバイ はじめにステークホルダーとのコミュニケーションなどマネジメントをしているとどんどん疲弊しませんか？PMをやっていると、その責任の重圧から頑張りすぎたり、ステークホルダーによく見せようとつい張り切って疲れることも多々あると思います。この記事では、メンタルヘルスを守るためのステークホルダーマネジメントの重要性とその方法について説明します。 ステークホルダーマネジメントとはメンタルヘルスとステークホルダーの関係ステークホ

          mikaji

        ソフトウェアエンジニアからプロダクトマネージャーへのキャリアチェンジを考えてみよう

        mikaji

        マガジン

        • PM Insights
          9本

        記事

          他人の人生を生きるのやめよう

          人のために生きなさい、良いマインドです。 でもその人は他人だとすると、多すぎます。人生全て使っても足りないです。 そこで他人のスコープ調整が必要。簡単で、家族と大切な友人のためだけで良いと思います。愛を持って接する相手だからです。 逆に言うと、会社の同僚や大した関わりのない知人程度であれば、搾取されず、コミットしないことにより自分を守った方が良いです。 自分を守り、大事な人を守りましょう。

          mikaji

          他人の人生を生きるのやめよう

          mikaji

          仕様書とPRDと要件定義書とDesign Docの違いを整理しよう

          はじめに 以下の記事を読んでいて、わかるわかる〜となりつつ、仕様書とPRDと要件定義書とDesign Docの違いってちゃんと言語化して整理しておいた方が良いよねってことで整理していきます。まずはperplexityにそれぞれ聞いてみます。 仕様書システムが備えるべき機能や性能などを記載した文書 「何を作るのか」を文や図で表現 要件定義で定められたものを満たし、プロジェクトを進行する要となる ここでいう仕様とは、システムに関する機能を指すものになります。よくシーケンス

          mikaji

          仕様書とPRDと要件定義書とDesign Docの違いを整理しよう

          mikaji

          尖ったスキルが実は小さい尖りかもしれないので気をつけよう

          キャリア形成の話になると、まずは尖ったスキルを持つのが大事という話をよく聞きます。私も同感で、自分は〇〇が得意です、というものが最低ひとつはないとこの人はどんな価値を生み出すんだろうというのがわかりにくいです。 尖ったスキルが他者と比較しても突出したものになると、希少性が上がり価値があると評価されます。 一方、努力して身につけて尖ったスキルが、実は相対的に他者と比較すると小さい尖りでしょぼいこともあります。図にするとこんな感じ。 これを私はスキルの当たり前品質と考えてい

          mikaji

          尖ったスキルが実は小さい尖りかもしれないので気をつけよう

          mikaji

          エンジニア出身のプロダクトマネージャーが気をつけるべきことを考えよう

          専門性でバリューを発揮しすぎない見出し画像Adobe Express のテンプレ使ったらそれっぽくなりましたね😉 今回は、エンジニアからプロダクトマネージャーにジョブチェンジするケースはまあまあありますが（自分もそう）、プロダクト・チームのためにならないムーブもいくつかあるので紹介します。心構え的なものなのでポエムだと思って読んでください。 1. コードを読まない・深追いしないまずは、「コードを読まない・深追いしない」です。 プロダクトコードが読めるPMは、仕様の確認や問

          mikaji

          エンジニア出身のプロダクトマネージャーが気をつけるべきことを考えよう

          mikaji

          社内の水平分業をやめよう

          社内で受託開発組織にならないためのプロダクトマネジメント先日、一休CTOの伊藤さんの記事が公開されて読んだのですが、『エンジニアとビジネスが受発注の関係にならないように』のパートがわかるわかるとうなずきまくる内容だったので、社内で受託開発組織ならないためにはにどうすれば良いかをPM目線でちょっと深掘ってみます。 なんで社内で受託開発しちゃいけないの？まずは、受託開発はなんで良くないんだっけということを整理します。受託開発とは、依頼者から開発依頼を受けその要求に基づいて開発

          mikaji

          社内の水平分業をやめよう

          mikaji

          テクニカルプロダクトマネージャー(TPM)という職種と、TPMになるにはどうすれば良いか考えてみよう

          TPMは技術を軸にしたプロダクトマネジメントの専門家テクニカルプロダクトマネージャー（以下、TPM）という職種・ロールはご存知でしょうか？この記事では、TPMとは何か、TPMはなぜ生まれるのか、キャリアパスについて話せればと思います。 TPMとはTPMについて、まずはPerplexity に聞いてみましょう。 昨今、プロダクトマネジメントをするPMという職種はかなり知名度を上げ重要なポジションとなってきました。一方、組織のサイズやプロダクトのサイズによってPMも複数人存在

          mikaji

          テクニカルプロダクトマネージャー(TPM)という職種と、TPMになるにはどうすれば良いか考えてみよう

          mikaji

          自己紹介

          こんにちは mikajiです。「みかじ」と呼んでください。 テクニカルプロダクトマネージャー（TPM）という職種で働いてます。TPMとはなんぞや、 PMとは違うのか、と言った話はまたどこかでできればと思います。 noteでは、意識の低いプロダクトマネジメントTips、キラキラしないプロダクトマネジメントについて記事を書こうと思っています。 最後に、プロフィールにもありますが、投稿はわたし個人のものであり、所属組織の立場や戦略、意見を表すものではありません。仮に企業やプロダ

          mikaji

          自己紹介

          mikaji