日本発のGAFAを作るのに必要なのは、POではなく“PM”　海外のリーン開発者がこぞって学ぶトヨタの製品開発

グローバル・ピープル・ソリューションズの酒井崇男氏によるLTがスタート

酒井崇男氏：皆さんはじめまして、酒井崇男と申します。みなさんがこれまでどういうかたちでPO（プロダクトオーナー）とかPM（プロダクトマネージャー）というポジションに就かれたのかはわからないのですが、一般的にこの界隈の話は「また海外から来ている話じゃないかな」と理解されていると思うのです。

ところが、実はこのあたり、つまりPO／PMの先祖は日本にありまして。私はこの業界では、世界的によく知られています。本日のこのお題の話は、実は世界的にも、最重要なのだけど最難関とされている領域の議論なんですよね。今日はせっかくなのでみなさんにこのあたりのお話をしてみようか、ということです。

今年4月にフランスにおりまして、観光もしたのですが、一応仕事で出かけていきまして。（スライドを指して）この「リーン開発会議」でオープニング基調講演と「トヨタ製品開発」というワークショップを、ヨーロッパ人のこの界隈の人向けにやってきました。ちなみにリーンというのは、「トヨタ流」という意味ですね。内容はこの2冊の本に基づいたものをお話ししています。

この1冊目（「タレント」の時代）が、実は、「人間系」のおもしろい話なのです。でこれが、我々的にはいわゆる「最終問題」とされていたところ。これがうまく説明されていなかったので、分かる人たちにとっては、本当におもしろい本なのです。で各分野の一流というかすごい人たちで、書いてあることが分かると小躍りしてしまう方たちがけっこうおられるという、コアなファンが多い本です。

「トヨタの製品開発」が、日本ではまったく知られていなかったという事実

しかし、この本は部数的にはさっぱり売れなかったのですね。なぜなら、1冊目の本の議論の前提が、そもそも世間で一切知られていなかったのですよね。つまり、「トヨタの製品開発」が、とくに日本ではまったく知られていなかった。

そこで、次のこの2冊目の本を書いたわけです。1冊目の本を出した後、2冊目（『トヨタの強さの秘密』）を再編集して書いたら、よく売れまして。あれよあれよと世界で有名になりました。英語版もこの4月に出版されていて、海外のリーン業界の人たちがだいたいみんな読んでは勉強されています。

みなさんとは、まず、ここで接点があると思います。Scrum, Inc.さんがやっている「Scrum＠Scale」というイベントで、ジェフ・サザーランドが私の本を取り上げています。

実は、このあたりの話の先祖はトヨタなんですよね。（スライドを指して）こんな感じですね。ただ、ジェフ・サザーランドと息子のJJサザーランドの理解がまったく十分ではないということで、ちょっと問題になっていまして。本当は採点すると×なのですが、彼らも一生懸命頑張っておられるようですし、気持ち的にスライドでは△にしてあります。

今日、大量の情報を詰め込んできましたが、実は10分しか時間がないので急いでやらなきゃいけない。詳しくは、今月の「アジャイルジャパン2018」で関さんとセッションをやるときに、90分の詳細版をじっくり話しますので、ぜひ、ご参加くださいね。

デザイン思考は日本の自動車会社研究の産物

（スライドを指して）これはシリコンバレーでの講演ですね。IntelとかWestern Digitalとか、そういう会社さんがありますよね。iObeya（クラウド大部屋システム）なんてソフトウエアの会社の展示が出ています。この会議にはいろいろな方がいるのですが、だいたい皆さんが常連になっていて、私は彼らの先生という感じになっています。

（スライドを指して）これはテキサスです。（別のスライドを指して）Steelcaseという100年続くミシガンの会社。IDEOというデザインコンサルティング会社は、ご存知の方もおられると思います。実は最初にこのIDEOにお金を出したのが、このSteelcaseです。バリー・カッツというIDEOのフェローが言うには、結局デザイン思考は日本の自動車会社研究からできているよとのことです。

このSteelcaseは、トヨタ流、つまりリーンの研究を長らく続けていて、その文脈にあります。ミシガンはフォードやGMといった自動車の街ですが、かつて日本の自動車会社にコテンパンにやられたので、あの地域の人たちは一生懸命にトヨタ流を、つまりリーンを研究してきました。実はそういった歴史的な背景があります。

