天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

メルカリの成長を支えるデータ分析チームの「今」と「これから」に参加してきた

mercari.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、connpassのイベントページから引用です。

メルカリデータ分析チームの運営するMercari Analytics Blogでは、連載「メルカリのデータアナリストが向き合う11のテーマ」を開始しました。11人のデータアナリストがそれぞれ奮闘しているテーマについて語り、「メルカリの分析ってどんなもの?」という疑問に答えています。このイベントでは、ブログでは書ききれなかった「今」と「これから」についてお話します。Product / Growth / Infra / Insight の4チームが発表。マネージャー・メンバーの対談形式のため、チームの雰囲気が感じられるイベントになっています。ブログを読んでいない方でもお楽しみいただけます!

※Mercari Analytics Blogとは…メルカリAnalyticsチームがお届けするデータ分析にまつわるブログ。幅広い層向けにデータ分析のあれこれをお伝えします。

会で印象的だったこと

インタビューの怖さ

お客さんの声(特に実際の強い声)、というデータは非常に強く生々しい一方で、データ分析の観点でも非常に重要ではありますが、熱量があると特に、どうしても間に受けて顧客が言っていることをそのまま信じてしまったり、一人の声が大きいユーザに引っ張られてしまったりと、諸刃のつるぎ的な一面があるよね、というお話が出ていました。

また、ユーザーインタビューなど定量的なインタビューはかなり時間を要するため、ROI観点で本当に有益かを考える必要があるということでした。

データの使い方

インフォメーションスキーマはもちろんですが、auditlogをかなり見ている印象があるというお話が挙がっていました。

また、データ基盤はまだあまり整理されていない状態でも分析に使われすぎている節があり、これはメルカリならではの悩みかもしれない、とお話が挙がっていました。(一般的にはデータを整備しても中々開発チームが使ってくれないという悩みがありがちで、データが整備されておらず分析が難しい中でもガツガツ使っているというのは恐ろしいという話がありました)

新規事業におけるデータ分析の活用

新規事業では、思いとは逆行するような指標が出てくる機会も多く、頻繁にプロダクトの定義を見直しながら動くことがあるため、「泥臭い」仕事をすることも多いというお話でした。(ただ、新しい発見が毎日のようにある楽しみもある)

全然性質の違う多種多様なデータを頻繁に切り替えながら分析をしていく経験は、新規事業ならではの面白さがあるということです。

競合分析

他社のプロダクトに関する競合分析も、プロダクトの分析をしていく中では実施しているということでした。

ただ、競合他社がどのように使われているかや競合他社のプロダクトに関するデータよりも、実際に顧客がどのように自分たちのプロダクトについて考えているかを優先することが多いということです。

会全体を通した感想

パネルディスカッション形式で進行していましたが、さまざまなチームが代わる代わるデータ分析に関して議論を進める形式で、全然違う観点からデータ分析の話を仕事にどのように活用しているか聞くことができて、面白かったです。

また、パネリストのプロフィールが非常に個性的かつ多様性があったのも印象的でした。

XP祭りにプロポーザルを出しました

confengine.com

XP祭りにプロポーザルを出しました!興味がある方は、是非likeをお願いしますー!

出した経緯

少しTwitterのタイムラインでも話題になっていましたが、実はXP祭りは個人的には登壇ハードルが高いカンファレンスで、昨年は登壇を見送ったカンファレンスでもありました。

今年もちょっと出すのは見送りしようかと思っていたのですが、分散アジャイルチームの会で、皆さんが軽い気持ちでどんどんプロポーザルを出していくのを見た上に、発表のネタ*1や聞きたいことまで貰ってしまったので、これは書くしかないと思って、プロポーザルを出すことにしました!

話す内容について

今回は、500日以上毎日継続して書いている、このブログの話をしようと思います。

正直まだそこまで内容は固まっていないので、これから発表に向けて考える過程でアップデートしていくような形になっていくと思うのですが、

  • ブログを書き始めてから今に至るまでの流れ
  • ブログを書き続けるコツ
  • ブログをいかに楽にかくか
  • ブログで書く話、書かない話の線引き

