次の方法で共有

コードのクリーンアップ

  • [アーティクル]

アジャイルな手法を使用して技術的負債を返済する

David Laribee

すべてのコードベースには、暗くて恐ろしい隠れた場所や小道があります。非常に脆弱なコード、回帰バグが発生するコード、および処理をたどろうとするとイライラしてしまうようなコードのことです。

Ward Cunningham は、コードの、変更が困難でエラーが発生しやすい部分を金銭的負債ににたとえて、みごとな隠喩を作りました。技術的負債があると、前に進んだり、利益を得たり、"黒字" の状態を維持したりすることができなくなります。現実世界と同様に、安い負債もあります。低リスクの金融商品よりも利率の低い負債です。また、負債をさらに増やしていく高利率のクレジット カード料金のような、高い負債もあります。

技術的負債は足手まといであり、生産性を低下させ、保守を厄介、困難、または、場合によっては不可能にすることがあります。技術的負債には、明らかな経済的マイナス面に加えて、真の心理的な代償もあります。非常に脆弱で複雑なソース コードを扱うことになるとわかっていながら、朝、喜んでコンピューターの前に座る開発者はいないでしょう。こうして生まれたいら立ちや無力感は、より体系的な問題 (開発者の離職率など) の根本原因である場合がよくあります。開発者の離職率は、技術的負債の真の経済的な代償の 1 つに過ぎません。

私が作業やレビューを行ってきたコードベースはすべて、ある程度の技術的負債を含んでいます。ほとんど害のないタイプの負債もあり、その 1 つが、システムの奥深くの安定的でめったに修正されない場所にある奇妙な名前の付いた型間の入り組んだ依存関係です。もう 1 つは、その場で容易に修正可能だがより優先順位の高い問題に対処しようと急ぐあまり無視されることの多いずさんなコードです。他にも例はたくさんあります。

この記事では、高利率の負債に対処するためのワークフローといくつかの方法について概説します。ここで紹介するプロセスやプラクティスは目新しいものではなく、リーン/アジャイル戦略からそのまま採用したものです。

負債を修正する必要がある理由

私の意見では、「技術的負債は修正する必要があるか」という質問は、考えるまでもない非常に簡単な質問です。もちろん修正する必要があります。技術的負債は時間の経過と共に作業速度の低下をもたらすため、目標の妨げとなります。変更コスト曲線と呼ばれる有名なグラフ (図 1 参照) があります。これは、"完ぺきな品質を追求するテスト駆動型の" アプローチと "いいかげんな仕事をするプログラマが補修テープで繕うようにしてずさんなプログラムを適当に作る" アプローチの違いを示すものです。

Cost of Change Curve

図 1 変更コスト曲線

変更コスト曲線は、品質が高く単純で従いやすい設計の方が、初期コストは高い可能性があるが技術的負債は少ないことを示しています。コードへの後からの追加や修正のコストは、時間の経過と共に低くなります。"高品質" アプローチの曲線 (青) では、初期コストはもう 1 つの曲線よりも高いですが、時間の経過と共にコストが予測可能になることがわかります。"適当に作る" アプローチの曲線 (赤) では、初期コストはもう 1 つの曲線よりも低いですが、将来の開発、保守、および製品とそのコードの総保有コストは、時間が経過するにつれて高くなります。

Ward Cunningham の「プログラミングの第 1 原則」(c2.com/cgi-bin/wiki?FirstLawOfProgramming、英語) には、"品質を落とすと開発期間が長くなります。" という言葉があります。また、次のような言葉があります。

"高品質のソフトウェアは、開発にかかる期間が最も少なくて済みます。できるだけ単純なコード、徹底的なテスト、および適切な設計があれば、影響が最小限に抑えられるので、可能な範囲で最も速い方法で追加や変更を行うことができます。したがって、適当に作ったものの量が多くなればなるほど作業速度は低下します。コード 1 行ごとに追加や変更のコストが増大するためです。"

簡単に言うと、技術的負債は時間の経過と共にスループットを低下させます。

