MVPを元にした製品開発

Inspired日本語版というWebページの記事がとても面白かったのでメモ。
いわゆるリーンスタートアップに出てくるMVPを元にした製品開発を題材にしているように思える。
目に留まった内容をラフなメモ書き。
詳細はWebページを見てください。
App Storeでも電子書籍で売られているようです。

【元ネタ】
書籍目次 ≪ Inspired日本語版

App Store - inspired-j

【1】はじめに ≪ Inspired日本語版

(引用開始)
もっとわかりやすく言うと、技術的にいい仕事をするだけではダメなのだ。それと同じくらい、あるいはそれ以上に大事なのは、価値があって (valuable)、使いやすくて (usable)、実現可能な (feasible) 製品を「見つけ出す」ことである。
失敗の原因を徹底的に突き詰めていくうちに、何を作るかを決めたのは、プロダクトマネージャーと呼ばれる人だということがわかった。プロダクトマネージャーは、通常はマーケティング部門に所属していて、私たちエンジニアが作り上げる製品のプロフィールを決める人であった。ところが、さらにわかったのは、プロダクトマネジメントは、HPにとってあまり得意な領域ではないということだった。そして、後になって気づいたのだけれど、ほとんどの会社はプロダクトマネジメントが得意ではなく、その状態は今も変わっていない。
(引用開始)
プロダクトマネージャーの仕事は、価値のある、使いやすい、実現可能な製品を「見つけ出す」ことである。
(中略)
プロダクトマネージャーの仕事は、価値があって、使いやすくて、実現可能という目的を満たす上で必要最小限の (余計なものが一切そぎ落とされて洗練された) 製品を特定することである。これによって、製品化までの時間と製品の複雑さを最小限にするのである。
(引用終了)

リーンスタートアップに出てくるMVPの定義とは、価値があって (valuable)、使いやすくて (usable)、実現可能な (feasible) 製品であり、必要最低限の機能を持つこと。
価値があるのは、顧客価値に相当。
使いやすさは、使用性(ユーザビリティ)という品質特性に相当。
実現可能性は、アーキテクチャがプログラムで実装可能で、システムとして実現可能(フィージビリティ)であること。

面白い点は、MVPは６個の品質特性(機能性、信頼性、性能、使用性、保守性、移植性)の中で、使用性を最も重視していること。
製品のアーキテクチャが実現可能(フィージビリティ)であることを保証する人は普通はアーキテクトだが、プロダクトマネージャもアーキテクトの役割を兼ねること。
つまり、プロダクトマネージャはかなりの高レベル人材であること。

(引用開始)
エンジニアリングは、重要で困難な仕事である。でも、もっと重要なのがユーザーエクスペリエンスデザインであり、それは、たいていの場合エンジニアリングよりも困難である。
エンジニアは、たいていユーザーエクスペリエンスデザインが不得意である。エンジニアは実装モデルで考えるが、ユーザーは概念モデルに基づいて考える。
機能性 (製品要求) とユーザーエクスペリエンスデザインは、本質的に連関している。
(引用終了)

使用性という品質を重視すること。それは機能性に密接に関係している。

【2】第1章　製品開発の鍵を握る担当者とその役割 ≪ Inspired日本語版

プロダクトマネージャーの役割
プロダクトマネージャーの主な任務は2つ。
製品の市場性を評価することと、開発すべき製品を定義すること。

(引用開始)
十分に市場性があって、自社でそのアイデアを実現できる可能性が高いと判断されれば、その次には、誰かが、そのアイデアの具体的な形、つまり、どういう製品にするのか（必要とされる特性と機能、ユーザーエクスペリエンス、発売の基準など）を「見つけ出す」必要がある。ここで、再びプロダクトマネージャーの出番となる。この任務は、プロダクトマネージャーの仕事の核心部分である。こうして形になっていく仕様は、製品要求仕様(PRD, Product Requirement Document)、あるいは、製品仕様、機能仕様などと呼ばれる。ここで、私は、紙ベースではなく、プロトタイプに基づく軽量なアプローチを勧める。しかし、肝心なのは、その仕様書が記述すべきことは、開発されるソフトがどういう機能を備えて何をするものかということであり、どのように動くかではないということだ。
(引用終了)

上記の製品こそが、リーンスタートアップに出てくるMVP(実用最低限の機能を持つ製品)に相当する。

【3】第2章　プロダクトマネジメント VS. プロダクトマーケティング ≪ Inspired日本語版

マーケティング主導の製品である
一つの役割に二人の担当者がいる
一人で二つの役割を兼務している

