はじめに

アジャイル開発を行う上で、機能開発と内部負債の解消というジレンマがあります。短期でみると、両者は利益相反しているため、しばしばビジネス側と開発側での対立を発生させます。機能開発を優先しすぎると、コードの複雑化により内部品質が低下し、最終的には機能リリースが極端に遅くなります。一方で、品質改善に注力しすぎると、ユーザー価値の提供が遅れ、ビジネスインパクトが小さくなってしまう恐れもあります。

この記事では、技術的負債を可視化する手段として、「負債観点表」をご紹介します。負債観点表を使って利害関係者と交渉し、あらかじめ開発スケジュールに負債解消の工数を計上します。中長期的な開発計画において、負債解消と機能開発を両立させるためのヒントになれば幸いです。

よくある課題

アジャイル開発で頻繁に直面するのが、機能追加と技術的負債の解消のバランスです。

プロダクトオーナーやビジネスサイドは、早期にユーザーへ価値を届けることを重視し、機能リリースを重視します
一方、エンジニアは中長期の保守性・拡張性を考慮し、設計改善やリファクタの時間を必要とします

両者はシーソーのような関係になっており、どちらかに傾きすぎると開発がうまく進みません。機能開発と負債解消のバランスを取るために、負債観点表をご紹介します。

この手法のメリット

機能開発と並行して、負債解消の工数を見積もりに含めることができる
技術的リスクを早期に関係者へ説明でき、開発のリアリティを共有しやすくなる
想定外の負債対応が減り、スケジュール遅延やエンジニアの心理的負荷を軽減できる

インプットとアウトプット

インプット
- 中期的な開発スケジュール（6か月〜1年） ... POが作成
- ユーザーストーリーマップ ... 開発チーム全員で作成
アウトプット
- 負債観点表（負債・リスクの可視化） ... 開発者が作成
- 更新された開発スケジュールとスコープの合意 ... 開発チーム全員ですり合わせ

実施タイミング

次のような開発の節目に取り入れると効果的です。

MVPの初回リリースが完了し、追加開発フェーズに入るタイミング
四半期単位のスプリント計画やロードマップ更新時
OKRやチーム目標の見直し時期

実践フロー

以下のステップで導入を進めていきます。

POは、中期的なリリース計画をビジネス側が立案し、開発チームに共有
開発チームは、ユーザーストーリーマップで機能スコープを整理
開発者は、技術的負債の洗い出しと負債観点表の作成
利害関係者へ負債観点表を共有
中期の開発日程の合意
開発しながらスケジュールの予実を管理

ステップ1：ビジネスサイドが中期計画を立案

