経営者に技術的負債を処理するよう説得するにはどうすればよいですか？

これは、開発者と仕事をするときによく自問する質問です。私はこれまで4つの会社で働いてきましたが、コードをクリーンに保ち、ソフトウェアアプリの将来の進歩を妨げる技術的負債に対処することに注意が払われていないことに気付きました。たとえば、最初に勤務した会社は、MySQLのようなものを使用するのではなく、ゼロからデータベースを作成し、アプリケーションをリファクタリングまたは拡張するときにチームのために地獄を作りました。マネージャーが予測について議論するとき、私はいつもマネージャーに正直で明確にしようとしましたが、経営陣はすでにあるものを修正することに興味がないようで、チームの士気に与える影響を見るのは恐ろしいです。

この問題に取り組む最善の方法について、あなたはどう思いますか？私が見たのは、荷物をまとめて帰る人たちです。同社はその後、開発者が出入りしてコードを悪化させる回転ドアになります。これを経営者にどのように伝えて、技術的負債の整理に興味を持たせますか？

これを議論するために上司と会ったとき、彼はすべての見積もりにリファクタリングを含めるべきだと言った。彼はそれが彼が考えたい問題ではないと言った。代わりに、私はそれを処理する必要があります。

これは経営陣が一般的に考えたい問題ではありません。彼らはエンジニアではありません、あなたです。これをあなたのすべての見積りの暗黙の一部にすると、技術的な負債が減少することがわかります。

しかし、完璧になることはありません。クレジットカードの負債のような技術的な負債は、顧客をより速くし、競合他社よりも早く市場シェアを獲得するための投資です。クレジットと同様に、適切に管理すれば、かなり成功することができます。

彼の戦術がヒトラーのような人とうまくいくかどうか尋ねられたとき、ガンジーが言ったようです。彼は「難しいだろう」と言った。しかし、答えは本当に「いいえ」であるという公正な議論があると思います。悲しいことに、あなたがやろうとしていることはできるとは思いません。悲観的になろうとしているのではなく、正直になろうとしているのです。

私にとっての問題は、マネージャーが納得する必要があるということではありません。より良いものはすでに管理されていない場合、債務がキラーになることができることを理解しています。しかし、彼らがそれを理解しているかどうか、彼らが良いマネージャーか悪いかに関わらず、彼らは皆、配達のプレッシャーに直面し、その配達は日付に対して上司によって判断されます。品質は、それが非常に悪い場合（開発者のせいである場合、または非常に良い場合、それが実現したのは管理の才能である場合）だけが重要です。品質は「十分」でなければなりません。

経営陣が工学とは非常に異なる考え方をしていることを理解している数少ない人の1人だからです。そして、顧客や品質に焦点を当てるのではなく、企業が日付主導型になり、プロジェクト管理が強化されるようになったと思います。これにより、私は典型的な企業を意味し、「完了したら完了します」（Apple Computerやid Softwareなど）と言う勇気を持っている本当に頑固な会社ではありません-はい、時々、人々は自由ではないことを理解していますそのアプローチを取るため）。

しかし、ここに問題があります。品質第一のアプローチをとる企業...あなたはそれらについて何に気づきますか？そうです、彼らはセールスマン、マーケティング担当者、プロジェクトマネージャー、会計士ではなく、エンジニアによって運営されています。HP、Apple、id、Google、Microsoft、IBMを考えてください。すべてがセールスマンではなくエンジニアによって開始され、成功しましたが、セールスマンは確かに役割を果たし、多くの人がマイクロソフトを品質に関連付けることについて議論するでしょう:)。そして、それらのうち、下り坂になったものは、エンジニアリング主導のリーダーシップから逃れました。しかし、変化する時代に適応し、自分の成長を管理することができないために最終的に失敗した多くの技術企業があるため、その声明には多くの議論があります。エンジニアリングベースのリーダーシップがこれらの失敗の原因だとは思わない。s開発者や会計士であることから独立したスキルとビジネスの洞察力の問題。しかし、一般的に言えば、エンジニアリングがコンポーネントである企業に利益をもたらす説明責任と規律の厳しさに対するエンジニアリングの献身があると思います。