【4】第3章　プロダクトマネジメント VS. プロジェクトマネジメント ≪ Inspired日本語版

プロダクトマネージャーとプロジェクトマネージャーの違い

トレインモデル。
それは並行開発。
複数のコンポーネントを平行に開発したり、別の複数の製品を平行に開発したりとか。
派生開発、ソフトウェアプロダクトラインを連想させる。

【5】第4章　プロダクトマネジメント vs. デザイン ≪ Inspired日本語版

ユーザーエクスペリエンスデザイン、つまり使用性(ユーザビリティ)という品質特性の重視

第5章　プロダクトマネジメント vs. エンジニアリング ≪ Inspired日本語版

正しい製品を作るのか、それとも、製品を正しく作るのか
前者はアーキテクトないしプロダクトマネージャ。つまり、製品設計、アーキテクチャの問題。
後者はマネージャ。つまりマネジメントの問題。

エンジニアリングチームがコードを書き直したいだって！？

(引用開始)
こういうことが起きてしまう原因でよ目につくのは、プロダクトマネージャーが、作れそうな機能なら何でもめいっぱいくっつける、というようなことを何年にもわたってエンジニアリングチームにやらせてきたために、彼らをボロボロにしてしまうことだ。結果はといえば、インフラを考えないで酷使すれ、いずれ、ソフトウェアがもはや機能しなくなるときが必ずやって来る。
(中略)
エンジニアリングで何かのキャパシティを設定するときは、そのうち一定の割合を予備として空けておくのだ。eBay ではこれをヘッドルーム (頭上の空間) と呼んでいた。
(中略)
エンジニアリングチームとは、次のような感じで取り決めをしておこう。プロダクトマネージャーは、エンジニアリングチームのキャパシティ全体の20% を空けておぃて、これをエンジニアリングチームの判断で使える予備の枠として与える。エンジニアリングチームは、たとえば、コードを書き直したり、アーキテクチャをやり直したり、コードのダメなところをリファクタリングしたり、データベースのシステムを入れ換えたり、システムのパフォーマンスを改善したり、といった作業のためにこの枠を使うことができる。つまり、「開発を中断してコードを書き直さなければだめだ」と言い出す事態を避けるために必要だと思うことであれば、何でも、この枠を使って手を打っておくのだ。
(引用終了)

システムのリプレース案件が最も危険な理由: プログラマの思索にも書いたが、ジョエルも同じ事を言っていた。
プログラムの保守性や移植性が落ちた場合、アーキテクチャが時代に追いつけず古くなってしまった場合が上記の状況に相当するだろう。
製品の品質やアーキテクチャが古くなってその重みに耐え切れなくなる前に、リファクタリングするリソースをあらかじめ確保して、少しずつ改善できるような環境を作っておく。

【6】第7章　プロダクトマネージャーを管理する方法 ≪ Inspired日本語版

プロダクトマネジメントチームを組織する
Scrumでプロダクトオーナーの役割を持つ人達が多い場合、一つのチームを作るのと同じ。

プロダクトマネージャーをどうやって評価するか？
ネットプロモータースコア (NPS)
推奨者 (プロモーター)に評価してもらい、結果を収集する。
リーンスタートアップにおけるMVPの評価方法に重なる。
新しいビジネスには新しい評価方法が必要。

【7】第20章　必要最小限までそぎ落とされた製品 ≪ Inspired日本語版

機能を減らすか、それとも発売を遅らせるか？

(引用開始)
ここで、まったく別のやり方を提案しよう。
第一に、プロダクトマネージャーがまずやることは、デザイナーと協力して、その製品としての目的を達成するために必要最小限の機能を備えたハイフィデリティプロトタイプ (製品の正式版が正確にイメージできる試作品) を作ることである。
(中略)
第二に、デザインが始まる当初から、エンジニアリングチームからもだれか加わってもらって (普通はアーキテクトか主任エンジニア)、プロトタイプで表現される製品のアイデアをいっしょにレビューしてもらう必要がある。この人は、プロダクトマネージャーやエンジニアがそれぞれの製品アイデアに必要なコストを把握して、コストの比較をするのを手伝うのである。
(中略)
第三に、現実のターゲットユーザーとともにプロトタイプの検証を行うことが欠かせない。
(引用終了)

MVPの作り方。ハイフィデリティプロトタイプという考え方。

