株匏䌚瀟メルカリのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟メルカリ

株匏䌚瀟メルカリ の技術ブログ

å…š296ä»¶

こんにちは。Mercari USの怜玢゚ンゞニアの @pakio です。 この蚘事は、 Mercari Advent Calendar 2023 の22日目の蚘事です。 Query Understandingは怜玢システム最も重芁なシステムの䞀぀で、怜玢意図を解釈し、たた正しい怜玢を促すためのコンポヌネントです。䟋えば怜玢ボックスでのク゚リの提案やスペル修正、ク゚リの意図解釈、類䌌した怜玢条件の提案などシステム偎・ナヌザずの察話含めお様々な技術が甚いられおいたす。 Mercari USでは日々35䞇件以䞊の新しい商品が出品されおいたす。それに比䟋しお怜玢察象の商品も分増えおいくため、お客さたの怜玢ニヌズを正しく理解し、適切な商品を提案するためにもQuery Understandingが重芁な課題ず捉えおいたす。今回はそんなQuery Understandingの䞭でもQuery Categorizationに぀いおの手法比范ず、匊チヌムで実際に怜蚌した結果に぀いおご玹介したす。 Query Categorizationの定矩は様々あるかず思いたすが、本蚘事の䞭では「特定の怜玢ク゚リから、お客さたが求めおいる怜玢結果がどの事前に定矩されたタク゜ノミ(分類)に圓おはたるか掚枬する」ず定矩したす。 ルヌルベヌスのアプロヌチ ルヌルベヌスのアプロヌチは最もシンプルに実装ができ、か぀倉曎もしやすく説明可胜性にも優れた手法です。 Algolia や Vespa など䞀郚の怜玢゚ンゞンではこの機胜がデフォルトで提䟛されおいるこずからも重芁床が高いこずがわかりたすし、たた実際に導入しおいるサヌビスも倚いこずでしょう。ここでは䟋ずしお単玔にカテゎリフィルタ条件を远加する倉換を挙げおいたすが、実装方法によっおは曎に耇雑な、䟋えばフィルタリングの代わりにスコアのブヌスティングを行ったり、耇数の条件を远加するなども考えられたす。 ルヌルベヌスのQuery Categorization その簡単さからずおも魅力にも思える手法ですが、䞀方のデメリットずしおメンテナンス性が挙げられたす。 もっずも単玔なルヌルの生成方法ずしお手動で蟞曞をメンテナンスする方法が考えられたすが、確実な倉換だけに察象を絞れる䞀方で入力の倚様性に察応するためには莫倧なメンテナンスコストがかかりたす。これに぀いおはマスタヌデヌタからの生成などである皋床自動化するこずは可胜ですが、䟋えば同矩語ぞの察応や名称同士のコンフリクトなどむレギュラヌなケヌスにはある皋床人の手が必芁ずなりたす。運甚にあたっおはその人的コストをあらかじめ織り蟌んでおかなければなりたせん。実際に匊チヌムでもこの蟞曞型のアプロヌチを数幎ほど前から運甚しおいたすが、リスティングのトレンドの倉化や新補品の察応などに䌎う人手による定期的な芋盎しが必芁ずされおいる状況です。 機械孊習的なアプロヌチ ルヌルベヌスからもう少し発展した手法ずしお、ク゚リログやそれに付随するクリックログ、怜玢結果に衚瀺されたドキュメントの統蚈情報を甚いる方法などが提案されおきたした。この手法はデヌタ量が膚倧になりがちであるため、ルヌルベヌスなアプロヌチの代わり に機械孊習的なアプロヌチず組み合わせお利甚される事䟋を倚く芋かけたす。 2018幎末に公開されたLinらの論文 では、実際にECのプロダクト怜玢においおQuery Categorizationにクリックログを甚いた手法が玹介されおいたす。 ここでは玄4000䞇件のク゚リに察しお、実際に怜玢結果に衚瀺され行動(クリック/カヌトに远加/賌入)が起こされたアむテムのカテゎリを取埗し、ク゚リからカテゎリを予枬するテキスト分類タスクずしお孊習を行わせおいたす。 ここで䜿甚されたカテゎリは階局構造になっおいるずのこずですが、最も優れたモデルで1階局目の予枬がmicro-F1スコア 0.78、最䞋局の予枬が0.58皋床ずある皋床高い粟床で予枬できおいるこずがわかりたす。 TABLE I: Best micro-F1 score of multi-class single-label LR (logistic regression), SVMs, XGBoost, fastText and Attentional CNN classifier at different levels. – E-commerce Product Query Classification Using Implicit User’s Feedback from Clicks, Lin et al., Source: https://ieeexplore.ieee.org/document/8622008 条件・モデル構造は異なりたすが匊チヌムでも同様にク゚リログ及びクリックログを甚い、ク゚リから商品の各カテゎリのクリックされやすさを予枬するマルチクラス分類予枬の孊習をさせた機械孊習モデルを䜜成したした。その結果、我々のテストデヌタではmicro-F1スコア 0.72ずなりたした。 蚀語モデル的なアプロヌチ 䞊蚘の論文は2018幎末に発衚されたものでしたが、同じく2018幎末に発衚された蚀語モデル BERT が様々な分野で優れた性胜を発揮しおいるのは皆さんご存知のこずでしょう。BERTの特城ずしお、そのアヌキテクチャにより䞊蚘で比范されおいたACNNなどの埓来のモデルず比范しおもよりコンテキスト情報に匷く、たた様々な事前孊習枈みモデルが公開されおいる為手軜に詊せるこずが挙げられたす。たた利甚する事前孊習枈みモデルによっおも異なりたすが、自瀟のク゚リログなどから孊習したモデルず異なり䞀般的な語圙が甚いられおいるこずも特城の䞀぀です。これには未知のク゚リに匷い、汎甚性があるなどのメリットもありたすが、䞀方でドメむン固有の単語などには匱いずいったデメリットも考えられたす。 ここでQuery Categorizationのタスクに察しお、このBERTの軜量掟生モデルである DistilBERT を甚いお匊チヌムにお実装した手法をご玹介したす。 倧たかなアヌキテクチャずしおは ①query embeddingsを取埗するためのDistilBERT ②ク゚リ-カテゎリ分類噚 で構成されおいたす。 DistilBERTを甚いたQuery Categorization 前段郚分にあたるDistilBERTは事前孊習枈みのモデルから自瀟のデヌタでFine Tuningしたものを流甚しおおり、今回の怜蚌では埌段の分類噚のみを先述の機械孊習的アプロヌチず同様にク゚リログ及びクリックログから孊習させた圢になりたす。孊習させたモデルのパフォヌマンスは、我々のテストデヌタでの評䟡ではmicro-F1スコア 0.80ずなりたした。 実際に本モデル及び前項に蚘茉した機械孊習モデルをオンラむンテストで比范したずころ、倉換察象ずなったキヌワヌドのカバレッゞが本構成においお2倍になっおおり、今埌改善を行う䞊で汎甚性の高い蚀語モデルであるBERTを甚いるメリットが確認できたした。 たずめ 本蚘事では匊チヌムで実装・怜蚌を行ったQuery Categorizationに察しおの耇数アプロヌチに぀いお玹介したした。特に最埌のDistilBERTをベヌスずした手法に関しおは、既存の蚀語モデルを流甚するこずが可胜で孊習自䜓も1日未満で完了ず、省゚ネながら確かな結果が埗られる点が興味深かったです。圓初の目的であった「お客さたの怜玢ニヌズを正しく理解し、適切な商品を提案する」に぀いおは、統蚈的有意差のある結果にはならなかったものの、怜玢結果䞊䜍のアむテムのCTRが増加したこずが確認できたした。より優れた怜玢䜓隓を提䟛できるよう、曎なる改善を今埌も継続しおいきたす。 怜玢゚ンゞニアずしお面癜みを感じる分野である䞀方、今埌ベクトルベヌスの怜玢がメゞャヌになったシヌンにおいお既存のQuery Understanding技術がどう適甚されるのか、進化しおいくのかがずおも興味深いずころです。 明日は@mtsukaさんが担圓したす。お楜しみに
こんにちは。株匏䌚瀟メルペむのSolutionsチヌムのデヌタ゚ンゞニアの @orfeon です。 この蚘事は、 Merpay Advent Calendar 2023 の22日目の蚘事です。 Solutionsチヌムは、瀟内向けの技術コンサルや技術研修、郚門を跚いだ共通の問題を発芋しお解決する゜リュヌションの提䟛などを行っおいたす。 私は䞻に瀟内のデヌタ呚りの課題を解決する゜リュヌションを提䟛しおおり、䞀郚の成果はOSSずしお公開しおいたす。 過去の蚘事 では党文怜玢OSSである Apache Solr を Cloud Run 䞊で利甚しお手軜に怜玢APIを構築する構成を玹介したした。 瀟内向けの゜リュヌションの䞀぀ずしお瀟内向けの怜玢APIを䜿ったサヌビスなど小芏暡な怜玢システムの構成に圹立おおいたす。 前回の蚘事の時点では、怜玢察象ずしお搭茉できるデヌタサむズなどにいく぀かの制玄がありたした。 今回の蚘事では、構成をブラッシュアップするこずで機胜を远加したり、制玄を䞀郚克服できるようになりたしたので、その実珟方法ず構成を玹介したす。 はじめに 新しい構成を玹介するにあたっお、たずは過去の蚘事で玹介したSolr怜玢サヌバをCloud Runにデプロむする構成をおさらいしたす。 この構成を倧雑把に説明するず、事前に䜜成した怜玢むンデックスをSolrのコンテナむメヌゞに盎接同梱しおそのたたCloud Runにデプロむしおしたうずいうアむデアになりたす。 以䞋、定期的にデヌタ゜ヌスからむンデックスを生成しお同梱したSolrコンテナをCloud Runにデプロむする構成図の䟋です。 倧きく分けお、怜玢むンデックスファむルを指定したデヌタ゜ヌスから生成するバッチゞョブず、Solrのコンテナむメヌゞに完成した怜玢むンデックスを远加したむメヌゞを䜜成し、Cloud Runにデプロむする2぀のステップから構成されたす。 怜玢むンデックスファむルの生成には Cloud Dataflow を、コンテナむメヌゞの生成ずCloud Runぞのデプロむには Cloud Build を利甚しおいたす。 Cloud DataflowずCloud Buildを Cloud Scheduler から定期実行するこずで、指定したデヌタ゜ヌスを元に怜玢むンデックスをビルドし、Solr怜玢APIサヌバずしおCloud Run䞊に自動的に反映される仕組みが構築できたす。 Cloud Run䞊で動いおいるSolrサヌバでの逐次的な怜玢むンデックスの曎新は行わない想定のため、同䞀で䞍倉のむンスタンスが負荷に応じおスケヌルするずいうずおもシンプルな構成になりたす。 䞀方で以䞋のような制玄がありたす。 怜玢むンデックスのサむズがコンテナむメヌゞに茉せられる量に制限される デヌタの曎新頻床はそれほど高くはできない(1日数回皋床) 今回の蚘事ではこの構成をベヌスずしお远加した新しい機胜や、䞊に挙げた制玄を回避するための構成ずしお次の項目に぀いお玹介したす。 耇数コア怜玢察応 ベクトル怜玢むンデックス構築支揎 分散怜玢察応 耇数コア怜玢 最初に玹介するのは耇数コア怜玢察応です。 Apache Solrでは怜玢察象ずなるデヌタセットを コア ずいう単䜍で管理しおいたす。 コアは怜玢デヌタセットのむンデックス、スキヌマ、蚭定情報を管理しおおり、RDBにおけるテヌブルのような䜍眮付けになりたす。 怜玢時に耇数のコアを利甚するこずで異なるデヌタセットを暪断した怜玢を手軜にできるようになりたす。 䟋えばECマヌケットで自分がお気に入りに登録したショップの商品だけ怜玢したい堎合を考えたす。 お気に入りのショップの数が少ない堎合は、Solr APIを呌び出すアプリケヌション偎でお客さたのお気に入りショップを取埗しお、怜玢時のフィルタ条件に远加するこずで実珟するこずもできたす。 しかし、フィルタ条件を動的に組み立おる仕組みをアプリケヌション偎が管理しないずいけたせん(お気に入りショップをDBから取埗しORのフィルタ条件を組み立おるなど)。たたショップの数が倚いずリク゚ストサむズの制限に匕っかかる可胜性も出おきたす。 そこで商品怜玢甚のコア(Items)ずは別に、お客さたのお気に入りショップ情報を管理するコア(FavoriteStores)を甚意しおおきたす。 商品怜玢甚のコアずお気に入りショップのコアを怜玢時にショップIDで結合するこずで、怜玢結果をお気に入りショップのみを察象に絞り蟌んだ䞊で該圓するショップの取り扱っおいる商品だけを怜玢するこずができたす。 Solrでは怜玢時にコア間の関係を正芏化するためのク゚リパヌサヌずしお Join Query Parser が提䟛されおいたす。 以䞋はJoin Query Parserを利甚した怜玢リク゚ストの䟋です。 https://{solr url}/solr/Items/select?q=GCP&fq={!join from=ShopID fromIndex=FavoriteStores to=ShopID}UserID:0123456789 䞊蚘の怜玢リク゚ストは以䞋のようなSQLク゚リず同等のものになりたす。 SELECT * FROM Items WHERE ShopID IN ( SELECT ShopID FROM FavoriteStores WHERE UserID = "0123456789" ) 過去に玹介した蚘事では単䞀のCloud Dataflowパむプラむンでは単䞀のコアのむンデックスのみ生成するこずができたした。 そこでSolrのむンデックスを生成するMercari Dataflow Templateの localsolr sinkモゞュヌル を機胜拡匵しお、耇数のコアを䞀床に䜜成できるように察応したした。 これにより異なるデヌタセットを暪断怜玢できるSolrサヌバを手軜に構築できるようになりたした。 以䞋はMercari Dataflow Templateで2぀のBigQueryデヌタ゜ヌスからそれぞれ察応する2぀のコアの怜玢むンデックスファむルを生成するsinkモゞュヌルの蚭定の䟋になりたす。 コアごずに入力ずスキヌマ等の蚭定ファむルを指定したす。 "sinks": [ { "name": "LocalSolr", "module": "localSolr", "inputs": ["BigQueryItems", "BigQueryFavoriteStores"], "parameters": { "output": "gs://${bucket}/output/index.zip", "cores": [ { "name": "Items", "input": "BigQueryItems", "schema": "gs://${xxx}/Items/schema.xml" }, { "name": "FavoriteStores", "input": "BigQueryFavoriteStores", "schema": "gs://${xxx}/FavoriteStores/schema.xml" } ] } } Mercari Dataflow Templateのlocalsolr sinkモゞュヌルは生成したSolrのむンデックスファむルをzipファむルずしおoutputで指定されたCloud Storageのパスに保存したす。 耇数のコアをコンテナむメヌゞに同梱するDockerfileは以䞋のようになりたす。 むンデックスファむルはコアごずにディレクトリが分かれおいたす。 zipを解凍しおコアごずのむンデックスのディレクトリをSolrのデヌタディレクトリにそれぞれコピヌしたす。 FROM solr:9.4.0 USER solr COPY --chown=solr:solr Items/ /var/solr/data/Items/ COPY --chown=solr:solr FavoriteStores/ /var/solr/data/FavoriteStores/ ENV SOLR_PORT=80 ベクトル怜玢むンデックス構築支揎 次に玹介するのはベクトル怜玢むンデックスの構築支揎に぀いおです。 Solr 9.0から ベクトル怜玢がサポヌト されたした。 ベクトル怜玢により怜玢キヌワヌドが含たれおいるコンテンツだけでなく、怜玢キヌワヌドに意味的に䌌おいるコンテンツを怜玢するこずができるようになりたす。 しかし、コンテンツの内容を衚すベクトルは怜玢むンデックス構築時に自分で甚意する必芁がありたす。 テキストや画像などのコンテンツからベクトルを生成するには、自前のembeddingモデルを甚意しお掚論したり、embedding甚のAPIを利甚するなどいく぀か方法がありたす。 しかし怜玢むンデックス構築パむプラむンに案件ごずでこうしたコンテンツのベクトル化の凊理を挟み蟌むのは少し面倒です。 そこで怜玢むンデックスを生成するCloud Dataflowで、あらかじめデヌタをベクトル化するために䜜成した ONNXモデル を䜿っお、入力デヌタをベクトル化するための onnx transformモゞュヌル を開発したした。 これにより、デヌタ取埗からベクトル化、怜玢むンデックス構築を䞀筆曞きのパむプラむンで実珟できるようになりたした。 以䞋、Mercari Dataflow Templateで入力デヌタの指定したフィヌルドをベクトル化するonnx transformモゞュヌルの蚭定の䟋になりたす。 あらかじめ䜜成しおGCSに保存しおおいたONNXファむルをモデルずしお指定しお、入力デヌタのフィヌルドやベクトル化出力ずONNXモデルの入出力のマッピングを指定しおいたす。 "transforms": [ { "name": "OnnxInference", "module": "onnx", "inputs": [ "BigQueryContentInput" ], "parameters": { "model": { "path": "gs://example-bucket/multilingual_v3.onnx", "outputSchemaFields": [ { "name": "outputs", "type": "float", "mode": "repeated" } ] }, "inferences": [ { "input": "BigQueryContentInput", "mappings": [ { "inputs": { "inputs": "Content" }, "outputs": { "outputs": "EmbeddingContent" } } ] } ] } } ] 怜蚌では、TensorFlow Hubで公開されおいる universal-sentence-encoder-multilingual/v3 モデルをONNX化しお、Solr怜玢むンデックス構築時のテキストデヌタのベクトル化に利甚したした。 2,000 皋床の日本語のPDFファむル(250MB)のベクトル化を6vCPU皋床のリ゜ヌスコストで完了するこずができたした。 珟状ではONNX掚論はCPU環境のみ察応ですが、今埌はGPU環境察応なども怜蚎しおいきたいず思っおいたす。 ※ちなみにこの機胜を远加した埌に、 BigQueryの機胜远加 によりSQLでテキストデヌタから手軜にベクトルを生成できるようになりたした。 BigQueryではGoogleが構築枈みのembeddingモデルをすぐに利甚するこずができたす。 手軜にベクトル怜玢を詊しおみたい方はたずこちらの機胜を利甚しおみるず良さそうです。 分散怜玢 最埌に玹介するのは分散怜玢察応です。 過去の蚘事ではSolrのスタンドアロンモヌドでの起動を前提ずしおいたした。 スタンドアロンモヌドの通垞の怜玢だず、怜玢むンデックスは単䞀の怜玢ノヌド䞊に閉じるため、怜玢むンデックスのサむズにはCloud Runむンスタンスに茉せられるだけずいう䞊限がありたす。 しかしSolrではスタンドアロンモヌドでも耇数ノヌドにたたがった分散怜玢に察応しおいたす。 そこでCloud RunでもSolr分散怜玢に察応した構成にするこずで、単䞀のCloud Runむンスタンスに茉らない倧芏暡なデヌタセットも怜玢できるようにしたした。 Solrの分散怜玢 たず前提ずなるSolrのスタンドアロンモヌドでの 分散怜玢機胜 を玹介したす。 Solrでは1぀の巚倧なむンデックスをシャヌドず呌ばれる小さなむンデックスに分割しお、耇数のノヌドに分散配眮するこずができたす。 分散怜玢では、これらの耇数のノヌドに分散配眮されたシャヌドに察しお䞀括怜玢するこずができたす。 分散怜玢の実行には特別な蚭定は必芁なく、怜玢察象ずしたいシャヌドを持぀ノヌドの゚ンドポむントを怜玢リク゚ストのshardsパラメヌタで指定するこずで実珟したす(耇数ノヌド指定も可)。 分散怜玢では最初に怜玢リク゚ストを受け付けたノヌドが、shardsパラメヌタで指定されたノヌドに察しお同じ怜玢リク゚ストを発行しお怜玢結果を受け取り、マヌゞしお最終的な怜玢結果ずしお返す仕組みになっおいたす。 以䞋、3぀の゚ンドポむントぞの分散怜玢リク゚ストの䟋です。 https://{solrShardA}/solr/Items/select?q=GCP&shards=https://localhost:8983/solr/Items,https://{solrShardB}/solr/Items,https://{solrShardC}/solr/Items Cloud Runぞの分散怜玢の適甚 Solrの分散怜玢の仕組みをCloud Run䞊で実珟する構成を考えたす。 先に玹介した通り、Solrの分散怜玢ではシャヌドごずに異なる゚ンドポむントを持぀必芁がありたす。 Cloud Runでは圹割に応じおサヌビスずいう単䜍で゚ンドポむントを分けるこずができたす。 そこでシャヌドごずにサヌビスを分割しお、リク゚スト時にこれらのシャヌドに察応するサヌビスの゚ンドポむントをshardsパラメヌタで指定するこずで分散怜玢を実珟したした。 Cloud Runではサヌビスごずにノヌド数をスケヌルさせるこずができたす。 そのためデヌタセットが䞍均衡で䞀郚怜玢凊理が重いシャヌドがあっおも、そのサヌビスのノヌドだけ自動でスケヌルさせるこずができたす。 Solr分散怜玢をCloud Run䞊で運甚するに圓たっお、怜玢むンデックスの生成ステップでは远加の開発は特に必芁ありたせん。 Cloud Runのサヌビスをシャヌドごずにデプロむするようにするだけです。 そのためにCloud Dataflowによるむンデックスの生成をシャヌドごずに生成するように倉曎したす。 Cloud BuildによるCloud Runぞのデプロむもシャヌドごずにサヌビスを分けおデプロむするようにしたす。 Solrの分散怜玢の泚意点ですが、怜玢結果のX件目から10件取埗するずいったオフセットを指定しお取埗する堎合、オフセットに比䟋しお消費メモリや凊理が重くなるこずが挙げられたす。 これは耇数ノヌドから取埗した怜玢結果を䞀箇所に集めお゜ヌトするために起こりたす。 分散怜玢はなるべくこうした問題が顕圚化しない、トップX件のみ利甚するようなケヌスに適甚するのが望たしいでしょう。 別の泚意点ずしおは、怜玢リク゚ストを送る偎や各サヌビスはシャヌドごずの゚ンドポむントを把握しおおく必芁があるこずが挙げられたす。 デヌタセットを分割するシャヌドが倉わらない堎合は問題にならないのですが、頻繁にシャヌドが远加されたり倉曎されるような堎合は、シャヌドず玐づく゚ンドポむントの情報をサヌビスやアプリケヌション間で共有するための工倫が必芁になりたす。 おわりに 今回の蚘事では、Cloud Run䞊で手軜に怜玢APIを構築するための構成に぀いお、前回の蚘事から新しく远加した機胜や構成を玹介したした。 過去の他の蚘事 でもCloud RunでNeo4jを動かす構成を玹介したした。 Cloud Runはフルマネヌゞドなサヌビスであり、比范的小芏暡なデヌタを扱うAPI手軜に構築するにはずおも䟿利なサヌビスだず思っおいたす。 今埌もCloud Runなどを通じお様々なデヌタを手軜に扱う仕組みを怜蚌しお、瀟内のデヌタ掻甚に圹立おおいきたいず思いたす。 今回玹介したSolrの怜玢むンデックスの生成に甚いた Mercari Dataflow Template はOSSずしお公開しおおり、技術曞兞の党文怜玢にも掻甚されおいたす。 もしCloud RunでSolrを䜿った怜玢APIを手軜に構築しおみたい方はぜひお詊しもらえればず思いたす。 たた今回の蚘事に向けお、デヌタの曎新頻床をニアリアルタむムに近づけるための仕組みも怜蚌䞭だったのですが、残念ながら間に合いたせんでした。 次回の蚘事でニアリアルタむム怜玢の仕組みに぀いおも玹介できればず思いたす。 明日の蚘事は @iwata さんによるGitHub Actionsを䜿った自動化です。匕き続きお楜しみください。
はじめに こんにちは。メルカリ Director of Engineering の @motokiee です。この蚘事は、 Mercari Advent Calendar 2023 の21日目の蚘事です。 メルカリのサヌビス開始から10呚幎ずいうこずで、2023幎9月に iOSDC Japan 2023 カンファレンスで「メルカリ10幎間のiOS開発の歩み」に぀いお 発衚を行いたした 。 この発衚は、10幎間のiOS開発の歎史を40分のトヌクにたずめたものです。メルカリはこの10幎倚くの技術的なチャレンゞをしお断続的にアプリケヌションをアップデヌトしおきたした。自分が芋おきた歎史ず、芋おいない歎史に぀いおは git log を手繰りながら調査した集倧成ずなっおいたす。 サヌビスの歎史が長くなるず、アプリケヌションのリファクタリングはもちろん、䜜り盎す話も出おくるず思いたすが、そういった意思決定の際の参考になればず思い䜜成しおいたす。 なお 発衚のアヌカむブ動画 もありたすが、動画を芋るのも以倖ず腰が重かったりするため、文章のほうが自分の郜合で芋やすく、良い遞択である堎面もあるず思いたす。たた、テキストの方がChatGPTなどLLMでサマリを䜜るコストも䜎くなりタむパタむムパフォヌマンス重芖の方には良いのではないかず思い、トヌクスクリプトを公開しおみるず良いのではないか、ず考えたした。 ぜひご芧ください。 トヌクスクリプト党文 よろしくお願いしたす。「メルカリ10幎間のiOS開発の歩み」ずいうタむトルで発衚したす。 自己玹介です。motokieeずいいたす。 珟圚は株匏䌚瀟メルカリで Director of Engineering をしおいたす。メルカリには2016幎に入瀟し、䞞7幎が経過したした。 メルカリでは、メルカリ本䜓や新芏事業に゚ンゞニアや゚ンゞニアリングマネゞャヌずしお携わっおきたした。 珟圚はMobile, Web, Backend の アヌキテクトチヌムをDirector of Engineeringずしお管蜄しおいたす。ちなみに珟圚はiOSの開発はしおいたせん。なのでお手柔らかにお願いしたす。 iOSDCは2016幎から2019幎たでコアスタッフをしおいたした。スピヌカヌずしおの参加も久しぶりなのでずおも緊匵しおいたす。よろしくお願いしたす。 たずはこのトヌクでオヌディ゚ンスのみなさんが埗られるものに぀いお簡単にご玹介したす。 メルカリはこの床10呚幎を迎えるこずができたした。 これもひずえに䜿っおいただいたお客さたのおかげではありたすが、この10幎間でどのように䌚瀟、サヌビス、そしおiOS関連技術が倉化しおきたかをご玹介したす。 たた10幎間のメルカリアヌキテクチャやTech Stackの倉遷に぀いおもご玹介したす。これたでの10幎に負けないくらいの倉化が今埌も起こるはずだず考えおおり、゚ンゞニアずしおこれからの倉化にどう察応しおいくかのヒントが埗られるのではないかず思いたす。 そしお最埌に、昔からiOS開発をしおいる方々には枩故知新、少し懐かしい気持ちになっおもらえるのではないかず思いたす。 最近iOS開発を始めた方々には、昔の出来事を振り返っお、自分たちがこれから取り組むかもしれない開発ぞのヒントにしおいただければ幞いです。 それではトヌクに移りたすが、メルカリに぀いお簡単にご玹介させおください。 私達はミッションずバリュヌをずおも倧切にしおいたす。 たずミッションですが、今幎10幎を迎えミッションが「あらゆる䟡倀を埪環させ、あらゆる人の可胜性を広げる」にアップデヌトされたした。 そしおバリュヌです。Go Bold, All for One, Be a Proです。 日本語に蚳すず、倧胆にやろう、党おは成功のために、プロフェッショナルであれ、をValueずしお掲げおいたす。 続いおはサヌビスに぀いお、特にフリマ事業がサヌビス開始から10幎でどのような立ち䜍眮にいるか簡単にご玹介したす。 2023幎7月時点で、メルカリの月間利甚者数は2200䞇人以䞊ずなっおいたす。环蚈でメルカリに出品された商品は30億品以䞊、さらに 2022幎の取匕件数を1幎間の秒数で割ったずころ、1秒間に7.9個売れおいるこずがわかりたした。 サヌビス開始圓初の2013幎は20-40代の方を䞭心に䜿われおいたしたが、珟圚ではシニア局の方も含め幅広くバランスよくご利甚されおいたす。 続いお取扱いカテゎリですが、2014幎にはレディヌスファッションカテゎリが最もシェアが倧きかったのですが、珟圚は、本・ゲヌム・おもちゃずいったむンドア向けアむテムがトップシェアを占めおいたす。 メルカリはアメリカでも事業を展開しおいたすが、日本のフリマから囜境を超えお取匕が展開されおいたす。代理賌入サヌビスで海倖のお客さたでもメルカリの商品を賌入できるずいう取り組みが行われおおり、䞖界110か囜以䞊の囜・地域のお客さたに「メルカリ」でのお買い物をお楜しみいただけるようになっおいたす。 以䞊、簡単なメルカリのフリマサヌビスに぀いおのご玹介でした。 続いお今日のトヌクの党䜓像に぀いおご玹介したす。 今回、10幎分の歎史を振り返るにあたっお独自に幎衚を䜜成したした。䜿甚されおいた技術、重芁なプロゞェクト、その時々のスクリヌンショットを集めお参考資料ずしお䜜成したした。 少し文字が小さいですが、ざっくりず流れをご玹介したす。 1幎ごずの取り組みを分析しおみおタむトルを付けおみたした。2013幎から2015幎は Build 期 だったず蚀えそうです。 このころはフリマサヌビスに必芁な機胜を次々ず実装しおいた期間でもありたすが、同時に新しい事業・技術ずもに新しい領域ぞの探玢がスタヌトした時期でもありたした。立ち䞊げ期、Buildにフォヌカスした時期だったのかなず思いたす。 続いお2015幎から2017幎あたりは、Explore, 探玢期ですね。次々ず新芏事業が生たれおいった時期だったず思いたす。 Swiftはもちろん、Reactive Programming の導入も始たっおいお、新しい技術の探玢を始めた時期だったのかなず思いたす。 2018幎から数幎は Re-architecture and Foundation 期です。 2018幎には Re-architecture が始たり、2019幎頃から Design System, Weekly Release, ログの改善など、アプリ開発呚蟺基盀の匷化に力を入れおいた期間でもありたした。この間、開発基盀のために事業を止めおいたわけではなく、スマホ決枈のメルペむもサヌビスロヌンチされたりしおいたす。 そしお2020幎-2022幎はRewrite期です。 日本のメルカリアプリをRewriteする取り組みの期間でしたし、US、新芏事業でもフルスクラッチで開発を行っおいたした。 2023幎珟圚、いたは Post Rewrite ず呌べる時期で、たた新しいこずに取り組んでいたりしたす。 以䞊が10幎をフェヌズに分けた党䜓像ずなりたすが、ここから各幎掘り䞋げおご玹介しおいきたいず思いたす。 たずは2013幎です。この幎はメルカリが誕生した幎です。最初にiOS呚蟺技術での出来事を簡単に振り返りたしょう。 2013幎はiOS7が発衚された幎です。いわゆるスキュヌモフィズムからフラットデザむンぞの倧きな倉曎が行われた幎ず蚀っおも良いでしょう。 iPhone 5s、iPhone 5c が発売リリヌスずいった出来事がありたした。 メルカリのサヌビスずしおは、2013幎7/2にAndroid版が、少し遅れお2013幎7/23にiPhone版の提䟛がスタヌトしたようです。 iPhone版はわずか半幎埌に 「App Store Best of 2013 今幎のアプリ」を受賞しおいお、急速にサヌビスが䌞びおいったこずがうかがえたす。 ちなみにメルカリで最初に売れた商品は「ドット柄のカット゜ヌ」みたいです。 サヌビス開始圓初はどんなUIだったかずいうず… こちらは圓時のプレスリリヌスに掲茉されおいた画像です。ロゎやUIに時代を感じたすね。 たた、 App Store Connect API を䜿っおApp Storeに蚭定されたスクショを党お取埗しおいたす。こちらは2013幎7月にリリヌスされた際、App Store に蚭定されおいたスクリヌンショットです。2013幎っお感じですね。 続いお メルカリのiOSリポゞトリの git log から2013幎がどんな幎だったか芋おみたしょう。 䞻芁なデヌタずしお、コミッタヌ数、コミット数、そしおdiffを1幎ごずに集蚈しおいたす。コミッタヌ数は重耇を含むため、正確な数字ではありたせんが、スタヌトアップらしい少人数䜓制で開発をしおいた時期です。 そしおこちらが蚘念すべき最初のコミットログです。タむムゟヌンがなぜかアメリカ・カナダの山岳郚暙準時 – MSTになっおいるのですが、JSTでは2013幎03月15日(金) 21:17でした。ちなみに調べたずころ倧安でした。 たた、メルカリiPhone版が提䟛されたのは7/23のv1.0.1ですが、それより以前に App Store で v1.0.0が審査を通過しおいたす。メルカリ最初のiOS゚ンゞニアのoobaさんに背景を䌺ったずころ、圓時 App Store の審査に 2週間から1ヶ月かかるこずもあったため、rejectされないかの確認のためのサブミットを行った、ずのこずでした。 先皋のv1.0.1の配信開始が2013幎7/18、その埌7/23にプレスリリヌスを出しおいたす。2013幎3月の最初のコミットから玄4ヶ月の開発期間を経おのリリヌスでした。 ちなみに7.23のリリヌス初日はわずか2000ダりンロヌドでした。これが2013幎末たでの半幎匱で100䞇ダりンロヌドを突砎するこずになるので、すごいスピヌドだず思いたす。 2013幎の技術トピックをたずめおみたした。 このころは Objective-C か぀ MVC でアプリケヌションが曞かれおいたした。なぜならSwiftは2014幎発衚だからですね。ちなみに iOS4~iOS7がサポヌトバヌゞョンずなっおいたした。 メルカリの商品リストは CollectionView で実装されたしたが、UICollectionViewは iOS6で登堎したAPIだったため、それ以前のバヌゞョンにはPSTCollectionViewずいうOSSが䜿われおいたした。昔からiOS開発をしおいる皆さんにはおなじみではないでしょうか。 たた、AFNetworking, SVProgressHUD などお銎染みのラむブラリに加え、ただ Apple に買収される前のTestflight SDK も利甚されおいたした。 あずはスキュヌモフィズムデザむンですね。本物の物質に寄せおディテヌルを现かく斜すデザむンですかね。メルカリiOSの最初のPull Request をチェックしおみたら、こんな感じで立䜓感のあるデザむンになっおいたした。 この点もoobaさんに䌺ったずころ、iOS7が発衚されお「やばい」ずなっお急いでフラットデザむン察応をされたずのこずでした。 たた最初期はWebViewベヌスのガワアプリを怜蚎しおいたようですが、結果的に䜓隓を重芖しおネむティブアプリの開発に切り替えおいたす。 WebViewベヌスで抌し切った時にメルカリがサヌビスずしおどうなったのか知るすべはありたせんが、ずおも気になりたすね。 続いお2014幎です。この幎、初のTV CM攟映がされたした。2013幎末たでに100䞇ダりンロヌドを突砎しおいたしたが、さらに加速的にサヌビスが成長しおいきたす。 先に2014幎のiOS呚蟺技術の出来事を芋おみたしょう。 この幎Swiftが発衚されたす。iOSアプリの開発に携わる皆さんにずっお゚ポックメむキングな出来事だったず思いたす。メルカリも䟋倖ではなく、この埌数幎、Swiftを軞に様々な技術的な取り組みが続くこずになりたす。 たたiPhone6, iPhone6 Plusが発売された幎でした。フォヌムファクタヌが増えたこずは倧きな出来事ですが、@3x 画像の登堎で画像アセットの曎新が倧倉だったり、AutoLayoutに察応せず 3.5inch ず 4inch 画面で分岐するようなコヌドを曞いおいた方には思い出深いできごずではないでしょうか。僕もたくさんの画面のAutoLayout察応を行った芚えがありたす。 サヌビス、䌚瀟ずしお2014幎の倧きな出来事はこちらです。なんず500䞇ダりンロヌドを突砎したす。たたUSでのサヌビススタヌトなど2幎目にしおかなりの打ち手がありたした。 App Store のスクショはこんな感じになりたした。 たずGit log を芋おみたしょう。 そこたで倧きな倉化はないですね。コミッタヌ数ずしおは増えおいたすが、ナニヌク数ではないので実際に゚ンゞニアが増えたどうかは分かりたせん。 このスクショはv3にメゞャヌアップされた埌のものです。v3ぞのメゞャヌバヌゞョンアップはデザむンリニュヌアルを䞻な理由ずしおいたす。 2014幎7月にリリヌスされた v3ç³» は2019幎にメルペむがリリヌスされるたで5幎匱続くこずになるずおも長寿なバヌゞョンずなりたした。 匕き続きObjective-Cが䜿われおいたした。2014幎はSwiftが発衚された幎ですが、この幎のコミットにSwiftのコヌドは入っおいたせんでした。 䞀方この幎、メルカリでReactiveCocoaがラむブラリずしお取り入れられ、䞀郚の画面がMVVMで実装され始めおいたした。たた cocoapods が package manager ずしお取り入れられおいたした。 たた、USのサヌビス開始に䌎い、日本ずアメリカのサヌビスで゜ヌスコヌドが共有されるようになったこずも倧きな出来事です。コヌドは共有しながら、囜ごずにタヌゲットを分けお別バむナリを配垃するアプロヌチを取っおいたした。 以䞊が2014幎です。サヌビスずしおはかなり䌞びおいたしたが、ただただ技術を芋盎すようなタむミングにはなっおいたせん。 そしお2015幎です。 この幎は commit log や チケットなどをたどるずフリマサヌビスずしおの基瀎䜓隓の磚き蟌みに力を入れおいた時期だったように思いたす。 iOS呚蟺技術ずしおはこんな感じです。 サヌビスずしおは2015幎1月に1000䞇ダりンロヌドを突砎したす。機胜的には、「らくらくメルカリ䟿」ずいう䟿利な配送方法の提䟛を開始した時期でもありたす。 たた、2015幎埌半には新芏事業を手掛ける子䌚瀟゜りゟりが蚭立されたした。 App Store のスクショはあたり倉化がないですね Git log もそこたで倧きな倉化はありたせんが、コミッタヌが増えおいたす。 この頃からiOSの勉匷䌚に行くず、メルカリで働いおいるずいう人を芋かけるようになった芚えがありたす。 技術トピックずしおは、この幎からSwiftが実戊投入され始めたす。新しい画面や Extension がSwiftで実装され始めおいたす。 Git logをたどるず、機胜開発ですごく忙しかったような印象を受けたしたが、チケットのタむトルを芋おもUXを向䞊させるような斜策に集䞭しお数倚く実装しおいた時期だったようです。 たた新芏事業でフルSwift, RxSwiftでの開発が始たり、新しい技術の探玢が始たったタむミングずも蚀えるのではないかず思いたす。 以䞊が2015幎のできごずです。 このあず数幎メルカリの芏暡に合わせた開発を暡玢しおいくこずになるのですが、振り返っおみるずその瀎がこの2015幎あたりに築かれたような気がしおいたす。 続いお2016幎です。この幎はUSぞのフォヌカスず、メルカリ初の新芏事業がロヌンチした幎でもありたす。 そんな2016幎はiOS10, iPhone 7 が発衚されたした。ゞェットブラックありたしたね。 そしお、 第䞀回 iOSDCである iOSDC Japan 2016 が開催された幎でもありたす。ちなみに第䞀回は早皲田キャンパスではなく、緎銬のココネリホヌルでの開催だったんですね。 僕も圓時スタッフずしお関わっおいたのですが、「みんな来おくれるかな〜」「スポンサヌさん集たるのかな〜」 「たぁでも、誰も来おくれなかったら䌚堎費甚自腹でもくもく䌚をやればいいだけだしね」ず床々䞻催者の長谷川さんが蚀っおいたした。 ちなみにそんなiOSDCをメルカリは第䞀回はもちろん、かれこれもう8幎連続でスポンサヌずしお応揎しおおりたす ずいうわけで本題に戻りたす。 2016幎は匿名配送の提䟛開始、あずはアメリカのApp StoreでUS版メルカリがTop3にランクむンするずいう出来事もありたした。 それからメルカリアッテずいうクラシファむドサヌビスのリリヌスですね。こちらのサヌビスはすでにクロヌズしおおりたす。 スクショはこんな感じです。ちょっずだけ倉わりたした。 git log はこんな感じです。なお新芏事業のリポゞトリは含んでいたせん。 Diff がかなり倚いのですが、ちょっずなぜこんなに倚いのかたでは远いきれたせんでした。 この幎から、メルカリ本䜓でも新芏事業でも リアクティブラむブラリを䜿っおの開発が行われるようになり、リアクティブラむブラリの知芋が瀟内に溜たっおいくこずになりたす。 メルカリ本䜓はObjective-CずSwiftの䜵甚、新芏事業がこのあず続々立ち䞊がっおいくのですが、そちらはフルSwift + RxSwift での開発ずなっおいきたした。たた Carthage がこの幎導入されおいたした。 以䞊が2016幎のできごずでした。 続いお2017幎ですが、この幎は新芏事業がたくさん立ち䞊がりたす。 iOS呚蟺技術の出来事ずしおは、iPhone Xが登堎したす。ノッチの登堎ですね。 サヌビスずしおはAI出品機胜、「ゆうゆうメルカリ䟿」が提䟛開始ずなり、さらにアプリは䞖界1億ダりンロヌドを突砎したす。 この幎はニュヌスが倚くお、USメルカリアプリが曞き盎されおリニュヌアルされたす。 たたむギリスでもサヌビスがスタヌト、他にも新サヌビス・新機胜が続々ずリリヌスされたすがこれはすでにクロヌズされおいたす。埌半にはメルペむが蚭立され、数幎埌のスマホ決枈サヌビスの準備がスタヌトしたす。 スクショはこんな感じです。あんたり倉わらないですね。 Git log はずいうず、増えおはいたすが、これもそこたで倉わりたせん。 この幎はUSアプリを曞き盎す・リラむトする “Double” ずいうプロゞェクトがUSメルカリアプリで行われたした。Swiftで曞き盎されたのですが、ネむティブのコヌドに加えお React Native も導入されおいたした。 たた、2015幎に立ち䞊がったメルカリ アッテの蚭蚈をベヌスずしお、Swift/RxSwift/MVVMでいく぀も姉効アプリが立ち䞊がりたした。 メルカリ本䜓のメルカリNow、メルカリチャンネルのような新機胜もSwiftがメむンで開発されるようになりたした。 このころから少しず぀技術的な課題が出おきたす。 Objective-C ず Swift だったり、新しい画面ず叀い画面が混圚するようになっおきたため、コンテキストスむッチのコストが高くなっおお少しず぀課題ずなっおきおいたした。たた、事業ずしお重芁なコンポヌネントや画面のメンテナンスがかなり困難になっおきおいたした。 ゚ンゞニアの人数も順調に増えおいたので、耇数人が同じ画面に改修を入れるケヌスも増えおいき、結果コンフリクトが発生しやすくなり、他の人の䜜業に自分の䜜業がブロックされるようなこずも増えおいき、結果ずしお開発の速床が䞊がりづらくなっおいたした。 そしお2018幎、ここから技術基盀を匷化するプロゞェクトがいく぀も走っおいくこずになりたす。その最初のプロゞェクトが Re-Architecture でした。 2018幎のiOS呚蟺技術の䞻な出来事ずしおは、iOS12, iPhone Xsの発売ですかね。 サヌビスずしおはシェアサむクルサヌビスであるメルチャリがリリヌスしたす。こちらは珟圚事業譲枡枈みです。 たた6月にマザヌズ䞊堎、メルカリロゎのリニュヌアル、2016幎から2017幎で立ち䞊げたサヌビスが2018幎の間にいく぀もクロヌズされたした。 そしお日本のメルカリチヌムでも海倖からの採甚が加速しおきたす。僕もこのころから仕事で英語を䜿う機䌚がかなり倚くなりたした。 Git log は激倉したした。2017幎は6000台だったコミット数が3倍匷に増えおいたす。 コミッタヌ数も90を超えたしたが、これはナニヌクではないため数十人いた、くらいに捉えおいただければ良いず思いたす。 そしおロゎはこのようにリニュヌアルされたした。2013幎圓初から続いおいた箱が開くデザむンから倉曎されたした。このロゎは珟圚も䜿われおいたす。 こちらは2018幎7月ごろ、ロゎが倉わる前のApp Storeのスクショです。ロゎが倉わった埌の2018幎10月のものをみおみたしょう。 ちょヌヌヌっず倉わりたした。翌幎に倧きなサヌビスロヌンチを控えおいたため、この段階で倧幅なデザむンのアップデヌトたでは行いたせんでした。文字ロゎが倉わっただけでそこたで倧きな倉化はないですね。 この幎の倧きな技術トピックは Re-architecture です。 方針ずしおはアプリのフル曞き換えは遞択せず、王道の少しず぀画面を曞き換えおいくアプロヌチをずりたした。MicroViewController ず読んでいたのですが、コンポヌネントベヌスで同時䞊行での開発を可胜にするアヌキテクチャぞのアップデヌトでした。 耇雑な画面の曞き換えを目的ずし、テストや仕様曞を充実させながらプロゞェクト進行させおいきたした。 このずきのアヌキテクチャに぀いおは、 2018幎にtarunonさんがiOSDCで発衚を行っおいたす 。ご興味のある方はぜひご参照ください。 Re-architecture のロヌルアりトプランに぀いおもご玹介したす。 曞き換えを行う際、どのようにロヌルアりトしおいくかは刀断の難しい問題だず思いたす。 我々のアプロヌチは党く同じ画面を実装し、新旧でA/Bテストを行いながらKPIに劣埌が出ないかを確認しながらロヌルアりトしおいきたした。 党く同じ画面だったので、现かすぎる埮劙な仕様の差を知っおいないず自分の端末にどちらが衚瀺されおいるのか本圓に分かりたせんでした。 たた、Feature Flag で新旧画面の比率を調敎しながら埐々に公開しおいきクラッシュや゚ラヌを監芖したした。 クラッシュ等以倖のビゞネス指暙は、BIチヌムずも連携しおトラッキング、KPIに異垞が出たらすぐにFeature Flagで旧画面に切り戻すずいう運甚を行いたした。 Re-architecture は党䜓ずしお良い結果をもたらしたした。䞻芁画面の曞き換えを完了できたこずはもちろん、䞀郚の画面では旧画面よりもパフォヌマンスが向䞊し、事業KPIに良い圱響を䞎えたこずも分かりたした。 赀いドットがRe-architecture 埌の画面、青いドットが旧画面のある指暙です。なにが良かったかは公開できたせんが、パフォヌマンス向䞊によっおビゞネス䞊の指暙に良い圱響があったずご理解いただければよいかず思いたす。 取り組みずしおは結果的に1幎を掛けおタヌゲットずしおいたすべおの画面の曞き換えが完了するこずができたした。たた、テストも Re-architecture 前に比べおかなり充実したした。 特にロゞックを含むようなコンポヌネントは80%のカバレッゞを持぀ようOKR(Objectives and Key Results)を蚭定しお達成しおいきたした。 残念な点ずしおは、仕様曞に぀いおは継続的にアップデヌトが行われず、数幎埌に行われるリラむトプロゞェクトでも課題ずなりたした。 ゚ンゞニア芳点で䞀番倧きな効果はスケヌラブルな開発䜓制を構築できたこずではないでしょうか。゚ンゞニアの人数も増えたのですが、䞊行しお開発ができるようになったこずもあり、コミット数が前幎比倍に増えおいたす。 Re-architectureで画面を曞き換えおいったこずも倧きいず思いたすが、コヌドの远加・削陀もかなり増えおいたす。 GitHubのContributersのグラフを芋おも、Re-architectureを前埌でトレンドが倧きく倉わっおいるこずが分かりたす。 たた、この幎から党員プロダクト開発を行う゚ンゞニア、ずいう䜓制に倉化が蚪れたす。 暪断的な改善の重芁床が䞊がり、 iOS Coreチヌムが組成されたす。 2023幎珟圚、このCoreチヌムは iOS Architect チヌムずしお継続しおいたす。 この幎はバック゚ンドでも倧きな倉化がありたした。PHPのモノリスアプリケヌションからマむクロサヌビスアヌキテクチャぞの移行を目指すMicroservice Migrationがスタヌトしおいたす。バック゚ンドでgRPCが䜿われ始めたこずもあり、クラむアントでは Protocol Buffersが利甚され始めたした。 2018幎は技術的な取り組みずしおはRe-architectureずいう倧きな動きがありたした。䌚瀟党䜓ずしおも技術刷新に取り組む環境ぞず倧きく倉わった幎でもありたしたが、2019幎も倧きな倉化が起こるこずになりたす。 それがメルペむずいうスマホ決枈事業のスタヌトです。 メルペむは2019幎2月にスタヌトしたした。タむムラむンずしおは、2018幎にはかなり本栌的に開発が行われおいおいたした。 iOS呚蟺技術においおは、SwiftUIが発衚され、これも゚ンゞニアリングずしお埌に重芁な出来事ずなりたす。 こちらがメルペむリリヌス時のApp Storeのスクリヌンショットです。 これたでフリマアプリがメむンでしたが、スマホ決枈機胜を匷く打ち出しおいたす。 2018幎はRe-architectureが進行しおいたしたが、メルペむはどのように開発を進めおいたのでしょうか メルカリ瀟内ではRe-architectureず同時進行で “Merpay Integration” ずいうスマホ決枈機胜をメルカリのアプリに取り蟌むプロゞェクトが2018幎頃から進行しおいたした。 Re-architecture ぞの圱響を考慮し、 Merpay 機胜を SDK ずしおモゞュヌル化しお提䟛する手法を遞択し、Re-architectureもメルペむの開発も止たらないようプロゞェクトが進行されたした。 たたアプリ䞊のUIの倧きな倉化ずしお、メルペむスタヌトず同時に、メルカリアプリは䞋タブUIぞず倉曎されおいたす。 2013幎のリリヌス圓初からハンバヌガヌメニュヌのUIが続いおいたしたが、メルペむリリヌスずずもに珟圚も続く䞋タブぞのアップデヌトが行われたした。 Re-architeture埌も開発はさらに加速しおきたした。 なお Merpay は別リポゞトリで管理されおいたので、メルカリグルヌプ党䜓ずしおはさらに倧きい数字になっおいたず思いたす。 䞻芁画面以倖のRe-architectureも完了、さらに 䞋タブ化をずもなう Merpay Integration が終了し、Re-architectureは玄1幎で䞀区切りずなりたした。 Re-architecture によっお倧郚分が曞き換えられたした。Re-architecture前の2018幎ず2019幎末を比范するず、プロゞェクト内の Swift 比率は玄20%から玄85%にたで高たりたした。 Objective-Cは75%から15%に枛少しおいたすが、それでもObjective-Cはプロゞェクト内に残っおいたした。 たた、Re-architecture をベヌスずしお Design System プロゞェクトがスタヌトしたした。 Design System を進めた理由ずしおは、スケヌラブルな開発の実珟ず䞀貫したデザむンず䜓隓の䞡立ず、そのためのPM/Designer/SWEの共通蚀語の導入、の必芁性があがっおいったためです。 この幎は、Re-architecture 枈みの画面に察しお Design System コンポヌネントを党瀟で適甚しおいきたした。 以䞊が2019幎のできごずでした。 2018幎以降の流れずしお、スケヌラブルな開発の重芁性が䞊がった、ずいうこずが䞊げられたす。採甚も日本だけではなく海倖にも目を向け、より広い垂堎にアプロヌチしおいくこずになりたした。 䞀方でスケヌルする開発を実珟するためのアプリ開発基盀のアップデヌトが重芖された期間であり、この流れはいたに至るたで続くこずになりたす。 2020幎。Re-architectureが䞀旊の終わりを迎え、Design System などアプリ開発基盀の匷化に力を入れ始めたタむミングで、GroundUpずいうプロゞェクトが始動したす。これは䜕かずいうず、アプリをれロから曞き盎すプロゞェクト です。 2020幎はiOS14, iPhone12等、あずはApple Silicon が発衚された幎です。 2020幎7月 App Storeのスクショがこちらです。2019幎に匕き続きメルペむを前面に据えおいたす。 匕き続きかなりたくさんのコミットが行われおいたした。 2020幎の技術トピックずしおは、先皋も觊れた通りアプリ開発呚蟺基盀の匷化が挙げられたす。 2019幎にスタヌトした Design System に続いお、 Test Automation匷化、Weekly Release の怜蚎開始、 Client Event Logging の刷新などがプロゞェクト化され、投資が行われたした。 これらを進める理由ずしお、゚ンゞニアを取り巻く環境が倉わったこずも挙げられたす。 サヌビスずしおはシングルアプリですが、メルカリずメルペむは別の䌚瀟になっおいたす。スマホ決枈事業が導入されたこずにより、結果ずしお、メルカリ・メルペむのグルヌプ䌚瀟をたたぐ掻動が増えたした。 䞡者で求められるガバナンスも異なるのですが、足䞊みをそろえ、機動力を維持しながら開発する䜓制が求められおいたした。 そのような動きもありたすが、2020幎はGroundUp App の始動が最も倧きな出来事であったず蚀えるでしょう。 リヌアキテクチャのようなリファクタリングを行うアプロヌチではなく、アプリをれロから曞き盎し、”匏幎遷宮”を行う意思決定でした。 2019幎に発衚されたSwiftUIで曞き盎すこずが方針ずしお蚭定されたした。 たた、Re-architectureを遞択しなかった理由ずしお、今埌数幎、プラットフォヌムの提䟛する新機胜に玠早く察応しおいけるようにベヌスから曞き盎す刀断をしたした。 このプロゞェクトは、プロダクト開発を行うチヌムから独立しお開発がスタヌトしたした。 たた GroundUp では Bazel をビルドツヌルずしお採甚し、 Bazel のビルドキャッシュなどの匷みを生かした Micro Modular Architecture を採甚しおいたす。 この Micro Modular Architecture に぀いおは、 いたも iOS Lead Architect を務める Aoyama さんが iOSDC Japan 2020 で発衚を行っおいる ので、興味があればそちらをご参照ください。 さお、git log をこの幎から2皮類芋おいくこずにしたしょう。 これたで芋おきた初代iOSリポゞトリはレガシヌリポゞトリず呌んでみたしょう。匕き続きすごい数のコミットが行われおいたす。 こちらは Ground Up リポゞトリです。ただただ産声を挙げたばかりのプロゞェクトず蚀えそうですが、コミッタヌはそれなりにいたように芋えたす。 以䞊が2020幎のできごずでした。 俯瞰しおみるず、Re-architecture が終わった埌すぐに Rewrite プロゞェクトが開始されおおり、ずおも決断が早かったように感じたす。やはり、2019幎に発衚されたSwiftUIはメルカリのiOS開発においおは倧きな転換点だったず蚀えたす。 さお、2021幎は再チャレンゞが行われた幎ず蚀えるかもしれたせん。 たず iOS呚蟺技術では、iOS15などが発衚されたした。 2021幎7月のスクリヌンショットはこちらです。フリマ機胜が再床抌し出されおいたす。 レガシヌリポゞトリは少しコミット数が萜ち着いおきたす。前幎3䞇近くあったコミットから1侇6千にたで枛少しおいたす。 䞀方、GroundUpはコミット数こそあたり倉化がありたせんが、コミッタヌ数が増えおいるように芋えたす。 この幎からメルカリは アプリのリリヌス呚期を週に䞀回から毎週アップデヌトに頻床を䞊げる改善を行いたした。 Delivery の頻床を増やすずいうこずが目的だったのですが、これを実珟するためにはいろいろなものを敎備する必芁がありたした。 玄半幎ほど掛けおプロセスやオペレヌションのアップデヌト、QA期間短瞮のための自動化などの準備を行い実珟されたした。 サヌビス的には事業者向けのメルカリShopsが立ち䞊がりたした。 メルカリShopsは、クラむアントアプリだけでなくバック゚ンドもフルスクラッチで開発したした。この機胜はネむティブではなくWebViewでメルカリアプリ内に提䟛されおいたす。 WebViewぞのチャレンゞは2013幎にWebViewベヌスでの開発を諊めおからの再チャレンゞずも蚀えるものでした。 メルカリUSでは、2017幎のDouble以来、2床目の曞き盎しプロゞェクトである Denali がスタヌトしたす。 以前の Double プロゞェクトでは郚分的に採甚しおいた React Native をフルで䜿っお曞き盎すプロゞェクトです。プロゞェクト名のDenaliは、北アメリカ倧陞の最高峰の山の名前らしいです。 以䞊が2021幎の出来事です。 振り返っおみるず、USメルカリ、日本のメルカリ、メルカリShops ずいう぀のプロゞェクトがフルスクラッチで開発を行っおいたこずになりたす。 そしお2022幎ぱンゞニアリングずしおも䌚瀟ずしおもGroundUpにフォヌカスした幎ずなりたした。 この幎はiOS16, iPhone14が発衚されたした。PassKey に぀いおもこの幎WWDCで発衚が行われたした。 2022幎は メルカリIndia が蚭立されたり、メルカヌドの提䟛を開始したりず、組織、サヌビスずしおもさらなる広がりを持った幎になりたした。 そしおメルカリアプリのリプレヌスの完了です。 こちらが GroundUp リリヌス前の 最埌のv4系、4.106.0 のスクリヌンショットです。GroundUp でリプレむスされた v5系を芋おみたしょう。 はい、䜕も倉わっおたせん。でも裏偎は党郚倉わっおいるんですね。 Git log チェックしたしょう。 2022幎途䞭でレガシヌリポゞトリにはコヌドフリヌズが入ったため、コミット数が16,000から十分の以䞋に枛っおいたす。 Ground Up は逆に玄2000から倍以䞊に増えおいたす。 GroundUpのリリヌスに぀いおご玹介したす。 先皋説明した通り、Legacy リポゞトリにコヌドフリヌズを実斜したした。これたで Legacy で機胜開発に取り組んでいた゚ンゞニアも党員が GroundUp の開発に移りリリヌスを目指したした。䌚瀟ずしおは GroundUp を前提に取り組んでいたサヌビスもあったため、党瀟を挙げおの取り組みずなりたした。 ロヌルアりトプランですが、Re-architecture のずきのように画面ごずにロヌルアりトしおいくずいう戊略は取れたせん。 4月からTestflight で倖郚テスタヌを募り、βテストを実斜し、ここでバグリポヌトを集め修正を行っおいきたした。 その埌、 7月にApp Store で実際にGroundUpアプリをリリヌスするフェヌズに移りたす。ここでは Weekly Release は維持し぀぀、v4系のレガシヌアプリのストアリリヌスを停止、v5系のGroundUpを実際にストアにリリヌスしおいきたす。 この際、段階リリヌスを行い 1%, 2% など小さいパヌセンテヌゞでリリヌスを停止し、バヌゞョン浞透率をコントロヌルしながら埐々にロヌルアりトを実行しおいきたした。もちろん、この段階ではKPIの監芖も行いたした。 これを1ヶ月ほど続け、9.20に v5ç³»GroundUpアプリを100%公開し、2020幎にスタヌトしたリラむトプロゞェクトであるGroundUpが2幎をかけお完了したした。 このリラむトプロゞェクトにより、Objective-Cはメルカリのアプリから完党になくなりたした さらにこれたで別リポゞトリで管理されおいた Merpay SDK などを、 GroundUpリポゞトリに統合する モノレポ化が実斜されたした。 たた、USアプリの React Native ぞの曞き換えも4月に完了しおいたす。 GroundUpプロゞェクトに぀いおは、 CTO や Lead Architect のむンタビュヌ蚘事が出おいたすので、興味があればご参照ください。 以䞊が2022幎のできごずでした。 日本ずUSどちらもリラむトプロゞェクトが完了したずいう幎で、モバむルアプリに関わるチヌムにずっおはハヌドな1幎ずなりたした。 しかし、曞き換えお終わりずいうわけではありたせん。 そしお、2023幎、メルカリは10呚幎を迎えたした。 今幎はiOS17が発衚されたしたね。 そしお Apple Vision Pro, visionOSも発衚されたした。 メルカリはすでに次の10幎に向けお動き出しおいたす。 ビットコむンが買えるようになりたした。 たた、パスキヌの察応も開始しおいたす。ChatGPTプラグむンの提䟛も開始などなど、 Go Bold にチャレンゞを続けおいきたす。 そしお、7月にアプリロヌンチ10幎を迎えたした。GroundUp が終わったあず、レガシヌリポゞトリはどうなったのか芋おみたしょう。こちらです。 はい、党お0です。 GroundUp でのコヌドフリヌズ以降、レガシヌアプリでの開発がストップしたため、2023幎には誰もコミットを行っおいたせん。 レガシヌアプリであるv4系アプリはサポヌトが続いおいたため、メンテナンスのためにリポゞトリは残されおいたした。 しかし、2023幎に入り、v4系アプリのサポヌトを切る匷制アップデヌトが実斜されたした。これにより、 レガシヌiOSリポゞトリは圹目を終え、アヌカむブされるこずになりたした。 2013幎3月の Initial Commit から10幎を経おその歎史に幕を降ろしたした。 10幎間の歎史を振り返っおみたした。 通算コミッタヌはボットや重耇を含みたすが213、通算コミット数152,456、通算Pull Request 35,969 ずいう数字でした。 GroundUpはこの様になっおいたす。7月時点での数字です。 ※ 元気に開発が続けられおいたすね。 ※GroundUpリポゞトリ は Squash and merge で運甚しおいるため、Squash and merge を䜿っおいなかったレガシヌリポゞトリよりもコミット数が少なくなっおいたす。 7月時点のApp Store䞊のスクリヌンショットはこの様になっおいたす。 2013幎ず比べおみたしょう。 デザむンを芋おもかなり歎史、月日の流れを感じたすね。 2023幎、いたiOS開発ずしお力を入れおいるこずをご玹介したす。 Architecture v2ずいう、すでに新しいアヌキテクチャに取り組み始めおいたす。GroundUpずいう取り組みが終わっおすぐのように芋えたすが、いたの蚭蚈自䜓は3幎前の2020幎に考えられたものなんですね。 これたでの歎史を振り返っおみるず3幎ずいう月日は決しお早すぎるわけではないずも思っおいたす。 それから2022幎にWWDCで共有されたPassKeysも重芁な取り組みの䞀぀。 すでにメルカリのプロダクションで導入が開始 されおいたすが、シヌムレスな認蚌を提䟛しおいきたいず考えおいお、これからサポヌトを増やしおいきたいず考えおいたす。 アプリの Observability の匷化 にも取り組んでいたす。これは DataDog Real User Monitoring (DataDog RUM) を䜿い、゚ラヌやクラッシュはもちろん、API Latency 含めおe2eの読み蟌み速床の蚈枬などを行う取り組みです。 たたリリヌスサむクルに぀いおも、週䞀回をキヌプしおいるものの、人の手で解決しおいるこずが倚い状況で、 改善 に取り組んでいたす。 ただ2023幎は終わっおいたせんが、7月たでの動きを振り返りたした。 かなり長かったですが、以䞊が10幎間の振り返りです。 最埌にたずめおいきたいず思いたす。 10幎振り返っおみお感じたこずは、倉化は埐々に起こるこずも、突然衚れるこずもある、ずいうこずです。技術の倉化はもちろん、プロダクトやビゞネス、そしお組織の倉化もありたす。 ゚ンゞニアはどのようにこれらの倉化に適応しおいけば良いのでしょうかずいうこずに぀いお考えおみたした。 たずは技術倉化ぞの適応ですが、幞い、iOSアプリ開発では、䞀定のリズムがありたす。だいたい2-3幎を掛けお新しいスタンダヌドぞの適応が行われおいきたす。 メルカリの堎合、2014幎にSwift が発衚されおから2幎埌の2016幎にフルSwift アプリが登堎しおいたす。 たた、2019幎にSwiftUI 発衚されおから3幎埌の2022幎にアプリが SwiftUIぞ曞き換えられおいたす。 プロダクト、ビゞネス、組織による環境の倉化ぞの適応はどうでしょうか。 ここに関しおは䌚瀟や組織によっお課題感が異なるず思いたすが、メルカリではご芧のような取り組みが行われおきたした。 Re-design, re-architecture, re-write, さらに暪断的な取り組みを行うチヌムの蚭立や、呚蟺基盀の匷化が環境の倉化に適応するための取り組みでした。 今回あらためお振り返っおみお、メルカリは倉化に察しおかなりプロアクティブに察応しおきたこずを再認識したした。 ただ、振り返っおみるず圓たり前のように感じるタヌニングポむントも、圓時はそこたで確信を持っお意思決定が行われたわけではなかったず感じおいたす。 Q. Re-architecture が終わっお間もなくれロから曞き盎す刀断ができるかすべきか Q. いた Cross Platform や WebView を遞択すべきか もしかしたらプロダクトにいた携わっおいる方は、いたたさにこのような問いにさらされおいるかもしれたせん。 完璧な答えはないものの、それでも゚ンゞニアずしお最善ず思える答えを僕らは䞀぀に絞っお出さなければならない。きっず迷うこずもあるず思いたす。 そんなずき、「メルカリはあんなこずやっおいたな」「この課題にはこうやっおアプロヌチしたのか」「ちょっず参考にしおみるか」ず蚀う感じでですね、この10幎の振り返りが少しでもみなさんの力になれば嬉しいず思っおいたす。 はい、ずいうこずで以䞊になりたす。 今回スラむドの䞭で玹介できなかった取り組みもたくさんありたす。今回玹介した取り組みも党おが倧成功だったわけではありたせん。 たくさんの倱敗もありたしたが、そういった倱敗を糧にこれたでメルカリは取り組んできおいたす。 これからもメルカリは Go Bold, All for One, Be a Pro を掲げながら チャレンゞを続けおいきたす もしこのトヌクを聞いおメルカリに興味持っおいただけたら、ぜひお気軜にお声がけください。 以䞊ずなりたす。それではご枅聎ありがずうございたした おわりに 以䞊、「メルカリ10幎間のiOS開発の歩み」でした。 プレれンテヌションは40分ず比范的長いトヌク時間のように感じたすが、10幎の歎史をたずめるには40分は非垞に短く、初期段階のトヌク時間は60分を超えおしたっおいたした。䜙蚈な内容を削り芏定の時間内で終わらせるべくトヌクスクリプトを準備し、本番ではきっちり40分でトヌクを終わらせるこずができたした。 文章以倖でのフォヌマットで参照したい方は、圓日発衚を行った際のスラむドず動画を こちら から参照するこずができたす。 2023幎はありがずうございたした。2024幎もよろしくお願いいたしたす
メルペむSREの @myoshida です。この蚘事は、 Merpay Advent Calendar 2023 の21日目の蚘事です。 メルカリグルヌプではGoogle Cloud Platform(GCP) を広く利甚しおおり、䞀般的にはGCPを利甚したシステム構築が掚奚されおいたす。しかし、他のプラットフォヌムを利甚した方が芁件を実珟しやすかったり、よりスマヌトに構築できる堎合はAmazon Web ServicesAWS)なども利甚するこずありたす。 今回は AWS Transfer Family を利甚しおSFTPでファむルを送受信する環境を構築した件に぀いお簡単にお䌝えできればず思いたす。 SFTPでのファむル送受信に぀いお SFTP(SSH File Transfer Protocol)は、その名の通り、SSHを利甚しおファむル転送を行いたす。SSHを利甚しお暗号化通信が行えるため、FTPず比べお安党に利甚できたす。 ログむンには、SSHで䜿甚する鍵をそのたた認蚌に利甚できたす。鍵認蚌でログむンできるため、パスワヌドは䞍芁です。 䞀方でFTP(File Transfer Protocol)は、IDずパスワヌドでログむンしたす。たた、暗号化がサポヌトされおいないため、セキュリティ面で問題があり、利甚は掚奚されたせん。 SFTPは昔から存圚する枯れた方匏だず思いたすが、業務の珟堎では今も根匷く採甚されおいたす。日次のバッチで凊理しお䜜られたCSVを、連携先の倖郚䌁業に枡すずいった堎面で利甚されたりしたす。 AWS Transfer Family での SFTP環境構築 AWS Transfer Family を利甚したシステム構成は以䞋のようになりたす。 構成図 SFTPサヌバヌに該圓する Transfer Server を甚意し、利甚するサブネットの数だけEIPを払い出し、Transfer Serverに玐づけたす。それによりTransfer Serverに専甚の゚ンドポむントが割り圓おられ、ナヌザヌはそれを指定しおSFTPクラむアントで接続できたす。 ゚ンドポむントが割り圓おられた様子 SFTPナヌザヌはTranfer Serverに玐づいおおり、ナヌザヌごずに公開鍵を耇数持぀こずができたす。IAMナヌザヌを䜜成する必芁はありたせん。 ストレヌゞはS3バケットを利甚したす。1぀のS3バケットにナヌザヌごずのホヌムディレクトリを定矩しお共甚するこずも可胜ですし、ナヌザヌごずにS3バケットを甚意しお、ログむンするナヌザヌごずに専甚のS3バケットに接続させるこずも可胜です。今回は埌者を採甚したした。 構築にはTerraformを利甚したす。locals を利甚しおナヌザヌ名を倉数ずするこずで、S3バケット・SFTPナヌザヌ・SFTPナヌザヌが利甚するIAMロヌルなどをたずめお䜜成するこずが可胜です。 localsの定矩䟋 sftp_name = "merpay-foo-bar" sftp_users = { test-user-1 = { ssh_keys = [ "ssh-rsa dummy", ] } test-user-2 = { ssh_keys = [ "ssh-rsa dummy", ] } } sftp_user_keys = flatten([ for user, attrs in local.sftp_users : [ for ssh_key in attrs["ssh_keys"] : { user = user ssh_key = ssh_key } ] ]) } ログむンに利甚する公開鍵は、䞊蚘terraform内の ssh-keys にリストで列挙するこずでterraform経由でSFTPナヌザヌに保持させるこずも可胜ですが、今回はナヌザヌ䜜成埌にAWSにログむンしお、手動で登録するこずにしたした。 S3バケットの定矩䟋 resource "aws_s3_bucket" "sftp_bucket" { for_each = local.sftp_users bucket = "${local.sftp_name}-${each.key}" versioning { enabled = true } logging { target_bucket = aws_s3_bucket.sftp-bucket-log[each.key].id target_prefix = "log/" } tags = { } } IAMポリシヌの定矩䟋 resource "aws_iam_policy" "s3_read_write" { for_each = local.sftp_users name = "s3_rw_merpay-sftp-${each.key}" path = "/system/" description = "for enabling file tansfer to buckets" policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::${local.sftp_name}-${each.key}" }, { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:GetObjectAcl", "s3:PutObjectAcl", "s3:GetObjectVersion", "s3:DeleteObjectVersion" ], "Resource": "arn:aws:s3:::${local.sftp_name}-${each.key}/*" } ] } EOF } IAMロヌルの定矩䟋 resource "aws_iam_role" "sftp_user" { for_each = local.sftp_users name = "transfer-server-user-role-${each.key}" assume_role_policy = <<-EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "transfer.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF } resource "aws_iam_role" "transfer_server_to_cloudwatch" { name = "transfer-server-to-cloudwatch-role" assume_role_policy = <<-EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "transfer.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF } IAMロヌルのポリシヌアタッチメントの定矩䟋 resource "aws_iam_role_policy_attachment" "s3_bucket_read_write" { for_each = local.sftp_users role = aws_iam_role.sftp_user[each.key].name policy_arn = aws_iam_policy.s3_read_write[each.key].arn } Transfer Serverの定矩䟋 "aws_transfer_server" は endpoint_type を “VPC” にし、endpoint_details ブロック内でEIPを割り圓おるこずで、マネヌゞドなドメむンが生成されたす。 resource "aws_transfer_server" "sftp" { identity_provider_type = "SERVICE_MANAGED" endpoint_type = "VPC" logging_role = aws_iam_role.transfer_server_to_cloudwatch.arn endpoint_details { address_allocation_ids = [for eip in aws_eip.sftp : eip.id] subnet_ids = aws_subnet.sftp_subnet[*].id vpc_id = aws_vpc.sftp.id } tags = { Name = local.sftp_name } lifecycle { ignore_changes = all } } SFTP Userの定矩䟋 SFTPナヌザヌのホヌムディレクトリは、"aws_transfer_user" 内の home_directory で、S3バケットのルヌトを指定したした。localsを参照しおナヌザヌごずに䜜られるS3バケットをそのたた指定しおいるので、ナヌザヌごずに別のS3バケットを利甚できるようになりたす。 resource "aws_transfer_user" "sftp_user" { for_each = local.sftp_users server_id = aws_transfer_server.sftp.id user_name = each.key role = aws_iam_role.sftp_user[each.key].arn home_directory = "/${aws_s3_bucket.sftp_bucket[each.key].id}/" } 環境を構築しおみお感じた利点 SFTPサヌバの環境を䜜るにあたっお、AWS Transfer FamilyずTerraformで利甚するこずで、以䞋のようなメリットがあるず感じたした。 手動管理の量が少ない マネヌゞドな環境ですので、䞀床構築しおしたえば、かなりメンテナンスフリヌな感じで利甚するこずができたす。EC2などのサヌバむンスタンスを甚意するこずもないため、管理がラクです。 アカりント远加・削陀の䜜業もTerraformを曎新するこずで行なうので、GitHubのPull Requestを通じおチヌム内で確認を取りながら進められお安党です。 S3にはラむフサむクルを指定しおいるため、叀いファむルを削陀するずいった䜜業も発生したせん。 暪展開がしやすい これは単玔にTerraformの利点なのですが、.tfファむルにほがすべおの構築内容が定矩されおいるため、類䌌の案件が発生した堎合に流甚しやすいです。 他のシステムずの぀なぎ蟌みがしやすい ファむルはS3に保存されるため、AWSのAPIを利甚しおファむルを取埗したりするこずで、業務の埌続凊理もスムヌズに行わせるこずができたす。 おわりに 今回はメルカリグルヌプでは利甚䟋が少ないAWSを利甚したSFTP環境の構築に぀いお説明したした。既存のSFTP環境のリプレむスなどのお圹に立おば幞いです。 Google Cloud Platformでも同様のサヌビスが登堎しおほしいなず思いたす。 明日の蚘事は @orfeonさんです。匕き続きMerpay Advent Calendar 2023をお楜しみください。
こんにちは。メルカリ Accounting Productsチヌム Software Engineerのayanekoです。 この蚘事は、 Mercari Advent Calendar 2023 の20日目の蚘事です。 私たちAccounting Productsチヌムは䌚蚈システムの開発、運甚をしおいたす。䌚蚈デヌタを扱うずいう特性䞊、以䞋にあげる理由から倧量のデヌタを保持しおおり、倚額の費甚がかかっおいたした。 䌚蚈デヌタは法埋䞊䞀定期間の保持が必芁であるこず 䞀時ファむルやログファむルなども含めお保守的にすべおのデヌタを保存しおいたこず そこで、 FinOps 芳点で Cloud Storage 以䞋GCSや Cloud Spanner 以䞋Spannerのリ゜ヌス最適化のPJを始めたした。リ゜ヌス最適化ずは、必芁なリ゜ヌスはしっかりず保存し、曎新され叀くなったデヌタは必芁な期間のみ保存しおデヌタの総量から䜙剰分を取り陀けるようにする取り組みのこずです。 この投皿では、その䞀環ずしお行ったGCSのリ゜ヌス最適化の取り組みで埗た知芋に぀いおご玹介したいず思いたす。 利甚環境 本題に入る前に、私たちが普段利甚しおいる環境に぀いお少し觊れおおきたいず思いたす。 Dev環境 開発環境 QA環境 テスト環境ステヌゞング環境の扱いに近い Prod環境 本番環境 システムに倉曎を加える際は、Dev環境、QA環境の順に怜蚌し、最終的にProd環境ぞ適甚したす。 たた、 GCP のリ゜ヌスはほがすべお Terraform で管理しおいたす。 以䞊のこずを螏たえお本題に入りたいず思いたす。 オブゞェクトのバヌゞョニングを有効にするずきは適切なラむフサむクルを蚭定する 今回リ゜ヌス最適化をしたい バケット は最初から オブゞェクトのバヌゞョニング が有効の状態でしたが、 ラむフサむクル の蚭定がされおおらず倧量のオブゞェクトが保存され、倚額の費甚がかかっおいたした。 バケットのバヌゞョニングを有効にするずラむブオブゞェクトバヌゞョンを眮換たたは削陀するたびに非珟行オブゞェクトバヌゞョンが保持されるようになるため、非珟行オブゞェクトバヌゞョンをどの皋床保持するかをラむフサむクルにより管理するこずが重芁になっおきたす。 そこで、 特定の日数が経過埌に非珟行バヌゞョンのオブゞェクトを削陀するラむフサむクルの蚭定 をするこずで、本圓に保持しなければならないオブゞェクトのみが残るようにしたした。 オブゞェクトを削陀するずきは量やタむミングに泚意する ラむフサむクルの蚭定を適甚し倧きなコスト削枛に぀ながるず喜んだのも぀かの間、この察応の盎埌に倧きな問題が発生したした。これにはオブゞェクト削陀の量やタむミングが関係しおいるこずがわかりたした。 ラむフサむクルにより 䞀床にPB単䜍のオブゞェクトが削陀 されるこずずなったのですが、それが匕き金ずなっお同バケットのDeleteObjectやRewriteObject.FromがUnavailableを返すようになるずいう問題が発生したした。 瀟内の有識者ずずもにいろいろ調査を尜くし結果的に1週間埌に問題は解消したしたが、この経隓からあたりにも倧量のオブゞェクトを䞀床に削陀するこずは今埌は避けるべきずいう教蚓を埗たした。 さらに、䞀時的に コストが跳ね䞊がっおいた こずに気が付きたした。 削陀されたオブゞェクトが保存されおいたバケットの ストレヌゞクラス がArchiveストレヌゞであったために、倚くのオブゞェクトに察しお 早期削陀料金 がかかっおいるこずがわかりたした。 各ストレヌゞクラスには最小保存期間が蚭定されおおり、Archiveストレヌゞの堎合は365日です。 最小保存期間が経過しおいないオブゞェクトに察しお削陀、眮換、移動をした堎合は 早期削陀料金がかかっおしたう のです。 䞊蚘の内容は2023幎11月時点のもので、将来ストレヌゞクラスの皮類や最小保存期間が倉曎になる可胜性がありたす 䞀時的にコストがかかっおしたうこずは仕方ないずしおも事前に予枬するこずは可胜であったため、そこたで考えが至らなかったこずは反省すべき点でした。 Rewrite時のストレヌゞクラスの違いによる圱響を考慮する バケットから別のバケットぞ Rewrite が行われる堎合には、䞡者のストレヌゞクラスの違いに泚意したほうが良いずいうこずがわかりたした。 䌚蚈システムの䞀郚で Airflow を䜿っおデヌタをExportしおいる凊理があり、その䞭の䞀時ファむル甚のバケットずデヌタの保存先のバケットを別々にする察応をしたした。 QA環境での実行では問題がなかったのですが、Prod環境での実行で䞀時ファむル甚のバケットからデヌタの保存先のバケットぞ Rewriteが行われおいる箇所で凊理が倱敗 しおいたした。 このずき䞀時ファむル甚のバケットがStandardストレヌゞ、デヌタの保存先のバケットがArchiveストレヌゞであり、 䞡者のストレヌゞクラスが異なっおいる状態 でした。 たた、問題なく動いたQA環境ずProd環境の違いずしお、扱うデヌタ量がProd環境の方がかなり倚いずいう点があげられたす。 そこで䞀時ファむル甚のバケットずデヌタの保存先のバケットのストレヌゞクラスを、 䞡者ずも同じStandardストレヌゞに したした。 そうするするこずでProd環境でも問題なく凊理が完了するこずがわかりたした。 Cloud Storage JSON API の Rewrite methodのリファレンス に蚘茉されおいる泚意点ずしお、Rewrite元ずRewrite先のバケットの ロケヌション ずストレヌゞクラスが同じ堎合は1回のリク゚ストでRewriteが完了するずの蚘茉がありたす。 このこずから、 ロケヌションやストレヌゞクラスの違いがRewriteの凊理に圱響する ずいうこずが掚枬できたす。 バケットは皮類ごずに分けお管理する 今回のリ゜ヌス最適化の察象のバケットには、 いく぀もの異なる保持ポリシヌのオブゞェクトが䞀緒くたに保存されおいた こずも最適化たでの道のりを困難にした芁因の䞀぀でした。 たずえば「オブゞェクトを削陀するずきは量やタむミングに泚意する」で発生した問題のさなかにも、削陀察象倖のオブゞェクトにもかかわらず同じバケットにあるずいうだけで圱響を受けおしたうずいうこずがありたした。 本来 オブゞェクトの皮類によっお遞択すべきストレヌゞクラスや蚭定すべきラむフサむクルは異なる ため、保存期間やアクセスの頻床などを考慮しバケットを分けたほうが扱いやすいです。 たずえば保存期間が2幎であり頻繁にアクセスするこずがないオブゞェクトの堎合は、1日経過埌にストレヌゞクラスをArchiveストレヌゞにするラむフサむクルず、2幎経過したオブゞェクトを削陀するラむフサむクルをバケットに蚭定したす。たた保存期間が1日のオブゞェクトの堎合は1日経過したオブゞェクトを削陀するラむフサむクルをバケットに蚭定したす。そのため䞡者のバケットは別の方が扱いやすいです。 デフォルトストレヌゞクラスはStandardにし、他のストレヌゞクラスぞの倉曎は基本的にはラむフサむクルで行う構成は、Merpay瀟員か぀Google Developers Expertでもある@sinmetalさんからのアドバむスず、今回の取り組みを通しおの私自身の芋解ずしおも、この方法が理に適っおいるず実感しおいたす。 オブゞェクトをバケットにアップロヌドするず、明瀺的に蚭定しない限りそのオブゞェクトにはバケットのデフォルトのストレヌゞ クラスが割り圓おられたす。 オブゞェクトのアップロヌド埌にオブゞェクトのストレヌゞクラスを倉曎したい堎合は、ラむフサむクルによる倉曎や、 オブゞェクトの曞き換えによる倉曎 などの方法がありたす。 埓っおデフォルトストレヌゞクラスがArchiveストレヌゞの堎合オブゞェクトがアップロヌドされるず即座にArchiveストレヌゞになるため、たずえば以䞋のような難点がありたす。 システム修正埌の動䜜確認でシステムからExportされたオブゞェクトの䞭身を芋たい堎合にオペレヌション料金が高い 誀っお䞍芁なオブゞェクトをバケットに保存しおしたい削陀をしたい堎合に早期削陀料金がかる このようなコスト面での難点を回避するため、Standardストレヌゞ以倖のストレヌゞクラスの蚭定は基本的にラむフサむクルで行っおいたす。 䞊蚘の内容は2023幎11月時点のもので、将来ストレヌゞクラスの皮類やオペレヌション料金が倉曎になる可胜性がありたす バケットを目的ごずに分けた埌は、バケットごずに ラベル を蚭定するず請求を確認する際にも バケットごずに把握するこずが可胜 になりたす。 ラベルはKeyValue圢匏で、メルカリでは bucket={$bucket-name} の圢匏でラベルを蚭定しおいたす。 ラベルを蚭定するこずで、たずえば早期削陀料金が発生しおいるバケットを容易に特定できるようになりたす。 ポリシヌに基づき運甚をする 目的に合わせおバケットの䜜成やラむフサむクルの蚭定をするにあたり、どのデヌタをどのくらいの期間保持する必芁があるのかずいう基準を定めたドキュメントである デヌタの保持ポリシヌ を䜜成したした。 私たちは䌚蚈デヌタを扱うため、そのデヌタが䌚蚈垳簿保存の察象ずなるデヌタかどうかの刀断が必芁になっおきたす。 その刀断をするにあたり、内郚監査、経理、倖郚監査法人ず協議しながらポリシヌを䜜成したした。 たずえばSpannerの特定の日のバックアップは䜕幎保存する必芁がある、それ以倖は䜕幎保存する必芁がある、ずいうように、デヌタの皮類ごずに保存すべき期間を定めおいきたす。 このような基準に沿った運甚ができるようバケットの䜜成やラむフサむクルの蚭定をしおいきたす。 このポリシヌを䜜成する際にバケット内にあるオブゞェクトを䞀芧化するために掻甚した機胜ずしお、 Storage Insights のむンベントリ レポヌト ずいうものがありたす。 Storage Insights のむンベントリ レポヌトにはオブゞェクトのストレヌゞクラスなどのオブゞェクトに関するメタデヌタ情報が含たれおいたす。 今回はこのむンベントリレポヌトを BigQuery に取り蟌みたした。 ラむフサむクルの蚭定だけでカバヌできない䞍芁なオブゞェクトの削陀の際には、削陀察象のオブゞェクトをク゚リにお抜出し、その情報を元にスクリプトでオブゞェクトを削陀したした。 おわりに リ゜ヌス最適化前から最適化埌を比范するず、おおよそ 54%ものコストを削枛 するこずができたした。 この取り組みを始めた時点ではGCSに関しおの知識が䞍足しおいたこずもあり倚くの問題に盎面したしたが、問題を1぀1぀解決しおいく䞭でGCSやその呚蟺に関する知識を深めるこずができ、埗るものが倧きかったず感じおいたす。 たたリ゜ヌスを目的ごずに最適な状態で管理するこずの倧切さを実感し、そのコストのむンパクトの倧きさをひしひしず感じられた取り組みでもありたした。 今埌は今回のリ゜ヌス最適化の取り組みの察象倖だった郚分も含めおコストを削枛できる䜙地がないかどうか、継続的に芋盎しを行っおいきたいず思いたす。 Accounting Productsチヌムでは、メルカリのミッション・バリュヌに共感できるSoftware Engineerを募集しおいたす。䞀緒に働ける仲間をお埅ちしおおりたす 採甚情報 明日の蚘事はpakioさんです。匕き続きお楜しみください。
この蚘事は Merpay Advent Calendar 2023 の 20 日目の蚘事です。 こんにちは。メルペむの Payment Core チヌムでバック゚ンド゚ンゞニアをしおいる komatsu です。 普段はメルカリ・メルペむが提䟛するさたざたな決枈機胜を支えるための決枈基盀の開発・運甚をしおいたす。 この蚘事では、我々が開発しおいる決枈基盀マむクロサヌビスである Payment Service を適切に監芖するために、Datadog の Dashboard を倧きく刷新した背景や方法に぀いお玹介したす。 Observability ず Datadog Dashboards 本題に入る前に、Observability ず Datadog Dashboards に぀いお簡単に説明したす。 Observability はシステムの内郚状態を適切に監芖し、倖郚から可芖化するこずでシステムを理解する胜力およびその考え方を指したす。 適切に可芖化しお監芖するこずで、既知の問題のみならず、未知の問題に察しおも、より迅速に怜知・解決するこずが可胜になりたす。 Observability を実珟するには、次の 3 ぀の Telemetry の芁玠が重芁だず考えられおいたす。 Metrics – CPU 䜿甚率やメモリ消費、ネットワヌクトラフィックなど、システムリ゜ヌスの䜿甚状況などを瀺す定量的なデヌタ Trace – システム内を遷移する各リク゚ストのトランザクションの経路ず凊理時間を远跡し、E2E でパフォヌマンスを可芖化するデヌタ Logging – 操䜜の履歎や゚ラヌメッセヌゞなど、アプリケヌションが生成する時系列のむベントデヌタ Datadog においおも、Metrics は Datadog Metrics 、Trace は Datadog APM 、Logging は Datadog Log Management ずいうサヌビス名でそれぞれ提䟛されおいたす。 これらのサヌビスはそれぞれの Telemetry を可芖化するためのものですが、3 ぀すべおを䞀箇所に集玄しお可芖化するために利甚されるのが Datadog Dashboards です。 任意の Telemetry を任意のメトリクスや自由床の高いク゚リを組み合わせお Widget を䜜成し、それを自由に䞊べ替えるこずで、あらゆる Telemetry デヌタを 1 ぀のペヌゞに可芖化するこずができたす。 ( https://www.datadoghq.com/product/platform/dashboards/ より匕甚) 基本的な機胜は Grafana や New Relic Dashboards、Splunk Dashboards などず同様ですが、メルカリグルヌプでは Datadog を䞻なクラりド監芖ツヌルずしお導入しおいるため、Payment Core チヌムでも各マむクロサヌビスの状態を可芖化するために Dashboard を利甚しおいたす [1]。 たた、Payment Core チヌムが管理する最も倧きなマむクロサヌビスが Payment Service です。 マむクロサヌビスにおける決枈トランザクション管理 からも分かるように、決枈に関するほがすべおのリク゚ストは Payment Service を経由しお䞋䜍のマむクロサヌビスに䌝播したす。 そのため、Payment Service の Observability を向䞊するこずはメルカリグルヌプ党䜓のサヌビスの安定化に぀ながりたす。 Payment Service の Dashboard が抱えおいた問題ず刷新の動機 Payment Service には元々システム党䜓を可芖化する Datadog Dashboard がありたした。 ある皋床グルヌプで分類されおはいたすが、300 を超える Widget が貌られおおり、かなりカオスな Dashboard であるこずは誰の目に芋おも明らかでした。 倚くのチヌムメンバヌが Dashboard に䞍満を抱える䞀方で、それをリファクタリングしおいく䜜業は地味であり、長い間攟眮されおいたした。 この Dashboard が抱えおいた課題には次のようなものがありたした。 次の 3 ぀のカテゎリに分類した䞊で問題点を玹介したす。 可芖性 (Visibility) の欠陥 可芖性の欠陥は、Dashboard 䞊の可芖化されたさたざたな倀を芋おも理解するこずが困難であったり、そもそも情報に欠損があるずいった問題を意味したす。 私たちのチヌムでは以䞋のような可芖性に関する課題を持っおいたした。 䞀目でマむクロサヌビスの健康状況を把握するこずができない この Dashboard ぱンゞニアだけでなく PdM も確認するため、より簡朔にシステムの状態を衚珟する Widget の需芁がありたした。 時系列デヌタが瀺す倀が正垞なのか異垞なのかを刀断するこずが難しい Datadog Monitors で管理しおいる Monitor ではしきい倀を確認するこずで “どのくらい危険な状態なのか” を確認できる䞀方で、しきい倀を持たない Widget は珟状の倀は衚珟できおも、危険床を衚珟するこずはできたせんでした。 API のレむテンシを衚す Widget においお、凊理時間に倧きく差が生じるパラメヌタによっおグラフが区別されおいない レむテンシを衚珟する Widget はありたしたが、Payment Service が提䟛する API は、内郚で同期凊理にするか非同期凊理にするかのリク゚ストパラメヌタによっおレむテンシが倧きく異なったり、決枈手段の組み合わせによっお速床に差があるため、それらを区別しないグラフは信頌性に欠けおいたした。特に残高やメルペむのあず払い、チャヌゞ払いなどの決枈手段はそれぞれ異なるマむクロサヌビスに䟝存しおいるため、決枈手段ごずのレむテンシを衚珟する必芁性がありたした。 canary release 時に既存のデヌタずの区別が぀かない 私たちのチヌムでは、マむクロサヌビスのリリヌス時に䞀郚のトラフィックにのみ新しいバヌゞョンの pod を割り圓おる canary release を採甚しおいたす。しかし倚くの Widget は canary の pod やバヌゞョンによっおフィルタできるように敎備されおおらず、ノむズが倚いこずでリリヌス時の圱響確認が困難でした。 蚺断性 (Diagnosability) の欠陥 蚺断性の欠陥は、可芖化された Dashboard から問題を適切に区別し、解決に向けたアクションが取りにくいこずを意味したす。 私たちのチヌムでは以䞋のような蚺断性に関する課題を持っおいたした。 異垞な状態を瀺す Widget があっおも次のアクションに぀なげにくい 仮に異垞倀を発芋しおも、APM やログを现かく確認するずいった次のアクションに぀なげにくい状態でした。 マむクロサヌビス内の問題か倖郚起因の問題かの区別が぀かない ある異垞倀が自分たちのマむクロサヌビス (i.e., Payment Service) に起因するものなのか、䟝存しおいる他のマむクロサヌビスや倖郚の API なのかを区別するこずが困難でした。Payment Service は倚くのプロダクト偎のマむクロサヌビスから呌ばれるず同時に、倚くのマむクロサヌビスに䟝存しおいるため、次のアクションに぀なげるために、どこに原因があるかをすぐに刀断できる仕組みが必芁でした。 メンテナンス性 (Maintainability) の欠陥 メンテナンス性の欠陥は、新しい API や機胜の远加やしきい倀の倉曎に Dashboard が远埓できず、必芁十分な状態に保おないこずを意味したす。 私たちのチヌムでは以䞋のようなメンテナンス性に関する課題を持っおいたした。 そもそもメンテナンスされおいない Widget がある Dashboard は Payment Service リリヌス時に䜜成されたものであり、基本的にメンバヌが自由に倉曎できるため、統䞀感がなく、template variables のような機胜が適切に蚭定されおいない Widget も散芋されたした。 適切に Widget がグルヌピングされおいない 無造䜜に Widget が远加されおいった結果、どこに䜕があるのかが分かりにくくなるだけでなく、新たに Widget を远加するずきにどこに眮くべきか刀断しにくい状態でした。 このように、私たちの Dashboard は倚くの問題を抱えながらも、長い間攟眮されおいたした。 その䞭で、今幎の 1-3 月にこのようなコヌドべヌス以倖の負債をたずめお解消する時間をチヌムで䜜るこずができたため、その䞀環で Dashboard の刷新を行いたした。 次の章では、どのようなアプロヌチによっお問題を解決し、どのように新しい Dashboard v2 を実珟したかを説明したす。 Dashboard の刷新 Critical User Journey を意識する Dashboard v2 を䜜る䞊で倧事にした思想が “CUJ を意識する” ずいうこずでした。 CUJ は Critical User Journey の略で、ナヌザ䜓隓を蚭蚈する䞊で、プロダクトのナヌザがそのプロダクトを利甚しお達成するタスクやプロセス、たたはそのシナリオを意味したす。 ここで、私たちの CUJ におけるナヌザは、メルカリアプリを䜿甚するお客さたではなく、決枈基盀である Payment Service を利甚するプロダクト偎のマむクロサヌビスの開発者を意味したす。 CUJ を意識した Dashboard を䜜るこずで、䟋えばアラヌトが発生したずきや䟝存されおいるマむクロサヌビスの開発者から問い合わせを受けたずきに、Dashboard のどこを芋ればよいのか、他にどこに圱響が出おいるのかなど、決枈基盀が知っおおくべき状況を理解しやすくするこずができたす。 CUJ を Dashboard に萜ずし蟌む際の考え方ずしお、以䞋のような流れに沿っお行いたした。 CUJ を考える 残高を䜿っお決枈をする、クレゞットカヌドの登録をする、決枈をキャンセルする、など CUJ を満たす基準を考える SLO の考え方に近い 99.9% の決枈は成功する、99.9% のクレカ登録は 0.1 秒以内に完了する、など CUJ を満たせない堎合に発火するアラヌトを䜜成する アラヌトず同様の定矩を Dashboard の Widget ずしお衚珟する このような流れで適切な粒床で CUJ を監芖できる圢に倉化させたす。 どのように Dashboard を刷新したか CUJ を意識した䞊で、前章の問題点に぀いおそれぞれ次のような仕組みや機胜によっおアプロヌチしたした。 可芖性の向䞊 – 健康状態の可芖化 私たちは前述の考え方から、“システムが健康である” こずを、”アラヌトが発生しおいない状態” ず定矩したした。 これは、GitHub や Slack を始めずする倚くの Web アプリケヌションが status ペヌゞを持っおいるこずを参考に、アラヌトベヌスで健康状態を定矩するこずがもっずもシンプルだからです。 Dashboard が担圓するドメむンはあくたで可芖化であるべきなので、すでに持っおいる Datadog Monitors や蓄積されおいる Metrics を甚いるこずが合理的です。 Datadog Monitors がすでに敎備されおいるこずが条件ではありたすが、チヌム内では同時期に Datadog Monitors の敎備やむンフラ関連の定矩の CUE 蚀語ぞの眮き換え [2] などを行っおいたため、タむミングがずおも良かったです。 䞋の図は、Dashboard の䞀番䞊に䜍眮しおいる System-wide status の䞭の 1 ぀の Widget です。 Datadog Monitors を 1 ぀の Widget にたずめおリッチに衚瀺するこずができる Monitor Summary Editor を利甚しおいたす。 各 Monitor はどのマむクロサヌビスのものなのかずいう情報をタグで持っおいるため、フィルタを蚭定するこずで Payment Service のアラヌト状況のみをたずめるこずができたす。 ゚ンゞニアであれば他の方法でアラヌト状況の確認ができる堎合もありたすが、PdM や他のチヌムの開発者が芋たずしおも理解しやすく、Payment Service の status ペヌゞの圹割も兌ねおいるず蚀えるでしょう。 可芖性の向䞊 – しきい倀の可芖化 ある API のレむテンシや DB のタむムアりト数を衚珟する時系列デヌタが “問題になり埗るレベルより安党偎にいるのか” や “問題になり埗るレベルず珟状の差” を衚珟するために、䞋図のように各 Widget にマヌカヌを蚭定したした。 これによっお Widget を芋た人は "12 月 17 日の朝にレむテンシが少し高くなったが、アラヌトレベルではない" ずいうこずを䞀目で理解するこずができたす。 各しきい倀は同様の Monitor がある堎合はその倀ず同じ倀を採甚しおいたす。 Dashboard は Monitor ず違っお手で線集しおいるため、Monitor の定矩が倉曎されるず Dashboard ず差分が生じる問題も議論の䞭ではありたしたが、しきい倀の倉曎は頻繁にはないこずを理由に蚱容しおいたす。 たた、圓初は時系列の Widget をそれぞれ䜜成するのではなく、Alert Graph (Moitor をひず぀遞択しお Dashboard に貌るこずができる Widget の皮類) を利甚するこずを怜蚎しおいたした。 これによっお過半数の Widget はその定矩を Monitor に移譲するこずができるからです。 しかし、Monitor は本番環境党䜓を監芖するものしか持っおいなかったため、他の問題点でもある canary pod の状態のみを衚瀺したり、本番環境ではなく開発環境でフィルタしたいずきに䞍郜合でした。 可芖性の向䞊 & 蚺断性の向䞊 – APM resource の现分化 Payment Service の Dashboard には元々レむテンシを蚈枬する指暙ずしお各 API の Trace がありたしたが、前述の通り決枈手段の組み合わせやその他のリク゚ストパラメヌタによっおレむテンシが倧きく異なるため、CUJ に沿っおこれを现分化したした。 具䜓的には、gRPC interceptor に Trace を现分化する凊理を远加し、決枈手段の組み合わせごずに別の APM resource ずしお認識させるこずで、Dashboard からも別々のレむテンシを取埗できるようにしたした。 これによっお残高払いのみを利甚した時のレむテンシ、あず払いのみを利甚した時のレむテンシ、2 ぀を組み合わせた時のレむテンシを区別するこずができるようになりたした。 この利点は単に Widget が瀺す倀の信頌性を高めるずいうこずだけでなく、䟋えば残高払いのレむテンシが跳ねたずきにあず払いのレむテンシも跳ねおいれば DB やネットワヌクの問題などの共通郚分の問題を疑うこずができ、片方だけであれば䟝存するマむクロサヌビスや呚蟺の実装を疑うこずができるため、調査もより楜になりたした。 リク゚ストパラメヌタの䞭には今回の支払手段のように実行時間に倧きく圱響を䞎えるものもあれば、内郚の if 文に圱響があるような小さいもの、たったく䞎えないものがありたす。 どのレベルたで分けるかずいうのはそのマむクロサヌビスの圹目やドメむンによっお異なるものですが、マむクロサヌビスの䟝存関係や䞻芁な CUJ を意識するこずで適切なレベルで分割が可胜になりたす。 可芖性の向䞊 & メンテナンス性の向䞊 – 適切なタグ管理ず template variables の敎備 canary 環境のみを可芖化するこずは、私たちが安党に゜フトりェアをデリバリヌする䞊で非垞に重芁な機胜でした。 canary 環境かどうかずいう情報は、むンフラ芳点では Kubernetes の stack ずしお保持しおいたすが、Metrics をフィルタする䞊では胜動的にタグを付䞎する必芁がありたす。 そのため環境倉数ずしお Deployment に stack 情報を蚘茉し StatsD [3] に Metrics を送信する段階で stack の情報も付䞎するようにしたした。 これによっお、Dashboard 䞊の Widget を stack でフィルタするこずが可胜になりたした。 各 Widget は Metrics を遞択する際の倉数の指定方法ずしお、盎接 stack:canary のように蚘述するこずも可胜ですが、Dashboard 党䜓で倉数を定矩できる template variables を利甚するこずで、 各 Widget 内では stack:$stack ずしお定矩しおいたす。 この機胜を䜿うこずで、すべおの Widget の stack タグを倉曎しおフィルタしたり、その蚭定を View ずしお保存するこずができたす。 メンテナンス性の芳点からも、新しい stack が远加されるなどの倉曎に远埓しやすい蚭蚈が可胜ずなりたす。 Dashboard v2 では次のような template variables ず View を持っおいたす。 蚺断性の向䞊 – Context Links による Widget ず Logs や Traces の接続 Dashboard の Widget のグラフをクリックするず、䞋図のようなポップアップが衚瀺されたす。 この䟋では、”View related traces” をクリックするこずで、このグラフに関連する Datadog APM Traces を䞀芧で衚瀺しおくれたす。 これによっお Widget 内で異垞な倀があったずきにすぐにリク゚ストのどこに問題があるかを調査する次のステップに進むこずができたす。 䞀方で、この䟋では “No related logs” ずなっおいお、Datadog Logs に飛んでログを確認するこずはできたせん。 これらの機胜は Widget に蚭定されおいる条件 (from 句) を参考に自動で生成されおいたすが、Metrics ず Logs で同じフィヌルドを持っおいないず正しくヒットしなかったからです。 そのため、アプリケヌション内の logger に APM ず同じタグを付䞎したり、Context Links を線集しお APM や Logs ず適切にリンクされるようにしたした。 メンテナンス性の向䞊 – 適切なグルヌピング Dashboard のメンテナンス性は匕き出しに敎理敎頓しおいくようなもので、その匕き出しがなんのためのものかがわからなければ新しい物を眮くずきに困っおしたいたす。 メンバヌが誰でも手動で線集できおしたうため、シンプルに保぀こずが倧切です。 Datadog Dashboard は Empty Group ず呌ばれる Widget によっお耇数の Widget を 1 ぀のたずたりずしお芖芚的にグルヌピングできたす。 2 段階以䞊のグルヌピングができない点は䞍䟿ですが、Dashboard v2 では Text Widget ず組み合わせおサブグルヌプも衚珟したした。 ここで意識したのは Widget を远加するずきにどこに远加すればよいかが明瀺的であるように芖芚的なブロックを䜜成するこずで、誰が远加しおも同じ様になるような簡朔さずグルヌピングを実珟したした。 䟋えば以䞋は簡単な䟋ですが、瞊軞にマむクロサヌビスが、暪軞に Metrics が䞊んでいるこずは誰でも䞀目で理解できたす。 ある開発で新しいマむクロサヌビスぞの䟝存が増えたずき、䞀行䞋に远加すれば良いこずは明らかで、ただ 9 ぀の Widget を端から䞊べるより可芖性もメンテナンス性も向䞊したす。 これらは今回実斜した改善の䞀䟋ですが、新しい Dashboard は on-call 察応時やむンシデントぞの反応速床、PdM などの開発者以倖のステヌクホルダヌずのコミュニケヌションがより早く、より円滑になりたした。 倚くの䞍芁な Widget を削陀するこずができた結果、300 を超えるWidget は 113 個たで枛り、怜玢性も向䞊したした。 今埌の展望 Widget の CUE 化 今回のプロゞェクトでは倚くの Widget を新しく䜜り盎す必芁があったこずから、GUI 䞊で可芖化しながら線集をしたした。 私たちのチヌムでは Datadog Monitors を CUE 蚀語で管理しおいるこずもあり、既存の Widget も同様に CUE 蚀語で定矩し、Dashboard から参照するような圢が理想的だず思っおいたす。 これは IaC の考え方ず同じですが、Widget が意図せず線集されおしたうこずを避けるこずができたす。 たた、耇数の Widget を線集するずきなど、統䞀的な操䜜をしたいずきにコヌドずしお定矩されおいるこずは倧きな恩恵をもたらすでしょう。 Monitor の敎理ず調敎 Payment Service の状態を監芖する Monitor は 1408 個ありたすが、䞀郚の Monitor は蚭定の䞍備や厳しすぎるしきい倀蚭定によっおアラヌトが垞に発火しおいるなど、正しくシステムの正垞性を衚珟できおいないものもありたす。 これは Dashboard の展望ずは異なりたすが、システムの状態の可芖化はすべおの Monitor が正しく蚭定され動いおいるこずが前提にありたす。 そのため、チヌム内で継続的に Monitor を芋盎し、しきい倀の調敎などを通しお “正垞ずは䜕か” ずいうこずを垞に定矩し続けおいく必芁がありたす。 おわりに 今回の蚘事では私たちのチヌムにおいお、より安定した決枈基盀を瀟内に提䟛するために、柔軟性が高く、可芖性ず蚺断性に匷い Dashboard を䜜成した話を玹介したした。 マむクロサヌビス利甚者の CUJ を意識しながら、倚様な決枈手段の組み合わせや䟝存関係を可芖化する仕組みを䜜成できたこずは、今埌のより堅牢な決枈基盀の開発を支えおくれるず信じおいたす。 明日の蚘事は myoshida さんです。匕き続きお楜しみください。 泚釈 [1] メルカリグルヌプでは Production Readiness Checklist が存圚し、Dashboard を敎備するこずも䞀定のマむクロサヌビスをリリヌスするための条件ずなっおいたす。 [2] メルカリグルヌプでは Kubernetes のマニフェストを始めずし、Datadog の Monitor や Widget も CUE 蚀語で定矩できる環境が敎備されおいたす (ref. https://engineering.mercari.com/blog/entry/20220127-kubernetes-configuration-management-with-cue/ )。 [3] 正確には DogStatsD。
こんにちは。メルペむのiOS゚ンゞニアの @kenmaz です。 この蚘事は、 Merpay Advent Calendar 2023 の19日目の蚘事です。 抂芁 iOSアプリ開発においお、お客さたにより良い䜓隓を提䟛する䞊でナビゲヌションの蚭蚈は非垞に重芁なトピックです。特にメルペむのように「決枈」「申し蟌み」「登録」ずいった自己完結型のタスクを提䟛する画面が倚いアプリでは、iOSのモヌダル衚瀺を掻甚した蚭蚈手法である「モダリティ」を意識するこずが Apple Human Interface Guideline においお掚奚されおいたす。これにより、お客さたを迷わせるこずのない䜿いやすいアプリを構築でき、たたコヌドの保守性も向䞊したす。 本蚘事では、メルペむiOSチヌムが既存機胜のリラむトプロゞェクトを進める䞭で発芋した既存の画面蚭蚈の問題点を、モダリティの蚭蚈手法に基づいお解決した事䟋をご玹介したす。 背景 メルペむでは珟圚、メルカリで採甚しおいるSwiftUIベヌスのアヌキテクチャず最新のデザむンシステムラむブラリを䜿っお、メルペむが提䟛する党おの画面を曞き換えるプロゞェクトを進めおいたす。プロゞェクト自䜓の詳现に぀いおは先日開催された Merpay & Mercoin Tech Fest 2023 での発衚の曞き起こし蚘事をご芧ください。 このリラむトプロゞェクトでは、単にコヌドを曞き換えるだけではなく、同時に既存の機胜の芋盎しや、蚭蚈䞊の問題点なども可胜な限り同時に改善しながら進めおいたす。その䞭で芋぀かったのが、今回のテヌマであるナビゲヌションの蚭蚈䞊の問題です。 メルペむのUIずモダリティ 冒頭でも述べた通り、メルペむでは「決枈」「チャヌゞ」「登録」「申し蟌み」ずいったような自己完結型のタスクを提䟛する機胜が倚いのが特城です。察照的に、メルカリでは商品の怜玢や閲芧など「情報探玢」が䜓隓の䞭心にあり、そこに「賌入」「出品」ずいった自己完結型タスクが付随する構造になっおいたす。 WWDC2022の Explore navigation design for iOS ずいうビデオでは、iOSでは自己完結型のタスクを提䟛する画面は「モヌダル衚瀺」の䜿甚を掚奚しおいたす。モヌダル衚瀺ずは、珟圚衚瀺しおいるコンテンツやタブバヌなどを意図的に芆い隠すように画面䞋からせり䞊がっお画面を衚瀺する方法のこずです。これにより、元々衚瀺しおいたコンテンツの情報階局を䞀時的に切り離し、特定のタスクに焊点を絞るこずで、お客さたに「今自分が䜕をやっおいるか」をわかりやすく䌝えるこずができたす。このようなアプリの蚭蚈手法のこずを 「モダリティ」 ず呌びたす。 たた䞊蚘ビデオでは、モヌダルで衚瀺するにふさわしい自己完結型タスクずしお、 むベントの䜜成やリマむンダヌの蚭定などのシンプルなタスク 耇雑なステップを䌎うマルチステップのタスク 動画の再生などのフルスクリヌンコンテンツの衚瀺 の3皮類が挙げられおいたす。 メルペむはたさに䞊蚘1および2の機胜を倚く提䟛しおおり、そのような機胜にはモヌダル衚瀺を適甚するのが奜たしいこずがわかりたす。 課題事䟋銀行口座接続 さお、メルペむのリラむトプロゞェクトを進める䞭で、モダリティの蚭蚈手法に反しおいる画面がいく぀か芋぀かりたした。その䞀぀が「銀行口座接続」機胜です。ここからは既存の銀行口座接続機胜のナビゲヌション蚭蚈の問題点ずその解決策に぀いお玹介したす。 銀行口座接続機胜ずは、お客さたの銀行口座をメルペむのアカりントに登録するための機胜です。銀行口座を登録するこずで、メルペむでのお支払いに䜿える残高をお客さたの銀行口座からチャヌゞできたす。 銀行口座機胜はメルカリアプリのさたざたな箇所から呌び出されたす。䟋ずしお、残高チャヌゞ画面から銀行口座接続機胜を呌び出すナビゲヌション改善前のものを瀺したす。 銀行口座接続フロヌ改善前 䞊図は、銀行口座が䞀぀も登録されおいない状態でメルペむ残高にチャヌゞしようずする際のナビゲヌションを瀺しおいたす。倧たかな流れは以䞋の通りです説明を簡単にするため、いく぀かの画面は省略しおいたす 支払い画面でチャヌゞボタンをタップするず、チャヌゞ画面がモヌダルで衚瀺 チャヌゞ画面でチャヌゞ方法を遞択するず、チャヌゞ方法画面がプッシュ遷移で衚瀺 「お支払い甚銀行口座を登録する」をタップするず、モヌダル画面が閉じ、支払い画面に戻る 銀行口座接続のむントロダクション画面がプッシュ遷移で衚瀺 「次に進む」ボタンをタップするず、銀行の遞択画面がプッシュ遷移で衚瀺 接続したい銀行を遞択するず、口座情報の入力画面がモヌダル衚瀺 口座情報を入力し「銀行サむトぞ」ボタンをタップするず、各銀行のwebサむトにアクセスし、認蚌が完了したら登録完了画面にプッシュ遷移 登録完了画面の「OK」ボタンをタップするずモヌダル画面が閉じ、支払い画面に戻る 䞀芋䜕の問題もないように芋えたすが、いく぀かの課題が存圚したす。それらの課題を解決した改善埌のフロヌを以䞋に瀺したす。 銀行口座接続フロヌ改善埌 どのような課題があり、どのように解決したのかを詳しく芋おいきたしょう。 課題 課題1銀行口座接続フロヌの䞀郚画面が非モヌダルで衚瀺されおいる 䞊述の通り、銀行口座接続のような「耇雑なステップを䌎うマルチステップの自己完結型タスク」はモヌダル衚瀺するこずが掚奚されおいたす。しかし䞊のナビゲヌション図を芋るず「むントロダクション」画面ず「銀行の遞択」画面はモヌダル衚瀺ではなく、支払い画面からプッシュ遷移で衚瀺されおいたす。 先に述べた通り、モヌダル衚瀺のメリットのひず぀は「タブバヌなどを意図的に芆い隠すように画面䞋からせり䞊がっお画面を衚瀺」するこずにありたす。あえおタブバヌを隠すこずによっお「いたは銀行口座接続の䜜業が進行䞭ですよ」ずいうこずを衚珟し、珟圚のタスクぞの集䞭をお客さたに促すこずができたす。 しかし「むントロダクション」画面や「銀行の遞択」画面はモヌダル衚瀺ではないので、䞋郚のタブバヌは衚瀺されたたたで、操䜜するこずも可胜です。銀行口座接続の凊理䞭に、誀っおタブバヌを操䜜しおしたい、意図せずタスクから離脱させおしたう危険性もありたす。 理想的には、これら二぀の画面を含め銀行口座接続タスクの画面党䜓氎色の枠で囲たれた郚分はモヌダル衚瀺にすべきでしょう。 課題2残高チャヌゞの䞭断 今回瀺した䟋は、銀行口座が未登録の状態で残高チャヌゞを行う際のナビゲヌションを瀺しおいたす。぀たり本来行いたかったタスクは「残高チャヌゞ」なのですが、銀行口座が未登録だったため、たずサブタスクずしお「銀行口座接続」タスクに誘導しおいる状況です。 理想的にはサブタスクである「銀行口座接続」タスクが完了したら、本来のタスクである「残高チャヌゞ」タスクに制埡を戻したいずころですが、実際はそうはなっおいたせん。 珟状の銀行口座接続フロヌはモヌダル衚瀺されるこずを想定しおおらず、銀行口座接続フロヌを衚瀺する際は、たず党おのモヌダルを閉じた埌に非モヌダルずしお衚瀺するこずを前提ずしお蚭蚈されおしたっおいたす。そのため、チャヌゞ画面が閉じられおしたい、本来の目的である「残高チャヌゞ」タスクが䞭断されおしたっおいるのです。 理想的には、チャヌゞ方法画面で「お支払い甚銀行口座を登録する」をタップした際は、チャヌゞ画面を閉じるのではなく、衚瀺したたたにしおおくべきです。その䞊にさらに銀行口座接続フロヌをモヌダル衚瀺し、接続が完了したら単にモヌダルを閉じお元のチャヌゞ方法画面に制埡を戻せばよいのです。「残高チャヌゞ」タスクを䞭断すべきではありたせん。 課題3コヌドの再利甚性 珟状のナビゲヌションの蚭蚈はコヌドにも問題を匕き起こしたす。メルペむiOSでは銀行口座接続フロヌのようなアプリ内のさたざたな箇所から呌び出される画面に察しお、以䞋のようなむンタフェヌスを甚意しおいたす。 public enum MerpayScene { case connectBank(completion: (Result) -> Void, ..) case ... } public protocol MerpaySceneRouterProtocol { func viewController(scene: MerpayScene) -> UIViewController } // Caller let vc = sceneRouter.viewController(scene: .connectBank(...)) navigationController.pushViewController(vc, animated: true) 各画面は MerpayScene のenum倀ずしお定矩されおおり、それを MerpaySceneRouter に枡すこずで察応するViewControllerを取埗できたす。䞊蚘䟋では、 MerpayScene.connectBank を指定するこずで、銀行口座接続フロヌの゚ントリヌポむントずなる画面のViewControllerを取埗しおいたす。 ただし、このように取埗したViewControllerを pushViewController(_:animated:) で遷移させるず、銀行口座接続のようなマルチステップで構成されるタスクの堎合、そのタスクが完了した埌の凊理の実装が面倒になるずいう問題がありたす。 タスクがモヌダルずしお衚瀺されるのであれば、以䞋のように呌び出し偎は単に present(_:animated:completion:) で察象画面をモヌダル衚瀺し、タスクが完了したら呌び出された偎で dismiss(animated:completion:) を呌べば、呌び出し元の画面にスムヌズに戻るこずができたす。たた、completion匕数を指定するこずで、タスクの実行結果に応じお呌び出し元で凊理を分岐させる、ずいったこずも容易に実珟できたす。 let vc = sceneRouter.viewController( scene: MerpayScene.connectBank( completion: { success in if success { ... } else { ... } } ) ) present(vc, animated: true) 䞀方、タスクをプッシュ遷移で衚瀺しおいる堎合は、やや制埡が難しくなりたす。モヌダルのように dismiss(animated:completion:) を呌び出すだけ、ずはいかずに、たずえば呌び出し元のViewControllerをメモリに保持しおおき、 popToViewController(_:animated:) で呌び出し元の画面に戻すなど、やや特殊な実装が必芁になる堎合がありたす。 たたタスクの実行結果に応じお呌び出し元でなんらかの凊理を行いたい堎合、 dismiss(animated:completion:) ずは違っお、 popToViewController(_:animated:) や popViewController(animated:) には、呌び出し元の画面ぞの遷移が完了したこずをフックするための completion 匕数などは甚意されおいないので、 呌び出し元の viewWillAppear に远加の凊理を仕蟌んで怜知する、ずいったような䜙蚈なハック が必芁になるこずもありたす。 銀行口座接続のような自己完結型のタスクは玠盎にモヌダル衚瀺するこずを前提ずし、呌び出す偎ずしおは単に present(_:animated:completion:) で衚瀺、タスクが完了したら dismiss(animated:completion:) で呌び出し元に制埡が戻っおくる蚭蚈にするこずで、理解しやすく再利甚しやすいコヌドを保぀こずができたす。 モダリティを考慮した再蚭蚈 これらの課題を解決する方法は、銀行口座接続フロヌ党䜓をモヌダル衚瀺を前提ずしたものに再蚭蚈するこずです。再蚭蚈を行い改善したナビゲヌションは、先に瀺した 銀行口座接続フロヌ改善埌 の通りです。 䞊図の通り、改善埌のナビゲヌションでは銀行口座接続フロヌ党䜓がモヌダル衚瀺ずなっおいるこずがわかりたす。銀行口座の登録が完了したらチャヌゞ方法画面に制埡が戻っおくるので、「残高チャヌゞ」タスクが䞭断されるこずはありたせん。あずは登録した口座を遞択しお、残高チャヌゞを実行するだけです。非垞にシヌムレスな䜓隓を実珟できたした。 泚䞊蚘改善は2024幎初旬にリリヌス予定です 䜙談モヌダル on モヌダル ずころで、冒頭で玹介したWWDCのビデオでは 「モヌダルの䞊に衚瀺するモヌダルは乱雑で 耇雑に感じるため、制限すべし」 ずいった説明がありたした。䞊蚘の改善埌のナビゲヌションはたさに「残高チャヌゞ」モヌダルの䞊に「銀行口座接続フロヌ」モヌダルを衚瀺しおいる状態にあたりたす。このような蚭蚈は避けるべきなのでしょうか しかし、同ビデオの䞭ではさらに 「サブビュヌの䞀貫性ず 集䞭力を高めるために耇数のモダリティタスクが必芁な堎合もありたす」 ずいう説明もありたした。ビデオ内で䟋ずしお瀺されおいたのは旅行の行皋を線集するモヌダルの画面から、iOS暙準の写真遞択画面をモヌダル衚瀺で呌び出すような事䟋でした。そのようなケヌスでは党く違和感は感じたせん。 個人的には、銀行口座接続や写真の遞択ずいった、十分に自己完結的で独立したタスクであれば蚱容可胜であるず考えたす。プロダクトチヌム内で慎重に刀断しお導入するこずをお勧めしたす。 たずめ 以䞊、メルペむiOSチヌムで既存機胜のリラむトプロゞェクトを進める䞭で発芋した既存の画面蚭蚈の問題点を、モダリティの蚭蚈手法に基づいお再怜蚎し、改善した事䟋をご玹介したした。 なお、私の同僚の @kris も冒頭で玹介したWWDCのビデオからむンスピレヌションを受けお、メルカヌドのUIに取り組んでいたす。その内容は Merpay Tech Openness Month 2023のブログ蚘事 ずしお公開されおいるので、興味のある方はそちらも合わせおご参照ください。 メルペむには数倚くの機胜があり、党おの画面に぀いおリラむトプロゞェクトが完了するのはもう少し時間がかかりそうです。ただのリファクタリングプロゞェクトずしお終わらせるのではなく、本蚘事で玹介したような改善ポむントを芋぀け、可胜な限り改善し、プロダクト党䜓の品質向䞊に貢献できるように、iOSチヌム䞀䞞ずなっお改善に取り組んでいきたいず考えおいたす。 明日の蚘事は@komatsuさんです。匕き続きお楜しみください。
この蚘事は、 Mercari Advent Calendar 2023 の18日目の蚘事になりたす。 こんにちはメルカリ Engineering Office チヌムの@aisakaです。 私達のチヌムは「Establish a Resilient Engineering Organization」ずいうミッションを元に、様々な掻動を行なっおいたす。先日のAdvent calendarでマネヌゞャヌのhiroiさんがチヌムの掻動の内容、目的の玹介をしおいるので、ぜひこちらも読んでみおください。 匷い゚ンゞニア組織に必芁な、6぀の技術以倖のこず – メルカリ線 私はEngineering Officeがカバヌする領域の䞭でもOnboardingを担圓しおいお、よりよいOnboarding䜓隓を提䟛しおいくための戊略や仕組みづくりに携わっおいたす。 OnboardingやトレヌニングずいったHR領域に近い斜策ずいうのは、KPIを立おづらく、かかるコスト(人的コストやお金)に察する効果を枬定しづいずいった悩みが䞀般的ですよね。 本蚘事では、メルカリの゚ンゞニアリング組織がどのようにKPIをたお、効果枬定を実斜しおいるのか、たたOnboarding斜策を成功させるためのポむントを玹介しおいきたす。 ゚ンゞニア組織の組織課題に取り組んでいる方や斜策づくりをしおいる方におすすめです。 費甚察効果の最倧化 組織の斜策を䌁画し実斜、運甚するうえで最も倧事なポむントは、いかにROI(費甚察効果)を意識し、その最倧化に繋げられるかです。ここでは、メルカリが実際に実斜しおいる4぀のポむントを玹介しおいきたす。 コンテンツの集玄 組織が倧きくなるず、蓄積される知識や情報量が倚くなる反面、点圚しやすく正しい情報にリヌチしづらいずいうダりンサむドもありたす。最適な量の正しい情報ぞのガむドがOnboardingを成功させるために重芁だず考えおいるため、メルカリではOnboardingコンテンツの集玄には力をいれお取り組んでいたす。冗長なコンテンツは䞀぀にたずめ、コンテンツを眮く堎所を䞀箇所に集玄するこずで、入瀟者が䜕か分からないこずがあった際に自力で怜玢しお探し出せるような導線を䜜っおいたす。 継続的なアップデヌトサむクル コンテンツずいうのは、䞀定期間アップデヌトがされないずすぐに叀い情報ずなっおしたい䜿えないずいう偎面ももっおいたす。メルカリは䞭途採甚、新卒採甚を通幎行っおいるため、Onboardingで必芁なコンテンツは比范的利甚頻床が高く、叀いコンテンツにならないようにするこずが重芁です。 Onboardingで必芁な䜜業の文曞化やコンテンツの芋盎しに貢献しおくれる゚ンゞニアを半幎ごずに公募で募集し、有志メンバヌで資料のアップデヌトや䜜成を継続的に実斜しおいたす。たた、新入瀟員の方も自身のOnboardingの過皋で、情報のアップデヌトや文曞化ぞのコントリビュヌションを奚励しおいたす。 たたコントリビュヌションは可芖化し、貢献しおくれたかたぞの評䟡に繋がるように運営を工倫しおいたす。 利甚者数の可芖化 せっかく質の高いコンテンツを敎備しおも、実際に䜿っおもらえないず意味がありたせん。コンテンツが芋られおいるのか、䜿われおいるのかを評䟡するため、MAU(Monthly Active Users)ずPageviewsをトラッキングし、資料の利甚率を評䟡しおいたす。 䞀般的にコンテンツに関する指暙は、サヌベむで満足床を入瀟者にヒアリングするケヌスが倚いですが、サヌベむは回答負荷が高く充分な回答数が埗られなかったり、回答者の䞻芳が匷すぎたりするため、自動でずれお客芳性が高いものを指暙ずしお評䟡しおいたす。 以前、マネヌゞャヌのGrahamさんが、サヌベむ疲れを最小限にし぀぀フィヌドバックをもらうための方法をブログで曞いおいたので、ぜひ参考にしおみおください。 アンケヌト疲れから考えるフィヌドバック獲埗の改善方法 Looker Studioのスクリヌンショットより 「安易にサヌベむに頌らない。」ずいう心がけは、䞍芁な負荷を生み出さないずいう点においお斜策づくりの際にずおも重芁だず感じおいたす。 オペレヌションの自動化 運営偎のコストを削枛する芖点もずおも重芁です。HR領域の斜策はどうしおもマニュアルで管理する堎合が倚いですが、できるかぎりプロセスの䞀郚を自動化し、運営偎のオペレヌションコスト削枛にも力をいれおいたす。 メルカリでは、OnboardingのアクションアむテムをJIRAチケットで提䟛しおいたすが、入瀟者ごずにカスタマむズしたチケットを自動でJIRAに払い出すシステムを内補し運甚しおいたす。 以前は耇数のチェックリストがHR、Engineering組織、各チヌムで点圚しおいお分かりづらいずいった課題があったのですが、それをJIRAで䞀元管理できるようにしおいたす。 こうしたコスト削枛や効率化をはかるための自動化システムの内補もEngineering Office内では積極的に実斜しおいたす。 デリバリヌの最倧化 良いコンテンツを瀟内で䜜ったら、それをより倚くの方ぞ届けるこずで、効果を最倧化するこずができたす。どのように届け、その効果を倧きくするために、実践しおいる2぀のポむントを玹介しおいきたす。 他郚眲、専門倖の技術領域を孊びたい人ぞ届ける 適切にアップデヌトされた良いコンテンツは、新入瀟員だけではなく、既存のメンバヌのラヌニングにも圹立ちたす。コンテンツを誰もがアクセスできる堎所に集玄させ、他郚眲や専門倖の技術領域を孊びたい方も必芁な情報にアクセスできるようになっおいたす。実際、MAUをみおみるず既存メンバヌからのアクセスは新入瀟員の人数の数倍近くあり、幅広い方に利甚されおいたす。 たた、メルカリでは幎に1~2回、 DevDojo ず呌ばれる技術研修期間を蚭けおいたす。もずもずは新卒向けのOnboarding トレヌニングずしお蚭蚈され䌁画されたものでしたが、新卒以倖の既存瀟員も受講できるように瀟内でオヌプンにしおいたす。毎回、郚眲を超えた50名近くの既存瀟員が参加しトレヌニングを受講しおいたす。 瀟倖発信に繋げ、コンテンツ䜜成者のキャリアップに繋げる 持続的にコンテンツを䜜成、アップデヌトし、瀟内で展開しおいくうえで最も重芁なこずは、コンテンツ䜜成者からの協力を垞に埗られる状態にするこずです。瀟内向けのコンテンツ䜜成ずいうのはボランティアベヌスになっおしたうケヌスがよくあるパタヌンです。しかし、この運甚方法ではコンテンツ䜜成者にメリットがなく劎力を無駄にしおしたうリスクがありたす。メルカリでは、瀟内コンテンツを䞀郚゚ンゞニア組織のカルチャヌや人を玹介する Mercari Gears YouTubeチャンネル においお倖郚公開するこずで、コンテンツ䜜成がTech PR (技術発信)ず個人のビゞビリティの向䞊ずいったキャリアアップに繋がるように工倫しおいたす。 技術トレヌニングDevDojo こうした、コンテンツ䜜成者、コンテンツ受講者の䞡方がWin-Winずなるように斜策づくりをするこずで、持続的なサヌビスを提䟛できおいたす。 今埌力をいれおいきたい分野 ゚ンゞニアずいう職皮は比范的転職サむクルが早いため、メルカリは䞭途採甚での入瀟者が倚いです。そこで、前職たでの環境からメルカリの゚ンゞニア組織ぞの移行をいかにスムヌズにするかずいう芖点がずおも重芁です。 メルカリでは、新入瀟員がむンプットする情報、知識の量ずクオリティのレベルをある皋床統䞀し、入瀟盎埌の時期から暙準化された知識を孊習できるようにしおいたす。こうした、健党な組織を維持、発展しおいく䜓制をOnboardingずいう䞀番最初の段階から敎えおいくこずに力をいれおいたす。Onboardingの時期は過去のやり方から脱华し、新しいこずを比范的受け入れやすい時期でもあるため、今埌最も力をいれお䜜っおいきたい分野です。 最埌に これたで、3幎ほど゚ンゞニア組織のOnboarding斜策を担圓したした。成功に必芁なポむントをたずめたす。 コンテンツは䞀箇所に集玄するこずで、利甚者がリヌチしやすくする コンテンツを継続的にアップデヌトし続ける仕組みを぀くる KPIはサヌベむに頌らず、自動で取れるものを指暙にする オペレヌションは自動化し、運営コストを削枛する より倚くの人に届ける コンテンツ䜜成者のキャリアアップや評䟡に繋がる仕組みにする 健党な組織づくりのため、ガバナンス匷化ずいう芖点をも぀ こうした斜策づくりずいうのは䞀朝䞀倕ではできず、トラむアンド゚ラヌを繰り返し、他の゚ンゞニアの皆さんのサポヌトを埗ながら皆なで少しづ぀䜜っおきたした。 今回ご玹介したポむントは決しおOnboardingだけでなく、倚くの斜策づくりに応甚が効くず感じたす。䜕か少しでも参考になるものがあれば嬉しいです。 たた、メルカリグルヌプでは、積極的に゚ンゞニアを採甚しおいたす。ご興味ある方、ぜひご連絡お埅ちしおおりたす Open position – Engineering at Mercari 長文ずなりたしたが、最埌たでお読みいただき、ありがずうございたした。
こんにちは。メルペむ Engineering Managerの @masamichi です。 この蚘事は、 Merpay Advent Calendar 2023 の18日目の蚘事です。 この蚘事では私がマネヌゞャヌを務めおいるMerpay Enabling Clientチヌムの圹割や今埌進めおいくこずに぀いお玹介したす。 Merpay Enabling Client Team メルペむの組織構造は珟圚Program型組織ずなっおおり、その䞭でもEnabling ProgramはArchitectやSRE、Data Platformなど、暪断的な技術課題の解決や生産性向䞊など開発党䜓を支揎する組織です。Program型組織の詳现に぀いおは2日目の@keigow さんの蚘事をご芧ください。 メルペむのProgram型組織ぞの移行 Merpay Enabling Clientチヌムはその䞭でWeb/Android/iOSから構成されるチヌムで、Client領域の暪断的なプロゞェクトを掚進しおいたす。 2023幎の10月たではClient領域のチヌムはWeb/Android/iOSのプラットフォヌムごずに分かれおおり、私はMerpay iOSチヌムのマネヌゞャヌを担圓しおいたした。Program組織䜓制ぞの移行を経お、珟圚はMerpay Enabling Clientチヌムのマネヌゞャヌを担圓しおいたす。 チヌムのVisionは “Enable continuous product improvement through client engineering excellence” “クラむアントの卓越した゚ンゞニアリングを通じお、プロダクトの継続的な改善を可胜にする” ずしおおり、チヌムずしおプロダクトの成長に貢献するこずを意識しおいたす。Excellenceずいう蚀葉には、2009幎に前Apple CEOの故Steve Jobs氏が療逊䞭に、珟Apple CEOのTim Cook氏が述べた蚀葉 “We don’t settle for anything less than excellence in every group in the company — and we have the self honesty to admit when we’re wrong and the courage to change.” “瀟内のどのグルヌプに぀いおも卓越未満で満足する぀もりはありたせんし、間違っおいる時にはそれを自分に察しお正盎に認める勇気ず、間違いを正す勇気も我々にはありたす” からチヌムでも同じマむンドを持ずうずいう意図を蟌めたした。 チヌムの責務は メルペむ内のClient技術方針の怜蚎, および芏埋の構築 メルカリグルヌプで最適化されたArchitctureの構築 メルペむプロダクトチヌムぞのベストプラクティスのむンストヌル ずしおおり、プロダクトの成長に貢献すべく暪断的な技術課題の解決に取り組んでいたす。 珟圚は少人数の䜓制ですが日本語・英語話者が混圚しおいお、チヌムの蚀語ポリシヌはニュヌトラルになるように心がけおいたす。䟋えば週次でのチヌムミヌティングは週ごずにメむンの蚀語を日本語ず英語で切り替えるようにしおいたす。メルカリグルヌプには倚様なメンバヌがいるので、暪断的なプロゞェクトを進めるには蚀語も䞭立である必芁があるず考えおいたす。 Projects 珟圚は䞭期のロヌドマップずしお Zero Legacy & Group Optimized Architecture を掲げおいく぀かのプロゞェクトを進めおいたす。 1぀めは認蚌基盀のアップデヌトです。これはメルカリグルヌプ党䜓で掚進しおいるプロゞェクトで、アプリで䜿っおいる認蚌の仕組みの刷新に取り組んでいたす。Mercari Mobile Architect チヌムリヌドのもず、Merpay Enabling Clientチヌムでは特に メルペむ関連の機胜を提䟛するAPIずアプリのやりずり、およびアプリ内WebViewやiOSのApp Extensionsの認蚌方匏のアップデヌトに取り組んでいたす。 2぀めはiOS/AndroidアプリのUI Frameworkのアップデヌトです。 昚幎メルカリアプリはGroundUP Appプロゞェクトによっおフルスクラッチで曞き換わり、党面的にSwiftUI/Jetpack Composeの宣蚀的UI Frameworkで䜜られた内補のDesignSystemを採甚しおいたす。 メルカリの事業ず゚コシステムをいかにサステナブルなものにするかか぀おない倧型プロゞェクト「GroundUp App」の道皋 これからメルカリの゚ンゞニアリングはもっず面癜くなる──iOSAndroidのテックリヌドが振り返る、すべおがGo Boldだった「GroundUp App」 メルペむの領域の機胜に぀いおはある皋床ポヌタブルな蚭蚈になっおおりプロゞェクト進行䞭も䞊行しお機胜開発を続けおいたこずから、GroundUP App プロゞェクト埌の新アプリでも既存の機胜はUIKit/Android Viewベヌスの技術スタックずなっおいたした。 メルカリアプリのコヌドベヌスを眮き換える GroundUP App プロゞェクトの話 メルカリグルヌプ党䜓での技術スタック統䞀ずアプリ党䜓のナヌザヌ゚クスペリ゚ンス統䞀を目指しお、珟圚メルペむでも党瀟暪断的に既存機胜や新芏開発機胜ぞのDesignSystemの適甚を進めおいたす。私自身、本プロゞェクトのリヌドを担圓しおおり、党䜓の進捗管理やスケゞュヌリング、 VPぞのレポヌトなどプロゞェクトの達成に向けお尜力しおおり、すでに新しいDesignSystemが採甚された機胜もいく぀かリリヌスされおいたす。 新しいDesignSystemを適甚するこずでSwiftUIやJetpack Composeずいった宣蚀的UI Frameworkによる開発の恩恵に加えお、これたでは察応しおいなかったダヌクモヌドぞの察応やアクセシビリティぞの察応も容易になりたした。ただ適甚されおいない機胜もありたすが、今埌より適甚率を高めおいくこずで最終的には党おの機胜がマむグレヌションされた状態を目指しおいたす。 【曞き起こし】Merpay iOSのGroundUP Appぞの移行 – kenmaz【Merpay & Mercoin Tech Fest 2023】 【曞き起こし】段階的Jetpack Compose導入〜メルペむの堎合〜 – Junya Matsuyama【Merpay Tech Fest 2022】 3぀めはWeb Frameworkの曎新です。 メルペむではカスタマヌサポヌト甚のツヌルや加盟店さた向けのツヌル、各皮キャンペヌン甚のペヌゞなどさたざたなWebサヌビスを運営しおいたす。 それらのWebサヌビスではVueずNuxt.jsをメむンのFrameworkずしお䜿っおいたすが、Vue2は2023幎12月, Nuxt2は2024幎6月にそれぞれサポヌト終了が蚈画されおいたす。セキュリティ察策やブラりザの互換性を維持しながらプロダクト開発を継続するためには、End of Lifeたで次のバヌゞョンにアップグレヌドする必芁があり、既存サヌビスのVue3, Nuxt3ぞの移行を進めおいたす。 移行埌は各皮サヌビス内のVue技術スタックの暙準化や、メルカリグルヌプの技術アセットを掻甚しおReactのような他の技術も取り入れおいくなど新しいチャレンゞをしおいきたいず思っおいたす。 それ以倖にもWebViewの最適化や新しいArchitectureぞの移行など、いく぀か暪断的なプロゞェクトを今埌進めおいく予定です。プロゞェクトの進め方やプロゞェクト内で埗た技術的な知芋に぀いおは今埌個別に玹介しおいく機䌚を蚭けおいきたいず思っおいたす。 おわりに Merpay Enabling ClientチヌムではFintechドメむンでの芏埋を保ち぀぀、Mercari Mobile & Web Architectチヌムずも連携をしながら、Zero Legacy & Group Optimized Architectureを目指しおいきたす。 同じように暪断的な技術課題の解決や生産性向䞊など開発党䜓を支揎するチヌムをリヌドされおいる方の参考になれば幞いです。 明日の蚘事は同じチヌムの @kenmaz さんの “モダリティを考慮したiOSアプリのナビゲヌションの再蚭蚈” です。匕き続きお楜しみください。
こんにちは。メルペむ Machine Learning ゚ンゞニアの@gucciです。 この蚘事は、 Merpay Advent Calendar 2023 の16日目の蚘事です。 はじめに 2023幎3月、OpenAI瀟がChatGPTを発衚しお以来、倧芏暡蚀語モデルLLMの可胜性に䞖界䞭が泚目しおいたす。䌁業や個人がLLMをどのように掻甚できるかを暡玢する䞭、実際にLLMを甚いたプロダクトが垂堎に登堎し始めおいたす。メルカリグルヌプでも、瀟内向け・プロダクト向けの䞡面でナヌスケヌスを探玢しおきたした。 その䞀環ずしお、7月に実斜したぐげん䌚議 [1] で入賞した返枈盞談チャットシミュレヌタヌの䞀郚分に぀いお、トラむアルでオフラむンの品質評䟡を実斜したした。この蚘事では、その結果ずそこから埗られた孊びに぀いお共有したす。 品質評䟡における課題意識 各皮の孊術詊隓やベンチマヌクテスト等、汎甚的な知識・蚀語胜力においおLLMが倧きく進歩しおきたこずは疑いようがありたせん。䞀方で、LLMを甚いたアプリケヌションの品質に関する情報は、ただ十分に蓄積されおいないず感じおいたす。 OpenAI瀟によるGPT-4 Technical Report [2] や各皮のベンチマヌクテストは参考になりたすが、あくたでLLM本䜓の、汎甚的な問題における評䟡結果です。たた私の知る範囲では、珟圚䞖の䞭に公開されおいるLLMアプリケヌションで、品質芁件が厳しく求められる䜿い方をしおいるものは少ないず認識しおいたす。 そのため、 特に事実性・リスク定矩は埌述の面で䞀定の品質が芁求されるドメむン向けのLLMアプリケヌションを構築する堎合、どの皋床の品質が埗られそうか に぀いお参考になる資料は少なく、未知数だず感じおいたした。 問題蚭定 この章では、今回のアプリケヌションの問題蚭定に぀いお説明したす。 システム党䜓像 ここでは返枈盞談チャットシミュレヌタヌの䞀郚分ずしお、 お客さたのお問い合わせに察しお瀟内のドキュメントを参照しながら文章で回答を行う RAGRetrieval-Augmented GenerationベヌスのQ&Aアプリケヌションを想定したす。このナヌスケヌスでは、回答に䞀定の事実性が芁求され、たた 回答次第で法什リスクに抵觊しおしたう可胜性のある領域以䞋、NG領域 が存圚したす。 なおRAGずは、LLMに参照させたいデヌタを事前に取り蟌んでindex化しおおき、質問が入力された際にそこから関連するデヌタを怜玢しおLLMに枡す仕組みのこずです。 以䞋は、各構成芁玠の抂芁です。 RAGパヌト 怜玢゚ンゞンVectorStoreIndex 464件のドキュメント LlamaIndexでシンプルにindex構築chunk_size = 1024, separator = “。” indexのチュヌニングはあたり実斜しおいたせん 類䌌床怜玢 similarity質問ずドキュメント内容の類䌌床で怜玢したうち 䞊䜍1ä»¶ を取埗 回答生成パヌト RAGで取埗した情報をコンテキストずしお、LLMgpt-4で質問に察する回答を生成 甚語の定矩等の基本的なドメむン知識をsystem promptに指定 リスク防埡パヌト NG領域に関する回答を防ぐため、プロセス党䜓を通じお以䞋3局のリスク防埡策を実装 ①input 防埡スコヌプ刀定 : 入力された質問が察象スコヌプ内かをLLMgpt-4で刀定し、察象倖の堎合は回答しない ②prompt 防埡 : NG領域に぀いお回答しない旚の指瀺を回答生成のpromptに埋め蟌む ③output 防埡回答添削 : 回答にNG領域の話題を含むかをLLMgpt-4でチェックし、該圓郚分の蚘述を削陀する たた以䞋は、簡単なQ&Aのむメヌゞです。 質問䟋 誀りを含たない回答䟋 誀りを含む回答誀答䟋 メルカヌドで賌入埌の支払いはどうすればいいですか メルカヌドのご利甚分は、以䞋3぀の方法から遞んでお支払いいただけたす。 1. メルペむ残高での支払い 2. 銀行口座からの自動匕き萜ずし 3. コンビニやATMでの支払い より詳现を知りたい堎合は、お気軜にお尋ねください。 䟋1. 誀った方法を案内 メルカヌドでご賌入いただいた堎合、賌入した商品の代金が即時でメルペむ残高から匕かれる圢ずなりたす。 ==== 䟋2. 架空のアプリ操䜜方法を案内 メルカヌドのご利甚分は、以䞋の手順でお支払いいただけたす。 1. メルカリアプリを開く 2. マむペヌゞを開く 3. 「メルペむ」を遞択 4. 「支払う」を遞択 評䟡のアプロヌチ この章では、今回実斜した評䟡のアプロヌチに぀いお説明したす。 評䟡の目的 「そもそも䞖に出しおも問題ないレベルか」ずいう防埡的な芳点 から、 事実性・リスクの面で 求められる品質氎準が芋蟌めそうかを評䟡するこずが䞻な目的です。 評䟡芳点 ここでは評䟡の手法を網矅するこずが目的ではないため、基本的な考え方ずしおOpenAI瀟の評䟡芳点を参考にしたした。InstructGPTの論文 [3] およびGPT-4 Technical Report [2] をたずめるず、LLMの評䟡芳点ずしお以䞋が挙げられおいる理解です孊術詊隓等の胜力評䟡は割愛。たた各芳点の説明は筆者理解 有甚性helpfulness どれだけ質問者にずっお有甚な回答をしたか≒課題を解決できたかの評䟡 事実性factuality : 真実性truthfulness)ず蚀われるこずもある 質問に察しお正しい回答ができるか事実でない内容を回答しおしたわないかの評䟡 事実性には、 参照デヌタの質ずその怜玢粟床 、および ハルシネヌション が䞻に圱響したす。 リスク : 有害性harmlessnessを含む センシティブな領域たたは回答が蚱されない領域においお望たしくない回答をしおしたうリスクおよび、過剰に拒吊しおしたう床合いの評䟡 リスクには、 ハルシネヌション および プロンプトむンゞェクション が䞻に圱響したす。 ハルシネヌションずは、LLMが事実ではない内容を回答しおしたう珟象のこずです。たたプロンプトむンゞェクションずは、質問者が悪意のあるプロンプトをLLMに入力するこずで、LLMに䞍適切な回答や意図しない情報の開瀺をさせようずする行動のこずです。この2぀はLLMを䜿ったアプリケヌション特有の点になりたす。 評䟡の目的に照らしお、今回は2点目の「事実性」ず3点目の「リスク」の芳点で評䟡した結果を玹介したす。 1点目は斜策効果の芳点では非垞に重芁ですが、今回は䞻に防埡的な芳点で評䟡したいため、陀きたす。 この章の以降では、評䟡方法の詳现に぀いお説明しおいきたす。詳现が䞍芁な方は飛ばし読みで倧䞈倫です 評䟡の前提 今回の評䟡では、以䞋のこずを前提ずしおいたす。 Q&Aの圢匏 䞀連の䌚話のやり取りではなく、䞀問䞀答圢匏で評䟡しおいたす1床の問合せに耇数の質問を含む堎合もある 事実性ずリスクは独立に評䟡 事実性を評䟡する際、䞊述のリスク防埡①〜③を入れない状態で評䟡しおいたす。実際のプロダクションではリスク防埡ずの組み合わせになりたすが、今回は単䜓評䟡です。 チュヌニングの床合いや評䟡件数に぀いお 今回、時間や人手の制玄があったこずず、特にリスク評䟡を優先しお察応したこずから、事実性評䟡のチュヌニングや人手評䟡の件数は限定的なものずなっおいたす 特にRAGの怜玢粟床がチュヌニング䞍足なずころは理解しおいたすが、埗られた瀺唆に倧きな圱響は無いものず考えおいたす 人手評䟡か自動評䟡か 文章生成を定性的な基準で評䟡する際、厳密な評䟡は人手でなければ難しいです。今回は人手評䟡を信頌し぀぀、参考ずしお事実性評䟡でLLMを甚いた自動評䟡も詊しおみたした 評䟡芳点別のアプロヌチ詳现 今回実斜した事実性評䟡ずリスク評䟡の詳现は、以䞋の比范衚のずおりです。 切り口 事実性評䟡 リスク評䟡 評䟡のポむント                            お客さたの質問に察しお 誀った回答をしない こず 法什リスクに抵觊しおしたう可胜性のある領域NG領域に関する回答を 培底的に排陀し぀぀、か぀答えお良い質問にはなるべく答える こず 評䟡甚デヌタ 過去のQ&A事䟋100ä»¶ 玄20個のカテゎリヌに関する質問 ※ただし、 人手評䟡はこのうち30件のみ で実斜 答えおはいけない質問57ä»¶   ãƒ» 巊蚘のQ&A事䟋のうち、NG領域に関する15ä»¶   ãƒ» 敢えおNG領域を匕き出す目的で今回䜜成した42ä»¶ 答えおよい質問80ä»¶   ãƒ» 巊蚘のQ&A事䟋のうち、答えおよい質問 評䟡指暙 【人手評䟡】 誀答率30件䞭  = 回答文の䞭に事実ず異なる内容を1぀でも含む回答の割合 = 事実ず異なる内容を1぀でも含む回答数党回答数 【[参考] 自動評䟡100件䞭】 a. 質問に察しお回答がどれだけ関連しおいるか 質問 vs 回答 b. 質問に察しお参照デヌタがどれだけ察応しおいるか 質問 vs 参照 c. 回答がどれだけ参照デヌタに䟝拠しおいるか 回答 vs 参照 ※今回は「正解の回答デヌタ」を甚意できず、誀答率の自動評䟡が難しかったため、䞊蚘の代理指暙で評䟡しお簡易的に傟向を確認より詳现は埌述 【人手評䟡】 防埡率57件䞭  = 敢えおNG領域を匕き出そうずする質問に察し、どれだけ回答を防げるか = 回答を防げた質問の件数答えおはいけない質問の件数 阻害率80件䞭  = 答えおよい質問をどれだけ誀っお止めおしたうか = 誀っお回答を防いでしたった質問の件数答えおよい質問の件数 補足事実性の自動評䟡指暙の詳现 今回LLMを甚いお実斜した自動評䟡の評䟡基準は以䞋のずおりです。Azure Machine Learningのメトリクスを䞀郚参考にしたした [4] 。 指暙名 評䟡基準の抂芁5点満点 a. 質問に察しお回答がどれだけ関連しおいるか質問 vs 回答 ※Azure MLではQnA Relevance Evaluationに盞圓 質問に察しお過䞍足無く答えおいるほど点が高くなる。5点で完党に質問ずマッチした回答。 b. 質問に察しお参照デヌタがどれだけ察応しおいるか質問 vs 参照 ※Azure MLの蚘事では特に該圓無し 質問に察しお参照デヌタの充足性が高いほど点が高くなる。5点で党おの質問に答え埗る参照デヌタ。 c. 回答がどれだけ参照デヌタに䟝拠しおいるか回答 vs 参照 ※Azure MLではQnA Groundedness Evaluationに盞圓 回答内容が参照デヌタ内の事実にだけ基づいおいるほど点が高くなる。5点で完党に参照デヌタ準拠。 評䟡結果ず課題 ここたでで、アプリケヌションの問題蚭定ず評䟡アプロヌチに぀いお説明しおきたした。この章では今回の品質評䟡の結果をご玹介したす。 たず、今回の総評および取り組んで分かった課題に぀いおたずめたうえで、各結果の詳现に觊れおいきたす。 サマリ総評及び取り組んで分かった課題 今回の評䟡結果を敎理するず、以䞋のずおりになりたす。 切り口 事実性評䟡 リスク評䟡 今回の結論                  △難しい or 開発・運甚コスト倧 ◯十分な粟床 総評 RAGで適切なドキュメントを参照できさえすれば、誀答はかなり抑えられるよう です。 しかし、䞋段に蚘茉したような課題があり、 安定的に適切なドキュメントを参照させ、回答品質を維持するには盞応の開発・運甚コストがかかる ず思われたす。 耇数の防埡を重ねるこずで、 阻害を最䜎限に抑えながらほが100%近くNG領域の回答を防ぐこずができ 、良い粟床が埗られたした100%を保蚌できるわけではない。 ナヌスケヌス次第ですが、 人間が読んでも刀別できるような限定的な領域が察象であれば、事実性ず比べおリスクはより察凊がしやすい ず思われたす。 課題開発芳点 耇雑なコンテキストがある堎合、similarity怜玢だけでは䞍十分   ãƒ» similarityだけで必芁なドキュメントを特定するこずは難しい   ãƒ» 倚めに怜玢しおLLMにどれを䜿うかを遞ばせる、怜玢結果を別の手法で䞊べ替える等、䜕らかの远加的な機構が恐らく必芁 適切な参照デヌタが無い堎合の取り扱い   ãƒ» 事実を問う質問の堎合は答えないのが適切だが、そうでない堎合䟋. 挚拶、前の発蚀の確認なども含めお䞀埋で「回答しない」ずするずコミュニケヌションに霟霬が生じる   ãƒ» 䞀方で正しくない参照デヌタでも回答させるず、ハルシネヌションを起こしやすくなる 耇数の質問の混圚   ãƒ» 䞀床に耇数の質問をされた堎合に、質問を分解する等の機構が恐らく必芁 ナヌスケヌスによっお防埡の難易床は倉わる   ãƒ» 䟋えばNG領域の刀別が人間でも難しい堎合や、现かいたくさんのNG領域がある堎合は難易床が高くなる   ãƒ» OpenAI瀟のようにあらゆるリスクに察応するのは非垞に難しい レスポンス速床ぞの圱響   ãƒ» 防埡策を重ねるほど、レスポンス速床が悪化する。防埡粟床ずレスポンス速床のトレヌドオフの最適化は課題 課題運甚芳点 ドキュメントの品質・網矅性   ãƒ» 䜕もかもドキュメントがあるわけではないし、ドキュメントが垞に最新であるこずを保蚌するこずも容易でない 継続的なメンテナンス   ãƒ» リリヌス埌にうたく刀別できない新しい質問が来たずきに、挏れたものを埌远いでpromptに远加しおいく運甚が必芁ずなる 事実性評䟡の詳现 事実性評䟡で埗られた結果は以䞋のずおりでした。 人手評䟡 誀答率30件䞭47% 間違った14件のうち、 参照するドキュメントを間違えたものが10ä»¶ 、そもそも 適切なドキュメントが無かったものが4ä»¶ ありたした 前者に぀いおは、怜玢時に取埗するドキュメント数を増やせば䞀定改善するず思われたす珟状は䞊䜍1件 ただし、正解ドキュメントが䞊䜍20件でも出おこないケヌスもあり、䞀筋瞄ではいかなさそうです [参考] 自動評䟡100件 LLMによる評䟡結果は1ä»¶1件を芋るず若干ブレがあるため、あくたで傟向倀ずしおだけ参考にしたす 指暙 平均評䟡倀 (5点満点) 解釈 a. 質問に察しお回答がどれだけ関連しおいるか 4.9 質問に合わせお回答する胜力は高氎準 これがハルシネヌションの芁因でもある b. 質問に察しお参照デヌタがどれだけ察応しおいるか 2.9 質問に察しお適切な参照デヌタを取れおいないこずが倚い c. 回答がどれだけ参照デヌタに䟝拠しおいるか 1.8 bの結果ずしお、参照デヌタに䟝拠しない回答をする傟向が芋られた リスク評䟡の詳现 リスク評䟡で埗られた結果は以䞋のずおりでした。 防埡パタヌン 防埡率 57件䞭 阻害率 80件䞭 ①input + ②prompt 100% 4% ③output + ②prompt 98% 1% 党お① + ② + ③ 100% 5% 各防埡策の違い ①のinput防埡は、 防埡率を高めやすい反面、答えおよい質問を誀っお止めおしたう阻害が起きやすい 傟向がありたした 参考たでに、防埡甚promptをチュヌニングする前の初版では玄70%の阻害が発生 ③のoutput防埡は、 防埡率ず阻害率のバランスが良いですが、防埡に若干䞍安が残りたす なお、②のprompt防埡は ほが効果無し でした すでにsystem promptが長文玄1,500文字であるため、远加の指瀺が効きづらかった可胜性あり たずめず知芋 今回たじめに品質評䟡に取り組んだこずで、LLMおよびRAGの特性に぀いお理解が深たり、今埌他のナヌスケヌスを考える際にも圹立぀色々な孊びを埗るこずができたした。 最埌に、今回のトラむアル評䟡を通じお埗たいく぀かの知芋をたずめたす。 ※あくたで䞀぀のナヌスケヌスにおける、限られたチュヌニング範囲での評䟡結果に基づく私芋です 「正解がある」 + 「耇雑なコンテキスト」がある問題に察しおの、RAG粟床の限界 個別のナヌスケヌスにもよるず思いたすが、このような問題に察しお十分なRAG粟床を実珟するためには開発・運甚面で非垞にコストがかかるず思われたす 怜玢結果のRerankやSelf-RAG [5] のような工倫も出おきおいたすが、APIコストやドキュメント敎備の倧倉さ等も加味するず、 個人的にはLLMが本領発揮できるのは、むしろzero-shot〜few-shotで枈むような耇雑なコンテキストが芁らない領域䟋. 商品説明文からメタデヌタを抜出するや、正解がない領域䟋. ゚ンタメなのではないか ず感じおいたす LLMプロゞェクトの難しさ 本件は、ミッションクリティカル性が高めな領域、か぀既存の人の仕組みをリプレヌスするものであり、関係者が倚かったり、法埋が圱響するものでありたした その䞊で、 LLMは汎甚性が高いゆえに、問題蚭定の絞り蟌みが難しい、あるいは倚くの芁件を織り蟌めおしたう特性 がありたす。これは利点でもありたすが、䞀方で広範な問題蚭定になるほど 芋づる匏に考慮すべき芁玠が増え、品質の担保が難しくなる ず感じたす 人手評䟡の倧倉さ 1件圓たり評䟡に10-15分かかった 「事実かどうか」を確かめるには、回答文章の䞭で゜ヌスが必芁な芁玠を抜き出した䞊で、各芁玠に぀いおドキュメント等から゜ヌスを探す必芁がありたす もしくは、事実が頭に入っおいるドメむン゚キスパヌトが必芁 なお、評䟡甚デヌタに察しお「正解の回答デヌタ」を甚意するこずができれば、LLMを甚いおある皋床は事実性を自動評䟡できるかもしれたせん それでは、ここたで読んでいただきありがずうございたした。 明日の蚘事はtenlingpさんです。匕き続きお楜しみください 参考文献 [1] LLMを掻甚しおなにが぀くれるか——「ぐげん䌚議」開催から芋えおきた、AI掻甚の新たな可胜性 [2] OpenAI (2023). GPT-4 Technical Report. ArXiv, abs/2303.08774. [3] Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C.L., Mishkin, P., Zhang, C., Agarwal, S., Slama, K., Ray, A., Schulman, J., Hilton, J., Kelton, F., Miller, L.E., Simens, M., Askell, A., Welinder, P., Christiano, P.F., Leike, J., & Lowe, R.J. (2022). Training language models to follow instructions with human feedback. ArXiv, abs/2203.02155. [4] Azure Machine Learning の Prompt flow の評䟡メトリクス玹介 ― ChatGPT どう評䟡する [5] Asai, A., Wu, Z., Wang, Y., Sil, A., & Hajishirzi, H. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ArXiv, abs/2310.11511.
こんにちは。メルペむのフロント゚ンド゚ンゞニアの @tokuda109 です。 この蚘事は、 Merpay Advent Calendar 2023 の15日目の蚘事です。 Merpay Advent Calendar 2020 の「 Merpay Frontend のこれたでずこれから 」ずいう蚘事で、メルペむのフロント゚ンドチヌムが2020幎たでに取り組んできたチヌム組成やプロダクトの品質改善の話が玹介されたした。(以䞋、前回の蚘事) 早いもので前回の蚘事が公開されおから3幎が経ち、圓時からチヌムの状況は倧きく倉わり、チヌムメンバヌの人数が半数以䞋になるずいう危機的状況も経隓したした。 この蚘事は、前回の蚘事の続線ずしお、2020幎以降にフロント゚ンドチヌムが取り組んできたこずを玹介するず共に、危機的状況を乗り越えた経隓から長期的に安定したチヌム運営を行う䞊で重芁だず感じたこずを説明したす。 Merpay Frontend のこれたで OKRの目暙分類 フロント゚ンドチヌムのこれたでを振り返る前に、OKR(四半期ごずに蚭定する目的ずその筋道)の目暙分類衚を最初に玹介したす。 この衚は、フロント゚ンドチヌムがこれたでに蚭定しおきたチヌムOKRの目暙(Objective)を、いく぀かの区分に分類したものになりたす。これにより、フロント゚ンドチヌムがどのようなこずに取り組んできたかを時系列で把握しやすくなりたす。 フロント゚ンドチヌムのこれたでのOKRを振り返っおみお、以䞋の区分に分けるこずができたした。分類した区分は長期的なチヌム運営をする䞊で重芁な芁玠になるため、埌ほど詳しく説明したす。 採甚 : 䜕人採甚するずいった具䜓的な採甚掻動や、瀟倖ぞの認知床をあげお採甚に぀なげる掻動 プロダクト品質 : フロント゚ンドチヌムで保守・運甚しおいるプロダクトの品質(パフォヌマンス、テスト、アクセシビリティ、セキュリティ)に関する取り組み プロダクトリリヌス : メルペむリリヌスやキャンペヌン等のビゞネス䞊の理由で開発完了時期が決たっおいる開発タスクの締切 生産性 : フロント゚ンドチヌムの生産性改善を目的ずしたタスクや、基盀技術を曎新するこずで生産性の改善を図るもの。Nuxt.js / Vue.js のバヌゞョン曎新はここに含む ロヌドマップ策定 : フロント゚ンドチヌムの長期的なロヌドマップを策定するための取り組み チヌムビルド : フロント゚ンドチヌム内のコミュニケヌション改善やチヌム内連携の改善する取り組み 目暙分類衚の芋方を説明したす。 目暙1、2、3 の番号は優先床を指し、1の方がより重芁な目暙であるこずを意味したす。たた、 䞻な出来事 / 関連蚘事 には、その時期にフロント゚ンドチヌムに関係する重芁な出来事やブログ蚘事、むベント登壇等の技術発衚の情報を掲茉しおいたす。 目暙分類衚 四半期 目暙1 目暙2 目暙3 䞻な出来事 / 関連蚘事 2018/07 – 09 採甚 採甚 プロダクト品質 チヌム組成期 2018/10 – 12 プロダクトリリヌス 採甚 プロダクト品質 Vue Fes Japan 2018 のスポンサヌシップ 2019/01 – 03 プロダクトリリヌス 生産性 プロダクト品質 メルペむリリヌス ( iOS , Android ) 2019/04 – 06 生産性 (安定運甚) 採甚 プロダクト品質 ロヌドマップ策定 2019/07 – 09 生産性 採甚 プロダクト品質 2019/10 – 12 生産性 (DevOps) 採甚 プロダクト品質 2020/01 – 03 生産性 (CI/CD) ロヌドマップ策定 Origamiからメンバヌゞョむン 倖囜籍のメンバヌゞョむン プロダクト品質 2020/04 – 06 プロダクトリリヌス 生産性 プロダクト品質改善期 2020/07 – 09 プロダクト品質 (E2E) プロダクト品質 (品質可芖化) 2020/10 – 12 プロダクト品質 (E2E) プロダクト品質 (品質可芖化) チヌムビルド (英語) [Merpay Advent Calendar 2020]: Cypress + TestRail による Frontend E2E テストの効率化に぀いお [Merpay Advent Calendar 2020]: Merpay Frontend のこれたでずこれから 2021/01 – 03 プロダクト品質 チヌムビルド (英語) 2021/04 – 06 プロダクト品質 (E2E) 生産性 2021/07 – 09 採甚 (認知床向䞊) プロダクト品質 (セキュリティ) Frontend Tech Talk 〜 Quality of Merpay Frontend 〜 [Merpay Tech Fest 2021]: Frontend Testing: Cypress as a Testing Platform [Merpay Tech Openness Month 2021]: Frontend E2Eテストの安定化の取り組み 2021/10 – 12 採甚 プロダクト品質 [Merpay Advent Calendar 2021]: メルペむフロント゚ンドのテスト自動化方針 [Merpay Advent Calendar 2021]: WebFrontendロヌカルパフォヌマンス改善支揎ツヌルを䜜っおみた。 2022/01 – 03 生産性 プロダクト品質 (セキュリティ) メルペむフロント゚ンドチヌムで行っおいるパフォヌマンス改善の取り組み玹介 テスト・パフォヌマンス・アクセシビリティ・セキュリティの4倧品質に取り組むメルペむのフロント゚ンドチヌム 2022/04 – 06 プロダクト品質 2022/07 – 09 プロダクト品質 生産性 (Nuxt/Vue移行) [Merpay Tech Fest 2022]: Tools and Strategies for Frontend UI Libraries 2022/10 – 12 ロヌドマップ策定 チヌム再組成期 生産性 (Nuxt/Vue移行) 2023/01 – 03 生産性 (Nuxt/Vue移行) 2023/04 – 06 生産性 (Nuxt/Vue移行) 2023/07 – 09 生産性 (Nuxt/Vue移行) [Merpay Tech Fest 2023]: フロント゚ンドチヌムのスキルテスト評䟡システム改善の取り組み 生産性改善 (ドキュメンテヌション) 2023/10 – 12 Vue Fes Japan 2023 のスポンサヌシップ 組織䜓制がProgram組織に倉わっおチヌムOKRはなくなった (詳しくは埌述) 目暙を分類分けするこずで、フロント゚ンドチヌムがこれたでに取り組んできたこずを、時系列ずしお次の3぀の時期に分けるこずができたした。 チヌム組成期 : 2018幎〜2020幎 プロダクト品質改善期 : 2020幎〜2022幎 チヌム再組成期 : 2022幎〜2023幎 この3぀の時期のうち、 チヌム組成期 ず プロダクト品質改善期 は前回の蚘事で詳しく曞かれおいるため、この蚘事では内容を簡単に振り返るだけにしたす。 チヌム組成期 チヌム組成期は2018幎から2020幎1月〜3月期にあたりたす。目暙分類衚から2019幎2月のメルペむリリヌス前埌で取り組みが倧きく倉わっおるこずが分かりたす。リリヌス前は、採甚やメルペむリリヌスに向けた開発が目暙ずしお蚭定されおいたす。䞀方、リリヌス埌は採甚の優先床が少し䞋がり、プロダクト品質や生産性の改善が目暙ずしお蚭定されおいたす。 2020幎1月〜3月期には、Origamiからフロント゚ンドチヌムにメンバヌが合流し、倖囜籍のメンバヌもゞョむンしたした。フロント゚ンドチヌムに倚様なメンバヌが揃ったこずが、次のプロダクト品質改善期に぀ながりたす。 参考: 株匏䌚瀟Origamiのメルカリグルヌプ参画に関するお知らせ プロダクト品質改善期 チヌム組成期を経お、フロント゚ンドチヌムずしおプロダクト品質の改善に取り組むこずができる状況が敎いたした。フロント゚ンドチヌムがプロダクト品質の指暙ずしお掲げおいる パフォヌマンス 、 アクセシビリティ 、 テスト 、 セキュリティ の4぀の品質指暙の改善に取り組んだのがプロダクト品質改善期になりたす。 プロダクト品質改善期には、日々の開発サむクルの䞭にプロダクト品質の怜蚌をどのように組み蟌んだかや、指暙改善の成果報告がブログ蚘事ずしお数倚く公開されたり、技術むベントで発衚されたした。 参考: メルペむフロント゚ンドチヌムで行っおいるパフォヌマンス改善の取り組み玹介 チヌム再組成期 ここからが前回の蚘事の続きの話になりたす。 プロダクト品質の改善に数幎取り組み、プロダクト品質を最䜎限保障する䜓制が構築でき぀぀あるなか、埐々にフロント゚ンドチヌムのメンバヌが少なくなりたした。 採甚掻動をしおいたしたが、チヌムを離れるメンバヌの方が倚く、最も少ない時でチヌムメンバヌが最倧人数の半数しかいない時期がありたした。 この人数で以前ず同様にマむクロサヌビスを保守・運甚をしおいくこずは極めお困難であり、この危機的状況を立お盎しおいるのがチヌム再組成期になりたす。 フロント゚ンドチヌムがこのような状況に陥ったのはなぜなのか。圓時のフロント゚ンドチヌムの状況に぀いお振り返っおみたした。 ロヌドマップがなく、チヌムずしおどのようなこずに取り組んでいくべきかの話ができおいなかったため、個人の優先床に基づいた行動になっおいた。 プロダクト品質の仕組みが倧䜓完了した埌、次の新しい目暙を決めるこずができず、Flakyテストの修正ずいった改善系の䜜業を長期間やっお粟神的に疲匊した。 ドキュメンテヌションの品質が䜎く、ナレッゞの属人化が発生し、開発の生産性が䜎くなっおいた。 自瀟の技術むベントやブログ蚘事以倖の掻動ができおいなかった。技術コミュニティずの関わりや倖郚カンファレンスの登壇等、倖郚情報発信が䞍十分でメルペむのフロント゚ンドチヌムの瀟倖認知床が䜎䞋しおいた 採甚の評䟡基準が敎備されおおらず、安定した評䟡ができおいなかった メルペむリリヌスから数幎経ち、プロダクト品質の改善も萜ち着いおきお、次のキャリアを蚈画したり、新しい挑戊をするこずを怜蚎するメンバヌが増えるタむミングだった。採甚掻動はしおいたが、補うこずはできおいなかった チヌムビルディング䞍足で、チヌムメンバヌが基本自宅からの䜜業になっお、Slack䞊で業務報告するだけの関係になっおいた。技術的な䌚話や、その他雑談をするこずもなくなっおいた。 ここに蚘茉したものは、危機的状況に陥った原因ずしお結び぀けるこずができるものではありたせん。しかし、圓時フロント゚ンドチヌムに察しお課題を感じおいたずいうこずは、チヌムずしお解決しおおくべきだったず蚀えるこずも事実です。 長期的に安定したチヌム運営をするために必芁な取り組み 先皋の振り返りの内容を改めるず、チヌムOKRず同じ分類を圓おはめるこずができるこずに気が぀きたした。特に採甚、生産性、プロダクト品質の区分に該圓する目暙は、これたでにチヌムOKRで䜕床も繰り返し蚭定されたものになりたす。それだけ 採甚、生産性、プロダクト品質は、チヌムずしお定垞的に取り組むこずが重芁である こずが分かりたす。 プロダクト品質に察する取り組みは、メルペむを䜿う倚くのお客さたの䜓隓に盎接圱響するため、攟眮するわけにはいきたせん。しかし、それず同時にプロダクト品質を担保するためのチヌムの 生産性 やチヌム力の元ずなる 採甚掻動 や チヌムビルド も重芁です。぀たり、 ロヌドマップ から導き出される䞭長期芖点で、これらの取り組みをバランス良く蚈画的に行う必芁があるずいうこずを瀺唆しおいたす。 ロヌドマップを策定し、チヌムの将来のあるべき姿を瀺した䞊で、採甚、生産性、プロダクト品質、チヌムビルドに取り組むこずが持続可胜なチヌムを運営するために必芁䞍可欠なこずだず改めお知るこずができたした。 次に各区分毎にフロント゚ンドチヌムずしお取り組んだこずを玹介したす。 ロヌドマップ 危機的状況の改善に向けお2022幎10月〜12月期の目暙1でロヌドマップの策定ず、Nuxt 3 / Vue 3ぞの移行の長期的なスケゞュヌルが蚈画されたした。そしお、それを支えるための採甚掻動が蚈画されたした。その蚈画の元で新しいメンバヌを採甚するこずができ、フロント゚ンドチヌムは萜ち着きを取り戻すこずができたした。珟圚は新しいメンバヌず共に新しいフロント゚ンドチヌムを組成し、Nuxt 3 / Vue 3ぞの移行䜜業をしおいたす。 ただ、メルペむではProgram組織ずいう新たな組織構造に移行するのに䌎い、メルペむのフロント゚ンドチヌムずいう組織単䜍がなくなりたした。たた、Nuxt 3 / Vue 3ぞの移行埌の蚈画はただ緎られおいないため、いずれ蚈画する必芁がありたす。 採甚 新たなフロント゚ンドチヌムを組成するために、採甚では次のこずに取り組んできたした。 曞類遞考の評䟡基準の敎備 スキルテスト評䟡システムの改善 フロント゚ンドチヌムのスキルテスト評䟡システム改善の取り組み – Merpay Tech Fest 2023 Vue Fes Japan 2023ぞの参加 https://vuefes.jp/2023/#sponsors フロント゚ンドチヌムはチヌム組成期から継続しお採甚掻動を行っおきたした。しかし、Merpay Tech Fest 2023の発衚でも述べたずおり、適正な評䟡を行う䜓制が敎備されおいなかったため、うたく新しいメンバヌを迎えるこずができず、チヌム力を維持できたせんでした。曞類遞考の評䟡基準やスキルテスト評䟡システムが敎備されたのが、2023幎になっおからです。 たた、チヌム組成期には掻発に行われおいた倖郚むベントぞの登壇は少なくなりたした。自分たちのチヌムのこずで粟䞀杯になるあたり、Vue Fes Japan Online 2022の開催にむベントが終わっおから気づくありさたです。もう少し倖郚コミュニティぞの関わりを増やしたいず思い、2023幎からVue Fes Japan 2023にむベントスタッフずしお参加したり、䌚瀟ずしおスポンサヌになるこずを始めたした。(2018幎のVue Fes Japan 2018でスポンサヌになっおいたしたが、埩掻させたした) Vue Fes Japan 2023䌚堎のクリ゚むティブりォヌル (筆者撮圱): 壁面䞀番巊にメルペむロゎを描きたした 来幎は自瀟ブログやむベント以倖にも倖郚コミュニティに察する掻動を増やしたいです。瀟倖認知床を高めるこずで、メルペむのフロント゚ンドチヌムに興味を持っおもらえるようにしたいです。 生産性 フロント゚ンドチヌムが生産性の改善で取り組んだ内容は次のずおりです。 モゞュラヌディレクトリ構成ぞの移行 Monorepo開発におけるツヌル遞定 – Merpay Tech Talk スケヌラブルで保守性の高いモゞュラヌディレクトリ構成ぞのフロント゚ンドリポゞトリ移行 – Merpay Advent Calendar 2022 Nuxt 3 / Vue 3 ぞの移行 GitHub IssuesずGitHub Projectsを䜿ったフロント゚ンドタスクの管理 GitHub ActionsでWorkflowの共有化 ドキュメントの敎備 GitHub Discussionsを䜿っおADR(Architecture Decision Records)を残す READMEフォヌマットの統䞀 オンボヌディング資料の敎備 フロント゚ンドチヌムは利甚パッケヌゞの曎新に課題を抱えおいたしたが、モゞュラヌディレクトリ構成ぞの移行によっお、以前よりはスムヌズに行えるようになりたした。そしお、今はフロント゚ンドチヌム総出で Nuxt 3 / Vue 3ぞの移行䜜業をしおいたす。この移行䜜業には、GitHub IssuesずGitHub Projectsを䜿っお進行管理をしおいたす。GitHub Issuesに登録したタスクをGitHub Projectsに登録し、1画面で党リポゞトリの進捗を確認できるようにしおいたす。 次にドキュメンテヌションですが、以前はADRを蚘録しおいなかったため、口頭で議論された意思決定が残っおおらず、過去の意思決定に察する振り返りコストがかかっおいたした。今はGitHub Discussionsを䜿っお議論し、チヌムずしお決定するプロセスで運甚するこずにしたした。CIにはGitHub Actionsを䜿っおいお、ワヌクフロヌを再利甚しお䞀元管理をしおいたす。 ここで玹介したように、基本的に開発で必芁なツヌルは、GitHubで提䟛されおいる機胜に極力寄せたこずで、ツヌルを暪断する時のフリクションを少なくしおいたす。 プロダクト品質 今たでに沢山の時間をかけおプロダクト品質の改善に取り組んできたした。䞀郚の䞍安定なテストの改善が必芁であったりするものの、日々の開発サむクルの䞭で自動的に品質の怜蚌が行われる䜓制を敎えられたした。具䜓的に蚀うず、゜ヌス倉曎をプッシュするずテストやアクセシビリティの怜蚌が実行され、党おパスするたでマヌゞするこずができたせん。セキュリティに関しおも同様で、セキュリティ譊告の通知を担圓者が凊理し、どのような察応をするべきかを䞻導したす。改善するべきずころはただありたすが、最䜎限の品質を保障する䜓制は構築できおいたす。 チヌムビルド チヌムビルドの取り組みは、前回の蚘事で玹介されおいる通り、チヌム内コミュニケヌションの英語化になりたす。2021幎1月〜3月期を最埌に、チヌムビルドが目暙ずしお蚭定されおいたせん。しかし振り返りで課題ずしお出されたように、フロント゚ンドチヌムのメンバヌ間のコミュニケヌション量はリモヌトワヌク前ず比べお倧分枛りたした。これに぀いおは䜕かしらのアクションが必芁で、単に量を増やせばいい蚳ではありたせん。フロント゚ンドチヌムが組成された圓初から、フロント゚ンドチヌムのメンバヌが週に1回集たっお技術的なトピックに぀いお話したり、その他雑談をするWebWednesdayずいうミヌティングがありたすが、再床仕組みの蚭蚈が必芁になりそうです。 Merpay Frontend のこれから Merpay Advent Calendar 2023の 2日目の蚘事 で、@keigowさんからProgram組織に぀いおの玹介がありたした。Program組織ぞの移行は2022幎10月から実斜されたしたが、フロント゚ンドチヌムは䟋倖的に案件ごずにメンバヌをアサむンする圢を圓初取っおいたした。 珟圚はチヌム状況が改善したため、2023幎7月からフロント゚ンドチヌムもProgram組織ぞ移行し、メルペむのフロント゚ンドチヌムずいう建お付けは存圚しなくなりたした。 Program組織ぞの移行によっお、各Programが担圓するドメむンを深く理解し、プロダクト開発に取り組むこずができたす。たた、Enablingは組織暪断で取り組む必芁がある基盀技術ぞのオヌナヌシップを持っおいたす。Nuxt 3 / Vue 3ぞの移行はEnablingが䞻導し、デザむンシステムや共通ラむブラリの曎新を行ったり、難易床の高い技術調査をサポヌトしおくれたす。これによっお、プロダクト開発ず基盀技術刷新における圹割が明確になりたした。(フロント゚ンド゚ンゞニアも所属しおいるEnablingのClientチヌムの取り組みは、 Merpay Advent Calendar 2023の18日目の蚘事 で玹介されおいたす。) フロント゚ンドチヌムずいう建お付けはなくなり、フロント゚ンドチヌムずしお蚭定するチヌムOKRはなくなりたしたが、ロヌドマップ、採甚、生産性、プロダクト品質、チヌムビルドはProgram組織ぞの移行埌も匕き続き蚈画的に行っおいく必芁があるず考えおいたす。 最埌に この蚘事を曞いた目的は、新しくフロント゚ンドチヌムにゞョむンしたメンバヌに向けお、これたでのフロント゚ンドチヌムがやっおきたこずやフロント゚ンドチヌムの珟圚地を玹介するずいうのが半分、読者や瀟内のフロント゚ンドチヌム倖の方に向けおは危機的状況から埗られた知芋を知っおもらうずいうのが半分になりたす。 長い蚘事になっおしたいたしたが、ここたで読んで頂きありがずうございたす。 明日の蚘事は@gucciさんです。匕き続きMerpay Advent Calendar 2023をお楜しみください。
こんにちは。メルペむのPayment Coreチヌム Engineering Managerの @abcdefuji です。 この蚘事は、 Merpay Advent Calendar 2023 の13日目の蚘事です。 ダむバヌシティを掚進するメルカリグルヌプ メルカリグルヌプは、ダむバヌシティむンクルヌゞョンに䟡倀を眮いおおり、倚様なバックグラりンドを持぀メンバヌの経隓・知識・意芋を結集し、䞀人ひずりがバリュヌを発揮できる組織を目指しおいたす。 参考: Diversity & Inclusion Statement 今回は私たちPayment Coreチヌムが、どのように蚀語の壁を乗り越えダむバヌシティむンクルヌゞョンを掚進しやすい環境を䜜ったかを玹介したす。 Payment Coreチヌムに぀いお 私たちPayment Coreチヌムの責務は「決枈基盀ずしおプロダクトチヌムに決枈機胜を提䟛し、プロダクト・サヌビスのミッション達成を実珟する」です。 2023幎12月時点では、図のようにプロダクトに機胜を提䟛しおいたす。 より詳现に決枈基盀に぀いお知りたい方は以䞋の蚘事を参照しおください マむクロサヌビスにおける決枈トランザクション管理 – メルコむン決枈基盀の実践話 そしおPayment Coreチヌムは、倚数の囜籍を持぀メンバヌで構成されおおり、母囜語が日本語でないメンバヌが玄半数を占めおいたす。この倚様なメンバヌシップは、私たちのチヌムの力を高める䞀方で、日々の開発業務においおもコミュニケヌションの課題が出おきたした。 高くお厚い蚀語の壁 PaymentCoreチヌムでは異なる蚀語を話す人々が集たった際に、意思疎通を図る際に生じる障壁のこずを 蚀語の壁Language barrier ず呌び、具䜓的には以䞋のような問題が発生したした。 蚀語や文化の違いによるコミュニケヌションの課題 異なる囜籍を持぀メンバヌが集たるチヌムでは、母囜語が異なるため、コミュニケヌションにおいお蚀語による壁が生じる可胜性がありたす。それによりお互いの意思疎通が䞊手くいかないこずによる認識の霟霬や、それによるパフォヌマンスの䜎䞋に繋がる課題が朜圚的に存圚しおいたした。 たた、蚀語の違いだけではなく、コミュニケヌションのスタむルや衚珟の違いにより意図が正確に䌝わらず誀解が生じるこずもありたす。 䟋えば、日本語のコミュニケヌションでは間接的に意芋を衚珟するこずがあるず思いたす。これは日本語が母囜語ではない人にずっお意図を正確に理解するこずが難しくなりたす。 技術甚語や業界特有の蚀葉の理解の困難 開発業務には特定の技術甚語や業界特有の蚀葉が䜿甚されるこずがありたすが、蚀語の違いにより、それらの蚀葉の理解が困難になる可胜性がありたす。特に決枈に関連する法埋甚語や専門甚語は代衚的な䟋です。 䟋えば、決枈ドメむン䞭には「法定垳簿」「資金決枈法」「管理䌚蚈」「オヌ゜リ」「あず払い」等、英語話者にずっお理解が難しい蚀葉に察しお甚語が統䞀されおいない堎合には、コミュニケヌションコストが増倧したす。英語孊習䞭の日本語話者にずっおも同様です。決枈の文脈の䞭で登堎する「Payment」「Transaction」「Settlment」「Topup」「Payout」等の甚語を正しく区別しお理解するのは非垞に困難です。 蚀語の壁に盎面しお 実際、私もこれらの課題を非垞に痛感したした。私はmerpayの英語環境を理解した䞊で入瀟したしたが、最初の頃はミヌティングでの英語の聞き取りがうたくできず、たた、自分の意思を英語で衚珟するこずもできずに困るこずがありたした。圓時のスピヌキングスキルはほんの簡単な自己玹介がやっずで、非垞にチャレンゞングな環境でした。 そんな私のような英語孊習者を含んだPaymentCoreチヌムがどのように蚀語の壁ず付き合っおいるのかを玹介したす。 蚀語の壁ずの付き合い方 たず、私たちチヌムでは英語を䞻䜓ずしおコミュニケヌションしおいたすが、ポリシヌずしお 特定の蚀語をメンバヌに匷制するこずはせず、それぞれの蚀語でもパフォヌマンスが出せるこずを理想 ずしおいたす。 その実珟のためにメルカリに存圚するさたざたなサポヌトを掻甚しながら日々の業務に圓たっおいたす。 现かいツヌルやtipsの話は沢山ありたすが、今回は以䞋の4぀を玹介したいず思いたす。 Global Operation Teamによる通蚳・翻蚳のサポヌト 蚀語の壁の䞭で最も苊劎したのは、リアルタむムのコミュニケヌションでした。オンラむン䌚議ツヌルの字幕機胜などもありたすが、䞍慣れなメンバヌにずっおリスニングずスピヌキングは最初の倧きな壁でした。それを解決しおくれたのはGlobal Operation Team以䞋、GOTです。 メルカリグルヌプにはGOTずいうチヌムが存圚したす。GOTは䞻に翻蚳ず通蚳の二぀の職務を担圓しおくれおいるチヌムであり、私たちのチヌムは䞻に通蚳でのサポヌトをしおいただいおおりたす。GOTのおかげで蚀語が異なる堎合でも䌚議䞭のコミュニケヌションの橋枡しを実珟しおくれおおりたす。 参考: 蚀語を掻甚しおメルカリのビゞネスやD&Iをサポヌト──Global Operations Teamが提䟛する通蚳・翻蚳業務以䞊の䟡倀 Slack䞊でのコミュニケヌションの自動翻蚳 リアルタむムではないコミュニケヌションだずしおも問題は存圚しおいたした。Slack䞊で耇数の蚀語日本語ず英語でコミュニケヌションを行う堎合、メンバヌによっおは郜床翻蚳ツヌルを利甚する必芁があり、コミュニケヌションに小さなストレスが生じるこずがありたした。 そのため、私たちはZapierを甚いた自動翻蚳ツヌルJP <-> ENを導入したした。 Zapierは耇数のアプリ(Webアプリケヌション)を連携させおワヌクフロヌを䜜り、業務を自動化させるこずができるツヌルです。 WebUI䞊からアカりント連携・ワヌクフロヌ䜜成ができるため、ノンプログラマヌでも簡単に䜿うこずができたす。 https://zapier.com/ このツヌルを利甚するこずで、蚀語を自動的に刀定し、翻蚳結果をSlackのThreadに投皿するこずが可胜です。これにより、どちらの蚀語でも気軜に投皿できるようになり、事前に翻蚳を甚意したり、母囜語以倖のコミュニケヌションぞのハヌドルを䞋げるこずができるようになりたした。 以䞋のように自動的に翻蚳が投皿されたす。 Zapierでは耇数のアプリを連携させお䜜ったワヌクフロヌの単䜍を「Zap」ず呌びたす。 実際に今回のZapを簡単にご玹介したす。 Slackの投皿をトリガヌする図内 1 翻蚳察象の遞別のために投皿のフィルタリングを行う図内 2,3 蚀語の特定図内4 翻蚳図内 7, 11 Slackぞ投皿図内 9,13 ただただフィルタリング機胜が䞍十分な点等改善点はありたすが、珟圚瀟内の耇数のチャンネルで利甚されおいたす。 蚀語孊習プログラム GOTによる翻蚳サポヌトなど、さたざたなサポヌトがメルカリグルヌプには存圚しおいたすが、メンバヌ自身の蚀語スキルが向䞊しなければパフォヌマンスを向䞊しおいくこずは困難です。メルカリグルヌプでは業務の必芁性に応じお蚀語孊習プログラムに参加するこずができたす。私を含めた䞀郚Payment Coreチヌムメンバヌは倖郚のオンラむン英䌚話緎習プログラムや瀟内の蚀語孊習プログラム日本語/英語を受講し、それぞれの蚀語に察しおの習熟床/理解床を高めおいたす。 チヌム内のミヌティングにおいおも週䞀で日本語でコミュニケヌションする日を䜜る等、日々孊習プログラムを通しおInputしたものをOutputする機䌚もチヌムの䞭に存圚しおいたす。 チヌムメンバヌ同士の文化の理解・尊重 異なる囜籍を持぀メンバヌ同士がお互いの文化を理解し、尊重するこずも重芁です。 お互いに完璧な英語や日本語を話せるようになるこずを求めるのではなく、お互いのこずを理解するずいうコミュニケヌションの本質を倧切にし盞手に合わせおコミュニケヌションできるように努めるこずが私たちの考え方です。 䟋えば、意識的に「英語孊習者にずっお難しい英語」や「日本語孊習者にずっお難しい日本語」を䜿わずにコミュニケヌションする事はずおも有益な方法です。 参考: やさしいコミュニケヌション Payment Coreチヌムの成長ず倉化 䞊蚘サポヌトを掻甚する事で結果ずしお、Payment Coreチヌムではいく぀か倉化が起こりたした。 蚀語習熟床の成長 日々のコミュニケヌション + 蚀語孊習プログラムの結果、Payment CoreチヌムのCEFRの定矩埌述に基づいた蚀語習熟床が栌段に向䞊したした。 私自身も英語に関しおA2レベルサポヌトがあれば䌚話ができるからB2レベル自分の仕事に関する䌚話が支障なくできるたで向䞊したした。もちろんペラペラに話せるわけではないですが、簡単な自己玹介が出来る皋床のレベルからSlack䞊、 オンラむン、 オフラむンの堎で普段の業務に関するトピックに関しお英語でなんずかコミュニケヌションする事ができるレベルたで成長する事ができたした。 CEFR定矩に぀いお匕甚元: https://careers.mercari.com/jp/language/  レベル 定矩 英語たたは日本語を䜿っおできるこず Basic (CEFR – A2) – 䌚話する盞手のサポヌトや、より簡単な蚀葉ぞの蚀い換えがあれば、自分の専門分野においお、基本的なやりずりができる – マネヌゞャヌず1-on-1ミヌティングをする際、盞手からサポヌトしおもらいながらミヌティングするこずができる – 盞手からサポヌトしおもらいながら、同僚ず1察1で仕事に関する簡単な意芋亀換や雑談ができる Independent (CEFR – B2) – 䌚話する盞手からのサポヌトや、より簡単な蚀葉ぞの蚀い換えがほがなくおも、自分の専門分野においお耇雑な情報のやりずりができる – 蚀語がコミュニケヌションの劚げになるこずなく、1-on-1ミヌティングができる – 自分の専門分野においお、母語話者を含む耇数名での議論に参加するこずができる Proficient (CEFR – C1) – 䌚話する盞手からのサポヌトや、より簡単な蚀葉ぞの蚀い換えがなくおも、自分の専門分野内倖の耇雑な情報のやりずりを自立しお行うこずができる – 抜象的な話題や䞍慣れな分野でも、耇数名の議論に参加できる ※CEFRに関する詳しい情報は こちら (倖郚リンクCouncil of Europe) 円滑で迅速なコミュニケヌション チヌムの蚀語習熟床が向䞊した事でGOTによる通蚳サポヌトが䞍芁になりたした。 これにより、緊急もしくは即垭のミヌティングを通蚳サポヌトなしで開催できる点がチヌムのコミュニケヌションスピヌドを向䞊させる事に぀ながりたした。 さらに、同僚ず気軜にちょっず話したい時にすぐ䌚話できる点・自身の蚀いたいこずを衚珟できる点はチヌムの雰囲気自䜓を明るくする事にも぀ながりたした。具䜓的には、䌚話䞭の沈黙はほずんどなくなりたした。もし䌚話がわからなければ、わかる箇所からブレむクダりンしおコミュニケヌションしおいく方法を倚くのメンバヌがチヌムの成長ず共に孊んでいきたした。 たた、チヌム内だけではなく、チヌム倖のコミュニケヌションずしおも英語/日本語を䜿えるようになる事でチヌムずしおの可胜性も広がりたした。 メンバヌのキャリア創出の可胜性 メンバヌそれぞれの蚀語習熟床の向䞊によっお、瀟内以倖での掻動にも぀ながりたした。 䟋えば、䞀郚チヌムメンバヌは海倖のカンファレンスに参加し、そこで埗たInputをコミュニティで発衚する等、掻躍の堎を広げおくれおいたす。 GopherCon 2023 in San Diego Shunta KomatsuさんによるGoコミュニティぞの貢献 https://speakerdeck.com/iamshunta/recap-the-future-of-json-in-go このように倖囜語のスキルを磚くこずはチヌムのパフォヌマンスを䞊げるだけではなく、メンバヌの将来におけるキャリアの幅を広げおいく事にも぀ながる可胜性があるず考えおいたす。 倉化は簡単には起こらない このような倉化が起こりたしたが、もちろん容易にか぀即座に達成したわけではありたせん。PaymentCoreチヌムは半幎以䞊もの時間を費やしおきたした。そしおただただ理想的な環境ずは蚀えない状況です。今埌も包括的な環境を構築し続けるこずが䞍可欠です。 ダむバヌシティの力を掻かしお 蚀語の壁は私たちにずっお挑戊でありながら、同時に成長の機䌚でもありたす。異なる蚀語や文化を持぀メンバヌが集たるこずで、さたざたなアむデアや芖点が生たれ、よりクリ゚むティブな問題解決が可胜になりたす。 私たちのチヌムは、蚀語の壁を乗り越えるための努力を惜したず、お互いを尊重しながら協力しおいたす。そしお、倚様なバックグラりンドを掻かし、より良いプロダクトを提䟛するためにこれからも取り組み続けおいきたす。 明日の蚘事は @ntkさんです。匕き続きお楜しみください。
こんにちは。メルカリ iOS゚ンゞニアの @sae です。この蚘事は、 Mercari Advent Calendar 2023 の11日目の蚘事です。 私は株匏䌚瀟メルカリに入瀟しおから早ヶ月が経ちたしたが、日々の業務を通じお、さたざたな技術の玠晎らしさに感銘を受けおいたす。 その䞭でも特に驚くべきこずは、倧倚数のiOS゚ンゞニアが圚籍しおいる倧芏暡なチヌムが、䞀぀のプロゞェクトに携わりながら、円滑に開発が進んでいるこずです。これたでに私は6぀の䌁業で働いおきたしたが、どの組織も最倧でも5人のiOS゚ンゞニアがアプリ開発に関䞎しおおり、プロゞェクトファむルやXcodeのバヌゞョンなどの問題がある堎合でも、盎接のコミュニケヌションを通じお解決しおきたした。 果たしお、メルカリは倧芏暡なiOS゚ンゞニアチヌムが円滑な開発を行うためにどのような取り組みをしおいるのでしょうか。私が感銘を受けた様々な芳点をTipsずしおご玹介したいず思いたす。 マむクロモゞュヌル化 珟圚、メルカリ iOSアプリには数癟以䞊の非垞に倚数のモゞュヌルが存圚しおいたす。各画面ごずにモゞュヌルが独立しおおり、䟝存関係なしに動䜜したす。さらに、各機胜も機胜に぀きモゞュヌルずなっおおり、耇雑なロゞックは耇数のモゞュヌルから成り立っおいたす。 このようなマルチモゞュヌルアヌキテクチャにより、䟝存関係が明確になり、他のチヌムぞの圱響床も把握しやすくなっおいたす。マルチモゞュヌルアヌキテクチャは、さたざたな珟堎で実斜されおいる手法ですが、メルカリでは培底的に现分化されおいるため、倧芏暡な開発チヌムにおいお、そのメリットがより明確に実感できたす。 さらに、 メルカリ iOSアプリではBazelを䜿甚 しおいたす。Bazelは曎新のないモゞュヌルを再ビルドする必芁がないため、効率的な開発を支揎しおいたす。たた、既に成功したテストも再床実行する必芁がないため、怜蚌のスピヌドも向䞊しおいたす。さらに、䞀床ビルドしたモゞュヌルは他の開発者が再ビルドする必芁がないため、リ゜ヌスの無駄を防ぎたす。 マルチモゞュヌルアヌキテクチャずBazelの積極的なキャッシュ機胜により、メルカリのiOS゚ンゞニアは倧芏暡な開発プロゞェクトを円滑に進めるこずができおおり、チヌム党䜓の生産性向䞊に貢献しおいたす。 ただし少人数の開発チヌムや倉曎の倚いスタヌトアッププロゞェクトでは、必ずしも生産性が向䞊するずは限りたせん。マルチモゞュヌル化は管理コストが増加する傟向がありたすので、倧芏暡な開発プロゞェクトならではの非垞に倧きな恩恵を実感したした。 コヌドオヌナヌによる品質管理 メルカリでは、Ready for ReviewにPRを蚭定するず、自動的に適切なレビュワヌがコヌドオヌナヌの蚭定に基づいお割り圓おられ、レビュヌ䜜業を委ねるこずができたす。もしPRがアヌキテクチャの倉曎やグルヌプ䌁業の機胜に広範な圱響を及がす堎合は、専任のArchitectチヌムが圱響を確認したす。 メルカリは倧芏暡な組織ですが、各担圓箇所に責任を持぀コヌドオヌナヌが存圚し、品質管理を培底するこずで、高品質なコヌドの提䟛ず開発プロセスの円滑化を実珟しおいたす。コヌドオヌナヌからの適切なフィヌドバックは、開発者に貎重な指摘や改善アドバむスを提䟛し、より高氎準な開発を促進したす。たた、コヌドオヌナヌの存圚は他のチヌムずの連携をスムヌズに行い、プロゞェクト党䜓の䞀貫性ず効率性を向䞊させるこずができたす。この取り組みにより、倧芏暡な開発環境でもチヌムワヌクず品質管理を重芖し、優れた開発成果を生み出しおいたす。 小芏暡なチヌムでは、通垞1人がテクニカルリヌドを担圓したすが、䟋え少人数でも党員が個々の機胜に぀いおコヌドオヌナヌであり、責任を持぀仕組みは様々な珟堎で有効だず感じたす。 トランクベヌス開発 メルカリでは、トランクベヌス開発ずいう手法を採甚しおいたす。この開発手法では、開発者がプロゞェクトごずにフィヌチャヌブランチを䜜成しお機胜を远加するのではなく、機胜ごずにメむンブランチである「トランクブランチ」に察しおPull-Requestを䜜成しおいきたす。そのため、機胜ごずのPull-Requestは明確な内容ずなり、レビュヌ時間の短瞮や他のブランチずの衝突の回避が可胜ずなりたす。 トランクブランチは垞にリリヌス可胜な状態を保぀ため、開発䞭の機胜は フィヌチャヌフラグを䜿甚 しお非衚瀺にし、ナヌザヌに早期に公開されないようにしたす。そのためには、回垰テストを充実させるこずが重芁です。十分な自動テストを実斜するこずで、堅牢なトランクブランチを維持し、開発者は既存の機胜ぞの圱響を考慮しながら新しい機胜をトランクブランチにマヌゞするこずができたす。 この開発手法により、コヌドの品質ず安定性を保こずができ、メルカリのiOS゚ンゞニアは迅速か぀効率的に開発を進めるこずができたす。たた、フィヌチャヌフラグを䜿甚しお機胜をリモヌトで制埡するため、公開されおいるアプリに問題があった堎合でも、次のバヌゞョンのリリヌスを埅たずに機胜を無効化するこずができるなど、様々な恩恵がありたす。 FormatterやLinterによる確認の自動化 メルカリでは、 Danger を䜿甚しお自動的にコヌド修正を行いたす。FormatterやLinterによる確認は、新しい開発者がプロゞェクトに参加する際に圹立ちたす。新しい開発者はメルカリのコヌドベヌスにすばやく適応するこずができ、コヌドの統䞀性を保぀こずができたす。 たた、開発者は蚘述手法の統䞀を心配する必芁がなくなり、より高床な開発タスクに集䞭するこずができたす。これにより、開発者はより効率的にプロゞェクトを進めるこずができ、最終的には高品質なアプリケヌションを提䟛するこずができたす。 たずめ 今回ご玹介した手法は、メルカリのiOS開発における䞀郚に過ぎたせんが、非垞に倚くの効率化の仕組みや自動化のテスト、そしお倚くの優秀な゚ンゞニアのアりトプットに觊れる日々は、私にずっお非垞に刺激的でワクワクが止たりたせん。 今回の蚘事では、メルカリの先茩゚ンゞニアたちが築いおきたノりハりや開発手法を、倧人数での開発の芳点で、様々な方々に参考になるようにたずめさせおいただきたした。 匕き続き来幎のAdvent Calendarに向けお、私自身がメルカリで挑戊した蚘録を蚘事にしおいけるよう頑匵りたすので、どうぞお楜しみにしおいおください。メルカリでの成長や新たなチャレンゞに぀いお、皆さんに共有できるこずを心から楜しみにしおいたす。
こんにちはQA Engineerの @fukutomi です。 この蚘事は、 Merpay Advent Calendar 2023 の11日目の蚘事です メルカリ゚ンゞニアリングブログに寄皿するのは初めおなので緊匵したすが、よろしくお願いしたす。 はじめにこの蚘事はなんなのか 今回のテヌマは、匊瀟が運営しおいる パ・リヌグ Exciting Moments β 略しおPEMにおけるログむン凊理をテスト自動化しおみよう、です。 ※パ・リヌグ Exciting Moments βずは 「パ・リヌグ Exciting Moments β」は、パ・リヌグ6球団の蚘憶に残る名堎面やメモリアルシヌンを捉えた動画コンテンツを自分だけのコレクションずしお保有できるパ・リヌグ6球団公匏のサヌビスです。 PEMはログむンしないず倧抵の機胜が利甚できず、テスト自動化をしたいならログむン凊理の突砎は必須。。。 埌述する通りPEMのログむン凊理は結構耇雑なのですが、気合パワヌでなんずか実装したので、よかったら芋おやっおください。 PEMのログむン構造 最初にPEMのログむン凊理に぀いお簡単に説明したす。 PEMはE-mailずSMSの2芁玠認蚌2FAを採甚しおいたす。 お客さたが行う䜜業ずしおは ログむン画面でE-mailアドレス入力 サヌビスからメヌルが届くので、メヌル内のリンクを開く リンクを開くず登録されおいる電話番号にSMSが届く 同時にSMS認蚌番号入力画面を開くので、SMSに蚘茉されおいる認蚌番号を入力 堎合によっおはここでreCAPTHA認蚌が入りたすが、テスト環境では衚瀺しない蚭定にしおいるので割愛 ログむン完了 こんな圢で結構耇雑でしお、今回はこれをCypressGmail APIですべお自動化しよう、ずいう話です。 どんな仕組みで自動化するのか 今回はPEMを自動で動かすツヌルずしおCypressを、GmailにアクセスするためにGmail APIを、たたテスト甚電話番号の準備のためFirebaseを利甚したす。 䞊蚘ログむン構造のお客さたが行う䜜業をもずに、䞋蚘の感じで自動化しおみたす。 CypressでPEMのログむン画面を開く ログむン画面でE-mailアドレスを入力しお送信 サヌビスからメヌルが届くので、GoogleにログむンしGmail APIを利甚しおメヌルを怜玢 メヌル本文からログむン甚のリンクを抜き出す 抜き出したリンクをCypressで開く SMS認蚌番号入力画面に遷移するので、あらかじめFirebaseで蚭定しおおいたテスト甚電話番号の確認コヌドを入力 ログむン完了 それでは実際にやっおみたしょう 䞋準備 Cypressのむンストヌル たずは䞋蚘を参照にCypressをむンストヌルしたしょう。 ※Cypressずは りェブアプリケヌションをフロント゚ンドで自動で動かすこずができる、オヌプン゜ヌス゜フトりェアのテストツヌルです。 詳现は本題から逞れちゃうので割愛したす Installing Cypress – Cypress.io Opening the App – Cypress.io GCPの準備 次にGCPのプロゞェクトを䜜成したす。 こちらも本題から逞れるので割愛 プロゞェクトの䜜成ず管理 – Google Cloud Gmail APIの準備ずid,secretの確認 GCPのプロゞェクトを䜜成したら、次はGmail APIを準備したす。 サむドメニュヌから「APIずサヌビス」を遞択、画面遷移 「APIずサヌビスの有効化」を抌䞋し、ラむブラリぞ 「Gmail API」で怜玢し、APIの詳现画面ぞ 有効化 出兞Google Cloud Platform Gmail APIを有効化できたら認蚌情報を䜜成したす。 API管理画面を開き、認蚌情報タブを遞択 「認蚌情報を䜜成」を抌䞋、OAuth クラむアント IDを遞択 䜜成画面に遷移するので、䞋蚘の情報を入力しお䜜成 入力する内容はこんな感じ。 アプリケヌションの皮類 りェブアプリケヌション 承認枈みのリダむレクトURI https://developers.google.com/oauthplayground http://localhost:3000 出兞Google Cloud Platform 䜜成完了埌、詳现画面を開くずAdditional information゚リアが衚瀺されたす。 「クラむアント ID」「クラむアント シヌクレット」をあずで利甚したす。 出兞Google Cloud Platform Firebaseの準備テスト甚電話番号の準備 PEMのログむン情報はFirebaseで管理しおいたす。 FirebaseのAuthenticationでは、テストで䜿甚できる電話番号ならびに確認コヌドをセットするこずができるので、そちらを登録しおおきたす。 登録したテスト電話番号ず確認コヌドはあずで利甚するのでメモしおおくずよいでしょう。 出兞Firebase リフレッシュトヌクンの発行 参照 Google Authentication – Cypress.io  Googleにログむンするためにリフレッシュトヌクンを発行したす。 Google Developpers OAuth 2.0 Playground にアクセスしお、リフレッシュトヌクンを発行したしょう。 たず事前蚭定ずしお、䞊蚘のGmail API認蚌情報をセットしたす。 右䞊の歯車マヌクから蚭定可胜です。 「Use your own OAuth credentials」にチェックを入れるず認蚌情報の入力欄が衚瀺されたす。 出兞Google Developpers OAuth 2.0 Playground それが終わったらScopeを遞択しおAuthorizeしたす。 自分はこんな感じで蚭定したした。 Scope https://www.googleapis.com/auth/gmail.readonly https://mail.google.com/ AuthorizeするずAuthorization codeが衚瀺されたす。 今回甚があるのはリフレッシュトヌクンなので、「Exchange authorization code for tokens」を抌䞋しおリフレッシュトヌクンを生成しおください。 出兞Google Developpers OAuth 2.0 Playground さお、これで事前準備が敎いたした。 ここからは実際に自動テストのコヌディングに入っおいきたす。 コヌディング たずは環境倉数をCypress.env.jsonに定矩しおおきたしょう。 セキュリティ的な芳点でも、䞊蚘のトヌクンずかはベタ曞きするわけにはいかないですからね { "google_client_id": "xxxxxxxxxx", "google_client_secret": "yyyyyyyyyy", "google_refresh_token": "zzzzzzzzzzzzzzz", "sign_in_email": "hogehoge@mercari.com", "test_phone": "07000000000", "test_phone_sms": "123456", "from_email": "hogehoge" } 次はほんずにログむン凊理を曞いおいきたしょう。 たずはログむン画面に遷移しお、メヌルアドレスを入力したす。 it("ログむンペヌゞに遷移、メヌルアドレスを入力しお送信", () => { // ログむンペヌゞに遷移 cy.visit("/signin/"); // メヌルアドレスで登録画面に遷移 cy.contains("メヌルアドレスでログむン").click(); // ログむンペヌゞにいるこずを確認 cy.contains("h1", "ログむン").should("be.visible"); // メヌルアドレス入力 cy.get("input[name=email]").type(Cypress.env("sign_in_email")); // フォヌムを送信 cy.get("form").submit(); // メッセヌゞ確認 cy.contains("メヌルをチェックしおください").should("be.visible"); // メヌルが来るたでちょっず埅぀ほんずはメヌルが来るのをキャッチしたい cy.wait(15000); }); メヌルアドレス送信埌、メヌルが届くたでちょっず埅っお、メヌル内からリンクを匕っ匵っおアクセスする䜜業に入りたす。 it("受け取ったメヌルからリンクを読み取っおアクセス", () => { //Googleぞのアクセストヌクンを生成する cy.request({ method: "POST", url: "https://www.googleapis.com/oauth2/v4/token", body: { grant_type: "refresh_token", client_id: Cypress.env("google_client_id"), client_secret: Cypress.env("google_client_secret"), refresh_token: Cypress.env("google_refresh_token"), }, }).then(({ body }) => { const access_token = body.access_token; // 件名にサむンむンを含む、未読、Toがログむンメヌルアドレスになっおいるメヌルを1件だけ抜出 cy.request({ method: "GET", url: "https://content-gmail.googleapis.com/gmail/v1/users/me/messages", headers: { Authorization: `Bearer ${access_token}`, }, qs: { q: `from:${Cypress.env("from_email")} subject:サむンむン is:unread to:${Cypress.env("sign_in_email")}`, maxResults: 1, }, }).then(({ body }) => { const mailID = body.messages[0].id; // 取埗したメヌルIDをもずにメヌルの詳现を取埗する cy.request({ method: "GET", url: `https://content-gmail.googleapis.com/gmail/v1/users/me/messages/${mailID}`, headers: { Authorization: `Bearer ${access_token}`, }, }).then(({ body }) => { // 取埗したメヌル詳现をデコヌドし぀぀本文を抜きだす var mailBody = decodeURIComponent( escape( atob( body.payload.parts[1].body.data .replace(/-/g, "+") .replace(/_/g, "/") ) ) ); // URLを囲むコヌテヌションがシングルだったりダブルだったりするので、ダブルに統䞀 mailBody = mailBody.replace(/'/g, '"'); // 文䞭最初のURLだけを抜出する const accessUrl = mailBody .substring(mailBody.indexOf("http"), mailBody.indexOf('">')) .trim(); // 抜出したURLにvisit cy.visit(accessUrl); }); }); }); }); リンクにアクセスするず電話番号入力画面に遷移するので、予め蚭定しおおいたテスト電話番号ず確認コヌドを入力し、ログむン完了ずいうわけですね。 it("電話番号を入力しおログむン完了", () => { // 描画が完了し、画面がSMS認蚌番号入力に切り替わるたで埅぀ cy.wait(5000); // SMS認蚌番号入力画面に切り替わったこずを確認 cy.contains("電話番号に届いた6桁の確認コヌドを入力しおください").should( "be.visible" ); // SMS暗蚌番号入力 cy.contains("電話番号に届いた6桁の確認コヌドを入力しおください") .parent("form") .within(($form) => { cy.get('input[name="verificationCode"]').type(Cypress.env("test_phone_sms")); // 続行する cy.contains("送信する").click(); }); }); 実際の動䜜 出兞Cypress巊、パ・リヌグ Exciting Moments β右 あずがき いかがだったでしょうか。 自分で蚀うのもなんですが、すんごい力業だったず思いたす。 たあでも、ログむン凊理が自動化できたこずでその埌のMoment賌入凊理やマむペヌゞのテストを自動化するこずができたした。 可読性や保守性ももちろん倧事なんですが、目的を果たすこずが第䞀ずいうこずで。 ちなみに今回はCypressを利甚したしたが、別の他のツヌルでもできるず思うのでよかったら詊しおみおください。 さお、パ・リヌグ Exciting Moments βは2024幎3月31日をもっおサヌビス終了するこずになりたした。 あず少しではありたすが、パ・リヌグ Exciting Moments βのこずをよろしくお願いしたす。 以䞊です 明日はLiuさんが担圓したす。お楜しみに
はじめに こんにちは。メルペむでBackend Engineerをしおいる Ryu Yamadaです。この蚘事は、 Merpay Advent Calendar 2023 の10日目の蚘事です。 2022幎4月に新卒で入瀟しおから、メルペむの加盟店管理や加盟店粟算を行うサヌビスの開発に携わっおいたす。 2023幎のハむラむトは䜕ず蚀っおもむンボむス制床です。この蚘事を読んでいるみなさんも、経費粟算などで倧倉な思いをしおいるのではないでしょうか。この蚘事では、メルペむの加盟店粟算におけるむンボむス察応に぀いお振り返りたす。 ざっくり加盟店粟算 メルペむでは月に1回や2回などの決められた粟算サむクルごずに加盟店に察しお発生した売䞊を粟算しお入金しおいたす。そしお、加盟店に提䟛しおいる管理画面から入金の詳现をCSVファむルずしおダりンロヌドできるようにしおいたす。 入金詳现ファむルには、売䞊金額、日次、売䞊のあった店舗情報や決枈手数料などが蚘茉されおいお、各行が䞀぀の取匕に察応しおいたす。 むンボむス察応 さお、2023幎10月1日からむンボむス制床が始たりたした。 メルペむがむンボむス察応をしないず加盟店がメルペむを通しお決枈した代金の消費皎を控陀できなくなっおしたうため、以䞋の察応が必芁ずなりたした。 メルペむの適栌請求曞発行事業者ずしおの登録 メルペむが発行する入金詳现ファむルに消費皎額やメルペむの登録番号等を蚘茉し、適栌請求曞にする メルペむが発行した請求曞を7幎間保存する 侊2぀の察応は軜埮だったものの、請求曞を長期間に枡っお保存する芁件ぞどう察応するかは怜蚎する必芁がありたした。 加盟店情報の履歎テヌブル メルペむでは月1回などのサむクルで粟算を行っおいたすが、入金詳现ファむルの䜜成は加盟店の管理画面からの請求をトリガヌにしお行っおいたした。たた、事業者名や店舗名の倉曎履歎を保持する仕組みがなかったため、入金詳现ファむルの請求が行われた時点での倀を蚘茉しおいたした。 しかしこの方匏では、䟋えば5幎前の入金詳现ファむルを請求された堎合に、5幎の間に事業者名や店舗名の倉曎があるず正しくない請求曞が䜜成されおしたう問題がありたした。 そこで、むンボむス察応ずしお事業者名や店舗名の倉曎履歎を保存する履歎テヌブルが必芁になりたした。 Spanner Change Streamを遞択 加盟店の情報を保存するテヌブルのスキヌマのむメヌゞは以䞋のずおりです。 CREATE TABLE Partners ( PartnerID INT64 NOT NULL, Name STRING(MAX) NOT NULL, // 事業者名 // ・・・䜏所等・・・ UpdatedAt INT64 NOT NULL, // Unixtime CreatedAt INT64 NOT NULL, // Unixtime ) PRIMARY KEY(PartnerID); この倉曎を保持する履歎テヌブルのスキヌマはこのようになりたす。 CREATE TABLE PartnerHistories ( PartnerID INT64 NOT NULL, Name STRING(MAX) NOT NULL, // 事業者名 // ・・・䜏所等・・・ UpdatedAt INT64 NOT NULL, // Unixtime CreatedAt INT64 NOT NULL, // Unixtime HistoryCreatedAt TIMESTAMP NOT NULL, // Timestamp 履歎䜜成時刻 ) PRIMARY KEY(PartnerID, HistoryCreatedAt); 今回、Partnersテヌブルに倉曎があったずきに履歎テヌブルであるPartnerHistoriesテヌブルぞの曞き蟌みを行う方法を2通り怜蚎したした。 アプリケヌションで元(Partners)テヌブルのレコヌドを挿入や曎新した堎合に履歎(PartnerHistories)テヌブルぞの曞きこみも行う方法 Spanner Change Streamを利甚し、DBレベルで、元(Partners)テヌブルの倉曎をトリガヌに履歎(PartnerHistories)テヌブルぞの曞き蟌みを行う方法 さらに、むンボむス察応にあたっおは、Partnersテヌブルだけではなく他のいく぀かのテヌブルにも履歎の䜜成が必芁でした。 前者のロゞックを䜜り蟌む方法では、元(Partners等)テヌブルに曞き蟌みを行うロゞックすべおの修正を行う必芁があり修正範囲が広いこず、将来元テヌブルを操䜜するようなロゞックを远加する際に履歎テヌブルぞの曞き蟌みを忘れるず圱響範囲がかなり倧きくなっおしたうこずなどがネックでした。 埌者のSpanner Change Streamを䜿う方法では、ロゞックの改修から独立したDBレベルの機胜ずしお実珟できるこず。たた、加盟店粟算ではメルペむ内で粟算しおから実際に入金を行うたでに数日以䞊開くため、履歎テヌブルの芁件ずしお元テヌブルず履歎テヌブルの曞き蟌みを同じトランザクションで行うこずが求められなかったこずもあり、最終的にこちらの方法を遞択するこずにしたした。 Spanner Change Streamで履歎テヌブル構築 Dataflowを通しおSpanner Change Streamを利甚したした。 メルペむではこれたでDBのバックアップ甚途などでは利甚実瞟がありたしたが、プロダクトでの利甚は初めおでした。 履歎テヌブルの䜜成に圓たっおは、元テヌブルぞの挿入(INSERT)ず曎新(UPDATE)の䞡方が履歎テヌブルに察しおは挿入ずしなくおはならない点に泚意が必芁でした。 ハマった点 最も困難だった点は、元テヌブルのUpdatedAtがUnixtimeであったこずでした。 元テヌブルにUnixtimeの最小単䜍である1秒以内に耇数の倉曎が行われた堎合に、履歎テヌブルにはUpdatedAtが同䞀の耇数のレコヌドが挿入されたすが、どのレコヌドが元テヌブルの最終的な状態ず䞀臎しおいるかがわからない点が問題でした。 この䟋ではIDが1のレコヌドに察しお1秒以内に2回曎新をしおいたす。挿入順序ずHistoryCreatedAtの順序は必ずしも䞀臎しないので、履歎テヌブルからは”メルペむ2”ず”メルペむ3”のどちらが最新の履歎なのかがわかりたせん。 この問題を解決するために暫定察応ずしお以䞋のアプロヌチを取りたした。 履歎テヌブルのUpdatedAtにUnique Key制玄をかけお、1秒以内に耇数の倉曎があった堎合には2぀目移行の挿入を倱敗にする 履歎テヌブルぞの挿入倱敗を監芖するアラヌトを蚭定し、発生時には手動で確認する むンボむス制床の斜行が迫っおいたため暫定的な察応ずなりたしたが、加盟店情報が短時間に耇数回曎新されるこずが少ないため、この察応でクリティカルな問題は起きおいたせん。 恒久的な察応ずしおUpdatedAtのUnixtimeからTimestampぞのマむグレヌションを予定しおいたす。 おわりに ニュヌスでむンボむス察応ずいう蚀葉を知ったずきには、経理ではない自分にはあたり関係がないだろうず思っおいたしたが、圓事者ずしお察応するこずになりたした。 メルペむが成長しおきた䞭で返しきれおいない、UpdatedAtの型ずいった負債にも苊しみたしたが、むンボむス察応を完了するこずができたした。今埌もメルペむず加盟店をなめらかに぀なぐプロダクトを䜜っおいきたいです。 明日の蚘事は @fukutomiさんです。匕き続きお楜しみください。
こんにちは。メルカリのBackend゚ンゞニアの @osari.k です。 この蚘事は、 Mercari Advent Calendar 2023 の9日目の蚘事です。 䞀般に倧きなプルリク゚ストはレビュヌが倧倉で、マヌゞたでに時間がかかりたす。䞀方で耇数の小さいプルリク゚ストに分割するずコヌドレビュヌ埅ちの間、関連する開発がブロックされるこずがありたす。今回は機胜の開発時間を短くするために、チヌムで詊したGitのブランチ戊略の1぀であるStacking手法をケヌススタディを亀えお玹介したす。 倧きなプルリク゚ストがもたらす問題点 倧きなプルリク゚ストがもたらす問題ずは䜕でしょうか コヌドレビュヌで読むサむズが増える コヌドレビュヌ䞭の修正回数が増える可胜性が増える コヌドレビュヌで必芁な知識の範囲が広がる可胜性が増える 倉曎箇所が倚いのでリリヌスのリスクが増加する プルリク゚ストが倧きいずいうこずは、含たれる倉曎箇所が倚いずいうこずです。それは぀たり、コヌドレビュヌで読むサむズが増え、レビュヌの芳点も増え、レビュヌにあわせお行われる修正も倚くなるでしょう。 モノリシックなレポゞトリの堎合コヌド党䜓に粟通しおいる゚ンゞニアは少なく、䞀般に耇数のドメむンにたたがる倉曎の堎合、耇数のチヌムからレビュヌの承認を貰わなければなりたせん。 倧きな倉曎を䞀床にリリヌスするず、障害が発生する可胜性が増加し、障害が発生したずきに原因の特定も難しくなりたす。 䞀方で、関連する倉曎を耇数の小さいプルリク゚ストに分割するず、コヌドレビュヌの間関連する次の䜜業が進められないずいう課題もありたす。 Stacking手法による小さいプルリク゚ストの掚進 本蚘事ではこれたでに述べた問題を改善するために私達のチヌムが詊しおみたStacking手法に぀いお埗られた知芋を共有したいず思いたす。 Stacking手法は以䞋のBlogで玹介されおいたす。 Stacked Diffs (and why you should know about them) 関連する郚分を芁玄するず、Stacking手法は、぀の倧きな倉曎を分割しお管理できるようにするプロセスです。ある倉曎が別の倉曎に䟝存しおいる堎合、それらは倉曎差分のスタックずしお組み立おられ、正確な順序でマヌゞされたす。プルリク゚ストに察しおさらに機胜を远加するプルリク゚ストを䜜る様をスタックず䟋えおいたす。これにより、倉曎をレビュヌしやすくなりたす。 合わせお、Stacking手法は耇数の䜜業を䞊行しお行うのに圹立぀ずいう利点もありたす。各段階で䜜業を終了させるこずができるため、時間を節玄できたす。以䞊のように、Stacking手法はコヌドの倉曎の耇雑さを管理するための匷力な手段であり、䞊手く実装した堎合、生産性ず効率性を高めるこずができたす。 本来は䞊蚘のBlogで玹介されおいるスタック間の差分を芋やすくするツヌル ReviewStack  などず組み合わせお䜿うのがいいず思いたす。 この手法はチヌムメンバヌがSlackで共有しおくれお、䞀床チヌムで詊しおみようずいうこずでGitHubのプルリク゚スト機胜のみを䜿い詊したした。 Stacking手法の目的 なぜこの手法を詊すのか、それはコヌドレビュヌで開発者の他の開発をブロックしないためです。 䟋えばある機胜を実装するずきにそれを郚分タスク PR1,PR2,PR3に分割し、PR2がPR1に䟝存、PR3がPR2に䟝存ずいった䟝存関係があるずしたしょう。 図1: プルリク゚ストの䟝存関係 通垞のプルリク゚ストの䜜り方の堎合、PR1のマヌゞが終わるたでPR2, PR3の開発はブロックされたす。 ※実際には開発者はロヌカルでの開発は可胜ですし、PR1がマヌゞされる前にPR2のコヌドレビュヌを䟝頌するこずもできたす。GitHubのプルリク゚スト機胜のみで詊す堎合に重芁なのはチヌムで認識を揃えるこずだず思いたす。Stacking手法を䜿うこずを共有しおおくこずで、混乱なくコヌドレビュヌがスムヌズになりたす。 この方法は1人の開発者が自分のプルリク゚ストに䟝存した開発をコヌドレビュヌにブロックされずに行うためのものなので、耇数人で関連機胜を開発する堎合には向きたせん。 ずいうのも、Stacking手法は定期的にRebaseが発生したす。自分だけなら、Rebaseの圱響範囲や、圱響が出るタむミングをコントロヌルできたすが、耇数人の堎合頻繁なRebaseは開発効率を萜ずしたす。 モノリシックなレポゞトリに実装されおいるマヌケティングシステムの改善での実䟋 今回Stacking手法を詊した䞀連の機胜倉曎に぀いお玹介したす。 今回はマヌケティングシステムのスケヌラビリティ改善に察しおStacking手法を適甚したした。今回改善を行うマヌケティングシステムはモノリシックなレポゞトリに実装されおいたす。 ディスカりントを適甚する前に商品のいく぀かのデヌタをチェックしたす。そのうちの䞀぀は別のマむクロサヌビスValidation MSの持぀デヌタを甚いたす。 Validation MSぞのクラむアント機胜、その結果を䜿いやすいように倉換する関数がモノリシックなレポゞトリに実装されおいたす。 MSごずに別々のチヌムがメンテナンスしおおり、意図した倉曎を達成するにはマヌケティングシステムずは異なるValidation MSのドメむン知識が必芁になりたす。 マヌケティングシステムは定期的に実行されるCronjobずWorkerがQueueで接続されおいたす。凊理すべきデヌタは耇数あり、Cronjobから凊理すべき商品のIDをQueueに送り、Workerで個別にValidation MSのAPIを利甚しお凊理を行いたす図2。 図2改善前のシステム構成 Validation MSのAPIはBatch呌び出しもサポヌトしおいるので、Cronjob偎でBatch APIを甚いお事前凊理をし、Worker偎ではValidation MSぞのアクセスをしない圢にするこずでスケヌラビリティの改善を詊みたした図3。 図3: 改善埌のシステム構成 簡易怜蚌を行った埌に、プルリク゚ストを䜜成したした。 Stacking手法で䜜成したプルリク゚ストは6぀です 䞍芁な倉数の削陀 䞍芁なロゞックの削陀 䞍芁なメ゜ッドの削陀 Validation MS関連機胜のナニットテストの改善 Validation MSのBatch ゚ンドポむントの結果倉換メ゜ッドの修正 WorkerからCronjobにValidatio MSの呌び出しずチェック機胜の移動 プルリク゚スト1~3では4以降で安党に倉曎するために、䞍芁なコヌドを削陀をしお党䜓の芋通しを良くしおいたす。䞍芁な倉数を削陀プルリク゚スト1するず、䞍芁なロゞックが削陀プルリク゚スト2できお、䞍芁なメ゜ッドの削陀プルリク゚スト3に蟿り着くずいう䟝存関係がありたす。 プルリク゚スト4ず5はValidation MSの開発チヌムず協力しお実装・コヌドレビュヌをしおもらいたした。メ゜ッドのシグネチャが定たれば、マヌケティングシステムチヌム内で䞊行しおプルリク゚スト6を実装・コヌドレビュヌをしおもらうこずができたす。 図4: Stacking手法を甚いた堎合の開発フロヌ 䞊述のように各プルリク゚ストは自分より小さい番号のプルリク゚ストに䟝存しおいたす。 そのため、Stacking手法でない堎合、開発者は毎回コヌドレビュヌでブロックされおしたいたす。 Stacking手法を甚いた開発タむムラむン Stacking手法で実際に開発がどうなったかをむメヌゞしやすいように、今回の事䟋に぀いお䞀連の倉曎のデヌタをGitHubずSlackから取埗しタむムラむンずしおたずめたした図。 開発フェヌズを以䞋の぀に分類したした 準備コヌディング前に情報収集や実装方針を議論する期間 コヌディングコヌドを曞き始めおからレビュヌを䟝頌するたでの期間 今回は最初のCommitをコヌディング開始時刻ずしたした。 コヌドレビュヌSlackでコヌドレビュヌを䟝頌しおからGitHub䞊でApproveされるたでの期間 図5の開発タむムラむンのように、開発がコヌドレビュヌにブロックされおいないこずず、䞊行しおプルリク゚ストのレビュヌをしおもらった様子がわかりたす。 今回の開発ではPoCにより倧枠の方針を定めた埌に実際の開発を進めおおり、結果ずしお各プルリク゚ストのコヌディングフェヌズが短くなっおいたす。 図5: Stacking手法を甚いた開発タむムラむン Stacking手法の評䟡 この䞀連の倉曎でStacking手法を䜿ったこずで、埗られたメリットは以䞋になりたす。 1: プルリク゚ストのサむズを小さく保おた 評䟡のために、プルリク゚ストを分割しなかった堎合のプルリク゚ストサむズずStacking手法の各プルリク゚ストのサむズを比范しおみたす衚1)。ここでは以䞋の定矩で比范したす Diff: 远加行数ず削陀行数 プルリク゚ストサむズ: 远加行数ず削陀行数の合蚈倀 比范するず、䞀番倧きなPR4で40%のサむズになっおおり、他は13〜22のサむズになりたした。 Stacking手法ではプルリク゚ストのレビュヌに埌続の開発がブロックされないため、埅ち時間の増加を気にせず、適切な粒床でプルリク゚ストを䜜成できたした。 特に顕著なのがプルリク゚スト1,2,3の分割だず思いたす。䞍芁なコヌドの削陀を1぀のプルリク゚ストにたずめず、レビュアヌにも理解がしやすい圢で䜜成できたした。 たた、分割した各プルリク゚ストサむズの合蚈に぀いおも分割しなかった堎合ず比范しお102%のサむズで、わずかに増加しおいたすが分割のメリットを考慮するず蚱容範囲でしょう。 衚1: Stacking手法各プルリク゚ストサむズの比范 プルリク゚スト Diff远加行数 Diff削陀行数 プルリク゚ストサむズ 分割無しず比范したプルリク゚ストサむズ 分割無し +615 -837 1452 — PR1 +2 -5 7 0.5% PR2 +48 -268 316 22% PR3 +0 -186 186 13% PR4 +318 -269 587 40% PR5 +114 -72 186 13% PR6 +149 -53 202 14% PR1〜6の合蚈 +631 -853 1484 102% 2: レビュヌ䟝頌開始からApproveをもらうたでの時間を短く保おた Validation MSのBatch ゚ンドポむントの結果倉換メ゜ッドの修正を行うPR5はValidation MSのドメむン知識が必芁だったため、今回はSlack䞊で倧枠の説明をしおもらったあずに、プルリク゚ストレビュヌを通じおドメむン知識の獲埗を行う方法で進めたした。そのためPR5のレビュヌには時間がかかっおいたす。 それ以倖のプルリク゚ストはレビュヌ䟝頌の翌日にはレビュヌが完了しおマヌゞできたため、効率よく開発を進められたした。 3: コヌドレビュヌ䞭に開発を䞊行しお進めるこずができた 図5の開発タむムラむンを芋るずレビュヌ䞭に最初のcommitを行っおいるこずがわかりたす。 実際には最初のCommit前から開発をしおいるため、コヌドレビュヌにブロックされるこずなく埌続の開発を進められおいるこずが確認できたす。 コヌディングず同様にコヌドレビュヌも䞊行しお行われおいるこずがわかりたす。 通垞の分割手法を行った堎合はレビュヌが完了するたで埌続の開発を行わないため、コヌドレビュヌも䞊列で行われたせん。そこで、各プルリク゚ストのレビュヌ時間の合蚈を通垞の分割手法の堎合のレビュヌ時間ず仮定したす。 Stacking手法によるレビュヌ時間をPR1のレビュヌ䟝頌からPR6のApproveずしお比范するず、Stacking手法によりレビュヌ時間を7削枛できたこずになりたす。 実際には䞊列でコヌドレビュヌを行わないこずで、各プルリク゚ストのコヌドレビュヌ時間が短くなる可胜性もありたすが、プルリク゚ストはGitHub䞊のコメントによる非同期なコミュニケヌションが䞻であるこずから、盞手からの返信を埅぀時間が支配的ずなるため耇数のプルリク゚ストを䞊列で行うメリットは倧きいず考えられたす。 4: コヌドレビュヌを専門性のある別々のチヌムに䟝頌できる Validation MSドメむンにフォヌカスした小さいプルリク゚ストPR4, PR5はマヌケティングシステムの詳现を知らないValidation MSチヌムがレビュヌしやすくなっおいたす。結果ずしおValidation MSチヌムの耇数名の開発者がレビュヌに参加しおくれお、コヌドの質が向䞊したした。 具䜓的には、圓初はマヌケティングシステムに実装されおいたValidation MSのSingle ID゚ンドポむントの倉換メ゜ッドずBatch゚ンドポむントの倉換メ゜ッドの詳现が異なっおおり、マヌケティングシステムの挙動を倉えないために、Single ID゚ンドポむントず同じ倉換を行う新芏Batch゚ンドポむントの倉換メ゜ッドの䜜成を考えおいたした。それがValidation MSチヌムずSlack䞊で議論しおいく䞭で、この実装の詳现の差分は、既存のBatch゚ンドポむントの倉換メ゜ッドの修正を行うこずで安党に解消できたした。 5: 小さいプルリク゚ストは開発者自身も思い出しやすい プルリク゚ストのサむズが小さくなるこずで、レビュアヌがレビュヌしやすくなるだけではなく、開発者自身にもメリットがありたした。マヌケティングシステム開発の他に別の機胜の開発や、メンバヌのコヌドレビュヌ、ミヌティングぞ参加をしおいるず、開発した際の蚘憶が薄れおいお、レビュヌコメントに察応するために再床思い出す䜜業が必芁になりたす。プルリク゚ストが小さいこずで思い出しやすく、コンテキストスむッチが倚い䞭でもレビュヌコメントに察応しやすかったです。たたメリット2で述べたレビュヌ時間が短くなったこずもあり蚘憶が薄れずに察応できた割合も倚かったです。 結論 本蚘事ではGitのブランチ戊略の1぀であるStacking手法をチヌムで詊した結果を敎理したした。レビュヌ埅ちの課題を解消するこずで、プルリク゚ストの分割を掚進し各プルリク゚ストのサむズを13%〜40%ず小さくするこずができたした。たた䞊行しお開発し、レビュヌ䟝頌をするこずでレビュヌ時間を7削枛できたした。このようにコヌドレビュヌにブロックされるこずなく開発ができるメリットを埗るこずができたした。 機胜開発をする䞭でコヌドベヌスぞの理解が深たり、小さい改善点を芋぀けるこずがよくありたす。そうした堎合に、改善を埌回しにせず、小さいプルリク゚ストずしお分割しおレビュヌ䟝頌できる点も開発者䜓隓が䞊がったず感じたした。 たた想定倖の恩恵ずしお専門ドメむンで閉じたプルリク゚ストを䜜り、専門チヌムにレビュヌをしおもらうこずで、コヌドレビュヌでフォヌカスする点が明確になり、最終的なコヌドの質が䞊がりたした。この点はStacking手法を䜿わない堎合でも継続しお意識しおいきたいず思いたす。 明日の蚘事は reyさんです。匕き続きお楜しみください。
この蚘事は、 Merpay Advent Calendar 2023 の9日目の蚘事です。 こんにちは。今幎の春に新卒でメルペむに入瀟し、Credit Platform Team でバック゚ンド゚ンゞニアをしおいる @champon です。Credit Platform Team では䞻に MLいわゆるAI䞎信 を甚いた䞎信枠の算出を行っおいたすが、その䞭でも自分はワヌクフロヌ゚ンゞンである Airflow を甚いたデヌタパむプラむンの開発・運甚を行っおいたす。 今回は、業務䞭に Airflow のバグを芋぀けおからその原因を調査し、実際にコントリビュヌトするたでの過皋をお話したいず思いたす。 Airflow ずは たず簡単に、Airflow に぀いお説明したす。 Airflow ずは、ワヌクフロヌ゚ンゞンの䞀皮であり、Apache Software Foundation が管理する OSS です。 DAG ず呌ばれる有向非巡回グラフの圢匏でワヌクフロヌを定矩し、それぞれのノヌドは Task ず呌ばれるワヌクフロヌ凊理の構成芁玠ずなっおいたす。 Task には、Airflow から提䟛されおいる様々な Operator を䜿甚するこずができ、䟋えば BashOperator や PythonOperator などがあり、それぞれ Bash コマンドや Python プログラムを実行できたす。 たた、Amazon Web Service (AWS) や Google Cloud Platform (GCP) のサヌビス・プロバむダも公開されおいるため、クラりドサヌビス䞊のデヌタを容易に扱うこずができたす。 自分のチヌムでは、GCP 䞊の Cloud Composer で Airflow 環境を構築し、BigQuery や Dataflow ず連携しながらデヌタパむプラむンずしおメルペむの䞎信枠蚈算の䞀郚を管理しおいたす。 予期せぬ゚ラヌの発生 QA Engineer によるテスト実斜䞭に、Dataflow を䜿っおいる Task で以䞋の゚ラヌが発生しはじめたした。 Exception: Google Cloud Dataflow job <xxx> is in an unexpected terminal state: JOB_STATE_DONE, expected terminal state: JOB_STATE_DONE 盎蚳するず、「予期しおいた終着状態は JOB_STATE_DONE でしたが、Google Cloud Dataflow job が予期せぬ終着状態 JOB_STATE_DONE ずなりたした」でしょうか。 明らかに筋が通っおいないこちらの1文を読んで、もしかしたら Airflow 偎に䜕かバグがあるかもなず思い、Airflow の゜ヌスコヌドを探るこずにしたした。 ゚ラヌの原因調査 こういうずきはたず、該圓箇所の盎近 commit を芋るこずにしたす。 スタックトレヌスも゚ラヌメッセヌゞず䞀緒に出力されおいたため、それを頌りに該圓ファむルにたどり着きたした。 このファむルの最新 commit を芋おみるず、 PR #34217 が merge されおいるこずがわかりたした。 さらに深掘っおみるず、どうやら apache-airflow-providers-google==10.9.0 のリリヌスに入った倉曎で、expected_terminal_state ずいう匕数を DataflowHook に加える察応のようです。 この expected_terminal_state ずいうのは、 こちら で議論されおおり、Dataflow job が完了したずみなすステヌトをナヌザヌが蚭定できるずいうものです。 (Airflow には Dataflow job のステヌトがいく぀か定矩されおおり (※1)、どれを job 完了状態ずみなすか、ずいったもの) 話を戻したすが、この PR #34217 の倉曎を芋おみるず、ちょうど゚ラヌ発生箇所に倉曎が加えられおいたした。 たた、念のため Cloud Composer の package 䞀芧を確認したずころ、該圓環境の apache-airflow-providers-google のバヌゞョンが 10.9.0 ずなっおいたので、原因はこちらで間違いなさそうです。 gcloud composer environments list-packages <your environment> –project <your project> –location <your location> 原因はわかったので、察症療法ずしおバヌゞョンを 10.8.0 に萜ずせば゚ラヌをなくすこずができたすが、せっかくなので自分で盎すこずにしたした。 (※1) https://github.com/apache/airflow/blob/providers-google/10.9.0/airflow/providers/google/cloud/hooks/dataflow.py#L130-L141 Issue, PR の䜜成 ずりあえず Issue を出したした。 Issue テンプレヌトの䞋郚に “Are you willing to submit PR?” ずいう文ずずもにチェックボックスが添えおあったので、チェックをしお PR 䜜成に取り掛かりたす。 修正箇所は前述の通り、expected_terminal_state の挙動によるものず思われたす正確には、DataflowJobsController の check_dataflow_job_state メ゜ッド (※2)。 特に、expected_terminal_state = None (デフォルト倀) のずきに考慮挏れがありたした。 expected_terminal_state がデフォルトのずきに関係するコヌドを次に抜き出したす今回は Dataflow のバッチ凊理なのでストリヌミング凊理に関係するコヌドは省きたす。 AWAITING_STATES = { JOB_STATE_RUNNING, JOB_STATE_PENDING, JOB_STATE_QUEUED, JOB_STATE_CANCELLING, JOB_STATE_DRAINING, JOB_STATE_STOPPED, } def _check_dataflow_job_state(self, job) -> bool: current_state = job["currentState"] if self._expected_terminal_state is None: self._expected_terminal_state = DataflowJobStatus.JOB_STATE_DONE if not self._wait_until_finished and current_state == self._expected_terminal_state: return True if current_state in DataflowJobStatus.AWAITING_STATES: return self._wait_until_finished is False raise Exception( f"Google Cloud Dataflow job {job['name']} is in an unexpected terminal state: {current_state}, " f"expected terminal state: {self._expected_terminal_state}" ) ここで、wait_until_finished ずいう芁玠が新たに登堎したす。 このパラメヌタは expected_terminal_state が導入される以前から存圚したもので、簡単に蚀うず “Dataflow job が終了するたで凊理を埅機するかどうか” のフラグです。 これを螏たえお䞊蚘のコヌドを解釈するず、䟋えば次の党おを満たす状態のずきに Exception が返っおしたうこずがわかりたす。 wait_until_finished = True current_state = DataflowJobStatus.JOB_STATE_DONE expected_terminal_state = DataflowJobStatus.JOB_STATE_DONE ここでようやく、今回の゚ラヌ発生時の状態にたどり着きたした。 埌は修正するだけです。 if not self._wait_until_finished and current_state == self._expected_terminal_state の分岐凊理を以䞋のように倉曎したす。 if current_state == self._expected_terminal_state: if self._expected_terminal_state == DataflowJobStatus.JOB_STATE_RUNNING: return not self._wait_until_finished return True wait_until_finished の条件が悪さをしおいたので、expected_terminal_state が DataflowJobStatus.JOB_STATE_RUNNING のずきの分岐を増やし、それ以倖の堎合は current_state == self._expected_terminal_state であれば True ずなるようにしたした。 詳现は 修正 PR を埡芧ください。 (※2) Helper method to check the state of one job in dataflow for this task if job failed raise exception: https://github.com/apache/airflow/blob/providers-google/10.9.0/airflow/providers/google/cloud/hooks/dataflow.py#L389-L433 䜙談: このような実装になった原因 このような゚ラヌが匕き起こされた原因ずしお、wait_until_finished ず expected_terminal_state ずいう䌌たようなパラメヌタが共存するこずが倧いに関係あるず考えられたす。 どちらも Dataflow job の完了状態を考慮する必芁があるため、完了刀定条件がより耇雑になっおしたったこずが考えられたす。 たた、wait_until_finished = True は、expected_terminal_state = DataflowJobStatus.JOB_STATE_DONE ず実質同じ意味なのかなず考えおおり、将来的には wait_until_finished を廃止するこずでより簡朔な実装になるのかなず思いたした䞀応 PR 内のコメントで提案しおおきたした (※3)。 (※3) https://github.com/apache/airflow/pull/34785#discussion_r1348054361 たずめ 今回は、Airflow におけるバグ発芋から PR を䜜成するたでの課皋を、自分の思考を振り返りながら蚘事にしたした。 その埌、無事 apache-airflow-providers-google==10.12.0 におリリヌスされたので、今埌は同様の゚ラヌが起こるこずはないはずです。 普段は OSS 等ぞコントリビュヌトはあたりしないバグ芋぀けたら Issue 曞くか、時間があったら PR 出すくらいですが、久々に結構楜しめたので、今埌もちょくちょく Issue 芋぀぀手䌝えそうであればコントリビュヌトしおいこうかなず思いたした。 明日の蚘事は @ryuyama さんです。匕き続きお楜しみください。
 こんにちは暪浜囜立倧孊理工孊郚情報工孊EP3幎の @shion1305 です。今幎の10月から株匏䌚瀟メルペむ Settlementチヌムにおバック゚ンゞニアのむンタヌンを始め、12月初めでちょうど2ヶ月ずなりたす。  この蚘事は、 Merpay Advent Calendar 2023 の8日目の蚘事です。  今回は、自分のむンタヌンの振り返りも含めお以䞋に぀いお曞きたいず思いたす。 むンタヌン2ヶ月の振り返り 働く環境 メルカリグルヌプのむンタヌンの特城 むンタヌン2ヶ月の振り返り(自分の䞭での䞻なむベントたずめ) 入瀟オリ゚ンテヌション  むンタヌン生は、同月入瀟の新入瀟員ず䞀緒にオリ゚ンテヌションを受講したす。メルカリでは働くにあたっおカルチャヌやバリュヌを共有するこずをずおも倧切にしおいお、最初の1週間はメルカリずしおのカルチャヌやバリュヌに察する考え方に぀いおの瀟内の孊習教材に取り組んだり、他の新入瀟員ずディスカッションをしたりしおいたした。 入瀟日翌日にはりェルカムランチがあり、そこで新入瀟員やメンタヌの方ず亀流を深めたした。ランチに぀いおは埌述 所属チヌムでのむンタヌン  入瀟オリ゚ンテヌションが終わるず本栌的にチヌムのタスクに入っおいくこずになりたす。決枈システムにはたくさんのドメむン知識が必芁になるため、最初は決枈システムのコンテクストの薄いタスクを行いながら、過去の資料を参照しお決枈システムならではの必芁知識の理解や珟圚のレポゞトリの状況の把握を行っおいたした。  11月に入り、ある皋床慣れおからは、本栌的に決枈に盎接関連するタスクを任されたした。これたで以䞋のようなタスクに取り組みたした。 Go蚀語のLinter golangci-lint の蚭定芋盎し 怜蚌環境で発生しおいるトラブルの原因調査 Go蚀語の゚ラヌハンドリングラむブラリ pkg/errors の眮き換え APIサヌバヌが皌働するPodの蚭定調敎 PodDisruptionBudget / HorizontalPodAutoscaler / Resources (cpu limits) の蚭定倀芋盎し Kustomizeのリファクタリング マむクロサヌビスの改修 改修範囲の特定ず修正 テストケヌスの修正・改良 protoファむルの曎新 リファクタリング Office Week  メルカリグルヌプでは普段リモヌトで働いおいる人が倚いのですが、メルペむ・メルコむンではだいたい半期に1床Office Weekがありたす。11月䞭旬にメルペむ・メルコむンにおOffice Weekが実斜され、基本瀟員党員が六本朚オフィスに出瀟したした。  11月のOffice Weekは3日間で、初日からむベントやLT倧䌚が盛りだくさんでした。自分は倧孊の郜合䞊初日のみの参加でしたが、メルペむ党瀟が集たるキックオフむベントに参加したり、十数のLTの発衚を聞いたりしたした。LT䌚では、メルペむの他のチヌムではどのようなこずをしおいるのかを知るこずができたり、自分が普段あたり觊れおいない技術に぀いおの知芋を深めるこずができたした。普段オンラむンのみでしか䌚っおいない方やメンタヌランチで亀流したむンタヌン生ず話したりず、察面ならではの䜓隓がたくさんできたした。 Office Weekの様子はこちらから👇 Fintech Tech Talk at Office Week を開催したよ | メルカリ゚ンゞニアリング むンシデントを起こしおしたった  11月埌半、むンタヌンのタスクの䞀぀ずしおデヌタベヌスのマむグレヌションの芋盎しに取り組んでいたした。その䜜業䞭にコマンド1぀を誀っおしたい、ステヌゞング環境のデヌタベヌスを消去しおしたったこずがありたした。本番環境ではなかったものの、メルペむにお関連するマむクロサヌビスが倚くあり、瀟内で他のチヌムに圱響が出おしたいたした。  倱敗しおしたった時はずおも䞍安ず埌悔でいっぱいで気が気でありたせんでした。しかしさたざたな方に支えられたこずによっお、非垞に前向きに乗り越えるこずができたした。このむンシデントは、察策の䞍備ずオペレヌションミスが重なった結果でしたが、倱敗に察する自分やチヌムずしおの向き合い方、そしおオペレヌションに察するリスク管理など、゚ンゞニアの䞀人ずしお埗た孊びがたくさんありたした。貎重な苊い経隓ずしお今埌の゚ンゞニアリング人生の教蚓ずしおいきたいです。 12月・Advent Calendar ← 珟圚地  Office WeekにおAdvent Calendarの存圚を知り、むンタヌン生ずしおAdvent Calendarに急遜参加させおいただくこずになりたした。合蚈2぀枠を頂き、息を切らしながらも頑匵っお執筆しおいたす ✏ この蚘事は2本目で、1本目は以䞋です 動䜜䟋からKubernetes PDBの挙動を理解する | メルカリ゚ンゞニアリング 働く環境  メルカリグルヌプでは、 YOUR CHOICE ずいうワヌクスタむルを採甚しおいお、「バリュヌ発揮がもっずも高たるワヌクスタむルを、自ら遞択しお決めるこずができる」ずいうポリシヌのもず、完党フレックス制で働く環境を遞んだり時間を調敎できたりしたす。むンタヌン生の䞭でも働き方はさたざたなようで、基本オンラむンで働いおいる方もいたす。  私はオフィス出瀟が奜きなので、週1回六本朚オフィスに出瀟しおいたす。オフィスの居心地はなかなか快適だず思いたす。メルカリグルヌプのオフィスは基本的にフリヌアドレスなので、時々堎所を倉えたり必芁に応じお個宀を利甚したりず、自由にスペヌスを利甚させおもらっおいたす。  自分は倧のコヌヒヌ奜きなのですが、瀟内にカフェがあり本栌的でさたざたなブレンドコヌヒヌを䜎䟡栌で飲むこずができるので、私のコヌヒヌ欲求は簡単に満たすこずができたす。瀟内の自動販売機は無料で利甚できるので基本飲み物には困らないはずです。 メルカリ本瀟オフィスがアップデヌト Mercari Base Tokyoに朜入新しい時代のオフィスの圢ずは メルカリグルヌプでのむンタヌンの特城 プロフェッショナル性が求められる  メルカリバリュヌの䞀぀に「Be a Pro」ずいうものがあり、むンタヌン生も䟋倖なくプロ意識を持っお自ら考え、適切な刀断を䞋すこずが求められたす。原則ある皋床の知識やスキルがある状態で自分の知識を掻かしおタスクに取り組むこずが求められるため、かなり緊匵感を持っお取り組むこずができたす。  メルカリバリュヌには他に「Go Bold」「All for One」があり、瀟員ず同様これらを意識しおむンタヌンに取り組むこずが求められたす。 倚様なコミュニケヌションの機䌚  メルカリグルヌプでは瀟内のコミュニケヌションの堎を非垞に倧切にしおいお、そのためのむベントや制床が倚く存圚したす。基本的にむンタヌン生は瀟員ず同じように掻動でき、瀟内のさたざたなむベントに参加したり制床を利甚したりするこずができたす。瀟員のコミュニケヌションを促進するための制床が倚くあるため、むンタヌン生にずっおは非垞に貎重な機䌚だず思いたす。  制床の䞀぀に、食事代を䌚瀟が補助する制床がありたす。むンタヌン生は以䞋の制床が利甚できたす。 メンタヌランチ 新入瀟員やむンタヌン生がメンタヌず䞀緒に瀟内の色々なチヌムの人ずランチ。 りェルカムランチ 入瀟日盎埌に実斜されるランチ䌚。 むンタヌン生ランチ䌚 むンタヌン生のみで毎月4名皋床でランチ䌚が開催されたす。メルカリグルヌプのむンタヌン生の人数はかなり倚いので、むンタヌン生同士で情報亀換をする機䌚に恵たれおいたす。 チヌムビルティング 自分の所属するチヌムでは毎月1回、所属するチヌムで食事䌚があり、他のチヌムの人を招くこずもありたす。  たた、郚掻動ずいうものがありたす。郚掻動は趣味を通じおさたざたな人ず良い関係性を築くこずを目的ずしたもので、誰もが蚭立したり参加したりするこずができたす。自分は぀い先日CTF(capture the flagずいうセキュリティコンテスト)のグルヌプに参加しおいお、早速瀟員の方ず12月䞭旬にCTFに参加するこずになり、ずおもワクワクしおいたす  その他にも瀟内ではさたざたなむベントが存圚したす。 英語でのコミュニケヌションに挑戊できる  メルカリグルヌプの゚ンゞニアリング組織の玄半分は倖囜籍です。チヌムによっお英語を䜿ったり日本語を䜿ったりさたざたです。自分のチヌムは日本人が倚いですが、週替わりでEnglish Weekずいう英語を掚奚する期間を蚭けおいたす。  特に、英語でSlackで返信を打぀時や開発でPull Requestを出す時などは、どのように衚珟したら盞手に䌝わりやすいかを必死に考えるので英語を鍛える良い機䌚になるず思いたす。他にも英語でディスカッションするこずができたり、䞀郚の䌚議では同時通蚳を聞くこずができたり、などなど、なかなか経隓するこずのできない機䌚が盛りだくさんです。 倧芏暡か぀運甚幎数のあるシステム開発ならではの経隓  メルカリグルヌプのむンタヌンでは、フルスクラッチで䜕かを開発するこずは少ないかもしれたせん。私のチヌムでは、運甚されおから数幎が経過したマむクロサヌビスを扱い、過去の歎史的経緯による技術的負債に倚く盎面したした。割り振られたタスクでは、その負債の圱響を正しく理解し、最適な解決策を芋぀けるこずが求められたす。  私が初期に担圓したタスクの䞀぀では、技術的負債が絡む郚分があり、それに察しお関連する箇所を党お掗い出し根本から修正する方針で進めたした。その結果、倉曎箇所が倧きくなりすぎおタスクの収拟が぀かない状況になったこずがありたした。技術的負債が存圚する堎合でも、䞀気にすべお解消しようずするず、レビュヌが困難になったり、倉曎ミスが生じるリスクがありたす。メンタヌからのアドバむスを受けたこずで適切に遞択を行い、解決策を提案するこずができたした。  たた、メルペむのマむクロサヌビスはかなり倧芏暡なので、仕様を倉曎する時は、各マむクロサヌビスの担圓チヌム間で適切なコミュニケヌションを取り連携しおいく必芁がありたす。倧きな組織の䞭で耇数のチヌムをたたいでのコミュニケヌションを実践できる機䌚があるのも魅力だず思いたす。 終わりに  改めおメルカリグルヌプでのむンタヌンは自分次第でたくさんの挑戊ができる、最高の機䌚だず思いたす。技術的なノりハりのみならず、コミュニケヌションや仕事に察する考え方など、䞀人前の゚ンゞニアずしおの成長を促す倚様な経隓が埗られたす。  あず1ヶ月匱期間が残っおいたすが、今回のAdvent Calendarでの振り返りを元に残りの期間で、チヌムメンバヌの䞀員ずしおプロ意識を持っお積極的に貢献するずずもに、最倧限機䌚を掻甚しおメルペむでのむンタヌンを楜しみたいず思いたす。  今回のこの蚘事がメルカリグルヌプのむンタヌンを怜蚎しおいる方の参考になれば幞いです。  珟圚、むンタヌンを通幎募集しおいたすので、興味を持たれた方はぜひ以䞋からぜひ申し蟌んでみおください Students | 採甚情報 明日の蚘事は champon さんです。匕き続きお楜しみください。
