誰も使わない機能を、誰も消せない理由

TL;DR

前職で、ある業務SaaSのアプリの保守を担当していた時期があった。実利用はほぼゼロなのに、改修要望だけは定期的に届く。サンクコストの罠だとは頭ではわかっていたけれど、それでも「この機能、なくしませんか」とは、誰も言い出せなかった。私を含めて。

この記事の中心の問いは、残すか、消すか、改善するかを、根拠を持って判断できる場が、SIerではなぜ作りにくいのか、というものだ。「持ち主不在の機能」がそれを生む。AI時代には、その判断する場はさらに作りにくくなる気がしている。

それでも、保守ベンダーの立場で個人として打てる手はある。利用状況の計測を提案し、合意のうえでフォーマット化された報告に乗せる。逆損益分岐点を試算する。どれも、判断する場の素材を場に置く動きだ。当時の私はやらなかった。今、振り返って書き残しておく。

ある業務SaaSの保守現場から

前職で、ある業務SaaSのまわりに置かれていた独自アプリの保守を、何年か担当していた時期がある。SaaSの種類は伏せておくが、業務上の登録処理を1申請=1フォームでしか受け付けない設計のSaaSだった、とだけ書いておく。

ユーザ企業の利用部門からは、当然のように「数十件まとめて登録したい」という声が上がる。導入の意思決定をした人たちは、Excelで一括登録できる独自アプリを別途作る、という解決を選んだ。私の所属していた開発ベンダーが、その独自アプリの構築と保守を請け負っていた。

バリデーション地獄

Excelシートには、業務上のデータ項目が数十列並んでいた。それぞれにバリデーションがある。SaaS側の項目仕様が変わるたびに、アプリ側の入力チェックも追従改修する。デグレ確認が本当につらかった。項目の組み合わせ次第で矛盾するパターンは膨大で、テストケースを書き切ることは事実上不可能。半ば祈りながらリリースしていた、というのが本音だ。

正直に書くと、バグの温床だった。

ほぼ使われない、それでも届く改修要望

そして、この機能はほぼ使われていなかった。

正確には、本稼働してから私が離任するまでの間に、一括登録経由で実際に処理された申請はほんの一握り。それも利用部門が主導したテスト的な登録だ。それ以外の申請は全部、SaaS本体の単票登録経由で行われていた。

矛盾しているように聞こえるかもしれないけれど、改善要望は定期的に届いた。たぶん使おうとしたが使いづらいから、結局使われない、という状態だったのだと思う。利用部門の頭の中には「使えるようになれば使いたい機能」として残っていて、だからこそ要望は止まらない。「項目の表示順を変えてほしい」「必須項目に色を付けてほしい」「使わない項目はグレーアウトしてほしい」。要望そのものは正当だった。Excelは確かに使いづらかったから。でも、その改修を真面目にやろうとすると、また数十列分のバリデーション地獄を通過することになる。

私はその状態を保守し続けていた。誰も使わない機能を、改修要望に応えながら、デグレに怯えながら。

サンクコストの罠だ、と頭ではわかっていた。逆損益分岐点を出すアプローチがあることも知っていた。それでも、私はやらなかった。避けている自分自身を観察しながら、目の前の改修を続けていた。

この記事は、なぜ私が「この機能、なくしませんか」と言えなかったのか、その理由を自分なりに棚卸ししてみる試みだ。

そもそも、なぜ「なくす」を考えるのか

「使われていないなら、別に残しておけばいいのでは?」というのは、当時の私自身もどこかで持っていた疑問だ。先に進む前に、なぜ削除を検討すべきかを整理しておきたい。

機能が積み上がっていくと、見えにくい弊害が3つの方向から効いてくる。

コストの観点

コードベースの劣化、サポートコストの増加、テスト工数の増大、新メンバーのオンボーディング長期化。一機能あたりは小さくても、機能の数だけ積み上がる。

特にSIerの保守では、使われていない機能のためのテストが、毎回走り続ける。前職でも、SaaS側の項目仕様が変わるたびに、誰も使っていない機能のバリデーション追従改修とデグレ確認を、半年に一度くらい繰り返していた。実利用ゼロの機能のために、保守ベンダーの工数が確実に発生する。見えない税金のようなものだ。

UI/UXの観点

使われない機能が画面に並んでいると、ユーザは毎回「どれを使えばいいのか」を判断することになる。認知負荷は機能の数に比例して増える。業務システムのような複雑なものだと、「使わない機能をどう避けるか」だけでヘルプデスクへの問い合わせが発生したりもする。

