ykmc09 blog

Profile: https://ykmc09.works

プロダクトマネージャーがプロダクト企画についてエンジニアと話すときに、あらかじめ書いておくとよいリスト(ラフな PRD テンプレのようなもの)

以前「プロダクト企画にエンジニアを早めに巻き込む(嫌がられずに協力を得る方法)」という記事を書きました。

ykmc09.hateblo.jp

「TL;DR : ひとことでいうと」を抜粋すると以下のような感じです。

  • 決定事項になる前に早めに巻き込もう
  • 巻き込むときは、
    • その意図や相手に期待することを伝えよう
    • 特性を理解して、ちょっとした工夫(最初の一声はチャットなどの非同期コミュニケーションを使う、etc)をしよう

この記事では、「はやめに巻き込もう」ということを中心に書きましたが、最低限こういったことを考えて書いておくと、話がよりスムーズになるよ、というものを挙げてみようと思います。

続きを読む

リモートミーティングに臨むときに意識しておくと良いこと(まだ慣れていない人向け)

緊急事態宣言も出され、多くの人がリモートで仕事をするようになったと思います。 特に、これまでリモート中心で何かをすることを前提にしていなかった組織で、急にリモート中心で仕事をすることになったケースもあると思います。

ここでは、私が(特に大勢での)リモートビデオミーティング(以下、リモートミーティング)に臨むときに意識的していることを記そうと思います。

リモートミーティングの具体的なチップスは、Web 上に数多くあると思いますが、 自分でチップスを考える上でも、これを念頭に置いておくと新しいアイディアを考える際のヒントになるかもと思います。

「オフラインの対面ミーティングと、リモートミーティングは別物」

私がリモートミーティングに臨むときには意識的に考えていることは、「オフラインの対面ミーティングと、リモートミーティングは別物と考える」ということです。つまり、「オフラインでやっていた対面ミーティングを、リモートツールを使ってやるだけ」と考えないということです*1。 こういった考えをしないでリモートミーティングに臨むと、いつものオフラインの対面ミーティングではうまくできていたことができず、フラストレーションを抱えることになります。こんなご時世、ストレスは少しでも少ないほうがいいですよね。

リモートミーティングとオフラインの対面ミーティングの違い

やってみるとすぐに感じることと思いますが、リモートミーティングでは、(特にマイナス面として)以下のような違いがおこります。

*1:思考実験的に「オフラインでやっていた〇〇をオンラインでやるには?」と考えるのは良いことだと思います。

続きを読む

2019年の記録

振り返りというほどでもなく、2019年をログに残しておきます。

2018年の記録はこちらです。

仕事

いまの会社に入って2年目の年でした。

年初は、メインのアジャイルコーチングの仕事の傍、何件か社内プロジェクトの立ち上げや、社内プロダクトのプロダクト設計などに一時的に関わっていました。 限られた時間でしたが、久しぶりにプロダクトチームの一員として働く感覚はとても楽しかった記憶があります。

並行して年初にアジャイルコーチングの組織を正式にチーム化し、夏頃にはプロジェクトマネジメントの組織と統合した組織を作ったりと、そういった形になれるほどにはやってきたことに対して社内での認知を一定得られたのかなと思う年でした。 同時にプレイヤーとマネージャーの両立に苦しんだ(でいる)年でもありました。

この組織での仕事については LINE DevDay 2019 でお話しし、ログミーでの書き起こしもしていただいたのでご興味ある方はぜひ。(お仲間募集中・・・!)

logmi.jp logmi.jp

また、社内でスポットで支援したワークショップも記事化していただいたりもしたので、こちらもご興味あれば。楽しい仕事でした。

line-hr.jp

仕事(副業)

続きを読む

プロダクト企画にエンジニアを早めに巻き込む(嫌がられずに協力を得る方法)

TL;DR : ひとことでいうと

  • 決定事項になる前に早めに巻き込もう
  • 巻き込むときは、
    • その意図や相手に期待することを伝えよう
    • 特性を理解して、ちょっとした工夫(最初の一声はチャットなどの非同期コミュニケーションを使う、etc)をしよう

たまに遭遇するシーン

ソフトウェアプロダクトの企画(プロダクトデザイン、プロダクト設計)を行う人や組織が、 企画の要件や仕様をかっちりと固めてから、エンジニアに渡したほうがいい 、と思っているシーンを見聞きすることがあります。

「重厚なウォーターフォールプロセスを採用しているから」という場合もあると思いますが、 軽量なプロセス下にある Web サービス企業でも、企画と開発で役割分担をしている場合は(程度の大小はあれど)起こってしまう と思っていて、今回はそういったケースを想定しています。

特に、以下のような思いがあるからそうしている、というケースを話題に上げたいと思っています。

  1. エンジニアに企画を説明すると、 多くの指摘(マサカリ)が入ることが多いので、なるべくちゃん作り込みたい
  2. エンジニアを 邪魔してはいけないという考えがある (または、嫌がられる)

ちなみに私は、エンジニア→プロダクトオーナーを経て、今は社内で横断的にチームの何がしかを支援する仕事をしています。エンジニアとプロダクトオーナー(≒ 企画職)両方を経験したので、ある程度どちらの立場もわかるなぁという気持ちです。

こういったケースで起こること

続きを読む