(引用開始)
こういうわけで、いったん必要最小限の機能の製品を定義して、ターゲットユーザーといっしょに検証を続けて、これでうまくいくという確証が得られたら、その後はもう機能のどれかを落とすことはできないし、また、それをやってもユーザーからはお墨付きをもらえるなどと思ってはいけない。もしこれができるとすれば、実は、そもそも初めから必要最小限の機能の製品にはなっていなかったということだ。
それでもまだ、難しい決断をしなければならない場面は出てくるだろう。よくあるのは、機能の中のあるものについて、予想よりも実装に時間がかかるという場合だ。でも、私がここで説明しているモデルでは、機能を減らすのではなく、スケジュールをずらすのがまっとうな対応である。とっくに機能は必要最小限までそぎ落としてしまっていることを思い出してほしい。このモデルのいいところは、他のよくある手法に比べて、見積りが正確だということである。
(引用終了)

MVPがなぜ良いのか？
機能は必要最低限まで落とされているので、見積りが正確になりやすいこと。
実際に作ってみたら、とても難しいことが分かっても、それ以上の機能を減らすことができない。
実際にMVPの開発が始まると、プロダクトマネージャすらも簡単に機能追加することはできない。

【8】第26章 アジャイル開発手法を使いこなす ≪ Inspired日本語版

プロダクトマネージャーは、プロダクトオーナーの役割を兼ねる。
製品計画は必要。
プロダクトマネージャーとデザイナーは、いつも1つか2つ先行したスプリントを計画しておく。

(引用開始)
プロダクトマネージャー兼プロダクトオーナーの中心的な役割として、価値があって使いやすいプロトタイプとユーザーストーリー (ユーザーの要求事項を文章の形で記述したもの) を用意することがある。これらは、製品開発チームが開発を進める出発点となるのだ。大げさな PRD (製品要求仕様) や機能仕様書ではなくて、プロトタイプとユーザーストーリーがいいのだ。
(引用終了)

プロダクトマネージャの仕事は、ばかでかい製品仕様書ではなく、プロトタイプ仕様とユーザストーリーを用意すること。

プロダクトマネージャー兼プロダクトオーナーとインタラクションデザイナーは、毎日の進捗報告会議 (スタンドアップ、あるいは、デイリースクラムとも言う) に欠かさず出席する。

初期のスプリント(いわゆるアーキテクチャスパイク、アーキテクチャ助走路)はプロトタイプの代わりにならない。

(引用開始)
スクラムのようなアジャイル開発手法を使えば、ソフトウェアチームを何十年間も悩ませ続けた主な問題のいくつかが解消される。でも、多くのプロダクトマネージャーやユーザーエクスペリエンスデザイナーが、そして多くとまでは言わないけれど品質保証マネージャーも、最初のうちはアジャイルに戸惑い、自分の役割はこの手法の中ではどうなるのか、と頭を抱えている。はっきりさせておくと、アジャイル開発手法では、こうした人たちの役割は間違いなく必要だとされているのだけれど、私は、アジャイル開発手法の由来のせいでこういう混乱が起きているのだと思う。だから、その由来を説明すると、アジャイルがどういう問題を解決しようとしているのか、そしてどういう課題が残っているのかが明確になるようだ。
(引用終了)

アジャイル開発はカスタムソフトウェア製品の世界から生まれた。
アジャイル開発が生まれる前はウォーターフォール型開発が主流であり、幾つかの問題があった。

(引用開始)
顧客は何が欲しいのかを自分で理解していると思い込んでいるので、プロダクトマネージャーがやるべきことはほとんど見当たらない。同じように、ユーザーエクスペリエンスデザイナーの役割も見当たらない。
そして、カスタムソフトのプロジェクトの大多数は、比較的規模が小さく、社内の業務支援を目的にしているため、ユーザーの数は限定されていて、システムの拡張性や性能といった問題はあまり重要ではない。
(中略)
その問題に対し、アジャイル開発は、客とエンジニアの間のコミュニケーションがよくなるし、小回りの利くプロトタイプを作って試すというのを何度も何度も繰り返すことによって、製品開発のリスクをぐんと減らすことができる。
フトウェアをテストするための最新の考え方を取り入れるのにも役に立つし、製品開発チームとしても、めったに読んでもらえないうえにすぐに使い物にならなくなってしまう書類を作るのに膨大な時間をつぎ込まなくてすむ。
(引用終了)

しかし、製品ソフトウェアにアジャイル開発を導入する場合、ユーザーエクスペリエンスデザインを開発プロセスに取り込むか、プロダクトマネージャーはどんな役割になるか、例えば大規模なインターネットサービスに対するアーキテクチャデザインをどのように開発プロセスに取り込むか、という点はいくつか修正する必要がある、と。