プロダクト品質の向上に注力するチームができました - 目指すもの・立ち上げ・開発

2022年1月26日 10:29

株式会社スペースマーケットのデザイナー、中原です。
今一番欲しいものは床暖房です🔥

昨年スペースマーケットの開発チーム（ユニット）の一つとして「MQチーム」が誕生しました。
特定のKPIや予定されている機能改善・施策の実現などを目的としているチームとは異なり、「プロダクトの品質向上を目指し、改善を繰り返す」ことを目的としたチームになります。

今回はそのチームが目指すもの、立ち上げ〜運用をどのように行っているかを紹介したいと思います。

なぜこのチームが必要なのか🤔

ちなみにチーム名のMQはMust-be Qualityの略です。狩野モデルなどで出てくる「当たり前品質」から拝借しました。

※チームとしては「当たり前品質」だけではなく他の「一元的品質」など他の品質も求めていくので本来の用語の意味とはすこしずれるのですが、チームの方向性を一番わかりやすく表現していそうなこのワードを中心に置くことにしました。

品質を維持・向上させる仕組みがほしい

どうしてもビジネスとしてプロダクト開発をしている以上、ビジネス指標や短期的な成果を生み出す部分にパワーを使うので、リソースに限りがある組織ではどうしてもクリティカルではない問題/細かな改善が後回しにされがちです。

そういった技術負債・UX負債の積み重なりが、開発効率を著しく下げてしまう、ユーザーに不信感をもたせてしまうなどの後々の大きな問題につながってしまうことがあります。
常に改善に取り組み、問題をなるべく小さいうちに解決していくことが継続的なプロダクト開発には必須になります。

こういった取り組みはメインで取り組む目標・業務の合間に行われることが多いのですが、なかなかうまくいっているチームはないんじゃないでしょうか。
なぜなら余力のあるチームなんてこの世に存在しておらず（）、どうしても別の優先タスクが差し込まれてしまうからです。

そんな背景もあってか？今回、他のプロジェクトチームと並列で品質向上に専念するチームを作ることになりました。

チームを立ち上げる🙌

今回のチームは初めて一緒に仕事をするメンバーも多く、また今までに存在しなかったチームだったこともあり、

チームの目指すものはなにか
具体的なチーム運営の方法

を固めるところからはじめました。

チームメンバー：
PM、バックエンドエンジニア（2人）、フロントエンドエンジニア、デザイナー（私）

キックオフ - われわれはどんなチームなのか？

まずメンバー同士の理解・チームの目的を共有するためにキックオフミーティングをおこないました。

まずはアイスブレイクがてらメンバー同士の自己紹介から。
はじめましてのメンバーもいるので、こういうの地味に大事だったりします。

ちなみに自己紹介の項目

名前の呼び方（なんて呼ばれてる？呼ばれたい？）
仕事歴を簡単に
辛かった/楽しかった仕事
好きなもの
嫌い・苦手なもの

十分に温まったところで（？）、チーム方針の策定に進みます。

このチームの目的（存在意義）はなにか？
- 会社から求められている役割
- 自分たちがプロダクト開発を通して生み出していきたい価値
どんなチームでありたいか
- ふるまい、ムード
チーム名
- 何を目指しているかが伝わるチーム名

このチームが立ち上がるきっかけとなった「放置されている負債を解消したい」「インパクトは小さくともユーザーのために改善を繰り返していきたい」といった課題感はどのメンバーも多かれ少なかれ持っているものでした。
ここでは具体的にどんなことをしたい、どんなマインドでチームタスクに取り組んでいきたいかというようなことを書き出し、すり合わせを行って簡潔な文章にまとめていきました。

短期的な施策・効果を狙うものではなく、ユーザーの体験を少しづつよくしていく長期的な取り組みの中で効果が現れることを目指す
という点が、このチームが大事にする軸であるということを確認できました。

チーム開発を回す🌀

日々の開発を管理する

MQチームではアジャイル開発のいわゆる“カンバン方式”というものを参考に開発を管理しています。

弊社の他チームはスクラムを採用しているチームが多いのですが、MQチームは

比較的細かな施策をこなすことが多い
- すぐ終わるもの多数
- 長期間の見通しを立てる場面が少ない
そもそも他PJと兼務のメンバーが多いので、チームとしてのベロシティを割り出すのが難しい（出たところで活かしにくい、改善しにくい）
- ※兼業だと成果出しにくいよねみたいなことを↑で書きましたが実際に専業できるほど現実は甘くない😇

