読者です 読者をやめる 読者になる 読者になる

valid,invalid

関心を持てる事柄について

『Inspired: 顧客の心を捉える製品の創り方』読んだ

Product

マーティ・ケイガン の『Inspired: 顧客の心を捉える製品の創り方』を読んだ。

この本は社内の日報・ポエム置き場のようなレポジトリで CTO が紹介していて、その場で購入したのだけれどずっと kindle 内に積んだままになっていた。

うーん、これは、もっと早く読むべきだった。

内容

いわゆるプロダクト開発・マネジメントのベストプラクティス集。

Hewlett-Packard、NetscapeeBay など名だたる企業でプロダクトマネージャーとして働いてきた著者の経験だけでなく、知人友人その他あらゆる人脈から収集したテクニックがあますところなく紹介されていて、とにかく凝集度が高い。

219ページしかないらしいのだが、毎ページ進むたびにハイライトしたくなる(傍線を引きたくなる)。

顧客向け(BtoC)のソフトウェアプロダクトが中心だが、企業向け(BtoB)ソフトウェアに関するテクニックも多く紹介されている。ソフトウェアに限らない話も多い。

感想

これまでソフトウェア開発で経験してきて知っていること、わかったつもりで誤解していたこと、解決の仕方がわからなかったこと、ぼんやりと考えてはいたが言語化できていなかったことがことごとく語られていて、うーん、これは、もっと早く読むべきだった(2回目)。

現職の周囲の人々に限らず、世の中にはこれを読んで欲しい人がたくさんいる。

そして、あまりにも多くのことがこの1冊でまとめられているので個々の話題に触れていくとまったく語り終わる気がしない。

製品(プロダクト)と感情

特に印象に残った、製品と感情の関係について。同書では第34章で語られていた。

サイエンスやビジネスのバックグラウンドを持つ我々が最も真剣に向き合わなければならないので人間の感情だった、という皮肉ぽい話でぞくっとした。

人々は、ふつうは、感情的な理由で製品を買って、製品を使う。

これについては経験から思うところがあったので別の記事を今度書いてみたい。

欠点

本当に良い本なのでこれを殊更取り上げて言うほどのことなのかわからないけど、脱字が多かった。

あまりにも多く感じたので途中から見つけた脱字はすべてハイライトした。Amazon に報告すればクーポンがもらえるのだろうか。

Highlited

ハイライトした箇所の抜き出し。

Inspired: Kokyaku No Kokoro O Toraeru Seihin No Tsukurikata (Japanese Edition)
by Marty Cagan

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

Read more at location 179


ソフトウェア開発の組織には、プロダクトマネージャーとデザイナーとエンジニアの人数について、適正な割合があることがわかっている。

Read more at location 240


ダメな製品が無駄に世に送り出されるいちばんの原因は、ほとんどの場合、会社の中でプロダクトマネージャーの役割が明確にされていないことと、プロダクトマネージャーとなる人に対する教育が不十分なことにある。

Read more at location 259


プロダクトマネージャーの役割は、エンジニアリングチームが作り上げるべき製品を詳細に定義することである。これに対して、プロダクトマーケティングの役割は、世界に対して製品を語ることである。この 2つはまったく違う仕事である。

Read more at location 264


プロダクトマネージャーの役割は、作りたい製品のプロフィールを細かいところまで決めることと、実際の顧客やユーザーとともに製品を検証することである。

Read more at location 327


担当者の肩書きや社内の組織体系がどうあれ、あらゆる優れた製品の陰には、責任を持ってその製品のプロフィールを決めた 1人の人間がいる、と私は断言する。

Read more at location 340


プロダクトマネジメントの役割が、価値のある、使いやすい、実現可能な製品を見つけ出すことにあるのに対して、プロジェクトマネジメントの役割は、製品を市場に送り出すことに尽きるからだ。

Read more at location 385


企業向けのサービスである場合は、ライバルに差をつけるいちばんの近道の 1つが、ユーザーエクスペリエンスをよくすることである。一般的に、多くの企業向けの製品では、ユーザーエクスペリエンスがかなりおろそかにされているからだ。

Read more at location 483


製品を必要最小限までそぎ落とすことに集中すること。後でもっと詳しく説明するが、ともかく、プロダクトマネージャーの仕事は、究極の製品を定義することではなく、目的を達成するために必要最小限までそぎ落とされた製品を定義することである。

