技術的負債の優先順位について論文を読んでみた

はじめに

POLプロダクト Advent Calendar 2020の8日目のバトンを受け取りましたので、技術的負債の優先度について考えてみます。

技術的負債の認識とその対策が非常に重要であることは、エンジニア以外の方々にとっても、認識されつつあると思います。
技術的負債と呼ばれるものは非常に多岐に渡り、どのような会社においても大量に存在するでしょう。
私自身もエンジニアとして大量の技術的負債を作ってきた自覚があり、またどなたかの技術的負債に向き合ってきた経験があります。

しかしながら、ではどの負債から返すべきなのかということは、私の中にも確固たるロジックがありませんでした。
今回はこの問題を掘り下げるべく、ある文献レビュー論文を追いかけ、その中で紹介されていたわかりやすい方法を紹介します。

技術負債とはなにか？

技術的負債はWard Cunninghamさんが1992年に国際カンファレンスで発表した “The WyCash Portfolio Management System.”にてはじめて負債というメタファーを生み出しました。
その後多くの方がこのメタファーについて議論を行いました。
Albarakさんは「技術的負債のメタファーは、システムを開発、維持、進化させる際に、不良、不適切、または最適ではない慣行から生じる問題」と表現し、Codabuxさんは「一時的な回避策がもたらす悲惨な結果」と表現し、後ほど紹介するZazworkaさんは「借金のように何らかの行為をスキップした結果が、短期的にどのように回収されるかを説明するメタファー」としています。

メタファーゆえちょっと難しいところもありますが、本当は丁寧に考えて作らねばならないのに、時間的な制約などでえいやで物を作り、後で痛い目にあった経験は皆様にあるのではないでしょうか。

もう少し具体で言いますと、「第3正規化以下はすべて技術的負債である」（Albarak 2018）と言う定義や、「技術的負債を語るには技術的理想を整理しそれ以外が負債である。例えばすべてのコードにおけるユニットテストのカバレッジが70%以上であることだ」（Letouzey 2012）等、様々な議論があります。

Alfayezさんの文献レビュー論文

技術的負債が何であるかということがわかりました。ではそれを適切に返済したい。それはどのように行うべきかということもまた活発に議論されていました。
今回は私も勉強のためAlfayezさんの“A Systematic Literature Review of Technical Debt Prioritization.”と言う論文に目を通してみます。

この論文では技術的負債の問題をEvans Data Corp、CIA Factbook、および Stripe の共同調査レポートより引用し、「開発者が "悪いコード” に費やす時間により、世界中で年間850億ドルの機会費用が失われていると推定されました。さらに報告書では、平均的な開発者が週に13.5時間も技術的負債の返済に費やしていることも判明しています。」としています。

そして技術的負債と呼ばれるものをすべて返済すればよいのかというと、多くの場合リソースは有限です。このため、その選択肢が有効であることは少ないので、どのようにして優先順位を付けていけばよいのかについて、Alfayezさんは24の論文に対して文献レビュー論文を投稿しました。

それによると優先順位の方法論として「Value」29.17%、「Value and cost」54.17%、「Value, cost, and constraint」16.67%、と言う大きなカテゴリがあることを示しています。また技術的負債の優先順位付けにおいて必要な要素として、「ソースコード」「コードリポジトリ」「リリースデータ」「設計図」などが多く使われていることを明らかにしています。同時にこれらの優先順位付けのアプローチが、フィジビリティスタディまで行われているものは24論文中1例しかなかったとしています。結論に置いても、色々な方法論が論じられているけど、実際に検証されたものがないよねというのが語られています。

私も、レビューされている24の論文を読んでみたのですが、多くの論文が正直なところちょっと現場で使うには手間な手法が多く紹介されていました。

ランキングによる2軸評価

Zazworkaさんは、ランキングによる2軸評価を提案しており、これは現場で使えるかもと思い紹介します。

技術的負債の特定

Zazworkaは技術的負債の定義として、Object-Oriented Metrics in Practice で紹介された3つのソフトウェアメトリクスから、良くないクラス（=God class）を特定することを採用しています。私は使ったことがないのですが、PMDを使う方はよく見るかも知れません。

God Classは以下をすべて満たすものとして定義されています。

• ATFD > 5
• WMC > 46
• TCC > 0.33

ATFD： あるクラスが直接またはアクセサ・メソッドを介して属性にアクセスする外部クラスの数
WMC： クラスで宣言されたすべてのメソッドの複雑度の合計
TCC: メソッドの凝集度

リファクタリングにかかる工数の調査

またこれによって、治す際にどのぐらいの「努力（リファクタリングにかかる工数）」が必要なのかを明らかにするため、ランキングを行います。

