Technology部の菊池です。
システム開発において、本来は時間をかけるべき工程でその場しのぎの解決策を取ってしまった場合、将来的に追加で改修作業を行う可能性が発生します。これは負債の支払いになぞらえて、技術的負債（Technical debt）と呼ばれています。
今回は技術的負債が引き起こす問題や、陥った場合の対策、予防方法について解説します。
技術的負債とは
技術的負債は、品質、保守性、拡張性などが十分に検討されないまま作業を進めてしまうことで発生します。
たとえば機能を実装するスピードを優先するために、品質や保守性に配慮せずにコードを書いてしまった場合、そのコードが将来的に問題を引き起こすかもしれません。このような場合、将来的に改善が必要となり、負債として返済する必要があります。
技術的負債が発生すると、システムの品質や保守性が低下し、最悪の場合は修正や追加開発が不可能になるリスクも否めません。したがって、技術的負債が発生しないようにコントロールすることが重要です。
発生原因
技術的負債が発生する原因は一概には言えないものの、以下のようなケースが考えられます。
- 対応遅れ並びに先送り
- 組織文化
- チームのスキル不足
開発がスケジュール通り進まず納期が短い場合は、リリースが最優先となってしまいます。こうした状況ではレビューやリファクタリングなどの時間が割けなくなり、負債が蓄積する原因となります。
品質保証が組織の文化として浸透していない場合も原因として考えられます。結果として技術的負債を防ぐ対応が不足し、負債が蓄積されることを認識できていないケースもあります。
また、負債を解消するための予算やリソースを確保できずに、結果的に技術的負債が蓄積される場合もあるでしょう。
開発チームが必要なスキルを持っていないと、不適切なコーディング方法や設計パターンの選択によりコードの品質が低下します。結果的に技術的負債を蓄積する結果となるでしょう。
技術的負債によって起こりうる問題
生産性の低下
技術的負債によりコードが複雑化すると、メンテナンス性が低下します。
開発者がコードの理解に時間を費やす必要があるため、新しい機能の開発や修正に費やす時間が確保できません。結果、さらに生産性が下がってしまうような負のループに陥ってしまいます。
品質の低下
技術的負債によりコード品質が低下すると、バグやセキュリティの脆弱性が生じる可能性が高くなります。システムの信頼性にも影響を及ぼすため、細心の注意が必要です。
開発コストの増加
技術的負債がかさむとメンテナンス性が低くなり、各種修正に対して、レビューやテストなど必要以上に工数が発生してしまいます。
また技術的負債を解消するため、リファクタリングなどの工数も必要となる場合も。結果的に開発コストが膨らむ可能性があります。
リリース遅延
上記のような事態が積み重なると、生産性の低下、品質の低下により思うように開発が進みません。当初の期日までにリリースが間に合わなくなる可能性も考えられます。
技術的負債の具体例と予防・改善策
具体例
では、具体的に技術的負債とはどういったものが当てはまるのか。例をいくつかピックアップしましたので、以下のようなことに当てはまっていないかをチェックしてみてください。
- コード品質観点
-
- ソースコード自体がスパゲッティコードとなっている
- クラス名や変数名など適切な命名規則やコメントが不適切で可読性が低い
- 低凝集、高結合なコード
- モジュール間の結合度が高くリファクタリングが困難な状況になっている
- 運用観点
-
- DevOpsないしDevSecOps化されておらず、デプロイやコードチェック処理など各種プロセスが自動化されていない
- 結果的に各担当の作業工数の増加と作業品質が低下している
- アーキテクチャ観点
-
- 選定している技術が古くなっており、新しいOSやフレームワーク、ライブラリに対して対応できなくなっている
- 結果的にシステムのパフォーマンスが低下し、機能追加や修正のための工数が増加
- その他
-
- 各種資料やルールが文書化されていない（文書になっている場合も記述が曖昧）
- 各種ソースコードのコミット内容の不備、各種議論した内容がどこにも残っていない
- その結果として確認やミーティングのための工数が増加
予防・改善策
このような技術的負債を抱えないためには、以下のような取り組みを徹底することが重要です。
クリーンコードを実現する
開発プロジェクトの生産性を高めるうえでは、可読性、メンテンス性、拡張性の3つが揃った「クリーンコード」を実現することが重要です。詳しくは下記の記事で解説していますので、ぜひご覧ください。
高凝集・低結合な「クリーンコード」を実現するためにやるべきこと
また、ソースコードの可読性とメンテナンス性の向上にもつながるためリファクタリングを実施することも有用といえます。
テストカバレッジの向上
テストカバレッジを向上させることは、バグの発生防止につながります。特にオフショア開発の場合、品質担保は重要な課題です。
そのためにもテストに着目とした開発手法であるテスト駆動開発 （TDD）というものがあります。詳しくは下記の記事で解説していますのでご参考になさってください。
テスト駆動開発 (TDD)を使ったオフショア適用方法について解説
CI/CDの導入
CI（継続的インテグレーション）/CD（継続的デリバリー）とは、アプリケーション開発のステージに自動化を取り入れて、顧客にアプリケーションを提供する頻度を高める手法です。
自動化テストツールや自動ビルドツール、静的コード解析ツールを導入することで、開発効率の向上や品質向上を期待できるでしょう。CI/CDツールや静的コード解析ツールについては以下の記事で詳しく解説しています。
CI/CDとは何かを解説！具体的な各ツールの詳細な比較も
静的解析で設定しておきたいルールを解説
アーキテクチャの見直し
将来的に負債が発生する可能性を予防するために、古くなったアーキテクチャを刷新することも検討しましょう。アーキテクチャを見直すことで、システムの拡張性、保守性、パフォーマンスを担保し、長期的なメンテナンスや追加開発ができるようになります。
各種資料の文書化
設計書資料や開発ルールを文書化すれば、プロジェクトの透明性が高まり、新しいチームメンバーが迅速にプロジェクトに参加できるようなります。結果として確認やミーティング工数削減につながり、開発効率を高められるでしょう。
トレーニングの実施
上記のように自動化ツールや文書を活用するだけでなく、必要に応じて未熟なメンバーのトレーニングも実施しましょう。たとえばツールによる機械的なチェックだけでは確認できない部分に対するコードレビューを実施することも重要です。
さいごに
今回は技術的負債の原因や予防・改善策を紹介しました。
実際のプロジェクトで技術的負債が起こり得ないようにするためには、プロジェクト開始前段階でしっかりと準備することが望ましいです。
ただ現実問題として、システムやOS、ライブラリ、開発リポジトリのアップデートが逐次行われています。当初導入していた施策などがレガシーとなったり、複数の要因で開発がうまくできなくなったりするケースも十分ありえます。
技術的負債は一度対策を行ったら終了というわけではなく、継続的に繰り返し見直しとチェックを行い、何か問題が見つかったとしても常に手戻りできるようにしておく準備が必要です。
そのため技術的な負債の解消は、個人だけでなくチームとしての課題として常に念頭におきながらチェックし続けるようなマネジメントを心がけましょう。
