めっちゃダイバーシティな開発チームで英語でDX Criteriaをやってみたプロマネの体験談（3/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の重要なところをまとめたConfluenceページを作成

DX Criteriaの重要なところをコピーしたものを日本語と英語で作成しました。これは関係者に概要を説明するため。

次に、

２．なぜやるかの説明も書き、上司に説明

ポイントは

私たちが頑張ってきたことを数値で内外に説明しよう

評価面談で定性ではなく定量で説明するために活用しよう

の、大きく２点です。

３．英語版のDX Criteriaアセスメントシート(v202104)を作成

これは、日本CTO協会で提供されていたアセスメントシートを紐解いて英語化、もしくは日本語に英語版を足していきました。

最後に、

４．解説本の概略をまとめたConfluenceページを作成

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する を読み、重要なところを書き出したものを日本語と英語で作成しました。これは、

最も重要な理由は、「どうしてか知りたければ詳しくは本を読め」ではなく、DX Criteriaを計測する意味の裏付けとなる、どんなことを伝えたいのか効率的に引用するため。

特に英語版や日本語版を気にしながら伝達するのは思いのほか億劫で、2か国語で一箇所にあったほうが便利なんです。

ちなみに日本語だけで書いたページを渡して「Google翻訳してくれ。」は、日本語をある程度勉強しているエンジニアにそこそこ伝わればいいときはアリですが、割とトンデモ訳が出てそれに自分が気づかないこともあるので、ここは必要な局面と割り切り、時間はかかりましたが、主にDeepLの力を借りて最小の労力で書きました。

他には、自分がパワポ職人で頑張るよりも、権威ある本の引用のほうが説得力があるから。さらに、どこを重要だと考えるのかはっきりさせる自分自身の勉強を兼ねて、が理由でした。

どんな風に実行したか

私たちのチームには、テックリード1人、シニアエンジニアが３人、ジュニアエンジニアが3人（それぞれ新卒、歴2年目、3年目）、パートナースタッフが1人います。

そしていよいよ、プロダクトのなかで１つ再建リリースが終わったあと、評価面談が始まる前の期中に、チームのみんなにDX Criteriaを実施したい旨を伝達して、一緒にひとつひとつの評価項目に回答していく読み合わせ会を開催しました。

我々のチームの場合、一般的な日本企業と違ってデフォルトの会議枠は30分です。読み合わせは、30分×7回で計3.5時間かかりました。項目を読み上げる人は当番制で持ち回り。

また、その際、コーポレートの項は大企業だとチームの力の診断につながらない項目ばかりなので、丸ごとスキップしました。

工夫したこと

尚、各評価項目に「Contributor」功労者という欄を設け、この項目って誰が貢献したっけ？という名前を挙げられるようにしました。

これは「誰々が〇月にやったあれは、これに入るよね？」という会話が生まれ、「では〇〇さん、今期の評価振り返りで是非使ってね。」という流れが出来てなかなか良かったです。

学びがあったこと

普段、目前のプロジェクトの話はしますが、これから向かうところやチームの状態などについては、実は全然会話していないことに気がつきます。

長らくリモートワークで数か月メンバーと直接会っていないこともあるかもしれませんが、あっても限定的なメンバーだけのおしゃべりに留まっていた可能性が高いでしょう。

結論、どちらにせよDX Criteriaの読み合わせのようなお膳立て無しでは、なかなか全員が集まって体系的に俯瞰するような機会は出来ないと思います。

以下が、やってみて私がチームについて気づいたことでした。

・ファシリテーションがうまいエンジニアがいる

・ファシリテーションがうまいエンジニアは全員シニアだった（！）

・ファシリテーションにも、冗談を交えて楽しく進める人もいれば、コントリビューターの名前を挙げるのにみんなにうまく話を振ったり、どうしても答えが出なければ、ヒントになる話を出したり、と違ういい面があった

・技術的な知識は明らかにシニアが上だった（当たり前だと言われましたが(笑)）

・ジュニアエンジニアが全員素直に、「これ何ですか？どういうことですか？」と聞けていた（スバラシイ）

・特にKPI関連で、プロマネが問題だと考えている点をジュニアエンジニアはまるで問題がないと認識しているなど、相違があることに気づいた

・XPな環境を経験してきたシニアエンジニアがいると改めて認識できた

・ジュニアにとっては、今の状態にはまだまだ改善余地があり目指すべきところがあるのではないかと、客観的に捉えたり新しい用語を学ぶ機会になったはず

、、、現場からは以上です！

結果総論

DockerやJenkinsが利用できるような新構成と環境整備を進めてきただけあって、システムの項目を中心に大幅に評点を改善することができました。

もし問題ないことが確認できれば、英語版のDX Criteriaシートも公開したいと思います。

ここまでお読みいただき、ありがとうございました！