世界的テック企業のプロダクト作りを習得する秘訣
世の中を牽引するテック企業は、テクノロジーを活用して、顧客が熱狂し、かつビジネスも成長させるプロダクト作りを熟知している。これを通じ、技術への投資から着実なリターンも得ている。この働き方を「プロダクト運用モデル」と呼び、どの企業も習得しようと取り組んでいるが、成功させるのは難しい。それは日本の企業のみならず、米国の伝統的企業でもそうなのだ。
読者の中には、プロダクトマネジメントコーチのマーティー・ケーガンをご存じの方も多いと思う。20年以上シリコンバレーでコーチングを行い、「INSPIRED」や「EMPOWERED」といったプロダクト作りのバイブルを出版してきた業界の大先生だ。彼が今年春、そもそもテック企業のような働き方をしていない企業が、どうしたらそうなれるか、変革のため秘訣をまとめた本「TRANSFORMED」を出版した。ここに彼の20年を超える学びが蓄積されており、非常に学びが多かったので、この本と彼が所属するSVPGの記事を掛け合わせた内容を紹介したいと思う。
①プロダクト作りの10の落とし穴
テクノロジードリブンな事業成長ができる企業に変革しようと、沢山の会社が資金をつぎ込んで取り組んでいるのに、なぜその多くが失敗するのか。企業がどこで躓くのか、マーティーは10の「落とし穴」を挙げているので、そこから紹介したい。
①-1. スコープの過小評価
一般的に、変革は技術組織内で起こるものだと企業幹部は考えがち。しかし、始めるとすぐ分かるように、変革は組織全体（例：営業、マーケ、財務、人事、法務、コンプライアンス等）に影響を及ぼすもの。これらの組織を巻き込まないと、前に進めない。
①-2. CEOの役割の過小評価
改革は全社横断の活動となる一方、多くのCEOはこの責任をCIO・CDO・CDXOに委任しがち。社員は、CEOが気にすることを気にするので、これでは十分な注目が集まらない。変革できるかは、CEOが最大の旗振り役になれるかにかかっている。
①-3. テクノロジーの役割の過小評価
多くの企業は、物理的な製品とデジタル製品を別モノとして捉える。しかし、テクノロジーは、デジタルのみならず全ての製品を改善できる可能性を持つ。また、テクノロジーは単なる経費より大きなインパクトをもたらすもの。プロダクト運用モデルへの変革は、テクノロジーを経費ではなく利益の源泉にすることと言える。
①-4. 必要な能力の過小評価
社員に新しい役職を与えることは簡単だが、彼らの考え方や行動を変えることは何倍も難易度が高い。その新しい役割期待は、既存の社員では満たせない場合もある。この問題はプロダクトマネージャーに最も多いが、エンジニアリーダーでもよく起きる。良いプロダクトは強いプロダクトチームから生まれ、強いプロダクトチームはこれらの役割期待を全うできる人達から成る。強いメンバーがチームにいないと、プロダクト運用モデルは崩壊する。
①-5. エンジニアリングの役割の誤解
プロダクト運用モデルを実践する企業とそうでない企業では、エンジニアに対する考え方が驚く程異なる。伝統的な企業の多くは、エンジニアをコモディティと見なし、彼らを外注する。良いプロダクトを作る会社では、彼らをビジネス機会と解決策の両方を見出せる最も重要な人財と見なす。
①-6. プロダクト開発の性質の誤解
スティーブ・ジョブスが「アイデア出しが仕事の9割だと勘違いする病」と称した通り、製品作りにおいてアイデアはただの始まり。そのアイデアが期待された価値を出せないことも多々ある。プロダクト作りが上手な企業は、これを理解した上で、なるべく早く実験を回すことで、良い解決策に辿り着くまでの時間を短縮している。
①-7. プロダクトリーダーのコーチング不足
強いチームを作るには、プロダクトチームのメンバーが期待された役割を果たし、良い意思決定を促せるよう、彼らをコーチングできる人が必要不可欠。多くの企業では、この重要な役割が無視又は委任されている。良いプロダクトを作れる企業では、リーダー達はこれが最も重要な仕事として取り組んでいる。
①-8. メリハリのない戦略
企業が成功するためには、最もインパクトの見込める機会を追い、最もリスクの高い脅威に対応する必要がある。しかし、殆どの企業では、限られた資源を薄く広く配賦することで、どの事業部でもブレークスルーが起きない状態を作っている。成功するためには、社員を鼓動できるビジョンと、洞察に基づいた戦略でメリハリをつける必要がある。
①-9. 結果より、予測可能性を優先している
全ての企業は予測可能性（何がいつ起きるか）と結果（必要な成果の達成）の両方を求めるが、多くの企業ではこの2つの関係性が理解されていない。熟練のプロダクト企業は、機能のリリースがすぐに成果に結びつかないことも多々あることを理解している。これが理解できていないと、結果に関係なく、とりあえず沢山の機能をリリースしようとしてしまう。
①-10. プロダクト経験のない人の指導
変革に失敗している企業の殆どは、プロダクトを作ったことのない人からの指導を受けている。これは、発注側が注意する必要があり、彼らが実際に当事者としてプロダクトマネジメントを行ったことがあるかを確認する必要がある。
プロダクト運用モデルを習得するためには、これらの問題を全て上手く乗り切らないといけない。それは容易ではないが、何を注意すべきか、どこに辿り着くべきかについての感覚を持つことが出発点となる。
② 「プロダクト運用モデル」への変革とは
では、テクノロジードリブンな事業成長ができる企業に変革するためには、何をしなくてはならないのか。それは、突き詰めると3つのことに辿り着く。
開発の仕方を変える：機能のリリースをこまめに行い、顧客の手により早く届ける
問題の解決の仕方を変える：作るべき機能ではなく、解決すべき問題を与える
解決すべき問題の選び方を変える：ビジョンや戦略を通じ、最も大事な問題に焦点を絞る
②-1. 開発の仕方を変える
従来型のITモデルでは、通常、テクノロジーへの投資はプロジェクトとして扱われてきた。予算の承認をもらい、メンバーを配置し、計画・実行・納品を経て、チームは解散する。しかし、このやり方には大きな落とし穴がある。開発において得られる価値は、①作るものと②学ぶことの両方があるが、プロジェクト型の開発を行うと、学んだことの殆どは残らない。
その機能を改良したい時、新たなメンバーにそれを再学習するために時間とお金がかかるか、またはその学びが蓄積されずにもう一度過去のミスを犯しかねない。
加えて、プロジェクトの終わりでそのコードとサヨナラするチームの場合、それを見込んで開発する。外注モデルでは技術的な負債が蔓延するのは、このためだ。売るために家を改装するのと、住むために改装するのでは違うように、前者の場合、売れれば後で問題が発覚しても気にしない。
これらの弊害を考慮すると、実はプロジェクト型の働き方は時間と金の両面で非常に高価なのだ。さらに深刻なことに、殆どの場合、それは顧客と会社が必要とするイノベーションに繋がらない。
だからこそ、変革を起こすためには、開発のやり方から変えなくてはならない。そのためには、プロジェクト型→プロダクト型の運用モデルに移行する必要がある。
プロダクトモデルでは、開発は日常的な取り組みとして管理し、そのプロダクトへの投資又は提供をやめる意思決定をしない限り、こまめに機能のリリースを続ける（目安、少なくとも2週間に1回。できれば数日毎）。直感に反するかもしれないが、頻繁かつこまめに機能をリリースする方が、より効率良く顧客に価値を届けることができるのだ。（詳しく知りたい方は、「LeanとDevOpsの科学：テクノロジーの戦略的活用が組織変革を加速する」をご参照頂きたい。）信頼性の観点からも、小さな機能のテストを頻繁に行う方が、一度に沢山の機能を加えるより、バグの特定・分離がしやすく遥かに簡単である（後者は「ビッグバン」リリースと呼ばれ、NGパターンとして認識されている）。
また、プロダクト型に移行すべきもう1つの理由として、提供している機能が適切に作動しているか・どう使われているかを常に把握している必要があることが挙げられる。問題があればいち早くそれを検出し、また、新しく提供した機能が本当に必要な価値を提供しているかを検証しなくてはならない。こうした活動を日常的に行うことで、エンジニアチームが、コストではなく、売上の源泉として活躍するための基盤ができていくのだ。
②-2. 問題の解決の仕方を変える
どの企業も業績を上げるべく沢山の機能をリリースしているが、多くの企業は単なる「リリース工場」になってしまっていると言われる。こういった企業では、取り組んだプロジェクトの約1~3割程度しか、費用対効果に見合う成果が出ないことが多い。
何故こうなるかというと、これらのチームが顧客ではなく、社内の他部署（例：営業、財務、法務）の期待に応えるために動いていてるからだ。さらに言うと、関連事業部は、依頼した機能が成果に繋がると信じている一方、彼ら自身は技術への理解が乏しく、ユーザーや顧客の真のニーズを捉えられる立場にいないため、成果に繋がらない機能を依頼してしまう確率が高い。
この場合、開発チームは頼まれたものをその通りに作るためだけに存在し、依頼した側も失敗の責任を負いたくないため、「期待した機能と違う」、「期待した時間軸に間に合わなかったから」、と弁明し、互いの信頼関係が壊れていくこととなる。
また、この働き方を続けると、結果が出ずに放置される機能が沢山生まれ、手に負えないレベルの技術的負債が生まれていく。日々ニュースを見て分かるように、技術的負債は企業にとって命とりになり得る。
こうして徐々に顧客のために開発する力を失っていくと、より魅力的な解決策を競合が出し、必然的に顧客が自社のプロダクトから離れていくこととなる。
②-2-a. 課題解決の権限をプロダクトチームに与える
これに対し、権限のあるプロダクトチームは、作るべき機能を与えられるのではなく、解決すべき問題と達成すべき目標を与えられる。他チームの依頼を聞きながら、その根底にある問題が何かを考え、期待する結果や成功の測り方を決めるのだ。これらを咀嚼して、顧客とビジネス両方の課題を解決する策を考え出すのが仕事になる。この解決策とは、4つのことを意味する：
顧客がそれを買い、使いたいと思う
顧客がそれを使いこなせる
チームに与えられている時間・スキル・技術で形にできる
他チーム（財務、法務、マーケ等）の制約を満たせる
何故、この働き方が良いのか。オーナーシップを持つことによる士気向上や、ユーザーとのテスト等を通じて得られる知識もさることながら、一番の理由は、権限のあるエンジニアこそが、イノベーションの源泉だからであり、権限のあるプロダクトチームを作ることでその環境が整うからだ。エンジニアは、日々最先端の技術に触れているため、何が実現可能か分かる理想的な立場にいる。権限移譲されたエンジニアがPMやUXデザイナーと協力し、顧客と直に接点を持ちながら開発に取り組むことで、顧客が熱狂するプロダクトを形にすることができる。日々開発を外注している企業にとっては、このエンジニアに対する考え方は哲学的な飛躍と言える。エンジニアが、良いUXを理解しているデザイナーと、顧客とビジネス両方のニーズを理解しているPMと組むことで、顧客が熱狂し、ビジネス課題も解決できるプロダクトを作れるチームが揃う。
②-2-b. 高頻度の実験を積み重ねる
プロダクトチームに課題と目標の責任を持たせると、彼らは、機能のリリースより、それらが実際にお金を生む（＝結果を達成する）までの時間を縮めようと動く。時間を短縮するには、様々なアイデアが良い解決策かを見極めなくてはならないため、そのアイデアを素早くテストするようになる（例：プロトタイプ）。この過程を、プロダクト・ディスカバリーと呼ぶ。
一般的には、市場に投入した機能が必要なリターンを生むまでに3~5回の反復が必要となる。チームに作る機能を指示すると、各ステージで数カ月、つまりリターンを生むまでに最低1~2年かかる。一方、チームに権限移譲すれば、それぞれの反復を数日～数週間で行うことができ、わずか数カ月でビジネスの成果に繋げることも可能となる。権限移譲された小さなチームが、遥かに人数の多い機能チームを凌駕できるのは、この働き方の違いにある。
②-2-c. 関連事業部と真の共同関係を築く
お金と時間を節約すること以上に重要なメリットは、問題解決の方法自体を変えることで、一貫して顧客に対して価値を創造できる仕組みを作り出せることだ。プロダクトチームは、関連事業部（例：営業、財務、法務）に仕えるのではなく、顧客に仕えながらビジネスとして成り立つ方法を考えるチームになる。この違いは些細ではなく、組織の考え方を根本的に変えることである。
これは、関連事業部が人的資源を掌握する権限がなくなることを意味しており、この変化を良く思わない人が出てくる。受動的に抵抗する社員や、能動的に反発する社員も出てくるかもしれない。CEOが最大の旗振り役でないと改革が失敗するのは、このためだ。
また、現役のPM・デザイナー・エンジニアの中には、追加の責任を担う意思や能力がない人もいるかもしれない。課題を解決する責任を負うのは、言われたことをそのままやるよりよほど難しい。強いプロダクトチームを作るには、適切なメンバーを配置し、彼らが成功するために必要なコーチングと背景を提供しなくてはならない。
②-3. 解決すべき問題の選び方を変える
では、そのプロダクトチームに与えるべき課題は、どう選べば良いのか？与える課題が本当に顧客や会社にとって解決すべきものでなければ、事業の舵取りを間違えてしまう。多くの企業では、財務や役員が計画会議で提出された案を吟味して決めるが、これでは長期視点で一貫性のある判断ができない。一貫性のある判断をするためには、顧客起点のビジョンと、洞察に基づいた戦略を定め、それを基に解決すべき課題を選ぶ必要がある。
②-3-a. 顧客起点のプロダクトビジョン
多くの企業では、競合の新製品や、顧客の要求、価格改定など、何かに「反応」するために費やす時間が多い。良いプロダクト作りができる企業は、もちろんこれらの課題も気にするが、それに駆り立てられてはない。これら企業を駆り立てるのは、顧客の生活にインパクトを与えるビジョンの追求だ。実際、このような企業では、社員の心を動かす魅力的なビジョンこそが、採用力の源泉となっている。強いビジョンは組織を長年に渡り鼓動することができる。
これは奥深い話なので、別途書く機会を設けたいが、良いビジョンとは先ず第一に、企業の収益や四半期の優先事項等の社内事情ではなく、顧客についてのビジョンである必要がある。顧客の生活をどう改善し、どんな未来を創りたいのかを語らなくてはならない。また、多数の事業がある企業では、それら事業群を結びつけ、チームが一丸となれる共通のビジョンが必要となる。
②-3-b. 洞察に基づくプロダクト戦略
戦略とは、実現したい未来に向け、今解決すべき最も重要な課題の特定の仕方と言える。「良い戦略、悪い戦略」の筆者リチャード・ルメルトはこんな言葉を残している。「多くの企業、特に大企業は戦略がない。戦略とは集中であり、殆どの大企業は資源を集中できていない。代わりに、彼らは同時に複数の目標を掲げることで、それぞれにブレークスルーに足りない量の資源を割り当てている。」二兎を追うものは一兎も得ずとはよく言ったものだ。
いくつかの重点領域を特定したら、次に、どの洞察（インサイト）に賭けるかを選べなくてはならない。顧客のデータや、顧客との会話に基づく定性的な情報、業界や技術のトレンドを鑑みて、その中から最も重要な課題を選んでいく。洞察に基づく課題選定は、企業にとっては新しい筋肉を鍛えるようなエクササイズとなるが、その力をつけることで、テクノロジーへの投資から最大限のリターンを得る基盤を作ることができる。
ここでいうプロダクト戦略とは、ビジネス戦略や、マーケティング戦略とは異なるものと理解することが大事だ。自社のプロダクト戦略が、「他事業部のニーズに応える」だけならば、それはプロダクト戦略が存在しないのと同義と言える。
②-3-c. リーダーシップの役割
変革に取り組む殆どの企業は、プロダクトチームのレベルを引き上げる必要があることは理解している。より経験豊富でスキルのあるエンジニア、UXデザイナー、PMを日々探している。しかし、あまり理解されていないのは、多くの企業でプロダクトチームのリーダーシップにさらに大きなギャップがあることだ。プロダクト運用モデルでは、顧客が必要とする解決策をより効果的にメンバーが見つけ出し、リリースするためのコーチングは、リーダーの非常に重要な役割となる。どの問題を解決するか、問題をどう解決するか、解決策をどう形にするか、の全ての活動は、リーダーシップの手腕にかかっているのだ。
③. プロダクト運用モデルの原則
さて、上記までで「どう変わらないといけないか」を概念レベルで説明させて頂いた。これ以降は、「日常的にそれをどう実践すべきか」の指針となる20の「原則」を駆け足で紹介したい。「これをウチの会社で実践したい！」と思う方は是非お読み頂き、「概念として分かったので一先ずOK」と思う方は、長いので、流し読み頂く程度で良いかと思う。
これらの「原則」は、大きく5つの種類に分けられる：
機能横断型のプロダクトチーム
ビジョンと洞察に基づいたプロダクト戦略
適切なリスク評価と実験に基づいたプロダクトディスカバリー）
頻繁かつ堅牢なリリースを実現する、プロダクトデリバリー
革新を起こし続けるためのプロダクトカルチャー
③-1. プロダクトチーム
③-1-a：問題解決の権限を与える
前述の通り、権限のあるプロダクトチームとは、顧客が熱狂し、かつビジネスの成長に繋がるための課題解決を任されているチームのことである。プロダクトチームは課題を与えられ、それを解決するための最適解を決める責任を負う。これは「ITモデル」のように、依頼された機能やプロジェクトを完遂する働き方とは大きく異なる。
③-1-b：リリースより成果を重んじる
顧客の問題を真に解決するには、いくら機能をリリースしても、それが成果に繋がらないと、意味がない。例として、これを理解しているチームは、機能のリリースばかりに気を取られずに、機能を減らした方が良い顧客体験になるかも？という可能性も検証する。（これは特にモバイルアプリでは有効な打ち手の一つ。）
③-1-c：開発まで責任を持つ
プロダクトチームは解決策の発見と共に、その解決策の納品にも責任を持つ必要がある。これら2つを異なるチームに分けると、「言うだけの人」と「やるだけの人」の溝という、カルチャー的にも日常業務的にも大きな問題が生じてしまう。尚、時間配分は、デザイナーとPMは解決策の発見に主に時間を割き、エンジニアはそれの開発に主に時間を割くのが一般的。
③-1-d：真の協力関係を育む
プロダクトチーム内での良い協力関係とは、意見を一致させることでもなく、民主主義でもなく、要求を通すことでもなく、妥協することでもない。良い協力関係とは、価値があり、使いやすく、開発可能で、ビジネスとして成り立つ解決策を形にするために、お互いの専門分野を尊重しながら一緒に最適解を見出すことだ。この最たる例が、デザイナーが作成したモックアップを基に行うブレストだ。エンジニアが新たな作り方を提案し、デザイナーが様々な顧客体験を幅出しし、PMがそれらが顧客やビジネスに与える影響を示す中で、アプローチが収れんされていき、最適な解決策に辿り着く。意見が収れんしない時は、主にテストを行うことで判断材料を得て前に進む。
③-2. プロダクト戦略
③-2-a：選択と集中
スティーブ・ジョブスの言葉を借りると、「集中とは、他にも沢山ある良いアイデアにノーと言うこと。イノベーションとは、1,000のことにノーと言うことである。」集中するためには、会社のトップも意思決定に関わり、プロダクトリーダーは政治的な意図を持たずに透明性のある説明と提案をしなくてはならない。その上で、CEOが2~3程の最重要目標を選ぶと、それに基づいて組織が動けるようになる。その目標が何であるかより、それを決めたこと自体が重要で、これによって、「目標が多すぎて何も達成できない病」から免れることができる。
③-2-b：洞察による裏付け
集中するには規律が必要だが、何に集中するかを見分けるには洞察を得るスキルが必要。これらの洞察の主な源は、以下のようなものが一般的。
データ分析：顧客がプロダクトをどう購入・使用しているかのデータ
顧客との会話：顧客が今使用しているツール、環境や悩み、ツール切り替えに必要な要素、等
新たな技術：新たな技術が開く機会や体験、解決できるようになった問題
業界のトレンド：市場環境や顧客期待の変化から学べること
プロダクトリーダーはこれらの洞察を吸収し、分析する責任を持つ。洞察はどこからでも得られるので、企業は、全社員が得た情報のプロダクトリーダーへの共有を推奨すべき。
③-2-c: 透明性の担保
プロダクト運用モデルでは、どの問題を解決するかの決定権が、事業部からプロダクトチームに移るため、事業部や関係部署の嫉妬を招きやすい。このため、プロダクトリーダーが意思決定のためのデータや考え方を公開し、透明性を保つことが非常に重要となる。また、実行できる戦略を作るには、関連部署の賛同や協力を得るために、考え方を丁寧に説明していかなくてはならない。
③-2-d: いくつかの賭けをする
良い戦略とチームがあっても、四半期毎に全チームから期待通りの成果が出るわけではない。やってみたら想定より難しかった、あるいは思うような結果が出なかった、ということはよくある。このため、前述の2~3の最重要目標を選んだら、これらを「賭け」だと認識し、少なくともそれらのうち1つが次の四半期に結果を出すことを期待しながら、チームを監督していく必要がある。
③-3. プロダクトディスカバリー
③-3-a：無駄の最小化
プロダクトディスカバリーの最初の原則は、課題解決に必要な努力と時間の無駄を最小限に抑えること。伝統的な「ITモデル」のように、仮説を作り、エンジニアにそれを作れと要求することはできるが、この手法で作られる機能の7~9割は想定した結果に繋がらない。これでは、投資した費用だけでなく、その間他にできたことの機会損失という無駄も発生してしまう。賢い企業は、なる早でアイデアをテストし、作る価値のある機能を特定してから、その解決策を顧客にリリースすることで、大幅に無駄を削減している。
③-3-b：リスクの適切な評価
プロダクト作りには、必ずリスクがつきまとう。主には、①価値（顧客がそれを買いたい・使いたいと思うか）、②有用性（顧客がそれを使いこなせるか）、③実行可能性（他チームの制約を満たせるか）、④実現可能性（チームに与えられている時間・スキル・技術で形にできるか）の4つのリスクがあり、意思決定をする前にこのリスクを適切に評価・対処することが必要だ。
③-3-c：実験の受け入れ
これらのリスクに対応するには、自分達のアイデアが仮説にすぎないことを認識し、それを検証するための実験をしなくてはならない。また、実験は、チーム内で意見が分かれる時にも非常に有効で、顧客の反応を見ながらどのアイデアを採用するかを見極めることができる。実験する際は、定量及び定性両方の情報が必要で、定量情報を通じて顧客がどうプロダクトを使うかを把握し、定性情報を通じて顧客が何故そのように使うのかを理解しなくてはならない。
③-3-d：責任あるテスト
これは主に一定規模に成長した企業に言えることだが、このようなテストを行う際に、会社の収益・評判・顧客を損なわない形で行う必要がある。また、営業やカスタマーサクセス等、顧客から最初に質問を受けるチームには事前に情報共有しておかないと、彼らが不意打ちを食らうかもしれない。事前にこれらのことも考え、責任のある実験を行うことが重要だ。
③-4. プロダクトデリバリー
③-4-a：小規模、頻繁、かつ分離されたリリース
顧客のニーズに応えるための開発の第1原則は、小規模、頻繁、かつ分離されたリリースだ。目安は2週間に1度、早ければ1日に数回リリースする企業もあり、これを継続的インテグレーション（CI）・継続的デプロイメント（CD）と呼ぶ。我々がスマホアプリの新機能に気づかない理由は、まさに提供者が絶え間なく小さいリリースを行っているからなのだ。リリース時に信頼性を担保するのは実は複雑で、新しい機能自体をテストするだけでなく、それを導入した時に他の既存機能が壊れないかを確認する必要がある。これを回帰テストと呼ぶ。リリースの単位が小さい程、問題が起きた時に特定しやすいが、逆に四半期に一度などに何百・何千もの変更を詰め込もうとすると、問題の特定が非常に困難になり、解明中は問題を起こしていない機能もリリースできなくなる。SaaSプロダクトだと、顧客からリリースをまとめて欲しいという要望もあるようだが、それは顧客のためにもならないため、新機能のアクセス権限など、別の方法で対処した方が良い。
③-4-b：新機能の計測
プロダクトモデルでは、仕事は納品では終わらず、成果を出す責任を負うため、機能がどのように（あるいは実際に）使われているかが不可欠だ。そのためには、その機能の使用状況や過程が分かるデータやダッシュボードを作らなくてはならない。これにより、問題があればすぐに把握し、機能が価値を提供しているかを検証することができる。このデータは、機能の使い方の理解が深まるにつれ進化していくため、絶えず改善していく必要がある。
③-4-c：全機能のモニタリング
また、全ての機能を常にモニターできるデータの整備も不可欠だ。システムやアプリケーションが正しく動作し、問題があれば顧客が発見する前に検出しなくてはならない。また、これらのデータに機密情報や個人情報が含まれていないような設計が必要だ。
③-4-d：提供インフラの整備
もう1つ大事なものが、機能を提供する（デプロイメントと呼ぶ）インフラだ。新しい機能をリリースする準備が整ったら、先ずそれを導入した時に、問題が起きたらその変更を取り下げできる仕組みが必要だ（これをロールバックと言う）。また、全てが正常に動作していても、新しい機能をリリースしたら、(i) 顧客がそれをすぐ使うようになるか、(ii) 顧客がそれを画面上で見つけられないか、(iii) 顧客に見えるけど使われていない、といった様々なシナリオがあり得る。これを予め把握するには、A/Bテストができるインフラを整えなくてはならない。代表的なプロダクトカンパニーでは、日常的に数百ものテストが同時に走っており、これらの結果を基に新しい機能をリリースするかの意思決定を行っている。
③-5: プロダクトカルチャー
③-5-a：プロセスより原則
歴史上、革新的な企業として知られていた会社が、次第にイノベーションを起こす力を失った例は枚挙にいとまがない。ジェフ・ベゾスは、この現象について以下のように語る。「良いプロセスは顧客に良いサービスを提供する助けになるが、注意しないと、プロセス自体が目的になってしまう。これは大企業では容易に起こる。プロセスに支配されていないか、常に自問しなくてはならない。」リード・ヘイスティングスも同様に語る。「Netflixがこれほど成功している理由は、プロセスよりも人を重んじ、効率より革新を重視し、社員への制約を最小限にとどめているからだ。」プロセス自体が悪いわけではないが、社員が間違いを起こした時に、プロセスだけに頼らずコーチングを行うことで、よりオーナーシップと判断力のある社員を育てることができる。
③-5-b：コントロールより信頼
プロダクト運用モデルへの移行は、根本的なカルチャーの変化を必要とする。トップダウンの指揮統制モデルでキャリアを築いた人々は特に、意識的に課題解決の権限と責任を社員に委譲し、彼らをコーチングを通じて育てるスタイルに変わらなくてはならい。
③-5-c：予測可能性より革新
多くの企業は、四半期毎に計画通り機能を納品することに焦点をあててしまいがちだ。だが、アジャイルのコーチ、ヘンリク・ニーバーグの言葉を借りると、「100％予測可能＝0％革新」だ。予測可能性が高まることは良いことだが、イノベーションを起こすこと程大事ではなく、議論・開発しながら見えてくる学びを基に軌道修正する柔軟さも大事である。
③-5-d：失敗より学習
多くの企業では、失敗に対する根深い恐れがある。失敗を美化する必要はないが、イノベーションにリスクはつきものなため、ある程度の失敗は免れない。この時に、「何を学んだか」焦点をに当て、次に活かすことが大事だ。ジェフ・ベゾスの言葉を借りると、野球ではホームランを打っても4点しか入らないが、ビジネスではホームランが1,000点になる時もある。空振りを恐れずに、そこから学び、次のホームランを仕掛ける姿勢が将来を左右するかもしれないことを覚えておきたい。
以上、もしここまで読んでくださった方がいたら、両手を合わせてお礼を申し上げたい。また、私が新卒の頃から抱いていた、日本企業のイノベーションの役に立ちたいという思いは10年以上経っても変わらないので、ご相談に乗れることがあれば是非お気軽に相談頂きたい。先日、Webミーティングのスケジュールサイトも作成したので、もしご興味あれば是非ご活用頂ければと思う。
この記事が気に入ったらサポートをしてみませんか？