エンジニア出身のリーダー経験者が語る 失敗から学んだ「DXプロジェクトをスタックさせないtips」

アーカイブ動画

■登壇者プロフィール

佐藤 満氏
元株式会社ストライプインターナショナル　執行役員　CDO
兼　株式会社ストライプデパートメント　代表取締役社長

友松 哲也氏
株式会社POINT EDGE 代表取締役
兼　株式会社REaaS Technologies 取締役

岡村 直人氏
カーマンライン株式会社 代表取締役

PMの役割はステークホルダーの理解を得ること

元株式会社ストライプインターナショナル 執行役員・CDO 佐藤満氏は、メーカー、アパレル、ITベンチャーから大手まで、さまざまな業界で多様なプロジェクトに、リーダーとして携わってきた経験の持ち主だ。佐藤氏は要件定義をまとめたり、QCD（Quality／品質、Cost／コスト、Delivery／納期）のバランスを調整することで、DXプロジェクトを成功に導いてきた。だがヤフーの大型サービス統合プロジェクトでは、これまでの手法が通じず、大きな失敗を経験する。

「それまでのプロジェクトでは、自分より上のポジションのステークホルダーは事業部長や社長など数名程度でした。ところがヤフーでの大型プロジェクトは、メンバーは数百名規模、事業部長クラスも多く、綿密なコミュニケーションを取ることが難しい状況が続きました」（佐藤氏）

結局、1年でリリース予定だったプロジェクトは2年経ってもリリースできず、最終的にプロジェクトは頓挫する。しかし、佐藤氏は単なる失敗プロジェクトでは終わらせなかった。なぜ失敗したのかを振り返り、次のようなTipsを得たのである。

「当時の私は、画一的なコミュニケーションしか行っていませんでした。しかし、ステークホルダー一人ひとりのことを考え、それぞれの立場やマインドセットに合致したコミュニケーションを取ることが重要だったのです。その経験を活かし、プロジェクトの進め方を変えました。要件定義やQCDの調整に注力するのではなく、関わるステークホルダーのマネジメント、『いかに人を動かすか』を意識するべきだと気づいたのです。業務割合で言えば、80％の重要度だったと思っています」（佐藤氏）

兼務の管理職は避け、専任メンバー4～5名で始める

佐藤氏は、プロジェクト立ち上げ時期は方向性をしっかり決めることが重要なので、できるだけ少人数でスタートさせるのが望ましいと語っている。実際、失敗したヤフープロジェクトはスタート時から大人数だったが、成功したLOHACO、ストライプデパートメント（ストデパ）のプロジェクトは、少人数でのスタートだった。

「当たり前のことですが、人数が少ない方が認識のすり合わせ、スケジュールのコントロールがやりやすい。誰がどの役割を担うのかも明確です。メンバーが増えた際も、担当スコープのリーダーになってくれる。PMの負担が軽減するメリットもあります」（佐藤氏）

スターティングメンバーが多いと役割が重複し、責任の所在が分かりにくくなる。また、情報が外部に漏れる可能性も高まり、各種スタック要因が増えてしまう。そのため、プロジェクトにしっかりコミットできるメンバーをアサインすることが重要だ。

「メンバーは兼務ではなく、専任で携われることが必須。仮に優秀なメンバーであっても、他のプロジェクトに携わっている際にはアサインはしない」と、佐藤氏は言い切る。100％コミットしていないメンバーがいることで、ミーティングが進まなかったり、ネガティブな意見が出ることが懸念されるからだ。

同様の理由から、多忙な管理職のアサインも避ける。ただし、現場サイドとの関係性構築や情報量・ノウハウの観点から、「アドバイザーとして加わってもらうことはメリットがある」と補足した。 また、現システムの開発に携わった経験のあるエンジニアや、仕組みに詳しいエンジニアのアサインも避けた方がいいという。既存機能を捨てる決断ができず、ネガティブ意見を発することが多い傾向があるためだ。

