プロダクト開発における“難しさ”をモデル化してみよう　「意思決定」と「可観測性」の視点から考える、UGC特有の課題

登壇者の自己紹介

rokuroku氏：それでは「UGCプラットフォームの難しさをモデル化する」ということで、私、rokurokuが発表いたします。

最初に自己紹介をしたいのですが、私はrokurokuといいまして、今はpixiv事業本部の小説マンガ百科部という、長い名前のところでテックリードをやっています。

もともとは、アプリ開発やバックエンド設計、あとはデータ分析みたいなことをやっていたのですが、最近はプロダクトマネジメント周りの仕事をしていて、今日はそうした話をできればなと思います。

プロダクト全体のことを考えようと思うと途端に雲をつかむような話になってくる

突然ですが、みなさん、プロダクト開発って難しくないですか？　プロダクトの特定の一部の話だったらまだわかりますが、プロダクト全体のことを考えようと思うと、途端に漠然としてきて雲をつかむような話になってくると思います。今日は、そういう感じの話をしていきたいなと思います。

（スライドを示して）これは、「PIXIV MEETUP」のLPに掲載していた発表概要ですが、だいたいこんな感じの話をするので、ここだけちょっと話したいです。

日々サービス開発やコミュニティ運営をしていると、いろいろな困難に直面しますよね。そうしたことに対して今回は、意思決定や可観測性みたいなキーワードを軸に、この難しさをモデル化していきたいなと思います。最後に、プロダクト全体をモデル化すると、こういう視点も得られるよねみたいな話ができればなと思います。

発表のアウトラインですが、最初に意思決定や可観測性みたいな話をします。その後、プロダクトをモデル化すると、みたいな話をして、最後にちょっとだけ具体例を話します。

プロダクト開発＝夢を具体的な手段で現実にしていくこと

というわけで、意思決定の話をしていきます。

意思決定と言っても、たぶん人によっていろいろなものを思い浮かべると思います。施策をやるのか、やらないのかみたいな可否であったり、ユーザーサポートをどういう方針でやります、という話であったり、あとは機能実装。この機能を実装するのにどういう技術を選択します、とか、そういったことそれぞれが意思決定だと思います。

そういう具体的な意思決定の話は、今日は何もしません。もっと抽象的な「プロダクトにおいて意思決定っていったい何？」みたいな話をしていきたいと思います。

意思決定の話をする前に、意思の話をしたいと思います。「なんの話？」という感じですが「意思を決定している」ということは、決定されるなんらかの意思があるであろうということですね。

プロダクトの意思は、いろいろあると思います。例えば収益を増やしたいとか、ユーザーを増やしたいとか、機能改善してもっとプロダクトを良くしたいとか、そういう当たり前のものが基本的には根っこにあるはずです。

ただ、今言ったようなことって、かなり夢に近いですよね。なんの制約も考えていないし、「こうなったらいいな」でしかないと思うんですよ。ただ、プロダクト開発というのは、そうではいけない。つまり夢を具体的な手段で現実にしていくことが、プロダクト開発なのかなと思います。

意思決定とは抽象的な部分をどんどん具体的に決めていくこと

というわけで、「意思を実現することがプロダクト開発」だと思って、ここから考えていきます。

この具体的な手段というのは、先ほど言っていたように、企画の実施であったり、機能の追加であったり、改修であったり、あとはユーザーサポートの向上であったり、いろいろ手段があるかなと思います。

いろいろ手段があるのですが、ちょっとこの先、話を進めるにあたって、1度、機能のことだけをちょっと考えていきたいなと思います。ここを考えるとちょっと話の筋が良くなるのでこれを選んでいるというだけですね。

機能と言うと、みなさん引きずられて、仕様みたいなことを思い浮かべるかもしれません。機能開発するにあたっては、けっこうわかりやすい概念の1つかなと思います。

「仕様って何だろう？」と考えると、やはりこれは、少なくとも夢ではないですし、現実の制約もクリアしているでしょう。それにきっと、解釈の余地というものが、実現する上でかなり小さく最小限になっているはずです。

