スポンサーサイト

一定期間更新がないため広告を表示しています

- | - | -

製品開発力を読んだ

PO勉強会のメンバーで、夏休みの課題図書と題して各自なにか書籍を読むのはどうですか?ということになった。そこでぼくは
【増補版】製品開発力―自動車産業の「組織能力」と「競争力」の研究 を読んでみることにした。


以下はその読書メモになります。

驚いたことにこの書籍は英語版が1991年に出版され、日本語版は1993年に出版されているのであった。にもかかわらず、ぼくが常日頃直面しており、また2015年現在のウェブサービス界隈、スマホアプリ界隈で話題になっているようなことが、これでもかというぐらいに登場してくる。そのひとつが「ユーザー体験」ということば。いやほんとビックリ。
 
ユーザーは経験を積むことによって、製品の技術的な性能や表面的なデザインの特徴はもちろんのこと、もっと内面的なレベルにおける製品コンセプト全体のユーザー・ニーズに対する満足度に至るまで、製品のあらゆる側面において微妙な違いを敏感に感じとるようになってきた。(p23)

そうなんですよねー。スペックだけが差別化ポイントじゃないのだよな。
 

ーーーー ハンドルの反応、アクセルの感触、エンジンの音、風の音、ラジオ、ダッシュボードのきしみ、外の景色、他の車、歩行者、同乗者がこの車について話す声等々ーーーー を次から次へと受け取っていく。ユーザーは、これらのメッセージを解釈して、それぞれに意味を付加し、それが製品体験についての満足度、不満足度につながってくる。(p43)
数字じゃない。五感に訴えろってやつだ。
 
情報の枠組みにおいては、企業の最大の目的はユーザーとのコミュニケーションであると考えられる。モノとしての製品は、ユーザーに対して製品体験と企業のメッセージを伝達する単なるメディアにすぎない。(p44)
製品はメディアだというのは目から鱗もの。では何を伝えるのか。それがコンセプトなのだろう。
 
ユーザー体験のシミュレーションとしての製品開発(p45)
そのまま。
 
ユーザーのニーズを認識し、明確化することが容易な場合には、ユーザー体験をシミュレートする能力よりも、内部的な効率性、有効性が大きな役割を果たすかもしれない。他方、市場のニーズが予測しがたく、明確化することが困難な場合は、ユーザー体験をシミュレートする能力のいかんが企業の競争力を左右する。(p47)
変わっていかなきゃいけない。ところが効率などを伝えやすい数値にできる事柄で差別化し成功してきた場合には、それ自体が足かせになって変わっていくことができないのかもしれない。しかしどんな業界でも必ずユーザー体験にシフトする時がやってくるのだろう。
 
他方、ユーザーが、外観のデザイン、個性、ライフスタイルとの適合性といった、もっと微妙な製品の特徴、計画書や仕様書のなかで明確に表現することが困難な特徴に重点を置いて判断する場合には、フェース・ツー・フェースの打ち合わせや試作品がコミュニケーションのメディアとして重要性を増すこととなる。(p47)
試作品!つまりプロトタイプだ!
 
製品コンセプトは結局のところ、予測されたユーザー体験であり、ターゲットとなるユーザーを満足させることを期待して新製品が発信するメッセージの複合体である。(p49)
どんなメッセージを発しているのか、折にふれて確認していかなければ。
 
「製品の優秀性」は、基本となる機能的、技術的パフォーマンスよりももっと広い概念である。ある製品について経験を蓄積し、多様な角度からの微妙な違いに敏感になったユーザーは、製品の数多くの特色ーーーー たとえば、基本的機能、美的外観、ネーミング、信頼性、経済性 ーーーーが全体としてバランスよく備わっていることを求める。製品が全体としてこのバランスを有し、ユーザーを魅了し、満足させることのできる度合いが、製品の首尾一貫性を測る尺度と言えよう。(p53)
ユーザーは常に経験し変化している。
 
この、「アメリカ流のコンセプト」は、エネルギー価格が安く、長距離運転が多く、広くてまっすぐな道路網があり、「大きいこと」を評価する文化を持っているという土地柄を反映したと独特の製品体験に基づいてきたものである。(p61)
文化的背景を理解しないであの国で受け入れられているから同じ様なものをつくろうというのは必ずしも成功への近道ではない。
 
