開発者はコードを「修正」するのが大好き—それが問題な理由

すべての製品は、独自の不思議な方法で進化します。経験豊富なチームであっても、製品ライフサイクルのすべての変化を予測することはできません。単純な機能が、巨大な多条件ワークフローに変換される可能性があります。急速に開発されたいくつかのサイドシナリオが最も使用されるものになることもあります。製品の人気によって、予期しないパフォーマンスの問題が発生することもあります。市場のニーズに合わせてソフトウェアを適応させることは、まったく普通のことです。信頼性が高く予測可能な製品を実現する唯一の方法は、技術的負債を修正し、適切なリファクタリングプロセスを提供するために時間を確保することです。

この記事には用語の定義をいくつか含めた方がよいでしょう。技術的負債、または技術負債とは、コードベースに蓄積された妥協のことで、急速な開発やその他の変動中に発生する可能性があります。リファクタリング プロセスは、製品全般の改善に関するものです。パフォーマンス、コード構造の改善、ソリューションのシンプルさに関連するアクティビティが含まれる場合があります。ただし、これら 2 つの概念は非常に近い場合があります。たとえば、技術的負債に満ちたいくつかの機能では、新しいアイデアと再実装によって問題を完全に解決するために、モジュール全体を適切にリファクタリングする必要がある場合があります。

そして、ここに秘訣があります。一般的に、優秀なソフトウェア開発者は、製品の改善についてたくさんのアイデアを持っています。「よし、この機能中にいくつか微調整できるな」「ああ、それはそれほど重要ではないけど、このサイドモジュールのこの部分を修正するといいな」。それでも、チームメンバーにコードベースを強化する機会を与えることは、本当に関与するチームの構築に役立つため、非常に重要です。しかし、この記事では、マネージャーの観点からリファクタリングプロセスを明らかにしたいと思います。上記の例には1つの問題があります。開発者以外のチーム全体にとって不透明である可能性があるということです。QAとマネージャーは、適切で安定したソフトウェアをスケジュールどおりにリリースする計画を立てていますが、隠れた改善によって、リリース中に予期せぬひねりや緊張した再テストが発生する可能性があります。または、回帰段階を経て、文書化されていない変更が気付かれないままになると、本番環境で新しいバグが発生することもあります。したがって、コードの改善は必要ですが、管理可能である必要があります。

チーム内で管理可能なリファクタリングプロセスを構築する方法

解決策は複雑です。アジャイルは私たちにとって最高の味方です。なぜなら、アジャイル開発方法論の共通原則と手順で問題点をカバーできるからです。次のことが必要です。

1. 技術的負債のバックログを構築し、定期的にリソースを割り当てます。
2. 潜在的な改善点を発見するために、適切なグルーミングと計画のプロセスを確立します。
3. 反復中に予期しない問題が発生した場合に備えてプロセスを宣言します。

グルーミングとは、反復の前にチーム メンバー間で行われるコミュニケーションのことで、反復の範囲の定義、要件の指定、タスクの分解、作業量の見積もり、将来の作業項目の優先順位付けを目的としています。計画プロセスは、反復の最終的な範囲と関連しています。グルーミングされたすべてのタスクが反復に含まれるとは限りません。

それぞれのトピックについて詳しく見ていきましょう。

技術的負債バックログとリソース割り当てルールの構築

すべての開発者が技術的負債のバックログを作成する最も簡単な方法は、ソースコードで「To do」タグを使用することです。その後、コードベースを検索し、何かを改善し、承認のためにプルリクエストを送信できます。しかし、それだけでは十分ではありません。チームメンバーが適切な計画を立てたり、リリースの範囲を確認したりするのに役立ちません。