機能が増えると、機能間の整合性も維持しづらい。Aを改修したらBとの表記が揃わなくなる、Aで設定したことがBに反映されない、といった小さな矛盾が、ユーザの操作体験を少しずつ削っていく。

プロダクトの観点

機能を抱え続けるほど、プロダクトとしての軸がボヤけてくる。コアバリューが薄まって、ユーザにとって「これは何のためのプロダクトなのか」が伝わりにくくなる。

新規ユーザのオンボーディングにも効いてくる。「最初に何を触ればいいのか」「このプロダクトで自分は何ができるのか」が見えにくいプロダクトは、初手で振り落とされやすい。機能が多ければ多いほどいい、というのはたぶん幻想だ。

「残す」を選ぶ場合でも、根拠は必要

もちろん、「UX改善すれば使われるかもしれない」「いざというときの保険として残すべき」という選択肢もある。それを否定する気はない。でも、その判断をするためにも、まず現状のコストと便益を可視化する必要がある。根拠なく「とりあえず残す」を選び続けるのは、結局サンクコストの罠だった、と私は思う。

だからこの記事は、「機能はぜんぶ消すべき」と言いたいわけではない。残すか、消すか、改善するかを、根拠を持って判断できる場を作ることが、関心の中心にある。そのうえで、なぜそれが現場では難しいのか、を掘っていく。

SIerでは「判断する場」がそもそも作られない

ここで「判断する場」と呼んでいるのは、機能の存廃について、関係者が根拠を持って議論して結論を出せる場面・プロセスのことだ。会議体そのものを指すこともあれば、制度的な手続きを指すこともある。いずれにせよ、削除という意思決定が成立するための土台を、便宜的にこう呼んでいる。

その「判断する場」が成立するためには、ざっくり4つの要素が必要だと思う。権限(誰が決めるか)、情報(何を見て決めるか)、評価軸(削除を成果として認める仕組み)、継続性(廃止条件を時間軸で追えるか)。

プロダクト組織では、この4つを束ねる役割が一応ある。プロダクトオーナー(PO) だ。POは、新機能を作るだけでなく、過去のYesを取り消すのも仕事のうち、ということになっている。仮説が外れた、ユーザに刺さらなかった、運用コストが見合わなかった、なら捨てる。判断する場が、PO中心に成立している。

少なくとも私が見てきた請負/準委任の現場では、この役割が明示的に設計されていなかった。発注側の情シスや業務オーナーが担うべきだ、という規範論はありうるけれど、実装としては誰のジョブディスクリプションにも書かれていない。

設計と運用と利用と保守が全部別の人

前職の現場の登場人物を整理しておく。役割名で書く。

• 導入ベンダー: SaaSの選定と導入を主導した。アプリの初期要件定義にも関与した
• ユーザ企業のIT部門: SaaS導入の意思決定と初期の運用設計を担当した
• ユーザ企業の利用部門: 実際にSaaSを使う部門。改善要望の発信源
• 開発ベンダー(当時の私): アプリの新規開発と保守を請け負っていた

設計した人、運用する人、利用する人、保守する人が、ぜんぶ違う。誰もこの機能の生殺与奪を全権で握っていない。私はこの状態を持ち主不在の機能と勝手に呼ぶことにした。

4つの要素が、どれも誰のものでもない

持ち主不在の機能では、判断する場に必要な4つの要素が、揃って欠ける。

• 権限: 過去のYesを取り消す権限が、4アクターのどこにも明示的にない。発注側に決裁者はいるけれど、機能単位で「やめる」を発意する権限の所在は曖昧
• 情報: 利用ログの取得・分析は、導入ベンダーの契約スコープには通常含まれない。開発ベンダーの保守契約にも含まれない。利用部門が自前で取ることもまずない
• 評価軸: SIerの評価軸は工数・改修件数・新規開発の実績で構成されていて、削除は工数を生まないから評価対象になりにくい。「今期、この機能を消しました」がプラス評価になる制度設計を、私はあまり見たことがない
• 継続性: 廃止条件を要件定義書に書く文化がない。請負契約のスコープは「作る要件」であって、「やめる条件」を契約に盛り込むカルチャーは、たぶんない

機能を作るときには、複数のアクターがそれぞれの理由でYesを言うことができる。でも、機能をなくすときには、ぜんぶの人が全員Noを言わないといけない。判断する場そのものが立ち上がらないので、新規追加だけが進んで、削除は永遠に発意されない。

補足: 吉羽さんの「機能追加と削除の非対称性」と重なる

