自分が発表した話

発表資料

プロダクトバックログビフォーアフター from bonbon0605

www.slideshare.net

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

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

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

などがあります。

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

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

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

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

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

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

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

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

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

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

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