テクニカルデットをDXとAIで管理する

すべての会社、大小関係なく、テクニカルデットを心配しています。 ガートナーによると、約40%のインフラシステムがこの問題を抱えています。マッキンゼーのCIO調査によると、約3分の1のCIOが、新製品予算の20%以上をテクニカルデット関連の問題解決に費やしていることを感じています。ただし、多くの人が考えているように、これは単なるコーディングの問題ではありません。開発者エクスペリエンス（DX）の問題でもあります。開発者が不十分なアーキテクチャ、古いツール、開発ワークフローで作業しなければならない場合、生産性、パフォーマンス、モラルが低下します。

テクニカルデットを優先し、開発者の視点を考慮し、開発者が仕事に取り組む方法、使用するツール、取得できるキャリアアップを考慮することで、チームは焦点を当ててより迅速に作業できます。これが、企業がテクニカルデットを管理する方法が変化している理由です。DXとAIパワードツールへの焦点の増大によって推進されています。

DXを推進する

開発者のオンボーディング方法は、多くの場合、改善の余地があります。プロジェクトに貢献するために、数週間かかる場合があります。小さな機能やパッチを追加した後、CIサービスが変更とは無関係な理由で失敗することがあります。これは、テストスイートの品質の低さによるもので、開発者はテストスイートを壊す変更を提出しません。古いテストスイートは、90%の時間しか動作しません。既存のチームはそれに慣れているかもしれませんが、外部の人にとってはツールは古いもので、開発者の士気を下げるものです。

これは、DXを妨げる多くの例の1つです。そうしたことを防ぐには、ソフトウェアエンジニアリングと開発チームに指定されたチャンピオンが必要です。多くの小規模組織にはDXリーダーがいませんが、大規模で成功している組織にはいます。これらの専門家は、新しい開発者が環境を設定するのにかかる時間などを追跡します。2週間が長すぎる場合、時間を半分に削減する方法を見つけます。

CircleCIのようなツールが利用可能で、テストスイートの不安定性を追跡するネイティブ機能があります。必要なのは、スプリントの後に停止して、コードを将来より簡単に維持および作業できるようにする変更の一部を処理するリーダーです。DXを改善したいリーダーが必要です。そうするには、シニアエンジニアと、新しいスタッフメンバーを探し、潜在的なギャップに関するフィードバックを提供します。

また、IDCは、AIパワードのソフトウェアテスト自動化市場が2027年までに31.2%のCAGRで成長し続けることを予測しています。したがって、このテクノロジーを最大限に活用するようにしてください。

警告サインとメトリクス

チームにテクニカルデットが与える影響を評価する際に追跡できるメトリクスは多数あります。基本的なものは「修正時間」または「機能時間」です。バグを発見し、修正方法を知っている場合、コードの書き込みから生产までにかかる時間を追跡するツールがあります。たとえば、小さなパッチが2営業日かかるのに対し、チームは数時間で修正して出荷する必要があります。また、バグ修正数と機能完了数の比率を追跡することもできます。

モラル問題がチームのパフォーマンスに影響を与えることを特定する方法もあります。DXリーダーは、開発者がプロジェクトやその一部で作業していることに満足しているかどうかを判断するために、四半期ごとに調査を実施できます。CIプロセスなどの特定の領域について詳しく聞くことができます。また、チームの離職率や転勤率を追跡することもできます。人が頻繁に離職する場合、彼らは自分の懸念が聞かれていないと感じている可能性があります。

AIを活用する

AIツールの台頭は、開発者とエンジニアの生産性を高め、製品をより迅速に出荷することを目的としていますが、テクニカルデットはこれを妨げます。たとえば、GitHubまたはCopilotのようなツールを使用してコード変更を支援し、プルリクエストを送信し、CIが数時間後に戻ってくる場合、開発者は他の作業に取り組みますか。メールを確認しますか。コンテキストの切り替えと生産性の低下につながります。

開発者は、コードに集中できる製品で作業したいと考えています。ツールは、コードを生産に移すのを助けるもので、常に障害になるものではありません。AIは時間を節約できますが、エンジニアリングチームが受け入れられる複雑さの基準を定義する必要があります。そうするには、最初に、メインブランチに追加されるコードが受け入れられるレベルのテクニカルデットを持っていることを確認します。その前に、エンジニアリングチームとテクニカルデットとコード品質の受け入れ可能なしきい値についてのオープンディスカッションを実施し、全員がそのしきい値を超えることは即時の是正を必要とすることを理解するようにします。基準を定義した後、AIが活用されます。

エンジニアとAIエージェントが協力するケースがあります。カペジミニによる1,100人の幹部の調査によると、82%が次の3年以内にAIエージェントを統合する予定です。また、仕事の未来にも影響を与えています。バグレポートを見て、AIエージェントがコードレビューまで処理できる小さなバグである場合、チームの時間を節約し、より複雑な作業に集中できるようになります。ただし、ときどきこれらのツールに盲目的に従うと、AIが考慮しないトレードオフが発生する場合があります。

それが人間の判断が決定的な要因となる場合です。

目標とテクニカルデットの整合

テクニカルデット削減を目標と測定可能な成果に整合させる方法は何ですか。受け入れられるテクニカルデットに戻ります。ビジネスでは、迅速に出荷する必要がある場合があります。製品がスケーラブルではないこと、パフォーマンスの問題が発生する可能性があることを知りつつも出荷できます。開発者は、後で問題を解決するためにメモを残すことが多いですが、実際に解決することはほとんどありません。そうした文化が定着すると、テクニカルデットの影響が明らかになります。

これはスタートアップにとっては理解できますが、10年以上運営しているビジネスにとってはそうではありません。テクニカルデットを管理する文化の転換を早期に開始し、積極的に管理する必要があります。そうしないと、生産バグの修正やセキュリティとコンプライアンスの問題に対処するために多大な費用を費やすことになります。

最後に、ステークホルダーにテクニカルデットの削減やリファクタリングの価値を伝えるのに役立つメトリクスがあります。時間は1つです。コードの作成から生産まで、またはプルリクエストの開催からマージと生産までにかかる時間です。もう1つは平均修復時間（MTTR）です。この場合、バグまたはビルドの破損を発見し、チームがそれを修正するのにかかる時間を測定します。生産中のバグの数も追跡できます。バグの数が増加している場合、テクニカルデットに関連する問題が発生している可能性があります。

利子付きテクニカルデット

すべての組織は、テクニカルデットを削減するためにDXを改善するために、毎週数時間を費やすことができます。そうしない場合、後で支払うことになります。たとえば、パフォーマンスの低下、開発速度の低下、セキュリティの問題などです。たとえば、エンジニアや開発者のチームが、Ruby on Railsのアップグレードを10年間延期してきたとします。突然、プロジェクトのコストが50万ドル増加することになります。Rubyのバージョンが4世代古いため、古いコードと古い依存関係が大量に発生します。

段階的にアップグレードしていたら、この状況にはなっていません。したがって、ソフトウェア開発チームをサポートし、必要に応じて支払うようにしてください。そうしない場合、テクニカルデットは利子付きで戻ってきます。