私にとって、ソフトウェア開発の大きな喜びの 1 つは、すばらしい生産性の感覚を味わうことです。その対極にある感覚は (少なくとも私にとっては)、苦痛です。生産的でないとき、私は苦痛を感じます。そして、私から潜在的な生産性 (いわゆる "仕事が順調な日") を奪うのは苦痛です。ソフトウェア開発には苦痛の原因はたくさんありますが、柔軟性のない雑然としたコードベースほど明白な原因は他にありません。この心理的影響はチームの士気に大きな悪影響を与え、その結果、生産性が低下します。

体系的な思考

技術的負債を修正するためには、利害関係者とチームメートの両方から同じように積極的な参加を引き出す必要があります。そのためには、体系的に考える必要があります。体系的な思考は長期的な思考であり、投資的な思考です。体系的な思考は、今日の努力によって、将来、予測可能かつ持続的なペースで進歩することが可能になるという考え方です。

体系的な思考については、たとえ話で説明するのが一番わかりやすいかもしれません。私は、ジョージア州アトランタの中心街にあるインマン パークと呼ばれる古風な趣のある小さな地区に住んでいます。私は、そこでの暮らしの大部分については、非常に満足しています。ですが、都市計画が完全に無視されているように思えることに関して、多少のいら立ちを感じています。アトランタの通りは、迷路のように入り組んでいて、イライラさせられます。曲がるべき場所を通り過ぎてしまったら、簡単に引き返すことはできません。引き返すと、たちまち道に迷ってしまいます。この地区は他の面では非常に快適ですが、道路の計画にはほとんど道理も分別もないように思われます。

これを、ニューヨーク市マンハッタンの整然とした東西方向、南北方向の通り (ほとんどは、ですが) と比べてみてください。この都市はまるで、米国海兵隊の訓練教官が設計したようです。南北方向の通りはマンハッタン島全体の長さいっぱいに伸び、それに交差する東西方向の通りは、整然とした緯度方向の指標となっています。さらに、東西方向、南北方向どちらの通りにも、番号順に名前が付けられています。1 番街、2 番街、42 番通り、43 番通り、という具合です。間違った方向に進んでしまった場合、1 ブロック以上歩いても気付かないことはめったにありません。

この面について比較した場合の、アトランタとニュー ヨーク市の違いの根本原因は何でしょうか。

アトランタの通りは、牛の往来により地面がすり減ってできた道から作られました。聞き間違いではありません。"牛の道" です。都心と郊外の間を頻繁に行き来する必要性が生じ、そこで、あるカウボーイが「こういう牛の道を道路にしてしまうのが一番簡単なのではないか」と考えたのです。

ニューヨーク州議会は、ビジョンと将来への深い思慮を持って、成長し続けるニューヨーク州最大の都市ニューヨークを設計しました。州議会は、整然とした予測可能な東西方向、南北方向の通りを作るという格子状計画を採用することに決めました。将来のことを考えていたのです。

この話は、体系的な思考の本質をとらえています。立法手続きは時間がかかりますが、ビジョンに時間と労力をつぎ込むと、システムの存続期間全体にわたって最大の利益が生まれます。確かに、マンハッタンの危険な通りでは厄介なタクシーに対処しなければなりませんが、数日中には自分でどこへでも行けるようになるでしょう。アトランタでは、私は住み始めて 1 年が経過した今でも道に迷います。そして、Global Positioning System (GPS) にかかわっている体系的な思考をする人たちに毎日感謝しています。

プロジェクトではなく製品という考え方をする

開発チームはプロジェクトを完成させたらあとは保守チームに任せるという考え方は、根本的に間違っています。誤解しないでください。皆さんは製品を扱っているのであり、よくできた製品は非常に長い間使われ続けるのです。

