🗣️
「その機能、今作る必要ある？」PM Akiさんが考える プロダクトにおける開発する／しないの決め方 レポート
公開
2025-04-13
更新
2025-04-13
文章量
約3595字
はじめに
2024年12月19日にオンラインで開催された本イベントは、「プロダクトにおいて本当に必要な機能しか作らない」という、ある種の“潔さ”に焦点を当てました。スタートアップや大企業でプロダクトを率いてきた経験を持つ PM Aki さんに、どのような視点で「開発する／しない」を決めているのかを語っていただきました。
往々にして、プロダクト開発の現場では「要望に押し流されてすべてを機能化してしまう」「ビジネスサイドからの曖昧なリクエストを断れない」といった状況が生まれがちです。エンジニアとしては「開発にリソースを割いたものの、思ったほど使われなかった」という苦い経験をお持ちの方もいるかもしれません。
本イベントは、そうした課題を乗り越えるうえで「どの基準で意思決定すれば良いのか」「議論を円滑に進めるためにどんな背景やロジックを共有すれば良いのか」を、Akiさんの実体験を交えながら紐解く内容となりました。
以下では、LT（ライトニングトーク）のエッセンスやQ&Aディスカッションの要点をまとめています。
https://offers-jp.connpass.com/event/336412/
1. イベント概要と流れ
本イベントはオンラインで行われ、60分のミートアップ形式に加えて、質疑応答の時間もたっぷり確保されました。
前半（約15分）：AkiさんによるLT 「なるべく機能を作らない理由」や「意思決定のフレームワーク」
後半（約30分）：ディスカッション・Q&A 進行役のモデレーターがPM目線・エンジニア目線それぞれのギャップを深掘り。参加者からの質問もリアルタイムで取り上げ。
運営からは「議論の出発点として、まずなぜAkiさんが“何も作りたくない”と発信しているのかを知ってほしい」という意図が共有されました。まさに「技術的にもビジネス的にも何かを作る前に立ち止まろう」というテーマが主軸です。
2. AkiさんによるLT：「その機能、今作る必要ある？ 」
働きたくない＝「機能を最小化したい」という本音
Akiさんが「働きたくない」という少し衝撃的なワードで伝えたいのは、「開発すべき機能を最小限にすることで大きな価値を生み出したい」という思想です。世の中の多くの機能追加が、実は不要であったり、あるいはメンテナンスコストを無視して拡張しすぎているのではないか、との問題提起が冒頭にありました。
全機能はリリース後に緩やかな陳腐化が始まる
Akiさんは「どんな機能でもリリース後に必ず陳腐化が始まる」と指摘しました。競合の参入や技術トレンドの変化によって、実装した瞬間から相対的な価値は下がっていき、そのたびにリファクタリングや追加投資が必要となるのです。
陳腐化：保守コストが増す、セキュリティ要件が上がる、ユーザーの期待値が変化する
作るべき理由を明確化：曖昧なまま実装を進めると「思った以上に保守が大変」「ROIを生まない」リスクが大きい
作らないためのチェックリスト
Akiさんが実際に社内で使用していた「機能開発の意思決定フレームワーク」は、以下の6項目をクリアするかどうかを確認する形です。
オペレーションで大体可能か
単に「アナログ対応すればいい」とは異なる。最適な体験を保ちながらオペレーションで代替できるか。
市場にある既存プロダクトで大体可能か
自社で作らなくても、他ツールを組み合わせれば十分な価値を提供できるかもしれない。
プロダクトが競争優位性につながるか
既に他社がやっている機能をわざわざ自社で作る意義はあるのか。どこで差別化できるか。
SLAに整合した保守体制が可能か
大きな投資を要する機能に対し、保守コストの覚悟があるか。想定規模が増えた時に体制を維持できるか。
ROIが出るか
金銭的・非金銭的いずれのリターンでも良いが、仮説を明確化する。
「今」やるべき理由が明確か
本当に今がベストなタイミングか。遅らせて問題ないかなど。
このチェックを行ったうえで、作ったほうが良いと判断された機能のみを優先的に開発する、という流れでした。一度作ると保守の責任が永続的に発生するという点を意識するだけでも、軽々に機能を増やさなくなる、とAkiさんは強調しました。
3. ディスカッション・Q&A
開発するべきではなかった機能の実例
Akiさんは、過去に「紙のチラシをスキャンし、AR的なコンテンツをスマホ上で展開する」という機能の運用経験を挙げました。
企画自体は話題性があるように見えた
しかし運用コストが膨大（毎週チラシのレイアウトやARデータ更新が発生）
収益面や費用対効果を検討していなかった 結果として、後から振り返ると「なぜここまで大きな労力をかけたのか」と後悔するほどの失敗だったといいます。
もっと早く開発すべきだったと後悔した例
「基本的には、すべてもっと早くできればよかった…となることが多い」とのこと。開発リソースが有限で、やりたい機能が際限なく出てくる現場では、どうしても後手に回ってしまう場面が生じがちです。ただ、本当にイノベーティブな機能であればリスクを踏まえても挑戦する価値があるため、大切なのは「リスクとリターンを正しく認識し、撤退基準も含めて合意形成する」ことだと話されました。
「顧客が頼んでいるから」という曖昧な判断を変えるには？
要望の背景を深掘り：顧客がその機能を求める理由は？ 自社が別のアプローチで満たせないか？
コミュニケーションで納得感を醸成：顧客要望だけが根拠なら、本当に自社で作る意義はあるかを対話して掘り下げる
売上や優先度に影響するなら覚悟をもって：顧客が売上の大部分を占めるなど特別な事情がある場合は、やむを得ず作ることも。ただし将来の負債をどこまで許容するか、撤退の基準をどうするかは先に議論する
エンジニアは開発判断にどこまで関与すべき？
Akiさんは「エンジニアがビジネス面やROIを語ってくれると大変ありがたい」と語ります。ただ、一方でビジネス面が苦手なら、その立場を無理強いする必要もないとも。
重要なのは「お互いが得意な領域を理解し、補完し合う関係を作る」こと
エンジニアはビジネス要件に対し、実装面の負債コスト・保守コストを率直に提案
PMはその意見を尊重しつつ、ビジネス上の覚悟や撤退基準を明確にする
このように「チームメンバーが自己開示し合う」ことが、開発判断を円滑に進める鍵だといえます。
その他のQAピックアップ
リリース後、本当に必要だったかの振り返りは？ → スクラムのレトロスペクティブや追加機能検討時に「前回の成果」を再チェックしている。別途、関係者全員で集まり振り返る会を設定する場合も。
ビジョンとの整合がない場合はどうする？ → 選択肢のROI比較以前に、プロダクトの中核ビジョンとの整合を再検討する。競争優位が得られないなら、他のソリューションで十分では？
1度サービスを離れたユーザーを戻す施策は？ → 離れた理由がわからないことが多く、コストに対しリターンが出るかは不透明。新規ユーザー獲得に注力する方が効果的なケースが大半。
4. 全体を踏まえた感想
Akiさんの主張は「どんな機能でもリリースした時点から負債になる可能性がある」という、一見ドキッとする視点でした。しかし、そこには「本当に必要で意義のある機能に限られたリソースを注ぎ込み、最大の価値を生み出そう」というポジティブなメッセージが込められています。
エンジニアとして日々感じる「誰が望んでいるのかもはや分からない機能を保守し続ける」苦しみは、プロダクトマネージャーの思考プロセスやビジネス上の背景を知ることで、より解消へ近づくかもしれません。いま求められるのは「開発しない理由」を納得いくまで擦り合わせること。そして、どうしてもリスクを取るなら、「撤退基準や運用コストを事前に見積もり、組織全体で覚悟する」ことが大切と語られました。
プロダクトづくりはビジネス的にも技術的にも複雑でリスクの高い行為ですが、Akiさんの丁寧かつ大胆な実例は、開発現場に新しい視点を投げかけてくれます。「あえて作らない」「小さく作る」「途中でやめる選択肢を持つ」 —— そんな選択肢をチームの武器として磨いていけるかどうかが、これからのプロダクト開発を左右するのではないでしょうか。
本イベントを通じて、エンジニア・PM・ビジネスサイドそれぞれが「どんな指標やフレームワークで開発の是非を判断するのか」を共有し合う重要性が改めて示されました。プロダクト成功への近道は、作るものをただ増やすのではなく、「作らないものを明確にし、本当に作るべきものを選び抜く」ことなのかもしれません。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