骨子が固まったら説明会を開催、議事録は時系列でドキュメント保存

佐藤氏はプロジェクトの概要がある程度固まったら、プロジェクトの意義や意図、ミッションを伝える全社的な説明会を開催している。PJが何をしているのかを説明することで、社員が納得し、実際にユーザ部門などとやり取りする際に、コミュニケーションが取りやすくなるからだ。

「会社全体の反応を知ることもできるので、開発の方向性を再考するきっかけにもなります。また以降のメンバーのアサインにおいて、コミットメントの高いメンバーが手を挙げてくれる可能性が高まります」（佐藤氏）

後から入ってきたメンバーとの情報格差をなるべくつくらないように、ミッション、ビジョン、バリューも含め、スタート当初からのやり取りは議事録として、ドキュメントで残しておく。背景や理由がわかることはストレス軽減につながる。

プロジェクトの体制図を作成することも重要だ。責任と権限がひと目で分かるだけでなく、新しく入ってきたメンバーが疑問を持った際、誰に聞けばいいのかが、同じく一発で分かるからだ。

課題と対策は正確に伝える。高額予算は減価償却で計上

続いて佐藤氏は、各ステークホルダーに対するマネジメント手法を紹介した。 経営層に対するマネジメントのポイントは3つある。「投資対効果」「スケジュール」「現在の課題と対策」だ。これら3つのポイントについて定期的にプレゼンを開催し、パワーポイント3枚ほどのスライドを作成し、簡潔に説明する。

プレゼンの際には現状の様子をデモとして見せる。課題と対策に対しては嘘偽りなく正確に伝えることもポイントだ。また、現場部門の経営層には、プレゼンの際に「○○さんがいてくれて助かっています」と、優秀なメンバーがプロジェクトに参加・貢献していることのお礼を伝えることも重要だという。

経営層が思いつきで発言した機能追加なども、無下に扱わない。実際、重要な機能である場合もあり、経営層の高い視座を後から理解できることがある。着手時期は正確に示さなくてよいが、ペーパープロトタイプなどを作成しておき、検討している進捗を示す。「投資対効果」については、次のように説明した。

「システム案件は、投資額が1億円を超えることも多い。その場合は減価償却を使い、2000万円×5年と計上します。単年でのPLのインパクト軽減にもなりますし、予算が確保しやすいメリットもあります」（佐藤氏）

現場に対しても、「プロジェクトのために協力をお願いします」といった一歩通行のコミュニケーションではなく、ヒアリングを通じて、お互いの関係性やコミュニケーションを深めることが大切だ。 コミュニケーションを深めた上で、プロジェクトで開発するシステムやサービスが、いかに現場メンバーに対して画期的なものであるかを説明していく。特に、新しいシステムなどに敏感な若いメンバーとの交流が効果的だという。

開発チームは、内製か外注かで対応を変える

開発チームに対するマネジメントも、エンジニアの思考や立場を理解することが重要だ。そのため、内製・外注で対応を変える必要がある。

内製チームは品質を優先する一方、外注の外部ベンダーはコストを鑑み、スケジュール（工期）に重きを置くことが多い。そのため内製メンバーの場合は、機能の優先順位と開発難易度・工数のマトリクス図を作成し、ファーストフェーズですべてをやらないと決める。仮でも構わないので、セカンドフェーズを押さえておく。

一方で、記者会見やキャンペーンといった、リリース日以降の予定を共有することで、スケジュールに対しても意識させる。さらに、チームの心理的安全性を担保するために、不協和音を生むようなメンバーは早い時点でプロジェクトから抜けてもらう。ただし、抜けたメンバーのことも考慮し、別のチームで新たなチャンスを与える。

