Inspired日本語版

How To Create Products Customers Love

Kindle 版をリリースしました

お待たせしました! Inspired 日本語版の Kindle 版の準備ができました。Kindle がサポートするプラットフォームなら、どの環境でも Inspired 日本語版をお読みいただけます。

この機会に誤字脱字の修正、フォントや行間の調整なども行いましたので、さらに読みやすくなっています。ぜひ、目を通していただけるとうれしいです。

この書籍に対するコメント、ご質問などがあれば、いつでもご連絡ください。

Inspired 日本語版 発売!

長い間お待たせしましたが、先週、Inspired 日本語版をリリースしました。iOSデバイスをお持ちの方は、iTunes App Store にて購入いただけます。いろいろな議論はありましたが、製品開発の際にいつでも参照いただけるように、携帯アプリの形でお届けすることにいたしました。その他のプラットフォームにつきましても、順次、サポートして参ります。現在、Android、および、Kindle版を検討しております。

時間をいただいた分、翻訳には十分な時間を使い、完成度の高いものになったと自負しております。しかし、誤り、誤字、脱字等がありましたら、ご一報いただけますと幸いです。次以降のバージョンにて修正をして参ります。

皆様からのフィードバックを運営者一同、お待ちしております。

第30章 大きい会社で賢く立ち回るには

第30章 大きい会社で賢く立ち回るには
10のテクニック

私がこれまで仕事を手伝ってきた会社には、かなり規模が大きいところもたくさんあって、こういう会社の数多くの製品開発のリーダーからよく尋ねられたものだ。「大きな会社で物事を動かすにはどうすればいいのか?」 私自身も、いくつか大きな会社に勤めたことがある。それは確かに楽ではないけれど、大きい会社の豊富な人材を活用するコツを心得ている人にとっては、製品開発ではかなりのメリットになると思う。

この投稿の続きを読む

第29章 大きい会社でもイノベーションは不可能ではない

第29章 大きい会社でもイノベーションは不可能ではない
困難だが努力する価値はある

大きい会社で本当にイノベーション (革新) を起こすことができるのかどうかについては、皮肉な見方をする人が多い。本当のイノベーションというのは、ほとんどがベンチャー企業のような環境で起こっていて、大きい会社にできるのは、せいぜいそうしたベンチャー企業のイノベーションを真似するか、成功したベンチャー企業を買収するぐらいだ、と考える人もいる。確かに、イノベーションを起こすのはベンチャー企業の方がはるかにやりやすいのは認めるけれど、大きな会社でも、まず間違いなくイノベーションは可能である。

この投稿の続きを読む

第28 ベンチャー企業のプロダクトマネジメント

第28章 ベンチャー企業のプロダクトマネジメント
とにかく製品を見つけ出すことに尽きる

私は、この何年かで、かなりの数のベンチャー企業と仕事をしてきた。たいていはアドバイザーの立場だったが、もっと直接的に関わった仕事もある。ベンチャービジネスというのは、本来、新しい製品を創り出すことに尽きるので、プロダクトマネージャーが仕事をするにはもってこいの場である。だから、私は、ベンチャーで仕事をするのが大好きなのだ。でも、一般にベンチャーが最初の製品を創り出すやり方は、えらく非効率だと思う。そのために、いいアイデアだったはずのものの多くが、開発資金を得ることができなかったり、製品化までこぎ着けることができなかったりしている。

この投稿の続きを読む

第27章 ウォーターフォールプロセスを使いこなす

第27章 ウォーターフォールプロセスを使いこなす
先回りして手を打つ

この章では、大多数の製品開発チームが今もなお踏襲しているウォーターフォールプロセスについて見ていこう。

ウォーターフォールプロセスは、誕生してから30年以上経っていて、私も含め、エンジニアからもプロダクトマネージャーからもしょっちゅうこき下ろされているものだというのに、今でもソフトウェア製品を作るためにいちばんよく使われている手法である。

この投稿の続きを読む

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

第26章 アジャイル開発手法を使いこなす
10のテクニック

多くのソフトウェア製品開発チームが、現在アジャイル開発手法を試しているか、あるいは、つい最近アジャイル開発手法のどれかを導入したばかり、という状況にある。スクラムにしろ、XP (eXtreme Programming) にしろ、アジャイル開発手法には多くのメリットがあるのだけれど、そもそもカスタムソフトウェアの開発のために考案された手法なので、最初のうちは、製品ソフトウェアの開発に応用するにはどうするのがいちばんいいのか、と四苦八苦するチームも多い。

この章では、製品ソフトウェアの開発環境でアジャイル開発手法を使いこなすためのポイントを明らかにしよう。

この投稿の続きを読む

第25章 迅速な対応

第25章 迅速な対応
開発を始めたら最後まで手を抜かない、そしてリリースサイクル全体を守る

他の章では、製品の発売にこぎ着けることを成功と勘違いしてしまうという落とし穴のことや、製品やサービスの発売後も手を抜かないことがいかに重要かについて議論してきた。第25章では、この発売直後という製品開発プロジェクトの重大な局面で何をするべきかについて、詳しく見ていこう。

この投稿の続きを読む

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

第24章 ユーザーにやさしい緩やかなバージョン移行
ユーザーに苦痛を与えないために

「ユーザーに苦痛を与える」というのは、製品のユーザーに対してユーザーが歓迎しない変更をリリースすることで、意図せずに (だといいのだけれど) 無用な負担をユーザーにかけてしまうことだ。ユーザー全員が製品の変更を歓迎してくれるわけではないとは信じたくないかもしれないが、それが現実である。ユーザーがそう感じる理由はいくつかある。



この投稿の続きを読む

第23章 現在の製品を改善する

第23章 現在の製品を改善する
改善とは機能を追加することではない

できあがってしまった製品の開発を続けるという話になると、多くのプロダクトマネージャーは、何をすればいいのかわからないでいる。たいていは、詳細な製品ロードマップがあって、そこには、製品開発チームが追加したいと思っているあらゆる機能のすばらしいアイデアが示されている。あるいは、ロードマップには、特定の顧客からの「もしこの製品を買ってほしいなら、次の 6つの機能を追加してもらいたい・・・」というような要求で埋め尽くされている。

この投稿の続きを読む

%d人のブロガーが「いいね」をつけました。