こんにちは、坪田です。
dely Advent Calendar 3日目の記事です。

昨日は、エンジニアのmochizukiが NetflixのFast JSON APIを使ってみた を書きました！

僕は、クラシルを運営するdelyでクラシルユーザー体験と、開発部門のマネジメントに責任を持っており、そのプロダクトマネジメントのスタイルを書いてみます。

よく、CXOって何をするのか聞かれますが、僕の場合は社長である堀江さんのビジョンを汲み取り、1秒でも早く、ユーザーに評価される最適な体験を作ってリリースする事を仕事にしてます。プレイヤー領域としては、UIデザインを武器にしているので、ユーザー体験を可視化しながら関係者を巻き込んで開発するスタイルが強みです。

今回は、突破するプロダクトマネジメントという内容で、クラシルで実践しているプロダクトマネジメントの手法について書きました。

タイトルを突破するにしましたが、UX課題の多くは、アイディア問題ではなく、問いの適切さと、壁を乗り越えた実現への執着だと思います。

僕は、デザイナーでもあるので、資料を作り込むより、アイディアのプロトタイプを作り、可視化しながら議論して進める事を武器にしています。

ただ、多くの場合、アイディア実現にあたって障壁が立ちはだかります。

開発に最も身近な所だと職種の壁。

実現可能性についての議論、UIアニメーション一つとっても、開発に投資する納得感の醸成が大事ですし、何故工数を掛けるべきなのか、腹落ちしないとメンバーのモチベーションが下がって品質が下がります。その辺を意識してコミュニケーションしてます。

次は組織の壁。

仮にUIとして実現できても、コンテンツ確保する部門との調整、他社サービスとの連携時は、API開発の調整やお互いのスケジュール問題、シームレスなユーザー体験を実現するためには、上辺だけではないより突っ込んで認識をすり合わせるために多くの会話が必要になります。

ヒエラルキーの壁。

delyはフラット組織かつ社長の堀江さんと直接話せる環境なので、意思決定は早いですが、規模が大きくなるほど、ここがボトルネックにになりがちです。

サービス開発で意思決定者と直接話せない環境だと、同じ機能開発でも難易度がベリーハードになります。それを解決するのもプロダクトマネジメントの仕事です。

リーガルチェックなどと呼ばれますが、法律の壁。

事業ドメイン次第で向き合い方が変わりますが、ユーザーにとって理想のUI実現とリーガル観点が相反する事が多々あります。

法的観点をクリアしつつ、ユーザーが不便に感じない落とし所を考える必要があります。開発後にリーガルNGで巻き戻るとリソースの無駄遣いになるので、課題になりそうな企画は早めに有識者を巻き込んで進めます。

例えば利用規約やプライバシーポリシーの表示方法一つとっても、掲載場所、オプトイン・オプトアウト方法を可視化して着地させていきます。

すべての壁を突破できたとしても、今度はリソースの壁が存在します。1秒でも早く開発したいので、実現できる強いチームを作らないといけません。エンジニアリソースは生産性に直結するので、リソース責任も自分の担当として取り組みます。

プロダクトマネジメントのフレームワークは多々存在しますが、導入後に現場で最終的にぶつかるのはこれらの壁で

理想のユーザー体験を実現する場合、特に縦軸組織の調整が重要になるので、PdMは立場を超えて実現と向き合う総合格闘技みたいな感じです。

突破力大事。

クラシル開発で実践したこと

ここからはクラシルでの実践例を書いていきます。

delyに入社する事を決めてから、今年の5月に開発部全員で本音で課題を出すワークショップを実施しました。

サービスも組織も同じで、インサイトから課題を洗い出していきます。

上記は、ワークショップであがった課題の一部ですが、1秒でも早く開発するために、サービス・開発軸に切り分けて、これらを一つ一つシューティングしていきます。

付箋だと事後処理が大変で、ログ化しにくいので、スプレッドシートに記載する方法がオススメです。今振り返ってみたらわりと辛辣な内容でした。本音で話すのが大事ですね。

開発バックログが一本の場合、緊急性が高い短期タスクが差し込まれがちで、負債もたまっていくので、グロース、新機能開発、中長期投資のタスクに切り分けてロードマップを整備していきます。

この時に大事なのが、ロードマップを引いても、経営合意を得ないと絵に描いた餅になってしまうので、堀江さんとの1 on1 や経営合宿で来期のロードマップを合意するようにしてます。

ロードマップと優先順位の考え方が一枚の画像で理解できるような構成にしてます。社員入社時はこのロードマップを見せながら話してます。

モノづくりにおける100点基準の目線合わせ

次は品質基準を合わせていきます。モノづくりにおける100点は人によって異なるので、チームで開発するためにクラシルらしさの品質目線を合わせていくのが大事です。

毎週水・金曜日に開発中のデモを実機で触ってレビューするプロダクトレビュー会を始めました。開発チーム皆でポチポチ触って話す会です。

今は、そこで通過しないとリリースできない仕組みにしましたが、その際にNG理由を言語化する事が品質基準の目線合わせになります。