対して外部ベンダーの場合は、まずはエンジニア経験があるPMを立ててもらうよう進言し、開発現場には常駐してもらう。納品後、保守計画書も作成してもらうよう伝える。一方で、コストはかかるが1ベンダーではなく、複数のベンダーに依頼することで、リスクヘッジとする。品質や検収といったフローは、別のベンダーに任せることで透明性を高める。

最後は自分に対してのマネジメント、気持ちの持ち方についてのアドバイスだ。

PJを進める上で「神風は吹かない」と、佐藤氏。辛い状況に陥ったときほど「どうにかなる」「なんとかなるはずだ」という思考になった時点で、スタックする危険性がある。ネガティブマインドの原因をしっかりと把握し、掘り下げる勇気を持ち、実際に行動する重要性を指摘した。

佐藤氏は次のメッセージを送り、セッションを締めた。

「私は漫画『SLAM DUNK』が大好きです。一見するとDX推進担当は、チームを引っ張っている赤木君や流川君のように思えます。でも実際は、裏でチーム全体のコミュニケーションをまとめている、小暮君のような存在。そして大切なのは、有名な台詞『あきらめたら、そこで試合終了ですよ』のマインドだと思います」（佐藤氏）

DXに正解はないことを理解してもらう

続いては、新規事業支援やブランドコンサルティングを手がけるPOINT EDGEの代表取締役、友松哲也氏が登壇。「DXで気をつけるべき“しくじりポイント”とその乗り越え方」をテーマにセッションを行った。

まず友松氏は、「DXとはそれぞれの企業が、デジタルドリブンでビジネス変革を継続した結果、企業のカルチャーが変わることであり、自社のDXは何なのかを考えながらトライアンドエラーを繰り返すこと」だと語る。

また、DXに取り組む企業が増えている風潮についても言及。ダーウインの進化論を例に挙げ、次のように説明した。

「DXはあくまで次世代に生き残るための戦略であり、他社に勝つための戦略ではありません。そこを、誤解している経営者が多いように感じています」（友松氏）

このような誤解があるからだろう。DXをトップの号令でやることになった。実際にプロジェクトも立ち上がった。一方で、DXの本質を理解していないために、プロジェクトのメンバーが困惑するケースが少なくない。会社が目指す方向性、ミッションやバリューは、トップである経営者が示す必要があると、友松氏は指摘した。

フェーズによってプロジェクトスタイルを変える

DXは従来のビジネスモデルとは異なり、プロダクトやサービスが完成したら終わりではない。先に説明したとおり、デジタルドリブンな経営改革を継続することがDXだからだ。そのため、従来とはプロジェクトの進め方も変える必要がある。

一方で、経営者やDXの知識や経験が乏しいメンバーは、システムやプロダクトが完成したら、プロジェクトは終わりだと考えている。そのため従来のウォーターフォール型で計画を立て、成果物やエンジニアの工数を綿密に計算し表化した「WBS（Work Breakdown Structure／作業分解構成図）」などを作成しがちだ。

アジャイル型でDXを推進するプロジェクトチームとの考えに差異があるため、コミュニケーションやプロジェクトの進め方に関して、齟齬などの問題が生じることが多い。

友松氏は、これまでDXプロジェクトに従事した経験も含め、先行きが不透明なケースが大半だったと振り返る。実際、過去3年間に携わったDXプロジェクト17件のうち、実際にリリースに至ったのは4件。成果やゴールを求める経営層や管理層とは、意識ギャップがあることを強調した。

では、先行きが不透明で成功確率も低いDXプロジェクトを、どのように進めればよいのか。それは、ウォーターフォール型ではなく、適宜、柔軟に変更・対応できるアジャイル型でプロジェクトを進める。かつ、プロジェクトのフェーズにより、開発スタイルを変えることだと、友松氏は強調する。

「プロジェクトのスタート時は、2～3名で仮説を探索する業務に注力します。少人数でスピーディーに仮説を作成することを目指します」（友松氏）

