技術的債務に対処するよう経営陣を説得するにはどうすればよいですか？
これは、開発者と一緒に作業するときによく尋ねる質問です。私はこれまで4つの会社で働いていましたが、コードをクリーンに保ち、ソフトウェアアプリの将来の進歩を妨げる技術的負債に対処することに注意が向けられていないことに気づきました。たとえば、私が最初に働いた会社は、MySQLのようなものを使用するのではなく、ゼロからデータベースを作成し、アプリケーションをリファクタリングまたは拡張するときにチームに地獄を作りました。マネージャーが予測について話し合うとき、私はいつもマネージャーに正直で明確になるように努めてきましたが、経営陣はすでにそこにあるものを修正することに興味がないようで、チームの士気への影響を見るのは恐ろしいことです。
この問題に取り組むための最良の方法についてどう思いますか？私が見たのは、荷造りと荷降ろしの人々です。その後、同社は、開発者が出入りしてコードをさらに悪化させる回転ドアになっています。これを経営陣にどのように伝えて、整理に興味を持ってもらうことができますか 技術的負債 ？
上司に会ってこれについて話し合ったとき、彼はすべての見積もりにリファクタリングを含めるべきだと言った。それは彼が考えたい問題ではない、と彼は言った。代わりに、私はそれを処理する必要があります。
これは、一般的に経営陣が考えたい問題ではありません。彼らはエンジニアではなく、あなたです。これをすべての見積もりの暗黙の部分にすると、技術的な負債が減少することがわかります。
それは完璧ではありませんが。クレジットカードの借金と同様に、技術的な借金は、顧客をより早く獲得し、競合他社よりも早く市場シェアを獲得するための投資です。クレジットのように、適切に管理されている場合、それはあなたをかなり成功させることができます。
それは彼の戦術がヒトラーのような誰かとうまくいくかどうか尋ねられたときにガンジーが言ったようなものです。 「それは難しいだろう」と彼は言った。しかし、答えは本当に「いいえ」であるという公正な議論があると思います。悲しいことに、あなたがやろうとしていることができるとは思いません。悲観的になろうとしているのではなく、正直に言っているのです。
私にとっての問題は、マネージャーが説得する必要があるということではありません。より良いものは、債務が管理されない場合、借金がキラーになり得ることをすでに理解しています。しかし、彼らがそれを理解しているかどうかに関係なく、彼らが優れたマネージャーであるかどうかに関係なく、彼らはすべて配達のプレッシャーに直面し、その配達は上司によって日付に対して判断されます。品質が問題となるのは、それが極端に悪い場合（開発者の責任である場合）、または非常に良い場合（管理の才能がそれを実現した場合）だけです。品質は「十分」である必要があります。
管理がエンジニアリングとは非常に異なる考え方をしていることを理解している数少ないものの1つであるため、彼の答えでレネシスが言ったことを気に入っています。そして、顧客や品質に重点を置くのではなく、企業が日付主導でよりプロジェクト管理に移行するのを見てきました。これは、典型的な企業を意味します。「それが完了すると実行されます」（Apple Computer or id Software-and yes、I時々人々はそのアプローチを取る自由がないことを理解してください）。
しかし、ここで重要なのは、品質第一のアプローチを取る企業です...それらについて何に気付きますか？そうです、彼らはセールスマン、マーケティング担当者、プロジェクトマネージャー、会計士ではなく、エンジニアによって運営されています。 HP、Apple、id、Google、Microsoft、IBMについて考えてみてください。セールスマンではなく、エンジニアが始めて成功したのは確かですが、セールスマンは確かに役割を果たしており、Microsoftが品質に関わることについては多くの人が議論することでしょう。そして、そのうち、下り坂になったものは、エンジニアリング主導のリーダーシップから脱却しました。ただし、変化する時代に対応できず、自社の成長を管理できないために最終的に失敗した多くの技術企業が存在するため、そのステートメントには多数の議論があります。私はエンジニアリングに基づくリーダーシップがこれらの失敗の原因であるとは考えていません。それは、開発者や会計士である誰かに依存しないスキルとビジネスの洞察力の問題です。しかし、一般的に言えば、エンジニアリングがコンポーネントである企業に利益をもたらす、説明責任と規律の厳格さに対するエンジニアリングへの献身があると思います。
真剣に、周りを見てください。 ITのリーダーシップはひどく欠けています。焦点は常にコストと時間であり、十分に良好である限り、品質にはめったにありません。 ITリーダーがCEOに報告することはほとんどなくなり、現在は常にCFOとなっています。 ITは生産サポートを行って行き詰まり、革新的価値の大幅な変化ではなく、より小さく、より消化しやすく、測定可能なチャンクに焦点を当てているプロジェクトマネージャーにますます注目されています（これは必ずしも間違っているわけではありません。分割統治は良いことですが、ビジョン全体像を把握する必要があります）。
この投稿には時間がかかりすぎて申し訳ありませんが、結局のところ、技術的負債を管理する方法についてのあなたの質問は、既存のリーダーを変更するのではなく、適切なリーダーを見つけることでよりよく解決されると思います。レネシスが言ったように、標準的な思想家への技術的負債を説明することは、焦点をお金とコストに変えることを意味します、そして私はそれが翻訳で多くを失うと思います。たとえ成功したとしても、会社のトップリーダーがそれを購入した場合にのみ問題になります。ミドルマネージャーに正しいことをするように説得しても、おそらく彼は解雇されるだけです。
最初にすべきことは表現を変更することです。「技術的負債」と呼ぶことで、管理者はそれをある種の投資であるという考えを得ることができます。 。 （私は Dave Ramsey 技術的負債のようです。）
それを無給にすることを許すことは、見ることができないか、または簡単に定量化できない莫大な費用を伴います。
管理のために、次のような問題をリストします。
- 新機能の見積もりは、必要以上に高くなっています。または、まったく不可能です。
- 悪いコードはより悪いコードを生み出します
- バグリストは、開発者が常に修正している場合でも増加します
- チームメンバーが去ります（これ自体が、 この優れた答え で説明されているように問題があることを示している可能性があります）
私の経営陣は実際に技術的な負債に取り組むために真剣な努力を始めました。これは私がそこで働くのが好きな理由の1つですが、それは長期的な努力であり、努力が価値がある理由を思い出させることは決して害はありません。
私がプレッシャーをかけ続ける1つの方法は、見積もりを求められたときであり、特定の技術的な負債問題に対処する必要がなかった場合は時間を節約できたでしょう私はそれを見積もりに含めます。たとえば、「このバグを追跡するには2〜3日かかりますが、キューに永遠に残っている他の2つの「優先度の低い」バグにすでに対処している場合は、おそらく1つ未満です。 "多くの場合、応答は先に進んで、他の問題を修正することです。
私はまた、仕事の一部を改善することを検討し、それがあまりにも破壊的でない場合は、あなたが行っているときにそれらを行うことについての他の答えにも同意します。私の現在の仕事は、非常に不十分に設計されたコードに追加することです。一致する新しいコードを記述して混乱に追加するのではなく、共通機能を統合する前に少し時間を費やしているため、パケットを送信すると、わずかに変更されたコピーの15行を常に繰り返すのではなく、1行の関数呼び出しになります。ボイラープレートを貼り付けます。
将来的には、メンテナの正気をさらに節約できることは事実です。今日はメンテナーなので知っています。しかし、私はまた、この機能を導入してデバッグするという私の現在のタスクをスピードアップすると信じています。
私が過去に使用したもう1つの手法は、次の方法ですリファクタリングDVCSブランチを別の作業ツリーに保持するコンパイル中、長いテストを待機中、またはバグで燃え尽きたときは、少しペースを変える必要があります。時々アップストリームからマージして遠くに分岐しない限り、ごくわずかな労力で変更をリファクタリングするのに必要なだけ長く取ることができます。あちこちに15分ありますが、時間の経過に伴って実際に増える可能性があります。
あなたはクレジットカードの類推を試すことができます。それらに尋ねます「クレジットカードの明細を長期間にわたって無給のままにしておいても大丈夫ですか？」
マネージャーはコストとメリットを理解しますが、（通常）開発者が使用する技術用語を理解しません。 「技術的負債」という用語は、このコミュニケーションの障壁を克服するのを助けるためにすでに発明されていますが、それを明確に表現する必要があるかもしれません。ほとんどのマネージャーは、（多くの場合、自分の経験から）延滞したクレジットカードの支払いが恐ろしい金利で増加するため、未払いのままにしておくことが痛いことをよく知っています。これは、ソフトウェアエントロピーに関する問題の深刻さを理解するのに役立ちます。
しかし、これでも納得できない場合は、事実に基づいた証拠を収集して、いくつかの計算を行ってください。例えば。退職する従業員を置き換えるために、ハードキャッシュと時間のロスの両方で、会社にどのくらいの費用がかかりますか。
うまくいくものを（運がよければ）うまくいくものに置き換えるためにお金を払う人はいないでしょう。
あなたができることは、それをより多くのものに置き換えることを提案することです。つまり、技術的債務のサービスを、即時の具体的なビジネス上の利益をもたらすアップグレードにバンドルします。
もちろん、あなたはそれについてオープンであるべきです。ここでは、新しいプロジェクトを「忍び込む」ことについて話しているのではありません。
反対側は、開発者にとって扱いが難しいことです。基本的にはこれに要約されます。一部の開発者にとって、自分のコードが考えられる最高のコードであることを確認することは、プロの誇りの問題です。他の人にとっては、これは単なる別の仕事であり、その目的はそれを素早く終わらせて家に帰ることです。
説得力のあるものでその状況が変わることはありません。必須のコード品質基準を導入すると、9〜5人の開発者がシステムを操作する方法を見つけられますが、専任の開発者は必然的に手順全体に煩わされます（それらを狙ったものではありませんが、開発者Xはルールに従う必要があるとは言えませんが、Yは彼がやりたいことは何でもできます）。
機能しますが、それでも非常にイライラする可能性があるのは、より専門的で知識の豊富な開発者にコードベースを監視してもらうことです。
実際、多くの企業では、特に現在の経済状況を考えると、1時間ごとに誰かに請求する必要があります。
または、ダウンしますfast。
既存のクライアントがリファクタリングにお金を払うつもりでない限り、大幅にアップグレードされたパフォーマンスまたは機能が付属しない限り、それは非常にありそうもありません。その後、それは古いコードベースでは起こりません。クライアントのポケットが深い場合は、新しいプロジェクトの予算にそれを忍び込むことができるかもしれませんが、リファクタリングでAPIを変更する必要がない限り、古いプロジェクトには役に立たず、会社が2つのコードベースをサポートしている状況では、さらなる頭痛とコストが発生します。
私はエンジニアとして、何かが陳腐化したり廃止されたりするたびに、もはや目的に完全に適合しない古いコードをリファクタリングしたいと思います。しかし、私がこれまで働いたすべての会社の私のMDが私に言ったように"誰が支払うのか？"
私はいつも私が行くように片付けをしようとします。コードがきれいになるまで私は終わりません。技術的負債の問題は、ほとんどの人がそれを理解していないことです。それに取り組む最善の方法は、それを蓄積しないことです。マネージャーが開発者を信頼して問題の解決方法を決定する場合は、すべてのプログラミングタスクにコードの衛生状態を組み込むことができます。悪いコードをチェックインしないと、借金がたまりません。 ボーイスカウトルール にも従う場合（常にコードを見つけたときよりもきれいにしてください）、既存の借金はゆっくりと消えます。
機能の実装とは別のタスクとしてリファクタリングを考えていません。それはそれの不可欠な部分です。
技術者以外のマネージャーとやり取りしている場合は、彼らが理解できる用語に議論をキャストできると助かります。技術的負債を返済するために費やされた作業にROIがプラスになる現実的なケースを構築できれば、どこかに行く可能性があります。その演習は状況によって異なりますが、例は次のようなものです。
開発者がサポートの本番環境の問題の解決に費やす時間を分析し、古いコードを修正することで、A。サポート問題の数を減らし、B。開発がエスカレーションせずに問題を簡単に解決できるようにする。 C.問題が発生した場合に開発が本番環境の問題に費やす時間を削減する。開発者がサポート作業を行う必要がないことによって節約された金額で表すと、また、開発者がサポートに費やす1時間ごとが「ダブルワーミー」であることにも注意してください。これは、開発者にサポートを提供するために支払うだけでなく、その開発者が実行できること（新しい機能の追加など）の機会費用を消費しているためです。 。）
ええ、いくつかの数字はブードゥー/スモークアンドミラーになります...それは大丈夫です、管理の汚い秘密はそれらが知っている彼らが投げかけている数字の大部分が合計BSであることですあなたが彼らに働くように見える何かを彼らに与える限り、彼らは彼らの頭の中でそれを得ることができるので、あなたには戦いのチャンスがあります。
この技術的負債の説明の後、あなたの経営陣はそれを返済することを確信するはずです：
あなたががらくたでいっぱいの非常に汚いキッチンを持っていると想像してください。食事を準備する前に、まず1時間の掃除をする必要があります。そして、食べたいときはいつもそうです。また、食事を準備するときは、がらくたが食事に落ちないように、特に注意する必要があります。
キッチンはあなたのコード、食事はあなたの製品、そして食べることはあなたの製品を販売することです。
ユニットテストのセーフネットがなければ、変更が実装されるまでしばらく待つ余裕がある場合は、会社に問題があります。
元の製品とビジネスケースの観点から、私は今、そのお金を使って自分にとってより重要な何かをすることができないという非常に説得力のある議論でなければなりません。好むと好まざるとにかかわらず、あなたの経営者または顧客はこれにお金を払っており、彼らを別名納得させるために販売できる必要があります。
これを言い換えて、自分を顧客として位置づけましょう。古き良きロールプレイ。
あなたが冷蔵庫を買っていたとしましょう。そして、Acme CorpからOKで動作する1000ドルの冷蔵庫を購入したり、外観が同じで技術仕様は同じであったが、内部アーキテクチャがよりクリーンであるためメンテナンスコストが低いAcme Deluxe Fridgesから2000ドルの冷蔵庫を購入したりできます。
顧客として、あなたはどちらを購入しますか？
そして、Acme Deluxeのエンジニアは何がより良い答えだと思いますか？
" 技術的負債 "は、必要性を認識していない可能性があるため、経営者に提示するのが難しい場合があります。質問は、社内に支持者がいるかどうか、「ここで、技術的な負債に取り組むためにX％の時間を費やしています。これがうまく機能することを示すのに3か月かかります」などのように組み立てることができます。同様。そこには自治権に対する主張がありますが、そうでなければ管理者は、かなり危険な領域である結果が表示されるまでどのくらいの期間疑問に思うかもしれません。
最初のポイントは、これを問題と見なすかどうかです。視力の弱い人が眼鏡を知らず、眼鏡がどんな種類の変化をもたらすことができるかについて、視力検査がなぜ価値があるのかをどのように理解するのでしょうか？主題がかなり技術的であり、残念ながら簡単に定量化されていない場合の同じアイデア。
あなたはそれについて文句を言うのをやめるべきです。
理由は次のとおりです。
- 1年以上ソフトウェアを使用する予定はない
- 彼らの計画が後でそれを捨てることであるならば、それはそれを微調整する時間の無駄です
- 今修正する必要があるいくつかの実際の問題があります
- プログラマーは、それが常に楽しいわけではない場合でも、メンテナンスに対処する方法を学ぶ必要があります
- あなたは何をする必要があるかをよく知っていると不平を言うのは傲慢です-他の誰かが決定を下し、あなたはそれについて幸せでなければなりません
- とにかく彼らはあなたが良いコードを書くことを信頼しています
だから最善の方法は：
- 彼らがあなたに新しいタスクを与えるとき、それを与えられた時間にできるだけうまく実装するようにしてください
- 初めて完璧に書いてください。後で変更する必要がある場合、最初に間違えたため、変更は常に間違った方向に向かいます。これは、プログラマーが間違いを犯したときの学習機会です。
- それのために余分な時間を求めないでください、あなたはそれを得ることができません、あなたが知っている締め切りがあります。
既存のシステムを書き換えたり、置き換えたり、アップグレードしたりするプロジェクトに関与したことはないと思います。
これらは、正常に完了するのが最も難しいプロジェクトの一部です。遭遇する問題のいくつかは次のとおりです。
- ビジネスルールは時間内に失われます。
- ドキュメントと実装は完全に同期されていません。
- ユーザーが機能として見るバグとして見たもの。
- 逆に、多くの「機能」はユーザーによって欠陥と見なされます。
- あなたはユーザーの賛同を得ません-彼らはあなたの「事実の発見」を「愚かな質問をするオタク」と見なし、彼らはテストの労力を時間の無駄と見なし、新しい機能の追加を主張し、プロジェクトを長くするでしょうすでに予定より遅れています。
- ソースコードが実行中の実行可能ファイルと100％一致しない可能性があります。
- あなたの部門は開発のリファクタリングをめちゃくちゃにしていますが、ビジネスが実際に望んでいることは行われていません。
- おそらく、リファクタリングには「よりクリーンな改善されたインターフェース」が含まれ、他のプロジェクトを納品遅れや失敗したテストの泥沼にドラッグすることになります。
- プロジェクトが缶詰になった後（これらの取り組みの50％以上が完全に失敗します）、すべての信用が失われます-別の町の別の会社に移動して、あなたの話を聞く準備ができている人を見つける必要があります。
- プロジェクトが「成功する」と、誰もがそれがどんな悪夢だったかを覚えているでしょう-あなたは…….
ペストのような書き直しやリファクタリングのプロジェクトは避けてください。これらのプロジェクトは、専門家としてのキャリアの中で最も意気消沈するような経験になる可能性があります。
「壊れていなければ直さないで」という言葉には、多くの知恵があります。
（リファクタリングだけでなく）大規模な書き換えにすでに関与しているので、金融関係者にプロジェクトに同意してもらうことが大きなハードルの1つであったことに同意できます。このハードルを乗り越えるには、企業のビジネスが中期的に水に沈むことになるという多くの問題を指摘するレポートを書いて、提示し、擁護する必要がありました。
合意を進めるための主な要因：
- 既存のコードはサポートされなくなったツールチェーン（MicroPower Pascal）にあり、ほとんどサポートされていない開発プラットフォーム（PDP11-23）でのみ実行されていました。
- ツールやターゲットに取り組むことができる開発者を見つけることはほとんど不可能になりました。
- スペアが必要な場合、対象のハードウェアは利用できなくなり、メーカーとメーカーは修理サービスの提供に消極的になりました。
- コードの問題により、容易に特定できる顧客の不満と直接的なサービス費用が発生していました。
- ターゲットハードウェアの制限により、新しい機能の追加やバグの修正でさえほとんど不可能になり、問題に対処するときに他の領域をリファクタリングしてスペースを確保する必要がありました。
- 8時間のビルド時間で、あらゆる変更の開発とテストにコストがかかりました。
レポートでは、進行中のコストの見積もりとともに問題を詳しく説明し、3つのオプションを提供しました。
- 近い将来、バグ修正さえもしていない場所でフリーズします。
- 保守性を考慮せずに、スペースのみのコードを最適化します最適化されたコードを保守しようとする人は、最適化を行った人よりも賢くなければならないことを指摘します。
- テスト可能性と保守性を高い要素として、業界標準の広く教えられている言語（ANSI C）で、新しい低コストのCOTSハードウェア（PC-104）に再実装し、社内で複数のベンダーを利用可能残りの既存のハードウェアで動作するように設計されたインターフェイスカード。不揮発性ストレージ、障害状態での自動再起動を提供するウォッチドッグタイマーなどの開発の一部として、限定された新機能のセットを追加一部のユニットは1日に複数回クラッシュし、£40のサービスコールが必要でしたリセットするアウト、プロセスのより良い診断。
3番目のオプションを実行すると、3か月の契約が3年間の非常にハードな作業になり、新しいソフトウェアとハードウェアの両方を開発しましたが、非常に良い結果が得られました。
極端な技術的負債が少ない場合、私はゲリラリファクタリングと呼ぶものを採用する傾向があります。
特定のモジュールに問題がある場合：
- 問題を示す一連のテストを記述しますこれもリファクタリングなしでは失敗する可能性があります
- テストがまだ失敗していることを指摘して、開発の一部としてリファクタリングします。
私の人生において、なぜ一部の人々が盲目的に変化を恐れているのか理解できません-それはあなた自身の能力への自信の欠如のスマックです。
昨夜ヨセミテ国立公園でショーを見ましたが、1940年から1990年代後半にかけて、1本の新しいセコイアの木が発芽しなかったことがわかりました。その理由は、森林火災を燃やすことに対する厳格なポリシーがあり、セコイアの松ぼっくりが種子を開いて放出するために火からの熱を必要としたことが発見されました。
ほら、10年ごとの火事は健康でした。蓄積されたすべてのデッドウッドとキイチゴを取り除き、既存の木（プロセス）を健康に保ち、新しい木（機能）のための余地を作りました。
私は現在、再構築の明確なケースがあるプロジェクトに取り組んでいます。レガシーソフトウェアは完全に.NET Webフォームを使用して作成されました。ビジネスロジックのほとんどすべてがHTML /サーバータグビューロジックと混ざり合っており、ビジネスが成長した現在、他のアプリケーションに拡張することはできません。
彼らが彼らの開発者に適切な量の信頼を持っているので、管理はこの仕事の背後にあります。
はい、再構築が本当に必要かどうか自問してください。できる限り機能する既存のコードを再利用するために最善を尽くしてください。必要に応じて、そのコードをリビルドに統合します。大胆な変更を恐れることがソフトウェア開発者として存在する唯一の方法であることをだれにも納得させないでください。
幸運を！
あなたはあなたの経営者に技術的負債に対処するための財政的理由と、その技術的負債の削減を管理するためのフレームワークを与える必要があります。
技術ロードマップ を維持することは、そのようなフレームワークの1つです。ロードマップから始めることで、技術的負債が山積みになるのを防ぎ、既存の負債を減らすこともできます。
多くの成功した長期プロジェクトには、開発を導く運営委員会とロードマップが関連付けられています。これらは、複数の開発チームや関係者が関与している場合に特に役立ちます。
私の提案は、この戦略について上司（および可能であれば、お金がどこに費やされるかを決定する人）と話し合うことです。
ロードマップを作成および管理する一般的なアプローチは簡単ですが、管理チームのサポートが必要です。まず、目標を定義します。技術的負債の要素を定義し、技術的負債の要素を削減するターゲットシステムアーキテクチャを開発します。覚えておいてください、それは完璧である必要はありません。システムに追加される可能性のあるソフトウェア、開発ツール、ハードウェアプラットフォーム、主要な新機能を考慮してください。コスト分析を行います。必要なアーキテクチャがある場合、リファクタリングを実行することの具体的なメリットは何ですか？ （メリットには、テスト時間の短縮、より信頼性の高いソフトウェア製品、より予測可能な開発サイクルなどが含まれます。）リファクタリングの実行に十分なメリットを示すことができれば、管理サポートを受けることができます。
ロードマップと管理サポートが得られたら、この望ましい状態に到達するために必要な一連のステップ（計画とも呼ばれます）を作成します。ロードマップを維持し、ロードマップの開発チームをトレーニングおよび教育し、アーキテクチャの整合性の変更を定期的にレビューする運営委員会をまとめることは良い考えかもしれません。
ロードマップは本当に便利です。JoelTestの13番目の質問は「ロードマップがありますか？」