2016/11/26　「プロダクトオーナー祭り2016」に参加してきました。

公式サイト
https://postudy.doorkeeper.jp/events/52385

Togetter
http://togetter.com/li/1052774

聴講したセッションをあとで見返すためにスライド貼っておく。

---

[#A2]　この10年でここまで変化したプロダクトオーナーの役割とプロダクトマネジメント

アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと from Yasui Tsutomu

Stacey Matrix

• リーンのところはかんばんがいい。
• 素敵な思考は右上の領域から生まれる。
• 最初はスクラムで始めたプロダクトでも、だんだんわかってくると、だんだん左下（計画駆動）に近づいてくることが多い。

P.72

• サイモンさんが書いたマップ
• 左から右に時間が流れている。
• 最初は開拓者が試して動くようにする
• 入植者がスケールできる安定できるものにする
• 都市計画者が大規模にコモディティにかえていく
• さっきの図となにが違うかというと、人が違う
• 開拓者、入植者、都市計画者はそれぞれ得意なものがある。
• 同じ人がうまくもっていくのは難しい。
• なので引き継いでいく。
• 上手く渡すんじゃなくて、盗ませる。

トヨタの商品開発、という本はおすすめ

誰がやるのが効率的か、を考える必要がある。責任が誰にあるかは決める必要があるが。

SMがPOをコーチする。
攻撃的なPOとかの場合。
オレ流のPOなら、スクラムじゃないやりかたの方がいいこともある。

うまくいかないのはスクラムのせいではなく、そもそも問題があることがあぶりだされたんだ。
小さく失敗して小さく修正する、を繰り返す。

Joy,Inc

• アジャイルの本じゃない。
• アジャイルという言葉は一度も出てこない。
• でも書いてあることはアジャイル。
• 起業してアジャイルっぽくやって成功した話。
• 計画ゲームが学べるのでは。POの観点では。

---

[#A4]　世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス

世界と事例から学ぶ、プロダクトオーナーの「素養」としてのアジャイルメトリクス from Hiroyuki Ito

POは、プロダクトの価値だけでなく開発チームの作業の価値の最大化が目的

メトリクスを計測しているチームのほうがしていないチームより満足度が高い。つまり成功が高まる。 by 野中先生 squip

dodozineの記事：https://codezine.jp/article/detail/9690
プロダクトバックログの作成に役に立つ

仮説検証や継続的検証や停止判断をメトリクスをもとに判断するのがPOの役割

割り込み率は自作した。必要なメトリクスは自分で作る。

スループット　＝　一定時間内でリリースできたストーリー数やタスク数

変更要望の数と比率
受け入れた変更要望の数と比率
※後出し要求の方が重要なことが多い

自分たちを正当に評価してもらうためにもメトリクスを取る。

開発中の時点のメトリクスは難しいのかな、と思っている。

---

[#A5]　プロダクトオーナーこそ一番のユーザーであれ！

blog： http://udtalk.jp/post-2834/

---

[#A6]　プロダクトオーナーは育成できるのか？

プロダクトオーナーは育成できるのか？ - プロダクトオーナー祭り2016 from Yusuke SUZUKI

---

[#A12]　共感する開発だけを考えた

共感する開発のことだけ考えた。 from shoji_yamada

---

[#A13]　プロダクトマネージャとしてグローバルプラットフォーム開発に関わって学んだ5つのこと

プロダクトマネージャとしてグローバルプラットフォーム開発に関わって学んだ5つのこと #postudy from Daisuke Matsuda

---

[#A14]　なぜあなたのチームのプロダクトは太ってしまうのか
〜プロダクトマネジメントをかじったエンジニアが感じたLess is moreの極意〜

---

[#A15]　DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ

ブログ： http://i2key.hateblo.jp/entry/2016/11/29/091657

---

2016/11/18(金) 「Spring Day 2016」に参加してきました。

公式サイト
http://springday2016.springframework.jp/

セッション一覧＆資料
http://springday2016.springframework.jp/session.html

後で見返すためのメモ。聴講したセッションは以下。

---

ROOM1-2　Spring Framework 5.0

英語の同時通訳。

---

ROOM4-3　これからはじめるSpring MVC

資料未公開っぽい。

---

ROOM3-5　Spring Security で作る Web API アクセス制御の最適解

Spring Day 2016 - Web API アクセス制御の最適解 from ダイスケ 都元

タイトルにある「Spring Security」はほとんど登場しなかった・・・けど勉強になる内容。

---

ROOM3-6　Spring5に備えるリアクティブプログラミング入門

Spring 5に備えるリアクティブプログラミング入門 from Takuya Iwatsuka

Reactiveは最近よく聞くようになったなぁ

---

ROOM4-7　Springを使ったWebアプリにリファクタリングしよう

Springを使ったwebアプリにリファクタリングしよう from Kouhei Toki

ハンズオン資料：　https://github.com/KouheiToki/jsug-handson-20161118

ハンスオンはやっぱ勉強になりますね。ただ、時間が足りなかった・・・

---

ROOM2-9　Data Microservices with Spring Cloud Stream, Task, and Data Flow

Data Microservices with Spring Cloud Stream, Task, and Data Flow #jsug #springday de Toshiaki Maki

槙さんの講演はいつも高度ネタ満載ですな

---

2016/11/18(金) 「エンタープライズアジャイル勉強会　2016年11月セミナー」に参加してきました。

Webサイト
https://easg.smartcore.jp/C22/notice_details/VkRFSE5BPT0=

鈴木雄介さん（講演者）のブログ
日本企業にアジャイルを導入して考えてこと #easg

講演資料

ユーザー企業へのアジャイル導入四苦八苦 - エンタープライズアジャイル勉強会2016年11月セミナー from Yusuke SUZUKI

殴り書きメモ

保守契約ではなく、継続機能改善プロセスをいれませんか、と提案した。
３ヶ月ごとに同額で請負契約する。

３ヶ月リリース
予算確保の名目が難しい。名目が明確すぎると何かを作りきる、という誤解が生まれるので、うまくぼかす。

締め切り駆動が大事。
締め切りを守らない会社は難しい。
業種による。出版業者は死んでも守るのでアジャイルやりやすいかも。病院とかヘルスケアだと守りにくい。

３ヶ月は四半期目標にも合わせやすい。
先に３ヶ月、と決めちゃうと、意外とみんな守ってくれる。

次のリリース、という安心感がすごい。
今やるか、次やるか、を選べる。
要件を無理に押し込まなくなる。
３ヶ月に１回くらいだと経営層も聞いてくれる。毎月だと難しい。
評価者を正しく設定することが大事。
システムをつくる、ではなく、成果を出す、という視点になりやすい。

新機能開発と保守の間に、定期改善のアジャイル開発を挟むのが上手くいった。

POは、誰かの意見を聞くふりをすることは重要だが、想いをもっていないといけない。
誰かの意見ばっかり聞いていると、決められなくなる。そして、経営層が言ったから、とか逃げが生じる。

お客さんに説明するときはアジャイルという用語は出さない。
POは一人にするが、補佐する人がいることが大事。一人だときつい。

MSA
一貫性よりも結果整合性のほうが価値がある

アーキテクチャをきちんと考えた上で、フロントエンドはアジャイル、バックエンドはWF、とかはあり得る。