技術的負債の解決案について
こんばんは、小谷田です。今日は『技術的負債の解決案について』というお話です。
技術的負債って？
開発をされていない方には耳慣れない言葉かと思います。Wikipediaには下記とあります。
ソフトウェア開発における概念であり、時間がかかるより良いアプローチを使用する代わりに、今すぐ簡単な（限定的な）解決策を選択することで生じる追加の手直しの暗黙のコストを反映したものである。
今のコストを下げる方針を取った結果、未来にコストが発生してしまう状態、と言い換えられるかと思います。
未来の不必要なコスト(時間)は避けるべきです。その時間を他のそれこそ未来のためになるような案件に向けるべきだからです。
特に日本は少子化が進んでいます。そんな中余計なことにばかり時間を使ってしまうと生産力が落ちて死活問題にもなりかねません。繰り返しますが未来の不必要なコストは避けるべきです。
技術的負債の原因
同じくWikipediaに下記とあります。※頭の番号は私が振ったものです。
①継続的な開発：時間をかけてプロジェクトを強化していくと、古いソリューションは最適ではなくなる。
②不十分な先行定義：開発中に要件がまだ定義されていない場合、設計が行われる前に開発が開始される。これは時間を節約するために行われるが、後になって手直しをしなければならないことがよくある。
③ビジネス上のプレッシャー：必要な変更が完了する前に、ビジネスが何かをすぐにリリースすることを検討する場合、未完了の変更からなる技術的負債が蓄積される[6][7]。
④プロセスや理解の欠如。企業が技術的負債の概念に気付かず、その影響を考慮せずに意思決定を行う。
⑤緊密に結合されたコンポーネント。機能がモジュール化されていないため、ソフトウェアはビジネスニーズの変化に対応できるだけの柔軟性を持たない。
⑥テストスイートがないため、迅速でリスクの高い応急的なバグ修正が行われる。
⑦文書化の欠如：コードが文書化されずに作成されている。ドキュメントを作成するための作業は負債となる[6]。
⑧コラボレーションの欠如：知識が組織内で共有されず、ビジネスの効率が低下したり、若手開発者が適切に指導されない。
⑨複数のブランチで並行して開発を行うと、変更点を1つのソースベースにマージする作業が必要になるため、技術的負債が発生する。分離して行われた変更が多ければ多いほど、負債は大きくなる。
⑩リファクタリングの遅延：プロジェクトの要件が進化するにつれ、コードの一部が非効率的になったり、編集が困難になったりすることが明らかになり、将来の要件をサポートするためにリファクタリングが必要になることがある。リファクタリングが遅れれば遅れるほど、また、コードが追加されればされるほど、負債は大きくなる[7]。
⑪スタンダードとの整合性の欠如。業界標準の機能、フレームワーク、技術が無視されている。最終的にはスタンダードとの統合が行われ、それを早く行うことでコストを削減することができる（「リファクタリングの遅延」と同様）[6]。
⑫知識の欠如：開発者がエレガントなコードの書き方を知らない場合[7]。
⑬オーナーシップの欠如：ソフトウェアの外注化により、社内のエンジニアリングが外注コードのリファクタリングやリライトを要求される場合。
⑭技術的なリーダーシップの欠如：十分に考えられていない命令が指揮系統の下に伝えられること。
⑮直前の仕様変更。このような変更は、プロジェクト全体に浸透する可能性があるが、文書化してチェックするための時間や予算がない。
開発に関わる者として耳が痛くなることばかりです😓ただ私の経験から言うと、上記は開発をしていると起こりうる話でもあると思います。100％回避するというのは難しいのではと思います。
なので技術的負債は『起こさないもの』ではなく、『できる限り起こさないようにするべきだが、起こりうること』という方がしっくりきます。
技術的負債の解決案
ここで本題の解決案についてです。私は下記の前提プラス2点だと思います。
前提：基本的に技術的負債を発生させないよう最大限取り組む。しかしベストを尽くしても発生してしまった時は、、、
開発中、保守中に関わらず技術的負債に気づいたらチケットに起こすなりして見える化する
常に技術的負債に取り組む工数を確保し取り組む
1はそもそも技術的負債に気付けないという場合もあると思いますがそれは置いておいて、例えば上記原因で言う③はPdMの立場からすると起こりやすいと思います。
案件はビジネス的観点でリリース時期を決めて取り組むことが多く、その中で「これは直したほうがより良い状態になる」という事象が発生する、または発見することは多々あります。
べき論で言うと直した方が良いに決まっています。ただし、それらを全て対応するとリリースが遅れてしまうとなった場合、ケースバイケースではありますが、リリースによるユーザーさんへの価値提供・ビジネスインパクトと、未来の負債を比べ『これは対応しなくてもユーザーさんに影響はなく、リリースによる価値提供、ビジネスインパクトが大きい』という場合、その事象の対応は一旦置いておくという判断をすることがあります。やはり価値提供はしたい。
そうした時に、それを見える化しておかないと後で対応できなくなります。私の場合はチケットに起こしてバックログ(開発する候補の案件)に残します。原因③以外の事象も気づいた時に見える化するべきです。ここの見える化を行えるかがポイントです。
2については1のところで見える化した技術的負債を認識して常に取り組む工数(時間)を確保して取り組むようにする、と言うことです。
技術的負債はできる限り避けるけれども起こりうる、なので常にそれを想定して取り組みましょうねと言うことです。
バックログがあれば対応できます。対応を想定して目標に入れたり、工数を予め確保して取り組めば負債を減らしていけます。また、意外と案件と案件の隙間はあったりするので、その時間を技術的負債に充てるということはできると思います。
この前提プラス2を続けていけば、技術的負債を減らしていけるのではと思います。
さらに重要なこと
上記を実践できる『仕組み』が必要だと思います。マンパワーでは限界があるので組織的に自然と取り組むようになる仕組みが必要です。
その仕組みをいかにして構築できるかがポイントだと思います。ここをどうやるかが腕の見せ所です。私も頑張ります。
以上『技術的負債の解決案について』でした。