「ユーザーの数だけプロダクトが複雑になるのはおかしい」 人とAIエージェントが“道具”を組み合わせて使うアーキテクチャとは？

大規模プロダクトに関わったことのあるエンジニアの中には、ユーザーの要望に応えるたびに機能が増え、UIが複雑になった経験のある人は多いのではないでしょうか。しだいに、初期のシンプルさが失われてしまったという苦い思いがある方もいるかもしれません。

ユーザーが増えてもシンプルな構造が維持できれば…そう思っている方もいるはずです。

Wevoxは「エンゲージメントサーベイのSaaSでしょ？」と言われることが多いです。しかしそれを「測って終わり」にしないために、様々な組織活動を支えられるプロダクトに進化しています。組織活動は組織の数だけ存在するという前提のもと、ユーザーが自社の組織活動に合わせて、Wevoxのサービスを組み合わせられるプロダクトアーキテクチャを採用しています。

今回は、Wevoxをつくりながら考えてきた「様々なユースケースに耐えうるプロダクト」という思想を起点に、増え続けるユーザーの要望を取り込んでいけるプロダクト設計について書いてみたいと思います。

機能を増やすほどプロダクトはブレる。プロダクトのジレンマ

プロダクトをつくっていると、社内のあちこちからユーザーの課題を解決したいという声をもらいます。これは本当に嬉しいことです。ユーザーに真剣に向き合い、能動的に問題を解決しようとするメンバーが多い証でもあります。

だからこそCSやサポートチームの声をうまくプロダクトに取り入れたいのですが、そこには構造的なジレンマがあります。一般的に、解決したい課題が増えれば増えるほど、プロダクトは複雑になります。いただいた声を整理して取捨選択しなければ、もともと考えていたプロダクトの思想からどんどんブレてしまいます。

これが本当に怖いんです。

我々のチームでは、「シンプルかイージーか」という話がよく挙がります。イージーとは、難しいことを簡単にすることです。例えばデジカメを思い浮かべてください。レンズの仕組みや露出といったカメラの技術が分からなくても、オートフォーカスでボタンを押せばきれいな写真が撮れます。これはデジカメが「写真撮影という難しい行為を簡単にした」ということになります。

ところがそこに動画機能を乗せ、パノラマもフィルターもWi-Fi連携も…と1台でいろんな課題が解決できるように機能を詰め込むと、プロダクトはどんどん複雑になってしまいます。

僕たちもこの罠にはまりました。

当初Wevoxは、エンゲージメントサーベイをイージーにすることに振り切っていました。これは難しいカメラでの撮影をイージーにした話に近かったので、比較的やりやすかった。ところがいくらサーベイが簡単に取れるようになっても、組織が変化するわけではありませんでした。そこで、組織で行われている「行為」に着目するようになりました。1on1、振り返り、目標設定、従業員の健康課題…。気づけば、プロダクトは複雑になろうとしていました。

2年くらい前に、Core toolsの設計や思想をリードしているまるちゃんとせいやとこんな話をしたことがあります。

これは、Rippling社CEOのParker Conrad氏のインタビューを見て、彼が同じような領域で3回連続起業していると知り、もし僕が同じ領域で起業するとしたら？ と思考した結果出てきた考えです。

解決したい課題が増えることと、機能が増えることは、似ているようで違います。解決したい問題が増えれば増えるほど、プロダクトが複雑になる構造はおかしいと思ったのです。

Wevoxが採用している、コンポーザブルなプロダクトアーキテクチャとは何か

ここで、Wevoxのアーキテクチャについて説明します。

Wevoxは、企業ごとに異なる組織課題に合わせて自由に組み合わせて使えるよう、コンポーザブルなアーキテクチャを採用しています。また実装としては、モジュラモノリスを基本としつつ、独立性の高い機能だけをマイクロサービスに切り出すハイブリッド構成です。

具体的には、ドメイン（Engagement, Culture etc.）とツール（Board, Forms, Docs, Chat, Dashboard）を別レイヤーに分離しています。

