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

こいばな - riskriskと時々鼻メガネ -

正式名称は「どすこい!鼻メガネ会長のいつでも土俵際!」です。ソフトウェア開発に関することを書いています。

第12回 #TFSUG :TOC探究者のプロセス運営 に行ってきた。

コレに行ってきました。
遅刻したけどね・・・

今回は、

  • しばやまさん(@) さんの プロダクトオーナー の話
  • ちぇんわ(@) さんの、考え方 の話

どっちも面白かった。

相変わらず、ログを取ることを諦め聴きに徹してたので
内容はTogetterとか、発表者の方がスライド公開をしてくれるのを待ちましょう。

Togetter - http://togetter.com/li/376633

「プロダクトオーナーシップ」:SHIBAO800 さん

プロダクトオーナーの方は、いったい何を持ってプロダクトオーナーなのかの話。

こんなPOはいやだ は、あるあるってわけじゃないけど、よく聞くなーって

  • 定額食べ放題と勘違いしている
  • 色々ついていると、凄いと思っちゃう
  • リリースのマイルストーンしか決めない
  • プロダクトバックログを整理しない
  • 受け入れ基準を後出しする

僕がコレを聞いて思ったのは、しばやまさんも言ってたけど
ゴールデン・サークルの「What」だけを見ている状態なんだなって感じました。

出来るだけいっぱい機能がついてて、製品が期間内に出ていって、
謎だろうがなんだろうか、製品さえ出来れば、それで良し。
しかし、実は使えないことが分かると、コレが出来ないとダメだと言う

こりゃあいかんと思いますw

作る側の視点で、「なんでこんな機能いるんだろ・・・」って思うことがありますが
そんな時に、「本当にコレ必要ですか?」と聞けたら健全だなって
同じように、「どー考えても、この機能が必要だと思うんですけど・・・」とか

気になったことで、プロダクトオーナーシップが揃ってるPOが良いPOって
ことなのは分かるのですが、何も全てをPOがやる必要ないよなぁとも思いました。

僕が思うチームでやることの利点は、一緒に進む仲間がいることで
決定はPOがやることですが、POは色んな人に助けを求めるべきだとも思います。
チームで協力して一つの製品をつくり上げるのだから、POの足りない資質は
チームメンバーが協力してあげればいいなーって。

作業を全て1人でやったらパンクするわけで、作業を割り振って
結果をAgreeするのがPOでも僕はいいんじゃないかなーって。
(これは怒られるフラグか???)

「LEARN TO UNTANGLE」:CHANGEWORLDS さん

ちぇんわさんが、タイトル間違えてる!って言ってたんで直しておきました。
解くことを学ぶ!ってことでいいのかな

ちぇんわさんの事例を元に、対立って何なの?ってことを
改めて考えさせられる発表でした。

そもそも、事例自体もちぇんわさんの遭遇して考えた結果なので
自分に当てはまらないとしても、手段の対立ってのは
タイムライン上でもよく見かける気がします。

  • この言語はいいけど、あの言語はだめだ
  • あのプロセスはいいけど、このプロセスはダメだ
  • このプロセスを使うなら、この手段を使わないといけない

言い方が否定的になればなるほど、対立が強く見える気がしました。
あと、手段だけにフォーカスがあたってしまって
「なぜ」の部分がすっ飛んでることが多いと思ってます。

ハイリスク・ハイリターン は間違えてないとおもいますが
同じ目的に向かって走っている仲間と対立したときは
リスクを誰かが背負わなくてはならない なんてことを一度忘れて
みんなで幸せになれる方法を探すと、良い解決策が見つかるかなーって思います。

最後に

しばやまさん、ちぇんわさん、素晴らしい発表をありがとうございました。
とても楽しく色々と考えることが出来ました。

次回は、いんだれさんがしゃべるらしいですねwww
日本鼻メガネの会がこんなに入り込んでいいのかという疑問もありますが
みんな楽しそうなので良しすることにします。

書きまくって消して書きまくってを繰り返したので
ぶっとんでる部分もありますが、またなんかあれば追記しようと思いますw