（スライドを指して）これはイギリスですね。白髪のお爺さんがいると思うのですが、この人はダン・ジョーンズといって、「リーン」という言葉がはじめて使われた『The machine that changed the world』という本の著者の一人です。みなさんが教科書を読むと、Womack & Jonesという二人の著者で出てくると思いますが、Jonesがこのお爺さんです。

リーンという言葉を考えたのがJohn Krafcikと言う人で、この本を作るために5億円かけたプロジェクトが昔あったのですが、そこにいたことがある人です。このJohn Krafcikは今Googleの自動運転部門Waymoの社長さんです。そのあたりの話はまた詳しくAgile Japanで話します。彼は、もともとNUMMIというトヨタとGMの合弁企業で最初に雇われた技術員なんだそうです。技術員というのは昔風ですけど、エンジニアのことです。

トヨタの業績の良さが、研究対象となった理由

（スライドを指して）これはミシガン大の（ジェフリー・）ライカー教授。そしてマイク・ローザーですね。みなさん「バリューストリームマッピング（VSM）」というのを聞いたことはありますか？　ソフトウェアの人だったら、最近はたまに（聞いたことが）ある人もいると思うのですが、そのVSMという言葉を考えたのがこのマイク・ローザーと、ジョン・シュックという人ですね。

生産管理で「モノと情報の流れ図」とかいっているものを勝手にVSMと名付けたそうです。マイク・ローザーはトヨタのカタという、トヨタとはとくになんの関係もない話を勝手につくって商売もしています。翻訳本も出ていますね。

（スライドを指して）これはマイケル・バレ。フランスで有名なリーンコンサルタントです。父親のフレディ・バレも有名です。このお爺さんがマイケル・ケネディ。ケネディさんは、リーン開発なるものを作った（アレン・）ウォードの仲間だった人です。（別のスライドを指して）これはスウェーデンのチャルマーズ工科大の人達。（別のスライドを指して）この人はGE。GEもSix sigma, lean six sigma などリーンを35年やってトヨタの真似をしようと頑張っておられたそうです。

これらがワークショップに出ている人たちです。

じゃあ、なんでこんなに（トヨタについて）この人たちが必死に勉強しているかというと、圧倒的に業績が良いから研究するわけですよね。トヨタの製品や会社のことが好きだとか嫌いだとかはどうでもよくて、業績が良いからその理由を探ってしっかり研究したいというわけです。日本ですとみなさんAppleやGoogleについての本を買ったりしては、ありがたがっては学んでいる人もいると思いますが、その逆バージョンみたいなものです。

では、なんで私が詳しいのかというと、このアインシュタインの隣に立っている人と関係しています。私の先祖の1人なのですが興味ある人は個別に聞いてください。

「Product Development Performance」からPMの役割が生まれた

本日のお題です。実はご存知の通り、POというコンセプトはこのジェフ・サザーランドから来ています。一方、PM（Product management）という役割は、この『Product Development Performance』から来ています。キム・クラークというハーバードビジネススクールの先生が書いたものですが、重量級プロダクトマネージャー(Heavy weight product management)というやつで、皆さんがどうこう言っているPMは、実はそのあたりから来ていますね。役割を考えるには、源流に遡った方がわかりやすい。

では（スライドの赤丸部分を指して）ここを見ましょう。これはPOについての説明ですね。この本はたぶん翻訳も売っていると思いますが、このように翻訳で紹介されているかは定かではないと。「My inspiration for the role came from Toyota’s chief engineer. A chief engineer at Toyota is responsible...…」と書いてありますね。POは、これから来ているんです。

（スライドの赤丸部分を指して）次は、ここに「Shusa」と書いてありますよね。「everyone thinks of these legendary chief engineer」……。では、こういう内容をサザーランドさんたちはどこで勉強したのかというと、手に入るいろんな本を読んだり英語圏で行われている講習会に行って勉強していたわけです。「It’s this idea that I wanted to embody within Scrum. John Shook of the Lean Enterprise Institute...」と書いてあります。このLean Enterprise Instituteが海外でリーンを広めた人たちで、ジョン・シュックが中心の1人ですね。

みなさん、この人を知っていますよね。たまにチューハイのCMに出てくるモデルの方。沙耶・シュックさん。この人の親父さんがジョン・シュックで、トヨタの工場総務・人事系の人です。ですから内容が非常に工場寄りになっていて、説明がだいぶ粗くて、ですね。結果、派生物もいろいろ乱暴になっています。（例えば）スクラムマスターの説明では、「servant leader」と言っていますが、このサーバントリーダーというのは、具体的なイメージとしてトヨタの量産工場の班長・組長から着想を得ています。

