nozayasu

仕事全般/マネージメントで考えたこと

プロダクトオーナー祭りに参加してきた。

なんで参加したの?

僕は単なるプログラマーで、今現在明確にプロダクトオーナーとしての役割で仕事していません。
ましてやエンジニアチームでリーダーの役割すらしてません。本当に単なるプログラマーです。
がしかし、僕が所属する会社の人数規模(10名程度)では全員が多かれ少なかれ、
プロダクトオーナーの役割とされる分野に関与しながらサービスを作っていると感じています。

なのでやっぱり関わるなら理解をしてやりたいな!楽しくやりたいな!と思うようになりました。
現状はこの手の本を読んで、自分の解釈を同僚に話してみたりするくらいです。(良き同僚が多く、色んな影響をうけて幸せです) 知識を増やすことというのは不思議で、今まで関心がなかった分野(僕はマネジメントとかあんまり興味なかった)にとっかかりをつくると、どんどん欲求でてきます。もっと多方面の意見に触れたい。これが一番大きかった。

といったまぁよくあるモチベーションの元、マネジメント関連の外部イベントに参加してきたよって話です。

プロダクトオーナー祭りって?

こんなイベントでした。 postudy.doorkeeper.jp

togetterはこちら togetter.com

どうだった?

正直世界を変えるのは俺たちだ!とまではまだ思えませんが、内容良かったです。(月並みな感想!笑)
セッションについてでもうちょっと感じたことまとめます。

セッションについて(覚えてるとこだけ)

新カゴプロジェクトのプロダクトオーナーとしてやってきたこと

GMOペパボ株式会社 カラーミーショップ
10年続いているサービス運用上の話、すでに顧客を確保しているサービスで改善を進める時にこんな風にやった、やってるよ。
という話だったと理解しました。

登壇者様のスライド公開されたので引用

www.slideshare.net

このセッションで頭に残ったこと(僕の解釈の結果です、100%登壇者様の言葉ではないです。)

  • 優先順位を決める時、根拠となるデータがあると判断が早い
  • プロトタイプを早く触ってもらえるフローを整備する
  • 動画のように、実際動くものによる表現が一番伝わりやすい
  • 視覚からの情報が8割と言われてる
  • 哲学駆動開発wwwww(なぜ作るのかってのをまず詩で表した?ちょっと聞き逃した。深く内容聞きたい)
  • ユーザビリティテストで、実際の社内テスト時にユーザ操作を全て動画にとってチームで議論の種にした
  • 完了条件は明確であればあるほど判断しやすい
  • 誰に確認をとるか?を迷う状況はいいことない

僕はこう思ったです

プロトタイプとして早く共有する、動画での共有をするとか誰がみても共通の理解度持てるように工夫してるんだなと思った。
言葉やワイヤーフレームだけみても、共通理解とならないで各々頭の中で補完する内容が違うこと実感してる。
誰が見ても近しい理解度を得るために、想像や感覚で補完させてしまう部分を少なくする努力大事だ。
僕の会社にて不具合報告の方法として、GIFアニ入れて報告をやった場合にチームの理解度があがる効果あったし納得感ある。

GIFアニ作る時に使ってるやつ blog.scimpr.com

あとPivotal使ってるって話の時に、◯◯APIを作ります。みたいな粒度で登録してる風に受け取れた話があったけど、Pivotalは依存関係把握しにくいと思っていて、それだと何かがブロックしてるのかとか見えにくくないか?◯◯APIが必要なことわかるけどそれができると要件ベースでは何が完了となってるの?という疑問がわいた。というかそういう壁を僕のチームで感じたことがあった。

そこで僕のチームでは要求ベースでのストーリーをPivotalに登録して、受け入れ条件として細かな粒度のタスクをいれることを試してる。
依存関係のない単位で登録と、見積もりをする方がわかりやすいと感じてるので、ここを登壇者さんと話してみたかったけど質疑の時間なかったのが悲しかったー。

僕のチームのPivotal登録例
f:id:nozayasu:20151128224807p:plain

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

抱えている課題に対して、その要因の深堀と現状の分類・数値化をすることで定量的な変化を捉えられるようにする。
要因と思われることの変化を捉えられるように数値を設定すると、解決するためのアクションをイメージしやすくなるよね。
ということを実体験するワークショップだったと理解しました。

登壇者様のスライド公開されたので引用

www.slideshare.net

このワークショップで頭に残ったこと

  • 人の感覚は正解がそれぞれあることを理解する
  • 計画外追加作業が、質の改善要求?仕様の誤認?不具合?何要因による追加作業か正しく把握する
  • コミュニケーション時間量と消化ストーリーに相関関係はあるかという疑問

このセッションで頭に残ったこと(僕の解釈の結果です、100%登壇者様の言葉ではないです。)

  • 追うべき数値は自分で作ることもできる。新しいものは提案者の思想がアンカリングになって提案者主導になる
  • 数値変化を見れるようにするというのはコミュニケーションの促進剤

僕はこう思ったです

仕事への納得感の保ち方、進捗管理の効率化、見積もり精度の向上、チームメンバーの些細な悩みを上手く引き出す。
似たような課題を皆感じているんだなというのがわかるのは妙な安堵感がある。
同じ課題を持つ第三者だと、つっこんだ話も関係性とか無視して気軽にできるのよかった。

僕はチームの課題に対して、定量的にみるための機能を整備するコストを払うには、結構厳格なする理由を持たないといけないかなぁって考えてしまっていた。 なので勝手に敷居を高く感じて提案するのが億劫になってた部分がある。

単にチームのコミュニケーションの促進剤だよって意味の解釈をできると、役立つと思うからこれ把握できるようにしましょうよ!って提案への心持ちが軽くなっていい。

とはいえ業務効率やらなんやらの改善専門部署を用意できるほど、規模感があるわけではないので地道に個人が片手間で扱える範囲でまず頑張ろうと思います。

最後に

余談として僕の友人が「祭」とかかれた半被を着て門番的に待ち構えていたので、心強かったです。
(来るとこ間違ったかな?と少しなったし遠くで見て、ふいた)
頑張ってたね、お疲れ様。また似たようなの何かあったら教えてね。

おしまい。