技術負債の削減に向けた提案～「DX Criteria」の活用～
はじめに
DX（Digital Transformation）に対する期待とニーズは日増しに高まり、企業ITを司るCIO/CTOならびに情シス部門の皆様からも多くご相談を頂いています。
中でも「技術負債にどう向き合っていくべきか？」というテーマは、非常に重要かつ悩ましい課題の1つです。
デジタル時代の昨今、何らかの施策の実現にITは欠かせません。新規や既存の種類を問わず各企業で日々様々なシステム開発が進んでいます。つまり今現在も、未来の技術負債が増え続けている可能性があるのです。
まずこの発生を食い止めることが最優先課題なわけですが、ここではそのための1つの施策を紹介したいと思います。
技術負債の正体
技術負債を考える際に重要な視点が「内部品質」です。利用者からは見えないこの「内部品質」への考慮不足こそ、技術負債を生み続ける根本原因です。結果的に外部品質そしてユーザー品質をも劣化させると同時に、エンジニア含む保守メンバの精神的負担を強いる一端となっています。
（引用：和田卓人氏資料（質とスピード（2020春版） / Quality and Speed 2020 Spring Edition）)
内部品質のやっかいなところは、表から見えないという点です。ですので経営陣や業務ユーザーからは理解を得られないことも少なくありません。
参考までに、少し細かくなりますが各品質にはどんな項目が含まれているかをまとめました。こうしたユーザー品質や外部品質の項目をすべて満たすのはとても大変なことではあります。ただだからといって内部品質をないがしろにして良い理由にはなりません。
（参考：つながる世界のソフトウェア品質ガイド～あたらしい価値提供のための品質モデル活用のすすめ～：IPA 独立行政法人 情報処理推進機構）
なぜ内部品質は軽視されてしまうのか？
内部品質が軽視されてしまう理由は先程述べた「見えにくい」ということ以外にも複数考えられます。
● 目先のコストを下げたいから
● ITに関わる意思決定が組織論的に短期的な視点で意思決定される傾向があるから
● 発注側がベンダー（開発チーム）との関係性から強く要求を言えないから
● 自社にその見極めができるリソースがないから
正直属人的/組織的な問題も大きいのですが、ただ最後の「リソースがない」という問題は情シスとして対処すべきでありながら正直泣き所です。
内部品質を担保するためには一定レベルの開発管理技術が欠かせません。一般企業の情シス部門が最新の開発管理技術に長けたエンジニアを採用することは、現実的に困難だからです。
結果、開発を委託しているベンダーに内部品質を依存せざる得ないのが実情です。ベンダーの中にも優秀な開発チームはたくさんありますが、とりわけ内部品質の管理能力は見極めが難しい。結局運に頼るような管理になるケースも少なくありません。
そこで現実的な対策として、内部品質向上に向けた外部公開ナレッジの活用を提案したいと考えています。ここではその具体例として、今最も有効なナレッジの1つである、日本CTO協会が作成した「DX Criteria」をご紹介したいと思います。
「DX Criteria」とは？
「DX Criteria」とは一般社団法人日本CTO協会が作成している「DX基準」です。長期的に成果を最大化させるためには、「Digital Transformation（企業のデジタル化）」に加え、「Developer eXperience（開発者体験）」を両輪で推進することが必要不可欠であるという「2つのDX」を謳い、成長の基盤となるIT組織の改革を行い、技術負債を増やさない開発体制への進化を最優先に考えるための知識体型とも言えます。
「DX Criteria」にはチーム、システム、データ駆動、デザイン思考、コーポレートの５つのテーマがあります。中でも内部品質にはチーム＆システムの2つのテーマが密接に関連します。
各テーマは8つのカテゴリとカテゴリ毎の8つのチェックリストからなります。つまり1テーマにつき64個のチェック項目が存在します。
各チェックリストは、昨今のエンジニアリングにおける教科書とも呼べる各種技術書や実践的な技術ノウハウを元にバランスの取れた項目で構成されています。ちなみにこの項目は読むだけで網羅的な技術管理観点を知ることができるので、単純に読み物としてもおすすめです。
実際に各社でこのチェックリストを使ってみたというレポートが複数公開されていますので、そちらも参考にしてみてください。
実際の適用イメージ
この「DX Criteria」はDXに関する網羅的なチェックリスト（とういかナレッジ）なんですが、5つのテーマを全部丁寧に対応しようとすると結構大変です。
そこで、システム開発における技術負債削減に向けた内部品質向上という観点に限定するのであれば、チームとシステムの2つのテーマに限定して使う方法もお薦めです。（各テーマに依存関係はないので、部分的な活用ができるのも「DX Criteria」の利点かと思います）
実際、私が担当している某お客様向けの保守および継続開発チームに、この2テーマに絞って「DX Criteria」を適用してみました。
ちなみにこのチームは約30人規模体制であるお客様のシステムの継続開発を約3年に渡り受託しています。実際にトライしてみたチームからは以下のような声が挙がりました。
- 具体的に数字化されると今のチームの強み弱みが明確になった。
- ずっといつかはやらなければと思っていたことではあるが、改めて具体的な改善に落としやすくなった。
- チェック項目に対して、現状、評価、備考コメントが書けると定点観測（PDCA）がやりやすい。
- その質問で確認したいこと（観点）の補足記述があると評価を入れやすいと感じた。
- 改善施策の優先順位の立て方がポイントになりそう。
- 若干質問の語句が難しいものがあった（調べることで勉強になるが）
技術負債の削減に向けて
自ら受託開発を生業にしていて思うのは、ITパートナー（いわゆるSIerなど）側も決して内部品質の向上に対して無頓着なわけではないということです。ただ半分言い訳になりますが、なかなかその優先順位を高めることにクライアントと合意が難しいという部分と、開発チームが日々の作業に忙殺され「いつかはやらねば」をなかなかアクションに落とせないというのが現実的な課題です。そんな課題に対して「DX Criteria」は非常に効果的な打ち手だと思います。
本来日本CTO協会の設立主旨やDXCriteriaの開発背景を踏まえると、より包括的かつ内製化という文脈を想定されていることは想像されます。
ただ現実を見ると、国内における企業情報システムの多くはSIerなどのITパートナー企業にその保守や開発をアウトソーシングしている場合がほとんどです。携わっているエンジニアの数も圧倒的にITパートナー側が多い。内製化もコア領域なら可能な範囲で推し進めるべきではありますが、すぐに大局が変わるのを期待するのは現実的ではありません。
そう考えると、こうした新しい開発の在り方/やり方をより多くのユーザー企業に広め、ITパートナー側に一定の内部品質を体系的に要求していくことが大切だと私は思います。ユーザー企業とITパートナー企業とのいい意味での緊張感こそが、内部品質も含めた総合的な品質の底上げにつながると信じています。
そして業界全体としてDeveloper eXperience（開発者体験）の向上を謳っていくことこそが、エンジニアリング復興に向けて次世代エンジニア達に未来を託す我々の責務だとも思っています。もちろん厳しいビジネス要求の最前線で、関係者全てに理解を得ていくことは簡単ではありません。ただユーザー企業の経営陣や事業ライン側の方々にこうした理解を得るためのお手伝いをすることも、我々ITパートナーにとって大切な仕事だと思っています。
いづれにしても「DX Criteria」が受託開発チームにおいても効果的なナレッジであることは確認することができました。今後より多くのお客様にこうしたナレッジを知ってもらえるように努力をしていきたいと思います。
最後に
色々と「DX Criteria」を周りの皆様ご紹介したところ
- DX Criteriaを使ってみたいけどもう少し詳しく中身を知りたい。
- 実際にベンダーに適用してもらいたいけどその依頼や監査を自社だけでやるのは不安
という情シスのお客様もいらっしゃることがわかりました。
そこで弊社で「DX Criteria」の適用を支援するサービスを用意しました。
もしよろしければ上記ページからお問い合わせください。
この記事が気に入ったらサポートをしてみませんか？