商業用語でのリファクタリングの価値の定量化
これが古典的なシナリオです。開発チームがプロトタイプを作成します。ビジネス管理はそれを好み、それを生産に投入しました。開発チームは現在、コードベースがプロトタイプだったときに発生した技術的負債を支払うと同時に、新しい機能を提供し続ける必要があります。
私の質問はこれです（私を許してください、それはかなり自由回答です）。リファクタリング作業の価値を商業的に定量化するにはどうすればよいですか？
開発者として、コードの重複の削除、オブジェクトモデルの簡素化など、技術的な用語で価値を明確に理解し、伝えることができます。しかし、これは商業的要素に焦点を当てた幹部にとってはほとんど意味がありません。このエグゼクティブにとって何か意味があるのは開発者です。チームは要件をより迅速に提供できます。投資収益率（リファクタリングに割り当てられたリソースの見返りの増加速度）を明確に定量化するメトリックなしでこのステートメントを作成するだけでは、重要性はほとんどありません。
上記に関してポジティブまたはネガティブな経験をした人からの連絡をお待ちしています。
-----------------編集----------------
これまでの回答に感謝します。すべて良いと思います。私が開発したいのは、これらのステートメントすべてを証明する（または反証する）メトリックです。速度とリファクタリングを結び付け、プラスの効果を示すレポート。
これらの利点を説明することでsome成功しました：
- 将来のバグの減少（営業担当者でさえバグが悪いことを知っています）。
- 将来のバグを修正するためのより簡単、より速く、そしてより安い。
- 製品を拡張するための、より簡単で、より速く、そしてより安い価格。
- 製品にまったく新しい機能を追加するのがより簡単、高速、そして安価です。
- サードパーティのシステムとの統合がより簡単、高速、安価。
- リファクタリングを早く開始できるほど、技術的な負債が少なくなり、製品の品質が向上します（1〜5の方が簡単です）。
私は技術的な負債などの条件で限られた成功しか収めていません、一部の商業人はそれを手に入れました、それは専門家の人々が自分のことを正当化しようとしているだけだと思っています、それはすべてあなたがそれを説明しようとしている人に依存します。
うまく機能する1つの戦略（技術的な負債をあまり多く蓄積させない限り）は、営業担当者が行う次の拡張/機能/変更の開始時に小中規模のリファクタリングを実行することで、一度に少しずつそれを完済することです欲しいです。
それを彼らの要求の一部にします、「確かに、私たちはそれを行うことができますが、最初にこの新機能をサポートするためにシステムのこの部分を拡張する必要があります。」
あなたがリファクタリングをすることでどれだけの時間を節約できるかについての実際のメトリックを得ることができれば、個人的に私は二重見積もりがよりうまく機能することを発見しました。自己奉仕と見なされます。
二重見積もりとは、「確かに、サブシステムYを修正した場合、機能Xは3日かかります。それ以外の場合は、X + Z日で対処すると、サポートが減少します。呼び出して、計画された機能Wをより速く追加します。」
指標が好きな人が、機能/製品Xに関するサポートコールに費やした時間と私の二重見積もりを組み合わせる場合、この方法で、継続的なサポートコールに基づいて機能Xのコストを示すグラフ/スプレッドシート/コストを作成できます。リファクタリングからの削減見積もり。
時間が経つにつれて、リファクタリングの前後にフィーチャーXの実際の数値を生成できます。
開発コストの実際の数値を取得することは、各機能が1回だけ実装されるので（うまくいけば！）トリッキーです。1つのアイデアは、リファクタリングにかかる時間を追跡し、リファクタリングコストを「何をするかリファクタリングせずにコストが発生します」と表示されます。これは、実際の見積もりより高くなることが期待されます。これにより、時間とコストの節約が非常に明白になります。
基本的にcleanerコードベースを使用すると、ほとんどすべての処理をより高速に実行できるため、他の方法よりも安価になり、追加の価値とより優れたROIを商用ユーザーに提供できます。
SteBの回答（私は賛成しています）は非常に良いと思います。私は彼の回答の1つのポイントについて詳しく説明したいと思います（他のポイントにも適用される例として）。
製品を拡張するための、より簡単で、より速く、そしてより安い価格。
これの管理を納得させるには？
製品Xのリリース1があったとしましょう。
機能Yはリリース2で計画されており、機能Zはリリース3でほぼ確実に必要であることをすでに知っています。
次に、見積もり（ポーカーカードでグルーミングセッションを実行）を行い、その後マネージャーに連絡して次のように言います。
- 現在のコードでは、機能Yは8週間、機能Zは6週間かかります。
- リファクタリングされたコードでは、機能Yには4週間、機能Zには2週間かかります。リファクタリングには2週間かかります。
したがって、次のシナリオがあります。
- フィーチャーYを含むリリース2。フィーチャーYは、リファクタリングなしで8週間、リファクタリングありで6週間かかります。
- リリース2と3、フィーチャーYとZの両方。フィーチャーYとZは、リファクタリングなしで12週間、リファクタリングありで8週間かかります。
これはもちろん単なるスケッチですが、IMO同様の分析を行うことができれば、管理者を説得する可能性が高まる可能性があります。これは、単なる見積もりにすぎませんが、リファクタリングの利点について具体的な考えがあることを意味します。
[〜＃〜] note [〜＃〜]：同様の分析を作成するのが難しい場合は、それを必要としない可能性を考えてください。
私は上記の@maple_shaftのコメントと一緒です：
プロトタイピング時でも、不正なコードを記述しないでください。プロトタイプのコードをトレーサー弾丸のアプローチと考えてください。まだ完成していなくても最終製品になるもの。
リファクタリングを経営陣に説明したり正当化したりする必要はありません。これはプロセスの継続的な部分であるべきです。なぜ特定の継承構造を実行しているのか、特定のフレームワークを使用しているのかなどを説明しないのと同じです。これらは技術的な詳細です。あなたの顧客は、彼らが管理者であろうと最終顧客であろうと、結果だけを気にします。
回避したいのは、外界に関する限り、何も起こらない長いダウンタイムです。例えば。大量の不良コードを記述したくない場合は、3週間かけてリファクタリングして改善します。まず第一に、それはあまりうまくいきません。次に、リファクタリングに時間がかかっていることを説明したくなるかもしれません。部外者にとっては、ある種のオタク休暇を取っているように聞こえます。
早期リファクタリング。何かがおかしいと思って、それを正しくするのが少し面倒な場合は、そうしてください。補足：何かが間違っているかどうかわからない場合、または改善する方法がわからない場合は、問題が発生するまでそのままにしておきます。
何度も行ったことがある。
それを処理する方法はいくつかありますが、簡単な方法はありません。
あなたはそれをほとんど自分で言った：彼らはあなたができるだけ速く配達することを気にかけているだけだ。 Xか月のリファクタリングラウンドが新しいラウンドの開発にかかる時間を短縮するビジネスケースを利害関係者に示し、リファクタリングのための投資回収率（1年程度後）のROIを見積もります。
または、これが非常に難しい場合は、他の経済的な改善策が役立つ可能性があります。「プロトタイプを本番稼働させている場合、それを維持するためにさらに2人のエンジニアを雇う必要があります。リファクタリングプロジェクトに参加すれば、このコストを回避できます。 ……」.
内部コストセンターなどがある場合は、このアプリケーションをサポートする運用担当者が、同様の「運用に適した」アプリケーションよりも多く請求することを確認してください。
チームがある程度のコントロールを持っている場合は、新機能の開発フェーズにリファクタリングを埋め込むことができる場合があります。たとえば、複雑な階層を既に問題のあるデータモデルに入力したいと考えているとします。データモデルに変更を加えるための技術要件として、リファクタリングを含めます。同様のケース：配管工にラジエーターを交換するように依頼した場合、パイプが錆びて適切に機能しない場合は、彼が調査します。彼の職業は何をすべきかを知っているからです。ソフトウェア開発者も同じことを（すべき）行います。
あなたが壁にぶつかった場合、あなたの議論のために統計を集めてください。プロダクションにふさわしいコードで回避できた可能性があると報告された各バグ/運用上の問題にタグを付けます。次に、バグをかなり多くの％削減してビジネスケースを示し、稼働時間/安定性をさらに％増やすことができます。
ただし、ソフトウェア開発者は、「十分に良い」ことしかできない場合に、可能な限り最高のソリューションを作りたいという事実が常にあります。リファクタリングのための経済的な議論を構成できない場合、それはおそらく価値がないので、実行すべきではありません。
プロトタイプを量産するのは、設計プロジェクトが不十分な場合よりも悪いです。なぜなら、意思決定者が多すぎて、実際よりも優れていると考えているからです。プロトタイプ作成プロセス全体を通じて、「これはまだ準備ができていません。製造。"彼らが以下のことを確信していないため、この時点に到達する確率は低いです：
- 建てることができました。
- 誰もが本当にそれを必要とする/使うつもりでした。
「私はあなたにそう言った」に集中しないでください。ただし、プロトタイプのスケジュールを維持できなくなることや、あなたができないことを明確にしてください。これらのメトリックのいずれかを使用して、本番環境対応機能を作成するのにかかる時間を決定します。製品の機能は表示されますが、次のような問題があることを思い出してください。
- より多くのユーザーを処理できない場合があります
- エラー処理は一般的なユーザーには十分ではありません
- 新しくリクエストされた機能の多くを収容できません。
- テストはほとんどありません
上級管理職の技術者以外のメンバーは、リファクタリングの概念を理解しません。彼らはこの「うまくいく」ことを頭の中に持っており、何回あなたが裏切りに対して何かを言っても、彼らはプロジェクト全体を通してその考えを解放しません。仕様の一部にする必要があるだけです。技術管理者は厳しい時間的プレッシャーにさらされている可能性があり、プロジェクトの仕様からこれらのタスクの多くを実行しようとする場合があります。 「なぜ私たちはすでに完成している機能に取り組んでいるのですか？」他のanserのいくつかは、これが当てはまらない理由を説明するいくつかの方法を提供します。
幸運を
私は、非技術的なアナロジーを通じてこれに答えたいと思います。
いくつかの例：
レンガを使って、最大5階建ての家を簡単に建てることができます。あなたは簡単に単一の床に追加することができます。しかし、20階か30階に行って、突然バムしてみてください。鋼鉄の梁のようなより良いインフラストラクチャが必要なため、タイルが爆発しています。インフラストラクチャは重要であり、イニシャルを「リファクタリング」することでできるだけ早くそれを正しくすることがわかります...
あなたはあなたのガーを運転します。走るのに必要なのはガスだけ！まあ、あれと...オイルは頻繁に変わります。ああ、まれに、新しいタイヤ、そして時々他の流体と部品。メンテナンスは責任ある自動車所有者であることの一部であることが判明しました...
私はそのような立場にありました（私たちは皆そうだと思います）。
多くの場合、これは非常に効果的な答えです。
このプロジェクトを開発するために1年分の料金を支払っています。もし私が明日のバスに見舞われたら、あと2年間支払って、取り残された混乱を解く方法を見つけたいですか？ 3か月間支払っておくほうがいいので、次の人は1か月でスピードアップしますか？
重要：厄介なコードの記述に1年を費やしたと聞かれたときは、ブートを取得しないようにしてください。そうすれば、プロトタイプを時間どおりに取得できます...
リファクタリングとは何かを明確に定義できますか？ 2つのプロシージャのマージはおそらくリファクタリングです。しかし、オブジェクトの名前を変更するのはどうですか？方法？パブリック変数？プライベート変数？シグネチャを変更せずにメソッドの実装を変更するとどうなるでしょうか。その変更によって特定の種類の入力が遅くなり、コードの遠い部分に変更が発生した場合はどうなりますか？私が言っていることは、それを測定する方法またはいくつかの方法を選択する前に、測定しようとしているものの本当に明確な定義が必要だということです。
また、リファクタリングのメリットをすぐに理解できないため、これも困難です。 12個のメソッドを持つ5つのオブジェクトを5つのメソッドを持つ3つのオブジェクトに変換したとします。将来的には多くの時間を節約できますが、現在の機能を提供するのにかかる時間は2倍になります。したがって、これは仮想的な長期的な利益のためのビジネスにとっての短期的な損失です。リファクタリングを行うと、状況が悪化することもあります。
リファクタリングとは、コードの一部を変更すると、プログラム全体の機能が（多かれ少なかれ）維持されるようにコードの別の部分を変更する必要があるが、内部で機能する方法は、違う。定義により、エンドユーザーは通常、リファクタリングの効果を確認できません（パフォーマンスが向上するか、ユーザーに同じベースライン機能を提供するユーザーインターフェイスの簡素化を許可する場合を除く）。
したがって、プラスの影響を示すには長期的に物事を測定する必要があり、定義上、それは間接的な影響です。今日このことを一日中考えていて、数年前にタイム誌に掲載された、人々が最も長く生きる方法についての研究を思い出しました。炭酸飲料などをどれだけ喫煙または飲んだかを人々に尋ねるのではなく、地球上で最も長命の人々を調べ、何百（または何千）もの食事、ライフスタイル、環境要因を分析して、どこに共通していたかを特定しました。寿命が長く、一般的にはまれです。
毎月測定して、これまで以上にリファクタリングがいかに優れているか、またはリファクタリングを会社の最終収益に直接関連付けることができる小さなグラフで示すことができるメトリックが考えられないのは残念です。しかし、あなた（または付属大学のCS部門）は、成功したソフトウェアチームの特徴を見て、リファクタリングが彼らを際立たせるものであるかどうかを確認できると思います。私はそうなると思いますが、研究を見ることには非常に興味があります。たぶん、このフォーラムの他の誰かがそのような研究を指摘できますか？