DXとAIによる技術的負債の管理

規模の大小を問わず、すべての企業が技術的負債を懸念しています。 ガートナーの見積もり インフラシステムの約40%がこの問題を抱えている。マッキンゼーがCIOを対象に行った調査では、約XNUMX分のXNUMXが 20％を超えます 新製品予算の70%が技術的負債関連の問題の解決に充てられています。しかし、多くの人が考えているのとは反対に、これは単なるコーディングの問題ではなく、開発者エクスペリエンス（DX）の問題でもあります。開発者が不適切なアーキテクチャ、時代遅れのツール、そして不十分な開発ワークフローで作業しなければならない場合、生産性、パフォーマンス、そして士気は低下するからです。

開発者を念頭に置き、彼らの仕事への取り組み方、使用するツール、そしてキャリアアップの可能性に焦点を当てて技術的負債の優先順位付けを行うことで、チームは集中力を高め、より迅速にリリースすることができます。DXとAIを活用したツールへの注目の高まりを背景に、企業が技術的負債を管理する方法が変化しつつあるのは、まさにこのためです。

DXを推進する

開発者のオンボーディング方法には、多くの場合、改善の余地が大いにあります。プロジェクトへの貢献を開始するまでに数週間かかることもあります。ようやく小さな機能やパッチを追加できるようになったと思ったら、それまで取り組んできた変更とは全く関係のない理由で継続的インテグレーション（CI）サービスが失敗するという事態も珍しくありません。これは基本的に、テストスイートの品質問題が原因で失敗しているのに、開発者はテストスイートを壊すような変更を提出していないという状況です。これは、90%の確率でしか機能しない、不安定で質の低いテストです。既存のチームはおそらくこれで問題ないでしょう。単にプロセスを遅らせるだけですから。しかし、ツールが時代遅れで、組織外の人にとっては士気を低下させる可能性があります。

これは、適切なDXを阻害する多くの要因の一つです。これを防ぐ一つの方法は、ソフトウェアエンジニアリングおよび開発チームに専任の推進者を置くことです。多くの小規模組織にはDXリーダーがいませんが、大規模で成功している組織にはいます。これらの専門家は、新しい開発者が環境を構築するのにどれくらいの時間がかかるかなどを記録しています。そして、2週間が長すぎる場合は、その時間を半分に短縮する方法を考え出します。

CircleCIのようなツールには、テストスイートの不安定さを追跡するネイティブ機能が搭載されており、役立ちます。必要なのは、各スプリントの後に主導権を握り、コードのメンテナンスと将来の作業を容易にする変更点に対処してくれる人です。つまり、DXの改善に関心を持つリーダーの存在が不可欠です。そのためには、シニアレベルのエンジニアに加え、潜在的なギャップについてフィードバックを提供できる比較的新しいスタッフを探すことが重要です。

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

指標と警告サイン

技術的負債がチームにどのような影響を与えているかを評価する際に、追跡できる指標は数多くあります。基本的な指標としては、「修正時間」や「機能追加時間」などが挙げられます。例えば、バグに気づき、その修正方法を知っているとします。一部のツールでは、コードの作成から本番環境への実装までの所要時間を追跡できます。例えば、非常に小さなパッチの修正とリリースに2営業日かかっているのに、チームとしては数時間で完了させる必要がある、といった状況を把握できます。また、バグ修正数と完了した機能数といった比率を追跡することも可能です。

士気の問題がチームのパフォーマンスに影響を与えているかどうかを特定する方法もあります。DXリーダーは四半期ごとにアンケートを実施し、開発者がプロ​​ジェクト全体、あるいはその一部にどれだけ満足して取り組んでいるかを把握することができます。CIプロセスなど、具体的な領域について掘り下げて質問することも可能です。また、チーム内の離職率や離職率の変化を常に追跡することも可能です。離職者が後を絶たない場合、彼らは自分の懸念が聞き入れられていないと感じている可能性があります。

AIを活用したツール