「昔はただ軽くつくるとか、安くつくるとか、エンジン何馬力だとか、開発目標としての数字が出たわけです。ところが、そんなものでお客さんは満足しなくなってきました。乗ってみるとあれは違うとか、口で言えない1つの切り口があるのです。数字でブレーキの距離がどうとか、加速がどうだということは同じだけれども、あの車が違うというのがあるんですよ。これこそ感性です。」(p88)
デジタルなものよりアナログな感性が試されている!
 
「生活の基礎的なものは、すべて満たされているいまの『豊かさのなかでの選択』の時代には、ヤングはいろいろのモノを所有するという豊かさではなく、自分の生活をどう演出するかという『新しい豊かさ』を求めている。このことは、ヤングが車を選択するとき単位価格が安いとか、品質や機能が優れているというだけで商品の価値を評価するのではなく、『都会的感覚』『ハイテク感覚』・・・等といったソフト的な価値が付加されていないと彼らに魅力のある商品とはならない」(p88)
iPhone に飛びつくのはそういうことだろう。
 
ある日本のメーカーでは、プロダクト・マネージャーはチーフ・エンジニアと同格の高い地位を与えられている。インフォーマルなレベルでも強いリーダーシップを発揮し、製造部門やマーケティング部門も含めた製品開発プロジェクト全体の調整を行う。必要があれば現場担当エンジニアにも直接影響を行使し、製品コンセプトや製品計画の決定権を持つ。そして、現場技術者、デザイナー、工場の監督者やディーラー、ユーザー等とのコミュニケーションのために、オフィスの外での活動に多くの時間を割く。彼らは、一般的に自分たちのことを、単なる調整者ではなく、製品開発プロジェクトの最高責任者である、社内企業家であると考えているである。(p135)
責任も大きいし守備範囲も広い。
 
製品の首尾一貫性ーーーー社内における各作業の内的一貫性および製品体験ユーザーの期待との外的一貫性ーーーーは製品開発のパフォーマンスの高さを示す証である。そして、製品の首尾一貫性を高め、市場への対応を迅速かつ効率的にするためには、各部門の一丸となった努力とリーダーシップが必要であり、メーカーがそうした条件を整えるには、経営陣の示す方向性と製品開発組織のあり方が重要な役割を果たすと考えられる。(p163)
ボトムアップとトップダウンの両方が必要。
 
試作車を製作するのが早いからといって、製品エンジニアとテスト・エンジニアが試作車製作のサイクルに組み込まれ、効果的にコミュニケーションをとることができなければ、大した価値は生まれない。(p245)
みんなで作る、チームで作ることを組織としてビルトインできているかどうかが重要。
 
「製品エンジニアと工程エンジニアの対立は、我々(工程エンジニア)が早い時点で製品コンセプトを見る機会があれば、より容易に解消することができる。そうでないと、我々は製造性ばかりを追求しがちである。もし、製品コンセプトを見ることができれば、『よし、売れる車をつくってやろう』とか『製造しやすいが売れない車はいらない』とか考えるきっかけになるのだ。」
共有だ。
 
問題が複雑になりすぎてわずかな人間で解決することができなくなり、競争が激しくなるにつれて高度の専門技術が要求されるようになって、製品開発に携わる人間の数も非常に多くなった。そして結局のところ自動車メーカーは古い古典的な組織のジレンマに直面した。つまり高度に分業した専門技術を用いて、どのように全体として調整のとれた作業が実施できるかということである。(p293)
まさにいまそれ!
 
しかしながら、ユーザーの満足は、個々の性能の高さとともに製品の首尾一貫性に影響される。したがって、ユーザーの要求を満たすということは分業化と統合との間で適切なバランスをとることなのである。(p319)
耳が痛い。
 
だが、車を解体してその部分部分を詳しく調べるだけでは、その車の本質はわからない。個々の部品を理解することは重要なことであるが、車に特色を与え、ユーザーにとって魅力的なものにするには、いかに部分同士が一体となって作動し、他とは違ったユーザー体験を与えるかという点が大事である。(p337)
分解すれば見えてくるものがあるという風潮には違和感を覚えている。
 
