技術的負債を何かに例えてみる
どうも、テトリスでは棒がストレスなIwaoです。
ITエンジニア歴ももうすぐ20年になり、これまでに多くのソフトウェアを設計・開発してきました。しかしながら、非エンジニアに技術的負債を説明するコミュニケーションコストはなかなか減りません。それが仕事の一部ではありますが笑
なので今回はわかりやすく技術的負債の言葉の意味を説明するために、僕がよく使うたとえ話を整理してみました。そして最後に製品開発に気づきがあったので、その辺に興味があるかた向けのnoteになります。
技術的負債（英: Technical debt）とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。
では行きましょう！
テトリスに似ている説
テトリスに例えたこの記事がバズってたのは記憶に新しいです。急いで作ったソフトウェアは超高速で落ちてくるブロックを積み上げて、強引に作ったソフトウェアは回転せずにブロックを積み上げてる感があります。
余裕がない状態でゲームが進んでいくとゲームオーバーまっしぐらですよね。ぐちゃぐちゃのまま時間だけが過ぎてしまうと優秀なエンジニアを投入しても運ゲーになることが懸念されます。
いかに長くゲームを続けられるかは、いかに長く製品を存続できるかというプロダクトマネージャーの目的に合致します。PdMは製品の状態を理解して、1段消しか4段消しを狙うのか、どのくらいのスピードでブロックが落ちてくるのか把握してリスクヘッジしましょう。
倒壊寸前の家
個人的に家に例えることは多いんですが、技術的負債は老朽化した家そのものだと思っています。築年数はドッグイヤーで計算するので、10年のソフトウェアなら築70年の歴史的な物件です。
安心して暮らせる家は誰もが望みます。洪水や地震などの災害という障害から守ること、泥棒というハッカーの侵入を防ぐセキュリティ、事故物件にならないために情報漏洩を防止するなど、アーキテクチャ設計が基本にあります。
ディスポーザーや食洗機、ジャグジーバスなど機能的な魅力も理解できますし、ゴミを捨てたり掃除機をかけるというバグ改修も理解できます。しかしキッチンに冷蔵庫を置く場所がないとか、生活音が隣人に丸聞こえ、雨漏り、隙間風、無謀な角度の階段、折れそうな柱など当たり前品質を伴わない物件は、家賃を下げないと誰も住んでくれません。
個人的には老朽化した家は住むのは不安であり、リフォームを怠った物件は製品の資産価値に大きく影響するのではないでしょうか。
健康と医者
人体のたとえもドッグイヤーが適用できます。10年のソフトウェアなら70歳のおじいちゃんです。5年経った35歳あたりから健康管理、人間ドックは避けらないです。5年経ったらリプレイスする理論はここからきています。ファクトとしてもAndroidやiOSアプリは5年くらいで開発言語が変わっていますよね。技術的負債は人体における健康であることを解説します。
健康を維持して生活することは誰もが望みます。病気というバグを改修しながら、入院や手術という障害が起こらないように健康管理という製品管理が求められます。
好きなものを飲み食いしたり、寝ないで朝まで遊んだりする欲望という機能追加も魅力的ですが、無茶していると身体を壊してしまいます。病気も治りにくくなり、寿命を縮め、最悪どんな医者でも対処できなくなります。
製品は人体であり、健康に向き合うためにエンジニアは医者だと思って、異変があったら相談するなど健康管理をサボらないでほしいなと思います。
B/S
会社はB/Sの資産の部と負債の部で構成されますが、同じように製品を資産と負債に分離します。資産は機能とアーキテクチャ、負債はバグと技術的負債です。シンプルですがこれだけで製品は構成されています。
資産から負債を引き算したものが純資産ですから、資産を増やすだけでなく、負債を減らすことも経営には求められます。つまりバグもそうですが技術的負債を減らすことは製品の価値を高めることと同じなのです。
プロダクトマネージャーは顧客から見える機能やバグに目を向けるだけでなく、アーキテクチャや技術的負債とも向き合って、製品を管理することが求められます。
プラスの要素であるアーキテクチャ刷新や機能追加が魅力的なのも分かりますが、株主は健全にマネジメントされた会社に投資するように、顧客は健全にマネジメントされた製品を欲しがっています。
まとめ
テトリス、家、人体、B/Sとたとえを挙げてきましたが、だんだん現実に近づいてきました。特にB/Sに関しては書きながらこれが答えなんじゃないかって思ってしまい、たとえになっていない説がありますw
技術的負債やアーキテクチャは顧客だけでなくビジネスサイドにも見えない領域です。しかし製品の見える部分しか見ていないと製品価値がどんどん下がるリスクがあることが伝わったかと思います。そのために開発サイドとビジネスサイドは私たちの製品の技術的負債は何なのか？っていう建設的なコミュニケーションが必要です。
そしてなんだかんだ言ってきましたが、やっぱり技術的負債に対するテトリスのたとえは秀逸だなと再認識した次第でした^ ^