「意思決定って、じゃあ何かな？」というと、先ほど、ふんわりとした意思がありますよねという話がありました。これを、少なくとも仕様に落とし込めば機能開発につながるはずです。

なので、こういう意思を実現するために仕様を決めていく行為であったり、プロダクトに反映可能な状態に落とし込んでいくこと、整合性を取ったり拘束条件みたいなのを考えること。こういうのが意思決定なのではないかと考えられます。

（スライドを示して）つまりこんな感じですね。意思というのはかなり抽象的な部分なので、抽象的なままだとプロダクトにどうやっても反映できません。なので、具体的な部分をどんどん増やしてあげないといけないんですね。

この過程で拘束、制約をけっこう課したり、不純物も入ってくるのですが、これを繰り返していくと、どんどん抽象的でよくわからない部分が減っていって、最終的には、具体的な仕様であったりソフトウェアであったりが出来上がるはずです。

今言ったように、抽象的な部分をどんどん具体的に決めていくことが意思決定です。実施する、しないもそうですし、AにするかBにするかもそうですし、Cをやらないというのも全部意思決定です。

今、どんどん具体的にしていくと仕様になりますよねという話をしましたが、結局同じようなことは、企画やユーザーサポートにも言えます。何をやる、やらないを決めていくと、ふんわりとした意思が、どんどん現実に近づいていくはずです。

意思決定の難しさその1　意思決定が“破壊的な行為”であること

じゃあ、この、ただ決めるだけの意思決定の何が難しいんだろうという話ですね。組織構造の話もあると思いますが、今日はそういう話はせずに、もうちょっと意思決定そのものを見ていきたいと思います。

先ほど、抽象的なものを具体的にすると、仕様であったりソフトウェアであったりに近づくよねという話をしましたが、具体的にする時に絶対に失われるものがあるんですね。抽象的なものなので、（スライドを示して）ここにはいろいろなものが入っています。

例えば、情報伝達のロスみたいなのもここに入ってくると思いますが、そうではなくて、実現不可能、そもそも抽象的な意思で持っていたふんわりとしたイメージでは実現できない部分もここには含まれています。

これは具体的にしていくにつれて、「あっ、これは無理だったんだね」といってどんどん失われていきます。失われるだけならいいのですが、もともとの意思の中にあった本質的な部分が削れてしまう可能性があるんですね。

つまり、もともと思い描いていた意思が夢物語であった、あるいは、この意思決定の過程のどこかでなにかを間違えてしまった、ということが起きるので、意思決定は難しいですよね。

意思決定の難しさその2　“今の意思”は過去の意思の積み重ねで生まれること

もう1つ難しいところがあって、意思って、急にそのへんから湧いてくるものではなくて、過去の積み重ねの上に今の意思があるはずです。

人間ならもちろん自分の記憶があるので、自分の意思を見失うことはほとんどないとは思いますが、プロダクト開発の場合、けっこう入れ代わり立ち代わり、いろんな人がこの意思の代弁者になったりするので、過去の意思がきちんと伝わっていないと、今の意思というものが見失われます。

そうなると何が起きるかというと、意思が統一できず、コミュニケーションが破綻します。このコミュニケーションというのは、会社の内部の話もそうですし、外の話もそうです。

意思決定を言語化して残しておくことが大事

こうした難しさをどちらも解決するうまい手段はありません。とはいえ、意思決定を残していけば、少なくともどちらも緩和はされるだろうということですね。

意思決定を残す。ドキュメントに残すなどしないと、もちろん後世に伝わらないのはそうですし、言語化することで、より何を決めたのかが明確になります。

あと、もう1つ重要なこと。意思決定って「その時」というかなり強い環境要因を持って生まれるものなんですね。なので、結論だけ書くだけでは、なぜその結論になったのかが伝わらないです。そういうのを意識的に残さないといけません。なので、意思決定はどんどん残しておくとよいのでは、という話です。

意思決定の話のまとめとしては、意思という、ふんわりとしたものを実現していくことが意思決定で、そうした意思決定を残すことはすごく大事なことだよねという話を、1個目ではしました。

プロダクト開発に重要な「可観測性」とは？