多くのSaaSツールは"ドメインとツールが1対1で密結合"（例：エンゲージメントサーベイ製品＝サーベイ機能＋エンゲージメントデータ、が一体）しているのに対し、Wevoxは汎用ツール層を独立させ、その上にドメインプロダクトを構成できるようにしています。

これにより、Formsでデータを取り → Analyticsで分析し → その結果をWevox Boardに貼る、といったワークフロー的な組み替えが可能になります。

下から順に、Data層、Admin層、ビューをベースにしたProducts層、そしてその上にAI Products層、Intelligent層と名づけました。Products層の中には、ツール層である「Core tools」が置かれています。

この5層は、近年SaaSでよく使われる「System of 〜」という整理に重ねると、それぞれの役割がはっきりします（参照：https://optif.ai/media/ja/articles/system-of-record-vs-system-of-action/ ）。

最下層のData層は、組織やメンバーのデータが蓄積される「System of Record」です。その上のAdmin層は、プランや権限といった全体の土台を担います。Core toolsを含むProducts層は、人が実際に触れて作業する「System of Engagement（ユーザーと関係性を深めるシステム）」。さらにAI Products層(AnalyticsやPeople Signal)は、蓄積されたデータから示唆を引き出す「System of Intelligence」にあたります。

そして最上段のIntelligent層が「System of Action(行動のシステム)」です。ここには「Analytics Coach」「Facilitation Coach」「Career Coach」といった、組織づくりの特定テーマでユーザーを支援するAIエージェントが並びます。

同じ単語がつづくので整理すると、System of IntelligenceはSoRのデータを分析しユーザーに「わかる（示唆）」を提供する層です。一方、Intelligent層はその示唆を実際の「行動」に変え、AIによって自律的に業務を実行する層です。

AIエージェントが、その下にあるCore toolsを"道具"として使いこなし、ユーザーの代わりに分析したり、レポートにまとめたり、次の一手を提案したりと業務を遂行します。データが「記録 → 示唆 → 行動」へとつながっていく構造です。

Core toolsをあえて独立したツール層として切り出した理由も、ここに効いてきます。人間だけでなくAIエージェントも同じ道具を使えるようにしておけば、Intelligent層は新しいCore toolが増えるたびに、それをそのまま自分の道具として取り込めます。レイヤーを分けたこと自体が、AIエージェントの拡張性に直結しているんです。

このうち、Wevoxの設計において最も特徴的なのは「Core tools」と呼ばれるツール層の位置づけです。

▲Core toolsの開発を担当したエンジニア、まるちゃんとせいやのテックブログです

少し前、コンパウンドプロダクトの文脈で、ツール層を強くするべきだという論調が盛り上がりました。ツール層とは一般的に、認証・認可や決済システムなど、プロダクト運営上共通して必要なシステムのことです（以後、「共通アプリケーション基盤」）。

ところがWevoxの場合、ツール層にシステムだけでなくユーザーが直接触れるインターフェースを置くことにしました。つまり共通アプリケーション基盤の中に、UIを持ったツール群が並列して存在している、という構造です。
具体的には、自社に合わせたサーベイを自在につくれる Forms、書く行為に最適化された ドキュメント機能、仲間と対話し思考を広げ深めるWevox Boardなどです。これらのツールはそれぞれ単独でも使えるし、組み合わせて使うことも可能です。

このように各ツールが独立したインターフェースを持ちながら、共通アプリケーション基盤の上に並列で存在しています。よって、新しいツールを追加しても既存のツールに影響を与えません。ユーザー側も、使うツールを選んで組み合わせるだけで、自分の課題に合ったプロダクト体験を作れます。Wevoxという1つのプロダクトの中に用途の違う複数の道具が並んでいて、自分の課題に応じて自由に組み合わせて使えるかたちです。

「機能を足す」ではなく「組み合わせ方をユーザーに委ねる」

