ブレスト＆決定力向上塾

【実践ワーク】チームで技術的負債を特定し、計画的に解消するワークショップ

Tags: 技術的負債, チームワークショップ, 計画策定, 問題解決, アジャイル開発, ソフトウェア開発, チームビルディング

はじめに：技術的負債はなぜチームで向き合うべきか

ソフトウェア開発において、「技術的負債」は避けて通れない課題の一つです。短期的な開発速度を優先した結果、コードの品質低下、設計の複雑化、テストの不足などが生じ、それが将来の開発効率を著しく低下させます。これは単なるコードの問題に留まらず、チームの士気低下、リリース遅延、ひいてはビジネス機会の損失につながる可能性があります。

技術的負債への対処は、個々の開発者の責任ではなく、チーム全体で取り組むべき課題です。なぜなら、負債はチームが生み出し、チーム全体がその影響を受けるからです。また、負債の解消には共通認識と優先順位付けが不可欠であり、これはチームでの議論と合意形成を通じてのみ効果的に行えます。

このワークショップは、チームで技術的負債を共通認識し、その影響を評価し、現実的で実行可能な解消計画を策定することを目的としています。単に問題をリストアップするだけでなく、どのように、いつ、誰がその負債に取り組むのかを具体的に決定するプロセスを提供します。

ワークショップの目的と概要

ワークショップの手順

ステップ1：技術的負債の定義と共通認識（20分）

まず、チームにとって「技術的負債」とは何かを明確に定義し、参加者全員でその認識を共有します。これは、後続のステップで挙げられる項目が本当にチームが向き合うべき「技術的負債」であるか判断する基準となります。

  1. 定義の共有: ファシリテーターは、「技術的負債」という言葉の一般的な意味（例: 将来的な開発コスト増大やメンテナンス困難化につながるコードや設計上の課題）を提示します。
  2. チームでの議論: チームとして、どのような状態を技術的負債と見なすかについて議論します。
    • 例えば、「テストコードがない」「ドキュメントが古い/ない」「特定のライブラリが古いバージョンで固定されている」「特定のモジュールが複雑すぎる」「デプロイが手動で時間がかかる」など、具体的な例を挙げながら話し合います。
    • ポイント: 抽象的な議論に終始せず、チームの状況に即した具体的な「技術的負債」の定義に合意します。
  3. 共通定義の確認: チームで合意した技術的負債の定義をホワイトボードなどに書き出し、全員がいつでも確認できるようにします。

ステップ2：技術的負債の特定とリストアップ（40分）

チームメンバー各自が認識している技術的負債を洗い出し、リストアップします。

  1. 個別洗い出し: 参加者各自が、付箋にチームが抱えていると思う技術的負債を一つずつ書き出します。
    • 負債の場所（ファイル名、モジュール名など）や簡単な内容を具体的に記述します。
    • 例: 「UserService.java の createUser メソッドが長すぎる」「古い認証ライブラリ v1.x が使われている箇所」「商品検索APIのDBクエリが遅い」
    • ポイント: この段階では、質より量を重視し、思いつく限り全ての負債をリストアップします。遠慮なく、正直に書き出すことが重要です（心理的安全性がカギとなります）。
  2. 共有とグループ化: 書き出された付箋をホワイトボードに貼り出します。
    • 類似の内容は近くにまとめたり、グループ化したりします。
    • 各付箋の内容について、簡単な説明が必要な場合は記述者が補足説明します。
    • ポイント: 内容が重複している場合はまとめますが、異なる視点からの記述であれば残しておきます。

ステップ3：技術的負債の評価と共通理解（50分）

