目次
ご担当者様のご紹介 |
インタビューに応じていただいた小松様について
ー社内の組織構成や、普段の業務内容について教えてください。
メルカリのプロダクト開発の部門では、主にプロダクトマネージャー（PM）とエンジニア（Eng）の２つで構成されたチーム体制「キャンプ」で成り立っています。
開発を始めとした課題の解決をキャンプ内で完結できるように、クロスファンクショナルなメンバー構成になっています。キャンプ内には複数チームが存在し、その中にエンジニア・デザイナー・プロダクトマネージャーなど各分野の様々な専門家がメンバーとして集められ、１つのグループチームとして構成されます。
キャンプ単位でそれぞれの目的が設定され、その領域での方向性の決定権や、日々の開発における意思決定権を委ねられます。社内には合計10個のキャンプが存在し、私の属しているキャンプ３では主任として、外部パートナーと連携し、主に”新しい事業をつくること”に注力しています。
ーキャンプ３のミッションを教えてください
全社のミッションとしては「新たな価値を生みだす世界的なマーケットプレイスを創る」ことを掲げています。
それに従い、私たちのキャンプ３では、越境プロジェクト（日本のフリマアプリメルカリで出品されている商品をパートナー企業を通じて、海外の方も購入できるような新しい仕組み作り）をミッションとしています。
特にキャンプ３では、新規事業の実現をサポートしています。チームごとにサポートしている事業は異なっていますが、基本的にはメルカリJPと連携した新しい事業を立ち上げることを目指しています。
仕事例：日本の物を買いたいという海外のニーズに応えるため、メルカリで出品されている商品を、代理購入サービスの「Buyee」と連携し、海外のお客さまも購入ができるように越境販売しています。今までにはなかった新しいビジネスを展開しているのが私たちのチームです（「Buyee」は、世界100以上の国・地域に対応し、会員数は100万人を超える代理購入サービスです。）
ーmonday.comをどこの部署・業務でご活用いただいていますか？
キャンプ３内にある３つのうちの２つのチームで、エンジニアとPMがmonday.comを活用しています。monday.comの導入は、キャンプ３に属しているエンジニアが、他社ツールの使いづらさからmonday.comを提案したことから始まりました。
ー同じキャンプ内で２つのツールを使っているということでしょうか？
そうです。全社では他社ツールが使われていますが、日々ストレスなく作業を進めるにあたってスクラムの回し方やスプリントボードをどう管理するかは重要でした。
開発している当事者に一番使いやすい物を使ってほしいと思っています。
monday.comを検討したきっかけ |
ーmonday.comをご検討いただいたきっかけについて教えてください。
最初はある開発チームが無料トライアルでmonday.comを使ってみたのがきっかけだったと聞いています。当初、そのチーム内で完結できるプロジェクトであったために全社横断で使用されていた他社ツールを使用しなくても開発が行えたことも大きかったようです。
この無料トライアルで自分たちなりのスクラム開発とmonday.comの使い方の模索ができたことで、monday.comを使うことに決めたと聞いています。
ー当時の課題として、具体的にはどのようなものがありましたか？
従来のツールは、「プロセスやツールよりも個人と対話を」というアジャイルの最初の価値観に即したプロセスを実行することが難しく、私たちのチームの行動が制限されていました。
私たちがツールに求める一番のポイントは、柔軟性です。各チームで最適なプロセスをもって、定期的にサービスをリリースし、お客様に物を届ける。お客様に物を届けないと始まらないので、そのレビューをうけてプロダクトを改善していきます。
ｍonday.com は柔軟性が高く、マイクロサービスに取り組むバックエンドチームである私たちのチームに適したアジャイルプロセスを導入する機会を与えてくれました。
ー他社ツールではOKR の進捗状況を把握する際、エンジニアとPMの両方で使い勝手が悪かったことに課題を感じていたと伺っておりますが、具体的にはどういうことでしょうか？
OKR の進捗状況という意味では、四半期ごとの目標を定めたボードを作り、そこで OKR の進捗状況も確認できています。
この OKR の進捗状況が、プロダクトバックログとスプリントボードの実際の進捗状況から集計されたリアルタイムな情報でかつ自動的に行われているのは 他社ツールではできませんでした。
ーメルカリ様のIT統制について教えてください
背景として、IT統制の観点から僕らがリリースするのは基本的は誰かのレビュー・承認をもらっている状態を作らなければいけません。
元々は他社ツールでチケットを作成して、マネージャー以上の人がステータスを承認したらリリースできるというフローをとっていましたが、それが他社ツール上でしか表現されていなかったので、monday.comでどう体現しようかという話し合いがありました。
このようにフローが他社ツールに依存していましたが、この２年でシステムを単一のアプリケーションで構成する、モノリスなバックエンドからマイクロサービス（唯一のバックエンドではなくて、機能ごとに切り分けられたサービス）に切り替えが発生しており、どのようなフローにすべきかの議論も発生しておりました。
ー他社ツールでできない理由は何でしたか？
厳密に言うとできないことはないですが、プロジェクト管理のツールが混在してしまったために、マイクロサービス化の歴史の中で承認プロセスがなくなり、チームごとで別々のリリースプロセスが生まれてしまいました。
ー理想のリリースプロセスとはどのようなものでしょうか？
元々は各開発者が自身のフィーチャーに取り組むことができるように、マスターブランチの他にフィーチャーブランチを作成し、その中でQAをし、問題がなければリリースする流れでした。
最近はチームやエンジニアの数が増え、1つのサーバ・アプリケーションでやっていくと、リリース時に初めてマージされて実際の運用環境に展開されるので、コード上の衝突が起こりやすくなってしまいました。Newbizのマイクロサービスに関して言うと、「Trunk Based Development 」という手法（基本的にリリースはしないがフィーチャーブランチが問題なければ即座にマスターブランチにマージするやり方）を取り入れていて、マスターブランチに問題がなければリリースする流れを組んでいます。
まとめますと、以前はリリースする前にブランチをマージするかしないかに都度承認プロセスがありましたが、今ではマージしてしまうので、ブランチはマスターブランチに入ってしまいます。加えてチームによってリリースプロセス・開発プロセスが違うので、monday.comでは、どの段階でマネージャーがリリース承認をするかという課題を解決しようとしています。（monday.comで組める承認プロセスはこちら）
なぜメルカリはmonday.comを
|
ーメルカリ様がmonday.comを使って実施しているアジャイル・スクラムについて教えてください。
メルカリ様が採用しているスクラム（以下の図）
(参考：http://agile.blog.jp/agile_scrum/14885237.html）
（参考：https://less.works/less/framework?preferred_lang=de)
キャンプ３ではないのですが、キャンプ１では複数のチームが並行して作業しているため、チーム間の連携に優れている「Less framework」を採用していると聞いています。「Less framework」とは2∼8チームでの開発向けで、 チームを組織の基本単位とし、チームをブロックとして組み立てるよう に組織を構成することです。社内の実際のフレームワークは、キャンプ全体のスプリントレビューやMTG後、チーム単位でスプリントを実装、最後にまたスプリントレビューでキャンプ一同が集まる流れです。
ーメルカリ様のスクラムの特徴は何でしょうか？
スクラムはデイリースクラム(朝の集会)、スプリントプランニング、レトロスペクティブ、スプリントレビューの４つのセレモニー（MTG）から成り立っています。その開発過程で、スプリントレビューの時間の変更や、タスクの置き方をmonday.comを使って自分たちで自由に決めることができています。
ー開発をする上で特に重視している機能は何でしたか？
タスク自体に持たせる管理項目（ex:GitHubのURL、タスクに番号を付ける）を簡単に作成できるかが決め手でした。他社ツールだと次チームの開発プロセス合わせた項目の追加が出来ず不便だったので、monday.comに変えてからは作業がスムーズになりました。
ー他社ツールではなくmonday.comでアジャイル開発をする理由とメリットを教えてください。
２年前にアジャイル開発を導入しましょうとなったときに、スプリントボードの管理方法を考える中で、monday.comの無料トライアルをへて導入に至りました。
他社ツールでもmonday.comでも、ユーザーストーリー（開発チームメンバーが日常的な作業を行う理由とその背景を記述したもの）のタスク管理方法は人それぞれで、チームによってタスクの管理方法を気軽に変えられるかどうかは、かなり重要でした。
monday.comは、自由にチケットごとに項目の追加や削除を行うことができ、チームが見たい項目を足すことができた点が優れていると思います。日々の仕事をストレスなくできるかどうかが一番大切ですからね。
ーその他重視された点はありますでしょうか？
タスクを変更した際の反映スピードですね。
ー他社ツールはタスクの変更が遅いのでしょうか？
一覧をクリックするとタスクが表示されるのですが、その都度ローディングの表示がされるのがストレスでしたね。他社ツールの画面共有をした際に手元の作業が反映されなかったり、リフレッシュしないと変更が反映されないなど。この点monday.comは更新しなくても、オンタイムで変更をみれるので、無駄なコミュニケーションが起こらないので、リモートワークをする上でmonday.comは最適だと思います。
実際の業務におけるmonday.com活用状況 |
ー現在どのような業務の管理でmonday.comをご利用でしょうか？
他社ツールではタスク間の紐付けはできますが、 タスクの種類（チケット）が複数あり、 ユーザーストーリー を主要タスク（親チケット）にしないとスプリントボード上で関連タスクとして表示されず、その他の欄にまとめられてしまい、タスク漏れが発生していました。
monday.com だと図のようにスプリントボードに並んだユーザーストーリーの下に直感的にサブタスクとして、関連するタスクを紐づけすることができます。
プロダクトの改善点や新規機能などのユーザストーリーを優先順位をつけてストックしているプロダクトバックログや、日々の開発業務で今のスプリントでやるべきタスクの状況を示すスプリントボードとして使用しています。チームによっては使い方が少し異なっていますが、基本的なところは上述の通りです。
monday.comは管理項目が自由に足せるので、項目のタイプもバラエティに富んでおり、関連する仕様へのリンクや、 GitHubのプルリクエストへのリンク、そのタスクのステータスなど、そのチームがタスクに対して必要な情報をカスタマイズしており重宝しています。
個人的には一つのタスクに対して複数の人が割り当て可能である点やタスクの種類をmonday.comのタグ機能で管理していて、「#new_feature」 や「#improvement」のように表現することで、一つの項目に対して複数のタグを紐づけることができる点が良いです。
また、 四半期ごとの目標を定めたボードを作成し、各スプリントボードのタスクの消化具合を集計しており、今期の目標ごとの進捗が一覧できるようにしています。
私自身は現場に入って作業をするエンジニアではないのですが、こういった閲覧可能な進捗のサマリがあると進捗共有の報告会などを行う必要がなくなるので助かります。
最近は、monday.comの「ビュー機能」を使い、特定のタスクのみを「フィルタリング」を用いて抽出して表示させ、その設定を保存できるので、同一の管理画面でも複数の業務を管理することが出来ています。また、スタンドアップの共有時に必要な情報だけ表示するビューの作成なども行っています。
monday.com導入による効果 |
monday.comは、 Slack や GitHub などプロダクト開発に使われる他のツールとの連携機能が強力で、エンジニアたちからはストレスなく自分たちの業務に集中できていると聞いています。ボード間の連携や同一のデータをもとにした異なるビューの作成ができるので、進捗報告は見ればわかる状態になり、より本質的な議論に時間を使うことができるようになりました。
ー小松様、ありがとうございました。
monday.comでは2週間の無料トライアルを提供しています。
企業様ごとに、最適な活用方法を提案させていただいておりますので、monday.comについての質問などはこちらからお問い合わせください。
