はじめに
初めまして、サイバーフィジカル融合基盤プロジェクトの郭と申します。主にインフラ周りを担当しています。 自分が参加している開発チームでDX Criteriaを実施してみたので記事にまとめました。
何故やったか
昨年度より富士通も全社的にDX企業になるべく活動をしています。私たちの部署は主にソフトウェア開発をしているため、自分たちの部署でDXを実現するために何をしたら良いかをずっと考えてきました。偶然、興味のあった勉強会(Serverless Meetupと記憶していますが)で紹介されたことをきっかけに、このDX Criteriaを知りました。アセスメント項目をざっとみて、これは自分たちに必要でやるべきだと強く感じ、実施してみることにしました。
DX Criteriaとは
DX Criteriaとは、日本CTO協会というイケてるIT企業のCTOが集まった団体が作成したアセスメントツールです。 このアセスメントツールを使うと自社のDX進捗度が測れるものになっています。また、詳細なアセスメントも可能となっており、自社の強みや弱みを詳細に知ることができます。
5つのテーマ(チーム、システム、データ、デザイン、コーポレート)からなる合計320項目に回答するものになっています。
各項目に対し実施できているかを、基本的にはYes, Noで回答し、やったけどうまくいかない場合はYes,But、まだやってないがこれからやろうとしている場合はNo,Butを回答します。
また、各カテゴリにはアンチパターンの項目が3つありYes, Noが逆転します。
アセスメントの進め方
私が参加している2つの開発チームで今年の2月から週に1回2時間程度、チームメンバー全員で議論しました。よく分からない項目や参加者だけでは答えられそうにない項目は、点数が入らないようにNoで回答(アンチパターンならYes)して、あくまで内部で何が抜けていて、何をやらないといけないのかを明確にするために実施しました。
2つのチームで違う進め方で実施したので簡単に説明しておきます。 1つ目は社内ツールを開発しているチームで、2019年度下期に立ち上がったチームです。業務フローの自動化をメインにSREチームとプロジェクト内の参加希望者で構成されています。主なお客様は自分たち(研究員)です。こちらのチームは、自由参加ということもあり、日頃から活発な議論が行われてるので、研究員が集まってその場で議論して回答する形式を取りました。
もう1つのチームは、弊社から出している観光アプリ「たびしるべ」の推薦エンジンを開発しているチームで、2018年度に立ち上がったチームです。研究員がアルゴリズム、データ基盤、クラウド展開、クラウアントアプリなどを数名で担当しています。主なお客様は事業部、その先の観光協会、さらにはコンシューマユーザです。こちらのチームは、個人が担当を持っていることもあり、担当外のことについてはあまり口出ししない感じだったため、その場の雰囲気に流されることなく自分の意見が言えるよう事前に個人でアセスメントを実施し、集まったタイミングで議論して回答する形式を取りました。
また、担当だけでなく、それぞれのチームを担当しているマネージャにも可能な限り議論に参加してもらいました。
アセスメント結果
正直なところ、点数が悪すぎて、公開するか随分悩みました。結果を公開しないことには、どう活用できるのか議論できないので、結果のみを公開(合算すれば点数でます)とすることにします。点数の良し悪しについても議論しますが、あくまで富士通研究所の一部門についてであり、必ずしも他の部門に当てはまるわけではないですし、他社と比べられるものもありません。ご了承ください。
現状の弊社の状態と現場の研究員がどう自分たちの組織を変えようとしているのかを見ていただければと思います。
社内ツールチーム
以下のような結果となりました。チームやシステムについては参加者持ち寄りでこれまでの開発経験を踏まえた状態で開始したため、比較的点数が入りましたがデータやデザインに関しては、顧客が自分たちということもあり、特に設定しなかったため低い点数となっています。
推薦エンジンチーム
以下のような結果となりました。全体的に実施できていない項目が多いですが、クライアントアプリでユーザの移動履歴元に推薦しているため、カテゴリの顧客設定のデジタル化だけは7.5点と高い数字となっています。
結果に対する考察
何が実施できていて、何が実施できていないのかをみてみます。会社や制度が同じなので共通することも多く2チームまとめて書いています。
実施できている点
- 開発環境
- WindowsでもMacでも買えて、自社製品であればフルスペックで利用可能。
- 日常的に使うツールとして、Slack、GitHub、Atlassian Cloud(JIRA/Confluence)、G Suiteなどが利用可能で、パブリッククラウドへのCI/CDもCircle CI、GitHub ActionsやOSSを組み合わせて使っている。
- セキュリティ規定の拡張
- これまでの社内規定ではカバーできていなかった他社クラウド(AWS/GCP/Azure)やSaaS利用に関して、社内規定を踏襲・拡張したチーム内でのセキュリティポリシーを規定。
- ポリシーの例として、2FAを必須とし、関係者全員へのFIDOセキュリティキーの配布。
- チーム構成・権限委譲
- きちんと行われており、幹部社員への確認待ちが発生することはない。もちろん他部署への連絡や確認はすることはあるが開発チーム内で意見をまとめる程度で幹部社員が独断で決めることは発生しない。
- 1on1の実施
- 幹部社員との1on1を2週に1回程度実施しており、気軽に相談する時間はもらえる(幹部社員の方は大変そうですが)。
実施できていない点
- ふりかえり習慣がない
- コア技術の改善は継続的にやるが、毎回違うデモを作る。一つ一つがお客様に提供する価値に繋がるまで試作を繰り返したり、ふりかえりする習慣がない。
- メトリクスの計測ができていない
- 全カテゴリに共通していえることだが、メトリクスの計測が全くできていない。習慣づけが必要。
- 掛け持ちが多い
- 研究員は好きなチームに参加できる一方で、個人やチームとしての研究テーマも持っているので、なかなかフルで1つチームにコミットすることができない(もちろんフルで1つのテーマにコミットしている方もいる)。
- 属人化が発生する
- 推薦エンジンチームで言えば、担当箇所が決まっておりどうしても作った人に聞くことが発生してしまう。
- コーディング規約がない
- Linterを入れる人もいれば入れない人もいる。ルールもバラバラ。
- セキュリティチェックが不十分
- コンテナに含まれる脆弱性はチェックしているが、コードの静的解析はやっていない。
- CI/CDができていない
- 社内ツールチームは、開発と並行してビルドパイプラインを組んでいる最中でまだできていない。
- ペルソナを定義していない
- 社内ツールチームは具体的なターゲットを"自分たち"としか設定しておらず、幹部社員なのか研究員なのか、コードバリバリかけるのか、そうじゃないのかで、考慮すべきことが違う。
- 推薦エンジンチームも観光客としか定義しておらず、意思決定がステークホルダーの要望になってしまうことがある。
- ユーザインタビューしていない
- 社内ツールチームは近くにお客様がいるわけで、参加者以外の方からもニーズのサーベイはしておくべき。
ふりかえりと改善策の検討
アセスメントのふりかえり
チームメンバー全員でやったため想像以上に時間がかかりました。2月からやり始めて、おおよそ週1回やって6月までかかりました。事前に個人で実施する場合、意見の食い違いが生じてしまい議論するとどうしても時間がかかってしまいました。チームメンバー全員でやる場合は、発言しない人が居ないようであれば、全員で集まって回答しても良いのかなと思います。
一方で、普段の業務では、なんとなく推測してやっていたり、言わなくてもわかるだろう、で進めていたことを、改めて、言語化して、みんなで考え直す良いきっかけになりました。
また、研究員に共通することなのですが、自分の研究分野以外のことを知る良い機会になりました。あまりに素人すぎて、単語帳を作ってチーム間でシェアするようにしました。(笑)
改善策の検討
DX Criteriaには点数のみに着目することなく、現状を把握するのに使用すべきと注意書きがしてあります。 アセスメントが完了したのちに、改善すべき項目を1人3つあげを議論しました。
すぐに着手可能なものから、時間がかかるものに分け、以下の9カテゴリについて改善策を取ることにしました。また、ふりかえり習慣が0点だったことから、ピックアップした改善策を実施できているか、定期的に振り返る時間を設けるようにしました。詳細は割愛しますが、どういうツールを使って、どう実施すべきかまで落とし込んで実施できる状態になるまで議論しました。
- ソースコードの明確さ
- セキュリティのシフトレフト
- ペルソナ設定
- ユーザインタビュー
- メトリクスの計測
- システムモニタリング
- 継続的デプロイ
- API駆動開発
- 疎結合アーキテクチャ
参加者の感想
アセスメントが終わった後に参加者にDX Criteriaをやってみてどうだったかを聞いて感想をピックアップしました。 ほぼ全員が口お揃えて言っていたのは、DXを実現していくために自分たちで何をやらないといけないか共通意識を持てたということでした。
- DX Criteriaで具体的にDX企業になるために何をしたら良いか示したものになっているのは良い
- 案件の性質によっては全く点数が入らないことがあるため、
チームやシステムに絞って実施しても良いかも - 開発の初期だとスコアが低くなるので、開発フェーズが進んだ場合も考慮して定期的に評価したほうが良さそう
- アセスメントをやりながら気になった項目はすぐに改善するようにした、そこから組織をどう動かすかが今後の課題
- 全社で統一するのは無理なので、研究テーマやプロジェクト(部署)ごとにやるのが良さそう
- 自部署、事業部、全社、どこを想定して回答したら良いか迷うことがあった
- 企業が大きくなると組織が細分化されてしまい、特に
コーポレートは答えられないことが多かった - 回答できない選択肢として
不明も欲しかった - コロナ禍でリモートワークなって雑談が減っていたのでコミュニケーションにはよかった
- DX Criteriaには多面的な軸があり、普段聞くことない研究員の考え方が聞けたのがよかった
- 他のグループで課題を感じてるところがあれば広げていけると良い
- 今回のアセスメントは、自部署の開発チームで実施したが、どういうメンバーで議論したら良いか、違う部署の人たちも入れるべきかについて記載がDX Criteriaにあるとよかった
- アセスメントをやりながら、他部署の人たちも入れたほうが良いと気づいたが、自社のように人や業種も多種多様でこれだけのために声かける訳にもいかず事前に知っておきたかった
- DX Criteriaは主に開発・運用フェーズにフォーカスが当たっていると感じた、改善すべき点多くあったのも事実
- 一方で研究や新しいことをやるを考えるフェーズには別の評価軸が必要になりそう、何かまではわからないが時間軸で区切って活用するのが良いか
- 普段、言葉に出して言わないようなことをいったり、いろんなことを考える時間が多かった気がするので、糖分あったらよかった！
終わりに
DX Criteriaを紹介し、開発チーム全員参加で実践してみました。なかなかベンチャー企業のように、すぐに実施して改善するところまで持っていくのは難しいですが、自分たちでできることを地道にやって地に足つけた改善を実現していきたいと考えています。
DXを実現したいがどうしたら良いかわからないとお困りの場合は、一度アセスメントを実施して、自分たちに何が足りないのかを見つけるのに使ってみてはいかがでしょうか。
