ペパボ POとPOじゃない人の勉強会 第10回 の発表資料です。Inspired日本語版を読んでいます。

1. GMO Pepabo, Inc.
TAKAHASHI Kenichi
2015/07/15 POとPOじゃない人の勉強会 #10
Inspired
24章 26章

2. 前回のおさらい
> 製品仕様の検証とはフィージビリティ、
ユーザビリティ、価値の検証である
> 製品プロトタイプの検証はいろいろ
な手法や注意点があるのでよく読もう
> 製品を改善するとは「機能を追加す
る」ことではない

3. 第24章 ユーザにやさしい
緩やかなバージョン移行

4. 新しいバージョンがユーザに苦痛を与える
> 急に変更されたというストレス
> 今、変更に対応している時間はない
> そもそも新しいバージョンが動かない
> 互換性がない
> 変更されすぎでうんざり
> 前のバージョンに依存した手順書がある

5. ユーザは「変更」を求めていない
> よくできたソフトウェアを使いたい
> 新しい機能を使いたい
> でも今できていることはそのままがいい

6. だけどソフトウェアは変わらなければならない
> ニーズは変化する
> 技術は進歩する
> 市場も変化する

7. 賢いやり方で変更を展開する
> インターネットの普及によりネガティ
ブ、ポジティブな反応はあっという
間に世界中に広まってしまう
> 「緩やかなバージョン移行」が大切

8. 「緩やかなバージョン移行」で大切なこと
> ニュースレターやチュートリアルで前持っ
て変更の内容をユーザに知らせる
> ただし、多くのユーザは読んでくれない
> 自信を持って新しいバージョンをリリースできない
なら品質保証に労力をかける
> 大規模な変更の場合は、平行稼動できる期間を設
けたり、一部のユーザにリリースしたりするとよい
> ただし、膨大な時間とサポートコストがかかる

9. 善意の貯金は大切なときのためにとっておく
> ユーザがサービスを気にいってくれ
ているなら、善意の貯金があるはず
> ただ、それをバージョン以降で使わ
ないほうがよい
> じゃあどういうときに使うのがいいのだろ
う?

10. 第25章 迅速な対応

11. 製品の発売はゴールではない
> このタイミングでチームが解散させら
れることが多々あるが、これは間違い
> プロダクトマネジメントと製品開発プ
ロセスの不手際である
> Webサービスではあまりない?

12. 発売直後までプロジェクトを延長する
> 製品開発の中で一番ROIを改善できる
のは発売直後
> 発売することでわかることが沢山ある
> わかったことに迅速に対応する
> 問題があるかどうかではなく、どれだけすばや
く対処できたかで評価されることがある
> 次のリリースサイクルまで待っていては、
時間もコストもかかりすぎる

13. 発売しないとわからないことがある
> プロトタイピングや品質保証、開発
プロセスがどれだけ優れていても、
発売されないとわからないことがあ
ることを認める

14. 問題をどうやって発見するか
> 定量的な目標値を継続的にモニタリ
ングする
> リファレンスカスタマーを探す、なっ
てもらう

15. 製品開発チームがやるべきこと
> 毎日議論しよう
> 数値を確認する
> 優先順位をつける
> 解決方法を考える
> 提供方法を決める
> ご近所さんを呼ぶ
> CSなど

16. 第26章 アジャイルな
開発手法を使いこなす

18. アジャイル宣言の背後にある原則
> 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
> 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客
様の競争力を引き上げます。
> 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
> ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
> 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで
彼らを信頼します。
> 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです
> 動くソフトウェアこそが進 の最も重要な尺度です。
> アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるように
しなければなりません。
> 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
> シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
> 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
> チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのや
り方を最適に調整します。

19. Agile Is Dead
> Pragmatic Daveに質問: アジャイルより
も敏捷性
> http://www.infoq.com/jp/news/2014/11/
pragmatic-dave-agility
> Agile Is Dead (Long Live Agility) -
PragDave
> http://pragdave.me/blog/2014/03/04/
time-to-kill-agile/

20. 使いこなすためのポイント1
> プロダクトマネージャーがプロダク
トオーナーとなること
> アジャイルならうまくいくという勘
違いをしない

21. 使いこなすためのポイント2
> アジャイル開発は計画をたてないわ
けではない
> 細かいサイクルに対応できるように
軽量な市場性評価を行う

22. 使いこなすためのポイント3
> プロダクトマネージャーとデザイナー
は、製品開発チームよりも1,2スプ
リント先行すること
> 製品開発チームにも強力してもらう
ことを忘れない

23. 使いこなすためのポイント4
> デザイン作業の粒度を細かくしよう
> ただし、家をデザインするときに1部屋ずつ
デザインするような分割のしかたはよくない
> ショートケーキ
> 製品の機能をできるだけ削ぎ落すの
が大事

24. 使いこなすためのポイント5
> 重厚な仕様書ではなく、プロトタイ
プとユーザストーリーを作ろう
> 実際のユーザでテストできる
> 問題点を考えざるを得なくなる
> 次のスプリントで作るべきものが明確になる

25. 使いこなすためのポイント6
> ユーザストーリーをどう作業に落し
こむかはエンジニアに任せよう
> 品質、拡張性など、エンジニアならではの
視点があるはず

26. 使いこなすためのポイント7
> 朝会には必ず出席しよう
> 朝会はコミュニケーションの始まり
> 関係者間でのコミュニケーションを誘発する

27. 使いこなすためのポイント8
> 開発者の環境でなく、ステージング
環境で製品の品質を確保しよう
> 本番環境でちょくちょく変更すると
顧客に機嫌を損ねる可能性がある

28. 使いこなすためのポイント9
> スプリントの最後には、現状のデモ
と次のスプリントで開発するプロト
タイプのデモをしよう
> 動いているプロダクトの確認と、今
後の方向性を示す

29. 使いこなすためのポイント10
> 全員にアジャイル開発のトレーニン
グを受けさせよう
> 共通認識がないと、言葉の解釈やそ
もそも論になりやすい

30. 使いこなすためのポイント10
> 全員にアジャイル開発のトレーニン
グを受けさせよう
> 共通認識がないと、言葉の解釈やそ
もそも論になりやすい

31. コラム 26-1
> 製品を見つけ出すフェーズでエンジ
ニアチームを巻き込みすぎるのは高
コスト
> スプリントという単位ではなく、もっと細か
い単位でフィードバックループを回さないと
いけない
> エンジニアの仕事は山ほどある

32. コラム 26-2
> 長いので意訳
> アジャイルソフトウェア開発宣言と背後に
ある原則を理解しろ
> それを理解したコンサルを雇え

33. おわり