めっちゃダイバーシティな開発チームで英語でDX Criteriaをやってみたプロマネの体験談（2/3）

こんにちは、かしお優です。

手強いレガシーシステムを、６ヶ国の多国籍な若いエンジニア達と英語でつつくという環境でプロダクトマネージャーをしています。ここで３年目に入ろうかというところです。

DX Criteriaは大企業を想定していないかもしれませんが、大企業でやってみました。DX Criteria( DX基準 )とは、日本CTO協会が提供しているアセスメントツールです。プロマネはミニCEOだと言う説もあるらしいので、これも成り切りのひとつとご容赦ください。

英語版DX Criteriaをやりました。

最初の記事では私の場合の前提について、2番目の記事は大企業での利用どころ、最後の記事で実際にDX Criteriaの英語版を作成してチームで実行してみた結果を書いています。こちらは２番目の記事となります。

めっちゃダイバーシティな開発チームで英語でDX Criteriaをやってみたプロマネの体験談（1/3）

めっちゃダイバーシティな開発チームで英語でDX Criteriaをやってみたプロマネの体験談（2/3）（今この記事を読んでいます）

めっちゃダイバーシティな開発チームで英語でDX Criteriaをやってみたプロマネの体験談（3/3）

DX Criteriaの大企業での使い道は３つある

ポイント１: パンドラの箱を次々と開け続ける茨の道

1つ目は、別に大企業でなくてもというポイントですが

１．みんなで現在位置を確認しながら進めるから

です。

レガシーシステムをリプレイスするというのは、周りが想像するよりもチームにとっては困難です。

プロダクトマネージャーにとっては簡単だろうと見積もったものが、エンジニアにとっては複雑に絡んだいばらをかき分けて、いばらの向こうに見えるゴールに至るまでの道を作っていくという工程かもしれません。

ビジネスロジックの歴史変遷が残りまくった挙動の全体、なぜこう書かれているのか分からないコードの扱い、依存関係など、腫れ物に触るように歩いても、実際、一番大きな腫瘍にはタッチできていないこともありえるかもしれません。

「えぇー？この問題、どうして最初に言ってくれなかったの？」というような、プロマネのみならず、エンジニアにとっても蓋を開けてそのとき初めて分かった、ということも出てくるかもしれません。

レガシーの保守をするだけよりは達成感は得られやすいと思いますが、全員辛いことは辛い。ならば、道の途中になんらか目に見えるアンカー（DX Criteriaの実施）があり、みんなでそれを語り確認できる機会はとても有意義です。

ポイント２: プロマネは石橋をちゃんと叩きながらの大冒険だって、喧伝できているか？

大企業での活用ポイントの２つ目は、

２．プロジェクトの難易度を伝える（現在のプロダクトの状態を客観的に伝える）

です。

プロマネから見たらチームはちゃんと石橋を叩きながら大冒険して再建していても、想定外の事故やスケジュール遅延があり得るということです。

チーム内で何をしているか理解しあうことも幸せにつながりますが、大企業では内部にもステークホルダーがたくさんおり、プロマネがプロジェクトの難易度をステークホルダーに丁寧に説明できていることは非常に大切です。

ステークホルダーには、ユーザはもちろんですが、テック部門のボスと横組織、ビジネス部門、スポンサー部門、セールス部門、サポート部門などがあります。イマドキだとカスタマーサクセスと近しく連携しているテックチームもあるんでしょうね。

特に、何か想定外があれば、自分だけならずチームのエンジニアが全員、低評価を食らってもおかしくないので、テック部門のボスに十分に説明できていることが大事だと思います。

責任重大な説明ですが、これは着手前のプロダクトのDX Criteriaの結果を保存しておくことで、例えばほかのプロダクトと比べて評点が低いことや弱点、改善目標数値やそれを支える要素を整理して見せるなどで、客観的に定量的に説明しやすくすることができると思います。

残念ながら私はスタート当初、途中エンジニアからどんな自主的な案が出てくるか想像しきれておらず、また、DX Criteriaの存在に気づいていませんした。

最終的にはプロダクト再建を進めている途中で行き当たりばったりでエンジニアから出てきた案や課題を拾っているうちに改善点が広がりました。プロダクト再建実施前に、DX Criteriaを一度できていたら良かったなと思います。

ポイント３: プロマネにとっての喧伝方法とは

大企業での活用ポイント3つ目は、