Read more at location 544


開発チームと離れていればいるほど、また、言葉や文化や時差のためにコミュニケーション上の課題が大きければ大きいほど、製品仕様を決める段階でしっかり完璧に作業しておく必要性に、いっそう強く迫られることになる。プロジェクトとして最悪なのは、プロダクトマネージャーが何を作りたいのかよくわかっていない (あるいは、コロコロ考えを変える) ために、離れた所で作業しているチームがもがき苦しむことだ。

Read more at location 573


プロダクトマネージャーは、エンジニアリングチームのキャパシティ全体の 20% を空けておいて、これをエンジニアリングチームの判断で使える予備の枠として与える。エンジニアリングチームは、たとえば、コードを書き直したり、アーキテクチャーをやり直したり、コードのダメなところをリファクタリングしたり、データベースのシステムを入れ換えたり、システムのパフォーマンスを改善したり、といった作業のためにこの枠を使うことができる。つまり、「開発を中断してコードを書き直さなければだめだ」と言い出す事態を避けるために必要だと思うことであれば、何でもである。

Read more at location 674


eBay は瀕死の状態を経験してからは、二度と危機的な状況に陥ることがないような体制をしっかり整えた。問題が深刻になる前に、さっさとコードの書き直しを始めるようにしたのだ。実際のところ、eBay は、サービスが急成長する中で 3回もコードを書き直して、3回目のときはサイト全体を別のプログラミング言語アーキテクチャーに置き換えた。彼らは、この何百万行もの膨大な量のコードを数年かけて書き直し、同時に、記録的な数の新しい機能も追加した。そして、何よりも、ユーザーに不自由な思いをさせることなく、こうした作業をやってのけたのだ。

Read more at location 697


長い時間をかけて 1つの領域に精通してしまうと、プロダクトマネジメントのもう 1つのワナに落ちてしまうことがある。それは、自分がターゲットである顧客を代弁する人間で、実際以上に自分がターゲットである顧客に近い存在だと思い込むようになるのだ。プロダクトマネージャーというものは、自分の担当する分野や顧客について自分が考えていることを、絶えず問い直さなければならない。

Read more at location 925


最近、ビジネスにおける新たな測定基準が、多くの業界で注目を集めている。ネットプロモータースコア (NPS)

Read more at location 1077


特注品 (特定の顧客向けの製品のことで、だいたいは、製品の購入を確約してもらう見返りとして、特別仕様の仕事を引き受ける) に走るのはかなり危険だ。これは悪い売上の典型であり、会社がユーザーを幸せにする製品を作り出す力をダメにする。

Read more at location 1103


私が仕事をした会社でいちばん多かったのは、マーケティング部門の中にプロダクトマネジメントがあるパターンだ。この組織体系でまずいのは、製品は顧客と話すことから生まれるもので、そのために顧客と話すのはマーケティング部門の仕事だ、という間違った考え方に基づいている点だ。

Read more at location 1114


「どうやるかを指示してはならない。何をすべきかを指示すればいい。そうすれば、彼らの創意工夫に驚かされるだろう。」

Read more at location 1159


現実には、顧客やユーザーが何かいい解決策を思いつけるわけではない。彼らには、そもそも何ができるのかなどわからないのだから、どうやって解決するかを前もって想像するのはかなり難しいだろう。

Read more at location 1168


デザイナーというのは、製品開発のうんと早い段階、つまり、プロダクトマネージャーがターゲットとなる市場を把握してソリューションを考えている段階から参加してこそ、その真価を発揮できるのだ。

Read more at location 1179


この会社のせ製品は、

Read more at location 1247


効果的な製品の市場性評価をやるのは、それほど難しいことではない。私のやり方では、プロダクトマネージャーに、10個の基本的な質問に答えてもらうことにしている。 製品化によって具体的にどんな問題を解決するのか? (バリュープロポジション) だれのためにこの問題を解決しようとしているのか? (ターゲット市場) 市場の大きさは? (市場規模) 製品化の成功をどうやって評価するのか? (指標、収益戦略) 現在、他に競合する製品はあるか? (競合の見通し) なぜ当社がこの製品化をやるのに最適なプレーヤーと言えるのか? (差別化要因) なぜ今なのか? (市場投入の時期) どうやって製品を市場に出すのか? (市場投入戦略) 成功のために絶対に必要な要素は何か? (ソリューションの要件) これらを前提とした上で、最終的な提案は何か?(やるかやらないか)

