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

（スタート）あっ、もしかして来るところを間違えたよね？

現在の環境に入社1ヶ月くらいすると、あれ？やっぱり来て大丈夫だったのかな？と思い始めました。面接での話が的確だったので半分くらいは覚悟していましたが、なかなかにアジャイルと程遠い重めの現場だったからです。

私は業界歴だけは長いのですが、これだけ技術的負債を溜め込んだWebベースの現役システムは、業務基幹システム以外ではお目にかかったことがありませんでした。

ですので、プロマネとしての初めての仕事は、テックリードと協働してプロダクトの再建プランを起案することでした。尚、私にとっては英語環境も初挑戦でした。

開発コストを半減させてみせる

未来の姿に向かおうにも、まずは複雑化したレガシーなシステムに手をつけなければ何の進化も見込めないと確信して、「完了したら開発コストを半減させてみせる」という大見得を切って、プロダクトの作り直しについてステークホルダー各所の理解をとりつけました。

現役プロダクトを何箇所かに分け、UIの挙動を変えずに、もしくはUIUX改善を加えながら、最新のTech Stackで作り直したものに差し替えていく方法です。

そこそこ若いプロダクトを扱っているチームには、「いやいや、もうちょい少しずつリファクタリングしていくことは出来るだろ？」とか、大きい企業の組織の人ならQAチームが品質管理にテコ入れすれば開発チームの負担を減らして、半減ならずも1/3カットくらいまでいけるんじゃないか？とかいろいろとお見立てがあるかもしれません。

しかし個人的には、減価償却し終えているだろうソフトウェア基盤部分に、地雷を踏まないようにまた泥を重ねるように資産を積み上げていく泥船積木なんてエンジニア人生にとって意義なくない？というのが一番の気になるポイントでした。

エンジニアが死んだ魚の目をして作っていたらイイモノが出来ないですし、プロマネとしてもどうビジョンを語っていったらいいものか、将来を皆目見当つけかねました。

昔はよか..いや、今が大事だよね。

しかし、実際には当時の技術でのプロダクトとしてはしっかりしていまして、現在のこの成長規模を想定しなかっただろうなというヒャーと思うようなものまでちゃーんと現役で動いています。

昔のエンジニア（SE？）ってOSI参照モデルを何階層も自由に行き来してスクラッチでコードを書く人ばかりだったと尊敬しかないです。いわばプリミティブ。

しかしイマドキのエンジニアには下層と上層を行き来できているコトよりも、それぞれの領域でしっかりとパフォーマンスを出すということが求められているような気がします。

SREやDevOpsという概念が出てきて浸透し、データエンジニアとかフロントエンジニアとか、それぞれの領域で効率的な大量のデータの行き来とレスポンスを追っているというような。ソフトウェアエンジニアに、「IPv6ってなんでしたっけ？」っ言われても特に違和感もないと申しましょうか。

良い悪いではないですよねぇ、、、って、話がそれましたので、もとに戻します。

何が問題か？それは人がすぐ辞めてしまうこと

当時どんなに素晴らしく作られたものでも、今現在担当しているエンジニアが生き生きと向き合えなければプロダクトとしての未来も暗くなってしまいますので、やはり今生きている人を大事に考えてゆきたいものです。

６ヶ国の多国籍な若い前途洋々のエンジニア達にとってはDockerもフレームワークも無い古いテックスタック環境で何年か開発をしていくということは、どういうことか。

「うーん。あり得ないよね？どう？絶望しない？」って聞いてみたら、外国人ならみんなはっきり意思表示してくるだろうって？

いやいや、そんなことないです。こつこつと信頼関係を作ってから、こっそりこちらも自己開示して話したら苦笑いしながら正直に打ち明けてくれるかもしれませんが。

ただただ分かりにくく複雑化したプロダクトにオーダー通りに手を加えるだけの保守開発を延々とやり続けなきゃいけないのにやたら品質やらインシデントゼロやら言われたら疲れますし、誰しも少しは自分の将来はこれで大丈夫かなと不安になるでしょう。

心理的安全性にお国柄はあるのか？

それを正直に口に出せるかというのは多少個人差やお国柄やビジネスマナーの違いはあるかもしれませんが、その組織の環境や状態がよくなければ、まず口には出来ません。いわゆる心理的安全性の重要さは同じだと思います。

きっと何もしなければみんな3か月の教育コストをかけて1-2年で去っていく、というような暗澹たるサイクルになるでしょう。この先自分も疲弊して同じところをグルグル廻ることになるのは避けたかったです。

そもそもレガシーであるゆえにナレッジトランスファーが思い通りに進まず、テックリード自身も望んでいないのにメンバーにとっては過剰に権威的に感じられる悲劇的な状態に見えました。

情報の非対称性が是正されないと、テックリードの適切なアドバイスも活きてきません。

プロマネとしては、ROIをなんとか説明して再建を提案するしか、取れる道はないと感じていました。

次の記事では、DX Criteriaを大企業でどのように活用してプロジェクトを説明するかについて書きます。

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