AIツールの台頭は、開発者やエンジニアの生産性向上と製品のリリーススピード向上につながるはずですが、技術的負債がそれを阻害しています。例えば、GitHubやCopilotなどのツールを使ってコード変更を行い、プルリクエストを送信したとします。CIからの返信が届くまで数時間かかるとします。その間、開発者は何か他の作業をしているでしょうか？メールをチェックしているでしょうか？これはコンテキストスイッチを頻繁に発生させ、生産性を著しく低下させます。

開発者は、コードに集中できる製品開発に取り組みたいと考えています。ツールは、開発を本番環境に導入するためのものであり、常に障害となるものではありません。AIは時間を節約できますが、許容できる複雑さの基準をエンジニアリングチームが独自に定義する必要があります。そのためには、まず、メインブランチに追加するコードが、許容できるレベルの技術的負債を抱えていることを確認してください。その前に、技術的負債とコード品質の許容可能な閾値について、オープンな議論を行い、エンジニアリングチームの同意を得てください。その閾値を超えた場合は、直ちに修正が必要であることを全員が理解していることを確認してください。これらの基準を定義したら、AIが活躍の場となります。

エンジニアがオーケストレーターとして機能し、AIエージェントを活用するケースもある。キャップジェミニが大企業の経営幹部1,100人を対象に行った調査では、 82%がAIエージェントの統合を計画 今後3年間で、すでに影響を与えています 仕事の未来バグレポートを見て、AIエージェントが開始からコードレビューまで処理できるほど小さいと判断すると、チームの時間を節約し、より複雑な作業に時間を割けるようになります。しかし、これらのツールに盲目的に従うと、AIが考慮しきれないトレードオフが生じることがあります。

その時、人間の意見が決定要因になります。

技術的負債と目標の整合

技術的負債の削減と、達成しようとしている目標や測定可能な成果をどのように整合させるのでしょうか？それは許容できる技術的負債の話に戻りますが、ビジネスにおいては、迅速に出荷しなければならない場合もあります。製品がスケールしないことや、時間の経過とともにパフォーマンスの問題が発生する可能性があることを承知の上で、迅速に出荷できる場合もあります。多くの場合、開発者はこれらの問題に対処する時間が取れる時に後で戻ってくるようにメモを取りますが、実際にはそうすることは稀です。そして、常に明日出荷しなければならないという悪しき文化が蔓延すると、負債の影響は明白になります。

これはスタートアップ企業であれば理解できるかもしれませんが、10年も経営してきた企業では無理があります。技術的負債を管理するには、早い段階から積極的に企業文化の変革に取り組む必要があります。さもなければ、本番環境のバグ修正やセキュリティやコンプライアンスの懸念に多額の費用を費やすことになります。

最後に、リファクタリングや技術的負債の削減の価値をステークホルダーに伝えるのに役立つ指標があります。例えば、開始から本番環境への投入までの時間、プルリクエストの発行からマージ、そして本番環境への出荷までの時間などが挙げられます。また、平均修復時間（MTTR）も指標の一つです。この場合、バグやビルドの不具合を発見し、チームがそれを修正するのにかかった時間を測定します。本番環境におけるバグの数を追跡することもできます。その数が増えている場合は、技術的負債に関連する問題がある可能性があります。

利子付きの技術的負債

どの組織でも、毎週数時間をDXの改善に費やし、技術的負債の削減につなげることができます。そうしなければ、パフォーマンスの低下、開発速度の大幅な低下、セキュリティ問題など、後々そのツケを払うことになるかもしれません。例えば、エンジニアと開発者チームがRuby on Railsへのアップグレードを10年も延期していたとします。ところが、Rubyのバージョンが4世代も古いため、突然プロジェクトコストが50万ドルも増加し、大量のコードと時代遅れの依存関係が残ってしまうのです。

段階的にアップグレードしていれば、このような状況にはならなかったでしょう。ですから、ソフトウェア開発チームをサポートし、従量制で支払いましょう。そうしないと、技術的負債が利息を伴って再びあなたを苦しめることになります。