「機能を作ることはマイナスである」
この一文を書いたのは、LayerX執行役員でバクラク事業のCPOを務める榎本悠介（mosa）氏である。バクラクは経費精算、請求書受取、法人カード、勤怠・工数管理など15のプロダクトを擁するバックオフィス向けAIエージェントサービスで、榎本氏はその立ち上げから関わってきた。うち7つほどは自身が立ち上げたという。
会計や経費精算といった、本人いわく「今更感のある領域ばかり」をあえて選んでいる理由は一つ。「圧倒的に使いやすい」ことをプロダクトのアイデンティティに置いているからだ。
「今さら僕らが作るのだったら、本当にいいものを作るぞという気概で、バクラクというプロダクトを立ち上げから作っています」
その榎本氏が、6月に公開した社内資料「機能を作るな。楽して作るな。」の核心として置いたのが、冒頭の断言である。機能を作ることはプラスでもゼロでもなくマイナスだ、という主張だ。根拠は明快で、機能は使われて初めてアウトカムになるからである。使われなければ、残るのはコストだけになる。
「エンジニアとしてどんなにきれいにDB設計をして、どんなにきれいにコードを書いても、基本的には次の開発の邪魔になるんですよ」
技術的な完成度と、プロダクトが生む価値は別物だという指摘だ。使われない機能は、ユーザーにとって認知負荷でしかない一方、開発する側には将来にわたって負担を残す。動作確認の対象が増え、パフォーマンスを圧迫し、AIに渡すコンテキストとコストを食い続け、その挙動に責任を持つ人間を必要とし続ける。
この資料は、はてなブックマークで数多くのコメントを集め、本イベント「『機能を作るな。楽して作るな。』作れる時代に作らないを選択する等身大プロダクト開発Meetup」は、その反響から生まれた。
モデレーターを務めた柴山嶺（serima）氏は冒頭で、「内容が少しハイコンテキストな部分もあったかもしれません。公開資料だけが独り歩きしてしまうと、本来mosaが言いたかったことがうまく伝わらないかもしれないと思いまして」と企画の経緯を説明した。会場とオンライン配信を合わせ、約500名が申し込んだという。
体験が悪くなっても、使われ続けてしまう
なぜ、あえて「マイナス」とまで言い切る必要があるのか。榎本氏が挙げたのは、法人向けプロダクト特有の構造だった。
顧客が増え、業種が広がるほど、機能追加の要望は積み上がる。それを素直に実装していくと、画面には使わない機能が並び、訳の分からないプロダクトになっていく。しかも厄介なのは、その先である。
「体験が悪化しても、お客さまが契約を打ち切るわけではない。そういう、使われ続けてしまう構造がtoBだと結構ありうるんですよね」
導入を決める人と、日々使う人が違う。業務そのものは会社に存在し続けるため、使い勝手が落ちても現場は使い続けるしかない。悪化のシグナルが解約という形で返ってこないのだ。だからこそ、作り手の側が自分で線を引くしかない。榎本氏は「その機能を使わないユーザーにとっては、存在自体が百害あって一利なし。むしろ作るなという話です」と述べる。
出発点は「自分が経費精算をできないから」
もっとも、この主張は抽象的な理念から出てきたものではない。榎本氏が繰り返し語ったのは、自分自身がユーザーだったという原体験である。
「僕自身、正直コーポレートサービスに課題を感じていたからバクラクを作った、という面があるんです」「経費精算を作った一番の理由は、自分が経費精算をできなかったからなんですね」
自腹を切り続けた経験が、バクラク経費精算や勤怠の着想の原点になっている。「従業員の業務をなるべく楽にしたい」という動機が先にあり、機能を減らすという判断はその手段にすぎない。
だから、作らない判断によってエンジニアの手が空くことを、榎本氏は問題視しない。「エンジニアを暇にさせることに罪悪感は覚えなくていい。そういう意思を込めています」。空いた時間は、正しいものを作るために使えばよい。実際、3か月ほどヒアリングと仕様検討を重ねた機能を「結局これは多分使われないな」と判断し、サンクコストを無視して止めたこともあるという。
では、作る／作らないの線はどこに引かれるのか。この日、榎本氏が機能そのもの以上に強く戒めたのは、実は「設定」だった。