「To Do」を使用するよりも良い方法は、将来の変更のためのタスクを作成するプロセスを確立することです。開発者が潜在的な問題箇所を見つけたり、コードベースを改善するためのアイデアを持っている場合は、チケット システム (Jira、Azure DevOps、またはチームが使用している任意のシステム) に作業項目を作成する必要があります。エンジニアにチーム メンバー全員にアイデアの詳細な説明を求めるのはやりすぎですが、説明はチーム リーダーが変更の要点と範囲を理解できるほど明確である必要があります。これは、最初のステップ、つまり潜在的なタスクのリストを作成し、将来の変更の概要を説明する方法をカバーしています。

ステップ 2 は、誰もが理解できるようにすることです。このタスクは、資格に応じて、開発チーム リーダー、リリース マネージャー、または製品マネージャーが担当できます。結果には、次の詳細が示される必要があります。

• 私たちは何をしているのか？ - アイデアの高レベルの説明。
• なぜこれを行っているのか? - これらの変更によって、開発速度が向上し、スパゲッティ コードによる不安定性のリスクが軽減され、ソフトウェアのパフォーマンスが向上する仕組みについて説明します。
• これらの変更は将来の開発にとってどの程度重要ですか? - 変更の優先順位。たとえば、これらの変更を行わないと、将来の改善やビジネス機能のコストが飛躍的に増加する可能性があります。
• これらの変更によってどのようなリスクが生じますか? - QA による変更の検証に役立つ、影響を受ける機能またはモジュールのリスト。

作業項目にこれらすべての質問に対する答えがあれば、将来起こりうる問題を軽減するのに役立ちます。ただし、バックログがあるだけでは、管理可能なリファクタリングには不十分です。起こりうる変更を計画する必要があり、それらはプロセスの一部として常に存在する必要があります。もちろん、ビジネス機能や市場の需要のプレッシャーに直面することになり、技術的なタスクを省略したくなる誘惑に駆られます。しかし、適切なメンテナンスがなければ、将来さらに大きな問題に直面することになります。

技術バックログ プロセスの推奨事項は次のとおりです。

1. すべての反復において、チームは技術的な改善のために時間を確保する必要があります。

2. 改善のアイデアがある場合は、適切な説明を添えて作業項目として正式に定義する必要があります。

3. 作業項目はグルーミング プロセスに参加し、すべての利点とリスクが特定され、すべてのチーム メンバーからの見積もりが収集されるまで、チーム全体で議論する必要があります。

4. 作業項目は、見積もりに従ってアジャイル反復に計画される必要があります。

   
   

チームは、イテレーションで発生する可能性のある技術的負債の量を認識する必要があります。予約時間は必要に応じて増やすことができますが、通常の量よりも少なくしてはいけません。これにより、エンジニアがバックログに新しいタスクを作成し、優先順位を付けるようになります。誰もが、自分の提案が実装され、バックログが士気を低下させる巨大なリストに成長するのではなく、いつかは縮小することを知っています。

潜在的な技術的負債の開示のためのグルーミングと計画のプロセスの使用

時には、議論や見積もりの過程で技術的負債のタスクが明らかになることもありますが、チームは予期せぬ障害に直面し、実現の信頼性と柔軟性が低下します。たとえば、類似の機能があり、まったく新しい機能を作成するとコードベースが悪化するだけだと気付くかもしれません。しかし、それらの機能には、新しい機能に必要なビジネス機能は含まれていません。将来のメンテナンスを簡素化するために、すべての類似機能を接続する統合サービスを作成する方がよいでしょう。それでも、この変更は古い機能に影響を与え、不安定にする可能性があり、そこに課題があります。おそらく、欠陥に目をつぶって、安価に新しい機能を開発する方法があるでしょう。または、類似機能が少数しかない今こそ、統合サービスを作成する絶好の機会かもしれません。最も重要なことは、明らかにされた事実と適切に整えられた見積もりに基づいてチームメンバーが決定を下すのに役立つプロセスを確立することです。コミットされたバックログの実装フェーズでそのような決定を採用する必要がある状況を防ぐシステムを持つことが重要です。