この観察は、吉羽龍太郎さんが書いている「機能追加と削除の非対称性」^[1]とも重なる。吉羽さんはコスト・心理・情報・政治・依存・時間軸の6つを挙げているが、SIerの現場ではそれぞれがさらに強く効く。補足として並べておく。

非対称性	概要	SIerでは
コスト	削除は追加の何倍も工数がかかる	削除作業の多くが、誰の契約スコープにも収まらない
心理	使ってる人の声だけ届く	削除提案を発するチャネル自体がない
情報	使われていないことは沈黙だからわかりにくい	利用ログ取得が誰の責務でもない
政治・評価	削除はアウトプットを生まないので評価されにくい	過去のYesを言った関係者全員と気まずくなる
依存	派生物が積み上がって削除コストが複利で増える	派生物の扱いを誰が決めるか契約に書かれていない
時間軸	削除便益は中長期で数値化しづらい	単年度予算で中長期便益が組み込まれない

POが存在しないこと、それ自体が悪なのではない。SIerはその構造で何十年もまわってきた。ただ、削除という意思決定は、判断する場があってはじめて生まれる。判断する場がない以上、削除はどれだけ必要でも発意されない、ということになる。

改修のブレーキが効いたとき

実際、前職でも一度だけ、改修の慣性にブレーキがかかったことがあった。それは前述の機能の改修是非の議論をしている場で「改修をする前に、まずは今のマニュアルを周知して、実際に使ってもらってから改善要望を見よう」という趣旨の発言が出たときだ。

この発言をした彼は決して「機能を消そう」とは言わなかった。彼はこの機能の設計コンセプトを当初に作った側の人で、当初のコンセプトを根底から変えるような改善要望は、彼にとっては看過できないものだったかもしれない。彼自身がポジションを守りたいという欲求もあったと思う。それでも、需要側の事実確認が済むまで供給投資を止める、という意見を表明した。

これは結果的に判断する場の入口を作っていたのだと、今考えるとそう思う。逆に言うと、こういう偶然の重なりか、あとで書くような継続的に置かれた素材かがない限り、SIerでは判断する場はなかなか立ち上がらない。

ついでに正直に書いておくと、この記事を書いている私自身も、「保守地獄からの解放」という利害でこの方向に立っている。だから、構造批判だけしているつもりはない。私もこの構造の中の登場人物のひとりだ。

AI時代、判断する場はさらに作りにくくなる

ここからは、AI時代に何が起きそうか、という見立ての話だ。

AIが軽くするのは「作る」局面だけで、「判断する」局面は重いままだ。「使われているかを測る」「消してよいと合意する」「派生物を整理する」「責任分界を再設計する」、これらの局面では人間系の意思決定が残るので、AIで加速しない。結果として、「作る判断」だけが軽くなって、残す/消す/改善する側の判断との非対称性がさらに広がる。判断する場は、AI時代にもう一段、作りにくくなる。

もちろん、AIはログ分析、テスト生成、影響調査の一部も軽くする。ただし、「消してよい」と合意すること、責任分界を引き直すこと、過去の意思決定を取り消すことまでは、自動では引き受けてくれない。だから、AIが軽くする領域と、人間系の意思決定として残る領域の差は、むしろ広がっていく。

及川卓也さんと吉羽さんの対談^[2]で、吉羽さんはこんなことを言っている。

これまでの構造では、開発チームが工数を理由に交渉することで、結果としてスコープが絞られていた。しかしAIが登場し『何でもすぐに作れる』ようになったら、ブレーキが効かなくなる。

これまでは『開発チームが無理だと言っている』という言い訳が、ステークホルダーに対する盾になっていた。しかし、AIが24時間365日作れてしまう以上、その技はもう使えない。

保守ベンダーは従来、「工数がかかります」「デグレが怖いです」「テストケースが膨大です」と発話することで、改修の慣性を遅らせる暗黙のブレーキを発生させてきた。これは交渉戦術であると同時に、結果として無駄な改修を抑制する副作用も果たしていたと思う。AIで改修コストが下がると、この盾は効きにくくなる。

これだけならまだいい。もう一段悪い話は、判断する場を立ち上げようとする側のインセンティブまで、一緒に消えてしまうかもしれないことだ。

「とりあえず先に作って判断しましょう」は、改修コストが重いという事実で押し戻されていたことが多いと思う。重い投資判断だからこそ、需要側のエビデンスを先に確認して発注はそこから判断しよう、という論理が合理性を持ち得た。しかし、AIで実装コストが目に見えて軽くなった世界では、発注側の体感としては「エージェントを回せばすぐ作れる」が先に立ってしまう。すなわち、「先に作って様子を見ましょう」と返されやすくなる。