真剣に、周りを見てください。ITのリーダーシップは非常に不足しています。焦点は常にコストと時間にあり、それが十分である限りめったに品質にありません。ITリーダーがCEOに報告することはほとんどありませんが、現在は常にCFOです。ITは生産サポートを行うことにこだわっており、革新的価値の大きな変化ではなく、より小さく、より消化しやすく、測定可能なチャンクに焦点を当てているプロジェクトマネージャーにますます注目されています（これは必ずしも間違っているわけではありません。全体像を把握する必要があります）。

この投稿に非常に長い時間を割いて申し訳ありませんが、最終的には、技術的な負債を管理する方法についてのあなたの質問は、既存のリーダーを変更するよりも、適切なリーダーを見つけることで解決できると思います。レニシスが言ったように、標準的な思想家に技術的負債を説明することは、お金とコストに焦点を変えることを意味し、翻訳で多くを失うと思います。成功したとしても、会社のトップリーダーがそれを購入した場合にのみ問題になります。中間管理職に正しいことをさせるよう説得しても、おそらく彼は解雇されるだけです。

最初に行うことは、文言を変更することです。それを「技術的負債」と呼ぶことで、それを許可することは何らかの投資であるという考えを経営者に与えます。（私は技術的負債のデイブ・ラムジーのようです。）

それが無給になるのを許すことは、見ることができないか、簡単に定量化することができない莫大な費用を伴います。

管理に関する次のような問題をリストします。

• 新機能の推定値は、必要以上に高くなっています。または、まったく不可能です。
• 悪いコードはより悪いコードを生み出す
• 開発者が常にそれらを修正している場合でも、バグリストが増加する
• チームメンバーは退社します（これ自体が、この優れた回答で説明されているように問題があることを示しています）

私の経営陣は実際に技術的な負債に対処するために真剣な努力を始めました。それはそこで働くことが好きな理由の1つですが、それは長期的な努力であり、努力が価値がある理由を彼らに思い出させることは決して痛いことはありません。

プレッシャーをかけ続ける1つの方法は、見積もりを求められるときはいつでも、特定の技術的な債務問題に対処する必要がなければ時間を節約できたということです。それを見積もりに含めます。たとえば、「このバグの追跡には2〜3日かかりますが、キューに永遠に存在する他の2つの「優先度の低い」バグにすでに対処している場合は、おそらく1つ未満です。」応答は、先に進んで、他のタスクを修正することです。

私はまた、あなたの仕事の一部として改善を検討し、それがあまりにも破壊的でないなら、あなたが行くようにそれらを行うことに関する他の答えに同意します。私の現在の仕事には、非常に貧弱に設計されたコードへの追加が含まれます。一致する新しいコードを記述して混乱を招くのではなく、前もって共通の機能を統合するために少し時間を費やしているため、パケットを送信すると、わずかに変更された15行のコピーを常に繰り返すのではなく、1行の関数呼び出しになります定型文を貼り付けます。

実際のところ、メンテナーの正気をさらに救ってくれることはわかっています。私は今日のメンテナーだから知っています。ただし、この機能を今すぐデバッグし、現在の自分のタスクをスピードアップすると信じています。

私が過去に使用したことがあり、また行うべきもう1つのテクニックは、コンパイル中、長時間のテスト待ち、または単にペースの変更が必要な場合に、ダウンタイムの間、リファクタリングDVCSブランチを別の作業ツリーに保持することです。バグで燃え尽きたとき。時々アップストリームからマージして、あまり遠くに分岐しない限り、わずかな労力で変更をリファクタリングするのに必要な時間をかけることができます。あちこちで1日に15分あっても、時間がたつと実際に増える可能性があります。

