スポンサーサイト

一定期間更新がないため広告を表示しています

- | - | -

行動を観察する

社内で自分が関わっているサービスを触ったことがなさそうな人のところにいき、「これこれこういう状況です、こうしたいとおもっています、どうしますか?」というようなお題を与え、その人がどこをどう見てどう触ってどんな行動をとって結果どうなるのかを観察してみた。

 

どっひゃー。

 

みんなやるといいよ。

PO/PM | comments(0) | -

機能的負債との日々

「機能をひとつ追加するときは、いらなくなった・使われていない機能をひとつ削除してからにする」をモットーにしています。

 

しかしそうことはうまくいかないのであって、「追加ダメ〜」とどんなに長い手足を広げて止めようとしてもどんどんいろんなものが通り過ぎていってしまい、打ちひしがれる毎日なわけであります。

 

しかし、きょう、ようやくまたひとつの機能に別れを告げることができた。いままでありがとうねー。いっぱい稼いでくれもんね。でももうゆっくりおやすみよ。という気持ちでその機能を使えなくした。

 

そんなぼくがやらなければいけないと思っていること。

  • 壁一面にすべての機能を書き出しておく
  • 機能ひとつひとつに連番を振っておく
  • 毎朝関係者全員でその壁に向かう
  • ランダムに3人が0から9のうち好きな数字をひとつあげる
  • 3つの数字を適当に足したり引いたりつなげたりしてひとつの数字をつくる
  • その数字が振られた機能について3人が解説する
  • 3人全員が答えられなければその機能はリストラする

関係者がまともに答えられない機能なんてない方がマシだ。

 

システムはほうっておくとどんどん複雑になっていく。よかれとおもって、もっと便利になると思ってやったことが、どんどんどん複雑を生み出していく。そしてだんだん身動きが取れなくなる。

 

出したら片せ、しまえ。いらなくなったら感謝して捨てろ。

 

必要なものマイナス1くらいがちょうどいいのだとおもっている。飢えてる感じ、乾いてる感じがモチベーションにつながるように思うから。

 

そう願ってきょうもまた機能的負債を返済していく。

PO/PM | comments(0) | -

デザイン的負債と戦うためのチェックリストを作った

ひと通り作ったので部署のデザインしばき隊の人に共有した。

訳あってオープンにできないけど、知りたい人はわたくしのGistを漁ればでてきます。

 

これが仕組みに組み込まれると知らず知らずのうちにデザイン的負債が減っていくはず。

 

はぁ〜やっとデザイナになれたよ、ぼく。

PO/PM | comments(0) | -

ミーティング中なのに

自戒を込めて書いておく。
ミーティング中、とりわけスプリントレビューの時に顕著なのだけど、チームのほかの人の発表や発言を聞かずにもくもくとコンピュータに向かってなにかしら別のことをやっている人が多い。自分もその1人。
これよくないよなーとおもっていながらなかなか改善できていない。どうしたらいいんだろうなというのが正直なところ。
「発表をちゃんと聞くようにしませんか?」と問いかけるのがいいのかなぁ。
ふー。
PO/PM | comments(1) | -

それはどんなふうにあなたの気分をよくしてくれますか?

なになに機能をリリースしました。
ほげほげができるようになりました。

といったようなことをユーザーにお知らせすることが多々あるのです。そんな時は、それによってユーザー自身がどんなわくわくをうけとるのか、それを伝えることを意識しています。

ようするに「これであなたは幸せな気分になりますよ」ということ。

もう機能を売りにするのは嫌なんです。なぜなら飽和してるから。もちろん機能が増えたらそれだけで嬉しいし喜ばれるフェーズも存在します。たまたま僕がかかわっているものはそうじゃないというだけの話。がんばるぞ。
 
PO/PM | comments(0) | -

人日見積りから遠くはなれたところで暮らしたい

ついつい開発タスクを工数で見積もってしまいがち。
たとえば「4日」というように。そしてこの場合の4日が意味するのは「4人/日」である。

しかし、複数人の開発者がいるチームに所属しているわけなので、こういった工数の見積もりはしないように心がけるべきなんだろうな。特に、チームの人が自分しかいない場面で、たとえば上司からどれくらいかかるか聞かれた場合、ざっくり感を求められているとしても、だいたい「hogehoge日 くらい」と回答するのはできるかぎり回避するようにしたいと思った。

チームで考えたい

なんでかというと2つあって
  • 自分が開発者じゃないかつ実際のそのタスクを担当するわけではない
  • 自分たちのチームでならどれくらいで可能か、どうやれば可能かというのを、一旦チームのメンバーと話すというプロセスを持つことが、チームで取り組むための礼儀
こうすることで期待できることは
  • 作業者が見積もりに加わることで現実的な見積もりになる
  • 規模が大きかったとしてもチームで調整できる
  • POと開発チームで信頼関係が生まれる
  • チーム全員の一体感が生まれる(われわれ vs 問題 の構図が明確になる)
といったところだろうか。

人日の見積もりは、1人で担当した場合に何日かかります、という話なんだけど、どうしても誰か1人が担当することが想定されていて、しかもその基準が暗黙的に特定の誰かになっている感じがしてしまうのが嫌なんだろうな。開発者が1人しかいないならいいんだけど、先にも述べたように自分の場合は複数人いるし、スクラムを実践しているという前提があるので、チームで考えたいしそのような思考・行動をとるように心がけたい。

 
PO/PM | comments(0) | -