個々の重要要素ではなく、全体のパターンこそが他との違いを生み出すのである。(p338)
単独では強みになり得ないけど、全体になると強みになるということ。
 
1つの要素だけで迅速、効率的、高品質の製品開発を実現することはできない。(p350)
うぅぅぅ。
 
成功を収めるメーカーは、コンセプト創出、デザイン、エンジニアリング等の多くの異なった視点からの作業が互いにうまく協力して行われ、相互に強化しあうような組織及び管理手法のパターンをつくり上げている。(p355)
それぞれが他のそれぞれを強化していくこと。
 
どのようなやり方で実現するにせよ、製品の首尾一貫性は、製品開発の優れたパフォーマンスに不可欠の万国共通の要素である。(p357)
どのような製品であってもきっとそうなのだろう。
 
いずれも、少数の「成功のために不可欠な要素」にだけ優位性を発揮するというよりも、多くの重要な細部を注意深くバランスさせた点に特色がある。そして、はやりの技法を素早く取り入れるよりも、長期的な能力を重視して、その優位性を継続的なものにしている。(p357)
継続できないのには訳があるということか。
 
優れた製品開発パフォーマンスを実現するためのカギは、少数の重要要素というよりも、数多くのさまざまな要素から成る総合的なパターンに一貫性を持たせることである。(p357)
はい。
 
製品の特徴のもっと深いレベルで、その企業の製品全体に流れる共通のテーマ、機能や形状の細部の調査の取り方として表れるものである。したがって、それはマーケティングや装飾的技法にとどまらず、製品開発のプロセスおよび組織全体に関わる問題なのである。
ユーザーはそれを嗅ぎ分ける。
 
ユーザーは製品ラインの一貫性を製品のもっと深い部分で要求するようになってきており、アメリカのメーカーは、CIはもっと全体論的(ホリスティック)なアプローチーーーーつまり、部品、レイアウト、スタイリングをうまく調和させて各モデルに共通したコンセプトのテーマを持たせることーーーーでとらえるようにする必要があると考えられる。(p372)
これ、20年前の自動車業界の話だけど、今のインターネット界隈にもビンゴ。
 
将来の自動車エンジニアは、その技能と思考において、技術面と商業面とを合わせ持ち、ユーザーの期待と部品の詳細設計とを結びつける外的統合の推進者にもなるだろう。たとえば、従来型のトランスミッション・エンジニアは、数的な仕様と技術的計算を重視するが、次世代のトランスミッション・エンジニアは、たとえばユーザーがギア・シフトの感覚にどのように反応し、その製品の性格にはどれぐらいのギア比が適しているかといった、人間的要素、ユーザー・インターフェースも考慮に入れるようになる。(p389)
いま我々のいる業界だけではないし、もっとずっと前から自動車業かがそのようになっていたというのは驚きである。
 
要約すれば、将来のエンジニアは、ユーザーの声と部品の詳細部分、設計とテスト、エンジニアリングと製造、コンピュータと人間の判断、全体と部分、左脳と右脳を統合する技能を持たなければならない。(p389)
エンジニアと書かれているけれどデザイナも含まれるのであろうな。
 
優れた製品開発組織をつくることは、優れた製品をつくることと類似している。どちらも細部にわたる調和を必要とし、複雑かつ困難である。(p392)
製品開発と組織開発ということか。
 
すばらしい製品であることの証明は、首尾一貫性の存在である。(p396)
この言葉に魂撃ちぬかれた。
 
組織図をトップダウンにで大幅に変えても、実務レベルの細部の変化が伴わなければ、優れたパフォーマンスを実現することはできない。同様に、小さな実務チームにおいてチームワークを固め、士気を高めても、細部における作業のやり方、行動パターン、姿勢、組織構造、技能、経営哲学等に一貫性がなければ、全体の製品開発パフォーマンスを向上することはできない。何か1つの重要要素、ウルトラCの解決方法存在するわけではない。(p408)
ウルトラCを求めがちだ。ベストプラクティス依存症だ。気をつけなければ。

製品開発力を読み終えてぼくがやらなければならないと思ったこと

スペックを重視するのではなく、製品全体としてユーザーの気分をよくするための活動である。そしてそれができると他社は「スペックをあげれば競争に勝つことができる」と勘違いし、我々としては長期にわたって市場で優位に立ち続けることができるようになるであろう。なぜならユーザーが真に惹かれているのは、スペックではなく、使っていると気分がよくなるという製品体験であるからだ。もちろんスペックが重要であることは前提として存在するのだが。

