「下手だなあカイジくん…！技術的負債の返済の仕方が下手…！」 ちゃんとシステムを構築しないと後で多く利子を払うことになる

米村歩@日本一残業の少ないIT企業社長 @yonemura2006

「技術的負債」という言葉があります。要するにちゃんとシステムを構築しないと後で多く利子を払うことになってしまうということです。無茶な納期や金額でシステムを作らせてたまたまうまくいったら最初は得した気分になるかもです。しかし後々の改修やらメンテやらで莫大な利息を払うことになります。

広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

技術的負債の話が非エンジニアに通じにくかったら、使っていいよ。 どうやって解消していくかは、本を読んでみてくださいね。 #技術的負債 #randomに使っていいよ #エンジニアリング組織論への招待 pic.twitter.com/BQEzSmXdW9

拡大

Yuta Kashino @yutakashino

（´-`）.｡oO( スタートアップ創業者コーディング問題というのがありまして…．非エンジニアの創業者が最初エンジニアを雇えないため自分でコーディングした部分が最後まで技術的負債となりリスクを生むけれど，創業者自身はコーディングできることを最後まで外に吹聴しまくるという… )

えむばーど @m_bird

技術的負債のことをなんと呼ぶか？という話で、すぐに「そびえ立つ糞」って声に出してしまうのでもっと上品な表現を……と模索した結果、 「弊社の動く糞」 という言葉がひりだされました。同僚にはゴミを見るような目で見られました。

てるろー @terurou

「あなたの技術的負債はどこから？」「私は前任者から」

大平 之人(Yukito Ohira) | フリーランスエンジニア完全攻略バイブルの人 @yohira_dev

下手だなあカイジくん…！技術的負債の返済の仕方が下手…！カイジくんが本当に欲しいのは、1からの作り直し…！だけどそれはあまりに時間がかかるから、こっちのしょぼいリファクタリングでごまかそうっていうんだ…！

henrich @henrich

技術的負債ではなく、「連帯保証人」にされるのが辛いのでは

henrich @henrich

技術的負債（Technical Debt）、最初の人は借金してることすら気づいてなくて利子が複利で来てるのを、後からきた人が保証人にされて返済させられるのが多いのでネガティブワードになったのでは

wataru kubota @wkubota

技術的負債あるある。 技術的負債を残す人（残す判断をする人）と技術的負債を返済しなくちゃならなくなる人はたいてい別。

米村歩@日本一残業の少ないIT企業社長 @yonemura2006

一度技術的負債を抱えてしまうと、それを返済するためにも工数（お金）が発生します。その返済額の大きさによっては元金は返済せずに今後も利息を払い続けるという選択をする時もあります（ちなみにエンジニアはこれが嫌い）。どちらにしても余計にお金が出ていくので技術的負債は良いことありません。

米村歩@日本一残業の少ないIT企業社長 @yonemura2006

エンジニアは技術的負債を嫌いますが、これを作り出すのはエンジニアです。無茶な納期や金額でシステム作れと言われたら、技術的負債という借金を借りてきてシステムを作るしかなくなります。その莫大な借金の利息を払い続けるのは顧客です。目に見えないけど無茶な要求は自らの首を締めます。

米村歩@日本一残業の少ないIT企業社長 @yonemura2006

普通に作られてたら10万円の費用で済む簡単な改修を、技術的負債を抱えてしまっているせいで100万円かかってしまうということもあります。しかも技術的負債を返済しない限り、そのシステムの運用を続けてる間そんな非効率がその後もずっと続くのです。初期構築費用だけで判断してはいけない理由です。

広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

部屋を片付ける権利が家主になくて、いろんな荷物が順番に送られてくる。ゴミも出せないし。 部屋が汚くなっていくので掃除をさせてというと、費用対効果は？と聞かれるから困ってなかなか足の踏み場がなくなって二進も三進もいがなくなるまで放置される。 要はこれが技術的負債です。

広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

だから、なんでこんなもんが問題になるかというと、 １、家主に片付ける権利がないことと、 ２、荷物を送りつける人が部屋を観に来ないこと 普通のことなんですけど、システムだからわからないと思う人がいるだけ。 なので情報の非対称性からくる問題なのですよ。という。

広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

僕が「技術的負債」という言葉を使うとき、その正体は「ソフトウェアの複雑化による開発出力の低下」そのものでなく、その認識を意思決定者と共有しづらいという視界の非対称性にこそあると考えていて、対策はその観点から行われるとうまくいくことが多い。 pic.twitter.com/iSyROQqiH5

拡大

まろ@関数型言語作曲機械学習勉強してない @_marony

技術的負債の話の時に、たいていはむちゃくちゃな設計や改修につぐ改修での混乱が例に出されるんだけど、「優れた人が周りに周知せず導入した言語やツール」もかなり大きな負債だというのは声を大にして言いたい

ミノ駆動 @MinoDriven

技術的負債は知覚が困難なのが問題。 知覚できる人は、 ①「く、苦しい…この苦しさの原因は一体なんなんだ？」と自律的に原因に立ち向かった経験のある人 ②あるべき設計を学んだ人 ぐらい。 それは天と地ほどの差で、知覚できない人からは「これの何が問題なわけ？」と目をパチクリされるのだ。

神速 @sinsoku_listy

一般的なエンジニアは既存コードを参考にコードを量産する。その結果、技術的負債はメンバー数の複利で増えるし、既存コードを良いコードに書き直す（負債を返済する）エンジニアは評価されづらい。

広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

ベンチャー、うまくいってる時は成長が全てを癒してくれて、小さな個人的対立も意識することなく楽しい。徐々に成長がサチるころに、新しく入った人に先にいた人が防御、回避、攻撃的反応をするようになり摩擦が起きる。時を同じくして技術的負債が問題となり、「つまらなくなった」と初期メンが辞める

広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

先にいた人は、人数が少ない時は理想のホラクラシー組織だと楽しんでいて、マネージメントを放棄。その結果産んだ組織のせいで苦しみ、辞める。因果は見えにくいけど、面白く無くなったのではなく、面白くなくしたと考えた方がいい。

広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

じゃあどうしたらいいの？ 「エンジニアリング組織論への招待」を読んでください。お互い。

広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi

この本は、私は何も知らない。それどころか何も知りえない。他人も未来もわからない。わかりえない。しかし、自分の行動はコントロールできる。そこから出発した内省の本です。何かを知るためでなく、何も知らないのだと知るための本です。そして、それがエンジニアリングの全て。