リストアップされた技術的負債について、チーム全体でその影響度や解消の難易度を評価し、共通理解を深めます。

  1. 評価基準の設定: 技術的負債を評価するための基準をチームで合意します。一般的な基準としては以下のようなものがあります。
    • 影響度: その負債があることで、開発速度、保守性、安定性、セキュリティなどがどれくらい悪影響を受けているか（例: 高/中/低、または1〜5のスケール）。
    • 解消難易度: その負債を解消するためにどれくらいの労力（時間、コスト）がかかるか（例: 大/中/小、または1〜5のスケール）。
  2. 個別評価（任意）: 各自が付箋ごとに上記の基準で評価を書き込みます。
  3. チームでの議論と評価の合意: 付箋を一つずつ取り上げ、チームで議論しながら影響度と解消難易度を評価し、付箋に追記します。
    • なぜその評価になるのか、具体的な影響（例: 「このせいで〇〇機能の改修にいつも倍の時間がかかる」「たまに本番でエラーが発生する」）や解消の障害（例: 「関連箇所が多くて影響範囲の特定が難しい」「担当者がもういない」）について具体的に話し合います。
    • ポイント: 評価に絶対的な正解はありません。チームとしてその負債に対する「共通の認識」を持つことが最も重要です。意見が分かれる場合は、根拠を明確にして議論し、多数決ではなく合意を目指します。

ステップ4：解消対象の優先順位付けと計画策定（50分）

評価に基づいて、どの技術的負債に優先的に取り組むべきかを決定し、具体的な解消計画を立てます。

  1. 優先順位付けの検討: 評価結果（影響度と解消難易度）を基に、どの負債に優先的に取り組むか議論します。
    • 例えば、「影響度が高く、解消難易度が低い」ものは優先度が高くなる傾向があります。
    • 一方で、「影響度は高いが解消難易度も高い」ものや、「影響度は低いが解消難易度も低い（すぐに直せる）」ものなど、様々なタイプがあります。
    • ビジネス上の優先順位（例: 今後注力する機能に関連する負債か）も考慮に入れます。
    • ツール活用: 影響度と解消難易度を軸にしたマトリクス（例: 縦軸に影響度、横軸に解消難易度をとった図）を作成し、付箋を配置すると視覚的に分かりやすくなります。
    • ポイント: 全てを一度に解消することは不可能です。チームとして「この期間内に、この負債から優先的に取り組もう」という具体的な目標とリストを定めます。
  2. 計画策定: 優先順位の高い技術的負債について、解消のための具体的な計画を立てます。
    • 何を？: 解消する技術的負債。
    • どのように？: 具体的な作業内容（例: リファクタリング、テストコード追加、ライブラリ更新、ドキュメント作成）。
    • 誰が？: 主に誰が担当するか（担当者を決めることで実行可能性が高まります）。
    • いつまでに/いつ？: 目標とする完了時期や、どのスプリントで取り組むか。
    • ポイント: 解消作業を通常の開発タスクとして見積もり、バックログに追加することを検討します。計画は現実的である必要があります。全ての負債解消を目指すのではなく、まずは優先度の高い数件から取り組みます。

ステップ5：継続的な取り組みの合意（10分）

技術的負債は一度解消すれば終わりではありません。継続的に取り組み続けるための仕組みや意識について話し合います。

  1. 定期的なレビュー: 技術的負債のリストと計画を定期的に（例: 月に一度、四半期に一度）レビューする機会を設けることを合意します。
  2. 新規負債の発生抑制: 新たな技術的負債を生み出さないために、コードレビューの強化、ペアプログラミング、コーディング規約の見直しなど、チームで取り組めることを議論します。
  3. 計画の浸透: 策定した計画をチーム内で共有し、いつでも確認できるようにします。タスク管理ツールへの登録などを行います。

ワークショップの効果を高めるポイント

まとめ：チームの健全性を維持するために

技術的負債への計画的な取り組みは、短期的な開発効率だけでなく、長期的なプロダクトの持続可能性とチームの健全性を保つ上で非常に重要です。このワークショップを通じて、チーム全体で技術的負債という共通の課題に向き合い、具体的なアクションに繋げることができます。

一度きりでなく、定期的にこのワークショップを実施したり、日常の開発プロセスの中で技術的負債について話し合う時間を設けたりすることで、技術的負債を管理可能なレベルに保ち、チームの生産性とモチベーションを高く維持していくことが期待できます。ぜひ、あなたのチームでも実践してみてください。