2 ～ 3 年でもプロの開発者としての経験がある方なら、おそらく重大性増大効果を経験したことがおありでしょう。長持ちしたり複雑になったり変更されたりすることを意図せずに、ソフトウェアを作成したとします。6 か月後、皆さんは何をしているでしょうか。このソフトウェアの修正でしょうか。拡張でしょうか。バグの修正でしょうか。

役に立つソフトウェアには、非常に長い間使われ続けるという、場合によっては厄介な性質があります。これから言う隠喩のどちらを選ぶかは、皆さんしだいです。生き物たちが何百年も暮らし続け最盛を極めている美しいセコイアの森を手入れしますか。それとも、容赦のないクズのつるに覆われてこの森に光が届かなくなるのをそのままほうっておきますか。

基本的なワークフロー

ここまでの説明をお読みになって、技術的負債が皆さんの精神衛生にも顧客の最終的な収益にも大きな打撃を与える可能性があることがわかっていただけたのではないかと思います。また、作成している製品をより長い目で見る必要があることも理解していただけたのではないかと思います。

では、どうすればこの窮地から抜け出すことができるかについて考えていきましょう。

私は、職場を問わず、技術的負債に対処するための基本的なワークフローは (それどころか、あらゆる種類の改善は) 反復可能だと思っています。基本的に、次の 4 つの作業を行う必要があります。

  1. 負債のある場所を特定します。それぞれの負債項目は会社の最終的な収益とチームの生産性にどの程度の影響を与えているのでしょうか。
  2. 投資対効果検討書を作成し、優先順位に関して、その負債の影響を受ける人たち (チームメートと利害関係者の両方) と合意を築きます。
  3. 実績のある方法で、選択した負債を真っ向から修正します。
  4. 繰り返します。手順 1 に戻ってその他の負債を特定し、既に行った改善については現状を維持します。

