yuzu.

転職をし、教育系サービスのPdMをしています！以前はエンジニアをしていました。 仕事の…

yuzu.

転職をし、教育系サービスのPdMをしています！以前はエンジニアをしていました。 仕事のことや日々のこと、自分の経験談をベースにnoteを書いています 。

  • PMとしての学びまとめ

    エンジニアからPMに転身して、仕事や日々の中での気づきや学びをまとめてます。読んでいただけると嬉しいです。

1年前エンジニアからPMになって役に立ったスキル、足りなかったスキル

この記事は プロダクトマネージャー Advent Calendar 2020 9日目の記事となります🎄 簡単に自己紹介2017年4月にDMM.comに新卒のエンジニアとして入社し、主にサーバサイド（PHP）を書きながらtoC向けサービスのフロントエンドやネイティブアプリのコードなども書いていました。 現在の会社に1年前に転職をし、エンジニアからPMに職種を変え、現在はスタディサプリ ENGLISHという語学学習アプリのPMをしています。 なぜこの記事を書こうかと思ったか

yuzu.

    • PMという職種において、エンジニアリングの知識が役立つ瞬間と勉強法について

      よくPMにエンジニアの知識は必要か、プログラミングはできなくてはいけないのかみたいな議論がありますが、元エンジニアとしては知識として知っておいて損はない、むしろエンジニアと同じ温度感で話せるという面においてはすごくいいことだと思ってます。 PMにエンジニアリングの知識は必要？不要？について予想通りかもしれませんが、あった方がいいよねが世の中の意見だと思っています。エビデンスとして2つ挙げたいと思います。 GoogleでPMをしていた及川卓也さんは下記記事でこのように述べて

      yuzu.

      • 【PM1年目の学び②】施策や機能改善の背景や経緯を伝えることの大切さ

        こんにちは！ PM1年目（社会人としては4年目）として、日々大事だな〜とか学んだな〜とかみたいなことを綴ってます。 前回の記事はこちら↓ ＊＊＊＊＊ 今回は、施策や機能改善の背景や経緯を伝えることの大切さについてです。 誰に伝えるのって部分なのですが、ビジネスサイドやカスタマーサポートの人も大事ですが特にデザイナーやエンジニアといった開発メンバーに対しては伝えすぎかもぐらいに伝えた方がいいと思います。 理由について述べていきたいと思います。 理由その1.なぜその

        yuzu.

        • 【PM1年目の学び①】会議にはアジェンダとゴールの用意、終着点を複数パターン想像セヨ

          タイトルそのままなのですが、PM1年目の自分が学んだことをきちんとアウトプットしていければと思って書いています！ アジェンダとゴールがない会議なんぞやる意味がないエンジニア時代は自分主催のMTGというものがそれほどなかったのですが、PdMになってからはかなり増えました。 ちょっと強気な見出しですが、アジェンダがないなら会議をする必要はないし、ゴールが決まってるならslackで共有するだけでいい、会議をやらなくてもいいのです。 だいたい下記のようなテンプレート（仮)を使っ

          yuzu.

        1年前エンジニアからPMになって役に立ったスキル、足りなかったスキル

        yuzu.

        • PMという職種において、エンジニアリングの知識が役立つ瞬間と勉強法について

          yuzu.

        • 【PM1年目の学び②】施策や機能改善の背景や経緯を伝えることの大切さ

          yuzu.

        • 【PM1年目の学び①】会議にはアジェンダとゴールの用意、終着点を複数パターン想像セヨ

          yuzu.

        マガジン

        • PMとしての学びまとめ
          5本

        記事

          エンジニアが副業を始める前に気をつけた方がいいなと、今思うこと

          現在DMMという会社で3年目のエンジニアをしています。 私は手伝いたいサービスがあったり、知人の紹介で2018年の6月頃から少しずつ副業を始めたのですが、最近周りで副業始めるにあたって気をつけた方がいいことを聞かれたり、相談を受けたりすることがあったので共有しておきたいと思います！ エンジニアがとタイトルには書いてありますが、他の職種の為にもなるのではと思って書いています。 やっておけばよかったこと・何のために副業するのかを考えよう ・開業届を出した方がいい時もある ・

          yuzu.

          エンジニアが副業を始める前に気をつけた方がいいなと、今思うこと

          yuzu.

          エンジニアになってから聞いて、必死にググったマーケ用語などをまとめみた

          そろそろ正社員としてのエンジニア業務歴も2年と3ヶ月ほどになりそうです。 最近は数字を見ての開発だとか、データ・ドリブン開発が主流になってきて、その度に現れるマーケ用語たち。会議で聞いては必死にググって覚えたり、恥を忍んで聞いてみたりしてます。 そんな用語をまとめたら便利かなと思ったのでまとめてみました！（意味や解釈が間違ってたら、コメントで教えてもらえるか、TwitterのDMとかで教えてもらえると嬉しいです！）マーケじゃない用語も含まれてるかも！ 1. KGI事業部

          yuzu.

          エンジニアになってから聞いて、必死にググったマーケ用語などをまとめみた

          yuzu.

          ビデオチャットを使って、リモートペア読書をしてみた話

          エンジニアの@yuzoohoです！ この前同い年でデザイナーのちゃんまみ(私はそう呼んでる)とビデオチャット越しにリモートでペア読書をしたので、それについてまとめたいなと思います！ まみちゃんは今愛知にいてリモートワークをしています▼ 私たちの出会い？はTwitterなのですが、医療系ベンチャーのお手伝いを少し一緒にしたのがきっかけです。 1. なんでペア読書しようと思ったの？私は実家が愛知県なので、当初帰省の時に会おう！となっていて、その時ペア読書する？みたいな話だ

          yuzu.

          ビデオチャットを使って、リモートペア読書をしてみた話

          yuzu.

          働いてみて痛感した、仕事におけるコミュニケーションで大事なこと

          社会人になってそろそろ1年4ヶ月目、学生時代にインターンをしていたこともあったのですが、大学生までは基本知り合った友達や先生とせいぜいコミュニケーションするかどうかの日々でした。 社会人になると、いきなり関わる人が増え、その人のこともよくわからず、一緒に仕事することになります。 私が配属されてから、仕事上でイラっとしたり、落ち込んだりするときって、自分が実装できないとかわからない以外だと、だいたい人とのやりとりに起因するなと気づいて、 気にしすぎる性格なので、こう直して

          yuzu.

          働いてみて痛感した、仕事におけるコミュニケーションで大事なこと

          yuzu.

          TwitterでおすすめされたUIの本を読んでみた感想

          なんでUI本を読みたいと思ったか本職はサーバサイドエンジニアなので、基本業務でUI周りを触ることは管理画面のbootstrapぐらいしかないのです（もはやUIなのか）。 今回副業をしていく上で、使いにくい部分を修正していこうという時に、なぜそのUIがダメなのか、ダサいのかきちんと自分の言葉で説明できないということがあって、参考になる本があれば読みたいな〜と思ったのがきっかけです！ 3冊教えてもらって、全て買って読みました！Twitterで聞いて見たら、親切な方がたくさんい

          yuzu.

          TwitterでおすすめされたUIの本を読んでみた感想

          yuzu.

          【ディレクター・エンジニア向け】新機能を作るときの要求定義書テンプレート

          こんにちは！yuzuです！ エンジニア2年目が早くも1ヶ月半過ぎようとしています。 今回は、私が新卒1年目の時に、依頼された機能を作る際に、確認が多くなったり、作ってから要件が漏れていて、実装を仕直さなければいけなくなったということがありました。 その際に要求定義をしっかりしていればと思い、作った要求定義書のテンプレートについて紹介したいと思います！ 目次 ・要求定義と要件定義の違い ・要求定義書のテンプレートの説明　 ・実際に書くとこんな感じになる要求定義書の例 要

          yuzu.

          【ディレクター・エンジニア向け】新機能を作るときの要求定義書テンプレート

          yuzu.

          作ったものをアウトプットするということ

          絵でもコードでも作品でも文章でも、アウトプットをしている人が好きです。 今、新卒2年目なのですが、1年目の時は、あまり外に出ようとしていなかったり、家や休日にあまり開発をしなかったという後悔があります。 今年はへぼくてもいいし、写経でもいいから、自分が何かしたことを発信していきたいです。 でも、臆病だし、不安だし、こんなコードで非難されたらどうしようとか、こんなクオリティで出していいものかと、出す前はいつもビクビクします。 まあでも出したら嬉しい反応が返ってきたりする

          yuzu.

          作ったものをアウトプットするということ

          yuzu.

          #技術書典4「こまるUIよくしてみた本」の製作裏話

          4/22（日）に秋葉原UDXというところで、技術書典が開催されました！ 技術書展3の時の入場者数の二倍以上の5880名が参加されたそうです！ 今回共著という形で、有名人なナユさんといしまるさんと「こまるUIよくしてみた」という本を書きました。 表紙は、ろくさんとshizoooさんペアで作っていただきました！ 書いてみることになった経緯、当日出典してみての感想を書きたいと思います。 初動はよかったけど、本ができたのはギリギリ今回実はナユさんのツイートで、私といしまるさ

          yuzu.

          #技術書典4「こまるUIよくしてみた本」の製作裏話

          yuzu.

          コードレビューの改善が始まったその先・・・

          今日こんなツイートをした。 レビューをしてもらえるのはありがたいけど、指摘の仕方によっては言われた方が困ってしまうこともある。（どう直すべきなのかわからない、何を指摘されているのかわからない。） ↑こんな意見もあった コードレビューを改善しようと始まったのは最近以前のチームでのコードレビューは、結構ゆるくて、 1人がコードレビューしたらだいたい終わり、 設計や要件まで把握してコードレビューはしていなかったり、 マージ後にバグが起こったり、 レビュー規則は（ほぼ）なく

          yuzu.

          コードレビューの改善が始まったその先・・・

          yuzu.