【入門】 技術的負債について
はじめに
『技術的負債』はソフトウェア開発をする上で必ず向き合わなければならない課題のひとつです。今回は、この技術的負債の種類や、良くある問題など基本的な内容を紹介します。
エンジニア以外の役職の方も含め、今まで曖昧に覚えていた人、よくわからないと思っていた人は、ぜひ読んで参考にしていただければと思います。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
技術的負債とは
技術的負債とは、ソフトウェア開発において、過去に行なった技術的な作業が原因で、機能追加や改修を含めた継続的な開発作業が低下してしまうことを指します。
例えば、ある機能の改修作業において、「似た機能の改修が3人日程度の作業だったのにも関わらず、技術的負債が原因で2週間掛かってしまうと」いった事象や「古いツールのバージョンアップ作業に1週間かかる」といった作業がそれに当たります。このように技術的負債を抱えていると開発のどこかで問題が顕在化しか開発作業がストップしたり遅延する原因となります。
またそれとは別に、技術的負債によりチーム内のマネジメントで問題が発生することもあります。技術的負債の存在はエンジニア以外の職域からは理解するのが難しく、チームとしての共通認識がとれないことが主な原因のひとつです。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
技術的負債の種類
技術的負債にはいくつかの種類があり、全ての負債をすぐに返済しなければいけないということではありません。時には開発を効率良く進めるために、あえて戦略的な負債を受け入れることもあります。ここでは技術的負債の種類について紹介します。
■ 意図的な負債
戦略的な理由により意図的に受け入れた技術的負債です。これらの負債はエンジニアが存在を把握しているため、ある程度計画的に返済をコントロールすることが可能です。
(例)
・使い捨てられることが予めわかっているため、実装速度を優先してプログラムを書く
・初期のプロダクトのメンテナンス性を優先し、あえてスケール性が低いシンプルな構成で設計する
■ 意図しない負債
いいかげんな設計や実装、テストが無いなど、不慮のエラーを発生させるリスクを抱えている技術的負債です。このような負債はいつ顕在化するかわからず、突発的に重大なエラーを引き起こす可能性があります。
(例)
・コーディングルールを設定しない
・ソフトウェアテストを作成しない
・複雑な仕様のシステムの説明ドキュメントを書かない
■ 時間経過における負債
レガシィな環境や、バージョンが古くなったコードなど、時間経過により定期的に発生する技術的負債です。これらの負債はソフトウェア運用では必ず発生し、時間が経つほど問題の影響が大きくなる傾向があります。
(例)
・プログラム言語のバージョンが古い
・データベースのバージョンが古い
・昔のシステムのコードを引き継いでいる
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
技術的負債がチームに起こす問題
技術的負債は開発の進捗に影響を及ぼす可能性があるため、計画的に返済する必要があります。しかし、技術的負債が実際に問題として顕在化するまで対処できないこともたびたび発生します。
技術的な負債が返済できない理由として、負債自体ではなくチームの問題であることがあります。例えば次のようなチームは問題が発生しやすい傾向にあります。
・プロダクトの責任者とエンジニアで技術的負債について共通理解が取られていない
・プロダクトの責任者が、技術的負債の返済作業と新規の開発作業の優先度を判断できていない
こららの原因は「プロダクト責任者の知識不足」「エンジニアの説明不足」にありますが、根本的にはチーム全体の認識不足とも言えます。
プロダクト責任者は、技術的負債を返済しないことで発生するリスクを正しく理解する必要があり、同様にエンジニアもそれをプロダクト責任者を含むチーム全体に適切に説明する義務があります。負債の返済を計画的に進めるために、チーム全体で技術的負債と適切に向き合う体制づくりが必要です。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
初期のプロダクト開発で発生しがちな技術的負債の例
ここでは、はじめてプロダクトを開発するチームで起こりがちな技術的負債の例を紹介します。
■ 予算が無いため、安価な金額でエンジニアを雇用する
エンジニアの報酬が安価であることが直接的な原因とは限りませんが、フルタイムではなく掛け持ちで開発を行なったり、経験の浅いエンジニアを採用することは、技術的負債を発生させるリスクがあります。
フルタイムでエンジニアが雇用できない状況では、プロダクト責任者が積極的にコミュニケーションをとり、技術的負債の存在を把握しにいく必要があります。
技術選定やアーキテクチャなどの専門的な内容は、スポットで技術的な顧問を外部に依頼することでもこの問題を回避できる可能性があります。
■ リリース速度を優先して、メンテナンス性が低い実装を許容する
「テストコードを書かない」「必要最低限のドキュメントを書かない」など、リリース速度を重視しして最低限のメンテナンス性を捨ててしまうと後々大きな問題に繋がることがあります。
特にスピード感が求められるスタートアップ企業などでは、このような負債が良く発生します。このような負債は、サービスが大きくなり負債の影響が大きくなりすぎる前にどこかで返済する必要があります。
■ スケールをしにくいアーキテクチャで開発する
初期のユーザー数や開発スピードを優先し、スケールしにくいシンプルなシステムアーキテクチャで開発を進めることがあります。このような負債は、意図して選択するのであれば戦略的で意図した技術的負債といえます。
将来のユーザー増加を見据えて計画的に負債を返済できれば、問題を顕在化せずに負債を返済することも可能です。
一方このような負債では、エンジニアが「意図的な負債」であることをプロダクト責任者に上手く伝えられないという問題が起こりがちです。これによりプロダクト責任者がスケールできない構成に不安を感じてしまうことがあります。
計画的な負債を抱える時は、その返済計画を含めてエンジニアとプロダクト責任者で意思疎通を行なうことが重要です。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
技術的負債が顕在化した時によく起こる問題
技術的負債の影響が顕在化した時の対応で発生する問題について紹介します。もし技術的負債で問題が発生したした時に、次のような事態が起きないように事前に対策しておくとよいでしょう。
■ 負債の原因を知る人間がチームにいない
意図しない技術的負債の多くは開発初期に発生し、長い時間を経過した後に顕在化します。このとき問題の原因や経緯を知っている人間がすでにチームにいないということは良く起こります。
対策のひとつとして、チーム離脱時に負債の洗い出しや負債の共有を行い、技術的負債を引き継げる体制を作っておくことが考えられます。
■ プロダクト責任者が返済作業を許容できない
技術的負債の内容は、エンジニア以外は正しく理解することが難しく、プロダクト責任者は、突発的に発生する技術的負債の影響と既存の開発作業とのトレードオフを受け入れられないことがあります。その結果、プロダクト責任者が直近の機能開発を優先してしまい、負債の返済作業は後回しになります。
突発的な問題が発生した時は、問題の影響範囲についてエンジニアが適切に説明することが必要です。また、普段から技術的負債についてチームで共通認識を持つように仕組み化することが予防策となります。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
技術的負債との向き合い方
■ 意図しない技術的負債は、発生しないように務める
品質の低いプログラムコードや設計によって発生する「意図しない技術的負債」は、事前に防止することが可能です。テストコードやドキュメントを書く時間もタスクに含めるなど、なるべくこの負債が発生しないように努力すべきです。
■ 意図した技術的負債は、計画も含めてチームで共有する
たとえ意図した技術的負債であっても、チーム全体で共有することが重要です。どのようなシチュエーションになったら返済が必要になるかを事前に共有しておくことで、チームの不安やコミュニケーションの齟齬を防止することができます。
意図した技術的負債の返済時期が来るということは、プロダクトが順調に成長しているということでもあるため前向きに捉えるとよいでしょう。
■ 技術的負債は、少しずつ返済する
顕在化した負債も含めて、技術的負債は日常的に少しずつ返済していくことが重要です。たとえ今は影響が小さかったとしても、存在する技術的負債は連鎖的に他の技術的負債を生み出すリスクを持っています。通常の開発作業と並行して返済作業を一定の割合で組み込むなど計画的に返済を行いましょう。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
まとめ
読んでいただきありがとうございます。
技術的負債の基本的な内容について紹介しました。
この記事を通して、技術的負債の理解が少しでも深まれば幸いです。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
アンケートのお願い
このチャンネルでは、これから提供していくコンテンツやサポートの内容を改善していくために、アンケートをお願いしています。
ぜひアンケートにご協力ください。
この記事が気に入ったらサポートをしてみませんか？