Inspired日本語版

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

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

この投稿の続きを読む

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

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

この投稿の続きを読む

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

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

この投稿の続きを読む

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

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

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

この投稿の続きを読む

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

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

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

この投稿の続きを読む

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

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

この投稿の続きを読む

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

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



この投稿の続きを読む

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

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

この投稿の続きを読む

第22章 プロトタイプの検証
製品のアイデアを実際のユーザーの前でテストする

これまでの章で、私が、ハイフィデリティプロトタイプをどう位置づけているかはわかってもらえただろう。ハイフィデリティプロトタイプというのは、作るべき製品を表現して説明するためのいちばん基本的な方法であって、従来の紙ベースの仕様書よりも、製品開発チームにとってははるかに役に立つものだ。でも、このメリットは、あくまでもおまけのようなものにすぎない。ハイフィデリティプロトタイプを作るいちばんの目的は、製品についての理解をより深めて、最終的には、製品のアイデアを実際のユーザーといっしょに試すことにある。これをあらかじめやらないと、製品がその目的を果たせるかどうかを確実に証明できるものがない状態のまま、そんな製品をエンジニアリング部門に何ヶ月もかけて作らせることになってしまうからである。

この投稿の続きを読む

第21章 製品仕様の検証
価値があって、使いやすくて、実現可能であるという確証を得る

ここまでのいくつかの章では、私が製品の検証作業などと呼んできたことについて説明してきた。製品の検証とは、製品仕様が、売れる商品となること間違いなし、との確証が得られている製品のプロフィールを描写しているのかどうかを検証することである。ただ、この検証では、実際にその製品を作り上げてユーザーに披露する、ということはやらない。

この投稿の続きを読む