はじめに
こんにちは！株式会社CastingONEでHR領域のSaaSのPdM兼エンジニアをやっている@hiroakiです。
よく技術的負債とかは話題に上がる気がするのですが、今回は機能的負債がテーマです。その機能がプロダクト全体としてみた時に、足枷になっていないか、なっている場合どのように立ち向かうか。このテーマはPdM Days 2025のOSTでも取り上げさせていただきました。僕の経験やそこで出た議論を元に書いてみようと思います！（OSTで一緒に議論してくださった方々ありがとうございました）
そもそも機能的負債とは何なのか？
機能的負債とは？
冒頭でも少し書きましたが、プロダクト全体としてみた時に、足枷になっているものだと僕は考えています。
- その機能の体験がユーザーの理想とする体験からかけ離れてしまっている
- その機能のせいで、プロダクト全体のユーザー体験が悪くなってしまう
- 使われないのに存在し続けている。機能開発をしようとすると、その機能のことも考慮に入れないといけない
- その機能があることで、ソースコードも複雑化し開発スピードが遅くなる
など色々な特徴はあると思います。要はその存在によって事業やプロダクトに対してなんらかの負を与え続ける（もしくはその機能が提供する価値よりもマイナス面の方が大きくなってしまう）ものかなと考えています。
機能的負債はなぜ発生するのか？
機能的負債の発生起源は大きく2つだと思っています
ビルドトラップ系
「この機能があれば"プロダクト"がこの状態になる」というようにユーザーの課題や体験ではなく、プロダクトの方向性やソリューションベースで進めてしまうパターンです。リリースした結果、使われずに最終的に負債になってしまうという悲しい結末につながります。
Pivot系（事業の方向見直し）
元の方向性では事業マッチしていたものが、今となっては大きくずれてしまい、負債化してしまうパターンです。この場合によっては使用ユーザーもおり、負債だが消しにくいのでジワジワプロダクトを痛めつけてくる辛い魔物に変貌する恐れもあります。
機能的負債にどう立ち向かうのか？
機能的負債はないに越したことがないのですが、どんなに頑張っても生まれる可能性があります。ここでは立ち向かう方法について、3つ挙げてみました。
負債を負債であると認識する
『まずは敵を知る』にも、敵であることを認識しないと敵のことを知ることはできません。「ユーザーはその機能そもそも使っているのか」「ユーザーはその機能をいつどのように使っているのか」この辺りを監視することで、その機能が負債であるかどうかを認識することができると考えています。認識した後にそれに対してどう対処するかを考えていきます。
早く・細かく失敗を重ねる
巨大な失敗をしてしまうと、巨大な負債を抱えかねないので小さく失敗をしようというものです。開発しなくてもわかることはその前に検証してしまうことも重要だと思います。ユーザーの解像度を高めた状態で開発・リリースして、その結果をみてまた意思決定していく。月並みですが、ディスカバリーで学習を重ねて、それを踏まえたデリバリーで小さく早く学習サイクルを回すことがそもそも負債に対抗する一歩めかなと思っています。今はAIによって大分試行錯誤もしやすくなったため、より早く失敗を重ねることができるようになりましたしね！
負債のインパクトを考える
機能を開発する際はインパクトサイジングすると思うのですが、負債が存在することでのインパクトはあまり考えられない気がしています（そうでもなかったらすみません笑）。該当の機能があることで、ロードマップに記載しているアウトカムを達成するためにどれくらいそれを阻害してくるのか？開発スピードはどれくらい落ちるのか？正直全て定量的に判断するのは難しいですが、ある場合とない場合でどのような未来があるかを組織内で会話するだけでも少し見えてくるものがあるかもしれません。
実際にあった機能的負債
最後に僕の機能的負債について具体的な事例を書いてみようと思います。
扱っているプロダクト
僕の扱っているプロダクト『CastingONE』について、少し説明させてください。『CastingONE』は、非正規雇用に特化したCRMサービスです。現在の主なユーザーは派遣会社で、彼らは既に自社に登録している「未稼働スタッフ」や「過去に応募したが条件が合わず離脱した求職者」に対して、再アプローチをかける“掘り起こし”を日々行っています。
CastingONEでは、LINE・メール・SMSといったチャネルを活用し、適切な求職者に求人情報を届けることが可能です。求人を届けた時の求職者の行動や、求職意欲等のシグナルを用いて、既存人材の掘り起こしをより効果的・効率的に行うことができます。
開発した機能 v.s.使われない機能
そんなCastingONEに、かつて“面談調整機能”を開発したことがありました。これは、掘り起こしでアプローチした求職者が応募した後のプロセスも一部サポートできるようにする、という事業戦略的な意図がありました。
応募後に面談日程を調整できる仕組みを作れば、よりスムーズに採用につなげられる——そんな期待を込めて開発された機能でした。
しかし、リリース後機能はほとんど使われませんでした。当初は「機能認知が足りていないのでは？」「もう少しブラッシュアップすれば…」と様子を見ることにしましたが、時間が経っても利用率は伸びず、また追加の開発リソースも割けない状況が続きました。というのも、CastingONEはあくまで“掘り起こしに特化したCRM”という立ち位置があり、その軸から外れる機能の優先度はどうしても下がってしまうのです。一部の顧客には確かに使われていましたが、彼らはコアターゲットではありませんでした。
方針転換、そして削除へ
その後、事業として「よりCRMに特化する」という明確な方針が打ち出されました。これにより、面談機能はプロダクトの方向性にそぐわないものとなります。プロダクトの方向性に合わない且つ使用ユーザーも少ないことから、面談機能を削除することが決定しました。
機能削除については、sansanさんの記事を参考にさせていただきました。
出典：「いらない機能はさっさと消したい」負債解消の初手「消す」を組織全員で実践する方法
実際に使用していたユーザーに対しては、削除にあたっては削除する旨をお伝えすると共に代替手段の提示なども行いました。実際に使っていた一部のユーザーを除いて、大きな混乱は起きませんでした。
機能的負債が生まれた理由と学び
今回の面談機能は、一見事業方針見直しによるもののように見えますが、個人的にはビルドトラップにハマってしまった方が大きいと思っています。『CastingONE』で面談調整をしたいと顧客は熱望していなかったのかなと。顧客の掘り起こし採用プロセスにおける課題の把握もうまくできていないまま、悪く言えばプロダクトの方針のみを考えて面談機能を開発してしまったわけです。恥ずかしながら開発した時代は顧客の声を聞くことが疎かにしていました。その反省もあり、今となっては顧客と直接会話する機会も増えましたし、現場に行って顧客の業務を直接見学させていただくことも出てきました。改めて、機能的負債を防ぐには、顧客解像度を高めることが重要であることを改めて実感しました。
おわりに
機能的負債は生み出したくないものですが、どうしても生まれてしまうこともあると思います。途中で紹介したsansanさんの記事に以下のような記述があります
Sansanでは捨てることは大事にしているものの、「捨てる可能性のある機能をつくるな」とは言いません。大切なのは、失敗を恐れなくてもいいように「捨てる」仕組みをきちんとつくっておくことです。
出典：「いらない機能はさっさと消したい」負債解消の初手「消す」を組織全員で実践する方法
プロダクト開発は不確実性の塊のようなもので、リリースしないとわからないことも多いと思います。リリースしてその機能に対して観察を重ねてダメであれば消す。またはベータ版から始めてみる等も機能的負債を残さない方法の1つかもしれません（途中記載した「早く細かく失敗を重ねる」の中に包含されるかもしれませんが）。
ここまで読んでいただきありがとうございました！また、PdM Days 2025のOSTで一緒に議論していただいた方々、冒頭文章の繰り返しになりますが、改めて感謝いたします。機能的負債自分の会社はこう対処してるよ！等あったら教えてください✨
Discussion