プロダクト思考はどこから来たのか――TaylorismからBPR、Lean、Design Thinking、Lean Startupまでの100年史
「Product ManagementやProduct Thinkingでやっていることは、日本のコンサルが昔からBPRや業務改革でやってきたことと、かなり似ているのではないか」。
この疑問は、かなり本質を突いている。
顧客を定義する。現状を観察する。ペインやボトルネックを見つける。あるべき状態を考える。施策を設計する。KPIを置く。実行し、結果を見る。言葉だけを並べれば、BPR、Service Design、Lean UX、Product Discoveryは驚くほど似ている。
すると「BPRが生まれ、Leanへ発展し、Design Thinkingが顧客視点を加え、Lean Startupが実験を加え、Product Thinkingになった」という一直線の進化史を描きたくなる。
しかし史料を辿ると、これはかなり違う。
BPRが登場する1990年より約80年前から「仕事をどう科学的に設計するか」は議論されていた。BPRより約60年前には、すでに製品単位で結果に責任を持つBrand Managementの原型が生まれていた。人間中心設計やService Designにつながる思想もBPR以前から存在する。1980年代には、製品開発を逐次工程ではなく、部門横断チームによる高速な学習活動として捉える研究まで現れていた。
つまり、現代のProduct ThinkingはBPRの子孫ではない。
より正確には、20世紀に別々の場所で発達した「仕事」「品質」「製品」「顧客」「デザイン」「組織」「ソフトウェア」「学習」に関する複数の知識体系が、Software Productという場で合流したものだと考えたほうがよい。
この記事では、その約100年の知的系譜を辿る。そして最後に、なぜProduct Managementの世界ではこれらが公開されたBody of Knowledgeとして見えやすい一方、コンサルティングでは「弊社独自の変革方法論」「業務改革5ステップ」のような会社固有の言葉として見えやすいのかまで考えてみたい。
BPRは起点ではない。「仕事を設計する」という発想はもっと古い
Business Process Management研究者のWil van der Aalstは、BPMの起源を一点に特定するのは難しいとし、その系譜を産業革命、Adam Smithの分業、Frederick W. TaylorのScientific Management、Henry Fordの大量生産まで遡っている。
現代のTransformationに直接つながる大きな節目の一つが、1911年のFrederick Winslow Taylor『The Principles of Scientific Management』である。Library of Congressにも1911年版が所蔵されている。
Taylor以前にも効率化の工夫は当然あった。しかしScientific Managementが重要なのは、仕事を熟練工個人の経験や勘に任せず、「観察し、分解し、測定し、より良い方法を設計できる対象」として扱った点にある。
ここで起きた抽象化は大きい。
仕事とは、人がただ頑張るものではない。仕事には構造があり、その構造は設計し直せる。
現代から見ればTaylorismには、人間を生産システムの一要素として扱いすぎる危うさもある。しかし「現在の仕事の仕方を自然法則だと思わない」という態度は、その後のBPRにもLeanにもProduct Thinkingにも通底している。
「なぜこの作業は必要なのか」「なぜこの順番なのか」「なぜこの役割を経由するのか」と問い直す。Transformationの祖先は、BPRよりずっと古い。
1924年、品質は「最後に検査するもの」から「プロセスの中で学ぶもの」へ
次の重要な川はQuality Managementである。
Bell Telephone LaboratoriesのWalter A. Shewhartは1924年5月16日のメモで、今日の管理図につながる図を示し、1931年には『Economic Control of Quality of Manufactured Product』を出版した。NISTも、この1924年のメモをStatistical Quality Controlの重要な起点としている。
重要なのは管理図という道具だけではない。
Shewhartが持ち込んだのは、「結果が悪かったら担当者を責める」という世界観ではなく、ProcessにはVariationが存在し、それを観測し、原因を見分け、Systemそのものを改善するという世界観である。
W. Edwards Demingはこの思想をさらに広げ、1950年代の日本で統計的品質管理を教えた。Deming Instituteの記録では、1950年に日本の経営者・技術者向け講義を開始し、1951年にはJUSEがDeming Prizeを設立している。Deming自身も1967年、日本企業の品質向上について、統計技術だけでなくManagementの改善意思を重要要因として挙げている。
ここでTransformationにFeedbackという考えが入ってくる。
観察する。変動を見る。仮説を持つ。変更する。結果を見る。
もちろん、後世のLean StartupのBuild-Measure-LearnがShewhartから直線的に生まれたと言うべきではない。それでも、20世紀前半にはすでに「一度正しい設計を決めて終わり」ではなく、「結果を観測しながらSystemを改善し続ける」という循環的なManagement観が形成されていた。
1931年、別の川が始まる――「機能」ではなく「製品」に責任を持つ
Scientific ManagementやQuality Managementとは別の場所で、もう一つ重要な系譜が始まっていた。
1931年5月13日、Procter & GambleのNeil McElroyが書いた「Brand Men」メモである。
McElroyはブランドごとに担当者を置き、売上を調べ、強い地域では何が機能しているのかを分析し、弱い地域では広告や販促を調べ、現地へ赴いてDealerやConsumerを観察し、原因を見つけ、対策を実施する役割を構想した。Carnegie Mellon UniversityのProduct Management Programも、このメモを現代Product Managementの重要な起源として紹介している。
今日のProduct Managerと同じではない。中心はBrand ManagementとMarketingである。
それでもProduct Management史でこのメモが繰り返し参照される理由は明快だ。
組織を「広告部」「販売部」「製造部」というFunctionだけで見るのではなく、一つのProductやBrandを横断して結果に責任を持つ人間を置いたからである。
ここで生まれたのはEfficiencyでもQualityでもない。
Ownershipである。
現代のProduct ManagerがEngineering、Design、Sales、Marketing、Financeなどを横断しながらProduct Outcomeに責任を持つ構造には、このProduct単位のOwnershipという思想が残っている。
したがって、Product ManagementにはBPRとは別の祖先がいる。BPRとProduct Managementは似ているが、片方がもう片方から単純に派生したわけではない。
Toyota Production System――TaskからFlowへ
もう一つの巨大な川がToyota Production Systemである。
トヨタ自身の説明では、TPSの二本柱は「自働化」とJust-in-Timeであり、その根には豊田佐吉の自動織機と豊田喜一郎のJust-in-Time思想がある。トヨタの社史では1938年の挙母工場でJust-in-Time方式が導入されたとされている。
TPSを単なる「効率化手法」と理解すると本質を落とす。
重要なのは、一つ一つの作業を最大速度で行うことではない。必要なものを、必要な時に、必要な量だけ流す。異常が起きれば止める。在庫、手待ち、過剰生産、不良など、価値を生まない活動を減らす。工程全体をFlowとして見る。
局所的に作業者を10％速くしても、後工程が詰まればSystem全体は速くならない。大量に前倒しして作っても、使われなければInventoryというWasteになる。
最適化対象がTaskからSystemへ上がったのである。
1980年代後半、MITのInternational Motor Vehicle Programに関わったJohn Krafcikが「lean」という語を用い、1990年のWomack、Jones、Roos『The Machine That Changed the World』によってLean Productionが広く知られるようになる。Lean Enterprise Instituteも、Lean Productionという語をKrafcikに帰している。
後世のLean StartupとTPSを同一視することはできない。それでもSmall Batch、Pull、Flow、Waste、現場からのFeedbackという語彙が、後のSoftware/Product Developmentへ流れ込んだことは重要である。
Designの川――「正しい工程」の前に「何をつくるべきか」を問う
ここまでの系譜はOperations寄りである。しかし1960年代から1980年代にかけて、別の方向からDesignの思想が成熟していく。
Herbert A. Simonは1969年の『The Sciences of the Artificial』で、人間が作る人工物の世界を扱う「Design」の知的基盤を提示した。MIT Pressは初版を1969年刊として記録している。
1973年、Horst RittelとMelvin Webberは『Dilemmas in a General Theory of Planning』で、社会的問題の多くは明確な定義と唯一の正解を持つ「tame problem」ではなく、問題の定義自体が争われ、単純な真偽でSolutionを判定できない「wicked problem」であると論じた。
これは現代Product Developmentに直接つながる重要な視点である。
工程時間を10％短くするなら、目的関数は比較的置きやすい。しかし「学生生活をより良くするサービスとは何か」「高齢者が安心して移動できる仕組みとは何か」「ユーザーが欲しいSoftwareとは何か」では、Problem Definition自体が固定されていない。
TransformationはOptimizationだけでは足りない。Problem Framingが必要になる。
1984年、G. Lynn Shostackは『Designing Services That Deliver』で、Service Failureを場当たり的な接客の問題ではなくSystematic Design and Controlの問題として捉え、BlueprintによってServiceを設計する考えを示した。1986年にはDonald NormanとStephen Draperの『User Centered System Design』が、人間とComputerの関係をUser-centeredに考える体系を提示している。
ここでProcessの外側にいたCustomer/Userが設計の中心へ入ってくる。
「このSystemは効率的か」だけではない。「このSystemは人間にとって意味があるか。使えるか。望ましいExperienceを生むか」が問われる。
Product ThinkingのHuman-centerednessは、このDesign/HCIの川なしには説明できない。
1986年、日本から「ラグビー型」の製品開発が提示されていた
日本の話をするとき、忘れてはいけない重要な論文がある。
竹内弘高と野中郁次郎が1986年にHarvard Business Reviewへ発表した『The New New Product Development Game』である。
彼らは従来の製品開発を、工程ごとにバトンを渡す「relay race」に例え、それに対して部門横断チームが重なり合いながら進む「rugby」型のApproachを論じた。論文の問題意識は、品質・コスト・差別化だけでなくSpeedとFlexibilityが重要になり、Sequentialな開発だけではそれに対応しにくいというものだった。
後のSoftware DevelopmentでScrumという語が普及する際、この論文は重要な参照点の一つになった。
これは「日本には体系化されたProduct Development知がなく、海外から輸入しただけ」という単純な物語を壊す。
少なくとも製造・品質・製品開発の一部では、日本企業のPracticeを日本人研究者が抽象化し、それが世界のSoftware Developmentへ影響する逆方向の知識移転が起きていた。
問題は「日本に知識があるか、ないか」ではない。誰が実践知を公開可能なConceptへ変換し、会社を越えて再利用できるKnowledge Ecosystemを作るか、という問題なのである。
1990年、BPRが登場する――起点ではなく「第一回目の大統合」
そしてようやくBPRが登場する。
1990年、Michael HammerはHarvard Business Reviewに『Reengineering Work: Don’t Automate, Obliterate』を発表した。
古い仕事をComputerで速くするな。古い仕事そのものを捨て、Information Technologyの力を使ってBusiness Processを根本から再設計せよ。Hammerの論文は、既存のルールをComputerで高速化するだけでは大幅な性能改善は得られない、という問題意識から始まっている。
同じ1990年、Thomas DavenportとJames Shortも『The New Industrial Engineering: Information Technology and Business Process Redesign』を発表し、ITとBusiness Process Designを自然なPartnerとして位置づけ、部門をまたぐCustomer-drivenなProcessを対象にした。
ここで、それ以前の複数の思想が一度に接続される。
仕事は設計できるというScientific Management。Process全体を見るQuality/Operations。Functionを越えるSystem View。そして急速に力を持ち始めたInformation Technology。
だからBPRは巨大な節目だった。しかしTransformationの始まりではない。
むしろ、それ以前の約80年間に蓄積されたWork DesignやProcess Managementを、IT時代に再統合したものと見るほうが正確だ。
そしてProduct Thinkingとの類似もはっきりする。
Hammerが批判したのは、「昔からそうしている」という理由で古い業務を前提にし、その表面だけを自動化することだった。
Product Thinkingが批判するのは、「Roadmapに書いてある」という理由でFeatureを前提にし、本当にUser Problemを解くか確認せず実装することである。
どちらも既存Solutionを所与とすることを嫌う。ここは同型である。
それでもBPRとProduct Thinkingは同じではない――最大の違いは「探索」にある
ではBPRは、ほとんどProduct Thinkingだったのか。
半分はYes、半分はNoだと思う。
BPRの強みはFunctional Silosを越えてEnd-to-End Processを見たことにある。一方、古典的BPRには、現状を分析し、抜本的なTo-Be Processを設計し、それを実装するEngineering的世界観が強い。Hammer自身もReengineeringを、小さく慎重に積み上げる活動というよりRadical Redesignとして描いていた。
しかしProduct Thinkingが扱う世界では、To-Beの正しさそのものが事前には分からない。
ユーザーが使うのか分からない。どのProblemが重要なのか分からない。価格を払うのか分からない。技術的に作れてもBusinessとして成立するか分からない。
だから現代Product Developmentの中心問題はDesignだけでなくDiscoveryになる。
「良い答えを設計する」だけでなく、「何が良い答えなのかを探索する仕組みを設計する」必要がある。
ここが、BPRからProduct Thinkingへの単純な直線では説明できない最大の断絶である。
1990年代、すでに経営学はExplorationとExperimentationを研究していた
Lean Startupより前に、経営学ではこの探索問題がかなり明確に扱われていた。
James G. Marchは1991年の『Exploration and Exploitation in Organizational Learning』で、既知のものを洗練し効率化するExploitationと、新しい可能性を探るExplorationのTrade-offを論じた。さらに、適応的な組織はExploitationをExplorationより速く磨きやすく、短期的には有効でも長期的には自己破壊的になりうると論じている。
この議論をProduct Developmentへ持ち込むと分かりやすい。既存Process改善はExploitationに強い。一方、まだ何を作るべきか分からないInnovationではExplorationの能力が必要になる。
1995年、Shona BrownとKathleen Eisenhardtは、それまで断片化していたProduct Development研究をレビューし、Rational Plan、Communication Web、Disciplined Problem Solvingという三つの流れに整理した。Product Developmentはすでに単純な工程管理ではなく、Team、Customer、Supplier、Managementが関わるProblem Solvingとして研究されていた。
1998年にはStefan ThomkeがManagement Scienceで、ExperimentationがInnovationの基本的なProblem-solving活動であり、Rapid PrototypingやComputer Simulationなどによって「実験のEconomics」が変わることを論じた。
これは非常に現代的である。
Software Companyが速く学べるのは、単にEngineerが優秀だからではない。ExperimentのCostを下げやすいからである。
試作する。見せる。ログを取る。失敗したら戻す。SoftwareはPhysical Productに比べ、変更と実験のMarginal Costを劇的に下げた。
競争力は「最初から正解を当てる能力」だけでなく、「安く、速く、何回学習できるか」へ移っていく。
Agile――SoftwareがFeedback Loopを短くした
2001年、Agile Manifestoが公開された。
そこではProcesses and ToolsよりIndividuals and Interactions、Comprehensive DocumentationよりWorking Software、Contract NegotiationよりCustomer Collaboration、Following a PlanよりResponding to Changeが重視された。
Agileの歴史的重要性は、「計画は不要」と言ったことではない。
Software Developmentにおいて、長い計画と大きな一括Deliveryの間隔を短くし、現実からFeedbackを受け取る頻度を上げたことにある。
SoftwareのChangeabilityをManagement Systemへ組み込んだのである。
ただし、AgileだけではProduct Thinkingにはならない。
Agileは「どう作るか」を変えたが、「何を作るべきか」まで自動的には決めてくれない。間違ったFeatureをScrumで高速に作ることもできる。
ここにDiscoveryとDeliveryの違いが現れる。
Customer DevelopmentとBusiness Model Canvas――会社そのものを仮説として扱う
2000年代に入るとStartupの世界からCustomer Developmentが入ってくる。
Steve Blankは、Customer Discovery、Customer Validation、Customer Creation、Company Buildingという循環的なModelを提示した。Stanfordで公開されている『The Four Steps to the Epiphany』でも、Customer DevelopmentはProduct Developmentの代替ではなくCompanionであり、前半ではCustomer ProblemとNeedを理解し、ValidationでRepeatableなSales Modelを探るものとして説明されている。
重要なのはStartupを既存企業の小型版と見なさなかったことである。
既存企業は、ある程度分かっているBusiness ModelをExecutionできる。しかしStartupは、誰が顧客で、何を価値と感じ、どのChannelで届き、何にお金を払うかをまだ知らない。
だからStartupの仕事はExecutionの前にSearchである。
この「Search versus Execute」はProduct Thinking史の大きな転換である。
さらにAlexander OsterwalderとYves PigneurによるBusiness Model Canvasは、Customer Segments、Value Propositions、Channels、Revenue Streams、Key ActivitiesなどBusinessの構造を一枚へExternalizeした。Strategyzerはその起源を1999〜2009年のBusiness Model Ontology研究とCanvas形成に置いている。
Canvasの意義は整理の美しさだけではない。Business Modelを「未来を記述した計画」ではなく、「現在信じているHypothesisの集合」として扱いやすくした点にある。
現在のStrategyzer自身も、CanvasをPlanではなくClaimとして扱い、Evidenceが得られれば更新するものと説明している。
ManagementがPredictionからLearningへ移っていく。
Lean Startup――「学習」が正式なOutcomeになる
この流れを強力なManagement LanguageへまとめたのがEric RiesのLean Startupである。
最重要概念はMVPではない。
Validated Learningである。
Startupの目的は、単にProductを作ることでも忙しく働くことでもない。持続可能なBusinessをどう作るかを学習し、その学習をExperimentによって検証する。
IdeasをProductへ変える。Customerの反応をMeasureする。そこからLearnし、PersevereかPivotかを判断する。Build-Measure-Learnである。Riesの整理でもValidated LearningとBuild-Measure-Learnは中核原則として置かれている。
またMVPは「最小の商品」そのものではなく、最小の努力で最大のValidated Learningを得るためのVersionとして説明されている。
20世紀前半のQuality Managementから続くFeedback Loopが、Innovation Managementの中心へ移ったと見ることもできる。
ただし意味は違う。
Quality Managementでは、ある程度定義されたProcessを安定させるためにFeedbackを使う。
Lean Startupでは、正しいProductやBusiness Modelが何か分からないので、それを探索するためにFeedbackを使う。
同じ「測って改善する」でも、前者は主としてOptimization、後者はDiscoveryである。
Lean UXとProduct Discovery――100年分の思想がProduct Teamへ合流する
2013年、Jeff GothelfとJosh Seidenの『Lean UX』を見ると、ここまでの川が一冊に合流している。
O'Reillyが公開している目次にはCross-Functional Teams、Progress = Outcomes, Not Output、Problem-Focused Teams、Removing Waste、Small Batch Size、Continuous Discovery、User-Centricity、Shared Understanding、Learningが並ぶ。
Cross-functional TeamにはProduct Managementと1980年代のNew Product Developmentが見える。Removing WasteとSmall BatchにはLeanが見える。User-CentricityにはHCIとDesignが見える。Continuous DiscoveryとLearningにはCustomer DevelopmentとLean Startupが見える。
Lean UXは単なる「UXの軽量版」ではない。
20世紀に別々に発展したOperations、Design、Software、Entrepreneurshipの思想を、Software Product Teamという単位で統合した象徴的な方法論である。
その後Product ManagementではDiscoveryという概念がさらに明示的になる。
Marty CaganはProduct DiscoveryでValue、Usability、Feasibility、Viabilityという四つのRiskを検証することを重視する。
Teresa TorresのContinuous Discoveryでは、Outcomeを定め、継続的にCustomerへ接し、Opportunityを発見し、複数SolutionのAssumptionをTestする。Opportunity Solution TreeではOutcomeからOpportunity、Solution、Assumptionへ探索空間を可視化していく。
ここでは最初にSolutionがあるのではない。
Outcomeがある。Outcomeに影響するCustomer Opportunityがある。Opportunityに対する複数のSolution Hypothesisがある。そしてEvidenceによって探索空間を狭めていく。
As-Isを分析して一つのTo-Beを作り、それへ移行する古典的Transformationとは、かなり違う世界観である。
100年を一行に圧縮すると、何が変わったのか
固有名詞を忘れて抽象化すると、100年の変化は意外なほどきれいに見える。
Scientific Managementは、Taskをどう効率化するかを問うた。
Quality Managementは、Processをどう安定させ、Feedbackによって改善するかを加えた。
TPS/Leanは、局所ではなくFlow全体を見て、Valueを生まないWasteをどう減らすかを問うた。
Brand/Product Managementは、Functionを越えて誰がProductにOwnershipを持つかを問うた。
Design/HCIは、System都合ではなくHumanのProblemとExperienceから設計することを求めた。
BPRは、ITを使ってEnd-to-End Business Processそのものを作り替えた。
AgileはChangeを例外ではなく前提とし、Software DeliveryのFeedback Cycleを短くした。
Customer DevelopmentとBusiness Model Canvasは、CustomerやBusiness Model自体をHypothesisにした。
Lean StartupはValidated LearningをManagementの中心に置いた。
Lean UX、Product Discovery、Continuous Discoveryは、それらをCross-functional Product Teamの日常的Operating Modelへ統合した。
これをさらに圧縮すると、こうなる。
「作業を最適化する」から「Processを最適化する」へ。
「Processを最適化する」から「CustomerにValueを生むSystemを設計する」へ。
そして最後に、「正しいSystemを設計する」から「何が正しいかを継続的に学習できるSystemを設計する」へ。
これがProduct Thinkingまでの100年間に起きた、最も大きな変化ではないかと思う。
ではBPRとProduct Thinkingは何が同じで、何が違うのか
最初の疑問へ戻ろう。
Product Thinkingと、コンサルティング会社が行うBPRや業務改革は、結局かなり似ている。
どちらも現状を所与としない。Stakeholderを理解する。Current Stateを可視化する。Problemを特定する。望ましいOutcomeを考える。Interventionを設計する。そしてMetricで結果を見る。
抽象化すれば、両方とも同じ構造を持つ。
Actor → Problem → Value → Intervention → Outcome → Evidence。
BPRならActorがCustomerやEmployee、ProblemがProcess Bottleneck、InterventionがTo-Be Process、OutcomeがCost・Quality・Speedになる。
Product DiscoveryならActorがUser、ProblemがUnmet Need、InterventionがProduct Solution、OutcomeがUser BehaviorやBusiness Outcomeになる。
違うのは、どこから始め、何を最適化し、どれだけUncertaintyを前提にするかである。
古典的BPRはProcessから入りやすい。「この業務をどう再設計するか」が問題になる。
Product ThinkingはProblem Spaceまで一段上がりやすい。「この業務やFeature自体が、誰の何のProblemを解いているのか」が問題になる。
さらにProduct Thinkingでは、最初のTo-Beは完成形ではなくHypothesisである。使われ方を観測し、学習し、Problem Definitionから変える可能性がある。
したがってBPRとProduct Thinkingの境界は「業務かプロダクトか」ではない。
より本質的には、Optimizationにどれだけ重心を置くか、ExplorationをどれだけOperating Modelへ組み込むかの違いとして見るほうがよい。
日本のコンサルは「ガラパゴス」なのか――Knowledge Managementから考える
ここからは歴史的事実というより、私が日本のコンサルティングを見ていて感じる現象をKnowledge Management研究へ接続して考えてみたい。
日本のコンサル現場ではAs-Is、課題、To-Be、施策、Roadmapという仕事が何度も行われている。それ自体はBPR、BPM、Lean、Service Design、Business Architecture、Product Discoveryなど既存のBody of Knowledgeへかなり接続できる。
しかし実務では、必ずしも外部Knowledgeと接続された形で教えられない。
「あのPartnerは業務改革に詳しい」「この案件の過去資料を参考にする」「弊社ではこの5 Stepで考える」という形でKnowledgeがPerson、Project、Firmに付随しやすい。
この現象を「日本人は体系化が苦手」と説明する必要はない。Knowledge Management研究には、もっと精密な語彙がある。
野中郁次郎は1994年のOrganization Science論文で、Organizational KnowledgeがTacit KnowledgeとExplicit Knowledgeの継続的な対話から生まれると論じた。個人がKnowledgeを生む一方、OrganizationはそれをArticulateしAmplifyする役割を担う。
さらにHansen、Nohria、Tierneyは1999年、Consulting Firmなどを調査し、Knowledge ManagementにはCodification StrategyとPersonalization Strategyがあると整理した。
Codificationは、人の頭にあるKnowledgeをDocumentやDatabaseへ移し、本人から切り離して再利用可能にする「people-to-documents」の戦略である。
Personalizationは、Knowledgeを完全には切り離さず、「誰が知っているか」を見つけ、人と人をつないで共有する戦略である。
ConsultingはCustomized Problemを扱うため、Personalizationが合理的な場面は多い。「あのSenior Managerに聞け」という状態そのものは直ちに未熟ではない。
問題は、それが唯一のKnowledge Architectureになることである。
コンサルの知識が「完全には標準化されない」ことには、経済合理性もある
Timothy Morrisは2001年、Professional Service FirmにおけるKnowledge CodificationにはParadoxがあると論じた。
ProfessionalのStatusを支えているのはKnowledgeである。しかしKnowledgeを完全にCodifyして誰でも再利用可能にすれば、Professional本人の希少性を弱める可能性がある。
MorrisのCase Studyでは、Codificationは進められても、ConsultantのExpert Roleを無効化しない形で制限されていた。
これは示唆的である。
Consulting FirmにはMethodologyを標準化してDeliveryを効率化したいインセンティブがある。一方、完全にManual化され、「この本とTemplateがあれば誰でも同じ結果を出せる」となれば、高いProfessional Feeを正当化するDifferentiationが弱くなる。
Professional Serviceでは、Knowledgeを共有したい力とExpertiseを希少なまま保ちたい力が同時に働きうる。
ここから見ると「独自Framework」「独自Methodology」「Accelerator」は、単なる知識不足ではなく、KnowledgeをFirm-specific Assetとして所有するBusiness Modelとも整合する。
ただし、ここから「日本のコンサル会社は意図的に知識を隠している」と断定するのは飛躍である。HansenらやMorrisの研究はConsulting/Professional Service Firm一般を扱ったもので、日本だけを比較した研究ではない。
より慎重に言えば、私たちが「封建的」と感じる現象の一部は、KnowledgeがPublic Body of Knowledgeへ完全にExternalizeされず、PersonやFirmとの関係の中で価値を持つPersonalization-heavyなKnowledge Architectureとして説明できる、ということだろう。
Product Managementが「開かれた知識」に見える理由
一方、Product Managementの世界ではKnowledgeが比較的外から見えやすい。
Agile Manifestoは公開されている。Business Model Canvasは会社を越えた共通言語になった。O'ReillyからLean UXのような実践書が出る。SVPGはProduct Discoveryの考えを公開する。Teresa TorresはContinuous DiscoveryやOpportunity Solution Treeを体系化する。
もちろんProduct ManagementにもCompany-specific PracticeやTacit Knowledgeは大量にある。
それでも、会社を越えて議論するVocabularyが豊富だ。
Discovery、Delivery、Outcome、Output、Opportunity、Assumption、Experiment、MVP、Product-Market Fit、Value、Usability、Feasibility、Viability。
これらは「あのPartnerだけが知っている秘密の言葉」ではない。誰でも読める。批判できる。他の方法論と比較できる。研究やCaseへ接続できる。そして別のPractitionerが改良できる。
Public Knowledgeになると、KnowledgeはAuthorityから切り離されやすくなる。
「誰が言ったか」ではなく、「どんなAssumptionに立ち、どんなProblemに有効で、どんなEvidenceがあるか」を議論しやすくなる。
コンサルティングの知識が時に封建的に感じられるのは、内容が古いからだけではない。Knowledgeの正当性がBody of Knowledgeより、Project ExperienceやOrganizational Authorityと結びつきやすいからではないか。
Transformation Body of Knowledgeは、実はすでに存在している。ただし分散している
ここまで調べると、一つの見方がしっくりくる。
私たちは「Transformationの統一理論」がないと思っている。しかし構成要素はすでにかなり揃っている。
OperationsにはScientific Management、Industrial Engineering、TPS、Lean、BPMがある。
QualityとLearningにはShewhart、Deming、Statistical Process Control、Experimentation、Organizational Learningがある。
ProductとOwnershipにはBrand Management、Product Management、Cross-functional Product Teamがある。
HumanとDesignにはHuman-centered Design、HCI、Service Design、Design Thinkingがある。
SoftwareとAdaptationにはAgile、DevOps、Continuous Deliveryがある。
InnovationとDiscoveryにはCustomer Development、Business Model Canvas、Lean Startup、Lean UX、Product Discovery、Continuous Discoveryがある。
これらは別々の宗教ではない。
企業が価値を作るという同じ現象を、異なるScale、異なるUncertainty、異なるUnit of Analysisから研究してきたKnowledge Systemである。
本当に必要なのは、新しい「弊社独自Transformation Framework」をもう一つ発明することではないのかもしれない。
既存Body of Knowledgeを整理し、「どのProblemに、どの思想を使うのか」をMappingすることではないか。
一枚にするなら、Product Thinkingは「Value × Flow × Ownership × Learning」でできている
100年の歴史を最後に乱暴に圧縮してみる。
現代のProduct Thinkingを構成しているものは、大きく四つあるように見える。
Value。誰のどんなProblemを解き、どんな価値を生むのか。Design、Marketing、Service Design、Leanなどから流れ込んだ問いである。
Flow。価値を組織のSiloに邪魔されず、どれだけ速くCustomerへ届けられるか。Scientific Management、TPS、Lean、BPR、Agileが磨いてきた問いである。
Ownership。誰がEnd-to-Endで結果に責任を持つのか。Brand ManagementからProduct Management、Cross-functional Teamへ続く問いである。
Learning。何が正しいか分からない世界で、どうEvidenceを集め、Assumptionを更新するのか。Quality Management、Organizational Learning、Experimentation、Lean Startup、Continuous Discoveryへ続く問いである。
Product Thinkingとは突然現れた新しいManagement Methodではない。
Value × Flow × Ownership × Learningという、20世紀に別々に発達した思想の合流点なのである。
おわりに――Frameworkの名前ではなく、その背後の「問い」を学ぶ
BPRを勉強するとAs-Is / To-Beが出てくる。LeanではValue Stream。Service DesignではCustomer JourneyとService Blueprint。Design ThinkingではEmpathize、Define、Ideate、Prototype、Test。Lean StartupではMVPとBuild-Measure-Learn。Product DiscoveryではOpportunity、Assumption、Experimentが出てくる。
表面的にはFrameworkが増え続けているように見える。
しかし100年を通して見ると、人類が企業活動について問い続けてきたことは、それほど多くない。
仕事をどう設計するのか。品質をどう安定させるのか。価値をどう速く届けるのか。誰が結果に責任を持つのか。人間が本当に必要としているものは何か。複雑なProblemをどう定義するのか。Technologyによって何を根本から作り替えられるのか。未来が分からないとき、どう学習するのか。そしてOutputではなくOutcomeをどう生み出すのか。
Frameworkは、この問いに対する、その時代ごとのAnswerである。
だからFramework名を暗記するより、そのFrameworkが「以前の何に不満を持って生まれたのか」を理解したほうがいい。
Taylorは職人個人に閉じた仕事の仕方を疑った。
ShewhartとDemingは結果だけを見て人を責めるQuality Managementを変えた。
Toyotaは局所効率ではなくFlowとWasteを見た。
DesignはSystemではなくHumanを中心へ戻した。
BPRは古いProcessをComputerで自動化するだけのIT導入を疑った。
Agileは巨大なPlanを作ってから長期間実装するSoftware Developmentを疑った。
Customer DevelopmentとLean Startupは、Business Planの中に正解が書けるという前提を疑った。
Product Discoveryは、Stakeholderが要求したFeatureが正解だという前提を疑った。
Continuous Discoveryは、DiscoveryをProjectの最初に一度やれば十分だという前提さえ疑った。
そう考えると、Product Thinkingの本質は特定のCanvasでもFrameworkでもない。
「いま目の前にある仕事、要件、Solution、組織構造を、自然法則だと思わないこと」。
そして「自分たちのAssumptionを、現実からのFeedbackによって更新し続けること」。
100年前のScientific Managementから現代のContinuous Discoveryまで、形を変えながら残っているのは、この二つなのかもしれない。
日本のコンサルティングに必要なのも、新しい横文字の独自Frameworkを増やすことではないだろう。
自分たちが日々行っているTransformationを、世界で100年以上蓄積されてきたPublic Knowledgeへもう一度接続すること。そして「このPartnerがそう言っている」ではなく、「このProblemにはこのBody of Knowledgeがあり、このAssumptionではこのMethodが有効で、このEvidenceがある」と議論できるようにすること。
それができたとき、業務改革、BPR、Service Design、Product Managementといった部門別のLabelの奥に、同じ一つの営みが見えてくる。
企業とは、価値を生むための人工的なSystemである。
そしてTransformationとは、そのSystemを、より良く設計し、より速く学習できるように作り変え続ける営みなのである。