| God Class Name | WMC | TCC | ATFD | Overall Score | Ranking |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| GC1 | 49(3) | 0.0(8) | 20(6) | 17 | 6 |
| GC2 | 87(8) | 0.005(7) | 28(7) | 22 | 7 |
| ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ |
| GC8 | 48(2) | 0.199(2) | 7(1) | 5 | 2 |
| GC9 | 61(6) | 0.192(3) | 19(4) | 13 | 4 |
()内はランキング。 Table 1: Refactoring effort ranking based on detection strategy metricsをベースに筆者編集

影響範囲の調査

次にリストアップされたクラスについて、一定の期間内にクラスの変更を必要としたバグの数をカウントします。

| God Class Name | 変化尤度 | 欠陥可能性 | Overall Score | Ranking |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| GC1 | 0.016(1) | 0.0(1) | 2 | 1 |
| GC2 | 0.097(8) | 0.0(1) | 9 | 4 |
| ・・・ | ・・・ | ・・・ | ・・・ | ・・・ | ・・・ |
| GC8 | 0.052(6) | 0.133(7) | 13 | 7 |
| GC9 | 0.027(2) | 0.0(1) | 3 | 2 |
()内はランキング。 Table 2: Software quality characteristic ranking based on change and defect likelihoodをベースに筆者編集

総合的なランキング

これとソフトウェアメトリクスから導き出される欠陥可能性を、個別にランク付けし、合計し、総合ランキングを用意します。「品質への影響」と「リファクタリングにかかる工数」の2軸でプロットを行い、「品質への影響」が大きく「リファクタリングにかかる工数」が少ないものから順番に対応すべきてあると論じています。ですので、「品質への影響」のランクから「リファクタリングにかかる工数」のランクを引いたものが総合的なスコアになります。

God Class Name	Effort Rank	Impact Rank	Overall Score
GC7	1	6	5
GC8	2	7	5
・・・	・・・	・・・	・・・
GC9	4	2	-5
GC1	6	1	-5
()内はランキング。 Table 4: Total Ranking をベースに筆者編集

この場合GC7と8から着手すべきということです。

おわりに

技術的負債は難しいですね。上記はソースコードの世界について主に論じていました。しかし技術的負債がこのスコープで良いのか？あるいは、技術的負債を生む社会的負債と言うものがあるのではないかと、議論はどんどん深くなっていくのだろうなと想像します。

さて、私は何を思ったのか、2020年度よりJAISTの社会人学生をはじめました。それゆえ、普段はお断りしているこういうブログ投稿もご縁を感じて、特別にちょっと頑張ってみました。
実際のところ、今までの私の人生は論文を書くどころか読むこともサボってきました。今回良いきっかけとして色々な論文に向き合い、非常に不慣れな英語を何とかする機会をいただきました。このためあちこちに間違いがある内容になっているかもです。「ぜんぜん違うじゃん」などあるとおもいます、ぜひご指摘ください。

社会人学生をはじめてみて強く思うことは、アカデミックのDXが非常に遅れていることと、アカデミック出身者の評価ギャップです。論文一つをとってもあちこちに散乱し探すのに本当に苦労しますし、それの管理も多くは未だにローカルのツールです（paperpileいいですね！）。博士課程に進んだ人が就職に困るなどという話もよく聞く話です。こういうのは非常に良くないなと私も考えておるなかで、そういう問題解決に頑張っている会社さんがあるそうです。

POLさんと言うそうです。みなさま、ポチッとクリックしてみると良いかも知れません！ 中途採用ページ

次はPOLのUI/UXデザイナーである banyanfree さんです。ご期待ください！

Reference

Albarak, M., and R. Bahsoon. 2018. “Prioritizing Technical Debt in Database Normalization Using Portfolio Theory and Data Quality Metrics.” Of the 2018 International Conference on …. https://dl.acm.org/doi/abs/10.1145/3194164.3194170?casa_token=ZXYKovAoae8AAAAA:a4wONLhnKmwfeKKXopololWMfE321blgTlBj7bn6EDcCO2xiS03qZAm1sx1DfrSMhZE_DIdUJIxs0A.

Alfayez, Reem, Wesam Alwehaibi, Robert Winn, Elaine Venson, and Barry Boehm. 2020. “A Systematic Literature Review of Technical Debt Prioritization.” In Proceedings of the 3rd International Conference on Technical Debt, 1–10. TechDebt ’20. New York, NY, USA: Association for Computing Machinery.

Codabux, Z., and B. J. Williams. 2016. “Technical Debt Prioritization Using Predictive Analytics.” In 2016 IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C), 704–6. ieeexplore.ieee.org.

Cunningham, Ward. 1992. “The WyCash Portfolio Management System.” SIGPLAN OOPS Mess. 4 (2): 29–30.

Letouzey, J., and M. Ilkiewicz. 2012. “Managing Technical Debt with the SQALE Method.” IEEE Software 29 (6): 44–51.

Zazworka, Nico, Carolyn Seaman, and Forrest Shull. 2011. “Prioritizing Design Debt Investment Opportunities.” In Proceedings of the 2nd Workshop on Managing Technical Debt, 39–42. MTD ’11. New York, NY, USA: Association for Computing Machinery.