事業戦略・IT開発・UXデザインの開発から販売まですべてわかる｜『プロダクトマネジメントのすべて』を読んだ感想
かなり固めの本を読みました。「プロダクトマネジメント」というとタイトルの通り事業戦略から、スマホのアプリ開発だったり、Windowsアプリだったり、はたまた、そのアプリのデザインの仕方から、どのように販売していくかなど、とにかくたくさんの実施することがあります。
それらを網羅的に解説した本がこちらの、『プロダクトマネジメントのすべて』と言ってよいでしょう。
内容はとても固い感じだけど、様々な製品（プロダクト）の企画から、開発の進め方がしっかりと解説されています。
開発を進める上での、人を巻き込んでのアイデアのまとめ方や、利害関係者との意見のとりまとめや交渉の仕方など、人とからむ泥臭い部分も解説していて読んでいてなるほどと思いました。
ただ、淡々とした説明や知識習得といった場面もあるのでずっと読んでいて興味が出っぱなしというわけでなくて、ときどき読み飽きてくる場面もありますが、そういうフェーズを取り扱っているので致し方なしなのかなと思います。
本書を読むときの注意点｜添付資料が見づらいかも
オーディブルで聞きました。添付の資料はちゃんと入ってましたが資料番号が振ってなかったのでわかりにくかったです。（改善要望）本当に学習したい場合は自前で本も買った上で聞くのもよいかもです。
図表の参照が多いので、オーディブルは話の外観をつかんだうえで、活字の本で図表をしっかり見ながら読むとかです。
オーディブルという読んでくれる環境でしたので、この固い本でも結構興味深く聞くことができました。しかし、リアル本を読むとちょっと途中で投げ出したくなるかもです。そのうえでも、本書を本当に読むのであれば、オーディブル版と紙の本もしくは、kindleのような電子書籍と一緒に読むほうが良いかもしれません。
プロダクトは理念に立ち返る｜プロダクトマネージャーの仕事
プロダクトを作るとき、企業理念は何かを常に意識していることが印象に残りました。何かアプリケーションを作るときは、それはその企業が売り出す商品になることが多いです。そのため、何を作るかを決めるときに、その企業の企業理念までおさえてコンセプトを決めることが印象深かったです。
作るものを定義したとして、そこで何をかなえるか。そのかなえることがその企業のミッションに合致しているか。
目指す提供価値に合致しているかを常に意識しすることは大切である。
今後開発を進めていくうえで様々トラブルや方向性の選択など迫られるときに、その判断のよりどころとなる部分を意識づけることで正しい判断できるようになる。その動機づけをしっかりしておくことで、プロジェクトが迷子にならず進んでいくのだなと思いました。
様々な分析手法｜各章へ見に行こう
本書では、実例（シミュレーション用かわかりませんが）を交えて、こんなときどのような分析をするかが解説されていました。ただ、詳しい説明がないので、実際にどうするかは、その専門書の解説が必要なのかもしれません。
メンタルモデルダイヤグラムとカスタマージャーニー
本書を読んでいたら気になる2つの言葉が耳につきました。備忘録的に何かを書き記しておきます。
メンタルグラムダイヤグラム（プロダクトの体験が点）
カスタマージャーニー（時系列の設計）
上記の通りです。何のことだろう？になりますのでもう少し解説を加えると
メンタルモデルダイヤグラムは、アプリケーションの一つ一つについて、使いながら各インターフェイスに対してどうユーザーが反応をするかを考えます。
カスタマージャーニーは、そのアプリケーションを通してユーザーはどんな検索をして、どんな機能を試すかといったストーリーのようなものを仮定するようです。それをもとに最適なプロダクトを作るというのは新しい発見である。
KGI/KPIだけで目標管理をせずNSMもしっかり持とう
目標の達成のために、日本でも海外でもPDCAを回す中、KGIとKPIを作る。しかし、プロダクトを作成するには、NSMもしっかり設定しておこうということだ。※NSMとは、North Star Metricの略であり、羅針盤ともいえる目標でKGIより低く、KPIよりも高い目標のようである。
ちょうどKGI ⇔ NSM ⇔ KPIで
KGIの場合は、ゴールとなるので、お金で売り上げ〇〇万円となる。
一方でKPIはそのKGIの目標に対して、KPIに何を設定すればKGIに達するかという目標です。
しかし、プロダクトの場合、お金が最終目標でも、プロダクトの形というものがあります。North Star Metricという北極星を目指した状態で、KPIを達成することで目指す形でKGIを達成することができるという考えようです。
昨今、全ての開発技法がアジャイルになったわけではない
最近のスマホやウェブのアプリケーションの開発方法は、、アジャイル開発でないと無理というのは間違っているようです。
すでに仕様が固まっており、節目節目でしっかり押さえていくタイプのものは、たとえスマホアプリの開発であってもウォーターフォール開発の方が適しているようです。
一方、仮説検証でどんどん作って検証をくりかえるのなら、アジャイル開発の方がよいでしょう。
このようにプロジェクトがどんな風に進むかでも変わってくるようです。
トップダウンかボトムアップかは｜魂が入っている活動体がどちらにあるかで決まる
ITシステムを導入するとき、トップダウンかボトムアップかを議論することがあります。
トップダウンは上からコレをヤレー！と畳みかけるものですね。
トップダウンは上のビジョンを達成するために下の方に働きかけるので、強制力がある一方で、多くの場合下に行くほど業務量が増えるのでちょっと反感も呼びやすいです。
ボトムアップは改善などがあり、下から上に向かって改善していくパターンです。主に部分最適の状態が上の方に上がっていくので、部分最適同士の融合は難しくなるかもしれません。
となると、全体最適を考えるならトップダウンが良いと言われているけれど、トップが強い信念とリーダーシップをとってないと、上からの号令はすぐに発せられなくなるので失速してしまいます。
どこに推進力が経営側にあるのか、現場にあるのか、もしくは中間層にあるのかで、トップダウンか、ボトムアップか、中間層ならミドルアップダウンかを選んだ方が良いでしょう。
プロジェクト名を決めるとやる気スイッチが入る
プロジェクト名などを入れるとやる気スイッチが入るようです。例えばWindows95の開発コードはシカゴでした。
Windows XP はウィスラーでした。
そして、Windows Vista はロングホーンらしいです。
決め方はWindows XP はカナダのスキーリゾートの名前にして、Vistaは隣町のブラッコムというスキー場にしようとしていたようです。
開発の関係で、リリース時期は延びて延びて、その中間点のロングホーンというレストランになったようである。
でも、この開発コードによって携わる人々の士気が上がるので名前は重要なようです。
アジャイル開発には、スクラムとカンバンの2種類があるようだ
アジャイル開発とよく言うけど、手法としてはスクラムとカンバンの2種類があるようだ。違いが分かってないので、一度勉強しよっかな。
#3行日記 ：散歩がなかなか開始できない
お昼の散歩が10月になっても始められていません。それはまだ少し暑いからです。でも朝はだいぶ涼しいですね。もうちょっと涼しくなってからにします。なぜそんなに慎重かって、無理は禁物ということが最近あってですね。
またそれも、おいおい書いてみたいと思います。
#1年前 ：ブレーキとアクセルを間違えて焦ったようです
笑いごとではないですが、ブレーキとアクセルを踏み間違えたようです。ドキッとしましたが、事なきを得ました。油断していると健常者でも間違えることはあると思います。自分は大丈夫と思わず常に注意は怠らず、運転中は運転に集中が良さそうですね。当たり前のことですけど、改めて意識しなおすのも重要かと思いました。
最後まで読んでいただきありがとうございます。記事が気に入られたら、フォローやサポートをいただけると嬉しく思います。また、お気軽なコメントもお待ちしております。
いいなと思ったら応援しよう！