仮説がかたまったら、次は仮説検証だ。ここからはアジャイル型の開発フローで、プロトタイピングなどを行う。仮説検証がなされたら、次は計画実行フェーズである。こちらもアジャイル型で、チームのメンバーを増やし、プロジェクトを進めていく。

DXは投資プロジェクトだと理解してもらう

佐藤氏のセッションでも、経営層は投資対効果を気にするとの話題が上がったが、DXは先行き不透明なことが多い。さらにはデジタルサービスであるため、いきなりまとまった売上が入るのではなく、徐々にユーザーの増加や売上が向上していく傾向がある。

具体的には、サービスリリースから5～10年は必要だと友松氏は言う。経営層との認識ギャップを、どのように埋めるのか。

「従来のビジネスとは異なり、明確な回収計画は立たないこと、DXは投資プロジェクトであると理解してもらうこと。これを経営層だけでなく、すべてのステークホルダーに対しても認識してもらう必要があります」（友松氏）

具体的な手法としては、上記のスライドがわかりやすい。従来のプロダクト型のビジネスは時間の経過と共にプロダクトの価値も売上も減少していくが、DXで生まれたデジタルサービスは、機能追加やマーケットからのフィードバックによるバージョンアップなどにより、進化し続けていく。そしてその進化に伴い、顧客数や売上が上がっていくことを、懇切丁寧に説明するしかない。

ミクロ・マクロを行き来し包括的にビジネスをデザインする

2017年に設立したPOINT EDGEは、ビジネスデザインとの言葉を標榜し、少数精鋭で外部のさまざまなクリエイターと協業しながら、各種コンサルティングサービスを提供している。特に最近は、DXに関する案件が多いという。

ビジネスデザインとは、ビジネス全体の価値を設計することだと友松氏。価値をデザインするために、ビジョン、イノベーション、ビジネスモデル、アウトカムと主に4つの領域を注視している。

特徴的なのは、ユーザー視点のミクロな目線、マーケット寄りのマクロな客観視点両方を総体的、包括的に見ることで顧客の真の価値を見出し、ビジネスをデザインしていくこと。いわゆるUXだ。机上の理論ではなく、実際にクライアントのプロジェクトに参加する、伴走型のサービスでもある。

友松氏は事例として、産業財メーカーが新規事業として農業領域で立ち上げた、IoT事業を支援したケースを紹介。ビジネスモデルの設計、アライアンス体制の構築、プロトタイプ開発などを、まさにクライアントと伴走しながら提供しているという。2020年4月から、不動産事業を手がけるシノケングループの一員となったこともあり、不動産関連のDXも手がけている。

友松氏は次のように述べ、セッションを締めた。

「DXの本質を理解してもらうために、ワークショップを開催しています。これまでの関わってきた事例をまとめ、メソッドとして体系立てることで、DX経験が乏しい人でも関われるような取り組みも行っています。これまでDXに携わったことがない人でも、成果が出せる体制作りを今後も続けていきたいと思います」（友松氏）

【パネルディスカッション】エンジニア対して曖昧な指示は絶対にNG

パネルディスカッションは、数々のDXプロジェクトをリーダーポジションで取り組んできた、エンジニア出身でフリーコンサルタントの岡村直人氏がモデレーターを務め、現場の課題や対策についてディスカッションが行われた。

岡村：経営者や現場など、エンジニアと非エンジニアのギャップを埋めることの難しさが伝わってくるセッションでした。改めて、ステークホルダーとのギャップを埋め、説得する対策を教えていただけますか。

友松：このギャップは溝が深く、たやすく乗り越えられるものではありません。評価ポイントの違いもあります。一方で、DXは行う必要がある。結局は人対人の感覚的なところで、会話や対話を重ねていくしかないと、現状では考えています。

佐藤：経営層に対しては、どのような変化が起きるかを伝える。その変化に対して、コミットしてもらうことが重要だと考えています。一方で、カスタマー系のメンバーには配慮が必要です。DXによってクレームや問い合わせの対応が楽になるなど、自身の業務がより良く改善することを伝えます。