これを読んでいらっしゃるソフトウェア プロセス マニアの方々のために、このワークフローは、Eliyahu Goldratt (http://www.jp.goldrattconsulting.com/) が作り出した制約条件理論 (ToC) と呼ばれるビジネス管理アプローチを基にしたものであることをお伝えしておきます。ToC は、システムの全体的なスループットを向上させるためのフレームワークを提供する体系的思考モデルです。非常に簡単に言ってしまうと、ToC は、システム (たとえば製造工場) の最大のボトルネックがそのシステムの生産性の上限となるという考え方に基づいています。価値 (機能要求や、自動車のような売れる製品など) は、考案され、設計され、生み出され、展開されます。(内部または外部の) 顧客から機能の要求があると、その機能はビジネス (システム) を経由して、アイデアから具体的な結果に変わります。こうした機能が品質保証チームの前に山積みになったらどうなるでしょうか。開発の需要が、開発チームが満たせる需要の量を超えてしまったら、どうなるでしょうか。ボトルネックが発生し、システム全体の速度が低下します。

負債のある領域がコードベース内に多数存在する (ボトルネックが多数存在する) 可能性は大いにあります。最も速度を低下させる負債を見つけると、スループットの向上への最終的な影響が最も大きくなります。負債、およびそれに対処することによって生じる改善をチームとして (システムとして) 理解し、チームとして (システムとして) これに対処することが、プラスの変化をもたらすための最も効果的な方法です。コードを確認したりコードに手を加えたりする人の数が多ければ多いほど、リスクは低下し、設計はより優れたものになるからです。

負債のある領域を特定する

問題領域を指し示すことができることは重要です。Wiki、共有のリスト、コード コメントなどで問題領域を追跡していない場合は、まず、負債を見つけることから始める必要があります。

チームで作業している場合は、ミーティングを開いて、コード内の負債のトップ領域を示す具体的なリストを作成することをお勧めします。網羅的なリストを作成することは重要ではありません。高コストの項目をとらえることに重点を置いてください。このミーティングは、皆さんがチームのリーダーとして合意を築き始める最初の機会です。ある項目をリストに載せるには、過半数を超えるメンバーが同意しその項目を理解する必要があります。

作成したリストは、長持ちさせます。Wiki のトピックを作成する、ホワイトボードに書く (片隅に目立つように "消さないでください" とも書いておく) など、各自の状況に合った方法を使用してください。選択する媒体は、見やすく、永続的で、使いやすいものであり、定期的に目に入る必要があります。このリストを見直し、手を入れて良い状態に保つ必要があります。人間の短期記憶の量は限られているので、最も厄介な項目のうちの 5 ～ 9 個を記載したリストを保持することをお勧めします。すべての項目から成るリストを作成することについてはそれほど心配しないでください。重要な項目は、本当に重要なら、再び表面化します。

指標を使用して問題領域を見つける

負債を見つけるのは困難な場合があります。チームが当該のコードベースに不慣れな場合は特にそうです。利用できる集団的記憶や口伝えの慣例がない場合は、NDepend (ndepend.com、英語) などの静的分析ツールを使用して、コードを調べて特に厄介な場所を確認することができます。

ツールは、よく言っても補助的なものであり、2 番目の候補とさえ言えるかもしれません。ツールは、するべきことを教えてはくれません。ですが、意思決定のための情報は与えてくれます。コードの負債に関する単一の指標はありませんが、ある製品を来る日も来る日も扱っている方々ならきっと、最大の苦痛をもたらす暗い隠れた場所を指摘することができるでしょう。静的分析ツールを使用すると、実装の負債がある場所を知ることができます。残念ながら、こうしたツールでは、設計やアーキテクチャに関する、より質的な考慮事項 (不適切な名前付け、見つけやすさ、パフォーマンスなど) が原因となって生じる負債の場所を知ることはできません。

(テストがある場合は) テスト カバレッジを知ることも、隠れた負債を見つけるための重要なツールとなる場合があります。テスト カバレッジが十分でない箇所がシステムの大部分を占める場合、変更が次のリリースの品質に劇的な影響を与えないという確信が持てないことは疑いようもありません。回帰バグが発生する可能性があり、QA にとってのボトルネックが発生したり、顧客が見つけた欠陥によって決まり悪さや収益の損失が生じる可能性が生まれたりします。

バージョン管理システムのログ機能を使用して、過去 1 ～ 2 か月間にわたる変更のレポートを生成してください。システムの中で最も手が加えられる (変更や追加が行われる) ことの多い部分を見つけ、このような部分を詳細に調べて技術的負債がないかどうか確認します。これは、現在問題となっているボトルネックを見つけるのに役立ちます。システムの中のめったに変更されない部分にある負債を修正しても、ほとんど価値はありません。

人的ボトルネック

あるコンポーネント、サブシステム、またはアプリケーション全体に対処できる開発者が 1 人しかいない場合、ボトルネックが発生する可能性があります。個人がコードを所有していたり、1 人 1 人が知識を自分の中だけにため込んでいたりすると ("Dave は売掛金モジュールを担当する" のような...。つらい記憶がよみがえってきました)、その人がチームから抜けたり、やらなければならない仕事を他に山ほど抱えていたりする場合に、納品の妨げとなることがあります。プロジェクト内で、個人がコードを所有している箇所を見つけると、他のメンバーが負荷を分担することができるように設計を改善した場合のメリットと影響範囲について考えることができます。ボトルネックを解消してください。

エクストリーム プログラミングで規定されている共同所有のプラクティス (extremeprogramming.org/rules/collective.html、英語) には、多大なメリットがあります。共同所有を行うと、チーム内のすべての開発者が、"機能を追加したり、バグを修正したり、設計を改善したり、リファクタリングを行ったりするために" コードベース内のすべてのコードを変更することができます。"だれ 1 人として、変更のボトルネックにはなりません。"

ああ、また "ボトルネック" という言葉が出てきましたね。共同所有を可能にすると、(仕事を放棄したりバスにひかれたりする可能性のある) たった 1 人のプログラマしか知らない、システムのなぞめいた部分をなくすことができます。コードベースを共同所有した方が、リスクは低くなります。

私の経験では、設計もはるかに良くなります。1 人よりも 2 人、3 人、4 人で考えた方がいい知恵が浮かぶのは、ほぼ間違いありません。共同所有されているコードベースでは、チームの設計特性が生まれ、個人の個性や癖に取って代わります。

私はコードの共同所有をプラクティスと呼びましたが、実際のところ、共同所有は、うまく機能しているチームの創発特性です。考えてみてください。皆さんの中で、出社して "自分のコード" を扱う方と、チーム全体で共有しているコードを扱う方の人数比はどれくらいでしょうか。ソフトウェア開発でよく "チーム" と呼ばれるものは、実際のところ、割り当てエディターを使用して、ある機能、サブシステム、またはモジュールを過去に扱ったのはだれかに基づいてプログラミング タスクが少しずつ分配されるワークグループです。

チームとして優先順位を付ける

既に説明したように、改善に向けた取り組みにチーム全体を巻き込むことは重要です。私は、アジャイル コーチとして、"人は自分が創造に携わった世界を支持する" という強い信念を持っています。必要な人数分の支持を得られなければ、継続的改善の文化を育成するための取り組みが軌道に乗るのも、まして、持続するのも、非常に困難な場合があります。

合意を得ることは重要です。大多数のチーム メンバーに、皆さんが選択した現在の改善構想を支持してもらう必要があります。私は、Luke Hohmann が著書『Innovation Games』(innovationgames.com、英語) で提唱している "機能の購入" アプローチを使用して、ある程度の成功を収めました。このゲームを極端に単純化して説明してみます。皆さんの環境で機能しそうに思えたら、この書籍を読んでみることを強くお勧めします。

  1. 改善する必要がある項目が記載された短いリスト (項目数は 5 ～ 9 個) を生成します。これらの項目は皆さんの短期記憶内にあるのが理想的です。
  2. 難しさの観点から項目に評価を付けます。T シャツのサイズ (S、M、L、または XL) という抽象的な概念を使用したいと思います (このプラクティスの詳細については「改善の機会を評価する」参照)。
  3. サイズに基づいて機能に値段を付けます (たとえば、S の項目は 50 ドル、M の項目は 100 ドルなど)。
  4. 参加者全員に一定の額のお金を与えます。ここで重要なのは、ゲームに欠乏性を取り入れることです。興味のある機能を購入するためにはお金を共同出資しなければならないようにします。たとえば、M の機能に、どの参加者も 1 人では購入できないような値段を設定します。皆さんは同意を築こうとしているので、複数の参加者が優先順位が高いと思っているものを特定することは、重要です。
  5. 短時間 (20 ～ 30 分間くらい) ゲームをします。ゲーム内で、参加者は議論したり、結託したり、自分の主張を売り込んだりすることができます。これはかなり混沌としますが、とても楽しくもあり、チーム内で影響力のある人物を知ることができます。
  6. 購入された項目、およびどのくらいのマージンで購入されたかを確認します。購入された機能に基づいてリストの項目に順位を付けることができます。また、さらに良いことには、"機能の購入" ゲームの結果を他の手法 (次のリリース計画についての通知など) と組み合わせて使用することもできます。

改善の機会を評価する

負債項目や改善の機会を T シャツのサイズで大まかに評価することについて述べました。これは、アジャイル開発方法論で使用される一般的な手法です。相対的なサイズの観点から項目を収集するのです。S の項目、M の項目、L の項目 (それ以降のサイズについても同様) をそれぞれ、ひとまとまりと考えます。

ここでは、リストを非常に正確なものにすることはそれほど重要ではありません。こうした評価は相対的な基準であり、確約ではないことを覚えておいてください。難しさを大まかに理解する必要があり、理論上は、いくつもの項目を評価すると、項目間の差がならされていきます。ある M の項目を 2 人の開発者が完成させるには実際 2 週間かかり、別の M の項目を完成させるには 1 か月かかるとしても、平均すると、M の項目を完成させるには 3 週間かかることになります。

しかし、時間の経過と共に、L の項目や S の項目とは実際どのようなものなのかを示す良い例を収集できるようになってきます。これは、将来評価を行う際に役立ちます。比較の基準を持っていることになるためです。私は、新しい作業バッチを評価するために過去のさまざまなサイズの例をいくつか活用したことがあり、これは有効でした。

これは、経営陣にとっては受け入れがたいことである場合があります。経営陣は、まず、どのくらいの時間がかかるのかを正確に知りたがるでしょう。そして、率直に言いますが、皆さんは、より多くの時間をかけて、時間ベースの正確な評価を行わなければならない場合があります。

計画を売り込む

計画が用意できたので、今度は、負債を解消することの価値をプロジェクトのスポンサーに伝えます。実際には、このステップは特定と並行して行われる場合があります。顧客を最初から巻き込んでください。何しろ、計画の策定には、時間、労力、そして (突き詰めていくと) お金がかかります。まとまりのある計画を策定するためにだれのお金を費やしたのかについての質問は絶対に避ける必要があります。

大量の負債を解消するための取り組みを成功させ持続させるには、プロジェクトへの資金援助者やプロジェクトのスポンサーによるサポートが絶対に必要です。小切手を切る人たちに、皆さんが行おうとしている投資を理解してもらう必要があります。将来を見据えて長いスパンで考え、"今買って支払いは後" という考え方から離れるよう求めていることになるので、理解してもらうのは困難な場合があります。単に理由を説明しただけでは、とてもうまくはいきません。

これに関する問題は、幹部に必ず「君たちはプロではないのか」と聞かれることです。このようなせりふで探りを入れられると、皆さんは追い詰められたように感じるかもしれません。幹部は、期限内に予算内で高品質の製品が納品されることを期待してプロである皆さんにお金を払ったのでしょうから。

これに反論するのは困難です。気にしなくてよいというのが私の意見です。事実をありのままに伝える勇気と誠実さを持ってください。この一見危険に見えるアプローチは、説明責任と信頼という非常に人間的な問題に帰着します。

次のような言い方で主張を展開してみてください。求められた期間内に支給された予算内で正常なソフトウェアを開発しました。これを達成するためには、ビジネス上の必要に迫られて途中で妥協をしなければなりませんでした。予測可能かつ安定した速度で前に進むには、こうした妥協が及ぼす影響に対処する必要があります。組織全体が妥協を買い取ったので、今こそ返済するときです。

次の課題は、負債が最も大きな損害を与えている場所を技術者以外の人たちに示すことです。私の経験では、企業幹部は、"数値" や "事実" に基づく数量的でデータ主導の主張に好ましい反応を示します。数値と事実を二重引用符で囲んだのは、私たちは皆、自分たちが住んでいるのが相対的な世界であり、変更を納得させるたった 1 つの数値 (循環的複雑度、遠心性結合、コード行数、テスト カバレッジなど) などというものは存在しないことを本当は知っているからです。さらに困難なことには、最大の損害をもたらす領域を、"なぜこれは期待されるよりも低速なのか"、"なぜこの機能にはこれほどコストがかかったのか" のように経済的な観点から伝える必要があります。

Evidence DEFEATS Doubt (証拠が疑念を打ち砕く)

主張を展開する際は、"evidence defeats doubt" (証拠が疑念を打ち砕く) という簡潔なフレーズにまとめられた、Dale Carnegie の管理トレーニング システムの非常に役に立つツールを使用することができます。このような管理システム (および規律全般) にはよくあることですが、"DEFEATS" の部分は頭字語です。これがどのようにソフトウェア開発に当てはまるかについて、いくつか紹介していきます。ただし、"Exhibit" (提示する) を表す 2 つ目の E については、"Example" (例) を表す 1 つ目の E と内容が重なるように思えるので、割愛しました。

D は "Demonstration" (実例による説明) を表します。見せて説明することに勝るものはなく、実例による説明とはまさにそういうことです。速度を追跡している場合、実例による説明は簡単です。時間の経過と共に速度が低下していくようす (図 2 参照) を示し、これを、ますます柔軟性が低下し変更するのが困難になっていくコードと結び付けます。1 度売ったら、売り続ける必要があります。

Tracking Development Velocity

図 2 開発速度の追跡

スクラムやエクストリーム プログラミングなどのアジャイル プロセスを使用している場合は、顧客フィードバック イベントはきわめて重要なプラクティスです。1 回のサイクルの最後に、実例を用いて新機能を顧客に説明します。技術的負債のふきだまりが見つかって改善のための取り組みを強化している間は機能の品質と量が一時的に低下/減少しますが、時間の経過と共に得られる利益を実例を用いて説明できる必要があります。負債が少なければ少ないほど優れた結果が得られ、結果が優れていれば優れているほど実例を用いて説明できるものは増えます。

慣用句にもあるとおり、他人の気持ちは、その人と同じ経験をしてみなければわかりません。比較的技術的知識のある管理者がいる場合は、変更が困難であることについて共感してもらえるように、開発者と共にコードベース内の厄介なセクションのいくつかに取り組むよう勧めます。コードを少し見るように頼み、処理をたどることができるか、およびわかりやすいかを確認してもらいます。これが擁護者を得るための最も手っ取り早い方法です。

E は "Example" (例) を表します。具体的な例に勝るものはありません。技術的負債が原因で達成できなかったシナリオや要求、または、技術的負債が重大な回帰をもたらしたシナリオや要求をいくつか見つけます。わかりにくく、入り組んでいて、副作用だらけのコード セクションを選びます。コードのこうした特性が、どのようにして、顧客が見つけた欠陥や、QA で膨大な作業が必要になったことにつながったかを説明します。

アジャイル プロセスが提供するもう 1 つの強力なツールは回顧です。過去 2 ～ 3 回のサイクルで失敗したシナリオを選び、失敗の理由を考えます。そのシナリオが達成できなかったり、標準的なシナリオの 2 倍の時間がかかったり、2 つ以上のサイクルにまたがったりした理由の根本原因を突き止めます。柔軟性に欠けるソフトウェアが原因の場合がよくあります。また、回帰バグを克服できなかったため変更を元に戻さなければならなかった場合もよくあります。決定的な理由が技術的負債に関連するものだった場合は、分析を簡潔で率直な形でうまく表現します。これはもう 1 つの強みとなり、皆さんの主張のもう 1 つのポイントとなります。

F は "Fact" (事実) を表します。事実を手に入れるのは非常に簡単です。"プロジェクトを期限内にリリースしたか"、"リリース後の欠陥率はどのくらいか"、"ある期間におけるチームの平均的な速度はどのくらいか"、"顧客は納品されたソフトウェアに満足したか" というような種類の事実を交渉の場に持ち出す必要があります。私は、ビジネス意識のある人の心に最も直接的に訴えかけるのはこうした事実だと思っています。

ここでは、協調が重要な要素です。開発者である皆さんは、技術的な事実は比較的簡単に提供できます。予算を握っているスタッフからの協力を求めてください。こうしたスタッフの方が、皆さんよりも、技術的負債が与えている損害を示すビジネス上の事実をはるかに明確に把握していたり、はるかに簡単に入手できたりする可能性は大いにあります。

A は "Analogy" (たとえ話) を表します。私は、これは特に重要だと思います。ビジネス ピープルは、ソフトウェア開発をわかりにくく難解なものと感じることがあります。スポンサーを訪ねて、結合だの、凝集だの、単一責任の原則だのという話をすると、スポンサーを失う可能性が非常に高くなります。しかし、これらは職業的なソフトウェア開発において非常に重要な概念であり、また、結局、負債に対処するためのデータ主導の主張を展開するにはこうした話をする必要があるのです。専門用語の使用を避け、これらの項目をたとえ話で説明することをお勧めします。

たとえば、結合はトランプ タワーにたとえて説明することができます。コードに変更を加えるというのは、既に築き上げられた非常に手の込んだトランプ タワーに壁、天井、または階を追加するようなものであり、非常に優れた決断力や多大な時間と根気を要する究極的には不確実で不安を生じさせるような外科手術なのだということ (トランプ タワーは崩壊することがあります)、そして、これが速度が低下した理由であることを、スポンサーに伝えます。

隠喩や直喩を使用する場合は、隠喩や直喩を使用していると明言することをお勧めします。伝えようとしている、より技術的な概念について簡潔に説明して、たとえ話の正当性を示します。トランプ タワーの例を使用する場合は、「結合は、新機能の変更と追加に対処する能力にこのような影響を与えます。」などと言うことができます。

T は "Testimonial" (保証) を表します。同じメッセージを第三者から聞くと、より強力な効果がある場合があります。このような第三者として考えられるのは、業界のリーダーやコンサルタントなどです。このような第三者の言葉が皆さんの言葉よりも効果的なのは、このような人たちが客観的な専門家と見なされているからです。

外部のコンサルタントを雇うお金がない場合は、業界の思想的リーダーから無料で提供されている逸話や洞察を集めることを検討します。いわゆる "ベスト プラクティス" に関する一般的な保証は、支持を取り付けることに直接つながりはしないでしょうが、主張を全体的に強化します。

S は "Statistics" (統計) を表します。数値は重要です。経営管理でよく使われるフレーズに、"測定できないものは管理できない" というものがあります。この社会通念が全面的に当てはまるかどうかはわかりませんが、間違いなくこれに賛成を主張することはできます。結合と複雑さは、スループット (処理量) の低下とますます負債が増えていくコードベースとの因果関係を示すために使用することができる 2 つの指標です。

ここでは通常、複合的な統計を用いるのが最良の策です。時間の経過と共に値が低下するコード カバレッジ指標を速度の低下と重ね合わせて、関連性を示すとは言わないまでも暗示することができれば、コード カバレッジの重要性ははるかに理解しやすくなります。

リーダーを任命する

能力のあるリーダー、つまり、ビジネス用語で話をすることができ組織内の意思決定者に対して影響力を持つ擁護者がいると、技術的負債の修正に対するゴー サインを得るための取り組みにとって、大きなプラスになります。多くの場合、これは、皆さんの管理者、この管理者の管理者、CTO、エンジニアリング部門長、または、同様の、権限があると認識されている立場にいる人物です。

これは、"ニワトリが先か卵が先か" のような興味深い問題をもたらします。この人物を納得させるにはどうすればよいのでしょうか。"上司を管理する" というプロセスも開発者の任務のうちです。最初の課題は、売り手を納得させることです。では、これを行うには一体どうすればよいのでしょうか。"evidence defeats doubt" (証拠が疑念を打ち砕く) です。

次のステップ

ここまでのところで、チームとして負債を特定し、この負債を修正するための主張を展開する方法について説明しました。何度も繰り返しますが、チーム内の合意と顧客の積極的な参加は、こうしたステップにおける重要な要素です。

こうしたステップの規模を小さくし、多くの時間をつぎ込まないようにしてください。最初に負債を特定するときは、新しい改善機会を反復的に処理するときよりも必然的に時間がかかりますが、経営陣向けに主張を展開する際は、取り組む予定の項目のみを盛り込むようにしてください。常に生産性に気を配っておくと、労力を大いに節約することができます。

今後の記事では、ワークフローの残りの部分 (負債を解消するための方法など) を見ていきます。また、このプロセスを反復的なものにする方法、および以前に行った負債解消の取り組みから学んだ教訓を活かす方法についても説明します。

Dave Laribee は、VersionOne の製品開発チームを指導しています。全米各地の開発者イベントで頻繁に講演を行っており、2007 年と 2008 年に Microsoft Architecture MVP を受賞しました。CodeBetter ブログ ネットワークで、ブログ (thebeelog.com、英語) を執筆しています。

この記事のレビューに協力してくれた技術スタッフの Donald Belcham に心より感謝いたします。