あたりの話をしていこうと思っています。
他にも色々と聞きたいことがある方がもしいらっしゃれば、連携していただければ、テーマに含めようと思いますので、ご一報ください!

発表の形式や雰囲気については、XP「祭り」なので、お祭り感を少しでも出せるような感じがいいなあと思っていて、ここの仕掛けは今から考えていく予定です。

プロポーザルを出してみての感想

その場の流れで、過去で一番雑に書いて出してしまったプロポーザルになりましたが笑、これくらいざっくりしている段階でプロポーザルを出せたのは、それはそれでよかったのかなと思います。(毎回結構考えすぎて締め切りギリギリになってしまう傾向にあるので)

自分はブログでお金を稼いでいる訳でもなく、1日に何千アクセスもあるような記事を常に書いているようなわけでもなく、話題になるような記事を書くこともないので、ただメモ帳を公開しているんですくらいの話しかできないと思っていて需要はない話だと思っていたのですが、意外と皆さんから需要があったのは、知れてよかったです。

お祭りなので、いつも以上に楽しみたいと思います!

*1:発表のネタは色々といただけたのですが、聞きたいという声が一番多かったブログの話にしました

#xpjug XP祭り2022のプロポーザルをみてコメントしたり、つくったり、わいわいするぞに参加してきた

distributed-agile-team.connpass.com

今週も分散アジャイルチームの会に参加してきたので、会の様子と感想を書いていこうと思います。

XP祭りのプロポーザルのフィードバックが欲しい!

confengine.com

こちらのプロポーザルに対してのフィードバックを参加者の皆さんでしていきました。

  • 会を一言で表すと?というところから考えると良い
  • ラジオ感覚で参加できるセッションなのか?というのが気になるので書いておくといいと思う
  • 結構解釈が難しい本ではあるので、この本の内容を追随できるというのは貴重な会だと思う
  • セッション時間が100分だと、参加のハードルは上がる(拘束時間が長い)
  • XPの初版と第二版をみんながどれくらい読んでいるのか?というのが気になる(読んでいる人そんなにいない?)

良いプロポーザルの書き方のみならず、XP祭りの特徴や、どういうセッションにするとどのようなことが起きるのか?といった話も聞けて大満足でした。

XP祭りスクフェス仙台のプロポーザルを見ていく

続いて、XP祭りスクフェス仙台のプロポーザルをみんなで眺めたり、プロポーザルを出さないのかお互いに牽制しあったりしていきました笑
プロポーザルを眺めている時間では、プロポーザルや発表者に対する印象の話を聞くことができて、XP祭りスクフェス仙台も、より楽しみになる時間でした!

XP祭りはextreamという単語が入っていることもあって中々ハードルが高く感じていたのですが、XPの話はほとんどされないという話だったり、お祭り感があってテーマもフリーだという話を聞けたのがよかったです。

まなパタ

きょんさんが入ってきたこともあって、突如まなパタの話になりました。
パターン・ランゲージの本来の意義や定義とはずれてしまっている気がするという話が出ているのではないか?ということで、

  • パターンの基になっているエピソードが、学習科学といった再現性のある分野のエキスパートによるものではない点に違和感がある。話の内容の共感はできるが、パターンにはなっていない。
  • 共感してもらおうとするターゲット層が40-50歳に絞られているような気がする。科学的に裏付けられた話よりも経験で押していくようなイメージ。
  • 実践している本人がまとめているのではなく編集者が開いてまとめているのに違和感がある。

全体を通した感想

今日は冒頭の方で及部さんと森さんが盛り上げてくれて、いつもとはまた違った雰囲気になっていたのですが、XP祭りの歴史や過去にあった印象的なセッションの話をはじめ色々と知らない話を聞けた上に、重鎮の(?笑)方々もテキストチャットでスクラムにまつわる面白い話を色々としてくれて、とっても楽しかったです。

特に、Tommyさんが、XPは最初から間違っていることを教えてくれるという話をしてくれていたのが、すごく楽しみです。

