Zalandoのエンジニアリングチームが，溜まり続けた技術的負債をどういったプロセスで返済してコントロールできるようになったかを紹介してくれている記事．

なかなか優先順位が上がらずに技術的負債が溜まっていくとかは有り得そうなので，どうやってコントローラブルな形にしていったかは気になるところ．ちょっと毛色が違う記事だけど，面白そうだったので読んでみる

Technical debt, Known and Unknown

Johari windowを使って少し考えてみると，“known known (既知の既知) ”はわかるので置いておく，“unknown unknown (未知の未知) ”，つまり持っていることを知らない技術的負債も存在していることを認識する必要があると言っている．

未知の技術的負債には，少なくとも2つの原因がある

1. 認識していないだけで，サービスには問題がある
2. テクノロジーは日進月歩の分野で，今日の最先端の設計パターン・開発プロセス・テスト戦略・あるいはプログラミング言語やパラダイムさえも取って代わられる可能性がある
   • 既存のサービスを見直し，改善点を探す時間を取るべきである

Zalandoでは，技術選定や新技術の採用について正式なプロセスを設けているとのこと．

未知の未知に関する技術的負債はあまり聞かなかったし，確かになと思う点があるので，定期的に既存のサービスの見直しは意識するのが良いと思った．

Motivating your Engineers

Theory X / Theory Yの紹介がされている．Zalandoでは，バックログに3年前のチケットがあったりとチケットに取り組むモチベーションがないことを意味しているのは明らかで，何をすべきかを指示することは可能（Theory X）だが，自分が本当にやりたいと思うチケットに取り組んだ方が，生産性が高くなる傾向にあるのもまた然り（Theory Y）．

ここで著者は技術的負債に取り組むことの良さを伝えるTheory Yのアプローチで，改善を図っている．

例えば，以下の技術的負債の解消を実際に達成している．

• リソース要件を評価することで，AWSのホスティング料金を毎週500ドル削減
• データ型を最適化し，冗長な情報を取り除くことで，あるデータベースの容量要件を12％削減

こういった改善は結果も定量的に見えるものが多かったりするので，取り組む姿勢は見習いたい．一方でチームの理解も必要そうだなと思うので，もし自分がリードする立場になったらこの辺は是非推奨していきたいと共に，このような問題に取り掛かれる心の余裕がある組織を作りたいなと思った．

The Technical-Debt Rotation

技術的負債を解消するためのローテーションを組んでいるとのこと．すべてのエンジニアが技術的負債のローテーションを交代で担当し，1つのイテレーションは1週間続く．毎週月曜日に自分が取り組みたい技術的負債を決める時間を割き，既知の技術的負債もしくは未知の技術的負債に取り組む．

未知の技術的負債に取り組む場合は，サービスの中から一つを選び，ソースコードを研究し，改善点を探すことを推奨しているとのこと．これはもちろん優先順位があり，より緊急性の高いものがあればそちらに対応する．

技術的負債を分類するために，「複雑さ」と「インパクト」という2つの指標を使用し，両方を1～5の尺度でランク付けする簡単なシステムも導入しているとのこと．この基準から，複雑性が低く，中程度から高い影響力を持つ作業に取り組むことを推奨しているとのこと．