Read more at location 1392


最善のもの実施させるよう

Read more at location 1447


製品となるどうかは、

Read more at location 1519


見つけられるどう

Read more at location 1520


並行して 2つのバージョンで作業を進めることである。つまり、バージョン1 のエンジニアリングが始まって、プロジェクトが実行段階に入ったら、すぐにバージョン2 の発案作業も開始する。新しいアイデアを生み出す努力は決して絶やさないようにするのだ。あるバージョンがエンジニアリングの段階に入ったら、発案力は次のバージョンに振り向けよう。

Read more at location 1542


製品を見つけ出す段階というのは、あっさりクリアできてしまうこともあれば、ものすごく難しい場合もある。私の経験では、市場性がありそうなところを見つけ出して評価するのはそれほど難しくはないけれど、ソリューションを見つけ出すのに困難を極めることが多い。

Read more at location 1585


社員の多くは、本当はそうではないのに、自分のことを製品のターゲットであるユーザーに近い存在と考えている (あるいは、ターゲットユーザーのことを実際以上に理解しているつもりになっている)。

Read more at location 1675


経営陣は開発プロジェクトのうんと早いうちからコストについて知りたがるけれど、ある程度正確な見積りをするのに必要な情報をエンジニアリングチームが手に入れるのは、開発プロジェクトのずっと後になってからだ、ということにある (なぜなら、それまでは、必要とされるソリューションについてのまともな情報がほとんどないからである)。

Read more at location 1791


ターゲットとする顧客をしっかり理解することと、製品の発売までに確実なリファレンスカスタマーを確保しておくこと、この 2つの課題に取り組むために私がお勧めするのは、ユーザーモニター制度 (charter user program) を利用することだ。

Read more at location 1846


モニターは、間違いなくターゲット市場からの顧客やユーザーでなければならない。よく、アーリーアダプター (初期採用者) が集まってしまった、ということになりやすいものだ。こういう人々は、本来あるべきモニターよりもずっと寛容なので、結局はアーリーアダプターしか興味を持ってくれない製品になりかねない

Read more at location 1887


プロダクトマネージャーは、ユーザーとの面談、ユーザビリティテスト、ユーザーモニター制度での打合せなど、自分が担当する製品に直接関係のあるものなら何であっても出席するべきだ、

Read more at location 1943


すばらしい製品を発見するために必要な洞察力を得ること、それは、ユーザーとなる人々を十分に理解できるようになって、それぞれが根底に抱えているニーズを掘り起こすことから始まる。そういう洞察力は、「このページをカスタマイズして、1人当たりの作業時間を表示したレポートを出す必要がある」とか、「ユーザーの 72% がもっと解像度の高いビデオがいい、と言っていた」、というような表面的な会話からでは得られないだろう。

Read more at location 1945


ユーザーの一部には、目指すべき製品のプロフィールに仕立てていくとか、ユーザーとして示してくれる洞察力のレベルとかいった点で、他のユーザーよりもずっと優秀な人がいる。そういう人たちとは、継続的な関係を作っていこう。

Read more at location 1957


顧客アンケートで得られるデータは、解決策そのものを示すものではなく、解決策にたどり着くためのインプットの一部でしかない、

Read more at location 1986


どんな製品でも少しぐらいはいいところがあるもので、それを見つけるのがみなさんの仕事である。ライバルの製品のいいところや誤りを教訓にしよう。

Read more at location 2019


市場調査による情報は、製品を創造するプロセスへのインプットの一部とはなるけれど、市場調査で製品の方向性を決めようとすると、問題を抱えることとなる。

Read more at location 2028


何が必要のかを

Read more at location 2053


アラン・クーパー (Alan Cooper) の「コンピュータは、むずかしすぎて使えない!」(山形浩生訳、原題は The Inmates are Running the Asylum)

Read more at location 2080


あらゆる人々を満足させる製品にしようというのは、実によくある間違いであり、結局はだれも満足させることができない。

Read more at location 2114


製品開発チームがいちばんよくやってしまう間違いとしては、自分たちを顧客と混同するというのも挙げられる。私がとにかくペルソナを気に入っているのは、よくありがちなこの問題に光を当てるのに役立つからだ。