プロダクトオーナー祭り2015でLTしてきたこと

プロダクトオーナー祭り2015 〜世界を変えるのは俺たちだ!〜にスピーカーとして参加してきました。
発表資料を置いておきます。



イベント等で発表するのは初めての経験だったので、とても緊張しました。
いくつか反省点もみえてきたので今後に活かそうと思います。
関係者の皆様、ありがとうございました。

いやーそれにしてももうちょっと多方面で頑張らないとな。
 
PO/PM | comments(1) | -

ファシリテータむずい

雑談会の開催

所属している部署では自分と同じ職種の同僚が全部で6人います。その中には新卒で入社して社会人1年目、2年目の子もいます。きっちりと先輩後輩という関係で業務をすすめているわけでもないですし、同じ業務に複数人でがっつり取り組むようなこともありません。

そんなぼくたちが週に1回情報共有の場として雑談会を開催しています。業務中の1時間。最初はおたがいにこの1週間でどんなことしたか、これからどんなことをする予定かを順番に話していました。

会を重ねるごとに困っていることや課題みたいなのも出てくるようになってきました。そしてそれに対してそれぞれがアドバイスをしたりと。

KPT と KPTA を使ったふりかえり

開催するようになって4ヶ月ほどたったでしょうか。ここ数回は前半に業務の共有。後半は KPT と KPTA を使いながらふりかえりを実施するようにしました。

その際、自分自身がファシリテータを努めるようになりました。ファシリテータをやってみると、参加者の発言を引き出すことがあまりできてない自分を発見しました。

ファシリテータ難しい

そしてなによりも難しいなと感じているのは、話がそれていってしまいしかもわりと盛り上がってしまっている時の振る舞いです。正直ただただ聞き入るだけになってしまっています。

どうするのがいいんだろう。

しかしながら一応時間内には Problem の共有と、それを改善するための Try および Action がみんなからでてきて一応のチームとしての合意は取れています。ひとまずこれでいいのかなという思いもある。

ふりかえってみて

1時間というのは貴重な時間であり、だらだらするのはよくない。わかっていてもだらだらしてしまう。こういった場に PC を持ち込んでのぞむと、発言者と直接の関係者以外はだいたいみんな別のこと(たとえばメールチェック、チャットのチェック、SNS の流し読みなど)をやりがちです。

KPT を導入することでそのような時間がかなり減ったと実感しています。これがアナログ(付箋に書き出してそれをホワイトボードに貼る)の良さなのかもしれないですね。

また、ひとつの課題についても各自おのおのの視点からの工夫があがってくることで、それぞれが他人事というよりは自分事になっている印象があります。自分事に感じるからこそ一体感が生まれ、みんなで取り組んでいる感がでてとてもよいなと実感しています。
PO/PM | comments(0) | -

バックログリファインメントがうまいくいかない

タイトルのとおりなんだけど、うまくいかない理由はいくつか思い当たることがある。
  1. ユーザーストーリーで考えていない
  2. プロダクトで実現したいことよりもエンドが決まっている案件が目白押し
    • たとえば、外部連携先の仕様変更にともなう対応
  3. 不定期だけど継続的にやってくるお問い合わせに関する調査対応
    • 不具合だとまずいので、わりと優先度が高い
こう書いてみると結局たいしたことないな。

2と3もちゃんとユーザーになにかしらの価値をもたらすことができるはずなので、プロダクトオーナーとしてはそこを徹底的に考え、吸い上げて、ユーザーストーリーに持ち込めばいいだけじゃないのか?
すると
 
「ほとんどわれわれの都合じゃないか」 > 「ユーザーに価値を提供できていない」「プロダクトがなかなかよくならい」 > なんだかもやもや

という良くない流れを断ち切って、
 
「ちょっとずつだけど価値を提供できている」 > チームが一体となって「がんばるぞ」

という良い流れにできるはずだ。

ちなみにバックログリファインメントとはスクラムのイベントのひとつです。
詳しくはスクラムガイドを参照のこと。
PO/PM | comments(0) | -

PM/POに必要なのは熱意だ

熱意が足りなくなってる問題

ここしばらくの自分とサービスとの関わりを振り返ってみて、一番大切な熱意あるいは熱量あるいはオーナーシップが薄れているなと感じた。

どんなときに感じたか

これはまったくのいい訳だけど、サービスがある程度の規模になると、やっぱりすべてを把握することが難しくなってくると思うんですよね。そしてそのことに慣れてしまうというか。簡潔に書くと「まーいいか」が増えてきてしまったなと。

すべてを把握する必要があるのかということは置いておいて。

ただ、トヨタの長谷川龍雄だったか中村健也だったかが、アメリカでGMやフォードを視察した際に「あれこれ質問したけど全てを把握している人がいないことに驚いた、トヨタにはいるのに」というような文章をどこかで目にしていて、それもあってというのもある。

どうするか

別のサービスのPMが、すべてのイシューを見るようにしているということを聞きつけて、自分もそれをしてみようと思った。けっこう大変そうだけど。一回やってみようかなと。

要するに観測範囲を意識的に少しずつ広げていくということである。
PO/PM | comments(0) | -