【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
2022-12-21 技術的負債の返済から改善する開発者体験 - Techmee vol.5 https://timeedev.connpass.com/event/268296/ 動画 https://youtu.be/tQ3BGgnvMwQ
2021/04/10開催 Developer eXperience Day 2021 「クソコード動画『Userクラス』で考える技術的負債解消の観点」の解説資料です。 https://dxd2021.cto-a.org/program/time-table/b-3 クソコード動画はこちら https://twitter.com/MinoDriven/status/1380773721032433674 YouTubeライブのリンクはこちら https://www.youtube.com/watch?v=ajPaGPdj6tU
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
技術的負債の生態 - maru source
@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
「スタディサプリ」が React Native から卒業するまで、あるいは技術的負債への感謝と敬意 - スタディサプリ Product Team Blog
こんにちは、Quipper iOS エンジニアの @manicmaniac です。 現在スタディサプリ iOS アプリ開発チームのエンジニアリングマネージャをしています。 今回はスタディサプリで長らく使われていた React Native のコードを Swift に書き換えた話をします。 実は React Native から Swift への置き換え自体は半年ほど前に完了していたのですが、ブログに記すのに時間がかかってしまいました。 スタディサプリにおける React Native の利用 Quipper では 2017年ごろから React Native を iOS / Android アプリ開発に利用し始め、スタディサプリでは 2018年3月ごろから徐々に React Native を iOS アプリケーション開発に導入していました。 iOS 版スタディサプリの、git から取り出した
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
「下手だなあカイジくん…！技術的負債の返済の仕方が下手…！」 ちゃんとシステムを構築しないと後で多く利子を払うことになる
米村歩@日本一残業の少ないIT企業社長 @yonemura2006 「技術的負債」という言葉があります。要するにちゃんとシステムを構築しないと後で多く利子を払うことになってしまうということです。無茶な納期や金額でシステムを作らせてたまたまうまくいったら最初は得した気分になるかもです。しかし後々の改修やらメンテやらで莫大な利息を払うことになります。 2020-06-24 07:49:11
C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と
Googleの技術者Chandler Carruth氏らは、C++の後継を目指す実験的なプログラミング言語として「Carbon Language」（以下、Carbon）をGitHubで公開しました（Chandler Carruth氏のツイート）。 GitHubのドキュメントでは、C++が性能を重視するソフトウェア開発において主流のプログラミング言語である一方、言語そのものにおいて数十年にわたる技術的負債が蓄積されていることなどにより段階的に改良していくことが極めて困難になっていると指摘。 一方で、GoやSwift、Kotlin、Rustを始めとする優れた開発者体験を提供する多数のモダンな言語は、C++の代わりに採用する、あるいはC++の開発から移行するには、プログラミング言語の違いや性能のオーバーヘッドなど障壁が多すぎるといった課題があるとも指摘しています。 そこでC++の段階的な改善では
河野と申します。2018年8月からマッハバイトで業務委託（いわゆるフリーランス）として業務に携わっており、2022年6月から、テックリード（以降、TL）という立場となりました。 TLという言葉は広く使われていますが、実際に何をするのかは、会社や環境によってさまざま。 3ヶ月の振り返りがてら、ここに一例として公開してみようと思った次第です。 TL着任以前 Join当初はRailsエンジニアとしての働きを期待されており、最初の担当はマッハバイトiOS版用に、REST APIを開発することでした。 半年少しでその業務が一段落した後は、以下のことなどを担当してきました。 Rails製アプリケーションの機能追加、Ruby、RailsのUpdate ホストOSのUpdateに伴う、deploy環境の修正や、ライブラリなどのUpdate（オンプレ環境） マイクロサービスの中心に置きたいメッセージングサー
技術的負債を徹底的に解消した話 - オミカレのシステムフル刷新のためにやったことを全部教える - エンジニアHub｜Webエンジニアのキャリアを考える！
技術的負債を徹底的に解消した話 - オミカレのシステムフル刷新のためにやったことを全部教える 技術的負債、デザイン面での課題など、サービスを構成するシステムを全面にわたってリニューアルしたプロセスを、オミカレの高橋一騎さんが克明に伝えます。 株式会社オミカレでテックリードをしております、高橋一騎（たかはし・いっき／ @ikkitang ）です。私たちが提供する婚活メディアサービス「オミカレ」は、2019年3月にシステムのフルリニューアルに踏み切りました。本稿では、このリニューアルのプロセスをできるだけ詳細にお伝えしたいと思います。 さて、「技術的負債」という言葉を耳にすることがあります。なぜ負債が生まれるのか。「品質を犠牲にしてでも早々にサービスをリリースし、短期的にビジネスの速度を上げる」という判断はその理由の一つに挙げられるでしょう。エンドユーザーへの価値提供スピードを得るための見返り
Railsは技術的負債である
Railsを使うと、初速は早くなる。それは間違いないと思う。一方で、RailsはVierwからDBまで密結合したフレームワークなので、「段階的なアップグレード」とかがむずかしい。ヴァージョンをあげるときには一気にエイヤであげる必要が出てきがちである。さらに、プロダクトが巨大になってくると結局様々な工夫を凝らしてViewからDBまでの間を疎結合にしていくことになる。そうなってくると、「これRailsである意味あるんだっけ」となって、段階的なアップグレードのしにくさや気をぬくと密結合な設計になるという欠点が目立ってくる。 これは、まさに技術的負債そのものである。ここでわたしが「技術的負債」を「単なる悪いもの」として扱っているわけではないことに注意してほしい。Railsを使うというのは、そういう将来の負債を借り入れて、その借金を使って早くプロダクトを世の中に届けるという判断をしている、ということ
この記事は「Funds Advent Calendar 2022」21日目の記事です。 ファンズ株式会社 CTO の若松と申します。 今年も例年通り Twitter の運用は三日坊主となり、 note についても筆を断ったまま2022年を終わりを迎えようとしていたところ、アドベントカレンダーの時期が来ていました。 せっかくの機会ではあるので、以前から漠然と思っていた考えを整理してみたいと思い、この記事では財務諸表を読み解く概念的な考え方を使い、技術的負債について読み解いてみることにしました。 ソフトウェア開発上の概念である"技術的負債"ファンズは、貸付ファンドのオンラインマーケット「Funds」を通じて、個人投資家には着実な資産運用の機会を提供しつつ、企業に対しては借入によるファイナンスの機会を提供しています。そのような事業業態の性質上、コーポレートファイナンス的な考えに触れる機会も一般的
# ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す https://www.youtube.com/watch?v=PSCmjrrbNkg # Howだけ考えると複雑さを導入して仕事が増える https://soudai.hatenablog.com/entry/2020/08/14/101657 # 質とスピード（2020春版） / Quality and Speed 2020 Spring Edition https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition # 判断と決断の違いと決断のコツ https://soudai.hatenablog.com/entry/2022/01/04/151923 # Worse Is Better -
ライブドアブログが15年かけて積み上げた技術的負債への挑戦 LINEのブログサービスのエンジニアが明かす、光と影 Inside of Blog 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦 #1/2 2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINEの技術の深堀りを、2日目は「Production」をテーマに、Web開発技術やUI/UX、プロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦」に登壇したのはLINE 開発Bチームの大森貴博氏。前半パートとなる今回は、今年で3
カミナシでの技術的負債返済プロジェクトとその決断 / Beyond tech debts at Kaminashi
Talked at 「スタートアップと技術的負債」 #SELECKLIVE https://yumemi.connpass.com/event/255925/
【16-E-4】残業ゼロで開発スピードが10倍に！もう元の開発体制には戻れないデンソー流のアジャイル開発Developers Summit
4/30発売の『良いコード/悪いコードで学ぶ設計入門』を紹介する「『良いコード/悪いコードで学ぶ設計入門』著者トーク」。ここで著者の仙塲大也氏が登壇。最後に「エンジニアリングの当たり前を変える」に込められた想いと執筆の裏話を話します。前回はこちらから。 押さえるべきこと押さえて設計できるスキルは当然になるべきではないか 仙塲大也氏：そろそろ「エンジニアリングの当たり前を変える」という発表のタイトルを回収したいと思います。 「毎年12兆円以上」。これは何の金額かみなさん知っていますか。経済産業省の出した金額ですが、2025年以降、技術的負債による経済的損失が毎年、単年じゃないですよ。毎年12兆円以上になるという試算だそうです。 2021年の国家予算ですが、補正予算も合わせて142兆円です。それに対して、毎年12兆円以上も発生していくことになる。国家規模の損失が発生しているわけなんですよ。本当
スタートアップにクリーンアーキテクチャを適用したが、技術的負債が塵積った件 〜開発合宿で技術的負債を粉砕します〜 - ANDPAD Tech Blog
こんにちは。こんばんは。おはようございます。 アンドパッドで現在はバックエンドの方のエンジニアをやっている原田です。 アンドパッドには2021年6月にJOINしまして、現在までANDPADボードの開発に携わっています。 ANDPAD施工管理が比較的長期間の工事をターゲットにしているのに対して ANDPADボードは1日〜数日の間に短期間の工事や施工を行う際のスケジュール管理を行えるサービスです。 andpad.jp 今回は入社3ヶ月目というきりの良いタイミングで今まで行ってきたことを振り返りつつ、直近行った技術的負債を軽減するための「開発合宿」について書いていきます。 一応最初に書いておきますが、リファクタリングに関するチートスキルはないのでバーンとやってドーンと解決みたいなド派手な解決ではなく地道な改修作業をちまちま行いましたという内容です。 入社してからやってきたこと ANDPADボード
Re: 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - @kyanny's blog
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト
技術的負債になりかけていた機能をリアーキテクティングしたら、めちゃくちゃ改善した話 - カミナシ エンジニアブログ
ソフトウェアエンジニアの 鈴木 (@szk3) です。 先日、カミナシにおいて古くから存在する１つの機能をリアーキテクティングしました。 その結果、処理時間は4分の1以下、コストは90%程度削減 と大きな成果を出すことができました👏 本記事では、その機能が抱えていた課題に対しどのような改善のアプローチをして上記の結果に結びついたのか？について共有します。 Excel変換とは 今回、リアーキテクティングの対象となった機能は、カミナシに帳票として記録されたデータをExcel形式に変換して出力する機能です。 これを、”Excel変換” と呼んでいます。 Excel変換は、カミナシのサービスの中でも比較的古くから存在する機能です。 ここ数年での利用ユーザーの増加と共に、設計当初のシステムアーキテクチャが技術的な負債となっている状態でした。 Excel変換の課題 まず最初に、設計当初のアーキテクチ
2024.3.22（金） SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/
React＋Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計｜ハイクラス転職・求人情報サイト AMBI（アンビ）
React＋Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計 遷移なく表示コンテンツを変更できるシングルページアプリケーションでは、ページの状態管理が重要になります。現在はReactによるUI構築とReduxによる状態管理を選択しているChatworkは、jQueryなどの技術的負債と共存しながら、フロントエンド設計の見直しを重ねてきました。クライアントサイド・アーキテクトの火村智彦（@eielh）さんと、エンジニア採用広報の高瀬和之（@guvalif）さんによる解説です。 クラウド型ビジネスチャットツール「Chatwork」は、2011年3月にローンチされて10年以上にわたり開発を継続してきました。このように長く続くサービスがユーザーに価値を提供し続けるには、時間経過による変化に適応するため設計の見直しが必要になります。 しかし、設計を
20年以上前に構築した古い基幹系システムを使い続けるユーザー企業が5社に1社の割合で存在するとされるなか、「枯れた技術」の維持管理に危機が迫っている。枯れた技術としてはCOBOLが有名だが、今回取り上げるのは別の技術だ。 リレーショナルデータベース（RDB）である。とりわけ最大シェアを誇る米オラクル（Oracle）の「Oracle Database（Oracle DB）」を扱える技術者が足りないとささやかれ始めている。 クラウドシフトとAI人気が原因？ 「今まで1度も取引のないユーザー企業からOracle DBに障害が発生したといきなり連絡を受け、復旧作業を頼まれるケースが増えている」。こう証言するのはDBの導入や運用保守を専門とする、日本エクセムの後藤大介CEO（最高経営責任者）だ。 こうした依頼が増えた理由について、後藤CEOは「ユーザー企業が自社システムのクラウド移行を進めた結果、社
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
「負債にも50パーセントの時間を使ってください」は機能しなかった 西村賢氏（以下、西村）：最初にやったことに価値がありました。そして、次は第2段。 原トリ氏（以下、原）：この説明会やった時に、6月は一回止めますと（話しました）。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村：これ、カミナシの歴史で初めてですね。 原：たぶん、初めてだと思います。 西村：そこは「大丈夫なのかな？」とかなかったんですか？ 原：「この1年大きい機能、出てないよね？」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村：なるほど。なにか技術的にうまくいっていないというのがあった。 原：そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力
お前も技術的負債にしてやろうか！ もしくは技術的負債と和田卓人さんをめぐるシンクロニシティ - YAMDAS現更新履歴
みんな大好き、技術的負債の話題である。 t-wada.hatenablog.jp まずはエチケットペーパーというか議論の前提として、和田卓人さんのブログエントリをはっておく。 技術的負債という概念の生みの親であるウォード・カニンガムの説明を読み直すと、「技術的負債」という言葉の一般的にイメージとは結構違うという話だが、ワタシ自身、技術的負債といえば、和田さんが書くように「リリース優先で雑なコードを書いたものの、結局はきれいに書き直されていないコード」や「古くなってしまった技術基盤（言語やインフラやフレームワーク）」のことだと思い込んでいた。これには蒙を開かされた。 ieeexplore.ieee.org 偶然だろうが、和田さんの文章が公開されたのと同じ今年の6月、IEEE Software に技術的負債についての文章が掲載されている。これを書いたのは、『Just Enough Softwa
GMOペパボ株式会社で執行役員 技術部長 兼 VPoE（VP of Engineering）を務める柴田博志（@hsbt）と申します。CTOの栗林健太郎さん（@kentaro）と共にGMOペパボのエンジニアをまとめています。 技術的負債、どこの組織にもありますよね。どうやって返済していますか？ 会社として技術的負債にどう立ち向かうべきか、そのコツは人のマネジメントにあると考えています。今回はflexy読者の皆様と技術的負債を考えていこうと思います。 技術的負債とは： 技術的負債とは、開発の中で先送りにされる、ドキュメンテーション不足、保守コストのかかるテストコードや不必要に複雑なコードなどを指します。技術的負債が蓄積してしまうと、将来的に重大な問題を引き起こしたり、対応コストが雪だるま式に増えてしまいます。すべてのコードに技術的負債が発生する可能性があり、組織はどこかのタイミングで技術的負
1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が
【Startup Day 2023】技術的負債を抱えながら それでも生きていく / Living with technical debt
こちらで登壇したときの資料です。 主催 : AWS Startup Community Startup Day 2023 https://aws-startup-community.connpass.com/event/289498/ 技術的負債 x スタートアップ について経験から感じたことを踏まえて話します。 システムを開発する上で技術的負債の取り扱いは難しいですが、事業立ち上げの中での取り扱いは更に難しく感じます。スタートアップの文脈の中での技術的負債は、通常の開発よりも違った傾向を理解する必要があるのではないでしょうか。システムを立ち上げることと事業を立ち上げることの違い。金銭的や人的な余裕の違い。ほかにも様々な違いがありそう。 これらの違いを考察しながら、スタートアップという特殊環境で生まれる技術的負債の原因を考えてみます。 ▶ 話さないこと 技術的負債の与える影響 技術的負債の
技術的負債の中身｜wadap
これはエンジニアにとっては比較的当たり前の内容について書いている。そのためどちらかというと非エンジニア向けの内容として書こうと思う。 エンジニアが開発しづらいと感じたり開発速度を妨げる要因としてあげられるのが技術的負債だ。この単語自体はエンジニア意外にも知られる言葉となりつつあるため、わりと幅広い層の人たちが認識している単語だとは思う。実施に私自身が外部から関わっている会社でもよく聞かれる言葉ではあるが、単純に負債としてまとめていること自体が問題なケースも多く見かることが多い。その分類自体が問題の本質になっていることもあるため、自分の観測可能な範囲の情報をもとに書いてみようと思う。 技術的負債とは何か？wikipediaには以下のように書かれている。 技術的負債（英: Technical debt）とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こ
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。まずは、技術的負債とは何か、組織における技術的負債返済までの構図について紹介します。 組織と個人それぞれの技術的負債の解消方法 原トリ氏（以下、原）：こんにちは！ 今日はこんな話をします。（スライドを見て）なんだか面倒くさそうなキーワードばかり並んでいますね。どれも避けて通りたくなるものばかりです。 はじめまして。こんにちは。Tori、あるいは原トリと言います。ふだんはAWSという会社で、AWSのコンテナサービスをよりよいものにするために、いろいろな仕事をしています。 今日はタイトルのとおり、こんな話をしていきます。まずは「技術的負債って何でしたっけ？」という話を軽く整理していこう
20%ルールに頼らない: 技術的負債を解消する 組織的な取り組み / Developers Summit 2023 Summer
2023.07.27に開催されたDevelopers Summit 2023夏の登壇資料です 登壇者：湯前 慶大(VP of Engineering)
以前から「スタートアップのなかで『技術的負債』というものをどう扱うべきなのか」というテーマに対して関心が高かったのだが、今年の6月から「0→1」の新規事業に関わるようになって、自分の中でなんとなく考えがまとまりそうなので、雑に吐き出してみる。最近、社内でも「技術的負債」が話題にあがることが多く、その中で同僚のエンジニアからあがった意見も参考にしている。 そもそも技術的負債とは @t_wada さんの次の記事に答えが書いてある。 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wada のブログ 個人的には次のように解釈した。 「手を抜いた雑なコード」は技術的負債とは呼ばない。それはただの低品質なコードである 仮説検証や経験からさまざまな学びを得ることは正義 そこで得た「学び」と「現状のソフトウェア」とのギャップを「技術的負債」と呼ぶ このよう
リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog
皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの
ホクソエムサポーターの白井です。 今回は Matthew McAteer氏によるブログ記事Nitpicking Machine Learning Technical Debtの和訳を紹介します。 原著者の許可取得済みです。 Thank you! アメリカの国内ネタも含んでいて、日本語だと理解しにくい箇所もありますが、機械学習の技術的負債をどう対処していくかについて、とても役に立つ記事だと思います。 Nitpicking Machine Learning Technical Debt (機械学習の技術的負債の重箱の隅をつつく) イントロダクション Part1 技術的負債はあなたの予想以上に悪い Part2 機械学習の漠然とした性質 Part3 (通常の依存関係の頂上にある) データ依存関係 Part4 イライラさせるほど未定義なフィードバックループ 後編に続きます Nitpicking Ma
2019年6月20日、TECH PLAY SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。（※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席）。公開Q&Aには、メドピア株式会社執行役員のCTO福村彰展氏と、Sansan株式会社CTOの藤倉成太氏が登場。会場からの質問に回答します。 技術的負債を返す重要性をどう説明するか 司会者：お待たせしました。Q＆Aなんですけど、最初に、みなさん申し込みいただいたときに質問をいくつかいただいていたと思うので、そのなかで質問が多かったものを私のほうで5つぐらい取り上げさせていただいております。そのあと、会場のみなさんから質問を募集して、ディスカッションのようなかたちで進められれ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クソコード動画「Userクラス」で考える技術的負債解消の観点
「技術的負債」への処方箋と「２つのDX」 - Qiita
技術的負債とステークホルダと説明責任と / The Debt
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
技術的負債は開発者体験を悪化させる - mtx2s’s blog
業務委託テックリードと技術的負債 - LIVESENSE ENGINEER BLOG
財務諸表というフレームワークで考えるソフトウェア開発と技術的負債｜Yoshinobu Wakamatsu
失敗から学ぶ 技術的負債との正しい歩き方 / learn from predecessors
ライブドアブログが15年かけて積み上げた技術的負債への挑戦––LINEのブログサービスのエンジニアが明かす、光と影
ベロシティを上手く使って 技術的負債を計画的に解消する
技術的負債による年12兆円以上の経済的損失改善のために 『良いコード/悪いコードで学ぶ設計入門』の著者が願う 「設計が当たり前の世界」
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
ユーザー企業のOracle技術者が足りない、高まる技術的負債のリスク
「『50%の時間を技術的負債返済に』はぜんぜん駄目だった」 カミナシ社・原トリ氏が語る、試行錯誤の過程
GMOペパボ柴田博志が教える。経営者も理解しておくべき「技術的負債」 - FLEXY（フレキシー）
スタメンの技術的負債解消戦略 - stmn tech blog
技術的負債が生まれる背景を理解して，アーリーからレイター向けの根本的なアプローチを考える
組織の技術的負債の返済はなぜ進まないのか？ “工数確保の合意”に関わる意思決定層と現場視点の違い
「0→1」フェーズにおける技術的負債との向き合い方 - jmblog.jp
【翻訳】機械学習の技術的負債の重箱の隅をつつく (前編) - 株式会社ホクソエムのブログ
技術的負債の上手な積み上げ方・返し方