本来は "Test-Driven Development" の略語である TDD ですが、いつの間にやらジョークが広まってしまい、 "Tommy-Damedashi Development" へと発展しました。 これまでイベントで "その計画は最初から間違っている", "その品質は最初から間違っている" を登壇しましたが、今回は XP の 19 のプラクティスにのせて、間違ってることをいろいろ "ダメ出し" してみます。 逆から見ることにより、一層 XP が深まるハズです。

ドメインモデルパターンのクラス設計に取り組む現場の苦労ばなしに参加してきた

modeling-how-to-learn.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の前提

最初に会で話す内容についての前提について話がありました。

  • ドメインモデルを用いた設計について頻繁に議論しており、4人の中ではかなりコンテキストが共有されている(コンテキストを省いて座談会をしてしまう可能性がある)
  • 普遍的な設計の話をするつもりだが、言語はJavaを用いているので、Javaの概念が前提になっている可能性がある。

会で印象的だったこと

凝集度の捉え方の違い

トランザクションスクリプトは、リクエストベースで捉えると凝集度が高いように感じられますが、ドメインモデルの視点で捉えるとあちらこちらに業務ロジックが進んでいて凝集度が低いように感じられてしまうという話がありました。
トランザクションスクリプトからドメインモデルへの発想の転換が難しくなる原因の一つとして捉えることができて、面白かったです。

ドメインモデルが実践できないパターン

ドメインモデルが実践できない現場を見ていると、

  • ドメインモデルに関する知識がない
  • ドメインモデルに関する知識はあるが、実践できない
  • ドメインモデルの知識もあるし実践もできるが、やっていない

の3パターンがあるというお話を聞いていきました。

ドメインモデルに関する知識がない」場合は知識を教えればよくて、「ドメインモデルに関する知識はあるが、実践できない」場合はIDEの活用方法(ドメインモデルに必要なコーディングを素早く行うためのテクニック)を教えたりすれば良いということでしたが、「ドメインモデルの知識もあるし実践もできるが、やっていない」場合だけはどうしたものか分からないということでした。

実際にコードを書いて見せればドメインモデルのキャッチアップが進む?

一からドメインモデルを書いていくというのは難しいけれど、すでにコードベースがあったり、わかる人がコードベースを作ってあげれば雰囲気を掴んで書けるようになるのでは?という問いかけがあったのですが、実際の所コードベースがあってもなかなか馴染める人は少ないようお話が出ていました。

また、雰囲気だけ掴んで何となく書けるようになったけど本質は理解できていないので、クラスの書き方とかがドメインモデルっぽくなっても、ロジックが散らばりだしたりとあまりドメインモデルの恩恵を受けられていないコードになってしまうという話が出ていました。

トランザクションスクリプトが選ばれやすい理由

ドメインモデルの恩恵がなかなか分かってもらいにくいという話を受けて、高崎さんから「逆にトランザクションスクリプトが選ばれる理由は何だと思うか?」という問いかけがされました。以下、話で出ていた要素を箇条書きで挙げていきます。

増田さんが感じるドメインモデルに対する周囲の温度感の変化

増田さんがドメインモデルに注目し出したのは2008年だということですが、その際には本当に周りからは相手にされず、ブログで独り言を書いているような感覚だったということです。
その後、コミュニティ活動をしていく中で理解をしてくれる人が現れ出して、2013年に本の出版の話をもらうまでになったということでした。

ただ、スタートアップの人たちは本を出版して注目をしてくれた一方、SIerの人たちからは「面白いけど実践は難しい」という感想が殆どだったということで、SIerの人たちからも賛同を得られるようになったのはここ最近の話だと増田さんは感じているようです。*1

ドメインモデルにまず落とすところ

ドメインモデルを実践しようと思ったもののまずはどこからやればいいのか分からないという場合には、金額や小数点の切り上げ、日付などのロジックをカプセル化して、value objectを積極的に作っていくと良いという話が出ていました。

Kent beckテスト駆動開発で語られている例がMoneyだったこともあって、納得感があ理ました。

ロジック化と自己文書化のバランス