次ですね、可観測性。Observabilityとも呼ばれていますが、この話をします。

けっこう聞き慣れていないという方もいるかもしれませんが、意味としては字面のとおり、観測できる性質です。

もともとこれは、制御工学という分野の言葉だったのですが、最近は、なじみのあるソフトウェア開発にも取り入れられる概念になってきています。

どういう意味かというと、おおむね観測値から必要な内部状態がわかること。もっと簡単に言うと、対象、つまりここでいうとプロダクトのことを熟知していて、かつ、きちんとそういう観測ができる設計になっているということですね。

これ、何が重要なのかというと、可観測性がないということが何を意味するかということですね。

できないというのはだいたい2つです。1つが、プロダクトの構造を理解できていない。もう1つが、必要な情報が取れない設計になっている。この2つのどっちであれば、可観測性がないということになります。

そうした状況だと何が起きるかというと、正しい自己評価、価値のある開発、意味のある予測が全部困難になります。「これは本当に合っているの？」という状態ですね。

なので、この可観測性を確保することがかなり重要です。「じゃあ、どうすればいいの？」というと、あまり意味のある回答にはならないのですが、先ほどの裏返しで、プロダクトの構造を理解している状態、必要なセンサー、観測できるなにかを設置していて観測している状態。これを維持できる体制が必要になります。

価値の本質がユーザー側にあるUGCでは観測が難しい

「それって、普通にプロダクトのことを考えればいいんじゃない？」という話なのですが、実はここにはUGC特有の難しさが絡んできます。UGCだと何が難しいのかという話ですね。

たぶんみなさんご存じだとは思いますが、UGCはユーザー生成コンテンツのことです。サービス自らがコンテンツを提供しているのではなく、そこに来ているユーザーがコンテンツを投稿して、それがユーザーに提供される。そういうサービス、あるいはそのコンテンツのことです。

「pixiv」もこうしたUGCを取り扱うサービスの1つで、わりと「The UGC」みたいなサービスだと思っています。

普通の商品だと、価値というものはプロダクトの中に含まれています。これだとけっこう観測が容易ですね。どういう価値があるのかを自分たちで設計して提供しているので、それらのことはよく知っているはずです。

一方で、UGCサービスだと、提供する価値がUGCそのものになります。つまり、このUGCというのは、ユーザーが作るものなので、ユーザーの世界側に価値の本質があるわけですね。つまり、外側にあるので、かなり観測が難しいという話になります。

外側にある難しさというと、結局ユーザーが何を作るのかもわからないし、ユーザーが何を価値に感じているかもけっこう曖昧です。

さらにこの2つは、ユーザー同士の相互作用によってかなり動きます。つまりユーザーがなにかを作って、その作ったものに対してコミュニティが価値を見いだして、こういうのに価値があるんだと思って、その価値をどんどん育んでいく、そういう世界観なんですね。なので、ここを完全に制御することはぜんぜんできないし、そもそも何をもって観測とするのかすら難しいところです。

リリースを継続的に行い、ユーザーからのアクションを観測する

というわけで「じゃあ、そういう状態でどういうふうに観測体制を構築するの？」という話です。基本的には、ユーザーとコミュニケーションをするしかないです。コミュニケーションをするとはなにかというと、ユーザーにアクションをして、そのアクションが返ってくるということですね。

何もしていない状態って基本的にずっと同じ状態です。つまりずっと同じ情報しか得られない、新しい情報が増えないんですよね。

物で言うと、物は置いてあるだけだと結局重いのか軽いのかもわからないし、硬いのか柔らかいのかもわかりません。ただ、持ってみるとわかりますよね、みたいな話です。

「具体的に、じゃあどうしようか？」というと、リリースサイクルを回しましょうという話になります。

適切なリリースを継続的に行うのがやはり良くて、リリースって基本的にプロダクトを良くしますし、リリースによってやはりユーザーからの反応が返ってくるので、きちんとユーザーの理解も深まります。

というわけで可観測性というのは、プロダクトの構造を理解した上できちんと観測できるようにすることです。ユーザーに適切なリリースを届けることは効果的です、みたいな話をしました。