クレジットカードの例えを試すことができます。それらを求める「あなたは、長期間にわたる未払いのクレジットカードの明細書を残して快適に感じていますか？」

マネージャーはコストとメリットを理解していますが、（通常）開発者が使用する技術用語は理解していません。「技術的負債」という用語は、このコミュニケーションの障壁を克服するためにすでに考案されましたが、より明確に表現する必要があるかもしれません。ほとんどのマネージャーは、延滞したクレジットカードの支払いが恐ろしい金利で成長することをよく知っているので（多くの場合、自分の経験から）、無給のままにしておくのは痛いです。これは、ソフトウェアエントロピーに関する問題の深刻さを理解するのに役立つ場合があります。

しかし、これが彼らを納得させないなら、事実の証拠を集めて、いくつかの計算をしてみてください。たとえば、退職金を交換するために、ハードキャッシュと損失時間の両方で、会社にとってどれくらいの費用がかかりますか。

動作するものを（運がよければ）動作する他のものと交換するためにお金を与える人はいません。

あなたができることは、それをもっと多くのものに置き換えることを提案することです。すなわち、技術的負債のサービスをアップグレードにまとめて、即時で具体的なビジネス上の利益をもたらします。

もちろん、あなたはそれについてオープンであるべきです、ここで新しいプロジェクトを「忍び込ませる」ことについて話しているのではありません。

私は反対側、開発者の扱いが難しい側を見つけます。基本的にはこれに要約されます。一部の開発者にとっては、自分のコードが思いつく最高のコードであることを確認することは、プロの誇りの問題です。他の人にとっては、これは単なる別の仕事であり、目的はそれを迅速に完了して家に帰ることです。

そのような状況を変える説得力のある量はありません。必須のコード品質標準を導入すると、9〜5人の開発者がシステムを操作する方法を見つけますが、専任の開発者は必然的に手順全体（それらを狙ったわけではありませんが、開発者Xがルールに従う必要があるとは言えませんが、Yは彼がやりたいことは何でもできます）。

うまくいきますが、それでも非常にイライラする可能性があるのは、より熱心で知識のある開発者にコードベースを監督してもらうことです。

実際、多くの企業では、特に現在の経済状況を考えると、1時間ごとに誰かに請求する必要があります。

または、高速で下降します。

既存のクライアントがリファクタリングの費用を支払わない限り、大幅にアップグレードされたパフォーマンスまたは機能が付属していない限り、これはほとんどありません。その後、古いコードベースでは発生しません。クライアントに大きなポケットがある場合、新しいプロジェクトの予算にこっそりと入ることができるかもしれませんが、リファクタリングでAPIを変更する必要がない限り、古いプロジェクトには役に立たず、会社が2つのコードベースをサポートしている状況。これにより、さらに頭痛とコストが発生します。

エンジニアとして、古いコードをリファクタリングしたいと思います。これは、何かが時代遅れになったり非推奨になったりするたびに、もはや目的にふさわしくありません。しかし、私がこれまで働いてきたすべての会社の私のMDが私に言ったように：「だれが支払うか？」

私はいつも私が行くようにクリーンアップしようとします。コードがきれいになるまで完了しません。技術的負債の問題は、ほとんどの人がそれを理解していないことです。それに取り組む最善の方法は、どれも蓄積しないことです。マネージャーが開発者を信頼して問題を解決する方法を決定すれば、コードの衛生をすべてのプログラミングタスクの一部にすることができます。不正なコードをチェックインしない場合、借金は累積しません。また、ボーイスカウトルール（常にあなたが見つけたコードよりもきれいなままにしておきます）に従うと、既存の負債はゆっくりと消えていきます。

リファクタリングは、機能の実装とは別のタスクとは考えていません。それは不可欠な部分です。

あなたが非技術的なマネージャーを扱っているなら、あなたが彼らの理解する用語にあなたの議論を投げかけることができるならば、それは助けになるでしょう。技術的な負債を返済するために費やされた作業について、肯定的なROIを実現する現実的なケースを構築できる場合、どこかに到達する可能性があります。その練習はあなたの状況に依存しますが、例はこのようなものかもしれません：

