DXCriteriaは改善に取り組みたい人にとって最高のユビキタス言語

Adways Advent Calendar 2019 15日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2019


 

こんにちは、データエンジニアの内田です。

先日、日本CTO協会がDXCriteriaを公開されましたね。
この資料が改善を推進するに当たって最高のドキュメントだったのでその活用事例をお話したいと思います。

あらまし

内田「ミッションていうのはね、抽象度を高く設定するものなんですよ。オブジェクト指向だってそうでしょう?」
上司「??????!??!??!??!?」

f:id:AdwaysEngineerBlog:20191220154137p:plain

今思えば何を言っているのか自分でも判りませんね。

意図としては、日々遂行する業務はROIの高い、利益との関連性が
見えやすい業務を優先しがちです。いわゆる重要かつ緊急のタスクですね。

f:id:AdwaysEngineerBlog:20191220154213j:plain

出典:https://diamond.jp/articles/-/150657?page=4

そしてこの指標に従っている限り、リファクタリングは絶対にROIに敗北します。

とはいえ、日々技術的負債は溜まり続けているし、
前任者が作った動いているのかどうかよく判らないLambdaを棚卸しする時間は無いし
何より世界は急進的に変化し続けているのに漸進的にしか変化できない現状を打開したい。

そういった、見えないけれど重要な未来への投資、エンスージアズム、ミッションだけがエンジニアがROIに打ち勝てる唯一の武器なのです。

悩んだ

そうは言っても抽象度の高い?抽象度という言葉は使わない事にしたんでしたっけ?志の高いミッションとは?
具体的に何を指すの????つら... それを言語化していくのが次のクオーターのミッションかな...

f:id:AdwaysEngineerBlog:20191220154257p:plain

諦めかけていた時に出会ったのがDXCriteriaです。

DXに向けた具体的な行動がとんでも無いボリュームで列挙されている

ぜひ調査項目と説明資料 dxcriteria201912.pdfを全部見て頂きたいです。
DXの目指すところ、見えない投資の意義などが非常に具体的に書かれており、
また、簡易アセスメントシートでDXに必要な組織習慣や能力について自社を自己採点できるチェックリストも非常に素晴らしかったです。

f:id:AdwaysEngineerBlog:20191220154355p:plain

f:id:AdwaysEngineerBlog:20191220154435p:plain

[調査項目と説明資料 dxcriteria201912.pdf]より一部抜粋

DXCriteriaを面談の日までに書くと決意

求めていたのはこれだ..!絶対に簡易アセスメントシートを全部埋めきると決意し早速チェックリストを埋めて行きました。

書いてみた感想

結論から言うと、平社員がこのシートを書くのは全くオススメしません😇

f:id:AdwaysEngineerBlog:20191220154517p:plain

経営のデジタルファースト?まるで判らない...
とはいえやると決めたからにはやりきるしか無いので判らないなりに埋め切りました。
延べ5時間はかかりました..執念の5時間です。

それでも簡易アセスメントシートを平社員が書きたいと思った際のポイント

全社のDX化を踏まえつつ、自分のドメイン領域の中でも特に自分が取り組みたい事を示すと良いです。

現状特に課題だと感じているのはCI/CDが文化として根付いていない、テストコードが少なすぎる、意図が判らないソースコードを 棚卸しさせて欲しい(とその他諸々)だったので下記の様になりました。 ※黄色く塗りつぶしたセルが来期自分が取り組みたい事

f:id:AdwaysEngineerBlog:20191220154609p:plain

ここまで書き切ったら大丈夫やろ!

いざ面談へ

ワイ「...と言う事でこの項目を達成する事はデジタル化を進める為には必須の事柄だと自分は考えます。というのも2025年の崖というのがあってですね...」

f:id:AdwaysEngineerBlog:20191220154621j:plain

上司「お、いいねいいねー。採用。」
ワイ「??????!??!??!??!?」

 

 

 

 

 

 

 

 

〜完〜  

 

 

   

という事で採用です。流石に次のクオーターでこれ全部は厳しく無い?という事で優先順位の高いものを上司と握ったのが赤文字に変えた下記6項目です。

f:id:AdwaysEngineerBlog:20191220154644p:plain

延長戦

ワイ「ええねんけどリファクタリング反対してたよね?なんであっさり許可してくれたの?」

上司「いや最初から反対してないよ。自分も課題感は持っていたので、内田さんが今回言語化してくれたのが良かった。後は優先順位だけの問題」

ワイ「な、なるほど〜。」

※思い起こせば確かに反対はされてなかった。優先順位が下げられていただけだった。

なぜ認識のズレが起き、それが埋まったのか

お互いの役割の違いによって、常識、認知のズレが生じていたのだと今は思います。

f:id:AdwaysEngineerBlog:20191220154705p:plain

参考:組織の文化資本論 - 良いソフトウェアエンジニアリング組織はどの様に創られるか。
https://speakerdeck.com/hirokidaichi/cultural-capital-theory-in-software-engineering?slide=36

ROIとはP/L寄りのKPIですので、 B/S寄りのKPIを(暗黙的に)持っている我々現場のエンジニアと上司は別の認知をしているのだと理解しました。
学習する組織で言う「メンタルモデル」の問題ですね。

f:id:AdwaysEngineerBlog:20191220154724g:plain

参考:https://www.change-agent.jp/keywords/000933.html

「できごと」は変わらなくてもお互いの職務の違いから生じるメンタルモデルの差異が認識のズレを生んでいたのだと考えます。

この認識のズレを認識できたのは、
学習する組織で言う「共有ビジョン」を
DXCriteriaという共通の共有できるユビキタス言語を用いる事で持つことが出来たからだと考えます。

謝辞

広木 大地(@hiroki_daichi)さん本当にありがとうございます!!

経産省のレポートは前々から見ており、DXに取り組んで行きたいと個人的には思いつつも、ただの平社員に過ぎない身としてはどの様に取り組んでいって良いのかわからない、それどころが気持ち先行でDXをまだ言語化すら出来ていない状態だったので
DXのあるべき姿を示して頂けたのは本当に助かりました。

最後に

社員のみんな、俺の取り組む事はもうチャンネルに投稿してるので見てくれよな!

f:id:AdwaysEngineerBlog:20191220154743p:plain

  • [アンチパターン]システムのソースコードの閲覧を関連するエンジニアのみに限定している。(別チームのエンジニアや他のステークホルダーが閲覧できない。)
  • アプリケーションコードの循環的複雑度などのメトリクスを、ツール/サービスを用いて継続的に計測しているか
  • デッドコードを四半期以上のサイクルで定期的に棚卸しし、削除や分解をしているか
  • テストカバレッジ基準や自動テストガイドラインを用意し、これらを継続的に改善するための工数がチームで割かれているか。
  • プロダクトの半分以上のモジュール/クラスファイルに対して、ユニットテストが存在しているか。
  • データレイクから、データ分析基盤までのETL処理にも自動テストが存在しており、変換エラーなどがモニタリングされているか。

4Qで上記の6項目は俺が絶対に達成してみせる💪俺はやる!皆も頼んだぞ!

 


 

次は飛田さんの記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2019/16