岡村：デジタルリテラシーに関してはどうでしょう。

友松：これは非エンジニアに対してのメッセージになりますが、エンジニアは話を最後まで聞いてほしいのに、非エンジニア側は、話を途中で遮るケースがよく見られます。IT知識が不足していることが背景にありますが、最後までエンジニアの声に耳を傾けることで、コミュニケーションギャップは改善するのではないでしょうか。

岡村：逆にエンジニアも、ビジネスサイドの業務や思考について関心を持つ。お互いの歩み寄りが大事ですね。ただ、エンジニアのマネジメントは難しい面もあります。

佐藤：非エンジニアが、業務内容が理解しきれないままエンジニアをマネジメントするのは難易度が高い。ですから根本として、エンジニアでない人が、エンジニアをマネジメントしようとせず、一緒に考えるて進めることが大事だと思います。あえて気をつける点を挙げるとすれば、エンジニアは自分が何をすべきかを知りたがっています。ですから「適当にやっといて」といった曖昧ワードは、絶対にNGです。

友松：繰り返しになりますが、お互いの歩み寄りだと思います。非エンジニアの方は、IT知識を深めたり、エンジニアの思考を理解しようとする姿勢が大切ではないでしょうか。一方で、エンジニアもビジネスサイドに携わる。実際に経験を積むことで、新たな世界が見られることも伝えたいですね。

佐藤：いきなり要件の話から入ると、マネジメントがうまくいかないケースが多い。マネジメントしようとして構えるのではなく、趣味の話や雑談から入ることが重要ではないでしょうか。要件を正確に伝えることに集中しがちですが、エンジニアのアイデアや疑問点を聞きながら相互理解を深めるのが良いと思います。

【Q＆A】参加者から寄せられた質問を紹介

パネルディスカッション後はQ&Aタイムが設けられ、登壇者たちが質問に答えた。

Q：PoCも含めて仮説検証すると、想定が大きく変わりQCD管理が破綻しがちです。良い手はないでしょうか。

友松：ピボットを恐れないこと、「ピボット＝撤退」ではなく、より良い選択を得られたと捉えることが重要だと思います。そしてその内容を、ステークホルダーに適切に伝えることも重要です。逆に、想定が大きく変わったことを失敗だと捉え、PoCを変えることは、それこそ失敗パターンの典型です。

撤退（ピボット）の基準については、最初にKPIを設定し、達成できなかったら撤退する、という基準があります。ただし、撤退基準についてはプロジェクトによって異なるため、これだという明確な基準はありません。私自身も模索しているところです。

佐藤：PoCを外部ベンダーに依頼する際のコツは、PoCの先の契約があるかないか。PoCがうまくいったら、その先に本契約があることを共有する。つまり、PoCの検証が目標ではなく、目指すべきゴールは本開発なので、その道筋を一緒に作ってくれませんかといったコミュニケーションをすると、スムーズに運ぶと思います。

Q：Tipsを短期でキャッチアップできるコツはあるか。

佐藤：今回のようなイベントに参加して社外の事例を聞いたり、経験者に相談することです。私も以前は他人の話を聞くような姿勢ではありませんでしたが、失敗を経験してからはインプットの機会を増やしたところ、Tipsをキャッチアップできるようになりました。

岡村：知識も大事ですが、経験も重要だと思います。得た知識は実際にやってみることです。それを繰り返すことで、本物の経験に変わっていくのではないでしょうか。

友松：とにかくやってみることが大切だと思います。私もPdMになりたてのころは、数多くの失敗をしました。でも、そのような失敗を積極的に経験したからこそ、今があると思っています。

株式会社POINT EDGE
https://pointedge.work/

株式会社POINT EDGEの採用情報
https://pointedge.work/jobs/
https://hrmos.co/pages/shinoken/jobs/0000333