まず、ビジネスサイド側の人間が、中長期的なリリース計画を立てます。この計画は、ビジネス戦略や製品ロードマップをもとにした計画とします。現時点では、この計画には開発側の視点がまだ含まれていないため、あくまでもビジネス側から見た 要求としての計画とします。(もしこの時点の計画を確定版としてしまうと、計画の実現性が吟味されておらず、炎上する可能性が高くなります。🔥）

ステップ2：ユーザーストーリーマップの作成とリリーススコープの仮決め

次に、PO、デザイナーを中心とし、チーム全員でユーザーストーリーマップを作成します。作成したユーザーストーリーマップのうち、半年以内で実現したいフィーチャーと、後回しにすべきフィーチャーの線引きを行います。
この時点の線引きも、ビジネスサイド側からの要求にとどめ、確定はさせないようにします。

ステップ3：技術的負債の整理と観点表の作成

開発者は既存機能を一覧化し、それぞれにどのようなリスクや負債があるかを評価します。その際に活用するのが「負債観点表」です。以下のような観点で、各機能の改修リスクを点数化していきます。

仕様の複雑度
仕様の変更頻度
現在の実装に含まれる負債の大きさ

たとえば「仕様の複雑度」の点数定義は以下のようになります。

1点 … 単純なデータ取得処理
2点 … 単純なデータ更新処理
3点 … 複雑なビジネスロジックや複数データ操作がある

これらを機能ごとに集計し、リスクスコアを算出したうえで、対応すべきアクションを記載していきます。

負債観点表の例（機能ごとのリスク評価）

リスク観点の定義

ステップ4：負債観点表を共有

作成した負債観点表をもとに、技術的負債の状況と、各機能の実装にかかる追加工数をPOやビジネス側へ説明します。ポイントは、感覚や勘に頼らず、数値と根拠を用いた説明にすることです。これにより、スコープの現実性が客観的に伝わりやすくなります。

このタイミングでは、以下のような対話と意思決定を促します。

負債解消をを行う機能と、行わない機能の仕分け
- 業務ロジックが単純な機能や変更頻度が少ない機能などは、ビジネス価値が低い機能とみなし、リファクタを最低限に留めます（エンジニアがリファクタをやりすぎないよう抑止する）
- 重要機能は、業務ロジックの複雑度や既存実装の負債の大きさを鑑み、リファクタの必要工数を見積もります
もともとの開発計画に無理がないか確認
- 重要機能のリファクタ工数を開発スケジュールに追加します
- 元の開発スケジュールよりも圧迫させた状態になるため、リリース日程やリリーススコープの調整を行います
調整後の開発スケジュールにバッファを追加
- 開発計画のバッファが0%では、突発タスクに対応する余裕がなく炎上がほぼ約束された状態になります。開発チームは機能開発に30%程度のバッファを組み込むことをおすすめします

ステップ5：関係者との合意に基づいて、中期スケジュールを再構成する

ステップ4で得られたフィードバックをもとに、再調整された開発スケジュールを策定します。ここでは「ユーザー価値の提供速度」と「将来の開発効率」のバランスを取ったスケジュールであることが求められます。

スケジュールは、以下の視点を考慮して設計します。

追加開発のフィーチャーに優先度がついており、優先度が高いフィーチャー順に開発されるか？
負債解消を行う機能と行わない機能の線引きが、ビジネス側と開発者側で合意できているか？
開発日程及び、開発スコープにバッファが設定されているか？
- 開発日程のバッファとして、リリース日 = 必要な開発期間 * 1.3倍 といった安全係数がかかっているか？
- 開発スコープのバッファとして、機能を優先度付けしたときに、開発を諦めてもビジネス的に影響が小さい機能がいくつか存在するか？（MoSCoW分析を参照）

このステップで合意したスケジュールは、次フェーズでの開発指針の中核します。PO・開発チーム・マネジメントの三者が納得感を持てる状態にすることが重要です。

筆者は、アジャイル開発においても中長期のリリース計画を立てるべきと考えています。中長期の計画がなければ、マーケティング、開発予算、経営計画など、ビジネス側への説明責任を果たせないからです。

ステップ6：開発しながらスケジュールの予実をモニタリングする

再構成した中期スケジュールに基づき、開発がスタートした後も、定期的な予実の見直しが欠かせません。下記の3つのポイントを管理項目として、開発を進めていきます。

機能実装の進捗率（計画と現状の割合を管理）
負債解消の進捗率（計画と現状の割合を管理）
バッファ消化率（計画時に織り込まれたバッファをどれくらい使用したか）

予実のズレが出た際には、必要に応じてスコープや優先度を再検討します。一度引いた計画を形骸化させるのではなく、こまめにメンテナンスしながら、「使える計画」として管理します。

まとめ

プロダクト開発において、「機能追加」と「負債解消」は短期的には利益相反する概念です。また、ビジネスサイドの人間と開発サイドの人間では、プロダクト開発に関する視点が異なり、しばしば対立の原因となります。今回ご紹介した「負債観点表」は、ビジネスサイドに技術的リスクを定量的に示すことができます。定量的な指標をもとに、ビジネス側と開発側がコミュニケーションをすることで、両者の視点のすり合わせが容易になり、全体最適となる開発計画を立てやすくなります。

将来の価値提供のための投資としてリファクタを取り入れることが、持続可能なプロダクト開発への第一歩です。プロジェクトの計画段階で、負債をできるだけ可視化し、無理のない開発計画を作るようにしてください。

補足

アジャイル開発において、中期の開発計画を立てる際には「リリースプランニング」を行うとよいそうです。こちらはウォーターフォールほどかっちりした計画は立てませんが、プロダクトバックログをインプットに、半年先程度でリリース可能な機能のスコープを見積もる方法です。