エグゼクティブが機能を必要とするとき、技術的負債を管理する
ヘイデン・バイリオ
そう。
ヘイデン・バイリオ
見てみよう。
Hayden Baillio
我々はライブで、ここで人々を待っている。
Kelvin Del Monte
皆さん、ようこそ。
ヘイデン・バイリオ
そう、みんなと会うのが大変なんだ。もしチャットにいたら、よろしくね。
ヘイデン・バイリオ
ハウディを投げ、ハローを投げる。
ただ、僕に何かを投げつけたりしないでくれよ？
Kelvin Del Monte
You
ハッピー・ウェンズデー。ハッピー・ハンプ・デイ。
ヘイデン・バイリオ
そうだ。
ヘイデン・バイリオ
さてさて、こうなった。
ヘイデン・バイリオ
さて、そろそろ始めようか。
Kelvin Del Monte
いいかい？いいよ
Hayden Baillio
ちょうどあなたがフロントとセンターであることを確認するつもりです。カルヴィンから私へ、あなたと私の友人センターへ、それとも今、あなたは友人ですか？
ケルビン・デルモンテ
私たち2人は同じようにフロントとセンターだ。
ヘイデン・バイリオ
平等にフロントとセンター。そうあるべきだよし、完璧だ。
さてさて、お待たせしました。この素晴らしい、素晴らしいウェビナーにご参加いただきありがとうございます！経営幹部が新機能を必要とするときの技術的負債の管理についてお話しします。本題に入ります。30分しかありませんので、今日のスピーカーを紹介します。皆さん、彼は技術界で最も滑らかな声と、技術的負債を説明する稀有な能力の両方を持っているかもしれません。
エグゼクティブを泣かせることなく。HeroDevsのソリューション・アーキテクトとして、彼はレガシーシステムを最先端のプラットフォームへと変換し、技術的負債を消滅させることで解決する手助けをすることにキャリアを費やした。というのは冗談だ。HeroDevsがソフトウェアのライフサイクル管理においてどのような位置づけにあるのか。
そして今日、彼はあなたのコードベースが、前回の家族の集まりの折りたたみテーブルのように崩壊することなく、機能を出荷する方法を紹介する。技術的負債管理のASMRの声をお聞かせください。カルヴィン・デルモンテです。参加ありがとう。カルヴィン、もういいよ。君のせいだすべて君なんだ。
Kelvin Del Monte
ありがとうございました。
Kelvin Del Monte
ありがとうございました。ありがとう。ありがとう、ヘイデン。それでは。では、みなさんを歓迎したいと思います。お集まりいただきありがとうございます。このウェビナーは録画されていますので、後でご覧になる方もいらっしゃると思いますが、この美しい水曜日にようこそ。技術的負債について話しましょう。始める前に、まず自己紹介をしたいと思います。私はケルビン・デルモンテです。Hero Devsのソリューション・エンジニアです。2008年からソフトウェア・エンジニアをしています。
このキャリアの中で、私はいくつかのエンジニアリング・チームを率い、管理する機会にも恵まれました。今日お話しすることは、私の個人的な経験からのものです。私は大企業、中小企業、新興企業など、あらゆる種類の組織で働いた。技術的負債に関しては、その過程で多くのことを学んだ。そして、皆さんと分かち合いたいと思います。まず、技術的負債とは何なのか？
そして、これが技術的な死というものだ。これは一般的な表現で、ミームとして広まっているんだけど、僕はそれがすごく面白いんだ。そうだね。
ヘイデン・バイリオ
ケルビン、すまない。まだプレゼンを共有していないようですね。大丈夫です。テクニカルグレムリン。これはシリーズの最初のものです。
Kelvin Del Monte
すみません、すみません。ありがとう。ありがとうございます。ええ、実はそうさせてください。ええ、問題ありません。これで見られるはずです。
ヘイデン・バイリオ
そうだ。
Kelvin Del Monte
完璧。そうだね。それで、まず最初に...さっきはこのミームをお見せできませんでしたが、これは技術的負債がどのようなものかを表した超人気のミームです。こんな感じだけど...
いつもこうだとは限らない。家がこんな風にボロボロで、上司が新しい窓を付けられるかどうか聞いてくるわけじゃない。家がこんな風に壊れているのに、どうやって窓を追加するんだ？でも確かにこんな感じだ。これについては、今後のスライドでもう少し詳しく説明するつもりだ。技術的負債とは何かという話に入る前に、私たちは本当に...
テクニカルデット（技術的負債）という言葉は、1992年、私が3歳のときに、彼が金融商品を作っているときにこの比喩を使った。
彼はこの比喩を使って、チームがこのソフトウェア、つまりYcashのソフトウェアを作り続ける中で経験したことを上司に説明した。開発が進むにつれて、彼らのシステムに対する理解や、自分たちが構築しているシステムや構築方法に対する彼ら自身の意見も進化していった。
だから、ある方法で作り始めたんだ。そして時間が経つにつれて、彼らは新しいパラダイムや新しいパターンを見つけ、それがより有用で、彼らがやっている仕事のタイプに合っていると思うようになった。つまり、時間が進むにつれて、彼らがコードを書いたりアプリケーションをセットアップしたりしたその時点では、彼らにとって最適だった決定が、最適な決定だったということになる。
ケルビン・デルモンテ
6カ月先の未来、1年先の未来、彼らは人間として、エンジニアとして進化し、ソフトウェアも進化し、共同作業の方法も進化している。新しいツールが導入されているかもしれない。この間に起こりうることは山ほどある。そして彼らは、過去に自分たちが作ったコードに目を向けるような状況に陥った。
そして、彼らは進化していた。そのコードは、彼らが今どのように物事を構築しているのか、もはや標準には見えなくなっていた。小さなチームがソフトウェアに取り組んでいる。コードは変わっていなかった。彼らは変わった。彼らの意見が変わった。これが技術的負債という言葉を生み出した。チームが過去に書いた古いコードをさかのぼってやりとりしているようなものだから、と彼は説明した、
カニンガム氏が上司に説明したところによると、彼らはこのコードとやりとりしているときに速度低下を経験した。これが技術的負債というものだ。さて、ここで少しこのことを振り返ってみたいと思います。技術的負債の原型は何だったのでしょうか？それは意見だった。
そして、チームの理解も進化している。技術的負債について考えるなら、それは今も昔も変わっていないからだ。
強力な比喩だ。30年経っても、33年経っても、人々はそれを使っている。私たちは今日もその話をしている。超強力だ。そして、それは多くの意見と関係している。ご存知のように、意見は変わるものだ。そして誰もが1つは持っている。だから、私たちはそのことを心に留めておく必要がある。技術的負債というのは、ソフトウェアを作るのに何がベストなアプローチなのかという意見に基づいている。
Kelvin Del Monte
では、何が技術的負債を引き起こすのだろうか？技術的負債とは、今お話ししたように、チームメンバーの理解が深まることです。これらのどれでもあり得る。学習が進むにつれて、以前の選択が意味をなさなくなったり、今の選択より意味がなくなったりする。短期的な決断。プロジェクトを立ち上げようとしていて、もしかしたら時間に追われているかもしれない。十分な時間がない。
そして、先のことを十分に考えたり、少し先を見通したり、先の計画を立てたりすることができない。だから、短期的な決断ばかりして、それが蓄積されていく。そうしているうちに、技術的負債が蓄積されていく。また、アーキテクチャの選択が不適切な場合もあり、これは経験不足や...
アーキテクチャを選択し、アプリ全体が大きな技術的負債のようなものである場合、非常によくあることだ。また、あちこちに乱雑なコードがあり、さまざまな貢献者から生まれたパターンが出たり入ったりしている。重複していたり、テストがないこともある。これも技術的負債だ。それが技術的負債を生む。チームの変化。大きな、大きな。
技術的負債の発生を考慮しなければならない。例えば、あなたがプロダクトオーナーまたはステークホルダーで、5年間何の変更もなく一緒に仕事をしてきた開発者チームがあるとします。例えば、あなたがプロダクトオーナーやステークホルダーで、5年間何の変更もなく一緒に仕事をしてきた開発者チームがいるとしよう。彼らは自分たちのプロジェクトに技術的負債があるとは思っていないかもしれない。
しかし、たまたま何人かのエンジニアが去り、他の環境から来たエンジニアが加わることになる。そして彼らにとっては、繰り返しになりますが、それは非常に意見に基づくものなのです。彼らには、技術的な負債が山ほどあり、それが彼らの口から出てくるのです。この技術的負債は実際の技術的負債かもしれないし、彼らの意見かもしれない。根拠がない。後で少しお話しますが、実際の証拠もありません。
Kelvin Del Monte
そしてもちろん、要求の変更は非常によくあることだ。開発者は同じコードを何度も何度も変更して機能を拡張したり、以前の実装を壊さずに機能を少し変更したりする。そして、それは非常に速いスピードで進行する。そのため、このコードの一部で反復が行われているとき、これもまた短期的な決断に結びついている。多くの決断はその場で下される。
そしてそれが技術的負債につながる。技術的負債とは、自然に発生するものだ。つまり、これについてはすでに話したとおりだ。技術的負債とは進化なんだ。つまり、前進するにつれて技術的負債が蓄積されていくのです。人間やAIによって作られたプロジェクトで、ある種の技術的負債を抱えないものは地球上に存在しないし、今後も存在しないだろう。
では、これはあなたにどのような影響を与えるのだろうか？技術的負債は、プロジェクトや組織、製品にさまざまな影響を与える。セキュリティに関して言えば、スパゲッティ・コードや適切にメンテナンスされていないコードのどこかに、あなたが知らない脆弱性が潜んでいる可能性がある。
また、最大の不満のひとつであるベロシティーの問題もあります。実はこの言葉はベロシティの問題から生まれた造語なんですね。カニンガム氏は上司に、この古いコードとやりとりするたびにスピードが落ちるんだ、と説明したそうです。あなたのチームはエンジニアリング・チームです。
スピードが落ちるのは、保守の仕方がよくわからない、あるいは保守が難しいと思っている古いコードとやりとりしなければならないからだ。そしてこれは、次のポイントに完璧に結びつきますが、開発者の士気を低下させますよね？私は、アプリケーション全体が死んでしまったかのような環境にいることがあります。そして、変更を加えることを恐れてしまうのです。なぜなら、バグを引き起こしてしまい、そのバグが原因で生産上の問題が発生し、会社が損失を被る可能性があるからです。
ケルビン・デルモンテ
、そのような環境から抜け出せないのは、非常にストレスがたまるからだ。正直なところ、人生は短いのだから、良い仕事をしたいし、それほどストレスを感じなくてもすむようにしたいものだ。
ビジネス・リーダーは、技術的負債を単なるエンジニアリング上の懸念ではなく、デリバリー・リスクとして捉えるべきだ。これは、どのように賛同を得るかの一部であり、今後のスライドで少しお話しします。
ヘイデン・バイリオ
Hayden Baillio
ケルヴィン、その言葉大好きだよ。私もその言葉が大好きです。というのも、多くのエンジニアと話をすることがあるのですが、そのエンジニアたちは、自分の部署のビジネスリーダーと話をしなければならないような気がするのです。それがもっと大きな問題であるときはいつでも、解決してくれ。この古いソフトウェアや技術的負債が、より良い製品や体験、ソリューションを提供するのを妨げているんだ。私はこの言葉がとても気に入りました。素晴らしい。もっと大きな問題です。技術的負債とは、エンジニアリング部門だけの問題ではありません。私はそれが好きです。
Kelvin Del Monte
100 % 100 % Cレベルの人たちや経営幹部に理解してもらうのは難しいこともある。私たちは私たちを助けようとしているんだ。
そして次のスライドは、私が持っているもう一つのミームで、開発者のモラルに関連するものです。つまり、技術的負債を抱えたまま会社を去っていくエンジニアがいるということです。私はこのようなことを何度も何度も見てきました。おかしなことに、その技術的負債を作った人が
技術的負債の大半は、技術的負債が実際に残っているチームの全員を殺している間に、家からつま先立ちで逃げ出すようなものだ。技術的負債ではなく、技術的負債である。
ヘイデン・バイリオ
すごい。
Kelvin Del Monte
そう、よくあることなんだ。そうなんです。そして、それが原因で会社やチームから人が離れていく。では、どうすればいいのでしょうか？これは明らかな問題です。会社、製品、従業員、チームとしての士気に悪影響を及ぼします。そこで、よくある落とし穴をいくつか紹介したいと思います。基本的に、やってはいけないことから始めましょう。これらは私が過去にやってしまったことです。
そして、こういうことをやろうとすると、おそらく間違った方向に進んでしまうので、決してやらないようにという注意を促したい。つまり、技術的負債を反応的に修正するだけなのだ。これは非常にナイーブなアプローチで、チームに言うようなアプローチだ。キャリアを積めば、いつかは耳にすることになるだろう。ある人はこう言うだろう。
あるいは、もしあなたがファイルの中にいて、そのファイルにここで問題になっている債務の一部が含まれているのであれば、先に進んで修正してください。いや、これはうまくいかない。多くの問題がある。実際に取り組んでいることの範囲に影響する。
そのため、タイムラインを見逃してしまう可能性がある。スコープを汚してしまう。それは絶対に避けたいことだ。アジャイルに従うなら、スコープをきちんとタイトにして、技術的負債を抱えないようにしたい。
ファイルを開いたり、コードのあるセクションで作業しているときは、いつでもここにアップされる。だから、これはやってはいけないことなんだ。先手先手で対処したいものだ。まずそれを特定し、計画を立て、そして実際にそれを特定し、書き出し、チームメンバーの賛同を得る。
ケルビン・デルモンテ
そして、決して反応的にやらないというのは悪いアプローチだ。次に、可視性がないことです。もしあなたがリアクティブにやっているなら、これも問題です。あなたが知っているのは、あなたのコードをレビューした人だけで、その人はこの問題があって修正されたことを知っています。あなたのチームはそれを知らない。追跡する方法もない。つまり、可視性がなく、優先順位もない。
これもやってはいけないことだ。そしてここに、絶対にやってはいけないことの王様がいる。大規模なリファクタリングに過剰にコミットすることだ。私は過去にこれをやったことがある。特にキャリアをスタートさせたばかりの頃は、経験も浅く、情熱的だったと言うべきだろう。もっと、そして間違いなくもっとナイーブだった。
最新技術を使いたかったし、できるだけ早くそれをやりたかった。ビジネスのことはあまり考えずにね。これが重要なのだ。あなたが考えているのは、この大規模なリファクタリングではありません。この大規模なリファクタリングは、仮にあなたが成功したとしましょう。
失敗する可能性の方がはるかに大きい。そして、将来あなたが行うかもしれない大規模なリファクタリングについて、あなたを支持している人たちでさえ、この大規模なリファクタリングの途中のどこかで、日々の生活が本当に嫌になったとき、彼らはあなたを支持したことを忘れてしまうだろう。イスラエルがエジプトを去り、エジプトは素晴らしかったと振り返るようなものだ。
もちろん、砂漠の真ん中で、死にそうになって、水も見つからない。もちろん、振り返ればエジプトは信じられないような場所だっただろう？しかし、これこそまさに起こることだ。あまりにひどすぎる。なぜなら、この大規模なリファクタリングに全員がコミットしているからだ。
Kelvin Del Monte
おそらく、つまり、すべての確率はあなたに不利で、あなたがこの大規模なリファクタリングを引き起こした1人だったという立場にあなたを導く可能性が高い。そして、たとえそれを逃したとしても、それは大きな成果だ。たった2日か3日の差でそれを逃した。あなたは、皆が苦しみすぎてビジネスが危機に瀕し、それがすべてあなたや、この大規模なリファクタリングを支援した人のせいだという立場にいるのです。それは進むべき道ではない。
本当に。そして、もし万が一、あなたのチームにとって、この方法しか実行可能な方法がないのだとしたら、それにはとてもとても正当な理由があるはずだ。たいていの場合、このような進め方は間違っている。これは私のキャリアから学んだことだ。地獄への道は善意で舗装されている。あなたはこのリファクタリングに対して最高の意図を持っているかもしれない。
しかし聞いてほしい、これはあなたや最新技術を使いたがっている友人の話ではない。あなたのチームの問題なのだ。前進する前にコンセンサスを得なければならないということだ。自分の善意だけでなく、皆が納得し、同意する方法で物事を進めるようにしなければならない。そうすれば、とんでもない道を歩むことになる。
さて、では次に、効果のある戦術について。私はこれらを試してみたが、見事にうまくいった。今お話ししたことの逆のようなものです。詳しく説明するつもりだが、ここに列挙しておこう。深さの追跡、目に見える負債、見積もり、幹部の賛同、そして実行、これはこのライターのコンセプトだ。ちょっとニュアンスの違う実行の仕方だが、それについてはまた後で話そう。
必要であれば、外部の力を借りなければならない。それは恥ずかしいことではありません。実際、私たちの組織としては、これは従業員への特典のようなものです。それについても少しお話ししましょう。では、オーケー。目に見える形で負債を追跡するここに箇条書きにしてみました。だから、あなたは声を上げなければなりません。
ケルビン・デルモンテ
借金については、チーム全体に声を大にして伝えなければならない。チームが取り組むべきだと思うことがあれば、何でも話題にしなければならない。チーム・セッションでそれを提起してください。スタンドアップであれ、レトロスペクティブであれ、バックログ・グルーミングであれ、これらのことを言い始めることができる。ここで、あなたが...
そのようなことをいくつか口に出して、チームに知らせてほしい。これは冒頭の意見の要素につながる。あなたは「これはダメだ」という意見を持っているかもしれないが、他の同僚が「なぜこれはダメではないのか」説明してくれるかもしれないし、あなたがドキュメントのようなものを読んでいないかもしれない。もしかしたら、あなたはコードのこの部分や、なぜこのように書かれたのかをよく知らないかもしれない。それに...
あなたの人生を楽にする文書。もしかしたら、それは死んでいないかもしれない。だからまず、あなたのチームが死んだと信じている正式な負債が、死んだとマークできるものなのかどうか、コンセンサスを得る必要があるよね？
上達するために、この可視性を持つために、考えてみてほしい。ボードに書かなければならない。バックログのどこかになければならない。バックログ・グルーミング・セッションで議論されなければならない。エンジニアとして、PMとして、プロジェクトマネージャーとして、あるいはプログラムマネージャーとして、あなたは複数のプロジェクトに時間を費やしているかもしれない。
例えば、プロダクト・オーナーは、バックログツールやプロジェクト管理ツールを使っている。Jira、Santa、Trello、Monday、これらのツールのどれかだ。
Kelvin Del Monte
視認性が高い。実際、技術的負債が存在するのは、あなたが自分の仕事をし、自分の仕事を整理するためなのです。そのため、実際にどのような負債があるのかを文書化する際には、プロジェクト・マネージャーやテクニカル・リーダーと協力する必要がある。
もしそれが自分自身であるなら、PMと組んでこれらのことを記録し、実際に行動に移せるようにできる限りの情報を入れておくんだ。
一度にやる必要はないが、これがバックログ・グルーミングの目的だ。詳細を入力し、どんどんグルーミングしていく。行動可能なものにして、エピックを作るなどして分けてください。私は過去に、JIRAや他のツールでエピックを作成したことがあります。そしてそれは、永遠に続くエピックではありません。一つの問題を解決するための、限られたタスクしかないエピックです。
そのように扱うことができます。以前ラベルを使ったことがある、JIRAラベルを多用するような非常にラベルの多い環境では、どのような方法でも適切と思われる方法で整理されていることを確認してください。JIRAのラベルを多用する環境です。どのように整理するのが好きであれ、整理され、チームから見えるようにし、チームセッションに持ち込まれるようにしてください。可視性は死んでしまう。
を、実際に優先順位をつけて取り組めるものに変えるのだ。見えないものは直せない。見えないものは直せない。
Kelvin Del Monte
さて、まずコストの見積もりについて話そう。
ストーリー・ポイントを使ったり、他の見積もりをしたりすることもあるでしょうが、結局はコストに帰結しますよね？だからこれで、あなたが重要だと考えていて、チームのペースを落としているタスクを、あなたのエグゼクティブ・チームに提示することができます。経営幹部が気にかけていることを確認するのだ...
自分のやりたいことをやるのに、どれだけの実現可能性があるのか。彼らは数字で考えたいのだ。この負債について何か行動を起こすことに意味があるのかどうか、慎重に検討したいのだ。
あるいは、将来まで延期できるものなのか。時間的なものであれ、どのような見積もりであれ、経営陣が理解できるようなコストを提示したい。チームと協力し、プロジェクトマネージャーと協力して、技術的負債のストーリーを作成し、それに何らかの見積もりをつけるようにしたい。
そしてもちろん、技術的負債のエピソードやいくつかのエピソードを作成し、経営陣に提示することができます。そして、実際に作業を開始するための承認や、いつどのように作業を開始する余裕があるのかについてのガイダンスのようなものを得ることができる。ここに挙げた例をいくつか紹介しよう。
Kelvin Del Monte
このバグが存在するのは、これらのことが過去に私の身に起こったことだからだ。バグが発生したのは、ユニットテストがなかったからだ。私たちが求めていた、意図的なテストカバレッジがなかったんです。だから、それを彼らに伝えてください。技術的負債が、あなたやあなたの収益にどのような影響を及ぼしているのかを。そうすれば、彼らは技術的負債をもっともっと深刻に受け止めるようになるはずだ。
ということになる。この時点で、あなたは完全に実行可能な、コストが関連付けられたタスクのスタックを手に入れることができ、機能を出荷するよう依頼されている間、必要な経営幹部の賛同を得るのがずっと簡単になる。あなたの苦しみ、エンジニアリングの苦しみ、プロジェクト管理の苦しみを、彼らが理解できるように翻訳する必要がある。納品スピード、リスク、リスク、会社に利益をもたらす機能を出荷するリスク。
そして最後に、承認が得られたところで、実際にどのように実行し、前進すればいいのだろうか？あなたは経営陣から前進する承認を得た。しかし、その承認が緩かったかもしれない。彼らはあなたにガイダンスを与えず、あなたの好きなようにすることを許した。まあ、これは "しない "か "しない "かということにつながるんだけどね。
大規模なリファクタリングはしないこと。こうするんだ、ライター。高校時代、私はアメリカ政府、あるいは議会にはライターという概念があることを学んだ。ライターとは、通過しようとしている、あるいは多くの労力が費やされた大きな法案に添付される小さな法案のことだ。
そして、小さな負債が、時には大きな負債とは何の関係もない、小さな負債にくっついたりする。つまり、スプリントごとに数サイクルを予約するのだ。そうすることで、技術的負債を減らすと同時に、機能を提供し続けることができる。これができない場合もあることは承知している。できないかもしれないが、これが最適なアプローチのはずだ。
ケルビン・デルモンテ
少しずつ、つまり継続的に改善していく。時間が経てば、確実に100％複合的に改善されます。そして、それが6ヶ月でも1年でも、どんな時間であっても、あなたはその違いを目にすることになるでしょう。機能を提供し続けることで、アプリはより健全になります。そして誰もがハッピーになる。あなたはリーダーとして幸せです。あなたがリーダーとして、あるいはチームとして実際に行動を起こしているからこそ、チームもハッピーなのです。
そして当然、ステークホルダーは満足するだろう。
そこで最後の提案になるのですが、必要であれば外部の力を借りるということです。実は次のスライドで、私たちがやっていることを具体的にお話しするつもりですが、これが私たちの本業です。ですから、私たちのような会社に技術的負債を助けてもらうことができるのです。
あなたのチームが機能を出荷している間、私たちはそれに集中します。これは、大規模なアップグレードや、サポート依存地獄に陥っている場合、あるいは、他の技術や他の言語に深く書き換える必要がある場合などに非常に便利です。私たちがお手伝いしますし、外部の力を借りることもできます。会社からの特典のようなものですから、開発者の士気も高まります。あなたはエンジニアです。あなたはエンジニアです。
技術的な負債を解決するために、あなたの会社は外部の力を借りているのです。だから、スペシャリストを招聘することを常に考慮することが非常に重要なのだ。私たちHero Devsについて少しお話したいと思います。私たちは2018年に設立されました。
ケルビン・デルモンテ
フォーチュン500やフォーチュン100に名を連ねる企業から800社以上のお客様をお迎えしています。私たちは、サポートが終了したソフトウェアや、サポートが終了したソフトウェアを様々な形でサポートすることを専門としています。私たちには素晴らしいチームがあります。私たちは長い間、この仕事に携わってきました。私たちと一緒に仕事をしている企業をいくつか紹介しましょう。これは...
私の同僚が言うところの "気分のいいスライド "です。私たちは、これらすべての企業と協力し、移行を支援してきました。そしてもうひとつ、NES（ネバーエンディング・サポート）を通じて、これらの企業を支援する方法があります。
という製品ラインである。略してNESと呼んでいる。これは技術的負債を別の方法で解決するものです。例として、AngularJS Twangularマイグレーションを挙げたいと思います。多くのチームは、おそらく2010年にアプリを開発していたと思います、
2011年、あなたはおそらくAngularJSいただろう。しかし、あなたが製品を完成させた頃には、すでにAngular移行していました。だから、Angular移行するリソースがなかったのでしょう。ではどうするか？今度はサポートから抜け出せなくなります。終わりのないサポートは、移行をサポートすることはもちろんですが、実際に移行する必要はありません。
私たちは、ここに掲載されているライブラリやその他のライブラリのサポートを拡大していく予定です。私たちにご連絡いただければ、さらに多くのサポートをご提供できます。そうです、私たちは、お客様が使用しているソフトウェアやライブラリのサポートが終了しても、サポートを継続できるようお手伝いすることができます。また、技術的な負債を解消することもできます。つまり、使っている技術がサポート切れになってしまうということです。そう、私たちは...
Kelvin Del Monte
提供する商品を継続的に拡大し、ヘイデンが思うに、この1年でいくつの商品をリリースしただろうか？
Hayden Baillio
昨年は20以上のファミコン新製品をリリースしました。その多くが、私たちの顧客や、インターライフ・ライブラリーですでにお手伝いしている人たちが、私たちのところに来て、これにもサポートが必要だと言っているのを見るのは、とてもクールなことだと思います。と言ってくるのです。そのため、多くのビジネスや新製品の開発は、現在の顧客によって推進されています。
ああ、新しいニーズについてはいつでも聞く耳を持つよ。それは確かだ。
Kelvin Del Monte
ええ、多くの関心が寄せられています。もちろん、私が顧客としてHero Devsを訪れ、できない大規模な移行に直面しているのであれば、これは救世主です。そう、実際には何もする必要はない。耐用年数が終了しても、機能を出荷し続けることができます。ファミコンを購入した時点では、そのソフトはもう生産終了ではありませんから。
とにかく、最後のヒントと収穫だ。小さく始めて、技術的負債を見えるようにする。できる限りデリバリーに組み込むこと。必要であれば外部の助けを借りること。そして、負債ゼロを追い求めないこと。これは普通のことだ。これはソフトウェアを作る上で当たり前のことなのだ。常に存在する。ただ、それを管理すること。お時間をいただきありがとうございました。最後にヘイデンに引き継ぎます。
Hayden Baillio
ええ、いえ、本当にありがとう、ケルビン。概要を教えてくれてありがとう。技術的負債というのは、私たちが話をした人たち全員が間違いなく持っているもので、どこにでも蔓延していますよね。技術的負債から逃れることはできない。オープンソースを採用するということは、技術的負債を採用するということです。そういうものなんだ。将来の技術的負債を採用するようなものです。そして、あなたは実際に素晴らしい洞察をしてくれたと思います。この模様はYouTubeにアップする予定です。ご参加ありがとうございました。
もう7分過ぎましたので、質問をしたい方は、このウェビナーに招待してくださった方、あるいはケルヴィンさんにお願いします。ケルヴィン、この件に関して質問がある人が連絡しやすい場所はどこですか？
Kelvin Del Monte
現時点では、kelvin at herodevs.comまでメールしてください。喜んでお答えします。
Hayden Baillio
Herodotus.comのケルビンです。ありがとうございました。ありがとう、ケルビン。安全なところにいて、技術的負債にどう対処するか計画を立て始めてくれ。平和を、ヒーローたちを。