Read more at location 2116


ハイファイプロトタイプは、ここで挙げた条件に合っていることに加えて、紙ベースの仕様書と違ってテストできるところが最大のメリットだと思う。実際のターゲットユーザーの前に置いて、使い方がわかりやすいかどうか (ユーザビリティ) を確認することができるし、ユーザーが使いたいと思うかどうか (バリュー) も判定できる。プロトタイプがこの 2つのテストをパスするまでは、エンジニアに渡す意味のある製品仕様にはなっていない、ということだ。

Read more at location 2208


いいプロタイプ作成

Read more at location 2440


ユーザーが何を言うかではなく、何をするか、もっと注意して観察してほしい。

Read more at location 2618


製品化によって解決しようとしている問題に対して興味を示してくれる人がなかなか集まらない、あるいは、どうすれば製品をわかりやすく使いやすいものにしてターゲットユーザーに価値を認めてもらえるのか、どうしてもわからない、という判断になることがあるかもしれない。そんな時は、そこで中止して、アイデアを棚上げしよう。

Read more at location 2663


機能を追加することは、結果的に状況を悪くするだけで、何の改善にもならないことがあまりにも多い。

Read more at location 2691


製品の改善は、新しく製品を開発する場合と同じように、何を達成しようとしているのかをよく理解するところからすべてが始まる。

Read more at location 2693


一部の顧客が追加を望んでいる機能であるとか、調査結果だからとか、フォーカスグループがそう言っている、というような話ではないことを忘れないでほしい。大切なのは、製品の出来を表す数値を狙った方向に動かしてくれるのは何であるか、ということだ。

Read more at location 2715


スクラムにしろ、XP (eXtreme Programming) にしろ、アジャイル開発手法には多くのメリットがあるのだけれど、そもそもカスタムソフトウェア (個別の顧客の要求に基づいて作られる特注のソフトウェア) の開発のために考案された手法

Read more at location 2836


プロダクトマネージャーは、プロダクトオーナー (訳注:直訳すると、製品の発注者、すなわち、製品開発プロジェクトの施工主の意) であり、その製品の顧客を代弁する立場にある。

Read more at location 2843


アジャイル開発手法というのは、もともとカスタムソフトウェアの世界で生まれたということだ。 特定の顧客のために特定の目的のソフトを作るというカスタムソフトウェアの世界では、ひどく厄介な作業を強いられてきた。その理由の 1つは、顧客は、自分では何が必要なのかをわかっていないのに、何かが必要だからということで、とりあえずカスタムソフトウェアを作る会社に発注したり、社内の IT部門に依頼を出したりするためだ。

Read more at location 2928


カスタムソフトウェアを開発する会社は、トップクラスのソフトウェア開発者を採用して抱えておくことに関しては、ずっと貧乏くじを引かされてきている。

Read more at location 2936


歴史的には、カスタムソフトウェアの世界ではウォーターフォールプロセスが採用されているけれど、それは、開発を委託されたアプリケーションが作られていく長いプロセスにおいて、さまざまな関係者がその進み具合を監視する方法が必要だったからである。実際、ウォーターフォール型開発手法もまた、このニーズから始まったものである。

Read more at location 2957


大規模で複雑なソフトウェア開発プロジェクトですら、かなり正確なスケジュールを作ることは可能だ。ただ、これは、完全かつ正確に要求仕様と必要な技術を理解していること、そして、仕様の変更が発生しないことを前提としている。

Read more at location 3014


多くの点で、ウォーターフォールプロセスは、理想的ではあるけれどおめでたいとしか言いようがない考え方を象徴している。それは、人は、すべての主要な問題を予測することができて、要求仕様を完璧に理解できる、ということだ。もしそういう状況なのであれば (普通はうんと小さいプロジェクトに限られるけれど)、ウォーターフォールを使ったアプローチは、品質の高い実装を可能にする合理的な方法となり得るだろう。

Read more at location 3051


製品ソフトウェアでは、そういうことはめったに起こらない。実際にどうなるかというと、仕様の変更のために製品は計画より遅れて発売され、いったん現実のユーザーがそのソフトを目にして使い始めると、問題を修正するために、費用と時間をかけて追加のリリースをやらなければならなくなる。

