「設定を作るのは、判断をお客さまに丸投げすること」
一部の顧客や業種しか使わない機能を作ること自体を、榎本氏は否定しない。問題にするのは置き場所である。重視すべきは「欲しい人が欲しくなった時に気づく場所に置く」動線設計であり、その逆をいくのが、設定をオンにするまで機能を隠す方式だ。
「適当な場所に置いたら、数パーセント未満の人にしか使われない。それが設定だと思うので」
気づく人がほとんどいない機能は、存在しないのとほぼ同じである。加えて、設定は作った瞬間から負債を生む。設定するかしないかという分岐がユーザーに生まれ、開発側にはオンオフの組み合わせ分だけ動作確認が積み上がり、サポートには案内のコストがのしかかる。
「設定を作るというのは、ある意味、判断をお客さまに丸投げしていることだ。それを自覚しながら設定を作りましょう」
事業上どうしても必要な設定はある、とも榎本氏は補足する。ただし順序があり、まずはより上位の抽象化によって設定そのものを不要にできないかを探し、それでも駄目なときの最終手段として設定を選ぶ。
この「まず線を引き直す」姿勢は、パネルトークでも別の角度から語られた。
バクラク事業部でペイメント企画チームのプロダクトマネージャーを務める西井大翔（taisho）氏は、前職で7年ほど霞が関に勤めた経歴を持つ。法対応が絡む要件では「法律をまず読む。そして、どこまでやらなければいけないかをまず明確にする」ところから入り、実際に業務を体験したうえで、どこまで機能として実装するかを判断する。例えば、記録の保管要件であれば画面まで作る必要はない。榎本氏も「法律が現場の運用のことを考えていることなんて、ほとんどないと思っていて」と述べ、単純に法律に完全に沿わせることが従業員の幸せに直結するとは限らないと指摘した。
AIは増幅器である
ここまでは、AIがなくても成り立つ議論である。榎本氏がこのタイミングで資料を書いたのは、AIがこの構造を悪化させると見ているからだ。
「アウトプットって楽しいんですよね。僕もそもそもコードを書くのが大好きでしたし、AIに作らせて機能ができたら嬉しい。やった気になる」。作れる人の範囲が広がり、作れる速度が上がった結果、「みんなアウトプットの誘惑に弱くなっているんですよ。誘惑がすごく強くなっている時代」だという。
その具体的な姿として榎本氏が挙げたのが、次の光景だ。
「AIと壁打ちして、AIに作らせて、ちょっとチームで触って、『なんかよさそうじゃない？』でリリース。本当にやめましょう」
しかも法人向けプロダクトでは、一度出した機能を簡単には落とせない。過去にバクラクで大きめの機能を廃止した際は、丁寧な移行プランを作って張り付きで案内する必要があったという。落とせないからこそ、作る前の検討に時間を使うべきだという理屈になる。
AIそのものについて、榎本氏は明快な比喩を置いた。
「AIって増幅器なんですよね。その人の能力を増幅しますし、その人の間違いも増幅するので」
増幅された間違いは、誰かが間違い探しとして引き受けることになる。そして自身の実感として、依存が進んだときに何が起きるかも率直に明かした。自分でよく理解していないコードをAIに書かせ、AIにレビューさせ、通ったからマージする。「一度こういう楽をしてしまうと、もう中毒になってしまうんですよね」。その状態では周辺のバグ修正まで自力で判断できなくなり、簡単な修正でも当たりが付かないため、「いつの間にか、やはり動作確認マンになるんですよね」。速いはずが、かえって時間を取られる。
だから榎本氏は、自分の中に一線を引いている。DB設計やAPIのインターフェースといった、後戻りのコストが高い根幹部分は必ず人間が判断する。
もう一つ、AI時代に失われやすいものとして挙げられたのが、コードを書きながら気づけたはずの論点だ。デフォルトの並び順やフィルターといった細部は、手を動かす過程で自然に浮上する。それをAIにたたき台ごと作らせてしまうと、検討の機会そのものが消える。
「ビジネスでは、たたき台の持つ引力がとても強力です。普段仕事をする中で分かると思うんですけど、『たたきを作る人が一番偉い』という言葉にある通り、人間は絶対にたたき台に引きずられるので」
榎本氏が繰り返したキーワードは「早いだけじゃないか」である。機能を早く作れたと思っても、それが一瞬の速さなのか、継続的な速さになっているのかは別問題だ。
「本当にそれ、いるの？」から始める
では、作らない判断を支える実務はどうなっているのか。西井氏が挙げたのは、課題と手段の切り分けである。
「要望とは、お客さまが抱えているニーズや課題だと思うんですけど、その課題と手段は切り分けて考えた方がいいと思っています。手段が要望として上がってくるケースが多いと思いますが、それを鵜呑みにするのではなく、要望の裏の背景や実現したいことを深掘りするのが重要です」（西井氏）
課題の奥にある本当に実現したいことまで掘り、そのうえで解決の手段について複数の案を考える。解像度を上げるには、顧客の業務をフローチャート図に書き起こし、可能な限り自分で体験することだ。
バクラク事業部でエンジニアリングマネージャーを務める伊林義博（chan）氏は、エンジニアの側からも問い直すと語る。その機能が本当に必要か、別のプロダクトで解いたほうがよいのではないかというところまでプロダクトマネージャーに確認する。基準に置いているのは初見のユーザーだ。「お客さまはその画面を初めて見るパターンが多いと思っていて、では、初めて見たお客さまにとってこの画面は正しいものなのか」。営業やサポートの商談動画を週1本ほど見て業務理解を深めることも、社内では広く行われているという。
榎本氏は新規プロダクトを立ち上げるたび、社内のコーポレート担当者を隣に座らせ、自ら業務を体験する。ヒアリングでは「それ、本当にいるの？という感じで」疑ってかかり、要望の温度感を4段階ほどで点数化してもらう。基準は「ないと死ぬのか」だ。そして最も重要だと語ったのが、視点の持ち方だった。
「二重人格であることが結構大事だと、いつも思っています。ドメインにとても詳しくなって、その業務の専門家だと言いたくなるくらいの解像度を持ちながら、そのプロダクトを作る前のまっさらな自分、何も知らない自分と、両方の視点を持たないといけない」（榎本氏）
AIのコンテキストを時々クリアするのと同じように、立ち返って見つめ直す。それが複雑化への歯止めになる。その先にある到達点は、機能の削減よりも遠い。
「一番のムーンショット、やりたいこととしては、業務そのものをなくすところまで本当はいきたい」（榎本氏）
ただし、ここまではすべて個人の心構えである。そして榎本氏はこの日、自分が「作らない」と決めた機能がその後どうなったかを、自ら明かした。