しかも、ブレーキをかける側のインセンティブも変質する。改修コストが重かった時代には、自分の立場や正統性からブレーキをかける動機があった。でも改修が軽い時代には、「楽だからやっちゃいましょう」に流れる方が、関係者全員と気まずくならずに済む。場を立ち上げるリスクとリターンの比率が、AIによって反転してしまう。

つまり、AI時代こそ、判断する場を意図的に作らないと、非対称性は指数的に広がる。吉羽さんが「不均衡な状況でAIを回し続ければ、負債だけが積み上がる地獄絵図」^[2:1] と書いたのは、プロダクト組織でも同じ警告だけれど、判断する場の素地そのものが脆弱なSIerの現場では、もう一段深い形で効きそうだと思う。

それでも、判断する場の素材は個人にも置ける

ここまでで、SIerには判断する場が構造的に作りにくいことを書いてきた。前職の私は、その中でこの機能をずっと保守し続けていた。やれることがない、と諦めていた、というのが正直なところだ。

でも、今振り返ってみると、保守ベンダーの個人にもできることは、ゼロではなかった。判断する場の「素材」を、自分の手で場に置き続けることだ。組織設計を変えることはできない。POを召喚することもできない。それでも、素材を置き続ければ、判断する場が偶然にでも立ち上がる確率は、少しは上がる。

ここでは2つの手段を並べておく。どちらも、当時の私はやらなかったものだ。

手段1: 利用状況の計測 + 定期報告フォーマット

利用ログの取得を誰の責務にもしない、というのが SIer の構造的な弱点なら、保守ベンダー側から「使われ方を可視化させてください」と提案して、合意のうえで計測を入れるのが一つの手だと思う。軽微な保守改修の機会に、ログ集計の枠を相乗りさせれば、契約・監査・セキュリティ面の不安も場で潰せる。「機能の使われ方を把握したい」という提案自体は、たぶん発注側に反対する理由がない。

そのうえで、毎期、同じフォーマットで「使われ方サマリー」をステコミに出す。ポイントはフォーマット化のほうだ。一度きりの報告は流れてしまうけれど、毎期同じ枠で出てくる報告は、いずれ議題に組み込まれる。情報の非対称性が、少しずつ削れていく。

もちろん利用情報において個人情報やIPアドレス等は慎重に扱うべきではあるが、それでも簡易的にその機能の接続数やクリック数を定量化すること、それをサマリすることは個人で対処できる手段の一つであると考える。

手段2: 逆損益分岐点の試算

もう一つは、逆損益分岐点の試算だ。「この機能はいつの時点で、得られる便益より維持コストのほうが大きくなったのか」を、過去にさかのぼって見積もる。

過去数年の改修工数の累積、SaaS側の項目変更による追従改修の頻度とコスト、デグレ確認に費やした時間。そして分子側に置く実利用件数。前職の機能の場合、その分子はほとんどゼロだった。本稼働から数年で、ほんの一握りのテストデータだけ。バリデーションの追従改修にかかった人月と、その分子を並べてみたら、累積コストと累積便益の交点は、たぶん稼働してすぐのどこかにあったのだと思う。

ただし、逆損益分岐点の試算は単独では決定打にならない、と今は思う。試算結果を場にぽんと置いても、「ふーん、で?」で終わる可能性は十分にある。手段1で素材が継続的に場にあって、はじめて試算が対話の土台になる。

場の素材を置き続けるという、地味な動き

どちらの手段も、本質は同じだ。情報の非対称性を、少しずつ削って、判断する場の素材に変えていく。それだけ。組織設計が変わるわけではないし、POが降ってくるわけでもない。でも、ステコミで「ふーん、で?」と流される確率は、ちょっとは下がるかもしれない。

繰り返しになるが、当時の私はやらなかった。試算した結果を提示することがどんな反応を引き起こすか、その不確実性を引き受けたくなかった。それが正直なところだ。

今、現職で似た構造に出会ったときには、まず素材を場に置くところからやってみたい。サンクコストの罠と戦うには、戦う武器を揃えること、そこからしか始まらないと思う。

---

脚注

1. 吉羽龍太郎「機能追加と機能削除の非対称性」 https://x.com/ryuzee/status/2051081853738828257

2. 斉木 崇(編集部)「AI時代にプロダクトマネージャーは消滅するのか? 及川卓也×吉羽龍太郎が問う『最後に決断する人間』の価値」ProductZine, https://productzine.jp/article/detail/4267