がんばります。
PO/PM | comments(0) | -

監獄学園を18巻まで一気に読んでしまった

普段漫画を読むことはほとんどないのだけれど、漫画好きの同僚と席が近くになったのを機に、その方のおすすめの漫画を読んでみようかなという気になった。いくつかおすすめされたのだけど、監獄学園を読んでみることにした。なんでこれを選んだのかはよく覚えていない。たぶん、それなりに話題になっていたのと(ドラマが始まるみたいなのをニュースサイト経由で目にしていた)、すでに18巻まででているというボリューム感に惹かれたのだと思う。


 

読み終えた感想

早く19巻出てほしい!
くだらなくてバカバカしくていいねこれ。夜、読みながら1人で爆笑してしまった。実にくだらなくて、しかもそれがいたってまじめだからおもしろいのかな。

他にもおすすめの漫画を借りてみようと思った。
漫画 | comments(0) | -

そしてPO勉強会がはじまった

PO勉強会は、ランチタイムもしくは定時後に1時間という風に決めた。
調整さんなどで各自の予定を出して、なるべく多くの人が参加できる日程でという流れ。

勉強会では
  • 担当者が inspired の次の3章分を資料にまとめてくる。
  • こんなことが書いてありましたと発表する。(もちろん担当じゃなくてもみんな読んでくること前提)
  • 発表しながら、発表を聞きながら各自気になった点を質問。
  • ここ、弊社ではどーなのー?
  • そいういえばこんなことあんなことありました話。
のような感じですすんでいきます。

参加者が、エンジニア、デザイナ、ディレクタ、マネージャと職種も職位もバラバラでかつ事業部も別々であるため、いろんな視点の話ができて単純に社内の情報共有という点フォーカスしてみても、有意義な時間なのであります。

それにしても、毎回耳の痛い話ばかりでてくるのだけれど、そうおもっているのはぼくだけじゃないことがわかってホッとするとともに、「だからちゃんとしていこうね、ここにいるみんなで」という団結力が生まれるのもとてもいいなーと。みんな所属部署は違うけどチームで戦ってる感がすごく出ていてぼくはこの勉強会を愛してやまないのであります。

 
PO/PM | comments(0) | -

PO勉強会が始まったきっかけ

2015年のゴールデンウィーク明け頃から、社内の有志でPO勉強会(後に「POとPOじゃない人のための勉強会」に名称が変更された)なるものがスタートした。

きっかけは、ぼくが弊社基盤エンジニアの kenchan に声をかけたことだ。

声をかけた背景には次のようなことがあった。
  • とあるチームのPOを任されていたが、POとしてこれでよいのか悶々としていた
  • 弊社でスクラムを導入して3年くらい経っていた
  • SMについては社内に何人かモデルになる人がいた
  • 一方POについては「あれ?だれかモデルになるような人いたっけ?」という状態だった
  • もしかして他のPOも悶々としてるんじゃ?
  • もしかして弊社でスクラムというものがもう一歩成長するためにはPO力が不足しているかもと思い始めた
  • PO力高めたい
  • スクラムの経験が豊富な kenchan ならいろいろなタイプのPOと仕事をしているはず

ということを考えていたある日、別件でたまたま slack でトークがきた。ここぞとばかりに「PO力を高めたいのです、そのための勉強会などしたいです」という話をした。
そしたら「やりましょう!」という返事をいただき、slack でPOチャンネルまで作っていただいた。マジ感謝。

そしてあるプロジェクトでPOをやっている getsukikyu を invite した。
そこでまずは「Inspired: 顧客の心を捉える製品の創り方」を各自読みましょう、読んだら週一で集まってわいわいしながら読み直しましょうということになった。

これがゴールデンウィーク前のこと。

ゴールデンウィークがあけて、週一読書会の社内イベントをたてたところ、興味のある人が参加表明 & チャンネルに入り始めてきた。徐々に勢力が拡大し始めた感じ。

おおまかなながれはこうだったはず。
こうしてPO勉強会がスタートする準備が整ったのだった。
 
PO/PM | comments(0) | -