>"技術的負債とは何か"についてこの記事であらためて論じることはしませんが、

> (1) 設計や実装の当時に最適解と考えていたものが

> (2) 時間の経過とともに最適ではなくなった結果

> (3) その最適と現状との間に生まれる差分である

> と僕は考えています

>ヤフーでは、約20年分の技術的負債を数年間かけて返還しきる超苦しいPJを最近終えますた。。

>

> そこで得た

> ・技術的負債の一括返済は絶対やらない(辛過ぎる)

> ・"定期的な小出し返済"を遵守する

>

> の2点を組織ルールとして組み込みました。

>

> DXしていく全て企業で基本ルールにする事をオススメします。

>@sugimoto_kei: 「DX(Developer Experience)」って、本当に消費者気分な言葉だよね。

>@sugimoto_kei: 「変更容易性」と「技術的負債」ってことば、使うのを止めた方がいい。計測出来ないのに計測できそうな衣装をまとっている。ものがわかったような気分にさせる欺瞞的な言葉だと思う。

>@sugimoto_kei: ファウラーがいう技術的負債は、リリースまでの時間がないときに、意図して積むもの。巷で言われている技術的負債は本当にそれなのか？単にスキル不足で積まれているような気がする。ここにも意味のズレがある。都合のよい方にズラされている。

>@sugimoto_kei: パッと見にはなんでこんな複雑なコードになってるんだ、こうすれば簡単だろうと感じても、実際にやってみると、隠れた要件があって、簡単にはいかない場合もある。

>でもそれは、修正しようとしたからわかることで、やってみなければ、いつまでもわからないかも。

>@sugimoto_kei: ひとによって違うしね。弊社のコードは、僕にとっては変更容易だが、新しく加わったメンバーにとっては決してそうではない。どちらも正しい。

>「変更容易性」「技術的負債」という同じ言葉を使っても意見が合わない。コードの属性ではなく、コードベースと各人の関係性の問題だからだ。

>それは、修正しようとしたからわかることで、やってみなければ、いつまでもわからないかも。

>コードベースと各人の関係性の問題だからだ。

>@nfujita55a: んで、「技術的負債一掃」を旗印に、本当は必要な機能や仕組みが吹っ飛ぶ、までがワンセットね。

>私も「技術的負債」ってワードが飛んできたら、いやいや待て待ての人。

>@nfujita55a: 「あなたのお給料、その技術的負債が生み出してますよ」ってことを無視して、技術的負債（とそれが生み出された背景・経緯・要求）を取っ替えればみんなハッピーと考える人いますなぁ。

>※あの資料の作者＝無視する人はではありません

>@times_gon: 僕が開発者体験とか技術的負債という言葉が嫌いなのは「生産性」とか「再設計」みたいな言葉で表現できる問題を何故か一緒くたにしたジャーゴンで馴れ合って「あいつらは分かってねえ」みたい態度で経営者と対話する気がない技術者の傲慢さが垣間見えるから

>@shimpeiws: 技術的負債というワードが出るたびに、

>「それは負債ではなく必要なライブラリ更新ですね」

>「もとの品質がイマイチだったコードの書き直しですね」

>とこの記事を貼りながら警ら活動をしてるんですが、もはやオリジナルと違う意味の方が一般化してしまってる感はありますよね

>https://t.co/QowkwaE8w3

>@fuuuuuta21: 「業務が忙しくて、人材育成に時間を使えない」という話を聞くたびに、「人材育成に時間を使わないから、業務が忙しいのでは？」説を思いますし

>退職者が出た時に、自社のマネジメント改善のシグナルかもしれないのに、「組織の新陳代謝」として簡単に片付け、無学習でGOはどうかと思います。

>

>@tanakahisateru: 下手で安いプログラマーを雇ってやっつけで開発しても、それで商売が成り立てばいい、という流れで生まれた技術的負債もあるだろうけど、その負債の選択はそもそも経営者の判断なんだから、いくら開発者が奮起してそれを負債だなんとかしなきゃと言っても意味がなくて、もう経営やるしか手がないのでは

>@wonderful_panda: その場しのぎのコードは必ず負債になる、それは全くその通りだな。

>だがオレは、その負債を返すのがオレじゃないって可能性に賭けるぜ！

>@sinsoku_listy: なんか昔にツイートしたけど、技術的負債を積みながら分かりやすい成果を生んで、その成果をアピールして転職した方が合理的という話があってな…

>@Kory__3: 「未来予知は不可能なので、可能な限り誠実にメンタルモデルをそのまま落とすことが後々の様々なコストダウンに繋がる」というどこで得たのか全然わからない謎の直感があって、これがここ数年の僕のプログラミング経験の中では驚くほどとてもうまく機能している

>@Kory__3: 言語をより深く知ること、抽象的な理論を学ぶこと、形式を直感の永続化として重んじること、Premature Optimization を避けることは全部この謎の原理によって動機付けされている

>@k1_c_: 必要に迫られて速さを追求した結果やむを得ず質が悪くなってしまったコードって実はこの世にあんまり存在しないくて、単に技術レベルが低いかだらしなさの結果なんだよな

>「綺麗なコードを書くために勉強しながら開発してたら遅くなる」ってだけで、「綺麗なコードを書いてたら遅くなる」って話ではない

>こんな話は何十年もの間無限に繰り返されている話なんだけど、ここで真になにが言いたいかというと、日頃の素振りがだいじということ

>@fushiroyama: Twitterがゆっくりとしかし確実に壊れていっていることに残念ながら驚きはないというか、非常に複雑なソフトウェアの面倒を見る人を減らして急な機能追加をすると「分かりやすい大爆発」を起こすのではなくて「あちらこちらから無視できない水漏れが起こる」みたいな壊れ方をするんですよね

>世界最高峰のTech Giantsが世界最高峰の頭脳を世界最高峰の報酬でかき集めて作られているものは鬼怒川温泉の崖に作られた無理な建て増しのような状態になっているというのは案外外からは想像しづらいと思うけど、僕がかつていた会社も多かれ少なかれそうだったし他の会社も似たようなものだと思う。

>これは当事者のPMや経営陣からすら見えづらいことなんだけど、中の開発者はみんな知ってることだと思う。例えば機能Aがあって、これをBに変えるとする。理想的にはある一箇所を変えるだけですべてが切り替わる。こんなの簡単だと誰もが思う。でも実際はそうではない。同じフラグが2箇所にあったりする

>これは極端な例だけど、ある状態機械があって状態変更を次々に伝播させていくときにbroadcastのような仕組みが多段になっているケースがあって、しかもラグや失敗があるのを表面からはリトライやsleepで隠しているようなロジックが普通にあったりする。こういうのが「水漏れ」である。

>@fushiroyama:比較的大きくてもキレイなコードは本当に優れた技術者が独りとか2-3人で書いてる方が圧倒的に実現可能性が高くて、反対に数百人で開発してるソフトウェアは「クソコード」と「マシなクソコード」しか存在しない。

>しかしこれはsarcasmではなくて、大規模ソフトウェア開発とは取りも直さず、停まることを許されないなかで走り続けながらクソをマシなクソに直しながらそれでも未来永劫走り続けることです。これこそが大規模開発の腕の見せどころなのですね。

>@fushiroyama: もちろんみんなコーディング規約に則って、ユニットテスト書いて、コードレビューを通して、QAの末に皆の所に届くんですね。それでもバグるんですね。皆で何とか水漏れに蓋しながらコードを少しでもマシなクソにしながらそれでも走り続けるしかないんですね。これが大規模開発なんですね。