原点から学ぶことの重要性

（スライドを指して）こちらはどうかというと、ハーバードの社会学の人たちです。（スライドを指して）ここに出てきますね、「Leadership and Organization, The Heavyweight Product Manager」。本はまだAmazonとかにありますので、買って読んでみてください。ただ社会学的なアプローチなので、もちろん具体的にどうしたらいいかは一切書いてありません。分類しただけ。でとりあえず名前はつけたと。

実は、PO、PM、CE/Shusaはみんな同じものを説明しようとしています。そう、トヨタ発祥で、トヨタ本体が1950年代はじめからやっている車両開発の仕組み、トヨタの主査制度(現在はチーフエンジニア制度)の車両主査、チーフエンジニアのことです。当然私はオリジナルがどういうものでどう運用するか知っているので、これ（CE／Shusa）は正解です。本には書けるとこまでしか書いてはいません。海外の皆さんはこれが知りたいということで、必死で聞いているわけですね。

正解を知っている側から辛めに採点をさせてもらうと、（100点中）ジェフらの（PO）は2点くらい。これは単に調査・理解不足。なにせ英語圏には、一般的にまともな情報がこれまでありませんでしたから仕方ないです。ハーバードビジネススクール（PM）は4点。これも調査・理解不足ですけど、だいぶ古い本ですしね。調べた人達が社会学者ですから、その割にはよく頑張りましたと言ったところでしょう。

しかしながら、皆さんは、せっかくオリジナルが日本にあるのだから、こういったしょうもない派生版ではなくて、オリジナルから学ぶように心がけてください。それが早いですし、間違いがありません。当たり前ですよね。

じゃあ、なんでこんな間違いが起きたのか。ジェフ・サザーランドやハーバード(ビジネススクール)がなぜここまでいい加減なのかというと、もちろん原因があります。海外でトヨタは、そもそも「TPS＋Gemba QC」と説明されていて、これがすなわち「リーン」と説明されたためなのですね。これ（リーンの考え方）がアジャイル・スクラムというようにどんどん派生して。あとデザインシンキングにも若干影響があります。

ちなみにMITみたいにデザインシンキングをリーンの文脈で説明して教えている学校も米国にはあるという話です。また、例えばGEでは、先ほどちょっと言ったSix sigma, lean six sigmaときて、その後なにを血迷ったのか、リーンスタートアップとデザインシンキングをなんとトップダウンで全社展開からの推進してしまった。それら派生版が、実は、これまた論外にひどい出来だったのです。で、今GEさんの業績はメチャクチャになってしまっている。CEOのイメルトさんは解雇され、二兆円の資産売却、二万人の人員削減と大変な状況です。

GEでは、リーンスタートアップのことはファストワークスと言って、Eric Riesという人がコンサルタントで入ってやっていたというのは、ひょっとしたらみなさん聞いたことあるかもしれませんね。あれはダメですよ。デザインシンキングもそうですけど、ダメダメなので、気をつけてください。毒饅頭を体に良いと言われて食べさせられるようなものです。GEは毒饅頭の毒が回ってしまった。最近のGEの現状は、ネットで検索して自分で調べてみてください。この界隈の話は、毒饅頭が多いので、気をつけてください。騙されて毒饅頭を食べた方も悪いんですけどね。

国道248号線を境に、東と西で別の世界が現れるトヨタ本社

ところで、皆さん、GEが今ものすごく業績が悪いというのはご存知ですよね？？英語圏の新聞とかニュースも見るようにして下さいね。

話がそれましたが、なにが言いたいのかと言うと、間違ったものを例のごとく真面目に学ぶと大変なことになってしまいますよ、ということです。リーンの源流に遡ると、これ（Toyota=TPS+gemba QC=Classic “Lean”）がそもそもの間違いだったのですね。

トヨタのマスプロダクションの工場、つまり量産工場はこう（TPS+ gemba QC = Classic Lean）なのですが、実際のトヨタの会社としてのシステム全体はどうなのかいうと、ざっくりと言うとTPDとTPS、石川馨とか朝香鐵一という人たちのTQCでできています。TQCはもとをたどっていくと先祖はデミングですよね。ただデミングは、名前はみなさん知っておられますけど、彼の本当のところの思想とか仕組みとか実はあまり知られてないのではないですかね。

