
この記事は、著者の許可を得て配信しています。 https://understandlegacycode.com/blog/5-arguments-to-make-managers-care-about-technical-debt/
経営陣はレガシーコードをリファクタリングさせません!
あなたは自分の現在の状況を把握できていますか?すごくイライラする状況にいるのではないでしょうか。
開発者として、すでに問題が出ている点を修正することに興味がないマネージャーはたくさんいます。
新機能、緊急リリース、バグの修正…そのめちゃくちゃになっているコードベースのリファクタリングを先延ばしに言い訳はいくらでもあります 😭
正しいコードのメリットを説明しても、理解を示したり、気にかけようとしたりするマネージャーは多くはいません。マネージャーは、品質ではなく常にコストと時間を優先しているからです。そして、蓄積された技術的負債に対応することは無意味なことだと思っています。
ITは、せっかちな顧客向けに本番稼働サポートを行っているんだ
クライアントはリファクタリングの費用を支払わない
そんなものは、無駄な努力だ
こういう状況から、優秀な開発者はさっさと手を引き、会社を去っていきました。会社は回転ドアのように、開発者が常に入れ代わり立ち代わり…
悪いコード品質がビジネスに影響を与えることがあるということを管理者が理解できるようにしなければいけません。
最終的に、会社にとって重要なのはお金を生み出すことです。つまりは、収益性です。経営陣は、コストを削減して収益を上げるために最善の決断を行う必要があります。
したがって、リファクタリングを主張したい場合は、ビジネスに関連した言葉使うということを学ぶ必要があるのです。
私は以前コンサルタントや技術リーダーを務めたので、こういう事態にはとても慣れています。今日は、みなさんに私の経験してきたことを共有できればと思っています😉
この言葉はJ. B. Rainsberge氏の素晴らしい講演「ソフトウェア設計の経済学」から引用したものです。
そんな簡単な事、知っているからって立ち去らないでください! すでに知っていることを言うのは何気に賢く聞こえるものですよね。
詳しく見ていきましょう:
・これまでのところ「リファクタリングは削減する」となっていて上手くいっている
・「~の中のボラティリティ」とは「~の不確実性」という意味だ
・「限界費用」とは、「さらに1ユニット生産するのにどれだけ費用がかかるか」ということである
・「機能」はビジネス上の価値である! みんながビジネスにおける価値に関心を持っているはずだ。
要点をまとめると、5つの議論を要約したものとなります。これは、私たちが技術に詳しくない人々と話すときに見落としがちな論点です。
相手の言葉で話す
専門的な言葉を使わないようにすることが大事なのです。経済学とビジネスについて話すのがコツですね!
マネージャーとつながりをもつようにするのも大切です。
以上のことを念頭において、さきほどの話をマネージャーとしてみるとよいでしょう。どうなるか、察しがつくはずですね。
自分の主張をさらに上手にアピールするために、さらに2つのコツがあります。
数字をあなたの現実に当てはめてみましょう。
ここでのポイントは、実際にデータを見せて自分の主張をより強力に裏付けすることです。この技術的な負債はあなたの毎日の仕事に影響を与えているのです。それを証明することはできるのでしょうか?
もちろん可能です!
こちらに例をいくつか出しておきましょう:
・時間の経過に伴うベロシティ(速度)。スプリントごとに何ポイントしているのか? ポイントは減っていくのか?
・1週間に報告されるバグの数。 1週間に修正されたバグの数。 バグは蓄積しているのだろうか? バグ修正に多くの時間を費やしているのではないか?
・1週間に発生する緊急事態の数を追跡する。それは持続可能なのだろうか?数は増えているかどうか?
経営者にコストパフォーマンスが悪いということをこのように具体的に話せばよいのです。
おまけ:これらの数字を実際のお金に関連付けることも大事💰
ある日、私は静的型チェックで防ぐことができたバグの事後分析に出席しました。そこで使用されていたコードはJavaScriptでした。 会社でTypeScriptを導入するにあたってはずっと議論がなされていました。
事後分析を行っている開発者はそれについてより深く掘り下げ、そのバグの影響のおかげでビジネス上の損失をそこまで多く被ることがありませんでした。
そのバグに対し、数か月の間に100万カナダドルもの費用がかかったのです。1M $ CAD💥
それだけで、TypeScriptに投資する価値があるでしょう。
そのため、新しいサービスがTypeScriptに実装され、重要なサービスが型チェックで再検討されることが決定されたのです。
大事なので、もう一度言っておきます。彼らが理解できる言葉で話をするのです。
比喩は、メッセージを伝えるのに非常に効率的です。その人が知っている何かに関連付けることで、その人がよく知らない概念を理解しやすくするからです。
マネージャーは「ローン」に関してはよく知っているはずですし、「技術的負債」も有名な比喩です。
また、会社をレストラン、コードベースをキッチンと例えることもできる。皿を積み上げていくと、ますます多くのクライアントに対応するのがますます難しくなる。スタッフはあなたが行けば、すぐに皿を洗い始めないといけない。

