こちらを読んで、思ったことを書いてみようと思いました。
記事についての感想
ほとんど同意です！ 凄くまとまっていて読みやすかったです。
ここに書くのは引用記事の別視点での自分の解釈になります。
技術的負債はいつ生まれるか？
残念ながらアプリケーションのコードを書いた瞬間に技術的負債は生まれます。
どんなに綺麗に書いても、レビューをしても消えることはない闇です。
つまり技術的負債は生み出さないようにするものではなく、コントロールするべきものなのです。
そして、引用元タイトルでは戦う！となっていましたが、
僕は戦い続けて疲れてしまったため、マネジメントすることにしました。
(やることは変わりません)
技術的負債を許容する
技術的負債を細かく返すことは賛成。
ただ、開発者はスケジュールと戦っているため、スケジュール内に必要な機能を提供することが最低限になる。
プロダクトに価値を生むためにはリリースを最速でやったほうが良い場合がある。
そのときには技術的負債をある程度許容する。
その際にはどれほどの負債になるかを把握して、マネジメントすることが必要。
技術的負債はほとんどの場合についてお金のローンと同じように考えることが出来る
お金も投資することによって、ビジネスのスピードを上げることが出来る。
かわりにその瞬間は売上０。人を雇ってコストも掛かり、システムもまだ出来ていないため動かないのでお金ばかり出る。赤字である。ただ、最初に投資したお金を使うことで、最速でシステムが完成し、ビジネスが立ち上がり収益が出たときに、投資にかかったお金を返済する。
もちろん、自分の空いた時間だけでコツコツ１人でシステムを作れば赤字は０に出来る。
しかし、システムはいつ完成するか分からず、売上も上がらない。
ビジネスは負債を抱えても、スピードを重視しなければならないときがあるものです。
技術的負債も開発スピードを優先する瞬間には許容し、
ビジネスが立ち上がり、プロダクトが価値を提供できるようになったときに
初めてその返済するタイミングを考えることが出来る。
エンジニアは決済者に技術的返済のお願いをすることになるだろうが、
そのプロダクトがちゃんと価値を提供できる状態になったのか？軌道に乗ったのか？
を見極めて、そのタイミングでお願いをしなければ負債返済は了承されることはない。
プロダクトに価値を与えることこそがメインであり、手法として技術がある
残念ながら、そもそも売れないものすごくキレイなコードを書いても全く意味はないのだ。
エンジニアとして売れるか売れないかは理解しようもないが(企画をする人も世に出ない限り売れるかはわからないだろうが) プロダクトの価値を生む方法として技術があることに変わりはしない。
技術的負債の発生量を把握する
まず、メンバーの力量を知ること。
技術的負債をコントロールする人はコードを書く全員分のコードレビューを１度はした方が良い。
出来る限りメンバの力量を知る方が良い。
なぜなら、上手く書けない、設計できないメンバはコードを書くだけで負債を生み出してしまうからだ。
そのようなメンバはベテランのメンバとコンビを組むようにしたり、
１度しか使われないようなプログラムを多く任せて力を付けてもらう。
負債状況のシェア
KPTや愚痴大会でも良いので、どこに不満があるか、どのように改善したいか、なにか新しい良いものがあるかなど
負債状況を素直に話せる環境を作りましょう。
毎日のレビューだけでは出てこず、把握できないものが出てくるはずです。
タイミングについてはビジネスとのサイクルを合わせることが重要ですが、
負債の最新状況の把握は常にやらなければなりません。
必要なのは短期、中期、長期の負債戦略
もはや、お金の投資のタイミングの話と同じような事になります。
短期的に開発スピードを優先するケースと負債を抑えることを優先するケースを判断する
中期に開発スピードを落とす可能性のある負債を解消する。ルール定義を行うことやレビュー感覚を共有しノウハウをシェアして一定水準の品質を保てる仕組みやシェアの仕組みをつくる
長期に上手くコードが書けないメンバなどの引き上げや採用計画、チーム編成などを検討し安定した負債コントロール状態に出来る体制づくりをする
決済者との対話
中期的な負債解消の際には決済者と対話し時間を貰うことになるが、エンジニアには説明責任があると思う。
これを行わないと今は動いているが、中長期でどのようなことになるかをしっかり説明する。
- 開発スピードが下がり、新規機能の開発スケジュールが常に長くなる
- バグを誘発させ、障害になるケースが増える
- セキュリティ問題が発生し、情報漏えいなどの可能性がある
- システム許容サイズを超え、ビジネスをスケールさせることが出来ない
- 普通にツライので辞めるエンジニアが出る(たいてい優秀な人から辞める)
などなど
技術的負債とお金の負債の違う部分
技術的負債は生み出したメンバであってもプロジェクトを移ることで
別の人に丸ごと返済を追わせることが出来る、最悪のことが可能な恐ろしいものなのだ！
自分で生み出した負債でない対応に苦しめられるメンバは理不尽さを感じたり、自由に開発が出来ない不自由さから辞めてしまうこともある。
メンバ状況からプロジェクトで請け負える負債量を把握しながら返済したり借金したりしなければ、チームが破錠の道へ進むのはお金の場合と変わらない。
最後に
負債をひたすら嫌悪するだけではなく仲良く過ごす方法を考えましょう！
お借入は計画的に！