「いらない機能はさっさと消したい」負債解消の初手「消す」を組織全員で実践する方法【Sansan西場正浩】

多数のビッグプロダクトがローンチから10周年を迎える昨今、技術的負債は多くの開発チームにおいて巨大な課題となっています。積み重なった負債の影響で開発生産性が下がり、返済しようにもリソースが足りなかったり、どこから手をつけるべきか決めきれなかったりと、多くの開発チームにとって悩みの種となっています。

そんな中、SansanのVPoE/VPoPを務める西場正浩さんが、昨年Xで次のようなポストをしました。

「プロダクト開発における技術的負債と、システム開発における技術的負債は全くの別物。“プロダクト負債の解消”を実現するためには、コードの品質を上げるだけでなく“不要な機能を捨てること”が重要である」

確かにこれを実行できれば、技術的負債の解消は大幅に前進しそうに思えます。しかし、既存の機能を「捨てる」決断は、決して簡単ではないはずです。Sansanでは一体どのように「捨てる」意思決定をして実行に移し、プロダクトの価値を高めているのでしょうか？ 西場さんに詳しくお聞きしました。

• keyboard_arrow_down 技術的負債は「システム負債」と「プロダクト負債」に分けられる
• keyboard_arrow_down 「プロダクトの方向性と一致しないが、利用数の多い機能」を捨てる基準
• keyboard_arrow_down 「捨てる」を実現するのは、N=1の意見を見逃さない仕組み
• keyboard_arrow_down 「とりあえず残す」をやめるプロダクトビジョンの定め方
• keyboard_arrow_down 捨てる可能性のある機能をつくってもいい。捨て続けられるから挑戦できる

——西場さんが、不要な機能を「捨てる」ことが重要だと思うようになったのは、何がきっかけだったのですか？

西場：開発組織のいちメンバーだった頃から、非効率な時間が大嫌いだったんです。「使われていない機能のコードを書き直す時間はなんて不毛なんだ、消してしまえばいいのに」とずっと思っていました。

「捨てる」という発想を明確に得たのは、新卒で入社した会社で大規模な技術的負債の解消を提案したときです。負債解消にまつわるあらゆる書籍に目を通したところ、どの本にも「初手は機能を消す（捨てる）こと」と書いてあったので、その方針を忠実に実行しようと思いました。

しかし、機能を「捨てる」という判断は、エンジニアだけで簡単にできることではありません。じゃあ、「捨てる」意思決定は誰がするべきなんだろう。その人はどうすれば、あらゆるステークホルダーの合意を獲得した上で「捨てる」という意思決定ができるのだろう。そう考え続けてきました。

現在の私は、プロダクトや開発組織の責任者であり、経営陣の一人でもある。すなわち「捨てる」意思決定をする役割を担っています。その立場から「捨てられるものは捨てよう」と発信し実行しているだけで、「捨てる」に対する考え方は昔からずっと変わっていないのです。

——西場さんの言う「プロダクト負債」は、一般的な「技術的負債」と何が異なるのでしょうか？

西場：技術的負債の中に「システム負債」と「プロダクト負債」という2種類の負債があるイメージです。

まず「システム負債」とは、開発現場レベルでの解決が求められている負債であり、エンジニアがリファクタリングなどによって対応することが想定されています。

一方「プロダクト負債」とは、それよりも上位レイヤーでの対応が必要な負債です。そもそも「プロダクト」とは、顧客の課題解決のために存在するものです。そのプロダクトにかかわるすべての関係者が当事者となって対処すべき問題を「プロダクト負債」と呼んでいます。

例えばプロダクトビジョンに即していない機能や、ユーザーにとって使い勝手が悪い機能がある場合、その機能を捨てたり、大規模なアップデートを検討したりする必要があります。こうした「プロダクト負債」をそのままにしておくと、開発生産性もプロダクトの価値もどんどん下がってしまいます。けれど、これらの既存機能の大幅な変更は、プロダクトとして提供する価値を変えることになるため、営業やCS、経営陣などあらゆるステークホルダーを巻き込まなければなりません。

——「プロダクト負債」という考え方は、これまであまり定義されてこなかったかもしれません。

西場：「技術的負債」とひとことに言っても、エンジニアだけで対処すべき問題と、そうではない問題と両方が存在します。プロダクトの提供価値にかかわる問題なら、エンジニアに限らずメンバー総出で考えた方がいいですよね。

プロダクトが提供すべき価値は、ビジネスのフェーズや時勢とともに変わっていくものであり、それに応じて捨てるべき機能も変わります。大切なのは、いらない機能がないか常に見極めて「捨て続ける」こと。不要な機能を一気に捨てればそれで終わり、というわけではありません。

——「プロダクト負債」が生まれてしまうのは、どんなときなのでしょうか。

西場：プロダクトビジョン、すなわちプロダクトが提供すべき価値や、解決すべき課題などが定まっていなかったり、関係者間で共有できていなかったりすると、「必要な機能」の定義ができませんから、「不要な機能」が生まれやすくなるでしょう。

