“ワンチーム”として共創し、良いプロダクト開発をするために　クライアントワークで必要な、3つの「共通」を作ること

クライアントワークをする時に作る必要のある3つの「共通」

小谷草志氏：では「各業界の専門家とSaaSを立上げていくためのリサーチと開発プロセス」ということで、初め（の発表）で緊張するんですが、お話ししたいと思います。

僕は株式会社エルボーズの代表をしている小谷と申します。弊社は「ATTEND biz」という伴走型のプロダクト開発チームを提供しています。

コンセプトは「明日から、あなたの開発チームに」です。この「明日から、あなたの開発チームに」を、ある種のクライアントワークとして行っているというところが、まずは1つの特徴になるのかなと思います。そのためにいくつか必要なことがあると考えています。

「明日から、あなたの開発チームに」というところで、いわゆる内部の人と外部の人というように切り分けられてしまうと（チームとして働くのは）難しくなっていくので、内部とか外部とかという考え方を捨てて、クライアントとワンチームとして共に創っていく必要があると思っています。

そのために、クライアントも含めて3つの「共通」を作る必要があると考えています。1つ目が初期のプロダクト構想。2つ目がユーザー像とユーザー課題。3つ目がプロジェクトの進み具合という、この3つかなと思っています。

初期のプロダクト構想

まず1つ目の初期のプロダクト構想というところを話せればと思います。これは事業会社で開発されている方々にとってすごく当然のように感じるかなと思うのですが、これをクライアントワークの中で行っていくことが、1つのハードルになっているなと思っています。

というのも、デジタルなプロダクトを開発する時に、ざっくり開発の工程を分けていくと、課題仮説とか調査の設定をして、課題に対して仮説を持って、その仮説を基にプロダクトを構想して、そのプロダクト構想に沿って開発をしていく。

小さく実装して小さくユーザーさんに使ってもらって、ユーザーさんからフィードバックをもらって、それを改善していくというサイクルがあるのかなと思っています。課題仮説を立てて、小さく作って、小さく提供して、PDCAを回す。これがリーンスタートアップのざっくりとしたかたちかなと思います。

ただ、開発業界の中でクライアントワークを行っていると、後工程のみを開発会社さんにお願いすることがけっこう多いと思います。後工程、いわゆるミニマルな開発の部分から入って改善（するための）開発が進んでいくこともあるし、もっと悪いと、いわゆる請負というかたちで開発のみをやることも、クライアントワークをしている開発会社さんの中では多いのかなと思います。

後工程のみとか、もっといえば開発部分のみというかたちで開発に入っていくと「ユーザーにとって結局なにが課題で、なにが必要なんだっけ？」ということに基づいたプロダクト開発がなかなかできないと思います。

そういう意味だと、できるだけ上流部分からしっかり入って開発する必要があると思っています。プロダクト構想の部分や仮説の部分からしっかり入って、一緒にディスカッションをしながら、プロダクトの方向性や構想を練っていく必要があるかなと思っています。

プロジェクトの進み具合

（スライドを示して）3つ目のうちの真ん中が、おそらく調査に関わるところでもあると思っているので、先に3つ目のプロジェクトの進み具合というところ（について話そうと思います）。

これも当然なことと言えば当然なことなんですが、弊社だと（クライアントの）SlackとかのコミュニケーションツールにPMやエンジニアさんも一緒に入らせもらって、常にコミュニケーションを取れる状態を作ったりしています。あとは、週1で必ず定例ミーティングを設定しています。

あとは、弊社はNotionを使った「プロジェクトキット」というもので、開発に関する情報や工程を共通で見ることができます。同じ場所、1ヶ所に（人や情報を）集約することによって、プロジェクトの進み具合をしっかり共有するようにしています。

ユーザー像とユーザー課題

（スライドを示して）2つ目のユーザー像とユーザー課題というところで、ここがリサーチに関わってくるところかなと思っています。

先ほどお話に出ていたように、弊社は非IT系の中小企業さんの新規事業というところに入ることが多くて、開発の内容としては、その業界のクライアントさんがやりたいと思っている、業界の中での課題解決みたいなこと……。ただ、彼らはデジタルのプロダクトの立ち上げ方とか開発の仕方がわからないので、弊社と一緒に開発をすることが多いです。