アクティアの方々は、元々はドメインモデルの自己文書化に重心を置いていたということで、業務ロジックがないものでもValue objectをどんどん作っていたようですが*2、今は業務ロジックがないものはvalue objectにしていないということです。

自己文書化に振り切った結果どのような姿になるのか、という話の一端が聞けて面白かったです。

業務に目を向ける人とプログラミングに目を向ける人

ドメインモデルを実践するにあたっては業務知識も必須で、業務に興味を持てることも重要ですが、エンジニアはなかなか業務よりもプログラミングに興味を持つ人が多いし、業務知識を持っているマネージャー層の人はプログラミングはできないというし、中々両立させるのは難しいのかもしれない、という話が出ていました。

SIerでも自社開発でもこの傾向ははっきりあるということですが、増田さんの観測範囲では、業務知識を持っている人がドメインモデルを用いたプログラミングに取り組み出す例は見たことがないようで、プログラミングが好きな人が、より良いプログラミング方法を探究していく中でドメインモデルに目覚めるパターンしか見たことがないということでした。(ただし、この結果を良いとは思ってはおらず、業務知識を持っている人がドメインモデルを用いたプログラミングに興味を持つパターンも探求していきたいと話がありました)

プログラミングが好きな人がドメインモデルに目覚めて業務知識をつけていくパターンに至るまでの過程

トランザクションスクリプトリファクタリングをしていく中で、パッケージ構成の整理を話すタイミングが出てきて、その中でわかりやすいパッケージ構造に興味が湧き、パッケージ整理をするために自然とドメインの知識をつけ始めるというパターンが挙げられていました。

また、パッケージ構成については、ツリー構造に捉われなくなり出すと、一段上のステップに進んでいる感覚があるということです。

全体を通した感想

今回は普段の増田さんのイベントよりも座談会の比重が重かったのもあったのか、いつも以上に現場のリアルな話が聞けたのがよかったです。
普段はもうちょっと座談会聞きたい。。と思うこともあるのですが、今日はお腹いっぱいになるまで話を聞けました!

個人的には綺麗な話よりも現場のドロドロした話を求めているので、大満足でした。

参考資料(会の冒頭で使われていたスライド)

speakerdeck.com

*1:最近の仕事は、SIerの案件をずっとやっているということでした

*2:value objectの自動生成ツールもあるということ

大人のソフトウェアテスト雑談会 #110【平穏】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

何となく多言語が学べる

アプリのローカライズをしていたり音の真似をひたすらしていたりといったように、日々の仕事で他言語に触れていると、いつの間にか外国語のパターンがわかるようになっている(読めたり話したりできるくらいにはなる)というお話が出ていました。

途中から聞いて入ったので文脈はわかりませんが、何とも葛飾らしい話でしたw

Tommy Driven Development

Kent beckの師匠だというTommyさんからありがたいお言葉がありました。

Tommyさんは現場で働いていてSIerにもやったが故の発言だったようですが、最近Mockが書けなくなってきたというオンライン区長から、テストコードが書けないテスターの存在価値があるのか?という問題提起がされて、大いに盛り上がりました*1

カンファレンスフルスタックエンジニア

カンファレンスのサポートとして凄まじい活躍を見せているこばせさんのお話を聞いていきました。
自分も含めてみんな本心でこばせさんの凄さを実感しているようですが、こばせさん本人は自身のカンファレンスの裏方としての凄さをあまり実感していないのか、こばせさんはあまり褒められている気がしないようで、残念です。

結果責任を負わない

はしごをかける役割の人がはしごをかけたあとは、もしそのはしごを登ってもらって登れなかったとしても、登れなかった結果責任を感じることはない、という話を聞いていきました。

eroccoさんが、自分がはしごを登らないように止めてもはしごを登ろうとする人にはしごを登らせた結果はしごから落ちてもそれを気に掛ける必要はないし、はしごを登らせられなかったことを気に病む必要はない(非情でもない)というお話をしていたのも、納得感が強くて印象的でした。

フェイクドアテスト

www.j-cast.com

