「作らない」と決めた判断も、覆る
質疑応答で、榎本氏はある機能の話をした。法対応のために設定でがんじがらめにしたくないという考えから、あえて細かい設定を作らなかった案件である。
「ところが、どうしてもギチギチの設定がないと導入しないというお客さまが複数現れて、僕を引き継いだプロダクトマネージャーがその設定を作ったことはありました」（榎本氏）
「機能を作るな」と言い切った本人の判断が、事業の現実によって覆された事例を、本人が公開の場で語ったことになる。作らない判断は正しければ通るわけではなく、時間が経てば前提も変わる。
失敗談は、それだけではなかった。榎本氏自身、工数やスケジュールのリスクを踏まえて安全寄りの設計を選んだあと、「とてもモヤモヤしてきて、これを世に出していいのか、と」いう状態が続き、結局作り直したことがあるという。
「正直なところ、2か月くらい無駄にした可能性があるんですよね」（榎本氏）
4月に入社したばかりの伊林氏が語ったのは、AIとの距離感を誤った経験だ。顧客が喜びそうな要望のうち、自分でできそうなものを選び、AIに任せて機能を出した。返ってきたのは問いだった。
「『それは本当に自分で考えてやったんですか』と言われて、『考えはしたけれど、少しAIに任せすぎていたかもしれません』と答えることになりました」（伊林氏）
意志は続かないし、判断は間違う。だからバクラク事業部には、それを前提にした会がある。
「レビュー会」は最後の防波堤
バクラク事業部には、5年ほど続く社内の会がある。
「毎週2回、木曜と金曜にそれぞれ30分ずつ、その週に作ったものを一気に共有する会があるんです」（榎本氏）
これがレビュー会だ。そして、その後がある。
「その後に、振り返り会というちょっと闇の会があります。発表者やプロダクトマネージャーたちが居残りをして、この機能をどうしたらもっとよくできるのか、お互いにバシバシ指摘し合う会です」（榎本氏）
指摘の粒度は細かい。「『ここのボタン、微妙じゃない？』というレベルで、みんなが想像しているよりも細かい粒度で指摘します」（榎本氏）。
西井氏は、自分がレビュー会に持ち込んだ機能を例に挙げた。バクラクカードで、通知設定UIの種類を追加したときのことである。カードの詳細画面に、サイズなどを深く考えないまま、既存の通知設定UIと同じ大きさのものをもう一つ並べて置いた。返ってきたのは、榎本氏のこんな指摘だった。
「ここに来る人の関心がそこにいくことはあまりないので、もう少し小さくてもいいんじゃない」（榎本氏）
この会は、単なる情報共有ではない。榎本氏はこう位置づける。「さきほど言ったレビュー会などが一定の防波堤になっていると思っていて、あまりにも疑問符がつくものは、そこで開発が止まることが時々あります。簡単に言うと、リリースブロックですね」。
ただし榎本氏は、これを仕組みとして誇るような言い方はしなかった。レビュー会は、すでに作った後の場だからである。「そこで止めているのは、シフトレフトの観点ではめちゃくちゃ遅いんです。最後の最後なので、そこで止めるのは本当は良くない」。止まった実績があること自体は、うまくいっている証拠ではない。そこまで来てしまった時点で、すでに手遅れに近いという見方だ。
「そこだとさすがに不幸なので」と、榎本氏が続けて挙げたのがプロダクトマネージャー同士の仕様相談会である。毎週1時間、長いときは2時間ほど。不確実性の高い論点は、作る前にプロダクトマネージャーが持ち込んで相談する。止める位置を、できるだけ手前へずらすための場だ。
「作らない」は、個人が我慢して達成しているのではない。迷いを作る前に持ち込める場と、作ったものが週に2回は必ず他人の目に晒される頻度が、その判断を支えている。
目標に「リリースします」と書かせない
とはいえ、組織には別の引力も働く。目の前の受注を取るための機能追加は、売上KPIに寄与してしまう。誘惑にどう対抗するのかという質問に対し、榎本氏の答えは制度の設計だった。「うちのプロダクトマネージャーは、責務やKPIとして数字を直接は持っていません」。理由は「数字だけ考えると絶対に意思決定が歪む」から。
では、作らない意思決定を評価できる制度はどう作るのか。この質問には、会場にいたVPoPの飯沼広基（numashi）氏が飛び入りで答えた。
「目標設定はしっかりした方がよいと思っていて、そこに『こういう機能をリリースします』と入れるのは、絶対にやってはいけないと思います」（飯沼氏）
理由は、それがタスクになるからである。「それはただのアウトプットであって、プロダクトの価値が増えたかどうかが見えませんし、途中で撤退もしづらくなると思うんですよね」。リリースを目標に書いた瞬間、途中でやめる判断が自分の評価を削る行為になってしまう。良い意思決定を妨げるツールとして評価制度が働き始める。
代わりに何を書かせるのか。飯沼氏は西井氏の目標設定を例に挙げた。バクラクビジネスカードをより大きな顧客に届けるうえで障害になっている機能を解消し、顧客に提案できるようにする。そこまでを目標に書いてもらっているという。目標を「アウトプットの完了」ではなく「届いた先の状態」で記述させる、ということである。
「人事評価というのは基本的に、出した価値に対して正当に評価されるべきツールの一つかなと思っています」（飯沼氏）
作らないことは、禁欲ではなく設計である
こうして並べると、この日に語られたことの構造が見えてくる。「機能を作るな」は、作り手に我慢を求めるスローガンではない。使われない機能が体験と開発速度とコストを蝕むという事実認識があり、それを見過ごさないための一次情報の取り方があり、迷いを作る前に持ち込める場と、それでも通ってしまったものが他人の目に晒される場があり、止める判断が評価で損をしない目標の書き方がある。どれも、個人の意志が続くことを前提にしていない。
そのうえで、榎本氏が手放さなかったものがある。使われるかどうかを事前にシミュレートできるのか、という質問への回答だ。
「大事なのは思考放棄しないことだと思っています。出す前に、自分が100点だと思えるまで考え続けましたか？ そういうスタンスを持ちましょう、という話ですね」
AIによって、思考を飛ばして形にすることが誰にでもできるようになった。だからこそ、飛ばさなかったかどうかが差になる。持ち帰れる問いは3つだろう。
「その機能は、使われなかったときに誰が損をするのか」「その設定は、顧客に判断を丸投げしていないか」、そして「自分のチームには、作る前に迷いを持ち込める場と、止めても評価が下がらない目標の書き方があるか」。
なお、LayerXは9月3日に自社カンファレンス「Bet AI Day 2026」を開催する。キャッチコピーは「AIエージェントと働く未来に、Betしよう。」で、オンラインでも参加できる（参加申し込みぺージ）。
