CTOの仕事を技術的負債を減らし技術的資産を増やす仕事だと仮定すると上手くいきそうだな、と思った話
はじめに
こんにちは!
最近、
「技術顧問やCTOやってます!」
っていうと
「具体的に何をやってるのですか?」
と聞かれるので、色々と答えていたのですが、
・技術的負債
・技術的資産
という用語で整理すると結構すっきりしたので、自分自身のアウトプットをかねて書きます。
技術的負債とは何か?
「技術的負債」という言葉は、2000年代後半から2010年代初頭にかけて日本でも認知されたと言われてます。
この言葉の生みの親とされるのは、Ward Cunningham(ウォード・カニンガム)さん。
彼が初期のコードリリースを「借金」に例えたところからきてます。
技術的負債=「コードの借金」
コードをリリースする際、時間の制約などで最適な修正を後回しにすると、リリース後にそのツケ(=負債)が工数として返ってきます。
これを、まるで借金の利息のように例えたのが「技術的負債」という考え方です。
具体例でいうと:
テストコードがない → 後々のバグ修正に余計な時間がかかる
読みづらいコード → 開発者が離職する原因になったり、修正工数が増える
参考として、t-wadaさんが日本語で分かりやすく解説している記事を以下に紹介します:
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明
技術的資産とは何か?
「技術的負債」があるなら、「技術的資産」もあるかなと思って調べてみたのですが、こちらは生みの親がいなさそうなので勝手に定義してみました。
※もし、いらしたら教えて下さいm(_ _)m
技術的資産=「リソースを増やす要素」
技術的資産を考える上で、まず資産とは?
ということで、ロバート・キヨサキによる著書『金持ち父さん、貧乏父さん』の定義を引用します。
これを参考に以下のように定義してみると、結構すっきりしました。
資産 → リソース(人、もの、お金)を増やすもの
負債 → リソース(人、もの、お金)を減らすもの
技術的資産の例を挙げると:
最新のプログラミング言語を導入する → 開発者が魅力を感じ、採用がスムーズになる
読みづらいコードをリファクタリングする → 修正工数が減り、結果的にコスト削減につながる
定義した技術的資産、技術的負債を使ってCTOの仕事を整理すると?
このフレームワークを使うと、CEOやエンジニアじゃない人に説明するときも
例えば:
「この技術を採用すれば、採用活動がうまくいき、人材確保に貢献できます。」
(技術的資産を増やす活動)「コードが読みづらいのでリファクタリングをすることで、コードを読みやすくすること&改修するためのコストを減らす。」
(技術的負債を減らす活動)
となり、説明しやすくなるのかなと思いました。