反復段階がうまく機能すれば、適切なグルーミングと計画プロセスを通じて、そのような瞬間の開示が自動的に行われます。ほとんどの場合、予期しない障害からチームを守ることができる基本的なルールと手順がいくつかあります。

1. グルーミング バックログには、明確で実行可能な要件を持つタスクが含まれている必要があります。
2. グルーミング バックログは、議論や見積もりの前にチーム メンバーと共有する必要があります。
3. チームメンバー全員がグルーミングの前に準備し、タスクに精通している必要があります。
4. バックログ項目で追加の調査や再実装が必要な場合は、その懸念事項について話し合う必要があります。
5. 問題のあるバックログ項目の要件は、明らかになった特殊性に基づいて確定する必要があります。潜在的な問題領域はすべて文書化する必要があります。
6. 各バックログ項目を見積もる必要があります。

問題のあるバックログ項目は、個別のタスクに分解し、優先順位に従って計画することができます。実装戦略に関する決定は、リスクと期限に応じてリリース マネージャーに委ねられる場合があります。ただし、このアプローチは、すべての決定を文書化するのに役立ちます。技術的負債タスクが延期された場合でも、バックログに追加されます。後で、これらのタスクを確認してスケジュールする必要があります。このプロセスにより、忙しい反復中に優れた必要なアイデアが忘れられてしまうシナリオが修正されます。

反復中に予期しない問題が発生した場合のプロセスを確立する

それでも、技術的負債のバックログが適切に管理され、整備と計画のプロセスが機能している場合でも、開発中に予期しない時間のかかる障害に遭遇する可能性があります。ソフトウェア製品は、特に古いものや豊富な機能を備えているものなど、複雑になる可能性があります。

アジャイル プラクティスを使用すると、情報を早期に収集し、適切な決定を下すことができます。最も簡単な解決策の 1 つは、毎日の会議です。

エンジニアが何らかの問題に直面した場合、その問題は会議中に取り上げられ、後で議論される必要があります。障害はそれぞれ異なり、かかる時間も異なります。変更が「あったらいい」機能ではなく現在のイテレーションで実装されるか、イテレーション スコープの完全な見直しが必要になるかは問題ではありません。問題は、追跡システムで一般的な技術的負債タスクとして作成し、以前の記事の他の同様のタスクと同様に分解して説明する必要があります。一貫性が鍵であり、チームはこれらの状況に対処する方法を知っておく必要があります。

官僚機構の増大に対する批判とそれに対する対応

これらすべての方法は、無駄な官僚主義でチーム全体の時間を奪うための追加の方法のように思えるかもしれません。そして、厳格で明確なルールがないため、誰もが苦労しなければ、そうかもしれません。短期プロジェクトや最小限の価値ある製品 (MVP) の段階では、これらの推奨事項に従わなくても問題ありません。ただし、品質責任と大規模な製品を扱う生産現場では、明確に定義された内部プロセス システムが必要です。最も一般的な反論について見ていきましょう。

このようなタスクの作成には時間がかかり、記述するよりもコードを変更する方が速い場合もあります。

それは本当です。タスクを自然言語で記述することは、コードを修正するよりも難しい場合があります。しかし、ここにいくつかの解決策があります。