意思決定と可観測性をモデル化

最後にモデル化の話ですね。モデル化はなにかというと「対象の主な要素を中心に、構造を整理して、複雑なものを理解・把握できるようにするものです」と書いてあります。

今回、1個目に意思決定というものの話をしました。これはなにかというと、意思みたいな高い抽象度のものを抽象度の低いところに落とし込んでいって、ソフトウェアだったりにしましょうという話です。

もう1つした話が可観測性ですね。可観測性をきちんと確保して、そのサービスのユーザーのことをきちんと理解していきましょうという話ですね。

この2つを軸に、今回「プロダクト全体はこんなものなのでは？」みたいなものを考えてきました。

意思の具体化のステップみたいなものを縦に並べて、「その縦に並べたステップに応じてユーザーの側には何があるんだっけ？」という図です。

具体的にどんどん次にいっちゃうのですが、プロダクト側って、先ほど言ったように、抽象度の高い意思のようなものの抽象度をどんどん下げていって、コンセプトだったり要件だったりソフトウェアだったりに落とし込んでいきます。

ユーザーの側にも抽象度みたいな概念があると思っていて、ソフトウェアだと、アクセスに対してなにかレスポンスを返すみたいなレベルなので、アクセス単位の話になります。

それが集積されるとユーザー単位の話になって、さらにいくとコミュニティの話になって、もっといくと世界全体みたいな話になります。これを全部合わせて考えると、こんな図ができるかなと思います。

今回の発表、わりとこの図を出すために長々と話してきていて、この図を考えたかった理由として何があるかというと、そもそもプロダクト開発って、ユーザーサポートだったり実装であったり、ユーザーの行動の把握であったり、いろいろなことがあります。

ただ、それってもともとはプロダクト開発という1つのことの話なのに、わりとバラバラに見えてしまっていて、どこがどうつながっているのかがわからないという悩みがあって、それを解消するためにこういったことを考えていました。

これはどういう図かというと、上のほうに抽象度が高い状態があって、そこってやはり、なにを基に意思が生まれてくるかっていうこと、世界がどうなっているか、今何が求められているかみたいなのがありますと。

その下のコンセプトだと「コミュニティに対してどういうものを提供すると刺さるんだっけ？」みたいなところですね。もっと、ユーザー単位になってくると、「ユーザーサポートやユーザー体験ってどうあるべきなんだっけ？」みたいなそういう話です。

こういうふうに可観測性、ユーザーの世界をどう観測するかというところを、今言ったような層ごとに考えてみると、コミュニティの部分であったらユーザー反応を見るでしょうし、ユーザーサポートであったら解決までの時間とかを見るのかなと思います。ソフトウェアだと、Four Keysとかが役に立ちそうです。

というわけで、モデル化という話で、意思決定や観測を軸にプロダクトを俯瞰してみたよという話が今の話でした。

各作品種別ごとのチームでユーザーコミュニティを見ている

最後にちょっとだけ具体例を話します。今、pixivという開発組織にあるチームについて話をしていきたいなと思います。

今までの話、人がぜんぜん出てこなかったかなと思うんですが、けっこう意識的に人を省いていました。というのも、やはり人をどう配置するかって会社組織にとってのプロダクトへの最大の入力で、それをいかに正しく配置するかによって、プロダクトの結果を最大化できるかというところが重要だと思うんですね。なので、いろいろなチーム体制が考えられると思います。

今回話すのは、pixivのユーザーコミュニティを少しだけ分割して見ているよ、という話です。

pixiv全体のコミュニティを一遍に見ることもできるのですが、pixivには小説、マンガ、イラストみたいに作品の種別があるので、それごとにけっこうコミュニティが分かれていたりします。今、pixivには、小説チーム、マンガチーム、イラストチームがあります。

先ほどのモデルでいうと、（スライドを示して）ここの部分ですね。ここの部分を見るチームというかたちです。ここ、pixiv全体を見ているとけっこう大変だったりもするのですが、イラスト単体、マンガ単体、小説単体と考えると、わりと意思決定とか観測とかリリースとかのサイクルが回しやすくなってとても良いのでは、みたいなのがあります。