こちらの話から、フェイクドアテストはすごく有効だけど、まずは身内の人にちょっと試してから反応を見るべきで、本当にお腹が空いている人がこのテストを受けたら怒るだろうという話をしていきました。

全体を通した感想

今日はTommy Driven Developmentの話以外は真面目な話やドロドロした話が多かったですが、個人的には、errocoさんの話を中心に楽しむことができました!

おおひらさんに熱くQAについて教えてもらうことだけできなかったので、また次回に教えてもらおうと思います。

*1:オンライン区長が自ら話を脱線させていくハプニングがありましたがww

BDDに入門する

最近QAとして働くようになったこともあって、BDDを改めて勉強し直しています。
そこで、勉強していく中で参考にした本とそれぞれに対するコメントを書いていきます。

The BDD Books - Discovery

leanpub.com

最近日本語版が出版されたThe BDD Books -Discoveryですが、推薦の言葉にもあるようにBDDの日本語版入門書としては、これ以上ない本なのかな、と思います。

BDDを実践しようと考えた際、Gherkinなどはフォーマットがシンプルな分、キャッチアップもしやすいですし現場での導入も簡単にできるように思えてしまいますが、本書に書かれているような目的を正確に理解できていないと、チームの開発の足を引っ張るような活動になりかねないので、BDDの実践を考えるならまず本書から読んだほうが良いのかな、と個人的には感じています。(自分自身、Gherkinは数年間利用していましたが、この本を読んで、Gherkinの強みの一部しか利用できていなかったことやチーム全体の資産としてBDDを活用しきれていないことを痛感しました。)

Formulation: Document examples with Given/When/Then (BDD Books)

leanpub.com

上の続編。

こちらは日本語訳は出ていませんが、上の本を読んで「心構えはわかったけどじゃあどうやって実際にBDDの実践をしていくの?」となったらこちらを読んでいくのがいいのかな、と思っています。

BRIEFの原則やGherkinの書きっぷりの具体例が、登場人物たちの会話という具体的な例を通して理解できるので、内容が頭に入ってきやすいですし、とりあえずGherkinを書いてみたけどなんか違うような気がするんだよな。。と考えているような状態のチームには特にお勧めできるのかな、と思います。

The Cucumber Book: Behaviour-Driven Development for Testers and Developers

www.amazon.com

BDD本の中でもかなり実践的な本で、現場でBDDがどのように開発を導くのか?(データモデリングにどう繋がるのかやGOOSで語られているような開発にどう近づけていくのか?...)というのが詳細に書かれている印象があります。
内容もわかりやすく、Cucumberの強力さ(要求分析、開発、テスト、リファインメント...様々な場所で活用できる)が実感できる本です。

一方、本の構成や説明の仕方が、BDD=テストという思想を強めやすい内容になっているので*1、BDD booksと合わせて読むといい本かな、と思います。
また、開発者向けの本だなあという印象も強いので、エンジニア以外の人に勧めるのは少し憚られる本でもあります。

BDD in Action

www.amazon.com

BDDと言ったら個人的にまず思い浮かぶのがこの本で、BDDのバイブル的な書籍になっているかな、と感じます。

BDDが開発全体でどのような位置付けでどのような役割を果たしているのかや、それを支える周りの構造、ソフトウェア開発をしていくに当たって抽象度を場面ごとにどのようにコントロールしていくのか?、といった考え方が整理されており、素晴らしい書籍だと感じています。

BDDにおいて振る舞いを定義するためのコツが、わかりやすく具体的な例や豊富な図を用いて書かれているので、洋書ですが割と読みやすいのも特徴です。

その他

その他にも幾つかの本を読みましたが、上記4冊を読んだ後ということもあって、その他の本についてはそこまで目新しい内容はありませんでした。

一応、参考程度に本だけメモしておきます。

www.amazon.co.jp

 

あと、読めていないですが気になる本も一冊貼っておきます。

その他にも、

atmarkit.itmedia.co.jp

logmi.jp

の記事は読みやすい上に、本記事で紹介した本のエッセンスがぎゅっと詰まっているのでお勧めです。