Read more at location 3055


プロダクトマネージャーなって、

Read more at location 3073


どんなベンチャー企業であっても、すべては正しい製品から始まるということを認識する必要がある。だから、順番として最初にやるべきことは、50万ドルやらの創業資金を使い果たしてしまう前に、何が正しい製品であるのかをまず理解することなのである。

Read more at location 3107


大きい会社でのイノベーションを可能とするかどうかを左右する最大の要因は、企業文化と上司の 2つである。

Read more at location 3127


多くの場合、最高のアイデアというのは下から上がってくるものだ。20%ルールのすごいところは、数多くのアイデアを試すことができることにある。自分がアイデアを思い付いたという自負心があるので、そのアイデアはより強い熱意と創造力で追求されるのである。

Read more at location 3139


スカンクワークス (skunk works) というのはずいぶん古い業界用語で、もともとは秘密の軍事プロジェクトを指す言葉だった。今では、社内の官僚主義に邪魔されないように、他の人に気づかれないようにしながら、必要であれば個人の時間も使ってアイデアを追いかける、という意味で使われる。

Read more at location 3146


正式な業務きちんと

Read more at location 3151


覚えておいてほしいのは、イノベーションがまったく新しい問題を解決してくれることはめったにない、ということだ。ほとんどの場合、イノベーションとは、今ある問題を新しいやり方で解決することなのである。人々が今のソリューションに手を焼いているのを観察するのは、イノベーションのチャンスを浮かび上がらせるには最高の方法なのである。

Read more at location 3172


いっしょこのアイデア

Read more at location 3249


私の友人であるデービット・ウェイデン (David Weiden) の言葉は、大企業で働く多くの人がどんな状況に置かれていてどんなチャンスに恵まれているかを的確に言い表している。「多くの人は、暗闇の中をさまよい、 暗い暗いと文句ばかり言っていて、どこにスイッチがあるのを知ろうとしない。」

Read more at location 3309


他のどのハードウェア企業とも違って、アップルは、ハードウェアの役割はソフトウェアを支えることであり、その逆ではない、ということを理解している。

Read more at location 3328


もしアップルが技術系の会社として何か秘伝のソースを持っているとすれば、それは、こういうことだと思う。消費者が製品を欲しくなるとき、製品を手に入れるとき、製品に惚れ込むときに感情が果たす役割というものを、アップルは他のだれよりもよく理解しているのだ。アップルは、どうやって消費者の感情に語りかける製品を作るかを心得ている。

Read more at location 3347


特別仕様の何が悪いのだろうか? 製品を作る会社は、顧客の要求をあるべき製品要求と取り違えることで、まず間違いなく道を踏み外す。

Read more at location 3372


なぜ顧客を当てにすることができないかを説明してきた。その理由をここでおさらいしよう。第一に、顧客にとっては、実際にそのものを目にするまでは、自分が何を必要としているのかを理解するのはとても難しい。第二に、顧客は、どんな技術が可能であるかを知らない。第三に、共通のテーマを確認するために顧客同士が交流することはめったにない。

Read more at location 3375


次なる新しい目玉は何か、と思いを巡らせるのは、いつだって楽しいことだけれど、その目玉は、まったくの新しいものというよりは、むしろ、古いものの新たな生まれ変わりである。何が違うのかというと、新しく生まれ変わった製品は、以前の製品よりもずっといい、ずっと速い、あるいは、ずっと安いので、その製品ジャンルに変革を迫ることになるのだ。

Read more at location 3440


ユーザーを手こずらせる製品がある限り、他のだれかがそれを改良するチャンスがある。

Read more at location 3466


可能なことはいつも変化している。今日実現できないからといって、明日もムリとは限らない。

Read more at location 3468


今日のアプリケーションは、明日のインフラである。この世界のビジネスは、そうやって成り立っている。

Read more at location 3469


いいビジネスチャンスが完全になくなってしまうなんて、あり得ない。

Read more at location 3474


人々は、ふつうは、感情的な理由で製品を買って、製品を使う。優秀なマーケティング担当者は、このことを理解しているし、優秀な製品開発担当者は、製品を人々の感情に訴えかけるようにしようとする。

Read more at location 3479