という理由などからシンプルにタスク管理に重点を置いているので、カンバンでの管理が相性がいいかなと思って採用しました（今後チーム状況によって変わることもあると思います）。

振り返りは2週間おきに行い、開発の進め方の改善や個人/チームの問題解決に取り組んでいます。
最初にチームの方針をメンバーで合意したことによって、振り返りの度にチームの現状がその方針に沿ったものになっているかどうかをチェックすることができますし、また新たに生まれたTryからチーム方針のアップデートをおこなうことができます。

※余談ですが、チーム開発関係なく個人のプライベートの出来事やスキルアップに関する振り返りなんかも一緒に行うと、良いコミュニケーションやモチベーションアップに繋がるのでおすすめですね。

また時には数週間〜数ヶ月に及ぶ施策に取り組むことがあります。
チームとしては普段スプリントプランニング的なことはやっていないのですが、そういった大きめの施策に取り掛かる際には事前にプランニング（見積もり、やることの整理）を行なうことがあります。

最近取り組んだ施策では、エンジニアメンバーが

対応箇所＆タスクの洗い出し
それぞれのタスクの関連
- ボトルネックになりそうなところはどこか
作業見積もり

をFigJamで整理していました。わかりやすい！

他チームとの連携

プロダクト品質を向上させるためには、当たり前ですが様々なチームと連携して改修を進める必要があります。
ユーザーニーズやサービス運用の現場で起こっている問題を察知して的確に改善を行っていくために、他チームとのコミュニケーションの場を設けています。

例えばカスタマーサクセス・マーケティングチームとは週に一度定例ミーティングを行っています（MQチームからはPMと開発者代表が参加）。
施策の状況や改善リクエストなどを持ち寄って対応方針を話し合い、そこで出た内容ををMQチームに持ち帰り対応方法や優先度などを決めてチームに落とし込むという流れになっています。

他チームとの協業例

カスタマーサクセスチームとの協業
- ユーザーからの要望を教えてもらう
  - ↑に対する改善案の共有など
- CSメンバーがユーザーニーズに応えられるようにするための改善
マーケティングチームとの協業
- 計測方法の改善
プロダクトのバグ対応
- 複数チームがフォローしあってバグ対応にあたる仕組み（にMQチームも参加）
他のPJチームとの協力
- お互いがサポートメンバーを派遣
- 開発状況やチーム運営方法などの情報共有

ユーザーに直接価値を届けるということはもちろん、社内のユーザー（中の人）をサポートすることでサービスとしての品質を向上させるということもMQチームの重要な役割です。

バックログの認識合わせ

MQチームは様々なタスクに取り組むことになります。依頼、バグ対応、改善アイディアの実現などなど。
チームとして取り組むことは基本的にメンバー全員で確認し、対応の有無や優先度、必要な作業やリリース後確認する指標など、取り組むべきことはチームで決めます。

判断が必要な場合はPMに相談しますが、チームで取り組むことを決めるのがMQの目指す形です。
（もちろん個々で判断する場合や組織として決まるタスクもあるんですけどね）

課題に感じていること🙄

始動してから3ヶ月ほどですが、個人的に課題に感じていることを挙げておきます。

やったこと（チーム）の評価は難しい

どうしてもすべての改善の価値を計測し数値化することは難しいです。サービスの品質とかユーザーの満足度、ビジネスKPIなどは様々な要因が組み合わさって出てくるものなので。このチームにどれだけの価値があったのかを証明することは非常に難しいです。
（それでもそういった改善をやるべきであろう、という考えのもと発足したチームでもあるのである程度しょうがないことではあるのですが）

改善点の「発見」に取り組めていない

兼務のメンバーも多く作業時間を確保できないということもあるのですが、日々発生する細かな改善タスクをこなしつつ「本当にMQチームが今取り組むべき課題はなんだろう？」というところまで考えられていないというのが現状です。
チームの開発サイクルがやっと自然に回り始めたかなというところなので、これはチームが次のレベルに成長するための宿題かもしれませんね。

終わりに🔚

そういえば3年前にnoteでこんなことを書いていたのですが

今のMQチームがまさにこの時思ってたことを実現できるチームなんですよね。
プロダクトをより良いものにしていくチームの一員として、引き続きトライしていきたいと思います💪

MQチームに限らず、一緒にプロダクトを良くしてくれる人をあらゆる職種で募集してます！

この記事が気に入ったらサポートをしてみませんか？