GMO Pepabo, Inc. TAKAHASHI Kenichi

2015/07/15 POとPOじゃない人の勉強会 #10

Inspired 24章~26章

前回のおさらい> 製品仕様の検証とはフィージビリティ、ユーザビリティ、価値の検証である

> 製品プロトタイプの検証はいろいろな手法や注意点があるのでよく読もう

> 製品を改善するとは「機能を追加する」ことではない

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

新しいバージョンがユーザに苦痛を与える

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

ユーザは「変更」を求めていない> よくできたソフトウェアを使いたい > 新しい機能を使いたい

> でも今できていることはそのままがいい

だけどソフトウェアは変わらなければならない

> ニーズは変化する > 技術は進歩する > 市場も変化する

賢いやり方で変更を展開する> インターネットの普及によりネガティブ、ポジティブな反応はあっという間に世界中に広まってしまう

> 「緩やかなバージョン移行」が大切

「緩やかなバージョン移行」で大切なこと

> ニュースレターやチュートリアルで前持って変更の内容をユーザに知らせる > ただし、多くのユーザは読んでくれない

> 自信を持って新しいバージョンをリリースできないなら品質保証に労力をかける

> 大規模な変更の場合は、平行稼動できる期間を設けたり、一部のユーザにリリースしたりするとよい > ただし、膨大な時間とサポートコストがかかる

善意の貯金は大切なときのためにとっておく

> ユーザがサービスを気にいってくれているなら、善意の貯金があるはず

> ただ、それをバージョン以降で使わないほうがよい > じゃあどういうときに使うのがいいのだろう?

第25章 迅速な対応

製品の発売はゴールではない> このタイミングでチームが解散させられることが多々あるが、これは間違い

> プロダクトマネジメントと製品開発プロセスの不手際である

> Webサービスではあまりない?

発売直後までプロジェクトを延長する

> 製品開発の中で一番ROIを改善できるのは発売直後 > 発売することでわかることが沢山ある > わかったことに迅速に対応する > 問題があるかどうかではなく、どれだけすばやく対処できたかで評価されることがある

> 次のリリースサイクルまで待っていては、時間もコストもかかりすぎる

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

問題をどうやって発見するか> 定量的な目標値を継続的にモニタリングする

> リファレンスカスタマーを探す、なってもらう

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

> CSなど

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

アジャイル宣言の背後にある原則> 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 > 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

> 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 > ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 > 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

> 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです > 動くソフトウェアこそが進捗の最も重要な尺度です。 > アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

> 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 > シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 > 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 > チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

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/

使いこなすためのポイント1> プロダクトマネージャーがプロダクトオーナーとなること

> アジャイルならうまくいくという勘違いをしない

使いこなすためのポイント2> アジャイル開発は計画をたてないわけではない

> 細かいサイクルに対応できるように軽量な市場性評価を行う

使いこなすためのポイント3> プロダクトマネージャーとデザイナーは、製品開発チームよりも1,2スプリント先行すること

> 製品開発チームにも強力してもらうことを忘れない

使いこなすためのポイント4> デザイン作業の粒度を細かくしよう > ただし、家をデザインするときに1部屋ずつデザインするような分割のしかたはよくない

> ショートケーキ

> 製品の機能をできるだけ削ぎ落すのが大事

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

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

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

使いこなすためのポイント8> 開発者の環境でなく、ステージング環境で製品の品質を確保しよう

> 本番環境でちょくちょく変更すると顧客に機嫌を損ねる可能性がある

使いこなすためのポイント9> スプリントの最後には、現状のデモと次のスプリントで開発するプロトタイプのデモをしよう

> 動いているプロダクトの確認と、今後の方向性を示す

使いこなすためのポイント10> 全員にアジャイル開発のトレーニングを受けさせよう

> 共通認識がないと、言葉の解釈やそもそも論になりやすい

使いこなすためのポイント10> 全員にアジャイル開発のトレーニングを受けさせよう

> 共通認識がないと、言葉の解釈やそもそも論になりやすい

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

> エンジニアの仕事は山ほどある

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

> それを理解したコンサルを雇え

おわり