toCとtoBが混在する複雑で挑戦的なプロダクト開発
ココナラは、「一人ひとりが『自分のストーリー』を生きていく世の中を作る」というビジョンのもと、知識・スキル・経験のマッチングサービスを提供している。同社のマッチング事業は主に3種類に分けられる。
1つ目は、マーケットプレイスの「ココナラスキルマーケット」だ。バナー作成や占いなど、1回限りの役務（サービス）提供を必要とする購入者と提供者をつなぐプラットフォームとして機能している。2つ目は、エージェント事業だ。プロジェクト型とも呼ばれ、長期の業務委託の形で人手不足の解消を目指している。3つ目は、メディア事業の「ココナラ法律相談」だ。ビジネスモデルは広告収益型だが、適切な弁護士を見つけて悩みを解決したいというコンセプトは、マーケットプレイスと共通している。
今回のウェビナーのタイトルは「シンドイ開発も笑顔で終わりたい！ ココナラ開発、チームビルディング虎の巻」。竹下氏は現在もプレイングマネージャーとしてプロダクトマネージャーの職務を担っている。関川氏はプロダクト開発部長として、エンジニア主体で創意工夫しながらプロダクト開発に取り組んでいる。今回は主に、ココナラスキルマーケットでのプロジェクトについての経験やノウハウが展開された。
ココナラスキルマーケットは、個人のスキル、知識、経験をサービスとして提供できるプラットフォームだ。ECサイトのように、オンラインでサービス提供の売買ができるのが特徴である。出品者は、例えば「バナーを2万円で作ります」といったサービスを出品し、同じバナー制作を提供する他の出品者は、2万円や5万円、あるいは追加のサービスを含めて10万円といった価格設定で出品する。購入者は、ECサイトのようにこれらの出品を比較して、サービスを購入することができる。オンライン完結だけでなく、出張サービスなども対応している。
サービス提供の形態はtoCとtoBの両方で、400以上のカテゴリーを展開している。ビジネス利用が多いカテゴリーもあれば、主にプライベートで使われるカテゴリーもある。竹下氏は「個人向けと法人向けが入り乱れてマッチングされる珍しい形態のため、プロダクトの複雑さは社内でもよく指摘されます。開発側は、誰のためにその機能を作るのかを常に問いながら、難しいものづくりに取り組んでいます」と説明した。
多様な人材が体験した、しんどいけれど爽快なプロジェクト
ココナラのマーケットプレイス事業本部でプロダクト開発に関わるのは、プロダクトマネージャー（以下、図中ではPdM）、エンジニアリング、カスタマーサービス（カスタマーサポートとトラスト＆セーフティ）、QA（品質保証）の各チームで構成される。インフラ、デザイン、マーケティングは全社組織となっている。案件ごとに、部署を横断してチームを組成して開発を進めている。
竹下氏はメンバーの特徴について「ココナラには、エンジニアからプロダクトマネージャーまで、ビジョンを大切にし、ユーザーファーストの精神を持った人材が多く集まっています。職種としてのプロダクトマネージャー以外にも、社長や組織長、マーケティングのトップ、元財務のトップなどがプロダクトマネージャーの役割ができてしまうのも特徴。プロダクトドリブンな環境で、意思決定にはプロダクトに深い理解を持った人々が関わるため、非常に恵まれた状況にあります」と説明した。
重視している方針は「ユーザーへ最速で最高の価値を〜ただし未来へ負債をなるべく残さず〜」だ。それを実現するためには、現場でさまざまな課題が発生する。プロダクトマネージャーはユーザーが求める時期にリリースすることにこだわっている。その一方で、開発中に「もっと良い体験が提供できるのでは」と、変更を検討することがしばしばある。
クオリティとスピードのバランスは難しく、時には対立することもある。例えば、プロジェクト終了時にメンバーから「上から決められた納期を押し付けられていると感じる」とコメントをもらうことも。また、ユーザーファーストの精神から、当初決めたことが開発終盤で変更が入り、現場で混乱を招くこともあった。
そのような中、ビデオチャット機能をZoom Video SDKを使ったものにリプレースするプロジェクトが持ち上がった。元々リプレースの話はあったが、その計画が固まる前に「ビデオチャットを使ったスケジュール機能をリリースする」という大型プロジェクトが先に決定し、それがリリースされる前にあらかじめビデオチャットのリプレースを行って使い勝手を向上させておくべきだという話になった。
そんなわけで、スケジュールの見積もりが固まる前にリリース時期が決定、さらに「リプレースだけではユーザーにメリットがないため、機能追加も行おう」ということになった。これによりスケジュールの制限だけでなく新たなスコープが増え、側からみると炎上必至のプロジェクトが爆誕した。誰もが「ああ。このプロジェクトは「しんどい」だろう」と思っていた。
ところが、プロジェクト終了後のメンバーからのフィードバックはポジティブなものだった。「ピリピリした雰囲気が全然なかった」「連携が活発で良かった」「みんながテストに協力してくれて感謝している」「プロジェクト終盤でも雰囲気が良く、活気にあふれていた」という意見が多く、結果的に「しんどい開発を笑顔で終えることができた」ということになる。
プロジェクトを笑顔で終えるためのさまざまな要因と工夫
この結果に竹下氏、関川氏は驚き、その要因を調査した。リプレースプロジェクトで起きていたポジティブな要素の一つに、ユーザー理解が非常に高いメンバーがいたことが分かった。このメンバーは自分もユーザーとしてサービスを利用しており、従来のビデオチャットのUIの問題点を長文にまとめてデザイナーに直接持ち込むなど、熱心に取り組んだ。その行動により、データからは見えないユーザーの不満が明確になり、他のメンバーもユーザー理解が進むとともに、この機能開発をより身近で、自分ごととしてとらえるきっかけになった。
もう一つのポイントは、メンバーが「神アプデと呼ばれたい」というモチベーションを持っていたことだ。メンバーを集めたキックオフ時のランチ会でプロダクトオーナーがプロジェクトの目的を説明した際、自然と「神アプデ」という言葉が出てきた。この言葉がチームの士気を高め、困難な状況でも乗り越える力となった。
キックオフ時にメンバー全員が集まって行う、通称「キックオフランチ」。ここでユーザーに喜ばれるプロダクトを作るという目標を共有した。これにより、お互いを理解し、一蓮托生の関係を築くことができた。また、テストについてもテスト専門チームだけでなく、エンジニアやデザイナーなどを含めた全員で品質チェックに関わり、多様な環境での使用体験を考慮したテストを実施した。「成功のために分掌を越えて一致団結すること」。これがプロジェクトの成功に寄与した。
分掌をビヨンドボーダーしたシーンは他にもある。当初はプロダクトマネージャーが大量の要件を更新していた。しかし、手が足りず、そのことが開発のボトルネックになってしまったことがしばしばあった。竹下氏が「このぱつっている状況で、開発に支障をきたしてまで、なぜプロダクトマネージャーだけが仕様を書かなければならないのか」と疑問を呈したことで、仕様は皆で決めたことをアップデートするのだから、書ける人が書けばいいというルールができた。
この体験をもとに、竹下氏は別のプロジェクトでも再現性を高めるポイントを振り返った。ユーザー理解の壁を乗り越える工夫、メンバー同士が腹を割って話せる環境の工夫。そして、チャレンジしているチームに対して「俺も手伝うよ」と応援される環境を作ることが、プロジェクトのモチベーションを高め、結果的に品質につながる。竹下氏は「この手法を型化して他のプロジェクトにも取り入れるべきだと考え、現在実践しています」と説明した。
さらに竹下氏は、他のプロジェクトにも役立つポイントをいくつか紹介した。その一つが、ユーザーとの雑談の機会を持つことだ。ココナラでは月に1回、ユーザーを会社に招待してイベントを行うことがある。フォーマルなイベントだけでなく、ユーザーと飲んで食べるカジュアルな場もある。こうした場では、かしこまったインタビューでは得られないユーザーのプロダクトの使い方や、苦手な点などのインサイトを得られる。
竹下氏は「雑談の機会を持つことは、ユーザーインタビューと併用することで、より多くの有益な情報を集められます。可能であれば、ぜひ取り入れてほしい」と述べた。
ユーザーがいつでも気軽に意見を言える環境も提供し、問い合わせのハードルを低くしている。ユーザーの問い合わせはサポートセンターへのメールなどで行われるが、ココナラのサイトでは全ページの右下に「ご意見ボックス」が設置されている。ユーザーはTwitterでつぶやくように気軽に意見を投稿できる。「ご意見ボックス」はSlackとも連携しており、365日24時間、開発関係者全員に届く。
竹下氏は、プロジェクトの内容を大きく改善するキックオフランチの重要性を改めて唱えた。プロジェクト開始前に、実装者からQA担当者まで全員が集まり、豪華なお弁当を（会社経費で！）食べる。このランチの際、今後の開発での関係性を考慮しながら、席の配置にもこだわり、事業責任者やプロダクトマネージャーがプロジェクトの意義をプレゼンする。また、仲間を知るためのクイズなどを行い、普段はリモートワークが多い中でもオフラインで会話する機会を作ることが重要だとした。
また、プロジェクトの前段階で開発マインドをそろえる取り組みも行っている。プロジェクトコアバリューと呼ばれる、16の合言葉で構成される開発行動規範を作ったのだ。この規範にのっとって仕事をすることが、人事評価にもつながるように設計されている。
竹下氏はプレゼンテーションの最後に「プロダクトを作るプロダクトマネージャー、デザイナー、エンジニアが『どんな開発チームでありたいか』をしっかりと話し合う機会を持つことが非常に重要だと考えています。私たちのスローガン『ユーザーへ最速で最高の価値を』をチーム全体で守ることで、足りない点や問題点を話し合えます。まず、チーム全員で目標を決めることが、開発において非常に大切だと思います。ぜひ近くのエンジニアやマネージャーを巻き込んで、どのようなプロダクトを目指すのか一度話し合う機会を持っていただければと思います」とコメントした。
Q＆Aセッション
Q：ココナラには、ユーザー視点を重視する人と職人気質の人の両方がいると思われる。採用時にそのような人を選んでいるのか、入社後に変わっていくのか、どのような傾向があるのだろうか。
関川氏：ココナラのエンジニアは、技術力重視、プロダクト志向、入社後に変化する3タイプに分けられる。採用時の人材ニーズに合わせて柔軟に対応しつつ、入社後のフィードバックによって仕事の仕方が変化するケースもある。自分としては今まで触れたことのなかったカテゴリーのユーザーと話す機会があり、そうした経験を通じて徐々にプロダクトへの興味を深めていった。
Q：ユーザーの声を定期的に聞ける場があるという話があった。その中で、Slackを活用してユーザーの声をデータベースに蓄積し、社内で共有する仕組みを設けているのだろうか。ほかに情報共有やコミュニケーションの工夫があれば知りたい。
関川氏：Slack上でのオープンなコミュニケーションを大切にしている。自分が直接関わっているプロジェクト以外の情報にも、興味があれば自由にアクセスできる。ユーザーの声に触れる機会も増えるし、ほかの人の働き方を観察することもできる。これはココナラの文化の一つだ。
竹下氏：部署を超えた活発な議論が行われている。ユーザーの声をきっかけに、異なる事業部のエンジニアやプロダクトマネージャーが自らの経験を交えながら意見を交換し、データサイエンスチームを巻き込んで調査を開始することもある。最終的にはプロダクトマネージャーがディスカッションをまとめ、ユーザーへの影響を確認した上で、プロジェクト化の検討を進めるようなこともある。
Q：開発はウォーターフォール・アジャイル・ハイブリッドなど、どのようなスタイルか。
関川氏：ハイブリッドを採用している。2週間以上かかる大規模な機能開発では、ユーザーの要望を踏まえた要件定義を行い、ウォーターフォール型で進める。一方、ユーザーから寄せられた小さな改善点などは、チケットを積み上げてできたところからリリースするアジャイル型ですすめることもある。
Q：つらいプロジェクトほど、チームの結束力が重要だと考えている。プロダクトマネージャーやリーダーは、チーム作りにおいてどのような方針で臨んでいるのか。
関川氏：プロジェクトを笑顔で終わらせることを意識して行動している。納期が厳しくても笑顔で終われることもあれば、そうでなくてもつらい思いをして終わることもある。次のプロジェクトにつなげるためにも、今何をすればみんなが笑顔で終われるのか、モチベーションを上げるにはどうすればいいのかを考えながら動いている。
竹下氏：前向きな姿勢とムードメイキングが重要だ。後ろ向きな発言は控え、困難な状況でも明るい雰囲気をつくれる人材をメンバーに入れるようにしている。
また、開発リーダーやプロダクトマネージャーが一堂に会するミーティングを設け、プロジェクトの状況を俯瞰的に確認している。経験豊富なマネージャーが、若手にアドバイスを与え、困難な局面では息抜きの機会を提案するなど、臨機応変に対応している。状況が悪化した場合は、上位者が直接介入することもある。
Q：プロジェクトを成功に導くにあたり、プロダクトマネージャーとしては、どのような点に心がけているのか。
関川氏：リリース前は残業が増えたり、バグ修正のプレッシャーがかかったりと大変な時ももちろんあるが、その困難を乗り越えた達成感を共有したい。メンバーと現場で伴走し、「今日は頑張ろう」と励まし合いながら難局を乗り越える。最後は「しんどかった」ではなく、「何とかなった、達成した」という感覚で終われるようにしたい。
竹下氏：成果を出すことが重要。無駄な開発を避け、納期に間に合わない機能は削るなどのトレードオフの判断が必要になる。ユーザーのために追加要件が出た場合、優先度が低いものを見極め、データに基づいてユーザーへのインパクトを評価し、適切な優先順位付けを行うことが成果につながる。
プロジェクトの納得感も重要。多くのメンバーが関わるプロジェクトでは、全員が自走することが理想だが、そのためには仕様の間違いや改善点に各人が気づけるようになることが大切だ。プロジェクトの目的やユーザーへの価値、成功の定義をメンバーに浸透させることが肝要だ。キックオフだけでなく、繰り返し伝えることを意識している。
Q：プロジェクトメンバーでない外部の人に協力してもらう、外から応援される環境作りがうまくいくための具体策を知りたい。
関川氏：プロジェクトを構成するメンバーが流動的であるため、前回一緒に仕事をした人が今回困っている場合、自然と手を差し伸べたくなるようになっている。
竹下氏：マネージャーやリーダー同士とても仲が良い。私と関川も趣味の話で盛り上がる。リーダー同士仲が良いと「お互いのチームが困っているから助けたい」と自然に思える。仲の良さだけでなく、お互いの意見を出し合うオープンなコミュニケーションが大事だ。それがプロジェクト成功の一因だと思う。
プロダクト開発をサポートするZoom最新情報
今回のイベントに協賛いただいた、Zoom社の日本法人の最新情報をいくつか紹介させていただく。
Zoomでは、「Zoom ビデオ ミーティング」「Zoom Webinars」などのプロダクトを支えるバックボーンとしてデベロッパーエコシステムがあり、APIを使ってZoomの機能をさまざまなサービスと疎結合できるようになっている。
ココナラが採用したZoom Video SDKは、Zoomのビデオ通信機能を切り出し、自社のブランドやUI/UXにカスタマイズして利用可能となっている。特徴として次のようなものが挙げられる。
- iOS、Android、Mac、Windows、ブラウザ、Linux、Flutterなどをサポート
- 高品質なビデオや音声を活用できる
- Unityでの開発もベータ版で可能に
ココナラ以外では、以下のようなサービスでも導入されている。
- 株式会社チカク：高齢者向けのビデオ通話デバイス「ちかく」
- 株式会社野村総合研究所：電子契約と本人確認機能を内包したオンライン商談システム「econy」
Zoom Video SDKは毎月1万分まで無料で試すことが可能で、今後の展開としてAI機能（文字起こし、テキスト翻訳）の強化、ローコードツール「UI Toolkit」のリリースが予定されている。
また、ZoomのAPIやSDKに関する情報交換のコミュニティも開始されたので、そちらも併せて参照してほしい。