開発者が本番の問題でサポートの支援に費やす時間を分析し、古いコードを修正することでサポートの問題の数を減らし、B。開発にエスカレートせずにサポートが問題を簡単に解決できるようにする、 C.開発が本番の問題に発生したときに費やす時間を短縮します。開発者がサポート作業を行う必要がないことで節約できる費用の観点から考えてください。また、開発者がサポートに費やす時間は1時間ごとに「二重の苦労」であることに注意してください。これは、サポートに開発者にお金を払うだけでなく、その開発者ができることの機会費用（新しい機能を追加するなど） ）

ええ、いくつかの数字はブードゥー教/煙と鏡です...それは大丈夫です、管理の汚い秘密は、彼らが投げかける数字の大部分が合計BSであることを知っているということです一見具体的であるように思えるので、彼らは頭の中でそれを得ることができます、あなたは戦いのチャンスがあります。

技術的負債についてのこの説明の後、経営者はそれを完済することを確信する必要があります。

あなたががらくたでいっぱいの非常に汚いキッチンを持っていると想像してください。食事を準備する前に、まず1時間の掃除をする必要があります。そして、それはあなたが食べるたびにそのようなものです。また、食事を準備するときは、がらくたが食事に落ちないように特に注意する必要があります。

キッチンはあなたのコードであり、食事はあなたの製品であり、食事はあなたの製品を売っています。

ユニットテストのセーフネットがなくても、変更が実装されるのをもっと長く待つ余裕があるなら、会社に何か問題があります。

元の製品とビジネスケースの点で、私にとって今よりももっと重要なことをするためにそのお金を使うことができなかったということは、非常に説得力のある議論でなければなりません。好むと好まざるとにかかわらず、あなたの経営者またはあなたの顧客はこれにお金を払っています。

これを言い換えて、自分を顧客として位置付けましょう。古き良きロールプレイ。

冷蔵庫を買っていたとしましょう。そして、Acme Corpで問題なく動作する1000ドルの冷蔵庫を購入するか、Acme Deluxe Fridgesから2000ドルの冷蔵庫を購入することができます。

顧客として、あなたは自分でどちらを買いますか？

そして、Acme Deluxeのエンジニアはより良い答えだと思いますか？

「技術的負債」は、経営者に提示するのが難しい場合があります。質問は、会社に「ここで技術的負債に取り組むのにX％の時間を費やしている。これがうまくいくことを示すために3か月を与えてください」などと述べるチャンピオンがいるかどうかという枠組みになります。同様。そこには自治に対する主張がありますが、そうでない場合、管理者は、かなり危険な領域である結果を見るまでどれくらいかかるのか疑問に思うかもしれません。

ただし、最初のポイントは、これを問題と見なしているかどうかです。視力の悪い人が眼鏡とその変更の種類を何も知らない場合、視力検査がなぜ価値があるのか​​を理解するにはどうすればよいですか？ここでの同じ考えは、主題がかなり技術的であり、残念ながら簡単に定量化できない場合です。

あなたはそれについて不平を言うのをやめるべきです。

その理由は次のとおりです。

1. 彼らは1年以上ソフトウェアを使用する予定はありません
2. 彼らの計画が後でそれをダンプする場合、それはそれを微調整する時間の無駄です
3. 今修正する必要があるいくつかの実際の問題があります
4. 常に楽しいわけではない場合でも、プログラマはメンテナンスに対処することを学ぶ必要があります。
5. あなたがすべきことをよく知っていると不平を言うのは慢です-他の誰かが決定を下し、あなたはそれについて幸せでなければなりません
6. とにかく彼らはあなたに良いコードを書くことを信頼しています

最善の方法は次のとおりです。

