はじめに
初めまして、ソーシャルデータバンク企画チームの塩浦です。
機能廃止という仕事は痛みを伴います。
新機能を出すことの3倍くらいの労力と根気が必要な作業です。
一方で、常に向き合い続けていくべき、価値のある仕事だと思っています。
私も何度か（そして現在進行形で）機能廃止の開発を行なっています。
備忘的に、機能廃止開発に取り組む中での苦労や学びを記事にしておこうと思います！
なぜ機能廃止するのか
そもそも、なぜわざわざ機能を廃止しなければならないのでしょうか？
弊社では次のようなパターンがありました。
- 費用対効果が低い
(ex)利用率は低いのに、データベースへの負荷が高くボトルネックになっている - 複雑性が高い
(ex)一部のユーザーだけが利用する設定項目が増えていき、画面が複雑になっている - 新旧バージョンの併存
(ex)同じことが実現できる機能が新旧の2バージョン存在しておりダブルメンテになっている - これらの混在パターン
(ex)パフォーマンスの問題を解決するために、既存機能と同じ機能を持つ改良版が別バージョンとして存在する
このように、価値以上に負債としての側面が強くなっている機能について、廃止の検討をすることがありました。
何が難しいか
機能廃止の難しさは皆さんも想像に難くないのではないかと思います。
利用しているユーザーへの説明
「利用率が低い機能」であっても「一部のユーザーだけが使う設定」であっても、実際に利用しているユーザーは存在します。
ある日突然、えいやで廃止をしてしまっては、一部のユーザーに混乱が生じ、不利益を生んでしまいます。
なぜ廃止するのか、廃止したあとはどうしたらいいのか、ユーザーに説明し納得をしてもらわなければなりません。
影響度の把握
廃止した時の影響度を正確に把握することも難しさを感じます。
開発側の想定では大きな影響が出ないだろう、と判断した項目であっても、意外なユースケースが存在している場合もあります。
そのユースケースが利用しているユーザーにとって重要なものであった場合、廃止によって業務フローの実行が困難になってしまうことも考えられます。
データ移行
特に新旧バージョンの併存が存在していて、旧バージョンを廃止したい場合は、
現在時点で旧バージョンとして存在しているデータを新バージョンに移行する必要があります。
データ構造が近ければ移行もスムーズですが、必ずしもそうとは限りません。
新旧バージョンが生まれている時点で、何らかの技術的制約や歴史的経緯を含む場合も多く、
データ移行を実現するだけでもかなりの労力となる場合も存在します。
やったこと
社内の理解を得る
廃止を進めていく上で、社内のステークホルダーの理解を得ることは必須でした。
ユーザーの利用率や、この機能を維持していくことで発生するコスト・リスクについて定性・定量両面から説明し、
廃止という決断をすることに対して、全体としての意識統一を図りました。
廃止をする以上、一定のリスクは飲まなければなりません。
いざ廃止した後に、「担当のお客様から問い合わせがあったからやっぱり元に戻してほしい」となってしまうのは避けたいです。
新規作成の廃止から始める
廃止を進める上で、入口を閉めることは重要です。
どのように廃止していこうか、を考えているその瞬間もその機能を新たに利用し始めるユーザーがいるかもしれません。
利用するユーザーが増えれば、影響範囲も大きくなっていきます。
廃止する前に、まずは新規作成を停止しました。
ユーザーとのコミュニケーション
ユーザーとのコミュニケーションは丁寧に進めました。
ビジネスサイド通じて事前のヒアリング、サービス画面への掲示、メール等別手段での連絡など、
影響を及ぼすユーザー（特に、その機能を熱心に利用しているユーザー）については、理由や代替手段の提示、お客様にやって欲しいアクションの提示を可能な限り行うようにしました。
「やりたいことの実現」にコミットする
ユーザーとのコミュニケーションの中で代替手段の提示について触れました。
こういう時に私は「今この機能でできていることを別の形で提供する」という発想に陥りがちなのですが、その手前のフェーズとして「そもそも何がやりたいのか」を明確にするのが重要だと感じます。
機能はユーザーがやりたいことを実現するための手段でしかないからです。
「やりたいこと」が明確になったことで、実は既存の別機能で代替可能だったり、運用でカバーできたりすることもありました。
また、「使ってはいるけど特に大きな目的はなかった」というケースも存在します。そのような場合は、勇気を持って廃止に向けて説明していく姿勢も必要だろうと思います。
学び
リスクのない機能廃止はありません。
ユーザーとコミュニケーションをとり、社内の期待値を調整し、代替案を提示したとしても、廃止後にネガティブな声が上がることは避けられません。
だからこそ機能廃止は「痛み」を伴う仕事なのだと思います。
しかし、「リスクあるから廃止はできない」としてしまうと、負債が貯まっていく一方です。
痛みを覚悟で前に進んでいく覚悟が必要です。
ともすると、廃止の開発に関わるメンバーのモチベーションも下がってしまうこともあります。
せっかく作っているのに、悲しみに声ばかり届くのではそうなっても仕方ありません。
そういう時には、機能をなくすことは、機能をつくることと同じかそれ以上に「価値ある仕事」なのだとチームで共通認識を作ることが重要だと感じます。
一方で、廃止により不便さを感じてしまうお客様に対しては「将来的に今回以上の利益を提供する」という心構えでありたいと思います。
Discussion