質の悪い直接的なコストについて話をしました。
一見気づきにくいが、とても影響力の高いもの、それは転職率。
近年、企業が開発者を確保しておくことが難しくなってきています。 特に有能な開発者の確保はとても困難です。やる気がなくなってきた時に、別の会社からオファーが来たら、今の会社をすぐに辞めてしまうというのもあります。大変な仕事から逃れるためです。
そこのあなた!あなたも大変な職場から逃れてもっと快適な職場で働きたいとおもっているのではないでしょうか?
さて、では質問です:
「退職した開発者のポジションを埋めるために、また新しい人材を採用するにはどれくらいの費用がかかるのでしょうか?」
新しい人材の求人を出し、採用し、研修をしなければいけません。 それにはお金と時間がかかり、そのためチームの作業が遅延するということも想定できます。
あなたのマネージャーは、毎年新しい開発者を雇いたいとは思っていないはずです。離職率を下げるためには、まず議論が必要です。さらに、技術的な負債に取り組むために計画を立てることで、チームのやる気は高まっているはずです。
FRTとはとは初回レスポンス時間のことで、カスタマーキーメトリックです。
一番大切なのは、何よりも顧客の満足を保つことです。
そのポイントは次です。
・カスタマーサポート部門にとって重要なメトリックを取得する
・繰り返し発生する問題や、開発者が対処する必要がある問題を特定する
・根本的な問題に取り組むことで、サポート関連の問題の数を減らす計画を立てる
こういった問題を解決することにより、開発者はカスタマーサポートに充てる時間を短縮できます。 それは投資した時間の埋め合わせになるのです。つまりは、前向きな投資収益率といえます。
しかし、最後に彼らは決めました(おまけのアドバイス)
ですよね?
さて、技術的な負債に対応する重要性を裏付ける役立つ5つの論点を上に挙げました。
しかし、マネージャーと話をする前に、最後のおまけのアドバイスを1つお教えしましょう。
とにかくいつでもリファクタリングする。
リファクタリングは、機能の実装から独立した手順ではありません。 実際、次の機能がどうなるかは予想できません。 したがって、コードをリファクタリングして、新しい現実に適応させる必要があります。
それをするのはあなたの仕事のです。
プロの開発者として、あなたはビジネスにおける価値を常に創出し続けるために必要なものを知っているはずです。
これは、レガシーコードベースでも有効です。確かにそうでうね。明日は素晴らしい日にはならないでしょう。 また、大規模なリファクタリングに「いつでも」取り組むことはできません。 しかし、少なくともこれ以上、悪くなることはありません。
レガシコード関連の作業というものは、さらに良くする作業なのです。
バグを修正するたびに、自動テストを書くためにさらに1時間を使います。 すべての機能で、コードをきれいにするために丸一日を費やします。 変更をより簡単にできるようにしましょう。 毎日実施することで、 数か月後には、この習慣が生産性に大きな影響を与えるでしょう。
その理由をご存知ですか?
その理由は「そういった利益は、機能の限界コストの変動を減らすためにどんどん増えていく」からです! 😉

DevelopersIO / 2時間前

TechCrunch Japan / 2時間前

CNET Japan / 3時間前
![[小ネタ]AWS CLIを使ってAWS BakcupでEC2のバックアップを取得してみる | Developers.IO](https://s3-ap-northeast-1.amazonaws.com/raptor-photo-production/news_resource/138775/thumbnail_image/aws-backup.png)
DevelopersIO / 4時間前

DevelopersIO / 4時間前

TechCrunch Japan / 5時間前

TechCrunch Japan / 5時間前

TechCrunch Japan / 6時間前

ITmedia / 7時間前

TechCrunch Japan / 8時間前

TechCrunch Japan / 8時間前

ITmedia / 8時間前

TechCrunch Japan / 8時間前

TechCrunch Japan / 10時間前

ITmedia / 10時間前

TechCrunch Japan / 10時間前

TechCrunch Japan / 10時間前
![[ブックレビュー]小さいからこそ使いこなせる--「時間をもっと大切にするための小さいノート活用術」](https://s3-ap-northeast-1.amazonaws.com/raptor-photo-production/news_resource/138703/thumbnail_image/200218_chiisana_640.jpg)
CNET Japan / 10時間前

TechCrunch Japan / 10時間前

ITmedia / 10時間前