技術的負債とは
語るまでもないかもしれませんが、 Ward Cunningham （ウォード・カニンガム）が生み出したメタファーで、システムを長年運用していると開発効率が落ちていく様を言い表した言葉です。
和田卓人さんによるこちらの翻訳記事が大変分かりやすく、何度も読み返しています。
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明
本記事では触れませんが、翻訳後の解説にあるこの一節が個人的には大変好きです。
Ward の言う負債の悪影響とは、開発と共に得られていく知識や理解と目の前のシステムとの乖離が引き起こす生産性低下のことであり、自分たちが書いているコードの保守性（あるいは、雑さ）のことではありません。むしろコードを書くときには常にそのときのベストを尽くせと言っています。
技術的負債に向き合うエンジニアを外から見て
私は株式会社LIFULLでLIFULL HOME'Sという不動産ポータルサイトの開発に携わっているのですが、直近の2年はエンジニアでありながらプランニング部門（サイトの企画を担当する部門）の組織長をしています。
LIFULL HOME'S自体かなり息の長いサービスとなっており、古いコードベースが利用され続けているシステムや、誰が最後にコミットしたかわからない（もっというとバージョン管理すらされていない）コードも存在します。
それらに向き合い、再度ビジネスを加速するべく、システムやプロダクト、また開発組織全体をバージョンアップするために、エンジニアとしてプランニングも含めた全体を改革していくことが私のミッションです。
そんな2年間の仕事を通して、エンジニアのプレイヤーとして技術的負債に向き合っていた頃とは違う視点を持つに至ったので、それについてまとめ、書き残そうと思います。
技術的負債に向き合うとは
冒頭に述べたとおり、技術的負債はビジネスを減速してしまうものです。
よく言われることですが、そのコード・システムがビジネスに貢献しているのであればそれは悪ではありません。
しかし、成長を鈍化させてしまうのはやはり避けるべきで、その避け方＝向き合い方は大別すれば2つに集約されると考えます。
- 増やさない
- 減らす
技術的負債を解消し、ビジネスを再加速するためには、減らすペースが増えるペースを上回る必要があります。
でなければ、減らすための努力は文字通り焼け石に水で、もしかしたら行わないほうがビジネスが成長していたかもしれません。
つまり、技術的負債を解消するうえで最も重要なアプローチは、技術的負債が増えるペースを落とす、ことです。
技術的負債を増やさない
技術的負債と一言に言ってもビジネスのフェイズ、サービスの特徴、開発組織の特性、様々なものに左右されます。
そのため、まずは自分たちが負債だと感じているモノ/コトに対して、その発生要因はなにかを分析し、個別に対策する必要があります。
要因として思いつくものをパラパラ書いてみると、
- 組織的な慣習
- とりあえずリリースしたものを誰も消さない
- 組織間での引き継ぎが行われず、ナレッジが失われる
- ドキュメント化や自動テストの文化がない
- 技術選定の過ち
- 新しいフレームワークを導入したが、そのフレームワーク自体が短命だった
- マイクロサービス化を推進した結果、類似のシステムが量産されてしまって収拾がつかない
- 技術力不足
- ハイパーエンジニアが設計・実装したが、その人が抜けた後誰もメンテできない
- 新しい言語を導入したが、よくわからないまま初期実装を行ってしまった
弊社では上記が余さず起こっていますし、どの会社・システムでも同じだと思います。（違ったらどうしよう）
これらを完全に防ぐことは不可能ですが、繰り返さないための努力を怠ってはいけません。
組織的な慣習に向き合い、見直さなければ同種の負債が生まれ続けます。
技術選定には過去の（あるいは他社の）知見を活かさなければいけません。
技術力不足は永遠の課題なので、継続的な能力向上と、それを前提としたシステム設計、技術選定が必要です。
技術的負債を減らす
環境保護の世界では、3Rという考え方があります。
Reduce、Reuse、Recycleの頭文字をとった考え方ですが、まずはゴミとなるものを減らし、使ったものはなるべく再利用し、どうしようもないものは原料レベルで再利用しよう、という考え方です。
同じように、技術的負債の解消においても最優先で検討すべきはReduceだと思います。
上記のように負債自体を増やさないというのもそうですが、必要のないシステム・コードを失くすことが最重要です。
いきなりリファクタリングを始めるのではなく、どのシステムがどのくらい利用されていて、今後どのくらい改修される見込みなのかを検討しましょう。
それを見極めるために、プランナーを巻き込み、積極的に機能・システムの削除を提案しましょう。
一言聞いてみると、意外とあっさり消していいですよって返ってくること多いです。
また、もうどうしようもないから作り直そう、ということも往々にしてあると思います。
そういう場合にはシステムの見直しだけでなく、ビジネスの見直しを行いましょう。
カニンガムの言う通り、時間をかけたことで生じたビジネスとシステムのズレがあるはずです。
ただし、話を広げすぎて安易にシステムの作り直しを始めるのは地獄の始まりかもしません。
新旧システムが同居することになり、システムはより複雑化し、負債が増えるペースが増えかねません。
生産性が低下している要因を特定し、なるべく小さく対策、解消しましょう。
作り直す際も、機能単位、ページ単位で進めて、移行が終わったものは消す作業を同時に計画しましょう。
まとめ
いろいろと書き散らしましたが、プランニング組織から技術的負債の解消を見て感じたことは、増やさないためにも、しっかりと減らすためにも、もっとプランナーやビジネス部門を巻き込もうよ、ということでした。
技術的負債はシステムの課題ではなく、ビジネスの課題です。
エンジニアが頑張って生産性を上げる話ではなく、会社や組織としてビジネスを再加速する話です。
技術選定の過ちはエンジニアの責務では？と思うかもしれませんが、そんなこと言ったら施策のハズレはプランニングの責務です。そうやって境界を作ってもビジネスは加速しません。
お互いにチャレンジしつつ、失敗は素直に認めて共に乗り越えていくことが大事だと思います。