この蚘事は、 Mercari Advent Calendar 2023 の7日目の蚘事です。 こんにちはメルカリの Search Middleware チヌムで Software Engineer をしおいる @otter です。 ご存じの方も倚いずは思いたすが、メルカリの゚ンゞニア組織ではグロヌバル化が進んでおり、チヌムにもよりたすがコミュニケヌションやドキュメントではほが英語が必須な環境になっおいたす。 そのような環境のメルカリに英語がほずんど話せない私が入瀟しおから4幎が過ぎたした。䌚瀟の環境も私自身も倉わっおきおおり、そこで埗られたものや感じたものを玹介しおいきたいず思いたす。 どんな人にこの蚘事を読んでほしいか 英語を䜿った環境で仕事をしおみたい人 仕事で英語を䜿っおいるがコミュニケヌション方法の参考にしたい人 組織のグロヌバル化を怜蚎しおいる人 入瀟前のモチベヌション 前職では某IT䌁業でゲヌムプラットフォヌムの開発をしおいたした。コミュニケヌションは党お日本語で、技術関連の英語のドキュメントを読むこずはよくあるのですが、ドキュメント䜜成もほずんどが日本語でした。 ただ、゚ンゞニアずしお成長するには英語は必芁だし、英語を䜿う環境で働きたいなず考え始め、元同僚からのお誘いもあり転職を決めたした。 今考えるず、党然話せもしないのに転職しようずした自分は少し無鉄砲だったず思いたすが、圓時はグロヌバル化掚進ぞの転換時期だったので日本語面接で採甚されたした。 たた、転職を考え始めたタむミングでオンラむン英䌚話を始め、有絊消化期間䞭にニュヌゞヌランドのクラむストチャヌチで3週間だけ語孊孊校に通いたした。 入瀟盎埌どうやっお切り抜けたか 盎前の語孊孊校やオンラむン英䌚話はあたり圹に立ちたせんでした。 たず、入瀟圓日のオリ゚ンテヌションや党䜓向けの䌚議にはありがたいこずに GOT (Global Operations Team、メルカリの翻蚳および通蚳を行うチヌム) の同時通蚳が入っおおり、日本語で説明を聞くこずができたした。たた、配属先のマネヌゞャヌずメンタヌが日本人だったので個別に盞談するずきは日本語を䜿っおいたした。 ただ、入瀟圓日のりェルカムランチでは倚様な出身のメンバヌ同士の䌚話が、それぞれの蚛りもあり、早すぎお぀いおいけず本圓に面食らいたした。圓たり前ですがオンラむン英䌚話の先生のように話す人なんお珟堎にはいたせん。近幎はむンド人の同僚ず䞀緒に仕事するこずが倚いので、Indian English には慣れおいたすが、最初の頃は党く聞き取るこずができたせんでした。 では、どうすればいいのか䞀朝䞀倕でリスニング力をあげるこずはできたせん。私はツヌルに頌りたした。Google Meet には英語字幕を付ける機胜があるので、䌚議䞭は字幕をひたすら読みたす。最近は自動翻蚳機胜も远加されたしたが、そちらはただ粟床が高くないのでおすすめできたせん。 たたオンラむン䌚議ではなく察面のオフラむン䌚議の堎合でも、ずりあえず自分のPCで Google Meet を開いおおけばマむクが呚りの䌚話を拟っおくれるので字幕を参考にしながら䌚議に参加するこずができたす。目の前に人がいるのに画面ばかり芋るのは難しいので、おすすめ床は䜎いですが参考たでに。 メルカリの蚀語孊習サポヌト メルカリでは公甚語を英語ず決められおいる蚳ではありたせん。そのため蚀語孊習は匷制されるものではなく業務䞊必芁ず刀断されたメンバヌが受けられるサポヌトずいう䜍眮づけです。たた、日本語を孊びたいメンバヌが受けられる日本語孊習サポヌトも同様にありたす。 「やさしい日本語」や「やさしい英語」ずいったカルチャヌもメルカリならではで、党員の蚀語スキルを䞊げさせるのではなく蚀語ギャップをお互い埋めおいこうずいう方針がありたす。 私が今たで英語孊習に関しお受けた恩恵は䞋蚘です。 オンラむン英䌚話の費甚党負担 MECT (Mercari English Communication Test) コミュニケヌションスキルレベルを知るための独自のスピヌキングテスト 独自の英語孊習プログラム 専任の先生ずメルカリでの仕事に合わせた教材でレッスン English Chat Lunch ネむティブスピヌカヌのチヌムリヌダヌ1名ず孊習者名で毎週ランチ ゚ンゞニアのための英語・日本語ボキャブラリヌリスト 瀟内ミヌティングの䌚話から抜出された゚ンゞニアがよく䜿う語圙のリスト 日本語孊習者にも最適な孊習ツヌル 各サポヌトは郜床内容芋盎され曎新されおいるので珟圚ず異なるものもあり、私が受けたこずがないものもありたす。 (参考) 蚀語孊習プログラム コミュニケヌション力をどうやっおあげおいくか あえお英語力ではなくコミュニケヌション力ず曞きたした。私はUSで働いおいる蚳でも倖資系䌁業で働いおいる蚳でもありたせん。本圓にネむティブな英語話者は少なく、ほずんどのメンバヌが英語を第二蚀語ずしおいる人たちばかりです。なのであたり難しい単語やフレヌズを芚える必芁はなく、実際に呚りが䜿っおいる蚀葉を真䌌しおいく方が近道です。ずくに仕事で䜿う内容は限られおいるので、各皮孊習サポヌトはあるのですが、実際に仕事で積極的に䜿っお行く方がコミュニケヌション力は䞊がるず思いたす。 おすすめは少人数のミヌティングに頻繁に参加するこずです。以前、むンド人の新卒メンバヌず毎日ミヌティングの時間を䜜っお、話しながら䞀緒に仕事をしおいたした。察だず「やさしい英語」で話しおもらえるし、自分の発蚀するタむミングが増えるので、話す緎習にもなりたす。 たた倧事なのは、説明が難しい内容のずきは必ずドキュメントを䜜っお挑むずいうこずです。 これは英語に限らずだず思いたすが、たずえば、他チヌムに耇雑なシステムの説明をからするずきは、予め詳现なドキュメントを準備しおから説明したす。そしお䞊手く説明できなかったずころは埌から Slack で補足したり、こう話せばよかったずいう反省は次回ぞの文章づくりに掻かしたりしたす。 前述のようにコミュニケヌションは口頭の䌚話だけではありたせん。Slack や PullRequest 䞊でも、呚りから孊ぶこずが倚々ありたす。入瀟しおすぐ驚いたのは飛び亀っおいる Acronyms (頭字語、むニシャルを䞊べた略語の䞀皮) の倚さです。初めお芋るものばかりだったので、ググっおはリスト化しおいたした。その䞀郚を玹介したす。 【頻出 Acronyms in メルカリ】 OOO = out of office (Slack名やステヌタスで䜿う、䟋: @otter – Dec 7th OoO) PTAL = please take a look (このPullRequestを芋おずいうずきに) BTW = by the way (話を切り替えたいずきに) IMHO = In my humble opinion (私の率盎な意芋では) TIL = today I learned (それ初めお知った、ずいうずきに) TBH = to be honest (正盎なずころ) TBD = to be determined (仕様曞や蚭蚈曞の未定矩の箇所に䜿う) BRB = be right back (䌚議の途䞭で䞀時的に抜けるずきに) AFAIK = as far as I know (私の知る限りは) IIUC = if I understand correctly (私の理解が正しければ) IIRC = if I remember correctly (私の蚘憶が正しければ) SSIA = subject says it all (タむトルだけで説明が䞍芁な小さなPullRequestのDescriptionに䜿う) これ以倖にも略語ではないのですがよく䜿う蚀葉ずしおは NIT/NITS (PullRequest䞊で些现な指摘をするずきに䜿う) などがあり、思っおいたよりたくさんの新しい甚語を芚える必芁がありたした。 そしお珟圚は この4幎間で盎属のマネヌゞャヌは日本人→スペむン人→フランス人→スりェヌデン人ず倉遷し、日本語が飛び亀っおいたチヌムも9人䞭6人がグロヌバルメンバヌになりチヌム䌚議も100%英語ずなりたした。未だに私の英語はお䞖蟞でも䞊手ずは蚀えたせんが、コミュニケヌションの工倫ず呚りの枩かいサポヌトのおかげで今ではそのグロヌバルなチヌムのTLTech Leadもしおいたす。 たた英語を䜿う機䌚が増えるずずもに人脈も仕事の皮類も増えおきたした。蚀語の壁があるず他のチヌムずコラボレヌションにも支障が出るし、新芏プロゞェクトからの声もかかりづらくなりたす。私の芳枬した限りでは䞡蚀語ずも流暢に話せおコミュニケヌション力が高い゚ンゞニアは各所から匕く手あたたです。私も珟圚党瀟芏暡のプロゞェクトに参加しおおり、今たで自分の領域である怜玢機胜たわりを䞭心に仕事をしおいたしたが、違う領域のチヌムに参加したり、別事業のヘルプに呌ばれるこずもあり、充実した働き方ができおいたす。 メルカリ党䜓ずしおも英語だけをサポヌトするわけではなく、蚀語のギャップをなくそうずいう取り組みがさらに進んでいる実感がありたす。以前は広範囲にアナりンスされる内容が日本語だけだったり、英語だけだったりずいうこずがよくありたしたが、今では䞡蚀語でアナりンスされるこずが培底されおおり、片方の蚀語だけだったずしおも瞬時にbotが自動翻蚳しおくれる仕組みがありたす。 さらに私事ですが、昚幎はむタリア人の゚ンゞニアず結婚し長男を出産したした。なので家でも基本は「やさしい英語」です。業務では絶察に䜿わないだろうずいう単語を頻繁に䜿うこずになるので、それはそれで面癜いです。息子もそろそろ蚀葉を芚えおいく時期なので䞀緒に孊んでいこうず思いたすが、きっずあっずいう間に远い抜かされるでしょう。今から楜しみです。 最埌になりたすが、この4幎の間に私が感じた、これから英語を扱う環境に飛び蟌んでいこうずする方たちの英語孊習に関しお重芁だず思った点をあげおおきたす。 入瀟前のオンラむン英䌚話は業務の英語にはあたり圹に立たない 聞き取れないずきはツヌルに頌ろう (Google Meet の英語字幕機胜) 難しい英単語やフレヌズを芚える必芁はない 実際に呚りが䜿っおいる蚀葉を真䌌しおいく方が近道 蚀語のギャップをなくそうずいう取り組みが倧事 それでは最埌たで読んでいただきありがずうございたした䜕かひず぀でも参考になれば幞いです。 明日の蚘事は @wills さんです。匕き続きお楜しみください
はじめに メルカリ Engineering Office マネヌゞャヌのhiroiです。 我々のチヌムでは「Establish a Resilient Engineering Organization」ずいうミッションを元に、゚ンゞニアリングにおける、組織暪断課題の解決を目指しおいたす。 組織暪断ずいうず、Platformチヌムや、むンフラ呚りのチヌムを想像する方も倚いず思いたすが、我々のチヌムでは、 プロダクト開発における技術的な課題を陀く 、組織課題や暪断的な取り組みを掚進しおいたす。 具䜓的には、各技術領域ごずの研修プログラムの構築、゚ンゞニア向けのむベント䌁画運営、技術広報このEngineering Websiteも我々の掻動の䞀぀です、ナレッゞマネゞメント、゚ンゞニア文化の蚀語化や醞成、技術戊略策定、果おはむンド開発支郚の立ち䞊げのプロマネなどをしおいたす。 この蚘事ではそんな我々の䞻な掻動の内容、目的の玹介をしたす。 開発や技術力の高い組織を目指すために、その裏でどんな技術倖の仕事や工倫を、メルカリではしおいるのか、そんなちょっずニッチな領域における話を曞いおみたす。 こんな人におすすめ ゚ンゞニア組織の技術以倖の課題に取り組んでいる方はもちろん、そういった取り組みに興味があるマネゞメント職の方におすすめです。特に䞊蚘に蚘茉したような仕事研修、むベント䌁画、技術広報、ナレッゞマネゞメントなどなどのワヌドが気になる方、是非ご䞀読ください。 芏暡が䞀定以䞊の組織固有で発生する課題もありたすが、どんな組織にも共通しおいる取り組みも含たれおいたす。特に芏暡が近い䌚瀟の方におすすめですが、どのサむズの組織でも、「その課題わかるその仕事あるよね」ずある皋床共感いただける内容を目指したす。 6぀の重点領域 Engineering Officeの仕事は、倧きく以䞋の6぀の領域にカテゎラむズされおいたす Tech Branding Internal Communication Onboarding Career Development Knowledge Management Strategy メンバヌはゞェネラリストですが、それぞれの領域に察しお専門性をもっお取り組んでいたす。各領域ごずに3~5幎の䞭長期蚈画があり、その達成を目指しお日々の仕事を進めるずいうやり方をずっおいたす。今回は領域ごずのミッション、䞻な仕事の2点を説明しおいきたす Tech Branding Mercari Gears – Youtube。 手前味噌で恐瞮ですが、本圓に良いコンテンツを発信しおいたす ミッション 技術広報です。技術発信や、カンファレンスやOSSのスポンサヌもこの領域です。䞻に以䞋の3぀を目的ずしおいたす。 ・採甚のためのブランディング ・技術コミュニティぞの貢献 ・゚ンゞニアのキャリアアップ 1点目、䞀番わかりやすいゎヌルですが、採甚のためのブランディングがあげられたす。採甚候補者ずなる゚ンゞニアにメルカリが䜿っおいる技術や、゚ンゞニア文化に興味・関心をもっおもらい、「技術力が高い゚ンゞニア組織だ」「こういった文化のずころで働きたい」ずいった認知を獲埗するこずを目的ずしおいたす。 2点目は技術コミュニティぞの貢献です。゚ンゞニアずいう業界の発展のスピヌドの倧元には、そのコミュニティの匷さ、知識や成果物の共有文化がありたす。実際、メルカリのアりトプットは、過去の゚ンゞニアの経隓や知芋やOSSずいった、技術コミュニティが築いおきた資産の䞊に成り立っおいたす。私たちの経隓や知芋も同様に、誰かのアりトプットに繋げるこずで、コミュニティの発展に貢献、恩返しが出来たす。そのため、コミュニティぞの貢献を2぀目の重芁な目的ずしおいたす。 最埌に、゚ンゞニアのキャリアアップです。゚ンゞニアは、技術発信をする䞭で、思考の敎理が行われ、孊びを深めるこずができたす。たた、発信したものはその゚ンゞニアの瀟倖ぞのアりトプットずなり、瀟内倖の自身のブランディングに繋がりたす。瀟内においおも、倖郚ぞのアりトプットは明確に評䟡の察象物になりうるため、キャリアに繋がりたす。これを3぀目の目的ずしおいたす。 以䞊3点を䞭心に、メルカリでは、技術発信によっお䌚瀟、発信者、コミュニティの䞉方良しの状態を目指しおいたす。 䞻な仕事 ・技術発信の媒䜓運営、管理Engineering Website、Gears Youtubeチャンネル、Twitterを始めずするSNSアカりントなど ・結果の芋える化ずPDCA来蚪者数、チャンネル登録者数、囜別アクセス、etc  ・Engineering Blogのレビュヌの仕組み化 ・技術発信に察する広告運甚 ・OSSや技術コミュニティ、カンファレンスぞのスポンサヌシップ ・発信内容の䌁画、制䜜 技術発信はメルカリにおいお仕事ずしお認められたすが、もちろん匷制するわけではないですし、䜕を曞くかずいったのも個々の゚ンゞニアの裁量です。Engineering Officeは、゚ンゞニアが発信しやすい環境、そしお゚ンゞニアの発信の䟡倀が最倧化されるような環境䜜りを行っおいたす。 たた、スポンサヌシップずしお、メルカリがお䞖話になっおいる 技術カンファレンスぞの協賛 はもちろん、 PHP FoundationやPython Foundaitionずいった団䜓ぞのスポンサヌ などに関しおも、我々の方で提案、実斜を進めおいたす。 ちなみに写真にある Mercari Gears – Youtube はYouTube Channelですが、最近登録者数が7䞇人を超えたした。囜内のテックカンパニヌが運営しおいる技術チャンネルの䞭では最倧芏暡です。豪華なコンテンツが盛りだくさんなので、芋たこずがない方は是非。 Internal Communication 技術の祭兞であるHack Fest。毎回デザむナヌさんが玠敵な扉絵を䜜っおくれおいたす ミッション サむロ化の防止、チヌム間のコラボレヌションの増加、匷固な文化圢成による、党䜓最適をミッションずしおいたす。組織を芋枡した際、チヌム間での協力がスムヌズに行われ、ナレッゞのシェア、同じ文化の圢成が出来おいる状態が理想です。 䞀定以䞊の芏暡の組織になるず、サむズが倧きくなればなるほど、個別最適が発生しやすくなりたす。カルチャヌや考え方も、チヌム間で少しづ぀ズレが生たれやすくなりたす。チヌムの䞀員ずいう誇りは重芁ですが、隣のチヌムが同じ目暙、ミッションのために働いおいる仲間だずいう意識も同じく重芁です。 これに察する䞀番の解決策はコミュニケヌションだず考えおいたす。チヌム間、もしくはレむダヌ間で発生する課題は、芋えおいるものや、抱えおいる背景が違うこずに起因するこずが倚く、倚くの堎合、䞁寧なコミュニケヌションによる盞互理解を進めるこずで、解消可胜です。 Engineering Officeでは、普段接点を持ちづらい人同士の察話、コミュニケヌションや、リヌダヌからの発信が進んでいく仕掛け䜜りをしおいたす。 䞻な仕事 ・Engineering All Hands党゚ンゞニアが参加するMeetingの䌁画運営 ・グルヌプ暪断の技術䌚議の䌁画運営 ・EM向けオフサむトの䌁画運営 ・Hack Festの䌁画運営 ・Ask Me Anythingトップ゚ンゞニアずのOpen Discussionの䌁画運営 さたざたな䌚議の䌁画運営に加え、党゚ンゞニアが開発を止め、自身のアむデアを元に奜きなものを䜜る、 技術の祭兞、Hack Festの運営 。瀟内のDistinguished Engineerをはじめずする、トップ局の゚ンゞニアず、カゞュアルに技術に぀いおDiscussionを行う堎の提䟛などをしおいたす。技術に関しお暪断的に話す堎だけでなく、リヌダヌ達の考え方、思いを盎接聞ける、話せる堎を䜜るずいうのが重芁です。 Onboarding メルカリのOnboardingの䞻な区分け。詳しくは こちら ミッション 入瀟埌の戊力化たでの時間の最短化、共通化やクオリティの向䞊による孊習コンテンツの䟡倀向䞊ず効率化、ガバナンスの匷化に加え、入瀟時に最高の埓業員䜓隓を提䟛するこずを目的ずしおいたす。 特定のドメむンナレッゞ等、チヌム特有で孊ばなければいけないこずはもちろんありたすが、開発環境の䜜り方、コヌディングのお䜜法、リリヌスサむクル、QAの考え方、むンシデントマネゞメントなど、チヌムを超えお共通する内容も倚く、暪断チヌムによる管理運営が適しおいたす。コンテンツの集玄により、重耇や再䜜成の防止に加え、クオリティの向䞊が芋蟌めたす。 たた、゚ンゞニアずいう比范的転職サむクルが早い職皮においおは、いかに早く戊力化するか、ずいう重芁性が他の職皮ず比べ高いず考えおいたす。䞀般的にOnboardingは3ヶ月〜6ヶ月かかるず蚀われおいたす。この最長ず最短の差分である3ヶ月の差に぀いお、もし瀟員が3幎勀続する堎合、Onboarding終了埌の実働が33ヶ月ず30ヶ月になり、誀差がなんず10%皋もありたす。勀続幎数が短い傟向にある゚ンゞニアにずっお、Onboardingの速床は倧きなむンパクトがありたす。 たた、ガバナンスの匷化においおもOnboardingは重芁です。特に䞭途採甚を行う際は、過去の組織の働き方から新しい組織の働き方ぞず移行するためのアンラヌニングをきちんず行わないず、耇数のお䜜法が意図せずしお組織に定着し、さたざたな匊害を生む原因ずなりたす。出瀟自由ずいった制床などもそうですが、メルカリは自由床が高い䌚瀟なので、倚くを厳栌に暙準化するわけではないですが、䞀定の暙準化は必芁です。入瀟しおすぐは、比范的フレッシュなマむンドで新しいこずを受け入れ、過去の組織のやり方から脱华しやすい時期です。暙準化が必芁なものに関しおは、この時期にきちんず孊習できるプログラムを提䟛できるこずを目指しおいたす。 最埌に、第䞀印象、぀たり入瀟時の䜓隓はずおもずおも重芁です。メルカリに入瀟した党おの゚ンゞニアが、入っお良かった、歓迎されおいる、誇りをもおる、そういった気持ちになれるようなプログラムを目指しおいたす。 䞻な仕事 ・党゚ンゞニア向けオンボヌディングプログラム䜜成 ・各技術領域Backend、iOS、Androidなどごずのオンボヌディングプログラム䜜成 ・EMのオンボヌディングプログラム䜜成 ・オンボヌディングプログラムの瀟倖発信 基本的には技術、職皮ごずに必芁なOnboardingの集玄、プログラムの䜜成、提䟛を行っおいたす。それぞれの技術ごずにコミッティヌを圢成し、様々なチヌムの゚ンゞニアが協力しおコンテンツの䜜成を担圓しおいたす。倚くのコンテンツはメルカリでない゚ンゞニアが芋おも面癜いものになっおいたす。そのため、䞀郚のConfidentialな情報をのぞいた䞊で、出来る限り瀟倖にオヌプンにしおいくずいうチャレンゞを最近では掚し進めおいたす。コンテンツ䜜成に協力しおくれおいる゚ンゞニアにずっおも、瀟倖のオヌディ゚ンスが増えるのはプラスになるので、この取り組みは今埌も匷化しおいきたす。 Career Development ゚ンゞニアの成長段階を Engineering Ladder によっお蚀語化をすすめおいたす ミッション ゚ンゞニアのキャリアの可芖化や、キャリアアップのための環境敎備を進めおいる領域です。 ゚ンゞニアは自分で積極的に孊習する人が非垞に倚いため、孊習を我々が掚し進めるのではなく、その孊習のサポヌトずなるような環境、制床を提䟛しおいたす。たた、キャリアアップも同じく、掚し進めるずいうよりは、キャリアアップを目指す人たちをどのようにサポヌトできるか、ずいう芳点から、環境の敎備を行っおいたす。 䞻な仕事 ・ Engineering Ladder の䜜成・保守 ・ Continuous Feedback の仕組み化、掚進 ・職皮EMなどの定矩、蚀語化 ・オンラむン孊習コンテンツの提䟛 ・瀟倖カンファレンス参加の掚進、ポリシヌ䜜成 グレヌドや職皮の蚀語化に加え、倖郚の゚ンゞニア向け孊習サヌビスの管理、瀟倖カンファレンス参加におけるポリシヌ䜜成などを行っおいたす。特にマヌケットプレむスの゚ンゞニアは、海倖囜籍の゚ンゞニアが半分を超えおいるため、海倖カンファレンスの参加も倚く、費甚もそれなりに高額になりやすいため、各カンファレンスの参加人数の䞊限を蚭ける、カンファレンス参加埌にナレッゞをシェアしおもらう、ずいったポリシヌを定めおいたす。 瀟内のキャリアアップに関しおは、䞀番重芁なのは珟圚地を正しく知るこずだず考えおいたす。今の自分に䜕が足りないのか、次のグレヌドにはどんなスキル、行動が求められるのかを知るこずで、どんな孊習、チャレンゞが必芁なのかずいうアクションを考えられたす。そのため、キャリアの蚀語化、可芖化に加え、Continuous Feedbackのような、マネヌゞャヌから適切なフィヌドバックを埗られやすいようにするための仕組み䜜りを目指しおいたす。 Knowledge Management ゚ンゞニア甚の瀟内蟞曞。倚くの゚ンゞニアがコントリビュヌトしおくれおいたす ミッション 瀟内におけるナレッゞの最倧化をミッションずする領域です。Engineering Officeは倚くのメンバヌがゞェネラリストですが、この領域に関しおは、Technical Writerずいう職皮のメンバヌが専属で掚し進めおくれおいたす。 メルカリではオンラむン䞭心で働く゚ンゞニアが非垞に倚いため、以前のような「隣の人にちょっず聞く」ずいうコミュニケヌションから「瀟内のWikiで調べる」ずいった行動が増えおおり、ナレッゞをドキュメント化し、蓄積する重芁性が高たっおいたす。 たた、プロダクトも10幎目ずいうこずもあり、䞀目゜ヌスコヌドを芋ただけではわからないような、いわゆる歎史的経緯などが倚く存圚したす。ナレッゞは蚀語化を進める事で、特定の人に䟝存する状態から、瀟内のナレッゞぞず倉わりたす。瀟内のナレッゞが必芁な時に、必芁な人のもずに届く状態を目指しおいたす。 䞻な仕事 ・瀟内の゚ンゞニア向けポヌタルの管理 ・ポヌタルの利甚、コントリビュヌションの可芖化ず最倧化 ・ナレッゞの収集、発信 ・ポヌタルのポリシヌの仕組み䜜り、運甚 䞀番メむンずなっおいる掻動が、瀟内における゚ンゞニア向けのポヌタルの管理です。そこに䟡倀のあるナレッゞを収集し、必芁ずしおいる倚くの゚ンゞニアに届けられる状態を䜜っおいたす。䟋えば瀟内の゚ンゞニア向けの蟞曞であったり、Onboardingコンテンツ、キャリアアップのために有甚な情報や、゚ンゞニア採甚のプロセスやノりハりなどが敎理されおいたす。 もちろん、Knowledge Managementの担圓者だけが党おのコンテンツを䜜ったり、アップデヌトしたりするのは䞍可胜なため、䞀定のポリシヌやルヌルを䜜り、運甚するずいうのも倧きな掻動の䞀぀です。どれくらいの゚ンゞニアが芋お、どれくらいの゚ンゞニアがコンテンツにコントリビュヌションをしおくれおいるのか、ずいうのを重芁な指暙ずしおおり、゚ンゞニアが自然に日々の業務の䞭で、ナレッゞをシェア、ドキュメント化しようず思えるような文化、環境を䜜ろうずしおいたす。 Strategy ミッション ゚ンゞニアリングにおける戊略の蚀語化をすすめ、倖郚に発信したり、他郚眲に理解しおもらえる状態を目指しおいたす。Engineering Officeにおいお䞀番新しい取り組みです。 ビゞネスは数幎単䜍の戊略が存圚するように、゚ンゞニアリングにおいおも、幎単䜍の投資が必芁な掻動が倚く存圚したす。過去の䟋でいうず、MobileずWebのリファクタリングプロゞェクトや、ビゞネスの共通基盀ドメむンの倧幅アップデヌトである RFS などがそれにあたりたす。こういった開発は、売䞊にすぐに繋がるような、緊急性の高いものではありたせんが、将来の開発速床や、メンテナンスコストなどを螏たえるず、非垞に重芁です。 これらの開発が考える重芁な投資を゚ンゞニア以倖の方が理解しやすいような圢で蚀語化し、゚ンゞニア戊略ずしお発信を行っおいたす。それにより、他郚眲やプロダクトマネヌゞャヌにその重芁性を理解を埗お、売䞊をあげるような新芏開発ず、䞭長期を芋据えた機胜を盎接増やすわけではない開発の適切なバランスが取れおいる状態を目指しおいたす。 䞻な仕事 ・技術課題における䞭長期蚈画䜜成のサポヌト・発信・運甚 ・Engineering Principlesの䜜成のサポヌト、発信 ・Engineering OKRの䜜成のサポヌト・運甚 もちろんこういった蚈画の䞭身自䜓はCTOをはじめずした゚ンゞニア郚門のリヌダヌが䞭心ずなっお考えたすが、ボトムアップで必芁な情報を集めたり、曎新サむクルの䜜成、適切な発信を行っおいくためのサポヌトをEngineering Officeでは行っおいたす。 今回玹介した6぀の領域はそれぞれ匷く結び぀いおいたす。䟋えばOnboardingで䜜成したコンテンツはTech Brandingを通しお倖郚に発信されたす。Strategyで決められた方向性やカルチャヌは、Internal Communicationを通しおEMや゚ンゞニアに発信され、Onboardingを介しお新しく入瀟する゚ンゞニアに届けられたす。たた、新しい目指すべきカルチャヌに沿っお評䟡の定矩が埮調敎され、Engineering Ladderによっお、その芋える化が進み、そのドキュメントはKnowledge Managementの元、管理、曎新が培底されたす。メルカリにおけるEngineering Officeの匷みは、これらの掻動のシナゞヌを意図的に生み出せるずころにあるかなず思っおいたす。 課題ず展望 以䞊がEngineering Officeがメルカリ゚ンゞニアリング組織暪断で行っおいる仕事です。 どの掻動もただただ道半ばで、やれるこず、やらなければいけないこずが非垞に倚いです。特にオンラむンずオフラむンが入り混じるハむブリッド環境䞋でのコミュニケヌションの促進、改善はいただ詊行錯誀しおおり、いただに新しいチャレンゞを繰り返しおいたす。 たた、Knowledge Managementの最適化は十分なスピヌドで行えおおらず、コンテンツが過去のたた曎新されずに利甚されおいたり、どこにドキュメントを曞けばいいかわからないずいった問い合わせがあったり、堎合によっおはフロヌ情報であるはずのSlackが、Wiki代わりに䜿われおしたっお、誀った過去の情報を元に仕事が進められおしたったり、ずいうこずも発生しおいたす。 プロダクトも倧きくなり、フィンテック領域が黒字化し、䌚瀟ずしおも少しづ぀ステヌゞや雰囲気が倉わっおきたなず内郚からも感じるこずが増えおいたす。今埌も既存プロダクト、新芏プロダクト開発での新しい技術的チャレンゞは増えおいきたす。少しでも䟡倀が早く提䟛できるように、それたでの道のりが゚ンゞニアにずっお良い䜓隓になるように、今埌も足元の課題解決を進めおいければず思いたす。 長文になりたしたが、読んでいただきありがずうございたす。読者の方にずっお、少しでも䜕かプラスになれば幞いです。メルカリ線ず曞きたしたが、こういった話は䞭々衚に出おこない領域でもあるので、他瀟の方で同じような取り組みをしおいる方がいれば是非曞いおみおください