なぜ機能を削るのが良いのか

基本忙しいな〜と思いつつ、幸いにも仲良く仕事ができてることが多い。その理由を考えてた時に気づいたことをまとめたのがこの文章になる。ここで言いたいことはつまり、「機能を削ることはユーザーと開発チーム双方にとって、恐らく各位が考えている以上に良いことだ」ということだ。

なお、サムネは「機能を削ぎ落としていく過程はまるで彫刻製作のようだ...」と一瞬考えた時に程よい画像をとってきたのだけれど、単純にキモいなと思ったのと、的を射ているようで射てない気がしたし、プロダクト開発も彫刻もそんな知らないので、可及的速やかに忘れることにした。

いかにしてチームは殺伐となるか

リリース間際やプロダクト開発が長期化すると、えてしてチームは殺伐としがち。自分が関わったチームでのプロダクト開発では、半々で殺伐なシーンと平和なシーンだった。

殺伐な開発は、その後チームの人間関係に消しがたい遺恨を残し、結果退職や倒産といった非常に世知辛い結末を迎えることがある。「ことがある」と書いたけど経験上マジで100%退職者が出る。

そういったカミカゼのような特攻で死者を出しながらプロダクト開発をするのも、流派としてはありなのかもしれない。けど、できる限り僕は平和かつ持続可能な開発を行い、ユーザーに対しての利益を生み続け、チームが仲良くできるような環境を作り、自分の成長機会も得たい。

何度か新規の開発というのを経験した結果、殺伐としたチームになるか、それとも平和なチームとなるかの分水嶺の一つに、「"いかにして実装をしないで済むか"を皆が真剣に考えたか」という要素があると感じている。

僕は関与したほぼ全ての開発において、「この機能/UIいります！？」と叫び回っている気がしている。そしてこの主旨の発言を、チームメンバー全員が心理的安全性を担保しつつ言い合える文化だった場合、チームが平和でいられたという経験則がある。

機能を削るとなぜ良いのか

機能を削ることで得られるのは、もちろん工数削減による単純な時間的余裕（サボタージュの機会）もあるが、他にもいくつかある。

・ユーザーに対してよりシンプル（=初期の学習コストが低い）機能が提供できる
・時間的な余裕が発生したことにより精神的な負荷が低下する
・機能の効果検証時にノイズが少なくなる
・後々チームメンバーが互いに「一体誰がこの不要な仕様追加したんだ...」という疑心暗鬼に陥らずに済む

以上がパッと思いつくメリット。

もちろん、機能を多くすればするほどユーザーも関心を持ってくれる可能性が上がる場合もある。が、機能が増えすぎて後悔したことはあっても、減りすぎて後悔したことはないので、もう少し思い切ってこれらのメリットを享受するように取り組んだ方がいいと思う。

機能過多とチームの疑心暗鬼

"機能を削る旨の発言をチーム内で心理的安全性を担保しつつ言えたかどうかが分水嶺"と先ほど述べたけど、その要因となっているのが箇条書きで書いた最後の項目だと思う。

意外と見逃しがち/甘く見積もりがちなのだけれど、増えすぎた機能をそのままに開発を進めると、後々誰が責任をとることもなく不満が積み上がっていくという問題がある。

究極、現実的な工数と仕様の折り合いをつけられなかったPO/PMが悪いといえばそれまでなのだけれど、一人を断罪したからといって何が解決するわけでもない。仕様や機能、デザインを削ると言う行為に対して全員が責任を持たないと、「自分はやることやったけど、間に合わない。これは仕様と折り合いがつけられない(チームの文化|PO|PM|その機能を推してたメンバー)が悪い」という責任のなすりつけあいが、水面下で行われることになる。

こういう発言が悪い意味で表に出やすいチームもあるにはあるが、ある程度クリエイターのプライドみたいなのがあると、こう言った不満には皆押し黙り、目に見えない形で蓄積され、何処かのタイミングで爆発することになるのが通例だと思う。

逆に、機能を徹底的に削りながら進めれば、「最低限担保すべき価値提供」において、「自分はどこまでの責任を負うべきか」が非常に明確になる。

仕様や機能というのは、たとえ最初皆が納得したとしても、後々油断せず削っていかなければ、責任の所在が不明瞭なまま想定と実作業とのギャップに苦しみ不満が募っていくことになる。こうした不満を生じさせないためにも、全てのチームには「機能を削ること」への責任を自覚しなければならないという、隠れた義務がある。

なぜ機能を削れないのか

とはいえ、あくまで個人的な経験則の話だし、機能を削りにくい場合というのももちろんあると思う。

・事業ドメインの制約上、セキュリティ・リーガル面を理由に盛り込まないといけない機能が多い
・クライアント企業が存在して、かつ意思決定権が手元にない
・PO/PMが機能削減に対して理解がない

というのが、思い当たるケース。自社サービス開発だったり、クライアントが交渉に応じてくれやすいチームじゃないときついってのはその通りだと思う。それはごめんなさいという気持ち。

削らない方がいい機能は何か

よくありがちなミスとして、「出来合いのフレームワークでデザインをチープにしてフロント側の工数を削る」というのがある。フレームワーク使うのは全然良いのだけれど、全部乗っかろうとするのはヤバい匂いがする。

今はもう令和の時代で、ユーザーも目が肥えているんだから不用意に削ると痛い目を見る、というかユーザーは関心を持ってくれなくて即死する。

あと、「めんどくさいから削る」というのは性根として別にあっても良いとは思うけど、「ユーザー体験に大きく影響を及ぼすけど、実装難易度が高いのでやめたい」という怠けをなんとか取り繕おうとするのはよろしくない。逆に、「見た目の違いは誤差程度だが、コンポーネントの表示幅の調整に実はかなり工数がかかる」とかは削ってしまった方がいいと思う。

まとめ

以上をまとめると、「提供し、検証したいUXは損なわずに削れる機能を徹底的に削れるか、そういった隠れた義務を全員が当たり前に全うすると、チームは平和になる可能性が高くなる」ということが言いたかった。