『PM&TechTalk クラシル&ミラティブのPMとエンジニアが語る、開発・組織の課題と向き合いかた』イベントレポート
クラシルを運営するdelyと、Mirrativを運営するミラティブの2社のPM&エンジニアが、組織と開発の課題について語るイベントを2021年8月24日(火)に開催した。
ーークラシルとMirrativ、新しい体験や機能の追加の判断
奥原「Mirrativが2015年、クラシルが2016年にリリースされているんですけども。僕たちがよく言われるのが『もう開発するところないのでは?』ということです。僕らからすると『いや、まだまだあるよ!』と言いたいところですが...。一方で、プロダクトの基本機能はできていることは事実ですね。そういった状況のなかで、新しい体験や機能の追加は、どういう判断軸、体制でやってるか聞いてみたいです」
小川「Mirrativのサービスの場合、『配信』という場が一見同じでも、得られている体験には差があります。Mirrativは、ゲームの配信をきっかけにして同じゲームが好きな他のユーザーさんとつながるサービスなのですが、さらにその先には、ゲームというコンテンツが無くなっても雑談で楽しんでいる、友だち関係になったユーザーさんたちがいるんです。
ゲームを配信しているユーザーさん、雑談を楽しんでいるユーザーさん、それぞれに、どんな体験や遊びを提供するのかで違いがでてきます。この資料で言うと、ライブプラットフォーム、エモモ、新規プロジェクトの3つのチームがあります。
ライブプラットフォームは新規のユーザーさんを獲得し、新規のユーザーさんが仲良くなるための最初のステップをどうつくるのか、という課題を解決しています。エモモは、Mirrativ内のアバター機能であるエモモを中心としたコミュニケーションを促進する企画をつくっています。私と夏が所属している新規プロジェクトでは、ゲームをきっかけにMirrativを使ってくれるユーザーさんに、長くMirrativを楽しんでもらうにはどうしたらいいか、という課題に向き合っているチームです」
小深田「クラシルはSquad(スクワッド)という体制をとっていて、課題ごとにチームを編成しているので、Squadごとに意思決定して進めています。人数はSquadによりますが、5-10名ほどです。期中でも状況に応じてSquadの体制が変わったり、合併したり柔軟に動いています。意思決定を行うにあたっては、必ずデータを用いるので、チームメンバーの納得感があるのも特徴的です。
新機能の追加は、堀江さん(CEO)や坪田さん(CXO)からの発案で決まることも多いです。堀江さんや坪田さんは海外の動向や、『今どういうものが必要か?』という情報を日々集めていますし、それは組織全体に浸透している姿勢でもあります」
奥原「delyがSquadを採用している理由は、組織がピラミッド型になると意思決定のスピードが落ちてしまう。課題に対し、クイックに動けるようになろう、という背景からなんです。
一方で、Squad内だけで意思決定し推進しても上手くいきません。チーム内でよく出る例えなのですが、ピサの斜塔ってありますよね。組織で例えると、Squad内では良かれと思って進めていたことが、全体を見ると実は曲がっていることがあり得ると思います。こういったことを避けるために、1週間に1回にUX定例を設けて、全体的なUXに関わるものには、堀江さんや坪田さんを交えて議論しています」
小深田「ミラティブさんは、全体のUXに関わるものはどう判断されているのですか?」
小川「ミラティブもdelyさんと似ています。サービス全体のUXに関わる部分は、全プロジェクトのPMが集まる企画会議ですり合わせをし、サービス全体に影響がない部分は、プロジェクト単位で意思決定をしています」
ーー日々のコミュニケーションや会議について
奥原「PDCAということなのですが、ミラティブさんは、フルリモートに移行しましたが、コミュニケーション上で変化はありましたか?」
夏「リモートワークに移行し、今まですぐ隣にいて声がかけられるものが、そうでなくなりました。Slackは用がないと気軽に話しかけづらいものですので、コミュニケーションのコストを下げられるように、毎日プロジェクト内のエンジニアとデザイナー、PMが集まる開発定例を実施しています。そこで、ちょっとしたことでも話すようにしています」
奥原「delyは1人1つのSquad専任です。なので、MTGはイシューに関する議論が日々行われるのですが、SquadにはエンジニアやPMだけではなく、管理栄養士など他職種のメンバーもいるので、コミュニケーションは大事にしています」
小深田「座席は背中合わせで固めています。振り向いてすぐ話ができるのを意識していますね」
夏「エンジニアですと、Squadをまたがった課題に向き合う基盤的なチームはいますか?」
小深田「います。基盤チームもいますし、クラシルはリリースから5年経過しておりサーバサイドも技術負債がいくつかあるので、それらの負債を解消していくチームもありますね。Mirrativもリリースから6年が経過とのことですが、負債に向き合うチームは専任でいらっしゃいますか?」
夏「いますね。事業側の開発と兼務すると、新機能の開発と基盤の開発の優先順位を事業部側のPdMが判断する必要があり、基盤開発の優先順位が上がりづらくなることもあります。そういう時には専任の基盤開発チームを設けて、事業部を跨った開発体験の向上を目指せるといいのかなと思っています」
ーーSquad体制・プロジェクト体制で横断したつながり、ノウハウ共有やインシデントの対応は?
小川「PM陣は、プロジェクトを横断した企画を持ち寄る会議をしていますので、その場が互いの経験や成功・失敗の共有をする機会になっています」
夏「エンジニア組織では、サーバやクライアントなと職能ごとに定例は実施しています。あとは、障害がおきたときに振り返りは重要視しているのも特徴です。種類に応じて職種、もしくは、プロジェクト単位で振り返りを行います。そして、その場で中長期的な対応や改善といった、再発防止のための実行スケジュールを決めています。振り返りの内容はその後全体展開され、他のプロジェクトで参考にされたり、他の視点からのフィードバックが入ることもあります」
奥原「どういう背景でそういう文化になったのでしょうか?仕組み化に至った背景を聞いたみたいです」
夏「元々、DeNAで原因の深堀をしっかりやる文化がありましたね。障害に対し『なんとなくで対応した』は許されない。そういう対応をすると、ほっておいたら次も全く同じことやり、同じ障害につながるので...。障害から改善につなげていくことは、DeNAで培ったと思います」
小深田「delyでもサーバサイドのエンジニア同士で集まる会をやっていて、インシデントの共有もそのときにやっています。インシデントに関しては、ドキュメントにまとめて共有することを徹底し、大きなインシデントは全体会議したり、入社時のオンボーディングにもいれたりしています」
奥原「障害報告書もしっかり書く文化がありますね。直接的な原因、間接的な原因を明確にし、短期的な対応、恒久的な対応を記し、責任者を明確にしていますね」
小川「インシデント以外でも、開発フローの進め方で良くなかったな、ということがあった場合には振り返りをしています。例えば最近だと、QAで起票数が異常に多かったときに、低いクオリティで出してしまったのはどういう問題があるかと、PMとエンジニアそれぞれの立場の課題を出して振り返りました。その後は、挙がった課題の改善をしており、規定の気票数を超えたらアラートが飛ぶように仕組み化することで定量的にウォッチしています」
ーー企画のたてかた、すすめかた
奥原「delyでは企画会議があるのですが、複数の課題にまたがることがあるんですよね。カニバったものは、会議で『じゃあ、〇〇さんが担当ね』と、担当を明確にしています。そこに至った背景は、ボールが宙に浮いたものは誰が手をつけていいかわからないから。なので、すぐに担当者を明確にするのは意識的にやっていますね」
小川「サービス全体に影響がでる新機能の場合、他のプロジェクトのPMからも「ここは気をつけてほしい」などのフィードバックをもらい、吸収して進めていきます。最終的な意思決定はCPOがしています」
奥原「複数人のPMがいると、意思決定や企画の質、方向性がバラバラになるケースがあると思うのですが、共通化ってどうしていますか?」
小川「うーん。これ!と言語化したものは、無いですね。じゃあどうしているか?という実状としては、プロジェクト内でリードとなるPMのフィードバックが第一次ステップで、第二次ステップとしてとしてPM全体の企画会議の場としています。また、議論は他の人たちも見られる状態にしており、そういったプロセスを通じて共通化を図っている状態です」
奥原「そうですよね。意思決定の場が閉じると不信感...とまでは言い難いですが、背景がしっかり伝わらないと思っています。delyでもSquadごとにオープンなSlackチャンネルがあり、そこであらゆる議論がされていて、全て可視化しています。delyも共通化でも、これ!というものはないのですが、議論をどんどん吸収してバランスをとりつつ品質を担保しています。議論をふまえて、より良いものをつくっている感じですね」
小川「他のチームのチャンネルはよく見ますね!どんな議論がされているか気になります」
奥原「気になりますよね!」
小深田「他のSquadで常に新しい意思決定が行われており、日々方針も変わります。そういった速い動きをキャッチアップするために、他のSquadの情報も追っています」
奥原「少し話が違いますが、僕は考えていることをSlackに全て書くんです。以前は、考えていることを企画や仕様を出すときに一気に出していたのですが、そうすると伝わるまでに時間が必要で、開発がなかなか進まないということがあって。今はこまめに出すように心がけています」
ーー役割・役職を変えることについて。組織が成長し環境が変わるなかで、自分の役割・得意なこと見つけ方
奥原「夏さんは創業時はCTOとして、今は新規プロジェクト担当として役割が変わっていらっしゃいますがどうでしょうか?」
夏「ミラティブがDeNAは卒業して僕がCTOになったときと、CTOを辞めたときでは、人材の厚さが大幅に変わりました。会社も大きくなり人材も増え、コードを書くよりマネージメントのほうが重要な業務になっているけど、僕よりもマネージメント経験豊富な方や、組織のことを考えて戦略立てて考えられる方がいるときに『僕がミラティブのためにやれることって、これなんだっけ?』と考えました。
今はCTOを退任しコードを書いていますが、僕が長くMirrativのサーバ側の構造を知っているので、基盤開発や言語の移行の際に過去の状況を踏まえて判断できるのは、僕だからこそできる仕事だと思っています。そこで、バリューを出せているのは嬉しいです」
小川「夏さんが言ってくれたことと、近い話だと思うのですが、長く在籍していることで、サービスがどういう構造になっているとか、どういう背景でなっているとか、社内の誰が詳しいとか、そういった目に見えないノウハウ的なものが私のなかに蓄積されています。
今まではそのノウハウを自分で活かすことが多かったですが、最近は、新しいメンバーも増えてきたので、彼らが企画をしたものに対して私のノウハウで後押しすることができているな、と感じています。PMとして自分自身もヒットやホームランを打つことももちろん大事なのですが、チームとしてのものづくりに貢献していきたい。チームづくりが、今の私のフォーカスポイントになっています。一方で、チームづくりは自分が得意なことか?と言われると、実はそうではなくて...。なので、今はチャレンジでもあり、それもありがたい環境だと思っています」
小深田「私自身、delyに入社しまだ役割が変わってはいませんが、変わること自体に抵抗は感じていません。やってみないと得意かどうかとか、わからないですから。また、世の中的にも、技術スキルだけがあればいいというわけではありません。技術スキルがベースにあって、その他のプラスαがあることが大事だと思うので、今後もしもそういうチャレンジの機会があればのっかってみたいと思っています。
※発表内容と登壇者の肩書は、発表当時(2021年8月24日)のものです。
delyとミラティブ各社の詳細、採用について興味をもった方は、下記をご参照ください。
■dely
■ミラティブ
この記事が気に入ったらサポートをしてみませんか?