【翻訳】技術的負債という概念の生みの親 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 と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
フロントエンドの開発体験向上と脱レガシー - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。フロントエンドエキスパートチームの@nakajmgです。 私が所属しているフロントエンドエキスパートチームは、プロダクトのフロントエンドを横断的に支援するチームです。今回はフロントエンドエキスパートチームが行っている、プロダクトへの支援活動について紹介します。 フロントエンドエキスパートチームがどういったチームかに関しては、次の記事をご覧ください。 サイボウズのフロントエンドエキスパートチームの紹介 フロントエンドエキスパートチームの活動 サイボウズは主力プロダクトとしてGaroonとkintoneを提供しています。この 2 つのプロダクトはそれぞれ提供開始の時期が 2002 年と 2011 年となっており、浅くない歴史を持っています。 サイボウズの Web フロントエンドは、フロントエンド専任ではないエンジニアがバックエンドと合わせて担当しています。そうした背景もあり、フロン
GMOペパボ柴田博志が教える。経営者も理解しておくべき「技術的負債」 - FLEXY（フレキシー）
GMOペパボ株式会社で執行役員 技術部長 兼 VPoE（VP of Engineering）を務める柴田博志（@hsbt）と申します。CTOの栗林健太郎さん（@kentaro）と共にGMOペパボのエンジニアをまとめています。 技術的負債、どこの組織にもありますよね。どうやって返済していますか？ 会社として技術的負債にどう立ち向かうべきか、そのコツは人のマネジメントにあると考えています。今回はflexy読者の皆様と技術的負債を考えていこうと思います。 技術的負債とは： 技術的負債とは、開発の中で先送りにされる、ドキュメンテーション不足、保守コストのかかるテストコードや不必要に複雑なコードなどを指します。技術的負債が蓄積してしまうと、将来的に重大な問題を引き起こしたり、対応コストが雪だるま式に増えてしまいます。すべてのコードに技術的負債が発生する可能性があり、組織はどこかのタイミングで技術的負
老朽化ソフトウェアの技術的な負債、毎年１２兆円の衝撃｜広木大地（日本CTO協会理事/レクター取締役）
毎年オリンピック4回分の失敗。 これはなんだとおもいますか。経産省の発表した調査「DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」によると、2025年以降に作りっぱなしでメンテナンスできなくなってしまったソフトウェア(レガシーソフトウェア）が与える経済的な損失金額が毎年１２兆円に及ぶそうです。 これを予算総額が３兆円に達したと言われる東京オリンピックに換算すると、４回分。それが毎年です。 2025年以降の話ですから、まだ先の話じゃないかと思うかもしれないんですが、2018年現在時点でも毎年４兆円くらいの損失になるそうです。 これって結構な衝撃だと思いませんか。オリンピックの予算については、当然公費が使われるのもありますから、話題になるのもわかります。でも、少なくとも３兆円全部が無駄になるというわけじゃないでしょう。 毎年、４回オリンピックが全部失敗に終わってたら、
リファクタリング、リアーキテクティング、ビック・リライトの選択〜技術的負債とダンスを(4)
Many teams miss opportunities for refactoring by not realizing the different ways refactoring can fit into their… 『レガシーソフトウェア改善ガイド』では、リファクタリングを実施する際に、安全なステップで行う規律の大切さを先に言及しています。規律あるリファクタリングは、例えば次です。 依存関係をグラフ化して修正の影響範囲を理解するカバレッジ結果を参考に安全にリファクタリングできるコードか否かの判断する書籍『リファクタリング』のように小さなリファクタリングの連続のステップで理想のコードに近づく活動をこまめに継続する（長時間に動作しない状態は避ける）テストを使って外部振る舞いが壊れていないことを頻繁に確認する壊れたらすぐに戻れるようにバージョン管理システムを活用するIDEのリファクタ
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
あなたの会社は本当に機械学習を導入すべきなのか？ - bohemia日記
こんにちは。ぼへみあです。 こんな記事を読みました。 japan.zdnet.com よくあることだと思いますが、上から降ってきた機械学習プロジェクトは99%失敗し、導入したとしても技術的負債という形でエンジニアを苦しめることになるので、やらないほうがいいと思います。 僕は普段から、ディープラーニング面白しれー、機械学習サイコーと世に広めてしまっているのですが、 こちらの講演を聞き、機械学習をシステムに組み込んで運用する際に、普通のシステム以上に技術的負債が発生しやすく、どの企業でも気軽に導入を進めるべきでないと思いましたので、今の考えをまとめてみました。 ディープラーニング、実サービスへの導入の実際 〜niconicoにおけるレコメンド、コメント解析、画像解析〜 | Peatix 機械学習は技術的負債の高利子クレジットカード 近年高い成果を上げ、ブームになっている機械学習を導入したいと考
技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD
レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
技術的負債を抱えた状態で技術者がすべきこと - sandbox
この Qiita のエントリに触発され、元文章の目的はさておき、技術的負債についての自分の考えを書いてみようと思う。 技術的負債の定義や、問題は下記エントリを参照して頂くとして、なかでも最後の「技術者がすべきこと」について、「自分だったらこの様にアプローチするか」ということを書く。 技術者がすべきこと 大前提 開発前にステークホルダー(ここではプロジェクトの責任者とする)に、プロジェクトの性質として何を重視するかを認識、選択してもらう。 短期的な価値実現を最優先とし、初速を重視、ソフトウェアの健全さ、プロダクトの成長速度を犠牲にする 長期的な価値実現を最優先とし、ソフトウェアの健全さ、プロダクトの成長速度を重視し、初速を犠牲にする 1 を選択するという事について、健全でない状態や、成長速度が犠牲になった状態がどの様なものかを、プロジェクトが走り出す前に十分に認識してもらう必要がある。 …と
技術的負債 - Qiita
この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債という比喩で表していている。 たとえば、省略可能なプロセスを飛ばす事で開発の高速化を行う事があり、初期開発を高速に行う開発者の中には意識的・無意識的問わずこれを行っている事例が多々存在する。このようにして抱えられた技術的負債は長期的に見た場合に問題を引き起こ
朝Lint活動で細かな技術的負債を返済する - クックパッド開発者ブログ
買物情報事業部の八木です。クックパッド特売情報のAndroid部分を担当しています。普段はクックパッドのAndroid版（以後、本体アプリとします）の開発プロセスの中で特売情報の機能を開発しています。 本エントリでは細かな技術的負債を解消する為に本体アプリの開発チームが行っている朝Lint活動を紹介します。 2年近く経つ本体アプリのコードベース 私が買物情報事業部に所属する前は本体アプリを1から書き直すチームで働いていました。書き直し始めたのは2013年10月からなのでそろそろ2年が経とうとしています。2年前に設計された本体アプリは現在ではおよそ17万行を越え、日々どんどん変更が加えられています。 それらの変更の中には残念ながら悪いコードが含まれている場合があります。テストしづらいコードやテストがないコード、レビューに対する場当たりな対応や緊急のbug fixのために追加された汚いコード、
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
技術的負債の把握と改善を促すために - mixi engineer blog
こんにちは. 先日水道を止められて水のありがたみを再確認したgoccyこと五嶋@たんぽぽグループです. 今回は, 先日q_zouさんから紹介のあった技術的負債を減らす取り組みの一環で, 僕が開発したビジュアライザについてご紹介させて頂きます. はじめに 弊社では主な開発言語としてPerlを採用しており, そのソースコード量は数十万行単位に上ります. 自社で開発したライブラリ群はプロジェクトルート下のlib/Mixi/配下に設置されており, 更にその下でサービスや用途毎にNamespaceが分かれています(lib/Mixi/APIやlib/Mixi/Photo, lib/Mixi/Voiceなど). ※以降, 文章中のNamespaceという表現は, これら(lib/Mixi/APIなど)を指すものとします. 本来であればNamespace単位で疎結合化されているべきですが, なかなかうまく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債を "なるべく" 作らないためのコツ / Organization Performance Tips
技術的負債と向き合う