感情というレンズを通して見れば、ユーザーや顧客が製品やサービスのことを、さらには潜在的な競争相手のことをどう見ているのかという視点にもっと近づいて、物事を見ることができるようになってくる。顧客は、他にはどこに行けばこういう欲求を満足させることができるのか? こういう感情により直接的に訴えかけるには、ビジュアルデザインはどうすればいいか? こういう感情にわかりやすく訴えかけることを邪魔している機能は何なのか?

Read more at location 3488


ベンチャー企業キャズムに陥ってしまう理由の 1つは、状況を見誤るから、つまり、「合理性より感性タイプ」と「テクノロジー大好きタイプ」を混同してしまうからなのです。

Read more at location 3574


プロダクトマネージャーには何を探し求めるように指導していますか? J:怒り、憤慨、不満を探せ、と。ぼくらが嫌いになってしまうようなありとあらゆるもの、電話会社、銀行、消費者金融会社、税務署の職員、官僚、航空会社、医療機関などを見れば、こういうものはみんなイノベーションの絶好のチャンスです。なぜなら、消費者の潜在的な不満がものすごく高いからです。

Read more at location 3587


ぼくたちが問うのは、「どんな感情が行動を駆り立てるのか?」ということです。そして、こういう感情を、製品の機能やそのほかのすべてのものに利用する方法を探します。それぞれのプロジェクトでは、どんな基本的な感情に訴えるのか、そして、ユーザーの苦しみがどれほど深刻なのかを評価します。

Read more at location 3618


ぼくが使うテクニックに、「フレッシュマンテスト」と呼んでいるものがあります。高校に入った最初の日を思い出してください。その日、人生のどんな日よりも、人間の弱さという感情を強く感じたでしょう。自分がちっぽけで、すっかり委縮してしまって、前の学校での実績はすっかり洗い流され、自分は何者でもない。そう、自分が何者でもない、ということを思い知るんです。 すべての人間が日々感じているこうした感情、たとえば、孤独、不安、怖れ、不満、怒りなど、あの高校一年生の時に感じたような気持ち、こうしたもののどれか 1つでもうまく利用できれば、そのプロジェクトは正しい方向に向かっていくでしょう。

Read more at location 3621


多くの製品開発チームは、製品やサイトにとってビジュアルデザインが本当に重要だ、とは感じていない。そういうチームは、大切なのは機能やバリュープロポジション (顧客に提供する価値) であって、きれいな色、フォント、アイコン、レイアウトのようなものは、ムダでうわべだけのくだらないことだ、と主張する。私は、この考え方にはまったく賛成できない。私は、数多くの製品を見るにつけて、ワクワクするような製品では感情が一定の役割を果たしていて、その感情を生み出すのに直接影響を与えているのはビジュアルデザインだ、とますます強く確信するようになっている。

Read more at location 3648


個人向けインターネットサービスでは、ユーザビリティは避けて通れない。個人向けインターネットサービスというのは、ユーザーエクスペリエンスに尽きるからだ。ターゲットユーザーにとって使い方がわかり

Read more at location 3676


ユーザビリティでは、パフォーマンスも大きな要素であることも覚えておこう。ウェブページを読み込むのに時間がかかりすぎると、ユーザーは壊れていると思うか、嫌な思いをしたということでどこか別のサービスに行ってしまうだろう。

Read more at location 3680


個人向けのサービスを提供している会社が出くわすサプライズの中でも、最大の (そしていちばん不愉快な) ものの 1つが、顧客サポートに関することだ。最高のサービスを提供している会社ですら、従来からの顧客サポートでは、たちまち破綻まで追い込まれる可能性がある。

Read more at location 3704


顧客サポートの費用をなんとしても最小限に抑えるような製品を設計して構築する以外、選択の余地はない。

Read more at location 3708


いい製品であれば、ユーザーは、自分の経験を友だちや家族や同僚と共有したいと思うだろう。それこそが、製品を提供する側が望んでいることだ。これはいちばん強力なマーケティング手法だ

Read more at location 3719


すべての会社は顧客に依存しているけれど、個人向けインターネットサービスを提供している会社にとっては、このユーザーコミュニティがいっそうの影響力と重みを帯びてくる。

Read more at location 3744


たくさんの顧客に会って、その声に耳を傾けることは絶対にやるべきだ。ただ、顧客に製品要求を決める能力があると期待してはいけない。

Read more at location 3808