DX Criteriaを使って開発体制の改善状況を振り返る

Satoshi Tajima
Dec 9, 2020 · 7 min read

こんにちは。Finatextでエンジニアをしている@s_tajima です。
この記事は、CTOA Advent Calendar 2020の、12/9の記事です。

弊社では、日本CTO協会の出している、DX Criteria を使って自分たちの開発体制についてのアセスメントをしています。
初回は2019年12月頃に実施し、最近あらためて今の状況を確認してみました。

結果として、初回に比べて大きな改善傾向がみられたので、今回はその詳細について紹介します。
尚、今回紹介するアセスメント結果は私が全社の状況を俯瞰することを心がけて実施したものですが、これとは別にチーム単位でのアセスメントをしていたりもします。

アセスメント結果の比較画像

2回分のアセスメントの結果を並べた画像をお見せします。
左が2019年12月、右が2020年10月の時点のアセスメント結果です。

結果として、青(=ポジティブな評価)なエリアが増え、この約1年間で大きく改善していそうなことがわかりました。
セルフアセスメントによるものなので、他社の公表しているものと比較する意味はそれほどないかなとは思いますが、同じ人間が同じ組織・開発体制について評価したものなので、相対値としては参考にできるものと考えています。

改善内容のうちわけ

いくつかのポイントをブレイクダウンして見ていきます。

team

このテーマは、特にチームビルディングが 1.5 → 6.5 と、大きく改善しました。
ここが改善した要因は、2019年11月頃に、今まで雰囲気で形成されていたチームという概念を、オフィシャルなものとして明確に導入したことかなと思っています。
それによって、チームごとのオンボーディングの体制が整えられるようになったり、振り返りやPostmortemといった取り組みが積極的に行われるようになりました。

結果として、 チームは月に一度以上の頻度で仕事のふりかえりをおこなっており、その際にプロジェクト憲章またはインセプションデッキの認識を揃えているか。 は No → No, but に、新しくチームに参画するメンバー用のオンボーディング・デック(チームの一員として働き始めるための、価値観・実務・スキル・相互理解のための明文化されたドキュメント集)が存在するか。 は No → Yes という回答に変更になりました。

system

この項目は、特に継続的インテグレーションが 4.5 → 7.0 と改善しました。
この1年間で進めたこととしては、

  • GitHub Actions/AWS CodeBuild/AWS CodePipelineを用いたCI/CD基盤の整備とその展開
  • golangci-lintConftestのような、Lint/静的解析ツールの導入
  • SonarCloudによるソースコードのテストカバレッジや品質の可視化

といったことをやりました。

data

dataについては、テーマ全体のスコアが 24.5 → 42.5と大きく改善しました。
なかでも、データ蓄積・分析基盤 については 1.5 → 7.5 となっています。

この分野は、

  • Embulk を用いたバルクのもの、CloudWatch Logs / Kinesis Firehose を用いたストリーミングのもの、それぞれによって分析環境へのデータ移行を行えるように
  • Athena / BigQueryを用いたデータ解析の環境構築
  • 非エンジニアに対しても解析環境を解放し、使い方をレクチャー

といったことをすすめることができました。

design

1つ前のテーマである data が大きく改善したことで、現状スコアが一番低くなってしまったのがdesignです。
このテーマは、全体的に メトリクスの計測 についての項目が達成できていないなという印象です。

個人的に印象的な項目としては
一年に一度以上の頻度で経営幹部も参加するプロトタイプづくりのワークショップを行っているか。
というところで、前回 Yes だったのが今回は No, but になっています。

去年は、新規事業のためのプロトタイプづくりとしてオフサイトでのハッカソンを実施したりしていたのですが、今年は新型コロナウィルスの影響などもあり、そのような施策が実施できなかったので、来年はうまく計画していけたらいいなと思っています。

corporate

このテーマは、前回も一番高かったのですが、今回はさらにスコアをあげて引き続き一番高いスコアとなりました。
コミュニケーションツール に関しては、スコア上の変化には現れないのですが、歴史的経緯により、SlackのWorkSpaceが子会社の単位で複数に分かれてしまっていたのを統合し、グループ全体でのコミュニケーションを取りやすくなるようにしたり、ドキュメントツールの利用を促進するなどの施策を行いました。

セキュリティ面に関しても、顧客向けのサービスを提供するAWS環境の管理を改善したり、MDMやEDRの導入によって従業員が利用する端末のセキュリティを高めたりといった施策を進めました。

改善の成果

超高速な事業仮説の検証能力

DX Criteriaは、その設問事項に対する回答が改善することを目指すのではなく、その先に「超高速な事業仮説の検証能力を得ること」という目的があります。

この成果を測定する尺度は様々あると思うのですが、1つの指標としてPull Requestがマージされるまでの時間というのがあると思います。この画像は、Pull Pandaから確認できる弊社のGitHubリポジトリの運用の状況です。

一般的に、金融機関のシステムは、ちょっとした機能の追加や修正、時にはただの文言の変更に数週間から数ヶ月のリードタイムがかかってしまうと言われていますが、弊社の場合は、多くのリリースがPR作成から1日以内にマージされ、リリースされている状態です。

この指標だけで私達のやり方の正しさを示せているわけではありませんが、冒頭の「超高速な事業仮説の検証能力」というのを一定の割合で保持できているという参考情報になるかなと思います。

最後に

以上、弊社のDX Criteriaを使った開発体制の改善状況を振り返りの記事でした。
現在、Finatextグループではエンジニアを積極的に採用しています。今回紹介したような開発体制の改善に興味があるエンジニアの方は、ぜひ一度お話しましょう! 私のTwitterにDMをいただくか、以下の応募フォームから気軽にご連絡ください。

Finatext

THE Finatext Tech Blog

Finatext

THE Finatext Tech Blog

Satoshi Tajima

Written by

Finatext

THE Finatext Tech Blog