組織の技術的負債の返済はなぜ進まないのか？ “工数確保の合意”に関わる意思決定層と現場視点の違い

クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。まずは、技術的負債とは何か、組織における技術的負債返済までの構図について紹介します。 組織と個人それぞれの技術的負債の解消方法 原トリ氏（以下、原）：こんにちは！ 今日はこんな話をします。（スライドを見て）なんだか面倒くさそうなキーワードばかり並んでいますね。どれも避けて通りたくなるものばかりです。 はじめまして。こんにちは。Tori、あるいは原トリと言います。ふだんはAWSという会社で、AWSのコンテナサービスをよりよいものにするために、いろいろな仕事をしています。 今日はタイトルのとおり、こんな話をしていきます。まずは「技術的負債って何でしたっけ？」という話を軽く整理していこう

[t-wada]

技術的負債とは手抜き実装などのことではなく「実装当時に最適解と考えられたものが時間の経過とともに最適とは評価され得なくなったもの」。素晴らしい資料だったので文字起こしの公開はうれしい

[ed_v3]

まぁでも現場では手抜き実装起こるしそれはそれで技術的負債だし、技術的負債に向き合うときにはどっちも考えなきゃいけないと思うけどなぁ。

[hate1229]

使える工数は限られていたり納期もあるので意図した手抜きも技術的負債なのでは？

[coco7t]

技術的負債があっても正常に動いているものって過去にそれなりの手間かけて動くようにしているので安易にいじるとバグを生んだりしてユーザーに迷惑かけるので腰が重くなりがちなんだよな

[braitom]

すごくよい内容だった。“実装当時には考えられた方法の中でベストだと言えたものが、時間の経過とともにベストとは言えなくなったもの。これを本セッションでは技術的負債と定義します。”

[yukimi0721]

無能上司の返済方法も知りたい

[tattyu]

常々工数なんて正確に見積もれるのはせいぜい3週間程度だよなぁと思ってる。精度高い人も居るけど大体自分と関係無い所で工数は大きくズレていくのでそう言うの含めるとやはり3週間程度が限界かなぁって思う。