DXとAIを使用したテクニカルデットの管理

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

開発者の視点を優先してテクニカルデットを管理し、開発者の仕事のやり方、使用するツール、キャリアアップの機会に焦点を当てると、チームは集中してより迅速に製品を出荷できます。これが、企業がテクニカルデットを管理する方法が、DXとAIパワードのツールへの重点の増加によって変化している理由です。

DXの推進

開発者のオンボーディング方法は、多くの場合、改善の余地があります。誰かがプロジェクトに貢献し始めるまでに、数週間かかる場合があります。ついに小さな機能やパッチを追加できたとき、CIサービスが変更とは無関係な理由で失敗することは珍しくありません。これは、テストスイートが低品質の問題で失敗することであり、開発者はテストスイートを壊す変更を提出しませんでした。これは、90%の時間だけ動作するフラッキーで、悪く書かれたテストです。既存のチームはおそらくこれに慣れていますが、プロセスが遅くなるだけですが、組織外の誰かにとってはツールは古くて деморализирующий です。

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

CircleCIのようなツールは、テストスイートのフラッキネスを追跡するネイティブ機能を備えています。必要なのは、スプリントの後に停止して、コードを将来より簡単に維持および作業できるようにする変更に取り組むリーダーです。これは、DXを改善したいリーダーがいることにかかっています。これが起こるようにするには、シニアレベルのエンジニアと、潜在的なギャップに関するフィードバックを提供できる比較的新しいスタッフメンバーを探します。

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

メトリクスと警告サイン

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

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

AIを使用したツール

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

開発者は、コードに集中できる製品で作業したいと考えています。ツールは、製品を生産に移すのを助けるものであり、常に障害になるものではありません。AIは時間を節約できますが、エンジニアリングチームが受け入れられる複雑さの基準を定義することは、エンジニアリングチームの責任です。これを行うには、まず、メインブランチに追加されるコードが受け入れられるレベルのテクニカルデットを持っていることを確認します。その前に、エンジニアリングチームとテクニカルデットとコード品質の受け入れ可能なしきい値について公開で議論し、合意を得ます。誰もが、そのマークを超えることはすぐに修復する必要があることを理解していることを確認します。基準を定義したら、AIが活用されます。

エンジニアがオーケストレーターとして機能するAIエージェントの場合があります。Capgeminiが1,100人の大企業の幹部に対して実施した調査によると、82% が、3年以内にAIエージェントを統合する予定です。さらに、これは 仕事の未来 に既に影響を与えています。バグレポートを見て、AIエージェントがコードレビューから始めて処理できる小さなものであることがわかります。これにより、チームの時間が節約され、より複雑な作業に注力できるようになります。しかし、時にはこれらのツールに盲目的に従うと、AIが考慮することが難しいトレードオフが発生します。

そこで、人間の判断が決定的な要因となります。

テクニカルデットを目標と整列させる

テクニカルデットの削減を、達成しようとしている目標や測定可能な成果と整列させる方法は何ですか？受け入れられるテクニカルデットに戻ります。時には、ビジネスでは迅速に出荷する必要があります。製品がスケールしないことや、将来的にパフォーマンスの問題が発生することを知りながらも、出荷できます。開発者は、後にこれらの問題に対処する時間ができたときに戻ってくることをメモしますが、実際に戻ることはほとんどありません。悪い文化が優勢になると、常に明日出荷しなければならない状況になり、テクニカルデットの影響が明らかになります。

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

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

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

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

段階的にアップグレードしていたら、この状況にはなっていません。したがって、ソフトウェア開発チームをサポートし、途中で支払います。そうしないと、テクニカルデットが利子とともに戻ってきます。