ユーザーが触れるインターフェースまで含めて、モジューラブルで疎結合になっているプロダクトは、それほど多くありません。企業ごとに業務プロセスは異なり、各社のプロセスに応じてユーザーがプロダクトを自由にデザインできる設計になっているからです。

僕が大切にしている考え方として、「サービス」と「ツール」があります。
世の中のソフトウェアを大きく2つに分けるとしたら、ほとんどはサービスです。サービスは、ある業務プロセスの工程に沿って設計されていて、その工程は始まりから終わりまでだいたいいつも同じです。

一方、ツールは道具です。おたま、フライ返し、包丁とそれぞれ1つの道具でも「すくう、ひっくり返す、切る」という課題（ジョブ）を解決できますが、それらを組み合わせればもっと大きな課題を解決できるようになります。しかもユーザーは、これらの道具をどう使ってもいい。

技術的に言えば、これがコンポーザブルなプロダクトアーキテクチャということになります。

エンジニアの世界では、部品を自由に組み合わせて使えるようにするという発想が昔からあります。これらはモジュラー設計や疎結合と呼ばれ、お互いが干渉せず、より柔軟性を保つために考えられたアーキテクチャです。

近年ではこれらを総称してコンポーザブル・アーキテクチャと呼んでいたりします。

なぜこのような構造を採用したのか。理由はシンプルで、「企業ごとに全く違う組織づくりを支えるプロダクトアーキテクチャ」でありたかったからです。企業ごとに1on1のやり方も、振り返りで使用しているフレームワークも全く違います。みなさんも感じている通り、組織とは複雑で1つとして同じ課題はありません。

（同様の発想は、Notionの『ブロック』、Figmaの『コンポーネント』、Google Workspaceのツール間連携にも見られます。違いがあるとすれば、Wevoxは"組織のためのドメインデータ"を扱うプロダクトでこれを実現している点です。）

ということは、開発側が課題ごとに機能をつくり続けるという発想自体が、無理なのではないか。そこで、「組み合わせ方をユーザーに委ねる」という発想に転換しようと決めました。

ユーザーの数だけ課題はあって当たり前。これからのプロダクト設計の考え方

組織開発の領域でプロダクトを提供する僕たちが向き合っているのは、「1つとして同じ組織はない」ということです。

100のチームがあれば、その数だけ課題があります。これを「全て違うから一般化できない」と諦めるのか、「既存のフレームワークで無理やり一般化する」のか。あるいは「ユーザー自身がやりたいように自由に解決できるプロダクトをつくる」のか。

僕らが進もうとしているのは、第3の道です。

もともとWevoxは「自走する組織をつくりたい」と生まれたプロダクトです。まず人の内側から「私はこういうことをやりたい」「こういう課題に取り組みたい」という想いが立ち上がる。そのとき、プロダクト側に「最低限の道具」が揃っていれば、ユーザー自身が道具を組み合わせて自分の課題を解いていけます。

文化人類学者 レヴィ＝ストロースによる概念に「ブリコラージュ」という考え方があります。これは「ありあわせの道具、材料を用いて自分の手でモノをつくる」という考え方です（※）。

※引用 「ブリコラージュで実現する、「対話」と「受動的な創造性」に満ちた組織──文化人類学の知を組織づくりに活かす方法」（CULTIBASE）

IKEAの家具がなぜ多くの人に愛されるのか。その1つの理由として、自分で組み立てるプロセスが愛着を生むからだとも言われます。そんなふうに、人はある種のクラフトマンシップを持っていて、自分でプロダクトを組み立てながら使ってもらえば、よりWevoxのことを愛してもらえるのではないかと思っています。

ユーザーが10倍になれば要望は100倍になる、その100倍に機能で応えようとすると、プロダクトに限界がきます。これからのプロダクト設計に必要なのは、「ユーザーの数だけ課題があって当たり前」という前提を、構造ごと受け止められるアーキテクチャだと考えています。