読者です 読者をやめる 読者になる 読者になる

プロダクトオーナー祭り2015に参加して、プロダクトバックログについての話をしてきました

プロダクトオーナー祭り2015 ~世界を変えるのは俺たちだ!~スピーカーとして参加させて頂きました。楽しかった!!

自分が発表してみての話と、他の方のセッションに参加してみての話を両方書かれて頂きます。

自分が発表した話

発表資料

www.slideshare.net

発表のポイント

以下のような内容が主に伝えたかったことです。

  • バッドノウハウの共有
  • 課題との試行錯誤の様子を伝える
  • 仮に内容が間違っていたとしてもTry大事

失敗の内容もその改善策も、企業やチームによって色々かとは思いますが、(そして自分も、もちろん正解に辿りついているわけではないですが、)同じようなことをしている方々に、何かしらヒントみたいなものになれば良いなという気持ちでした。

発表後に思ったこと

正直、若干後悔するぐらいプレッシャーを感じていたのですが、やった後はやってよかったと思うものですね。理由として、

  • 自分の話にこんなに人が来てくれるのだという感動
  • 「この内容あるある」みたいな共感が得られると嬉しい
  • 「このやり方良いかも」とか言われると、報われた感が半端ない
  • 発表後に色々な人に話しかけてもらえる(懇親会でぼっちにならなかった)
  • 自分のやってることの整理になって、さらに色々考えられるようになる

などがあります。

ちなみに、大きなA会場と、A会場と比較して小さめのB〜D会場で、発表が行われたのですが(私はB会場)、アンケートによると、B〜D会場で行われたセッションの中での投票数 第2位 ということでした。本当に感謝感激でした。田舎の両親に報告します。

他の方のセッションに参加した話

比較的自分は最初の方の発表だったので、発表後は主にワークショップに参加して楽しませて頂きました。その内容についても簡単にですが、触れさせて頂きます。

「プロダクトオーナー/プロダクトオーナーシップ」カイワヤ会(出張版)

カイワヤとは

「会話」+「わや」という造語だそうです。「わや」というのは鎌倉ハムのKウインナーで(私の出身)愛知県ではおなじみの、「駄目になる」みたいな意味の方言です。方言は知っているのに、会の意味がよく分からなかったのですが(笑)、たくさん(≒めちゃくちゃになるぐらい)話す会みたいな意味かなと想像しました。

内容

プロダクトマネジメントマニフェスト

こちらで扱ったのは、プロダクトマネジメントマニフェスト です。

ここに書かれた内容について、他の参加者の方と、「ここが素晴らしい」とか「これは難しいのでは」「自分はここまではできてるけど、これはできてない」みたいなことを、共有&ディスカッションしました。

プロダクトマネージャに必要なのは「覚悟」

  • 基本的に権限はない
  • 製品に対するすべての責任を持っている
  • 最も困難な仕事をしている
  • すべての分野の専門家でなければならない

(そんなの現実的に無理でしょ、という意見もたくさん出つつ)。そんなプロダクトマネージャに必要なのは 覚悟 ではないか、という話をしていました。

別の機会で、実際にプロダクトマネージャをされている方と、 優れたプロダクトマネージャには、いわゆる「人間力」みたいなものが大事ですね というお話をさせて頂いたこととも通じるところがあるな、というのが自分の所感でした。

自分はまだまだ遠い・・・

『メトリクスによる「見える化」のススメ:No 見える化, No 改善』

課題解決のために、課題を「見える化」するためのメトリクスを考えて設定する、という内容のワークショップでした。内容だけでなく、ワークショップの進め方も大変勉強になる会でした。

ワークショップを通じて思ったことをざっくりまとめます。

メトリクスについて

  • 「数値化」できて「問題の状況が分かる」項目の設定って結構難しい
    • 例えば「バグ数」って数値化はできるけど、問題の状況が分かるか。多くなったら良い?少なくなったら良い?
  • 「問題の状況が分かる」ためには、解決したい問題が明確になった方が良さそう
    • 「優先順位が頻繁に変わる」が問題?「優先順位が変わるからスプリントが達成できない」が問題?「関係者が不満を持つ」が問題?
  • 感情とか数値かできなそうなものも、挑戦してみると楽しそう
    • 「朝来たときの気分」とか「夕方帰るときの気分」とか「ありがとうの数」とか
  • 「開発者が喜ぶメトリクスか」「マネージャが喜ぶメトリクスか」の両面を考えるのはとても良い視点
    • 片方だけに都合が良いメトリクスは、何か違っている部分があるのではないか、というヒントになりそう

ワークショップの進め方について

  • チーム名を決めるのは良い
    • 連帯感が高まる。名前付けるの個人的にはとても苦手ですが
  • 途中で一度発表して、他チームからフィードバックをもらえるのが良い
    • 自分たちだけでは気付きにくいことを言ってもらえる
    • チーム内でたくさんの人が発表できて、良い経験になる
  • 複数のチームの進行状況によって、変化できる柔軟なシナリオ
    • 純粋に勉強になりました

反省

最後にちょっとした余談ですが、反省として、 名刺を持っていかなければ駄目 でした。。。

これまでエンジニア界隈の勉強会で名刺交換をした記憶なんてほとんどないのですが、今回は大変多くの方から名刺を頂きまして、普段念のため持っている名刺が一瞬で無くなった私は、ひたすらに頂くだけになってしまいました。。。

関係各位のみなさま、大変失礼致しました m(__)m

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方