• チケット システムにテンプレートのシステムを作成すると便利です。これにより、タスクをすばやく追加し、正しいパラメーターとリンクを入力できるようになります。
• Confluence / Notion / SharePoint などの企業 wiki やその他のチーム ドキュメント プラットフォームにチケット ポリシーをいくつか用意しておくと便利です。これらのページは、正しく作成されたタスクの良い例になります。チーム リーダーにとって、技術ドキュメントを維持し、テンプレートを洗練させて、他のチーム メンバーが明確で理解しやすいチケットを送信できるようにすることが最善の策です。
• 基本的なレベルでは、エンジニアに、戦略ビジョンや提案の可能性に関する詳細な記事を書かずに、高レベルの説明でタスクを作成するように義務付けるだけで十分です。説明は、レビュー担当者 (通常はチーム リーダー) が変更の主なアイデアを理解するのに役立ちます。その後、チーム リーダーは提案を検証し、プロセスに従って詳細を追加できます。これにより、これらの変更が本当に必要かどうかを理解するのにも役立ち、品質フィルターも提供されます。
• 開発者に提案を実装する時間がある場合、機能ブランチ ポリシーは非常に役立ちます。それでも、チケットで名前が付けられた機能ブランチを作成するためのルールがあると便利なので、タスクを作成する必要があります。しかし、その結果、予期しない不安定化のリスクなしに、適切なイテレーションで検証のために整備および計画できる技術的負債、チケット、およびリンクされた実装の一部を実装した満足のいくエンジニアが得られます。

これらの変更はすべて非常に技術的であり、説明だけでは誰も理解できないため役に立ちません。

おそらくそうでしょう。しかし、それは説明次第です。何がうまくいかないか、どの機能が不安定になる可能性があるかを説明することが優先されます。ただし、変更の影響について書くことは、追加の可能性やシナリオを特定するのに役立つため、役に立ちます。また、最も技術的なアイデアであっても、自然言語を使用して簡単な文章で説明できます。それができない場合は、アイデア自体に問題がある可能性があり、それが潜在的なリスクになる可能性があるため、提案全体を再検討する必要があります。

次のように書いてください:

「メソッド「XXX」は、呼び出しごとに大量の RAM を消費します。このメソッドに追加のキャッシュを作成すると、RAM の消費量が減り、すべての API が高速化されます。このメソッドはめったに変更されないデータを使用するため、再起動時にキャッシュを削除するだけで十分です。変更は安全ですが、次の機能に影響する可能性があります: XXX、XXX、XXX…」。

場合によっては、これで十分でしょう。しかし、他の場合には、この提案が議論のきっかけになるかもしれません。エンジニアが、このキャッシュが問題を引き起こす可能性のある、古くてまだ使用されている機能を忘れている可能性があるからです。グルーミング プロセス中に、アイデアは修正され、チームは妥協点を見つけます。

これらのポリシーはすべて、ユーザーが新しい拡張機能を受け取ることを妨げるだけです

安定性と信頼性は、一部の機能の実行時間を数パーセント改善することよりも重要です。潜在的なパフォーマンスの向上を逃してもがっかりする人はいないでしょうが、製品の評判を傷つけるのは簡単です。

99.99% のケースで決して害を及ぼさない単純なコード スタイルのために、このような官僚主義が必要なのでしょうか?

目的は、プロセスを合理化し、リスクの評価を支援することです。エンジニアには、コードベースを保守し、いくつかの改善を行う機会を与える必要があります。製品全体を不安定にしない小さなものについては、反復中に完了できる集約的な作業項目を作成することができます。これらのタスクはプル リクエストとしてレビューする必要がありますが、チームに正式に通知する必要はありません。

結論

継続的な製品の改善はビジネスにとって重要であり、全体的な品質の維持に役立ちます。技術的負債と新しいアイデアを棚上げにしておくと、時代遅れの製品に悩まされ、すぐにそれを保守する専門のエンジニアを見つけるのに苦労することになります。

一方、これらのタスクは、ビジネスを新たな地平へと導く可能性のあるビジネス機能やその他のアイデアと競合します。技術タスクのバックログに関するこれらの推奨事項は、チームメンバーだけでなく利害関係者にとってもこれらのタスクの重要性を明らかにし、評価するのに役立ちます。これらのアイデアを自然言語で提示し、実装の時間を確保および保護するのに役立ちます。エンジニアには追加のアクションの負担がかかりますが、最終的にはチーム全体が高品質で信頼性の高い製品を提供するのに役立ちます。そして、マネージャーの責任は、このプロセスを維持するために適切な手段またはポリシーを選択することです。