僕の場合は、NGの時ほどわかりやすく言語化するように意識してます。

チームが肥大化してレビューが属人的になると、伝言ゲーム化したり、レビュー待ちで開発ブロッカーになると、メンバーのテンションが下がるので、クラシルらしさを話しながらチーム文化として品質基準を醸成していく事を意識してます。

毎週堀江さんと1 on 1してる内容をチームSlackに投下してます。目まぐるしく変化するスタートアップ市場は意思決定も変動するため、アジェンダ無くても1 on 1を実施して、思考から次のアクションを予想して体制検討や企画調査を始めます。

社長インサイトの分析をする事で、次の一手を予想して動きます。

いつもはカフェで実施してますが、この前は歩いて実施した 1 on 1も良い感じでした。

プロトタイプを議論の叩きにして巻き込んでいく

僕の場合はデザインが武器なので、こういうの実現したいんだよねーみたいな状況になったら、先ず一連の流れをデザインで起こして議論していきます。

この時のグラフィックは適当で、既存コンポネントを流用してスピードを重視して早く形にします。

例えば、堀江さんと1 on 1して出てきたアイディアをさくっと作って、Slackにキャプチャを張って議論したり、見える形でたたき台があると、他部門や関係者を巻き込んだ議論をしやすいのでオススメです。

具体化プロセスでどういう課題を解決したいのかざっくりペルソナを作って

それらの課題を可視化して実現にあたっての検討をしていくスタイル。

その時、数値根拠が必要であれば出したり、時にはユーザーインタビューしたり、状況によってアプローチは変わりますが、プロトタイプを軸にして進めていく事で、論点をぶらさないように意識してます。

フロー型で巻き込んでいくカルチャー

開発仕様などストックすべきモノはQiitaにまとめていきますが、メンバーを巻き込んで会話しながらゴールに向かえるよう、考えのキッカケとなるモノはSlackに投げて人を巻き込みながら精度を高めていきます。

delyの場合は、こんな感じで機能毎にSlack chを作って、そこに職種問わず必要なメンバー巻き込んで進めていく感じです。職種軸でコミュニケーションを閉じずに、機能やユーザー体験軸で会話していきます。

その時、Figmaを開かなくても、Slack上で閲覧が完結するような投げ方をする事で、閲覧率もあがり、会話が生まれやすくなります。

※そのやり方だと情報を追うSlack chが多くなってしまうのは課題

インハウスならデザインをキレイにまとめなくても、ホワイトボードでも十分です。書きながら議論していきましょう。

やっぱりリソースの解決

どこの会社もリソース不足ですよね。わかります。先ずエンジニアリソースから手を付けていきます。その次にデザイナー採用の順番です。

これは、実際に経営合宿で提案した時に使った画像ですが、ロードマップを引いたたら、明らかに工数が足りなかったので、エンジニア採用を強化するために20人採用したいと訴えてみました。

1秒でも早く作る体制を作るのが仕事なので、リソース不足を解消も自分のミッションとして考えます。

市場への魅力を伝えるアクションとして、エンジニア向けの採用スライドを作って公開しました。多くの人にみていただき、24,000PVを超えて面接に来る方がみてくれてる事が多いです。

資料はここからみれます。
https://speakerdeck.com/tsubotax/dely

公開後、エンジニア5人採用が決まり、エンジニアリソースも少しづつ整ってきました。

ただ、カルチャーをまとめて発信するだけではなく、制度についても人事や他部門と相談しながら決めました。

スタートアップの採用で大事なのは、メンバーが自信を持って自分の会社を勧められるかが大事でその環境を維持できるように努力し続けます。

外の人によく聞かれるので、上場を目指してる事も繰り返し伝えてます。

給与などの報酬体系も見直しています。開発部のオファーは未だ承諾率100%です。

エンジニアが100名超えても高い生産性が維持できる組織構築を目指す

エンジニア、デザイナーが100名超えた組織でも、生産性を落とさず開発できる環境構築を目指してます。先ず10月にVPoE / VPoE制度を導入しました。VPoEは組織設計がミッションでwevoxさんにこの辺の話を突っ込んだ記事を書いていただきました。

新“CXO＆VPoE”が語る組織開発のロードマップ
https://wevox.io/media/story-dely/

VPoPは事業目標の成果達成がミッションでヒューマンマネジメントは行わず、プロダクトの意思決定を行うのが仕事です。この辺はGunosyさんの CTO・VPoE・VPoPの分立とCTO を参考にしたり、模索段階ですが権限委譲やチームサイズを適切にする事で生産性を落とさず開発できる体制構築を目指しています。

成功するためには銀の弾丸を考える思考になりがちですが、経験上、破壊的なイノベーションを除いた現場で重要なのは、壁を乗り越える力だと思います。

食の課題解決に向けてdelyで働く事に興味がある方、ぜひご連絡ください。エンジニア、PdM、デザイナー全方位で募集してます。

おいしくできますように。

さて次回は、ロンさんが「Jupyterもいいけど、SageMath使って可能性もっと伸ばそう！」というタイトルで投稿します！