社内システムでDXCriteriaを一部取り入れてみた

早くも2022年も12月に入りましたね。
SLAM DUNKの劇場版を見ました。当時の想いがこみ上げてきて大興奮。本当に良かったです。
見ていない方は是非！もう一度見てみたいと思ってます。

さてこれまで社内システムに関して記事を投稿してきましたが、今回は日本CTO協会が監修している企業のデジタル化及びソフトウェア活用のためのガイドラインである DX Criteria のシステムの一部を取り組んでみたので紹介します。

過去の社内システムでの記事はこちらです

DX Criteriaとは？

以下DX Criteriaより抜粋したものです。
絶対的なものではなく、各組織やプロジェクトに併せてどのテーマのクライテリアから実施していくのかを進めていくほうが良いかと思います。

本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。

また、本基準は絶対ではありません。誰かを攻撃したり、アセスメント結果の数字のみに注目して本質的な改善をおろそかにするためのものではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会のWG内で議論をおこないながら、適宜アップデートをしていくものです。

取り組むことになったきっかけ

弊社が日本CTO協会の法人会員となっており、弊社CTOからの紹介で取り組むことになりました。
特にシステムというテーマの中でも取り組むべき項目が色々あり、
社内システムのプロジェクトでも取り組むべきものがいっぱいあるので1つずつ潰していこうということになりました。

取り組んだ内容

取り組むとなっても、5つもテーマがあり、1つのテーマにも64項目もあるためまずは何からすればよいのか。。。

現状を知る！

まずは、DXCriteriaのアセスメントシートからシステムというテーマ内のクライテリアを
社内システムの各メンバーに回答してもらい、現状を知るということから始めました。
各メンバーでクライテリアの項目ごとに感じていることが異なっていました。

改善項目を開発チームで合意する！

各メンバーに回答してもらったものから、開発チーム内で改善すべき項目を投票、合意した上で進めることになりました。
通常のタスクもある中なので、2項目に絞り込み、それぞれの改善項目のオーナーを決めました。
また期限は2ヶ月とし、2ヶ月後に改善項目
以下が改善項目の2つです。

• SYSTEM-2-2 デッドコードを四半期以上のサイクルで定期的に棚卸しし、削除や分解をしているか。
• SYSTEM-4-6 デプロイされたコードに問題が発生した際に、前のバージョンへの切り戻しを意思決定してから5分以内に切り戻すことができない。

改善項目の取り組み

期間は約2ヶ月とし、取り組む内容のオーナー含めて週次で進捗MTGを重ねて進めました。

改善項目の内容は以下となります。

• SYSTEM-2-2 デッドコードを四半期以上のサイクルで定期的に棚卸しし、削除や分解をしているか。

  • フォルダやファイルのステップ数の測定をIntelliJのプラグインのStatisticで行う
    
  • デッドコードの検出方法は、IntelliJのインスペクションを利用し洗い出すを行う
    
  • 検出したものをUnused declarationで確認し、デッドコードを削除する
  • デッドコードの削除後、ローカルで動作確認する

• SYSTEM-4-6 デプロイされたコードに問題が発生した際に、前のバージョンへの切り戻しを意思決定してから5分以内に切り戻すことができない。

  • 検討した結果、社内システム上では5分以内にすることはできませんでした（以降の課題として認識）
    • 不具合発生時に不具合切り分けに時間がかかる
    • 前回バージョンへのデプロイにステージング環境などでの動作確認など含めて5分以上かかってしまう
  • 5分以内への切り戻しに近づけるため、以下のルールを決めた
    • リリース切り戻し時の意思決定のルールをリリース手順書に記載する
    • ロールバック用のSQLを毎リリース毎に作成し、切り戻し対応にいち早く実施可能とする
  • 以降のリリースで出てきた課題から改善を行っていく

取り組み後

デッドコードの削除に関しては第1四半期に少し遅れた実施し、リリース待ちの状態となりました。
まずは、影響の少ない画面・機能から実施することで、デッドコード削除後のリスクを極力へらすことにした。

リリース不具合の切り戻し対応は、5分以内にすることは難しいため、社内システムのアーキテクトやクラウド基盤のサービスなどの検証などを行い、即時切り戻しなどの対応を行っていく必要があると思います。
ただ今回の取り組みで、リリースまで、リリース時のルールを見直し、取りまとめることで大きくリスクを減らし、開発者とリリース担当者の認識をあわせることができました。

まとめ

DXCriteriaのシステムの中には他にも取り組むべき項目がまだまだあります。
すべてを改善することは難しいですが、ガイドラインにも記載されているとおり、デジタル技術を企業が活用するために体系化されたもので、システムの構造上必須の有無はわかれますが、とても重要な項目で様々な企業が活用できればと思っています。

社内システムだけではなく、弊社内の他案件にも横展開し、会社としてテンプレート化していければと考えています。まだまだ先は長いですが、継続して取り組むことが大切だなと思いました！