TPDは「チーフエンジニア制度に基づく製品開発」。で、ソフト分野でも、強いプロダクトを作っていくみなさんははここをやらなければいけないと。このあたりが、そもそもPO・PMについて学者やコンサルタントが最終的に辿りついて、言いたいことなのですけど、現状、失敗しています。この部分で重要なのは、PO/PMに関しては、派生元は量産プロセスのTPSではありませんよ、ということです。

トヨタ本体の本社に行くと、国道248号線を境に、東と西で別の世界になっています。機能・役割が違うというか。規律上、こっち（TPD→TPS）は入れるんですが、こっち（TPS→TPD）は一切入れません。TPDでも、全体の構造を知っている人は、実はごくわずかしかいません。大きい会社だから当然です、というかだいたい大きい会社はそんなものです。だからトヨタのエラい人をつかまえて聞いてもみても構造はわかりません。

系列の人も、もちろんなにも知りません。そもそも別会社なのですから当然です。デンソーなんかに話した情報は、他の車両メーカーにそのままいってしまう可能性があるのは分かりますよね。どんな会社でも機密管理はしているし、そういうことは、別に珍しくもない当たり前の話です。アップルなんかは機密管理が厳しい会社ですよね。

トヨタ本体の場合は、過去に248号線の西側の工場のやり方を下請けの系列企業に積極的に展開したり、海外に工場を出したりする際に展開したので、そこの一部分のやり方が世間ではよく知られるようになりました。で、その一部分が、特に欧米や一部の日本人の間では、ですけど、それが「全体」みたいに語られるようになってしまった。それで、いろいろおかしくなってしまっているのです。

欧米の工場で働いていたOBや、トヨタ系列の工場の生産管理出身者のコンサルタントが欧米でリーンを教える商売をしたりして、TPSや量産工場の現場のQCばかりが世の中では、有名になってしまった。もともと全体のごく一部の話なのですけど。で、その一部分だけやればすごく儲かると、いうことに、いつの間にかなってしまっている。まさかそんなはずないんですけど。

リーン、アジャイルなどの翻訳物とのつきあいもほどほどには

で、普通に欧米のAgile系、Lean系の業界ですとトヨタといえば（スライドを指して）こんな感じで理解されています。なにもないのですよね（TPSだけしか存在しない）。わかりますよね。

ただ、ここで、こういう言葉は知られています。「主査は『製品の社長』であり、社長は主査の助っ人である」と。ですから、全体のビジネスプロセスがあって、チーフエンジニア、あるいはプロダクトマネージャーというのは、経営陣、技術、売上・利益、市場目標を含むすべてのビジネスプロセスに関わります。ここが重要ですよと。

（スライドを指して）ただ欧米ではこんな感じで理解されてきているので。……あるいはこんな感じですね。ジェフ・サザーランドたちなんかは（主査に関しては）完全にこのパターンと。彼らの勉強した教科書が間違っちゃっていたので、彼らも大きく間違えちゃった。

実際、最近まで、私はあまり知らなかったんですが、日本ではこういうへんてこなものをまじめに翻訳・紹介しているグループの人たちがいて、彼らとしては頑張っているわけですし別に悪いことではないんですが、今回はちょっとケースが特殊ですね。翻訳元の人たちがずいぶんおかしなことを今やっているので。

このあたり、つまりこの分野（リーン、アジャイルなど）の翻訳物は、はほどほどにしながら付きあっていただくよう心がけていただく、ということです。いちいち次から次へ出てくるものに真面目に付き合う必要は正直全くないです。

実は、POと言っているのは、Tierの低い製造受託企業、下請向けのイメージです。ソフトウエアだったら小さいソフトハウスや、協力会社さんとか、社内受託開発の人たちとか。

でも、今日ここにいらっしゃるみなさんが、今後どんどんやっていかなければならないのは、製品の価値を作る方法なのですよね。つまり世界で売れるソフトウエア・プロダクトの体験価値をつくるわけです。そのための手法というのは、組織の方法とかビジネスプロセスの方法とか、いろんなノウハウがあります。

結論から言ってしまうと、サザーランド父子のスクラム・フレームワークのPOは、下請受託開発以外ではお話にならないレベルなので、みなさんは今後、PO／PMだったらPMの方をどんどんやる。つまり今後はプロダクトマネジメントを学ぶようにしてください。POは論外です。もちろん、シリコンバレーでやられているPMも、漏れ抜けだらけでいい加減ではあるのですけど、一応ソフト分野であれば、PMの方は形にはなっています。グーグルとかがやっているものですね。足りない要素をさらに補っていけばさらに無敵となります。

