トランスフォーメーションのストーリー: 丸井グループ
これはプロダクトマネージャー Advent Calendar 2024 並びに
🎄丸井＆Muture アドベントカレンダー2024🎄 12日目の記事です。
みなさん、こんにちは！
Muture、そしてマルイユナイトのかねはらです。
現在、丸井グループとGoodpatchのジョイントベンチャーであるMutureに属しており、半分中・半分外という立場から丸井グループのトランスフォーメーションの支援をしています。
このトランスフォーメーションにおける一つのマイルストーンとして、今年の10月にmarui unite（マルイユナイト）という会社を設立しており、こちらの会社にもCPOという形で所属をしております。
今回は、まだまだ道半ばではありますが、今年発売されたTRANSFORMED内の項目をなぞり、「トランスフォームのストーリー: 丸井グループ」として、Mutureが設立されてから丸井グループとの2年半の歩みについて振り返ってみようと思います。
動機
Mutureの設立から、直近のマルイユナイトの設立までの流れについては以下のように表すことができます。
大企業を変革していくための一歩目として、大企業とテック企業の合弁会社をまず作るというある種突飛なアプローチにも見えるかもしれませんが、結果としては上図のように「出島」から「本島」にむけて丁寧にステップを重ねていきながら、徐々に新しい文化を形成し、広がっていっています。
なお、図における②③の歩みについては以下の記事でも触れております。
ここからは、この①~④の歩みについて順を追ってみていきます。
Phase1: 課題特定期 - Mutureの設立とエスノグラフィー
丸井グループは「知識創造型企業」への転換を掲げており、無形資産に対する投資を2019年より強化をしています。
ですが、この転換にむけては、求められる人材要件やデジタルケイパビリティにおいて大きなギャップがあることが明らかとなります。
このような背景があった中で、丸井グループとGoodpatchの両オーナーの不思議な出会いがあり、意気投合の末、2022年4月に両社の合弁会社としてMutureが設立されることとなります。
Mutureは、いわゆるアプリ開発やデザインを担う会社でもなければ、コンサル的に特定のイシューを解決するような会社でもありません。
あくまで企業自ら変革を実現できるように支援していくことがメインテーマであり、その企業自身が持つ課題解決力を向上させていくために、経営・組織・プロダクトのそれぞれのレイヤーに対して伴走をしていきながら、最終的には卒業をしていくことをゴールとしています。
Muture設立後、早速丸井グループの各種プロダクトに対して支援にあたりますが、この時点においては組織やプロダクト自体に対して手は入れておらず、Mutureの専門人材が各組織の中に入り込みながらエスノグラフィを行い、会社が持つ文化やプロセスへの理解を深めることに注力していた期間となります。
そのため、このタイミングでコミュニケーションの透明性を高めていくことを目的に、「デジタル三種の神器」を支援先チームに先んじて導入をすることで、エスノグラフィーの質を高めていくことを取り組みました。
Phase2: 改善探索期 - パイロットプロジェクトの立ち上げ
Mutureは、経営から事業やプロダクトまで、階層や部門を横断した包括的な支援を行っておりますが、あくまで企業体としては別の会社であるため、会社における組織構造や制度といったハード面に対してアプローチをすることは困難です。
そのため、Mutureの設立後まもなく丸井グループ直下にもDX推進室が設立され、アジャイルCoEのような形での共同体制を取っております。
これによって、経営から現場までに1つの串を刺すように、トップ⇔ボトム双方の観点から課題の抽出から解決までを実現しています。
この構造を前提に、Phase1で見えてきた課題に対してDX推進室と共に具体的なアクションを実行していきます。
バリューストリームに沿った組織の統廃合
パイロットプロジェクト(≒ 社内特区)の立ち上げ
「価値探索」「価値検証」のスキル獲得
丸投げな開発体制からの脱却
etc…
これらの取組みについて「エンタープライズアジャイル」を旗印に、丸井グループの経営層のバックアップを得ながら、一歩目を踏み出していきます。
Q. なぜ「アジャイル」ではなく「エンタープライズアジャイル」なの？
A. 当時、「アジャイル」はどうしても「開発手法である」という先入観が強く、ビジネス側の巻き込みや組織・制度までがスコープに入るという理解を得にくく、目線合わせという意味でミスリードがありました。
そのため、別のコンセプトを当てる必要があったのですが、大企業特有の課題を背景としたうえでのアジャイル推進を意味する「エンタープライズアジャイル」というワードを持ち出したところ、経営含めてこれがピタッとハマったため採用することとしました。
Phase3: 変革推進期 - 社内特区を会社単位へスケールアップ
兎にも角にも、Phase2で立ち上げたパイロットプロジェクトがうまく行かないことにはアジャイルの火は潰えてしまうため、ここはとにかく一生懸命がんばります。笑
ここの歩みについては以下のnoteをご覧になってください。
…というのがA面であり、本丸はこのパイロットプロジェクトとほぼ同時期に立ち上げられたB面としての新会社立ち上げプロジェクトです。
Phase1と同様に、社内特区として立ち上げられたパイロットプロジェクトに対するエスノグラフィーを通じて、丸井グループ内でこの取組みを拡大していく際に生じるであろう阻害要因について正確に洗い出していきます。
一方で、Phase1との違いとしては、Phase1ではあくまで既存の業務の延長線上から上がってくる課題だけでしたが、本フェーズでは丸井グループ内では前例の無い取組みを特区として推進していたため、上がってくる課題の質は大きく変わります。
ビジネスプロセス、決裁構造、予算組み
システムアーキテクチャ、情報システム・セキュリティ
採用、人事・等級・評価制度
etc…
など、領域問わずすべての課題を俎上に乗せたうえで、パイロットプロジェクトとは別の枠組みとして、これらの課題についてどのように解決していくかを検討するタスクフォースを別途立ち上げ、対応を進めていきました。
対応を検討する中で、やはりグループ共通の制度に手をいれるにはあまりにも影響範囲が大きすぎるため、どうやら新会社を設立する他なさそうだいうことで方向性が固まっていきます。
このように、「現場の動きを変え」→ 「新たに生まれた課題について対応をする」というプロセスは、ステークホルダー間の議論を円滑なものにし、早期の合意形成にも役立ったように思います。
外部事例をベースに議論を展開するAs-Is→To-Beのアプローチではなく、実際に生じた課題をベースに議論を進めていくFrom-Toのアプローチの方が、変化を生み出す観点においては摩擦が少なく最終的なゴールも早くなるのだなという学びも得られました。
A面で進めていたパイロットプロジェクトが完了したタイミングで、B面で進行していた新会社の立ち上げを実行し、パイロットプロジェクトをそのまま新会社に組み込む形で合流させました。
これにより、社内特区から会社単位にまで変革のスケールを拡大することができました。
Phase4: 変革実践期 - 変革の波をグループ全体へ波及
マルイユナイトは「ビジネスとテックを一体とする」ことを掲げており、自社での企画や開発の他に、事業会社とシステム会社との橋渡しも担っています。
Phase1~3はあくまでパイロットプロジェクト内で完結し、尚且つ解決可能な範囲で進めていましたが、Phase4からは各種事業会社と連携しながら個別最適な意思決定を全体最適となるように変えていくフェーズとなります。
ある種、鎖国状態だったものを開国させていくことになるため、会社間の連携においてこれまでにはなかった新しい課題が噴出してきます。
ですが、これまでの学びの通り、新しいことを始めたらまずは焦らずエスノグラフィーです。
まだ始まって2ヶ月ほどなので、まだまだ書けることは少ないですが、また来年のアドベントカレンダーあたりで共有できるように頑張っていきます。
プロダクトモデルへのトランスフォーメーション
ここからは、Phase1～4の取り組みを通じて学んだ、トランスフォーメーションを実現するために個人的に有用だったなと感じているポイントについてご紹介をしていきます。
不確実性を早期に抑制するための「アジャイルシフトレフト」
ここで紹介する「アジャイルシフトレフト」という考え方は、大企業のトランスフォーメーションにおいて最もコアにおいていたコンセプトであり、プロダクトマネジメントのナレッジが大企業変革においても非常に役立つという話にも繋がっていきます。
プロジェクトの進行によって不確実性が抑制されていくという「不確実性コーン」という考え方はご存知でしょうか。
三つめは「不確実性の減るペース」です。グラフではマイルストーンが等間隔で配置されているため、プロジェクトの後半（「ユーザーインタフェース設計完了」の段階）になってやっとバラツキが「0.8～1.25倍」へと縮まっているように見えます。しかし、実際のタイムスケール的には初期30パーセントの時点でここに到達します。このことから、プロジェクト初期に不確実性に対処することがいかに重要であるかが分かります。
部分的な情報からの見積り
細部が決まっていない状況で、見積りを行う場合が多い（予算決めなど早い段階）。
⇒ 部分的な情報から、推測するしかない
⇒ 実際とぶれがでることは避けられない
これらを踏まえると、プロジェクト全体をトータルで見た際の不確実性を抑制していくために、いわゆる上流工程で工夫できる点は多そうです。
一方で、プロジェクト進行の観点においても、失敗は早ければ早いほどコストは低く、後になればなるほど取り消し不可能なほどに増大することもまた知られているため、Fail fast learn fast（早く失敗し、早く学ぶ）が大事であることもまた有名な話かと思います。
このような話を踏まえると、アジャイルは開発工程だけで実現ができても、不確実性を低減されるという観点においては効果は不十分であり、むしろ不確実性が大きい「初期コンセプト」から「要求の完了」までの前工程において、アジャイルな価値探索を実現し進めていく方が合理的なように思えます。
このような仮説に基づき、アジャイル推進の1歩目として開発工程は選択せず、前工程である企画〜要求定義のプロセスから適応していくことを選択しています。
(そして、この戦略を「アジャイルシフトレフト」と"今"名付けました。笑)
プロダクトマネジメント的な文脈でいうと、継続的なプロダクト運営を前提においた際には「方法不確実性」を下げることに躍起になるよりも、「目的不確実性」を下げることに注力したほうが、アウトカムを最大化していくという観点において合理的であろうという言い方もできます。
プロダクトマネジメントの観点から企業変革を捉えた本としてTRANSFORMEDが書かれたというのも、このような特色があるからではないかと、実際にやってみて感じています。
よく、なぜプロダクトマネージャーが大企業の変革を？という質問をいただくのですが、感覚値としてもプロダクトマネジメントの知識やマインドセットは、大企業変革に求められるケイパビリティと一致しているように感じており、相性が良いのだと思います。
なお、今日時点においても開発工程において明示的にアジャイルといった概念は導入しておらず、開発工程の多くは企画時点でバッチサイズを小さくした、いわゆるミニウォーターフォール型として進行しています。
裏を返せば、2年半の歩みがあってなお、僕の中において開発組織のアジャイル化に対する優先度は高くなかったということでもあります。
※ もちろん、Phase4以降については開発組織の内製化というテーマにあわせて、開発組織側の取組みを重点項目として推進していきます。
トランジションの鍵となる "Innovator & Bridger"
Two Loops Modelというものはご存知でしょうか？
これの解説については、ChatGPT先生にお願いをしたものを以下に添えておきます。
Two Loops Model（ツーループモデル）は、社会変革や組織の変革プロセスを説明するためのフレームワークで、古いシステムが衰退して新しいシステムが成長していく過程を、2つの相互に関連するループで表現しています。
それぞれのループは、古いシステムの衰退と新しいシステムの台頭を示します。
このモデルは、組織や社会全体が変化する際に、古いシステムを否定するのではなく、その価値を認識しながら新しい可能性を育てていくプロセスを強調します。持続可能性、社会運動、組織変革など、多様な分野で応用されています。
■ モデルの構成要素
・第一のループ: 古いシステムの衰退
古いシステムはそのピークに達した後、次第に効率が低下し、衰退の道をたどります。システムの課題や限界が目立ち始め、これにより多くの人々が変革の必要性を感じます。
古いシステム内の「スティワード（Steward）」と呼ばれる人々は、システムの維持や変革をサポートしながら、次の段階を模索します。
・第二のループ: 新しいシステムの台頭
同時に、新しいアイデアやアプローチが生まれ、成長を始めます。「イノベーター」や「先駆者」は、新しいシステムの構築に取り組みます。この段階では実験と試行錯誤が重要です。
新しいシステムは、小さなコミュニティやネットワークを通じて広がり、古いシステムに代わる力を持つまで成長します。
■ キーとなる役割
スティワード（Steward）: 古いシステムの価値を守りつつ、次の世代にそれを引き継ぐ。
イノベーター（Innovator）: 新しいアイデアやソリューションを提案し、小さな実験を通じて成長を促す。
ブリッジャー（Bridger）: 古いシステムと新しいシステムを橋渡しし、変革を加速させる。
組織変革を支援しているというと「イノベーター」としての振る舞いをイメージされるかもしれませんが、それは正しくはありません。
対象組織内における「イノベーター」をいち早く発見し、そのイノベーター同士をつなぎ合わせていきながらコミュニティ形成を支援する
新しいシステムが形成されてきたら、「ブリッジャー」として2つのシステムが摩擦なくつながっていくように支援をする
この「イノベーター」「ブリッジャー」の2つの役割があってはじめてトランジションが生まれます。言葉にすると非常に単純なのですが、これを大企業の中で実践していくことは至難の業です。
また、仮に支援者がどれだけ頑張ったとしても、そもそも「イノベーター」が生まれにくい土壌だと、トランジションが生まれるはずもありません。
このような文化的土壌の重要性については、DX推進室のいとうさんの記事にて語られております。
🕺あなたが踊ることで、変革は加速していきます💃
短期の成果、長期の変革
多くの場合において、企業変革を求めているのは、あくまで会社であり経営層です。もちろん事業側も変革について他人事なわけではありませんが、基本的には収益を向上させるためのビジネストランスフォーメーションの話であり、指しているものは異なります。
例えば丸井グループの場合は、VISON BOOK 2050を作成しており、そこに向けての取組みとして中期経営計画が5年毎に策定されています。
一方で、事業会社は基本的には毎年の決算が重要なマイルストーンであるため、中期経営計画からバックキャストした年単位のサイクルで活動を行っています。
つまり、2050年を見据えると、次の5年でこの会社は変わっていかねばならぬ！と掲げたとしても、実際にこのアクションの影響を受ける大半は事業側の社員です。
事業会社は組織変革だけを頑張っていたらいいのかというとそんなはずはなく、従来通り事業数字の成果も求められます。つまり、事業会社は組織変革と事業成果という二倍の負荷がかかることになります。
だからこそ、組織変革に携わる人はあるべき論だけをかざすのではなく、この異なる2つの時間軸を理解しながら「短期の成果、長期の変革」というスタンスを徹底して持つことが重要であると考えています。
プロダクトチーム組成に向けた、 「育成」「パートナーシップ」「採用」
プロダクトモデルへのトランスフォーメーションに向けては、この核を担う「プロダクトチーム」の立ち上げが肝となります。
・プロダクトモデル・コンセプトの中で最も基礎的なものは、エンパワーされた職能横断型のプロダクトチーム、というコンセプトである。
・職能横断型のプロダクトチームには、プロダクトモデルの各コンピテンシーをカバーできるメンバーが揃っている必要がある。
・通常、各コンピテンシーとはプロダクトマネジャー、プロダクトデザイナー、そしてエンジニアのことを指す。
この3つのコンピテンシーを一つのチームに集めればOKなのですが…..
大企業に所属する多くの人材は「ビジネス総合職」であり、いわゆる3つのコンピテンシーに類する専門性の多くは、外部パートナーへアウトソースしていることがほとんどです。
つまり、どこをどう探しても、定義された3つのコンピテンシーは社内の職種として存在する可能性は限りなくゼロであるといえるでしょう。
では、「中途採用」を進めていく他ないのか？という話になりますが、その前にもう少し具体的に各コンピテンシーがどのような責任を担っているのかについて見てみましょう。
■ プロダクトマネージャー
・実行責任: 「価値リスク」「事業実現性リスク」
・説明責任: 「プロダクトのアウトカム達成」
■ プロダクトデザイナー
・実行責任: 「ユーザービリティリスク」
・説明責任：「プロダクト体験」
■ テックリード
・実行責任: 「実現可能性リスク」
・説明責任: 「プロダクトのデリバリー」
このようにしてみると、少なくともここの定義における「プロダクトマネージャー」相当の責任が企業内において不在である可能性は低く、おおよそデジタルプロダクト部門の部課長相当が担っているのではないでしょうか？
一方で、「プロダクトデザイナー」「テックリード」については企業の業種や特性によってばらつきがありそうですが、例えば情シス子会社が存在する場合はここが「テックリード」相当の責任を担っているともいえます。
市場におけるジョブ定義とは完全に一致はしなくとも、社内における職務分掌であったり、これまでの社内キャリア、個人特性などを鑑みながら、バイネームレベルで探すと、コンピテンシーに近い人材はきっといるはずです。
このように、各コンピテンシーと対象企業内に有するケイパビリティを照らし合わせながら、今組織に足りないものを見極めていくことで「育成」「パートナーシップ」「採用」といった人材戦略を、プロジェクトやプロダクトの特性を元に決定していくとよいでしょう。
Phase2のパイロットプロジェクトにおいては、以下のようにプロダクトチームを構成し、推進をしました。
■ プロダクトマネージャー
プロダクト部門の部課長(丸井G) + PdM伴走(Muture)
■ プロダクトデザイナー
UX ResearchとUI Designに分解。
UX Research → プロダクト部門の一般社員(丸井G) + 伴走支援(Muture)
UI Designer → パートナー企業に半常駐前提で依頼(Muture)
■ テックリード
情シス子会社所属の一般社員(丸井G) + パートナー企業に依頼(外部企業)
また、先述の「アジャイルシフトレフト」の考え方に基づくと、「プロトタイプ」は重要な役割を果たします。そのため、「プロダクトデザイナー」が1名いると働き方も大きく変えることができるため、相対的に優先度が高いと考えています。
なお、「採用」という選択肢は、その必然性が明らかになるまでは取らないことをおすすめします。なぜならば、外部人材にとって魅力的な環境や活躍できる土壌がないという採用以前の課題があまりにも多いからです。
「プロダクトトライアド」だけでは足りないなにか
会社の設立とともにデジタル的な観点が織り込まれているようなIT・テック企業においては、プロダクトトライアドという小さなチームを組成し、ディスカバリーを重ねていくという体制は自然な形です。
ですが、DXが課題とされているようないわゆる日本の大企業においては、メンバーシップ型が基本であり、ジョブローテーション等で経験を重ねることでその人にナレッジが溜まっていくという発想が起点にあり、いつでも誰でも手に取りやすいようなナレッジマネジメントは行われていません。
そのため、組織単位で情報が断片化しており、たとえプロダクトトライアドを形成しようとも意思決定に足るだけの情報を得ることは不可能です。
このような状況も踏まえ、プロダクトトライアドに加えてTwo Loops Modelでいう「ブリッジャー」を加えた「プロダクトトライアド + 1」の体制となるように意識した組織づくりをおこなっています。
この「ブリッジャー」はある種、既存組織というドメインのスペシャリストでもあるため、
断片化している情報の所在がわかり、集めてくることができる
事業状況と内部の温度感を理解しており、施策の妥当性を評価できる
組織の力学を理解しており、正しく調整をすることが出来る
などの動きによって、組織間のアラインメントを強固なものにしつつ、プロダクトトライアドも有効化されていきます。
この「ブリッジャー」は、僕の目線からみると大企業におけるプロダクトマネージャーの1つの像にも思えます。
もちろん、暗黙知が減っていき形式知化が進んだ先には、プロダクトトライアドにおける一般的なプロダクトマネージャーロールと一体化させるのが合理的ではありますが、そうでない状況においては明示的に役割として分離させておくのがよいと思います。
作り方を変える
この2年半、なにも変えていません！(キッパリ)
先述の通り、アジャイルシフトレフトの考えに基づいて、企画プロセスにおける継続的なProduct Discoveryの浸透を優先していたためです。
一方で、ベンダー企業との関係性については全体的に見直しをかけました。
経済産業省のDXレポートによると、ユーザ企業とベンダー企業は「低位安定」の関係にあると指摘をされています。
既存産業の業界構造は、ユーザー企業は委託による「コストの削減」を、ベンダー企業は受託による「低リスク・長期安定ビジネスの享受」という一見Win-Winの関係性にも見えますが、多くの場合、両者はデジタル時代において必要な能力を獲得できず、デジタル競争の敗者となる「低位安定」の関係性となっているのが現状です。
これは他人事ではなく解決しないといけない課題である一方で、会社間の問題でもあるため、時間がかかることを見越し、早い段階から取り組みを進めていきました。
例えば、従来のベンダー丸投げの開発体制から、スクラム的に企画チームと開発チームが一体となって進められるように、パートナー企業の選定や契約内容をゼロベースで見直しています。
あわせて、発注者である丸井グループ側に対しても、ベンダー企業との共創体制やコミュニケーションのあり方について支援を行っています。
また、あわせてブラックボックス化していた資産や知識についても、共同管理体制となるように、各種ツールの契約からアカウント管理含めて見直しを行い、今後の内製開発体制へのシフトを円滑にしていくための土台固めを行いました。
問題解決の方法を変える
デュアルトラックアジャイルによる継続的な価値探索の実践
ストリームアラインドチームとなるようにプロダクトチームを組成し、実際のプロジェクトを通じてDiscovery&Deliveryの考え方をチーム内に浸透させていきます。
これについては以下のnoteに記載をしています。
目的が不確実な施策に対する決裁ルールを策定する
大企業によくあるのが、決裁時点で「スコープ」「予算」「期間」を確定させてしまい、発注後に間に合わないとなった場合は「予算」「期間」を追加していくというウォーターフォール的な考え方に基づいたものです。
目的が明らかとなっているものや、特定の期日に出すことが重要である施策においてウォーターフォール型は有効である一方で、目的が不確実なものに対して検証を重ねていきながら進めていくアジャイル型の取組みを進める際に、決裁の枠組みが存在しないことは、継続的なプロダクトグロースを行うえで最も大きな障害となります。
今回のケースにおいては、パイロットプロジェクトの立ち上げにあわせて特例ルールを策定し、進行に合わせてこれをブラッシュアップをしていきながら理解を得ていくことで、最終的に正式なルール化へと至っています。
「1000の会議より、1つのプロトタイプ。」
喧々諤々と会議を重ねたうえで、いざ実装してみても、そもそも社内での認識齟齬があったり、リリースしてみても全然利用がされない…などといったケースは多いのではないでしょうか。
やはり、共通認識を形成することにおいて、インクリメント(=動作物)に勝るものはありません。
このようなときに用いられるのが「プロトタイプ」であり、特に実装を必要とせず実現できるFigma等によるLo-Fiプロトタイプは、ステークホルダー間の目線合わせ認識齟齬を防ぐ強力な武器となります。
これだけでなく、プロトタイプは価値探索から評価まで、あらゆる場面においてお客さまのフィードバックを得るために活用することができるため、Fail fast learn fastの観点においても、不確実性を乗りこなしていくために欠かすことは出来ません。
忘れてはいけないのは、ウォーターフォール型の決裁を行っている場合は、
少なくとも初期予算の中にプロトタイプを制作するためのコストを織り込んでおく
叶うならば、プロトタイプによる検証フェーズを経て、本決裁をとれるようなプロセスにすることを明文化する
のような状態になっていないと、そもそもの予算がなくLo-Fiプロトタイプを作ることが出来ないということに陥ってしまいますので、ここだけはどのような体制にしていくのか先に決めておけるとよいでしょう。
※ 個人的にはLo-Fiプロトタイプの都度発注はおすすめできないので、プロダクトデザイナーが不在の場合は、準委任で常に依頼できる体制を作っておくのが良いと思います。
お客さま不在のコミュニケーションからの脱却
大企業のコミュニケーション構造としてよく知られているのが「上意下達」です。いわゆる上位者が「考える人」であり、メンバーは「作業する人」という関係性のことです。
このような状態においては、上位者の脳内の答えを探すことにメンバーは腐心してしまい、段々と答申を突破することが目的化していきます。
この時点で、その企画においてお客さまは不在です。
お客さまにとって真に価値のあるサービスを作っていくためには、上司部下関係なく、同じお客さま像を共有していくことで、共創関係にシフトしていく必要があります。
この転換に向けての鍵になるのは、お客さまに関する一次情報であり、「量的データ」と「質的データ」となります。
「量的データ」についてはやっているよと思われる方も多いかもしれませんが、これが財務指標のみを指しているのであれば、それはお客さま理解の観点においては物足りません。
また、「質的データ」については対象企業の事業特性によって、この重要性や理解には大きな差があるように感じています。
丸井グループの場合は、基本的に新卒入社後に店頭での接客を経験しており、またお客さまとの共創で生まれたプライベートブランドもあります。
このような企業背景より、お客さまインタビューの導入ハードルは特にはなく、またインタビュアーとしての素養があるメンバーも多いです。
どちらか一方だけでは不十分であり、どちらも揃って意味を持ちます。
そのため、一次情報を獲得するためのケイパビリティをチームに宿しておくことは、お客さま中心のものづくりを実践するための必須事項であると考えています。
加えて、「一次情報の現場に赴き、体感する」ということも同等かそれ以上に重要です。本社にいると、なぜか気がつくと腰が重くなり、PCを開いてデータをみれば全てをわかった気になっていたりします。
これらのアクションを当たり前にしていくことで、今まで見えていなかった「要求の源」や「要求の獲得」の多様性に気づき、一次情報なしに企画を組み立てていくことの意味の無さに気付いていきます。
裏を返せば、一次情報を適切に獲得する方法を会得し、その情報が組織の中に流通していくようになれば、自ずと議論の質は向上し、企画の質も向上していきます。
濁った情報や、社内における定説、過去の経験だけで判断するから施策のピントがズレていくのです。
解くべき問題の決定方法を変える
サプライチェーン思考から脱出し、ビルドトラップを克服する
大企業によくある構造として、企画部門と開発・情シス部門が分断しているケースです。このような場合、開発プロセスを縦に切る形で組織が分断していることになるため、必然的に組織構造にあわせて責任分界点が発生し、「わたし考える人、あなたつくる人」の構図が生じます。
普通に考えれば、開発のリソースは有限であり、打てる施策数も限りがあるはずです。ですが、ビジネス部門はあくまで企画の承認を取ることまでがゴールとなっており、最もインパクトに直結するであろう「計画の優先度」「企画の分割」などは蔑ろにされがちです。
これはビジネス部門側がソフトウェア開発に対する理解が不十分であることに起因しており、企画を積み上げた分だけリソースも積み上げれば実現できるという感覚が今もなお根強いところにあるのだと理解しています。
なぜこのようなことになっているのかについて個人的な解釈ではありますが、この感覚はフィジカルなモノの製造のイメージでソフトウェア開発も捉えていることに原因があるように思います。
モノはある種、鋳型を作った後は生産拡大のためのライン増強を行っていくような発想にありますが、ソフトウェアはあくまで1つのソースコードを育て続けるわけで、ジェンガのようなイメージの方が適当です。
このモノの考え方に立脚すれば、生産効率を高めるために「サプライチェーン思考」に基づいたプロセスごとの水平分業を行うことが合理的であり、これにならう形で組織構造も形成されていきます。そして、プロセス毎の効率性を高めていくためのKPIが定められていくことで、ビルドトラップはどんどんと加速していくこととなります。
先述の通り、ソフトウェアはどこまでいっても1つであるため、持つべきは「バリューチェーン思考」であり、バリューストリームに従った組織によって企画からアウトカムの一連に責任を持てる体制を作ることが重要です。
このような体制に転換していくためには、大きく2つの方向性があります。
現時点においてプロダクトのアウトカムに対する責任を持っている組織を中心に、バリューチェーンを構成するのに不足しているケイパビリティを寄せていく。
組織を横断した共通のアウトカム指標を設定し、立場関係なくこれを向上させることが是であるというコンセンサスを形成する。
Phase2のパイロットプロジェクトにおいては①で実施しており、Phase3のマルイユナイトにおいては、事業会社とプロダクト会社が連動してアウトカムを生み出していく構造であるため②の方法を取っています。
小規模なプロダクトチームのうちは①で解決することができますが、プロダクトに関わる組織が大きくなればなるほど、必然的に組織分割をせざるを得ないので②を選択することになります。
が、②は組織を横断して責任やリスクを共有するものであるため、関係する組織長全員の理解と、KPI設計から評価まで含めたコミットメントがない限りは成立しません。
そのような意味で、②については理解あるリーダーが上位職にいれば実現出来る見込みがある一方で、不幸なことに不在の場合はボトムアップアプローチで解決出来る問題ではないので、今の体制のまま現実していくことは不可能です。
大企業に足りないエッセンシャル思考
サプライチェーン思考の話に重なる話題ではありますが、少なくとも僕の半径で観測している限りは「やらないことを決める」ことへの意識が薄いように感じています。
分業化を過度に進めた反動として、現場にいけばいくほどタスクを生み出すこと自体が仕事化し、ブルシット・ジョブ(クソどうでもいい仕事)であふれています。
費用対効果至上主義もこの一例で、「施策のROI」についてはすごく精緻に確認する一方で、「機会コスト」に対する意識は非常に薄いです。
スタートアップのように常にランウェイと戦い続ける環境では、組織を絶えず最適化し続ける必要があるため、そのような状況は起こりにくいです。
一方で、大企業のようなメンバーシップ型の組織では、ある種雇用を生み出している側面もあり、ドラスティックな変革が難しいです。さらに、リソースが潤沢であることも相まって、最適化の力学が非常に弱くなります。
やったほうがいいことはいくらでもあるが、今会社としてやらないといけないことはなにか？を定め、やらなくていいことを決定できるのは、上位レイヤーしかいません。
もし会社の中がブルシット・ジョブにあふれているように感じた場合は、現場としてはやらされ仕事を今すぐ止め、どれだけそれがムダな仕事であり、本来やるべきことにリソースを回せていないのかについて、きちんと上位層と対話をしていきながら、一緒に解消させていくことが必要です。
「開発案件一覧」から「プロダクトロードマップ」へのトランスフォーメーションガイド
ビルドトラップの深刻さが一番表面化してくるのが、企画部門が起票し、開発部門が線表に並べていく「開発案件一覧」です。
この運用である限りは、サプライチェーン的な発想から抜け出すことはできません。そのため、「プロダクトロードマップ」のように、アウトカム中心で優先順位を柔軟に変えられる運用へと転換していく必要があります。
このトランスフォームに関するStep by Stepについては、これだけで1本noteがかけそうな文量になりそうなので、また別の機会に書こうと思います。
が、基本的な発想としては、
意図が不明なバックログの山から意味性を汲み取りグルーピングをする。
そのうえで、この意味性について定量化したものを上位に据え、ここに施策をぶら下げていく。
といった流れで、バックログからプロダクトロードマップをバックトレースして書き起こし、このロードマップを中心とした新しい運用ルールについて経営・執行と合意したうえで、新しい運用プロセスがまわっていくことで、トランスフォームは完了します。
(それだけなんですが、いざやるのはとても大変です。。。)
成果
Phase1~3については、主軸は新しい文化を育てていくためのOS作りのようなフェーズであったため、なかなか定量的に示すことは難しいのですが、例えば「大手事業会社向けDX Criteria」でみると以下のようにスコアは順調に伸びています。
また、プロダクトディスカバリーに関する取組としても、改善サイクルは向上しており、対象プロダクトにおいて設定していた先行指標についても向上していることを確認できています。
今年の10月からはじまったPhase4においては、いわゆる出島から本島へ帰ってきており、本格的に事業数値向上に寄与していく必要があります。
長いようで短かったこれまでの2年半の旅ですが、ようやく「新世界編」のはじまりです。きちんと社会に対してインパクトを生み出していけるように、来年も着実に歩みを進めていきたいと思います。
それではみなさま、メリークリスマス🎅🎁 & 良いお年を🍊🎍！
いいなと思ったら応援しよう！