一方で、プロダクトビジョンが明確にあって関係者間での共有ができていたとしても、プロダクトがスケールするなどしてプロダクトビジョンそのものが変われば、既存の機能が負債になってしまうこともあります。

「Sansan」もリリースから今年で17年目に入り、「名刺管理」からスタートした初期のプロダクトビジョンは「営業DX」へと大きく変わりました。昔のプロダクトビジョンには合っていても、現在には合わない機能がどうしても生まれてしまうのは、ある程度仕方のないことだと捉えています。

——実際に機能を「捨てる」意思決定は、どのような判断基準で行っているのですか。

西場：まずプロダクトの機能を、「プロダクトの方向性と一致するかどうか」「利用数が多いかどうか」の2軸で、4象限に分けます。

西場：「（図①）プロダクトの方向性と一致せず、利用数も少ない機能」は迷いなく捨てられますよね。でも、それ以外の機能（図②③④）はそう簡単には決められません。「その機能は解決すべき課題を解決できているのか」に立ち戻ることが、判断の鍵となります。

次の「（図②）プロダクトの方向性と一致しないけれども、利用数が多い機能」については、多くのユーザーが、その機能をあるべき形で使用していない可能性があります。その場合「ユーザーはなぜこの機能を使うのか」を徹底的に調査し、ユーザーが本来実現したいことを理解してから、抜本的改善の方向性を判断します。より的確に課題解決できるような機能につくりかえていくのです。

そして、「（図③）プロダクトの方向性とは一致するが、利用数が少ない機能」。そうなっている原因の一つに「市場や環境が整っていない」ケースが考えられます。例えばインターネットが普及していない時代に、iPhoneのようなプロダクトがあったとしても流行らないじゃないですか。そんな感じで、その機能が使われるに足る市場環境がない場合、適切なタイミングで改めて打ち出すか、そこまでコストをかけられないなら消す、という判断ができます。それから、「ソリューションが磨き込まれておらず、機能としての品質が低い」ケースも考えられます。使いにくさが普及のネックになっているなら、機能のブラッシュアップや、より使いやすくするための大幅なアップデートが必要です。

最も判断が難しいのは、「（図④）プロダクトの方向性と一致し、利用数も多い機能」です。一見このままで問題ないように見えますが、かといって放置してしまってもいけません。すでにユーザーの課題を解決できている場合でも、さらに使いやすくできる余地がないか検討が求められます。

——「プロダクト負債を捨て続ける」ために、大切なことは何でしょうか？

西場：捨てられるものを探し続けることです。私はN=1の意見一つひとつに対して真剣に向き合うようにしています。社員からの「ちょっと使いづらい気がする」といった感想や、顧客からぽろっと漏れた本音は、プロダクトを改善する上で非常に重要なものです。

これらがこぼれ落ちないように、対応するべき声にはきちんと対応しきる仕組みをつくって徹底しています。

——そのために西場さんは、VPoE/VPoPとして具体的にどのような取り組みをしていますか？

西場：これはVPoPとしての役割だと捉えているんですが、プロダクトに関する全てのフィードバックに私自身が目を通すようにしています。

当社のSlackには、Sansanのプロダクトにかかわる全ての社員が参加する、プロダクトへのフィードバック用のチャンネルがあって、あらゆる改善要望がここに寄せられます。1日に約20件、1ヶ月で400件ほどスレッドが立ちますが、私がその全てを見てリアクションし、重要度を判断し、必要に応じて担当メンバーをアサインしています。

特に重要度の高いものは、対応用に別のチャンネルが立てられた後も追いかけます。もし重要度の高い改善案件が1ヶ月も動いていなかったら、必ず「どうなっていますか？」と声をかけるようにしています。1ヶ月後に進捗を確認できるよう、リマインド通知が来る設定にしているんです。

——改善案件の進捗まで追いかけているんですね。なぜこれほどまでに、VPoPである西場さん自身が動くことを徹底しているのですか？

西場：フィードバックを取りこぼさず、徹底的に対応しきることが当たり前だという土壌をつくるためです。これはVPoPとして当然やるべきことだと思うんですよね。

VPoPである私がこうした行動を取るので、メンバーは優先度の高い改善案件を放置してはいけないとよくわかっています。「プロダクトの改善は、プロダクトの全責任を負っている西場さんがこれだけ本気で取り組むような重要度の高いことなんだ」と、チーム全体の意識が高まるんです。

プロダクトに関するフィードバックの情報はどんなに些細なものだとしても、非常に価値が高いものです。どれだけ数が多くても、プロダクトの責任者が全てに目を通すべきだと考えています。

私は、非効率なことも不毛なこともやりたくないし、価値のあることにしっかりと時間と労力をかけたいと思うタイプです。だから、「FBに目を通し、反映すべきものは反映する」というプロダクトの改善にとって価値の高い仕事は、どんなに量が多くても注力して時間をかけたいと思っています。

——徹底的な仕組み化と土壌づくりによって、メンバー全員がプロダクトへの改善点を常に考え行動し続けることができているんですね。