*1:テストではない、と完全に否定できるものではないですが、BDD Booksを読むとBDDの罠や悪用につながりかねない考え方だと個人的には解釈しています

JJUGナイトセミナー「初めてのひとのためのSpring/Spring Boot」に参加してきた

jjug.doorkeeper.jp

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

サーブレットやその他のフレームワークを使ったことはあるし、Javaの知識もあるけれどSpringやSpring Bootを初めて学ぶ人を対象に、SpringやSpring Bootをの基本を説明してくれるイベントです。

会の様子

以下、常体で話されていた内容を書いていきます。

Springとは

  • VMwareが開発しているオープンソースJava FW
  • Rod Johnsonが自著のためにサンプルコードを書いたのが始まり
  • 2022年にJDK17以上が必須となるSpring6.0がリリースされる。

DIコンテナとは

インスタンスの入れ物。このコンテナで管理されているインスタンスをBeanと呼ぶ。

Beanを定義する方法は以下の4つ。*1

  • コンポーネントスキャン(@Componentが付いているクラスをBean管理する。@ConfigurationがついているJava Configで指定したパッケージ内の@Componentを探す)
  • Java Config(Java Config内のメソッドに@Beanをつけると、そのメソッドの戻り値が@Beanになる)
  • 関数型Bean定義
  • XML

Java configを指定してApplicationContextを作成すると、DIコンテナが作成できる。ApplicationContext#getBean()でBeanを取得できる。

コンストラクタに@AutoWiredをつけておくと、DIコンテナがそのコンストラクタを使用して、適切なBeanを引数に代入してくれる。*2
なお、@AutoWiredはコンストラクタ以外にもつけることが可能だが、クラスをイミュータブルにするためにはコンストラクタにつける以外の方法はないため、コンストラクタにつけることを推奨(=コンストラクタインジェクション)

AOP

Beanに対して割り込み処理を定義するための仕組み。今回のイベントではあまり詳しく説明しない。

Springのサブプロジェクト

Spring JDBC

JDBCによるDBアクセスコードをシンプルに書くことができるサブパッケージ。

Spring Tx

トランザクションの開始・コミット・ロールバックを自動で行うパッケージ。
@Transactionalを付加したメソッドにAOPで割り込み処理をする。

Spring MVC

サーブレットベースで作られたWebアプリケーションフレームワーク。(ただし使い手はサーブレットベースで作られていることを意識することはほぼない)
MVCモデルの雛形として機能し、Controllerの作成やViewとの連携*3ができる。

その他
  • Spring Security
  • Spring Data
  • Spring Batch
  • Spring Cloud

などなど(サブパッケージは膨大にあるので詳細説明は割愛)

Spring Bootとは?

Springで開発をしていくと、ライブラリがあまりにも多すぎる上に記述が必要なJava Configも大量にあり、開発を始めるまでが大変であるという課題がある。
この課題を解決するために、Spring Bootが登場した。

具体的には、ライブラリをまとめたライブラリ(Starterライブラリ)と、Java configの定義を少なくするためのAuto ConfigurationがSpring Bootで用意されている。

様々な便利機能*4が用意されているが、開発を始めるまでの準備を楽にして開発の一歩目を早く踏み出せるようにすることにフォーカスしており、開発を始めた後Spring Bootを使っていて楽に開発できるということはない。

参考資料

www.docswell.com

speakerdeck.com

speakerdeck.com

www.slideshare.net

springfest2020.springframework.jp

qiita.com

spring.pleiades.io

会全体を通した感想

業務で今更ながら(?)初めてSpring Bootを使うことになったので参加したのですが、エントリーポイントとしてありがたいでした。

*1:上位2つが一般的にはよく使われる

*2:クラス内にコンテキストが一つの場合は@AutoWiredをつけないことが多い

*3:作成できるViewは、Thymeleaf, FreeMarker, Groovy Templates, JSP...

*4:実行可能JARによるデプロイのコスト削減、application.propertiesに外部設定を逃すことが可能、Actuatorによる監視が可能でメトリクスがWeb APIとして提供されている