クライアントさんが持っているものとしては2つあります。1つは業界の知識で、もう1つは顧客基盤を基本的には持っていることが多いです。

業界における課題とか、そこに関するニーズみたいなところは、クライアントさん自身が当事者であることが多いので、そういった意味で業界（として）の課題を持っています。

だからこそプロダクト構想とか、彼らの感じている課題自体を丁寧にヒアリングしていくことが、業界の中のニーズやユーザー像をつかまえる上ですごく必要になってきているし、それによって解像度が上がっていくことがあるので、僕たちはここをファーストステップに置いていることが多いです。

そこにプラスアルファして、クライアントさんもまだ知らない1次情報とか、エンドと呼ばれる、実際に使われるユーザーさんの情報も得る必要がある。そのため、実際に弊社で実施したことがあるものとしては、初期（の頃）にクライアントさんにファーストステップとしてディスカッションを行い、それを行いながら、さらにエンドユーザーになり得る方にさまざまな方法でリサーチを行っています。

3つのリサーチ方法

その方法は大きく3つあります。1つ目は、プロトタイプを用いたインタビュー調査みたいなかたち。弊社では「Figma」とかを使ってデザインに起こした上で、その中でプロトタイピングをして、それを用いてユーザーさんにオンラインでインタビューを実施したりします。

あとは、業界の中で業務系のSaaSがあったりするので、現場の方々に、どういうふうに業務が進んでいるかの動画を撮影してもらって、その動画をクライアントさんと一緒に見ながら、「あぁ、こういうところを見ているんだね」とか「あぁ、こういうところがやりづらいんだな」とか「あぁ、ここは紙なんですね」みたいなことを共有して、「そうしたらこういう機能が必要なんじゃないか」みたいなことをディスカッションしていくことがけっこうあります。

あと一般的な（こと）といったら変ですが、本当にミニマム（なこと）でいうと、Googleフォームとかを使ってアンケートを作ってユーザーさんに聞いたり、それを分析した上で「じゃあ、どういうふうな機能が求められているんだろうか？」みたいなことをディスカッションしながら作っていくことをしています。

具体的な取り組み事例

具体的な事例として「こういうことをやりました」ということを共有するとわかりやすいかなと思ったので（共有します）。出版社さんと一緒に作った「BookLink」というデジタルチラシ配信サービスについて詳しく説明できればと思います。

BookLinkができた経緯です。出版社さんは、新しい書籍とか、いわゆるパブリシティの情報とかを、全国に100とか1,000とか1万とかあるような書店さんに、現在も紙ベース、FAXで送って、それを印刷した上で目検で見ながら発注をすることをしていて。

（そんな中で）出版業界で創業65年やっている文化通信社さんから、「手間だし、紙の量も使いすぎるということで、なんとかオンライン化できないか」という相談をいただきました。

チーム体制としては、先方にPOや営業担当者がいて、弊社には基本的にPMとデザイナーさんとエンジニアさんがいるというかたちでした。

実際に開発を進めていく中でいうと、最初に仮説を基にプロダクト構想を作りましょうと。この時僕も久しぶりに（構想を）作ったんですが、ペーパーモックみたいなかたちで、色紙をみんなで共有しながら「こういうかたちがあるんじゃないか」とかを、ディスカッションしました。

その上でデザインして実装して、一緒にリリースして。その後は、リサーチというかたちでユーザーに対してアンケート調査を行ったという流れになっています。

なので、プロダクトチームとしてやったものは大きく3つで、1つはペーパーモックです。（スライドを示して）下のものが実際に書いたものになるんですが、もともと持っていた課題をヒアリングしながら、「そのためにはこういうふうな画面が必要ですね」とか「こういうふうな機能があったら良さそうですよね」みたいなことを、みんなで一緒にテーブル1枚挟んで作ったというかたちです。

2つ目は、共通した情報源を常時共有するという意味で、Notionとか週1回の定例とかSlackに入ってもらったりしています。

3つ目はいわゆるアンケート調査なんですが、実際にGoogleフォームで作ったアンケートを初期のユーザーさんに答えてもらって、そこから出た改善点とかを開発に活かしていくというかたちを取りました。