1. 彼らがあなたに新しい仕事を与えたら、与えられた時間内に可能な限りそれを実装しようとする
2. 初めて完璧に書いてください。後で変更する必要がある場合は、最初にミスを犯し、変更は常に間違った方向に向かっています。ミスを犯すと、プログラマーにとって学習の機会になります。
3. 余分な時間を求めないでください、あなたはそれを手に入れません、あなたが知っている締め切りがあります。

既存のシステムを書き直したり、置き換えたり、アップグレードしたりするプロジェクトに関与したことはありません。

これらは、正常に完了するのが最も難しいプロジェクトの一部です。あなたが遭遇する問題のいくつかは次のとおりです。

1. ビジネスルールはやがて失われます。
2. ドキュメントと実装は完全に同期していません。
3. ユーザーが機能として見るバグとして見るもの。
4. 逆に、多くの「機能」はユーザーからは欠陥と見なされます。
5. ユーザーの同意を得ることはできません。彼らはあなたの「事実発見」を「愚かな質問をするオタク」と見なし、テストの労力を時間の無駄と見なし、新しい機能を追加することを主張します。すでに予定より遅れています。
6. ソースコードが実行中の実行可能ファイルと100％一致しない可能性があります。
7. あなたの部門がリファクタリング開発をいじっている間、ビジネスは実際に望んでいません。
8. リファクタリングに「よりクリーンな改良されたインターフェース」が含まれることにより、他のプロジェクトが配信の遅れやテストの失敗の泥沼にドラッグされる可能性があります。
9. プロジェクトが缶詰になった後（これらの努力の50％以上が完全に失敗します）、すべての信用を失います。
10. プロジェクトが「成功」した場合、誰もが悪夢だったことを思い出すでしょう。

ペストのような書き直し/リファクタリングのプロジェクトを避けることをお勧めします。それらはプロとしてのキャリアの中で最も心を痛める経験になる可能性があります。

「壊れていない場合は修正しないでください」というフレーズには多くの知恵があります。

私の人生では、なぜ何人かの人々が変化を盲目的に恐れている理由を理解することはできません。それはあなた自身の能力に自信を欠いているということです。

昨夜ヨセミテ国立公園でショーを見ましたが、1940年から1990年代後半にかけて、新しいセコイアの木は1本も芽生えませんでした。その理由は、森林火災を燃やすことに対して厳しい政策があり、セコイアのマツ円錐形は種を開いて放出するために火からの熱を必要としたことが発見されました。

ほら、10年ごとの火は健康でした。蓄積された枯れ木とブランブルをすべて取り除き、既存の木（プロセス）を健康に保ち、新しい木（機能）の場所を空けます。

私は現在、再構築の明確なケースがあるプロジェクトに取り組んでいます。レガシーソフトウェアは、完全に.NET Webフォームを使用して作成されました。ほとんどすべてのビジネスロジックはHTML /サーバータグビューロジックと混在しており、ビジネスが成長したため、他のアプリケーションに拡張することはできません。

管理者は、開発者に対して適切な量の信頼を持っているため、タスクの背後にあります。

はい、再構築が本当に必要かどうかを自問してください。可能な限り機能する既存のコードを再利用するために最善を尽くします。必要に応じて、そのコードを再構築に統合します。大胆な変更を行うことを恐れることがソフトウェア開発者として存在する唯一の方法であると誰にも納得させないでください。

幸運を！

経営陣に技術的負債に対処する経済的理由と、その技術的負債の削減を管理するためのフレームワークを提供する必要があります。

技術的なロードマップを維持することは、そのようなフレームワークの1つです。ロードマップから始めることは、技術的な負債を積み上げないようにするのに役立ち、既存の負債を減らすのにも役立ちます。

多くの成功した長期プロジェクトには、開発を導くための運営委員会とロードマップが関連付けられています。これらは、複数の開発チームと関係者がいる場合に特に役立ちます。

私の提案は、この戦略について上司（そして可能であればお金をどこで使うかを決定する人たち）と話し合うことです。

