機能を作るな。楽して作るな。 （LayerX社内資料） Don’t Build Features. Don’t Take the Easy Way Out.

LayerX社内の定例でつかった資料です。

Transcript

1. © LayerX Inc. 機能を作るな。楽して作るな。 2026/06/15 @mosa_siru (榎本悠介) LayerX社内資料
2. 2 © LayerX Inc. バクラクは圧倒的に使いやすいことがアイデンティティ 経費精算？勤怠？給与？いつからあるのその市場？ いまバクラクが作っている理由って何？ 後発でも戦えている理由はプロダクト。 体験だけは負けてはいけない。 Read Me
3. 3 © LayerX Inc. toBのプロダクトは構造的に悪くなりやすい 顧客拡⼤のために多様な業務フローに対応したくなるから。 良くないことに、体験が悪化しても使われ続ける。なぜなら • なんらかやらないといけない業務だから（業務整理をしない限り） • 導⼊意思決定者と利⽤者が異なったりするから • 移⾏のコストが⾼いから ある程度使われ続けること = 良いプロダクトであることの証左ではない そして基本的にバックオフィスプロダクトは恨みを買いやすい。 僕はそれが許せなくてバクラクを作りはじめた Read Me
4. 機能をつくることはマイナスである
5. 5 © LayerX Inc. 機能をつくることそれ単体に価値はない、むしろマイナスである 使われて初めて価値が出る 使われて運⽤に乗って初めて価値が出る 使わないユーザーには認知負荷を招く。 端的にいうと邪魔。理解ができない。とっつきづらい。無駄なストレス。 Read Me
6. 6 © LayerX Inc. 機能は未来に負担をおしつける 次の開発が遅くなる。 バグがないか常に動作確認し続ける必要がある。未来永劫。 パフォーマンスが悪くなる。その機能のせいでパフォーマンスの改善ができなくなる。 未来に悪影響をもたらす。 リファクタ、リアーキ、何らかの障壁になり続ける。 AIのコンテキストを無駄に⾷う。それも永劫。それは遅さとAIコストにつながる。 後続の⼈間の理解を要求し続ける。 そしてもちろんその時間で本来別のものが提供できた。機会コストの無駄である。 機能は、使わないユーザーにとっては百害あって⼀利なし。 Read Me
7. 使われないものを作るな 正しくないものを作るな
8. 8 © LayerX Inc. 使われないものを作るな 暇でいい、暇なほうがずっといい エンジニアは、作らないことは悪じゃない PdMは、エンジニアを暇させることは悪じゃない 間違ったものを作って未来とユーザーに負担を強いるより100倍良い 拙速な開発にストップをかけることは明確にあなたの仕事 PdMとかエンジニアとかデザイナーとかQAとか関係ない。 「AIで作れるから⼀旦作るか」と、とりあえず作ってないか？作ったものを誰かに判断させるコストをお しつけてないか？ Read Me
9. 9 © LayerX Inc. 過去の例：認証基盤のリニューアル撤退 Read Me https://note.com/applism_118/n/n6ac43ace4566
10. 10 © LayerX Inc. じゃあ、⼀部の⼈しか使わない機能はどうすればいいのか ⾊々な業種‧業態‧業務フローがある。⼀部の会社しか使わない機能は構造上存在する。時々し か使わない機能は存在する。 理想は、機能をつくるなら、欲しい⼈が欲しくなったときに気づく場所におく。 AIのSkillとおなじ。 ⼈間のコンテキストは限界がある。 使おうとおもったら⾃然と気付けるような場所。 Read Me
11. 11 © LayerX Inc. じゃあ、設定でON/OFFできるようにすればいいのか 明確にNo。 設定の認知コストがかかる。それは⼈間もだし、AIも含む。 設定に気づかせない限り誰も使わない機能である。それは存在しないのと同じ。作らない⽅が良い。気づかない ⼈、使わない⼈には百害あって⼀利なし。 設定に気付く⼈は、適当な場所においたら数%未満だろう。 設定をおくとしても、デフォルト値はなにかも徹底的に考え続ける必要がある。それを放棄するのはありえな い。 そして設定の分岐の数だけ動作確認で後ろのひとは永遠に苦しみ続ける お客さんへの案内は苦しみ続ける お客さんに設定を探し理解するコストを負担させているだけである。設定という概念は⼀⽣残る。 Read Me
12. 12 © LayerX Inc. 効果の逓減どころかマイナス 「みんなが使う機能」は減っていく 作る価値は逓減していく。もうそれは宿命。 むしろ判断をミスるとマイナスになる。機能が積み重なるほどリスクがあがる。 「もうコスパ悪いので、このプロダクト開発とめましょう」過去にいってくれたPdMがいた あなたがその現場を⼀番わかっているはず それを⾔えるくらいの解像度になれると理想。 あなたのほうがあなたのプロダクトをわかっている。 つくるなら、価値のあるものを作ろう。 Read Me
13. アウトプットの誘惑
14. 14 © LayerX Inc. 機能を作ることは楽しい なんかやった気になる。 速くつくって「すごいね！」と誰だって⾔われたい ⾮エンジニアでも作れるとなるとなおさら。 「もうエンジニアじゃん！」と誰だって⾔われたい Read Me
15. 15 © LayerX Inc. でも、あなたは責任を取り続けられますか Read Me あなたはそのコードがバグったときに責任取れますか セキュリティインシデントがおきたときに責任取れますか コードは、誰かが必ず⾯倒を⾒続ける コードは、AIのコンテキストを奪い続ける 動作は、誰かが必ず確認をし続ける ユーザーは、その機能に付き合い続ける 点として速く作る、アウトプットの誘惑に打ち勝たないといけない。
16. 16 © LayerX Inc. Read Me ⼀瞬のアウトプットが速いだけで 本当にアウトカムが速いですか アウトカムとかむずかしい⽤語だけど、要するに本当にユーザーはうれしがってますか 使わないユーザーに迷惑をかけていませんか あなたのつくったものは、全体の総和は未来にわたってプラスと断⾔できますか 点として速いだけではないですか
17. 17 © LayerX Inc. Read Me 万⼀つくったものが全然だめで、機能を落とすとなったとき あなたが顧客に謝りに⾏けますか 代替となるやり⽅を、丁寧に⽰せますか。 あなたは機能を落とせますか
18. 18 © LayerX Inc. Read Me Howを考えるのはこちらの仕事。 「要望からプルリクが⾃動でつくられるように」「つくったものをAIがレビューすれば良 い」とかいう世界観を夢想するな。お客さんに⽢えるな。 あなたはなぜその要望が出るのかわかってるのか。その裏側にある業務の全体像をわかって いるのか。複数のお客さんに俯瞰して考えられているのか。 AIで増幅された間違い探しを、他のメンバーとユーザーと、後続のメンバーと未来の ユーザーにおしつけない。 ⾔われた通り作るな
19. 19 © LayerX Inc. Read Me それは前提なだけ。というかコスト掛かってるだけなので無駄に使うことは偉くない。 点として速くつくって偉いねの時代は終わり。 価値を速くつくらないと意味がない。 そして点としてでは意味がない。 価値を提供し続けるのがプロダクト。 AIで速くつくって偉いねの時代は終わり
20. 20 © LayerX Inc. Read Me あなたもよく理解していないコードを、誰が責任を取り続けられますか？ 楽して任せたから、解像度低くなってずっとAIに任せざるを得ないだけではないですか。 短期の楽さをとったことで、AI中毒になっているだけではないですか。 持続可能な開発になっていますか。 価値を提供し続けるのがプロダクト。 楽しているだけではないですか？
21. 21 © LayerX Inc. Read Me Speed is Moat. もうそれは⼤前提。 でも間違ったものを速く作ってもゼロどころかマイナス。 スピードを⾔い訳にしない。 もちろん事業上スピードは⼤事
22. まとめ
23. 23 © LayerX Inc. Read Me なんか楽に速くつくってほめられる、評価される。 それができたらいいよね。 でもそんなに仕事は簡単じゃない。 ドメイン理解、スピード、事業、技術、組織、未来、あらゆるトレードオフと意思決定の連続。プロダク ト作りは本当に難しい。 なるべく多くの⼈を幸せにし続けられるプロダクトにしていきましょう。 まとめ：作るな
24. 24 © LayerX Inc. Read Me 開発速度が速いとは 「点として速い」だけでは意味がない。AI時代のプロダクト開発で本当に⼤事なこと【Bet X】 CPOが開発する覚悟 (pmconf 2023) 合わせてお読みください