カスタマーオンボーディングチームの小暮 和基です。
ご契約企業様のTreasure Data CDPのオンボーディングをサポートさせていただいている中で、お客様から「Quick Winってどうしたら(または何をすれば)出来ますか」といったご質問を頂戴したことが何度かあります。スモール・ウィン(スモール・サクセス)、アーリー・ウィン(クイック・ヒット)。同義の言葉も多くありますが、いずれも『小さくとも初期段階における成功実績』という意味合いで利用されます。ここ2-3年で市民権を得たのか、最近ではいろんな方が口にするようになったと感じるのは私だけでしょうか?
Quick Winは何か全く新しいことを始めるときや既存のやり方を変化させようと画策する際に有効な手立てであるとされています。その点ではCDP導入やDX推進はまさにドンピシャのテーマであると言えるでしょう。私自身、Treasure Data CDPのオンボーディングをサポートさせていただく際にはQuick Winを強く意識します。
一方で、ご契約企業様のコンディションやプロジェクトによってはQuick Winが思ったように作用せず期待した効果を発揮しなかった(= Quick Win創出のために割いたリソースがムダになってしまった)などの経験もあります。今回は、そんなお話しを交えつつ、Quick Winについて思うところを書いてみたいと思います。
Quick winに期待する効果と目的
企業が新しいことに取り組むときはいつだって、それが本当に成功するか否か、普段より厳しい視線に晒されます。もちろん取り組みの事前段階でじっくりと検証・考察をするでしょうし、他社のケーススタディなどから推進イメージも描くはず。それでも『新しい取り組み』である以上は不確定因子が潜んでいるかもしれず、結局どうなるかは蓋を開けてみるまでわからないのです。ここで問題になるのは、成功するかわからない・失敗リスクがある取り組みに対し周囲は積極的に関与することを嫌う、ということです。加えて基本的に人は変化を嫌う生き物なので、このような変化をもたらすための取り組み自体にも大した理由なく懐疑的な態度をとる人が少なくありません。
しかしCDP導入やDX推進の取り組みは他部署に協力を求めるべき瞬間が往々にしてあり、その協力要請に対して引け腰だったり協力するにせよおっかなびっくり作業にあたられていては話になりません。新しい取り組みの初期段階では、このような部分から是正していき取り組みの推進力を高めるべきケースもあるのです。そのためには取り組みの成功を周囲に匂わせ「この感じなら案外行けそうだ」と認識してもらうことが重要なポイントとなります。
取り組みの成功を周囲に匂わせる切り口こそ、今回のテーマであるQuick winです。先述したように、Quick winは『小さくとも、初期段階における成功実績』という意味合いです。その期待効果を一文で表現するならば「比較的初期段階で成功実績を作ることで取り組みそのものや旗振役に対する評価や信頼感を高め、引いては人々に受け入れられる土壌を作りその後のマネジメントをしやすくする。」となります。
ここには3つのポイントが存在し、それぞれが連鎖的に引き起こされていきます。
- 取り組みそのものや旗振役に対する評価や信頼感を高め
- 人々に受け入れられる土壌を作り
- その後のマネジメントをしやすくする
中でも、やはり連鎖反応の帰結部分である「3. その後のマネジメントをしやすくする」がQuick winに求めるべき最大の効果であると言えます。ただしマネジメントのしやすさと一口に言ってもその方向は広範で、人によっては「上司からの信頼や納得感を獲得し次のステップへの話しを通しやすくしたいから」であったり、「他部署を巻き込みリソースを確保したいから」などと具体的な内容を示す場合もあるでしょう。マネジメントのしやすさやQuick winを通じて勝ち得たい状態というのは案件により様々ではあるものの、取り組みへの体制によってある程度パターンが分類出来ると考えています。次からはその部分について解説させていただこうと思います。
ちなみにですが、Quick winの目的として「旗振役の精神的安定」を挙げる方もおります。個人的には強く同意なのですが、旗振役の責を負う立場の方から「俺の心の安寧のためにQuick winに取り組もう!」との発言は憚られますし、「リーダーの精神状況が取り組みにおける肝なので、Quick winに取り組みましょう!」と訴えてくれる心優しい部下の存在も稀有なので、残念ながら「旗振役の精神的安定」がQuick winの目的として認定される日は遠そうです。
CDP導入におけるQuick win
本題に触れる前に、Treasure Data CDP導入初期におけるご契約企業様のコンディションについて言及させてください。ご契約企業様は弊社との取り組みを推進されるにあたり、大なり小なりプロジェクトチームを組織されます。言い換えると、ご契約企業様の全社員が関わることは(少なくとも導入期には)ありませんし、ある種厳選されたプロジェクトメンバーの方々と共に推進していくことになります。本論とズレるので詳細は省かせていただきますが、その背景として以下のような項目が挙げられます。
ポイント
- CDP導入のために必要な役割やスキルセットが存在すること
- 意思決定のスピード感を担保するため
- 既存業務を回すためのリソースは最低限維持しておく必要があること
もちろんご契約企業様のコンディションによって別の理由が付帯されることもありますが、DXやCDP導入はその性質上、プロジェクトという体系を採ることが通例です。さらに、プロジェクトの体制は大きく以下の3つに分類されます。
前節でQuick winの目的は「3. その後のマネジメントをしやすくする」ことにあると触れました。なぜここでプロジェクトの体制について言及したかというと、体制の違いによってQuick winを通じて目指すべき”マネジメントしやすい状態”の在り方が異なってくるからです。それぞれ具体的に見ていきましょう。
プロジェクト体制とQuick win <機能・部署型>
最初の「機能・部署型」のプロジェクト体制は事業部制を敷いているメーカー企業などでよく見られ、単独事業部あるいはそこにシステム担当部署を加えた2部署程度で編成、3つのプロジェクト体制の中ではもっとも小規模なものです。(なお、ここでは他部署を巻き込み展開を拡げる計画は当面なく、CDPの利活用はあくまでも導入部署のみが主体となることを前提とします。)
このケースでは事業部または部署単位というすでにガバナンスを効かせやすい体制下での取り組みであるため、「マネジメントしやすい状態とは?」と考えたみたとき、実はすでに環境が整っている場合が多いのです。少し細かく見ていくと、マネジメントをしやすくするためにQuick winを通じて作用させたい対象としては以下の3つの方向性が考えられます。
- プロジェクトに所属する内部メンバー
- 現プロジェクトには属していないが、今後協力を仰ぎたい外部メンバー
- プロジェクト決裁者、またはプロジェクトの存続や動向に影響を与える役員レイヤー
機能・部署型は現況のマネジメント管轄配下で編成されるプロジェクト組織であるため、リソースコントロールをはじめとした「1.内部メンバーに対するマネジメント」は比較的容易です。さらに言うと機能・部署型でのCDP導入は、実行事業部がもともと追っているKPIをより一層リフトさせることを目的としていることが多く、この場合内部メンバーの目的意識が明確でモチベーションも維持しやすくなります。結果、本ケースにおける内部メンバーへのマネジメントはそこまでケアすべき対象とはなりづらいのです。(よほど内部メンバーがお互いを知らなかったり、士気が低い状態であれば別ですが笑)
また他部署を巻き込み展開を拡げる計画がないならば、「2.外部メンバーへの作用」も不要です。
残るは「3.プロジェクト決裁者、またはプロジェクトの存続や動向に影響を与える役員レイヤー」です。私見としては、事業部制であることから周囲の干渉を比較的受けづらく成果もじっくりと待つことができること、またCDP導入にはトップのマネジメントレイヤーからも高い理解を伴った承認を受けていることが多いことから、何らかの事情が絡まない限りは特段ケアすべき対象にはならない傾向にあると考えています。ただし、どちらかと言えばプロジェクト決裁者の裁量幅や、他役員の賛否意見・声の大きさなどでケアすべきかどうかを判断すべきでしょう。まさにご契約企業様のコンディションによる部分です。
以上のことから、「機能・部署型」はQuick winの恩恵を(後述する他のプロジェクト体制と比較して)受けづらいと考えています。Quick winや成果はあって困る類いのものではありませんが、時間やリソースを割いたところで徒労に終わってしまうリスクも孕んでいることを鑑みれば、不必要にQuick winを創出するため脇道に逸れるようなことはあまりお勧め出来ません。
個人的な経験ですが「機能・部署型」で推進力が高い企業様の傾向として、CDP導入に向け着実にステップを踏んでいきつつ、その過程で得られたもの(ここでは数値成果だけでなく、新たな気づきなども含め)をポジティブかつ細かくプロジェクト内外のメンバーに発信する進め方を採っていることが多いよう感じます。
さて、ここまで機能・部署型のプロジェクト体制においてQuick winは効果を発揮しづらいという論旨でお話ししましたが、もちろん例外もあります。ここでは特に注意したい2つのケースを紹介させていただきます。
ひとつめは前提条件として外させていただいた内容ですが、将来的に他部署を巻き込むなどで展開を拡げていきたいケースです。プロジェクトのロードマップに他部署の巻き込みが明記されていなくとも、プロジェクトリーダーなどが裏テーマとして他部署の巻き込み展開を設定しているようなら、Quick winを狙う価値は十分にあると言えます。
ふたつめは、CDP導入検討からプロジェクト計画の策定をシステムチームの完全主導により行われたケースです。CDP導入やDX推進プロジェクトは多くの場合、まずはビジネスサイドで要求や要件を整理し、それらを受けたシステムサイドがシステム要求や要件として落とし込み構築・整備を進めていく流れが採られます。それらの設計を全てシステムサイド単独で進めてしまい後々ビジネスサイドの考えと乖離が発覚すると、実行部隊であるビジネスサイドからの積極的な推進を得ることが出来ず最悪のケースとして鳴かず飛ばずの成果のまま結局プロジェクト自体が停滞してしまうなどの事態にも繋りかねません。
プロジェクト初段段階でビジネスサイドとシステムサイドが歩み寄ることが重要です。このような場合、Quick winをきっかけにビジネスサイドを巻き込み、さらにその成果をもって「(システムサイドで策定した)この計画で行けそうだ」とビジネスサイドに認識してもらうことが出来れば、その後のプロジェクト推進は大きく違ったものになるでしょう。
プロジェクト体制とQuick win <機能・部署横断型>
機能・部署横断型の体制は一般的にマネジメントレイヤーから成るステアリングコミッティの下、複数組織から人財を提供されたタスクフォースがプロジェクト実行部隊として組織されます。複数組織から横断的にメンバー編成する傍ら目的や思考の共通化を図りやすいなどのメリットがあり、大型のプロジェクトでは比較的選択されやすい体制です。しかしながら各組織から人財提供を受けていることに起因してマネジメントの難しさも当然存在します。
プロジェクトリーダーの立場から見れば、プロジェクトへの各メンバーのモチベーションを高めつつ、提供されるリソース量を高い水準で維持していくことが重要になるでしょう。と言うのも、各組織から提供されるほとんどの人財は既存のライン業務を兼務する場合が多く、そちらにもパフォーマンスを求められることが一般的です。(比較的各部署のエース級がプロジェクトメンバーに選定されやすいのですが、そのような方はライン業務から外すことも難しいようです)プロジェクトに提供してもらうリソースを高めてもらうためには逆説的に既存業務のプライオリティを下げてもらう必要がありますが、そう容易なことではありません。
これを実現するには対象メンバーのプロジェクトに対するモチベーションを高め自発的な関与を促すことももちろんですが、元々所属する部署のマネージャーからも高い理解を得ることが必要不可欠です。先述した通り、人は成功するかわからない・失敗リスクがある取り組みに対して積極的に関与することを嫌います。人財をプロジェクトに送り込む側からすれば、成功するかどうかわからないプロジェクトに対し貴重なエース級リソースの提供を(あまつさえ自部署で達成すべき目標もある中で)コミットしてもらうことは難しいものです。
このような状況を好転させるために、Quick winを通じて取り組みに対する評価や信頼感を高められれば、「このプロジェクトであればうちのエース級リソースを提供する価値がある」と各部門マネージャーに思ってもらうことができ、それはリソースの借入限度を高めることに繋がるのです。機能・部署横断型プロジェクト体制におけるQuick winの効果は他にもあります。マネジメントをしやすくするために作用させたい3つの対象別に整理すると以下のような具合です。機能・部署横断型体制においてはプロジェクト内外・縦横にQuick winが効果的に作用することがお分かりいただけるかと思います。
- プロジェクトに所属する内部メンバー
- プロジェクト自体の有効性や信頼度を高め、より積極的な関与を促せる
- Quick winを創出する過程で、内部メンバーのコミュニケーションを活性化できる
- 共通の成果を分かち合うことで、プロジェクトに対する誇りや帰属意識を強められる
- Quick winが所属部署の成果に直接繋がらなくとも、いずれ自分らにも還元されることを期待して継続的な関与を促せる(提供したリソースがムダにならないよう自分たちの直接利益に結びつくまで投資を継続させる心理)
- 現プロジェクトには属していないが、今後協力を仰ぎたい外部メンバー
- プロジェクトの社内認知や関心を高めることで、協力を仰ぎやすくなる
- 特に人財提供部署のマネジメント層から、より積極的なリソース提供の承認を得られやすくなる
- プロジェクト決裁者、またはプロジェクトの存続や動向に影響を与える役員レイヤー
- 決裁者が初段での成果を盾に(プロジェクトに懐疑的な役員がいても)意向を通しやすくなる
- 特に人財提供部署のマネジメント層から、より積極的なリソース提供の承認を得られやすくなる
- プロジェクトに懐疑的な役員に対し成果を示すことで、協力を得られやすくする
そもそもCDP導入プロジェクトはその効果を発揮するまでに長いスパンを見据えじっくり腰を据えて取り組む必要がある性質のものですが、機能・部署横断型の体制を成果が上がらないまま長期間維持することはなかなか困難で、目標に向けて小さな成果やアウトプットを積み上げ続けるようなプロジェクト計画が好ましいとされています。そう考えれば機能・部署横断型プロジェクト体制とQuick winは相性が抜群に良いのです。
プロジェクト体制とQuick win <特化型>
最後はプロジェクト特化型の組織編成です。エンジニアなどの実務者リソースがプロジェクトのために確保されており、彼らが事業部に対し支援を行う図式となっています。実際には1社単位でこの体制を敷くというよりも、ホールディングス企業が傘下の事業企業に対してDXやCDP導入を推進したいときなどに見られるプロジェクト体制です。
この体制の特徴的なところは、「全社(または全グループ)でのシステム導入案件」として推進されるケースがほとんどであるという点です。DX推進やCDP導入として本来好ましい進め方は各事業部(または事業会社)と個別にビジネス要件から詰めていくアプローチですが、個別に設計を進めることのタフさはもとより設計レベルで何か個別要望が上がったとて受け入れ可能な余地もさほどないため、まずはホールディングス企業の強権を発動しグループ広範にシステム導入を推し進めていくという格好となります。
ーここでお断りを入れさせていただきますが、特化型のプロジェクトでは「各事業部や事業会社に対してシステム導入すること」までをゴールとしその後の利活用方針の策定や利用定着フォローアップは運用先の組織体に任せる、というケースがよく見受けられます。強権を発動してシステムを導入するまでの工程ではマネジメントどうこうの話ではなかったりするので、以下からはプロジェクト対応範囲は「システム導入先での利活用策定および利用定着まで」としていることを前提として記載させていただきます。
さて、ここで改めて特化型の編成を見てみると、その構造から機能・部署横断型体制と似通った印象を受ける方も多いと思います。しかし実態としては、機能・部署型の項で例外として挙げた「CDP導入検討からプロジェクト計画の策定をシステムチームの完全主導により行われたケース」と酷似しており、その発展系と捉えた方が正しい見方のように思います。
つまり、このケースでマネジメントする上での最大の阻害リスクは「システムサイド主導で策定したビジネス要件や要求、またはその進め方自体が実行部隊であるビジネスサイドからの支持を得られず、積極的な協力を得られなくなること」なのです。これを放置し続ければ、大した成果をあげられず結局プロジェクト自体が停滞してしまうことに繋がります。早々に実行部隊と歩み寄り導入システムの有効性を示すことが求められ、これがQuick winを検討すべき事由となります。
また1事業部での成功実績があれば、他セクションに対して同様に取り組みを実施する際も説得力を持ってプロジェクトやシステムの有効性を示すことが出来るようになります。このようにQuick winが外部メンバー(他セクション)に寄与するという点では、機能・部署横断型体制と類似のポイントもあると言えるでしょう。
一方でプロジェクトの存続や動向に影響を与える決裁者や役員レイヤーについては、そもそも強権を使用してこのようなプロジェクトを開始出来ていることからも、後ろ盾としてそれなりに盤石であることが窺い知れます。Quick winの有無で大きく情勢が揺らぐことはなく、この作用対象者へのQuick win効果は限定的と考えます。
まとめ / さいごに
これまでプロジェクト体制ごとにQuick winの必要性や作用させやすい対象について書き連ねさせていただきました。これらはあくまでも傾向ですので、冒頭で触れたようにご契約企業様のコンディションやプロジェクト状況を踏まえてご検討いただけますと幸いです。
また今回はご紹介しておりませんがQuick winの効果を高める要素として「何をネタとするか?」と「どのように成果を演出/アピールするか?」も非常に重要だったりしますので、どこかで機会があればお話しできればと思います。最後に、Quick winであるかどうかは別としても、DX推進やCDP導入の成功企業と目される方々からは「〇〇という出来事があって以来、それまでの潮目が変わりプロジェクトが一気に推進に向かった瞬間があった」とよく耳にします。このあたりはTUG(トレジャーデータ ユーザー会)や弊社主催セミナーPlazmaなどでお話しされることも多くあるようですので、ぜひそのような機会にも積極的に触れていただければ幸甚です。
思っていたよりも長くなってしまい申し訳ございません。また稚拙な文章をここまでお目通しいただき有り難うございます。