西場：そうですね。Sansanではプロダクトにかかわる全員が「プロダクト負債」にアンテナを張れるよう、さまざまな取り組みを行っています。

例えば、ヘビーユーザーの不満をキャッチするために、営業メンバーには全員「Sansan」を使ってもらっています。逆に、初めてプロダクトに触れた人がつまずくポイントも把握したくて、ポジションを問わず多くの中途社員に、入社後1ヶ月の頃に「Sansan」のユーザビリティ調査に協力してもらっています。

他には、プロダクトマネージャーがエンジニアに改善点を聞きに行き、開発生産性の低下につながっている機能がないかを確認したり、自分自身で画面を操作したりして、違和感のある部分がないかをチェックしたりしています。

改善対応完了後は、フィードバックをくれた人に報告します。これは「自分の声を届けることには価値があるんだ」とその人に認識してもらいたいからです。自分の声がプロダクトを良い方向に変えたと知れば、きっとまた何か気づいたことがあったときに、率直にシェアしてくれるのではないかと思っています。

声を上げたら絶対に拾ってくれる、対応が完了したら共有してくれる、そういうカルチャーがあれば、確実に心理的安全性は上がる。「プロダクトで気づいたことがあったら、とりあえずエンジニアに言ってみよう」って感じてもらえると思うんですよ。

——「捨てる」を実践する上で、最も難しいことは何だと思いますか？

西場：プロダクトの関係者全員が「プロダクトビジョン」を共有し、それに対する自信を持ち続けることです。

もし自分たちが狙っている市場や、解決しようとしている課題に自信が持てなければ、ユーザーから「こんな機能がほしい」と言われたときに、プロダクトビジョンに沿ったものでなくてもつくってしまうかもしれません。本来は捨てた方がいい機能でも、ユーザーから「残してほしい」と言われたら、残してしまう、なんていうことも出てきてしまうでしょう。

この「揺らぎ」は、プロダクトをつくる上で非常に厄介なものです。この「揺らぎ」に左右されてしまうと、自社プロダクトならではの強みを見失ってしまうからです。

——プロダクトビジョンをはっきりと見定めるためには、どうすれば良いのでしょうか？

西場：プロダクトの向かう方向性や自分たちの価値観を信じ続けるに足るファクトを集め続けることが大切です。

まず、ファクトに基づいてプロダクトビジョンを固め、実現に向かってのロードマップを引く。そのうえで最新のファクトを集め続け、「既存のプロダクトビジョンやロードマップは、ファクトとマッチしていないかもしれない」と感じたら、その違和感を無視せず、プロダクトビジョンやロードマップを更新する。これらを継続することによってこそ、常に最新のファクトに基づいたプロダクトビジョンを信じ続けることができ、「捨てるべき」機能を「捨てるべきだ」と判断できるようになるのです。

例えば「Sansan」では、ユーザーインタビューなどで得られたファクトをもとに、プロダクト開発のロードマップを作成し、1年後、2年後のあるべき姿を描いています。自分たちが目指す先で、どんな価値を創出できそうか。新しい市場はあるのか。どんな課題を、どのくらいのクオリティで解決できそうなのか。これらを常に探り続けることで、「Sansan」が目指す姿が明確になります。

普段からこうした取り組みを続けていれば、プロダクトビジョンに合わない機能はそもそもつくらないし、すでにあるなら消すと判断できるはずです。私たちは常に適材適所を見極めなくてはなりません。プロダクトビジョンはそのために存在しています。

すべての関係者にプロダクトビジョンを共有したくて、CSなどのビジネス部門と一緒にワークショップをやったりもしています。もともと他部門と連携したいという声がメンバーの中から上がっていたので、その想いに応えるために改めて場を設けました。こういう部門を超えたディスカッションの場があることで、1つのプロダクトについて一緒に考える土壌をつくることにもなりますし、価値観の違う職域のメンバー同士の相互理解とか、目線合わせにもなると思っています。

——「捨てる」重要性は、なぜこれほどSansanの中で徹底されてきたのでしょうか？

西場： 誤解のないように言っておきたいんですけど、Sansanでは捨てることは大事にしているものの、「捨てる可能性のある機能をつくるな」とは言いません。大切なのは、失敗を恐れなくてもいいように「捨てる」仕組みをきちんとつくっておくことです。

私たちが目指すのは、新しい働き方の概念をつくり、それをリードしていくことです。初期の「Sansan」では、現物で管理するものだとされていた名刺をデータ化し、誰でも参照できる世界をつくりました。今まで誰もが当たり前だと思っていた「不便」を高いレベルで解消し、新しい「便利」をつくることは、決して簡単ではありません。それを実現するためには仮説検証を繰り返し、確度を上げていくしかないんです。

「捨てる」を常に考え続けること。それが、市場に対する大きなチャレンジを後押しするのだと思います。

取材：石川香苗子
執筆：一本麻衣
編集：光松瞳、王雨舟、石川香苗子
撮影：曽川拓哉