ロードマップを作成および管理する一般的な方法は簡単ですが、管理チームのサポートが必要です。まず、目標を定義します。技術的負債の要素を定義し、技術的負債の要素を削減するターゲットシステムアーキテクチャを開発します。覚えておいて、それは完璧である必要はなく、単に実行可能で、現在よりも優れている必要があります。ソフトウェア、開発ツール、ハードウェアプラットフォーム、システムに追加される可能性のある主要な新機能を考慮してください。コスト分析を行います。目的のアーキテクチャがある場合、リファクタリングを実行する具体的なメリットは何ですか？（利点には、テスト時間の短縮、より信頼性の高いソフトウェア製品、より予測可能な開発サイクルなどが含まれます。）リファクタリングの実行に十分な利点を示すことができれば、管理サポートを受けることができます。

ロードマップと管理サポートを取得したら、この望ましい状態に到達するために必要な一連の手順（計画とも呼ばれます）を開発します。ロードマップを維持し、ロードマップ上で開発チームをトレーニングおよび教育し、アーキテクチャの整合性の変更を定期的にレビューする運営委員会をまとめることは良い考えかもしれません。

ロードマップは非常に便利で、おそらくジョエルテストの13番目の質問は「ロードマップはありますか？」

これは最近のRed Hat Linuxロードマップセッションの最初の1時間のビデオです。

（リファクタリングだけでなく）主要な書き直しにすでに関与しているので、財務担当者をプロジェクトに同意させることが大きなハードルの1つであることに同意できます。そのハードルを乗り越えるには、中期的に中期的に企業のビジネスが水没することを意味する多くの問題を指摘した報告書を書き、提示し、擁護する必要がありました。

合意を進めるための主な要因：

• 既存のコードはサポートされていないツールチェーン（MicroPower Pascal）にあり、サポートされていない開発プラットフォーム（PDP11-23）でのみ実行されていました。
• ツールやターゲットに取り組むことができる開発者を見つけることはほとんど不可能になっていました。
• スペアが必要な場合、ターゲットハードウェアは使用できなくなり、メーカーは修理サービスを提供することに消極的になりました。
• コードの問題により、顧客の不満がすぐに特定され、直接的なサービスコストが発生していました。
• ターゲットハードウェアの制限により、問題に対処するときにスペースを確保するために他の領域をリファクタリングする必要があるため、新しい機能の追加やバグ修正さえもほとんど不可能になっていました。
• 8時間のビルド時間の開発とテストでは、変更に費用がかかりました。

このレポートでは、継続的なコストの見積もりとともに問題を詳しく説明し、3つのオプションを提供しました。

1. 近い将来、おそらくバグ修正さえ行わなかった場所を凍結します。
2. メンテナンス性を考慮せずに、スペースのみのコードを最適化し、最適化されたコードを維持しようとする人は、最適化を行った人よりも賢くなければならないことを指摘します。
3. 業界標準、広く教えられている言語（ANSI C）、新しい低コストのCOTSハードウェア（PC-104）で、テスト可能性と保守性を高い要因として再実装し、社内で複数のベンダーを利用可能残りの既存のハードウェアで動作できるように設計されたインターフェイスカード。不揮発性ストレージ、一部のユニットが1日に複数回クラッシュし、リセットに£40のサービスコールアウトが必要な障害状態で自動再起動を提供するウォッチドッグタイマーなど、開発の一部として限られた新機能セットを追加プロセスのより良い診断。

3番目のオプションの準備ができたので、私の3か月の契約は、新しいソフトウェアとハ​​ードウェアの両方を開発する3年間の非常に大変な作業になりましたが、非常に良い結果が得られました。

極端な技術的負債が少ない場合、私はゲリラリファクタリングと呼ぶものを採用する傾向があります。

特定のモジュールに問題がある場合：

1. リファクタリングせずに失敗する可能性が高い問題を実証する一連のテストを作成する
2. 開発の一環として、テストがまだ失敗していることを指摘してリファクタリングします。