DevOpsの観点から技術的負債を売却するには?

技術的負債を生み出さない方が良い、という劇的かつ情けない議論がしばしば行われます。はい、もちろんない方が良いです。しかし、その影響はまだ取り除くことができます。 私が技術的負債と呼んでいるのは、すべての変更と改善、インフラストラクチャの変更とプロセスの変更、ギャップを解消することを目的としたチーム構造の変更（製品発売の枠組み内で意識的にまたは無意識に行われた）、および時間の経過とともに大きく干渉する機能です。 そして、このような問題は、生産部門と運用部門の確固たる自信に満ちたチームプレイがなければ解決できないため、この話は直接 DevOps に関するものです。 技術的負債 - 誰のものですか? しかしまず、問題の根本から、なぜ私は技術的負債について話しているのでしょうか?なぜなら、企業がそのために時間を割り当ててくれないことに非常に腹を立てているからです。この赤いスレッドは、すべてのレポート、ミートアップ、開発者と運用間のコミュニケーションを通じて実行されます。 邪悪でひどい企業は、技術的負債に取り組む時間を割り当てません。 「品質はまったく必要ないのではないか？」という当然の疑問さえ生じます。将来を見据えて、私は「誰も品質を必要としていない」と言うでしょう。しかし、この考えは少し後で明らかにします。 この状況を分析するために、なぜ企業が私たちにこのようなことをするのかを考えてみましょう。答えを得るには、誰が技術的負債を抱えているかを考える必要があります。誰がその責任を負うのでしょうか？ 何年も関わってきた後、私たちは皆に指輪を提供するフロドのようなものであることに気づきました。 「この重荷を負うのを手伝ってください！」というようなものです。私たちは、企業が私たちに技術的負債への対処を望んでいる（まさにそれを望んでいる）のを待っています。しかし、企業との相互誤解の根本原因は、企業が決してそうしたいと思わないことです。 私たちにとって、それはエンジニアリングの課題であり、製品の卓越性を向上させる方法であり、さらには製品に対する誇りを高めるメカニズムでもあります。しかし、ビジネスにとって、それは常に迷惑であり、時間を費やさなければならない必要悪（または必然）です。 あなたがタクシーに乗ったとき、運転手が「洗車場に停めてもいいですか？」と尋ねたと想像してください。 この状況におけるビジネスはクライアントであり、開発者はタクシーの運転手です。 業者は「どうして?! 私が交通費を払っているのに、あなたは洗車に行くのですか!」と憤慨しています。 これに対し、タクシーの運転手は「いい匂いがするきれいな車に乗りたくないですか？」と当然のことを言いました。 業者はこう答えます。「もちろん、そう思います！でも、私はデフォルトでそれを期待しており、そのために今すぐ洗車場に立ち寄る準備はできていません！」 これが企業が技術的負債を扱う方法です。洗車場に立ち寄ってみないかという提案のようなものです。タクシーを注文するときは、清潔なサロンか高級なサロンを希望するかに応じて適切なカテゴリーを選択します。注文の段階では投資するつもりですが、洗車場に立ち寄るのはそうではありません。 なぜなら、先ほども言ったように、誰も品質を求めていないからです。しかし、それはデフォルトで期待されています。 それは絶対必要です。企業は洗車場に行かないことを諦めることはできませんし、自分の時間を犠牲にして洗車場に行くこともできません。どうしようか？ビジネスは機関車です。機能、販売、顧客が必要です。私たちの「欲しい」「望む」だけでは、技術的負債を企業に売ることは不可能です。しかし、別の方法でビジネスを動機付けることは可能です。 これまでの旅の過程で、私は技術的負債を「買う」ビジネス動機として 3 つのカテゴリーを形成しました。 「太った」無関心。裕福な投資家がいる場合、CEO は変なオタクの開発チームを雇う余裕があります。 「まあ、彼らにやってもらいましょう！ 重要なのは製品を完成させることです。チームのスピリットは素晴らしい、すべてがクールです、そして私たちは世界で最高のオフィスになるでしょう。」というようなものです。 私の考えでは、これはクールなフリースタイルですが、技術的負債には現実主義が必要なため、しばしば惨事につながります。現実的に行わないと、疑似クールな建築のリヴァイアサンを作成してしまいます。 恐れ。これは、技術的負債の最も効果的で、広く普及し、効率的なモデルの 1 つです。怖いとき、ここでどんな「願望」を語ればいいのでしょうか？それは、障害やハッキングによってクライアントが離脱したなど、何かが起こったときのことです。そしてそれはすべて、低品質、ブレーキ、またはその他のせいです。しかし、恐怖をあからさまに売りつけるのも良くありません。恐怖を伴う憶測は信頼に反します。できるだけ誠実に、慎重に販売する必要があります。 信頼。それは、企業が技術的負債に取り組むのに必要なだけの時間を与えてくれるときです。信頼が機能し、維持されるのは、あなたが慎重に全体のシェアを小さくし、時間をかけてできるだけ現実的である場合に限られます。そうしないと信頼が崩れてしまいます。しかも溜まらない。一定のプロセスには波があり、信頼が高まったり、消えたりします。 次に、私の経験と、私と私の素晴らしいチームにとって何が機能しているかについて説明します。 技術的負債のウサギの穴はどれくらい深いのか? 3 年前に新しい会社に入社したとき、この技術的負債がどれほどのものであるかを理解する必要がありました。企業やパートナーからのリクエストも含めたリクエストの統計からその存在を知りました。一般的に何を扱っているのかを理解する必要がありました。 これは、技術的負債に対処するための通常かつ義務的な最初のステップです。最初に見つけたものを急いで実行すべきではありません。状況を全体的に分析する必要があります。 そのとき見た内容に基づいて、根本的な問題の 1 つは大規模なコードの結合であると推測しました。今ではこのプロセスに全員が関与することは少なくなりましたが、当時は制作チーム全体を集めて、アプリケーション スイートでどの層を強調したいかを修正していました。 私たちのアプリケーションには少なくとも 80 の異なるコンポーネント (インストールではなくディストリビューション) がありました。状況を把握した後は、対処する必要がありました。 フェーズ 1. 仮想チーム とても賢い私は、全員に時間があるふりをして、各コンポーネントを中心に仮想チームを結成するというアイデアを思いつきました。 「皆さん、どのコンポーネントを誰が担当しますか? それを改善する方法について提案を作成してください。」 というようなものでした。しかし、集中力を維持するために、私たちは全員で最初のフェーズを最適化するための基準を策定しました。 疎結合 コスト効率の高い拡張性 新しい開発者の簡単な接続 (シンプルかつ明確な原則: このコンポーネントで正確に何ができるか、何ができないか、さらに誰もが「触れる」ことができないコードの分離) 必要に応じて外部 API を使用する機能 提案された技術スタックのアクセシビリティ 現在のソリューションにおける QuickWin の最適化 監視とトラブルシューティングが容易 監査 + ライセンスの純粋性原則 バージョン管理と陳腐化の原則 もちろん、これは焦点ではなく、ソフトウェア開発のほぼすべての側面に対する一連の基準でした。リスト全体は、「すべてを修正してください」という 1 つのフレーズに置き換えることができます。 この段階は単に何も起こらなかったという意味で大失敗に終わりました。共有バックログを通じて計画を立てようとしていたため、いくつかのことの実装はほとんど進みませんでした。任務は理解不能だった。それらは手動で作業に投入されました。私にとってもチームにとっても大変なことであり、対立や議論が絶えず増大していることにすぐに気づきました。 ということで、フェーズ２に進みました。 フェーズ 2. 技術的負債は私のものです フェーズ 1 では、バックログ クォータを導入することに当社の CEO と同意しました。 70% をビジネス上の問題に、15% を欠陥の除去に、15% を技術的負債に費やします。 次に、前のフェーズで、全員が問題に責任を負う場合、その問題に責任を負う人は誰もいないことに気づきました。これは決して青臭い声明ではありません。私自身はそれが好きではありません。しかし、その逆には、非常に高いレベルの成熟度とチームワークが必要です。そこで私は技術リーダー制度を創設することにしました。 しかし、私は単にコンポーネントの技術リーダーに人物を任命したわけではありません。私は可能な限り私の期待を説明し、開発パスを定義し、本番環境の状況については彼らに責任を負わせました。本番環境でコンポーネントが混乱しても、OPS の専門家は目を覚ましていません。状況を解決しようとしているのはあなたです。 そして私たちは出発しました。技術リーダー（責任者）がいて、技術的負債の15％のノルマ（時間はあります）があります。しかし、現実は結局どうなったのでしょうか？ 私たちが最初に直面したのは、FinTech、コンプライアンス、職務分掌があるということでした。つまり、私と開発者は生産にアクセスできず、定義上生産にアクセスできないということです。それなのに、私は「皆さん、生産現場の状況の責任はあなたたちにあります！」と言います。 人々にログを与えましょう! 人々に責任を与えるときは、彼らの手にツールを与えてください。そして、それが私たちが OPS 専門家と協力して行った最初のことであり、技術者がコンポーネントのログを確認できるようにログを提供しました。 そして、私たちは本当に協力的な取り組みを行いました。これは、運用と開発が連携する DevOps への第一歩です。エクスプロイトではログ転送 (Kibana など) が設定されましたが、開発ではログに機密情報 (個人データなど) が含まれていないことを確認する必要がありました。 5% は幸運だと考えられています... 現実には、15% のノルマがあるにもかかわらず、「パートナーは今すぐ必要としている」という理由で、すべてのスプリントでビジネス クライシスと緊急の注入が発生し、そうでないと退職してしまいます。もちろん、この技術的負債は最初にスプリントから押し出されます。その結果、スプリントは 0% になりました。 15% のスプリントもありましたが、技術的負債は平均して 5 ～ 8% しかありませんでした。プログラマは実装にどれくらいの時間がかかるかを知ることができないため、これは大きな問題です。 私としては、すべてのチームの上空にたゆまぬ凧揚げをすることで、この状況を救おうと努めました。各スプリントの詳細なメトリクスを収集する方法を学び、最後にスプリントを確認しました。 スプリントのハッキングとは、技術的負債の割り当てが組織的に違反されることです。 1 回のスプリントでノルマが達成されなかったとしても、すべてが悪いというわけではありません。確かに、さまざまな状況があるため、柔軟な対応が必要です。 しかし、それが組織的に繰り返されたとき、私は生産の専門家を集めて議論し、割り当てが合意されたものであるため、それがいかに重要であり、容認できないかを説明しました。そのモデルでプロセスを動かすのが私の毎日の仕事でした。 そしてそれは動きましたが、今ではこのアプローチには独自の重大な欠点があると私は考えています。 アプローチの限界 プロダクトオーナーは、バックログはすべて自分たちのものであり、すべてのタスクは自分たちによって調整されるという事実に慣れています。「割り当ては適切ですが、この技術的負債の割り当てでチームが何をするかを決めるのは私たちだけです!」 そして、開発者がリファクタリングや定型文の削除などのタスク (強力な接続性について思い出してください) を思いついたとき、「何?! 定型文って? 何のことを言っているの?!」という論理的な反応がありました。 その結果、タスクは、技術的負債と呼ばれる可能性はあるものの、条件付きでベンダーにとって有益なタスクに置き換えられました。だからこそ、私は厳しい態度をとってこう言わざるを得ませんでした。「技術的負債は私のものです。そして、それは各スプリントの技術的負債の割り当ての各製品チームの技術的負債に含まれると主張します。」 そうやって私たちは生きてきました。普通に生活し、仕事もしていましたが、不信感は強くなっていきました。私たちが何かを行い、それが何であるかを誰にも言わず、ビジネスタスクに時間を費やさなかった場合、私たちがどのような結果をもたらすかは誰にとっても不明確です。 技術的負債の割り当て利用率に関する統計が急増していたため、私たちは大規模なプロジェクトを実行できないという事実に直面しました。さらに、大規模なプロジェクトには複数のチームが必要になることがよくあります。各製品チームは自社の製品に集中しており、その現実に生きているため、これも不可能でした。それらを複雑なトピックにドッキングすることは不可能です。 また、誰もスプリントにオペレーションを含めていませんでした。本番環境のようなスプリントやバックログはありません。彼らは生産に関するタスクに忙殺されていますが、それは全体の計画には含まれていませんでした。そして、本番環境に展開するための小さな技術的負債の範囲内で開発が行われた場合、それはかなり長い間 OPS の要求に残る可能性があります。 なぜなら、彼らには本当に時間がなく、追加のタスクが課せられ、仕事ができなくなったからです。 しかし、このアプローチにはマイナス面もありましたが、私たちはかなり多くのことを達成しました。 このアプローチで何が達成できたのでしょうか? まず、自動テストの筋肉量を構築しました。 CI プロセス全体を大幅に再設計することで、私たちはそれを恥ずかしくない文明的なプロセスにしました。 次に、多くのコンポーネントでスパゲッティ コードとの戦いを実装することに成功しました。 モジュール化を行い定型文を削減しました。これらのタスクは、恐怖があっても企業に売り込むことはできません。製品の技術ギャップにこれらの問題が含まれており、それらを修正する必要がある場合 (問題がある場合は、最初に修正する必要があります)、製品を販売しようとする必要さえありません。それは「技術的負債 - それは私のもの」モデルを通じてのみ、割り当てを通じてのみ実行できます。 私は多くの試みを見てきましたが、最初のフェーズでは自分自身で別の方法でやろうとしました。うまくいきませんでした。 実際、このモードでの作業は長時間続けることはできません。それは、CTO およびチームリーダーとしてあなたを信頼して、経営陣があなたに与える限られた白紙の決断です。 フェーズ 3. 正当なプロジェクト 次に、技術的負債に取り組むための「正当な」プロジェクトであるフェーズ 3 を開始しました。前提条件は、クローズドクォータから脱却し、共通の製品バックログを通じて計画を立て（つまり、製品所有者がこれらのプロジェクトを実行する必要があることを認めている）、クリーンセールに移行するということでした。これを実現するために、次の 2 つのことを行いました。 このプロジェクトの枠組みの中で、私たちが着手する仕事の範囲を可能な限り絞り込みました。 私は本番環境で何のために戦うのかについて具体的な期待を立てました。私たちのタスクはできる限り実用的で、理解しやすく、ビジネスの観点からサービスに役立つものでなければならないため、これは理想主義の完全な拒否でした。 重要な点は、私たちは技術的負債のビジネス価値を計算しようとしているような錯覚を抱いているということですが、これはめったに可能ではありません。それでも計算できる場合は、悪夢のような技術的負債が存在することになります。 ビジネスには、負の値よりも正の値の方が効果的です。 「このクライアントは去っていきます。彼は大金をもたらしてくれます」と言ったとしても、彼が去るまでは機能しません。それはビジネス上の価値ではありません。また、リスクを承知で仕事をする文化がまだあまり高くないので、「辞めるまで損はしない」というモードです。 ビジネス価値を示す必要もありません。どこで見せられるかというと、技術的な価値を見せられるのは計算されたものだけ。 技術的負債の売却方法に関するガイド 技術的負債を販売するこのフェーズのワークフロー全体を次に示します。 重点分野を選択してください (1 つだけ) これは恐怖によって販売されているため、ビジネスに実際に影響を与える分野を選択してください。可用性、やり直しの速度、A/B テストと実験の安全性、やり直しのコストなど、分野はさまざまです。膨大な数の分野とトピックがあります。 私の場合、アクセシビリティを選択したのは、それがビジネスの注目を集めており、当社のサービスにある程度の影響を与えるためでした。自分の考えを薄く広げたり、トピックを 1 つだけ選択したりしないことが重要です。 統合分析を行う 私はその年の可用性とインシデントの統計を分析し、年間を通じて発生したすべての状況についてすべての事後分析を詳細に分析しました。その後、私は技術的に可能な限り、しかし再び実質的に取り組む必要があるものについて、トップレベルの理解を形成しました。 可用性の第一のルールは、常に利用可能なシステムを構築しようとするのではなく、インシデントが発生したときに備えられるようにすることです。それが私たちが保証しなければならないことです。 可用性の 2 番目の問題および基本ルールは、劣化協定です。いつか何かが必ず起こるので、提供する機能の一部を放棄することを犠牲にしても、サービスを維持する準備ができていなければなりません。この合意はプログラムレベルも含めて維持されなければなりません。 3 番目の問題は、監視と可観測性に関するものです。これは、インシデントの発生源の迅速な位置特定と応答の検出時間です。不安定なテストが多数ある場合は、モニタリングを信頼するのをやめる必要があります。本番環境のテストに、「5 分経っても電源が入らない場合は電話してください」などのサービス デスクの対応に関する指示が含まれている場合、本番環境の状況を監視していることにはなりません。テストはできる限り明確にする必要があります。「それは、どこかに問題があることを示しています。それでは、行きましょう!」 コンポーネントごとの分析を行う この目的のために、私たちは各方向とコンポーネントに対して具体的に何を行うかを策定しました。これは、サービス メッシュをどこにドラッグするか、監視をどのように変更するか、何を基準にするかを意味します。ここでは約 15% を列挙しましたが、実際にはプログラムの改善が数多くあります。 すべてを準備しましたが、まだ市場に出すことはできません。それを公然と公開するために、私たちはこのフェーズの各プロジェクトに対して次のことを行いました。 実質的かつ定量的な指標の策定 私たちは定量的な指標を非常に恐れています。定量的な指標で開発者の仕事の質をどのように測定できるのでしょうか?定量的指標に対しては多くの議論がありますが、それを真正面から受け止めるべきではありません。 価値をビジネス上の価値としてのみ捉えるべきではありません。これらは、たとえば、「X 件以下の誤検知」と表現できます。 カナリア リリースを提供するか、保証されたパッチ ロールバックを保証する機能を提供することが重要なコンポーネントの特定のセットをリストできます。もちろん、全体的な可用性は定量的な指標である必要があります。それは絶対必要です。 プロジェクトを守る この一連の実用的なプロジェクト、可能な限り明確な指標と達成する必要のある結果について、私はこう言いました。「皆さん、私には技術的負債の割り当てが必要です。これらのプロジェクトをあなたのプールに含めて、プロジェクトを加速して、ビジネス目標とともに、完全に法的根拠に基づいて全体的な計画を立ててください。」 それは聞き入れられ、私たちは実行し、そしてうまくいきました。フクロウの描き方動画「楕円と二本の破線を描く」に似ていると思います。最後には - 魔法 - あなたはフクロウを手に入れます!しかし、すべての魔法は、このプロジェクト全体を成功させて最後までやり遂げなければならないということです。 この方向に向かって何かをするだけではなく、それを結果に結びつけます。つまり、定められた定量的指標を達成し、それを示すことです。この深淵は95%の確率で飛び越えることができません。完全にジャンプする必要があります。 このアプローチの利点 それで、私たちは（深淵を越えて）ジャンプし始めました。私たちはそれを成功させています。現在、このプロジェクトは第 2 ラウンドに突入しています。つまり、最初のプロジェクト プールをドラッグし、2 番目のプロジェクト プールについて合意しました。変化したこと？ 信頼を高める 実際の定量化可能な指標を示すと、オープン性を通じて信頼が大幅に高まります。しかし真実は、技術的負債の売却は恐怖からやって来るということです。このステップは避けることができません。しかし、それを恐れたり恥ずかしがったりする必要はありません。重要なことは、さまざまな段階（総合分析、コンポーネントごとの分析）で示したように、恐怖を推測することではなく、実際に分析することです。 大きなプロジェクトを実行する これらは現在、正当なプロジェクトであるため、チーム間で同期して、非常に大きなプロジェクトを実行できます。一部のプロジェクトはスプリントからスプリントへと順番に実行されました。私たちはテクノロジーチームの構成によってプロジェクト内で定期的に (週に 1 回) 追跡され、誰がどこに (どのフェーズに) いるかを把握しています。 この情報は可能な限りオープンかつ透明です。プロジェクトの進捗状況と現在のステータスは公開され、製品所有者 (およびそれを見たい人は誰でも) が利用できます。 プロジェクトの OPS 担当者 最も重要なことは、インフラストラクチャと展開プロセスにおいて再設計しなければならないことがたくさんあることに気づきました。 OPS のユーザーはこのプロジェクトに明示的に含まれていました。 私の考えでは、OPS 担当者がコンポーネントのアーキテクチャを変更する方法を開発者と話し合ったり、開発者が OPS 担当者とインフラストラクチャを変更する最善の方法を話し合ったりする場合、これは Kubernetes や Docker よりも DevOps です。 なぜすぐにやらなかったのか? ここで、フェーズ 2 の終わりに話していたことに戻ります。以前は機能しなかっただろうということです。なぜなら、フェーズ 2 で行ったこと (再設計したスパゲッティ コード、テストの強化、CI プロセスの再設計) を、測定可能な指標に関してビジネスに売り込むことは不可能だったからです。 この状況は、特別な恐怖に対応するものではなく、「スパゲッティ コードだからコードを書くのに時間がかかる」という私たちの標準的な議論には、業界の誰も耳を傾けませんでした。したがって、そのアプローチを引きずることはできなかったでしょう。 私の観点からすると、これほど大規模なインフラストラクチャの再作業が必要なテクノロジー プラットフォームがある場合、フェーズ 2 を避けることはできません。 やり遂げなければなりませんが、常に凧のように飛び回るだけでなく、ビジネスの信頼を失わないようにすぐに店を閉める準備ができていなければなりません。