プロダクトマネジメントについて体系的に説明できる人は少ない

ただ、POはともかく、プロダクトマネジメントあるいは主査制度とかチーフエンジニア制度とかについて、体系的な説明や指導ができる人というのは、世界でも極めて数が少ないのですね。私は日本国内で、これまでまともに説明できる人に1人も会ったことがありません。

プロダクトマネジメントの重要性については、わかっている日本の方は結構たくさんおられるので有望です。しかしながら、普通はそれがどういうものなのかを知る機会はないし、理解して説明したり、導入支援できる人は日本には1人もいないのが現状です。私に聞いていただくしかない。ちゃんとした教科書もまだないですしね。そもそも会社によっては秘密だから、本で書く動機がとくにないのです。あるいは、書いたとしても書いて伝えるのがなかなか難しいけど。

このあたりのところは理解、導入、運用が非常に難しいので、おかしなことをやって永遠に遠回りして時間を浪費するよりは、私に聞いてください。導入に成功するには、例えば（スライドを指して）「Product & process」、「Product & people」、「Process & people」みたいに、一個ずつ分解してやっていくとかですね。いろいろやっていくと、人の能力とか組織の運用とか難しい話も絡むので、簡単ではないです。調べてみると、いろんな人が言っている、いろんなものがあるんですが、けっこういい加減な話が国内外であふれていますから、変なもので時間を潰さないようにしてください。

実際のソフトの場合ですが、この品質分解図には実は名前が付いていて、「Sakai’s quality creation diagram」、つまりSQCDと呼んで、説明に使っています。

みなさんの業界は、一般的には量産工場がないので、複製のところは考える必要がない場合があって。その場合PMは、もちろんクラウドサービスでスケールします、というときにインフラがどうこうという話がある場合は、量産（複製）と同じように考えれば良いです。

ただ、POの場合は、だいたい次のスライドのこんなイメージでやられている。基本的には全部、肝心の大きなところが終わってしまったあと、バックログの管理をやるというところです。そんなことでよいプロダクトになるのか的な。

PO／PM界隈の人の悩みは、どういう能力をもった人が、実際なにをどこまでやったらいいのかよくわからないよ、ということにあるのではないですか。教科書にはそれが書いていないし、アジャイルコーチやらスクラムの先生たちに聞いてみても、分かったような分からないようなことを言っているのではないですかね。彼らは、当然ですけどなにも分かっていません。

スクラム・フレームワークは、肝心なところがスコープ外だからですよね。そもそもどういう能力の誰がやる・やれるか問題とかね。で、突っ込まれてから、Lean startupとかデザインシンキングとかを持ち出す人もいるのだけど、そこでGEの先行大失敗事例を考えてもらう。あれは残念ながらソリューションにならず毒饅頭ですので、そのあたり、Agile Japanで分かるように話します。

日本発のGAFAを作るために必要なのは、POではなくPM

結局、目的は、ソフトであれサービスであれ、皆が喜んで使ってくれて、売れて利益が出るプロダクトができないといけないわけであって、クルマであれクラウドサービスであれ、人が使うシステムプロダクトについては、PMとか主査がその中心の役割を果たすわけです。サザーランドのバックログ管理しているPOなんかじゃ話にならんのは分かりますよね。タスクの管理を効率的にやる受託型協力会社さんの話と、プロダクト創造会社さんでは話が違いますよね。今日ここにおられるみなさんはどちらの会社さんの方ですか？

みなさんがスクラムやってみて、POの話で混乱するのが当然なのは分かりますよね。言い出しっぺのサザーランドたち自身、このあたりの話がサッパリ分かっていないのだから仕方ないのです。日本の古い体質のソフト業界の、受託下請けソフトハウスの開発ならともかく、みなさんはこれからプロダクトで稼がれるわけですよね。人月商売じゃないですよ、日本のソフト産業は。GAFAを日本発で作るんですよね？

だったら、POじゃなくてPM、つまり主査の方を。サザーランドたちみたいな、よく理解できていない人たちなんかほっておいて、先にみなさん自身で研究していかれると良いです。

そのあたりの説明は簡単ではないですが、いま極めて大事なところで、大きいところで間違えて真面目にやってしまうと、GEみたいにおかしくなるところも出てくるので。これはAgile Japanでわかりやすくお話しますので、また19日によろしくお願いします。ありがとうございます。

（会場拍手）