３．成功に向かって進捗していることを伝える（ROI目標に達していない場合でも達成に向かっていることを客観的に伝える）

です。

正直申しまして、「再建で開発コストを半分にして見せる。」の大見得は、みんなよく分からなくても

「新しく来た人がヤンチャを言い出すことに任せたほうがトキに大企業病になりがちなところいい刺激になるだろうから、よほどでなければやらせてみよう。」

くらいに甘受してくれるところがあり、投資額などにある程度の合理性があればパワポ職人でも起案は通ったりすると思います（それだけでも”やってみなはれ”な、いい環境だと言えると思いますが）。

つまりこの時点ではプロマネとしての実力なんか関係なく、千載一遇の一陣の風にのってやるべきだと訴えるリスクを取れるかだけだと思います。

しかし、その後は成果で値踏みされますし、プロダクト再建の場合は途中で打ち切られるとしんどいというのもあるので、「再建で開発コストを半分にして見せる。」のシナリオがまんがいちROI的に失敗している状態のときに、どのように成功に向かって改善しているかの状態を説明可能にしておきたいところです。

そのときに、着手前よりも少しでも進歩したDX Criteriaの項目があれば、どこをどう改善して次にどんな打ち手を考えているのか具体的に説明しやすくなります。

（予算続投の理由づけになるものですから、長期案件の受託のアジャイルコーチなどでも活用できるのではないでしょうか。）

番外: 大きな開発組織で活用するメリット

番外ではありますが、伝えておきたいことがあります。

より詳細に申しますと私が所属しているのは大きな企業であるだけでなく、同時にかなり大規模な開発組織にも所属しており、それゆえの説明の難しさがあります。

開発組織の配下には様々なプロダクトとそのチームがいて、置かれているフェーズも問題もそれぞれに異なります。

しかし大組織で統制的な管理が行き届いているがゆえ、EOSL対処、セキュリティ対策やミドルウェアアップデートなどのLCMはタイムリーにまわっていますし、設計、QA、SAなどは専門部隊がサポートしてくれたりします。

それらが既に業務フローとしてまわっているだけに、組織の大ボスには、逆に開発の内部品質として何が問題なのかを伝えることが困難なことがあるのです。なぜなら、悩みの相談に聞こえてしまうと「それぞれの専門部隊とよく協力しなさいね。」「はい。」で、話が終わりがちだからです。

開発組織では、だいたいどっちかの振り子の下にいるもの。決してどっちも振り回されるな。

大きな開発組織に長く関わった方なら覚えがあるかもしれませんが、ボスにとっては魅力的に映るに違いない最大公約数的な利益とおぼしき統制的な管理には、どんなに合理的で素晴らしく見えても、現場にとっては手間と疲弊を呼ぶだけでたいしたPDCAが回らず、現場の努力ほどの効果が実らないものもあります。

数年そっち側に振れたあと、反動で逆振れして放漫もしくは現場主義に振れ、またしばらくするとその悪い側面に注目が集まって振り子が戻ったりということは、ありがちなことです。

たいがい、良きにつけ悪しきにつけ下っ端はどっちか方向に振り回されがちな状態にあります。重要なのは、どっちにも振り回されすぎずに、自分たちの信じるミドルグラウンドをしっかり歩むことではないかと、私は思います。

そうでもしないと大企業でやりたいことはやれないです。

誰もが良くしようと考えて努力をしているのが組織というものなので、もしかすると統制的な管理にも改善点はあるかもしれませんが、統制的な管理そのものについては特に評価めいたことはせず、DX Criteriaが統制的な管理にもメリットがあることを伝えるのがいいと思います。それが放漫もしくは現場主義に振れている場合も同じです。

例えば私の場合なら、以下のような説明を心がけます。

この（DX Criteriaという現在の統制管理には無い）チームの内部品質の基準尺度を改善していくと、組織で行っている統制的な管理基準を満たすための改善にもつながるのか、もしくは効率的にパスする結果につながるのか

もしDX Criteriaの基準項目に沿わない統制的な管理ルールがあったとしても、この先結果がでれば必ず振り子を動かすチャンスは巡ってくると思います。変えたほうがいいと思っている人が多ければ声をかけてくれる人が出てきて、味方が出来ていくと思います。

ここまでがプロマネチックな側面にスポットをあてた内容でした。最後の記事では、実際に実行してみた経験について書きます。

次の記事：めっちゃダイバーシティな開発チームで英語でDX Criteriaをやってみたプロマネの体験談（3/3）