mosowave

sinamon129による(主に)技術ブログ。Ruby,Ruby on Rails,Elasticsearchやその他について書きます。

TokyoGirls.rb Meetup vol.1で「システム障害との向き合い方」を発表した

TokyoGirls.rb Meetup vol.1というRuby勉強会で登壇してきました。
どうもこんにちは、しなもんです。
このブログは、完全に登壇後記を書く場所と化してきました。

今回は*1お酒を飲んだら明日起きれなくなりそうなので*2シラフです。
(その代わり、セブンイレブンのレアチーズデザートストロベリーを食べています。二日に一回ぐらい食べてる)


techplay.jp

TokyoGirls.rbは女性も参加しやすい(でも女性限定ではない)Ruby勉強会で、
登壇者が全員女性、参加者は男女半々になるように枠が設定されていて、
会場に行くと男女比半々ぐらい(登壇者やスタッフが女性が多かったので、ちょっと女性が多め?だったかな)
という感じの多様性がある会でした。

特にRuby界隈のコミュニティはどこもすごく平和&技術の文脈において女性だけでコミュニケーションをとる必要はないとおもうので、
女性向け勉強会は何か理由がないと行かないことにしているのですが、
Rails Girls等、初学者にプログラミングを教える系のイベントにはコーチとして参加したりします)
「でも女性限定ではない」という多様性の担保をしている部分に共感したのと、
運営メンバーへの信頼が高く、依頼をいただいた時にすぐに登壇させてもらうことにしました!

実際、他の登壇者の方の発表内容も面白く、質疑応答も多くtwitterもすごく盛り上がっていて、
みている感じ全体の満足度の高さを感じました!
togetter.com



私の発表した内容はこちら↓

speakerdeck.com

さて、スライドにも書きましたが、りさきゃんちゃんから「ごりごりテックな話を」というオーダーがありまして、
はてさてどうするかなと考えていて、これまで遭遇してきたやばい障害とかバグの話とかするかー?みたいな話をしてたのですが、
その前後ぐらいで、スタートアップでサービスの小さい時期からほぼ一人で回してきた系エンジニアの方々に、
チームの人数が増えた時に障害対応を周りにスムーズにやってもらうにはどうすればいいですか?みたいな話を相談されることが度々ありまして。
「あらかじめいたメンバーと一緒に障害対応をするようになったことがある」という経験と、
「人数が増えた後に障害対応をするメンバーとうまくやってきた」という経験からなんか話せないかなーと思い今回の話になりました。

あとは、割とプログラミングを初めて1年未満・1~3年の方が多いというデータをあらかじめもらっていたので、
(登壇者向けの事前情報のgistに必要情報が完璧に掲載されていて、運営の仕事の丁寧さを感じました...!)
障害対応やってみたいけど、強い人じゃないとできなそう?と思ってる人向け(自分もそう思っていたので)のお話とかもさせていただきました。

前日の20時ぐらいに、資料の進捗10%ですって書いてたのでいろんな人に心配されていたのですが←、
なんとか間に合って無事発表できて、そして良い感想を沢山いただけて安心しましたw
(自分が思っていたよりびっくりするぐらい好評で、資料がめちゃくちゃシェアされてビビりましたw)

あらためて、運営の皆様、ご静聴いただいた皆様、ありがとうございました!

ちなみにだいぶん余談ですが、「このイベント以外のRuby勉強会で話しても大丈夫な内容の発表にする」みたいなのが個人的な裏テーマでした。
(参加しやすいけど、内容的には普通のRuby勉強会の空気になると、今後そういう場に行くきっかけになるかな?と思って。)

私自身はワークライフバランスしない生活が好きだし(ワークisライフ、そして死なない程度に休む)、独り身で自由だし、
一応大学の情報系学部を出て新卒からウェブアプリケーションエンジニア職という何の面白みの変哲も無い感じなので、
そういうプロファイルにはできるだけ触れずに、いつも通りの発表をしてみたつもりです。

こういう活動が続いて、最終的にエンジニア界隈での男女比が気にならない状態になって、
girlsっていう単語をつけずとも、枠を半分にせずともバランスの良い状態になるといいなと思っていて、
でも最初にRailsGirlsのコーチをした4年ぐらい前から考えると随分と近づいてる気もします。
いつかそういう日がくるといいなぁ、そのための活動には積極的に参加したいな、と思うのでした。
(もしそういう話があったらお声がけください!)

では、また。

*1:前回のブログも、前々回のブログも酒を飲みながら書いてた

*2:現在午前3時です

大江戸Ruby会議07で生活発表した #oedo07

大江戸Ruby会議という地方Ruby会議に登壇して来ました。
どうもこんにちは、しなもんです。
久しぶりにブログを書くと、書き方が思い出せなくなりますね。

前回と同様なぜかお酒を飲みながら*1お送りします。

regional.rubykaigi.org

大江戸Ruby会議07は、浅草周辺で毎週火曜日に開催される Ruby ミートアップの Asakusa.rb の設立10周年を記念して開催される地域Ruby会議ということで、
10周年ということで非常におめでたいイベントでした。
Rubyistの皆さんの生活発表があったり、
@thejonanshowさん(通称デカ外人さん)のkeynoteがあったり(日々の生活を振り返って心当たりを感じてドキッとしてしまうような、とっても面白くて印象にのこるいい話だった)、
Ruby3に入れるかもしれないbreaking changesに関して意見がある人を中心に議論したり(Rubyコミッター・Railsコミッター・gem作者メンテナ・言語を使う人などいろんな立場の人がそれぞれ懸念や利点を話すのが、面白かった)、
10年を振り返りつつ、豪華ゲストが出てくる10周年記念講演があったりと盛りだくさんなイベントでした。

Rubyコミュニティにいくと、「いい意味での人間味というか人間くささ」みたいなものを感じることが多くて、
改めていつも使っている言語やライブラリ等は誰かが考えて作っていたり、その人達同士がどういう風に考えているのかみたいなことを意識することが多かったですね。
Twitterで#oedo07のハッシュタグをみると、だいたい現場の雰囲気がつかめるかもしれない。


はてさて、主催の@amatsudaさんにお声がけいただきまして、ninja talksで登壇して来ました。
スライドはこちら
speakerdeck.com

お誘い頂いた時にテーマの縛りとかは特にないと言われていて、そして過去の登壇者のスライドを見ていると、インパクトの強いものが多くて、
だいぶん話す内容を考えるのに苦労をしましたw
スライド中でも出しましたが、Asakusa.rbに来ている人達は私の尊敬するRubyistの方々ばかりで、
自分が20分枠をもらって話す内容って何がいいんだろうって思っていました。
(終わった後考えてて、なんかどういうものを求められてるのかとかをもうちょっとヒヤリングしたらよかったなぁ、と思ったりもしました。今度反省がてら聞いてみよう)

「自分が体験した具体的なエピソード」をメインに話すと、自分にしか話せない話になるというのを前回の登壇準備時に聞いて学んだので、
とりあえずまず最初に「プログラムを書き始めてから体験した、自分の人生においてインパクトのあった出来事」をとりあえず書き出しました。
かいたのはこれ某登壇ネタ出し - HackMD
恥ずかしいけど見せた@ujmさんがこれも公開しようっていってくるのでww貼っておきますが、勢いで書いた文章なので読みやすくないし後長い。

で、エンジニアやっていこうってきっかけになった時の話と、好きな領域の会社で仕事すると便利て楽しいよっていう話と、最近の技術との向き合い方を変えないとなーと思ったのでその話にしました。

一番最初の話は、自分の中では結構インパクトはあるけど割と昔話になのは自覚してて、
なのであんまり実はあんまり出したくなかったんだけど(昔のよかった話に囚われたくないじゃないですか)、
まあ自分のモチベーションを語る上では外せないので入れて見ました(結果的に盛り上がりはあった)

二個目の話はこの領域の事業がすきだからそういうのやってる会社にするみたいな話ってあまり出てこないなって思ってて、
(金とか食とか旅行とかは結構あるけど、ファションとかの領域は少なくともエンジニアでしている話を聞いたことない)
でも実際それが仕事のモチベーションとか人生の満足度とか自分の成長に寄与してることって多いなって思ったのでその話をしました。

あと最近転職したのでその話を結構したかったんだけど、時間の尺上あまり話せなかったなぁ。
今の会社はRiLiという会社で7月からjoinして、トレンドが好きな女の子向けにメディアとEC事業をしている会社です。
この話をしそびれたんだけど、社長は私が大学生の時からいつかこの人と一緒に働きたいと思っていた(当時はエンジニアとして力も今よりなかったし、一方的に知っている人だった)人で、たまたま2年ぐらい前ファッション検索の話を勉強会でした時に聞きに来ていて、そこから会社に遊びにいくようになってというのがきっかけで、ファッションxITの領域において実現したいことがとても共感できる(というかそれ!それ!って感じ)。だからいまはがんばるぞ!ってかんじです。スライドにかいたけど会社の人たちがつくるものはとっても素敵で、私も自分の領域で支えていきたい。

三個目の話は、転職話に関連するけど1人目のバックエンドエンジニアになったので、0からシステムをつくる上で技術選択から設計実装運用まで、
フロント以外ほぼ一人でするとなった時に、過去2-3年とまたキャッチアップする必要のある情報だったり、探求することろを変えていかないとなーみたいな話。ちょっと浅草遠いんだけど、たまにいこうかなと思っています。
具体的にはActiveStorageで結構色々調べて考えておかないといけないことが出て来たし、ちょっとずつ緊急度が低いけど重要度が高いことやっていかないとなーと思って。緊急中毒、めっちゃウケてたけど7つの習慣にでてくる気がする(新卒研修の時に緊急中毒チェックみたいなのやったw)。

緊張してできなかった話とかもあったので、ざっくり各部分の話をしてみました。
会場内でおもしろかった・共感したという話をちらほら聞くことができたので、とりあえず少し安心。
今後生活発表する機会がある時には、もっとテックトークよりのことができるようになるといいなぁ。


そんなこんなで、運営の皆様、ご静聴いただいた皆様、ありがとうございました!

余談ですが、
あと、「女性エンジニアでこの年齢でパワフルにやってるからすごい」みたいな感想をいただけることがあって、
もちろんお褒めの言葉だと思って受け取っているのですが、
やっぱり「下駄を履いてる感のある状態」があるなぁと思ってしまっていて、
年齢性別を削ってでも評価されるように自分の力をあげていかないとなーというのと、
もはや褒め言葉として出てこない、「女性」をつけることがないぐらいエンジニア人口の多様性を上げていかないといけないのかなぁ、
みたいなことを考えたりもしました。
大学に入る前の職業選択を考える機会とかにもしこういう生き方もあるよ、みたいな話ができるならしてみたいなーというのを
たまにおもったりしますねぇ。

*1:読みづらさと謎のテンションが見受けられる可能性がありますが、文体だと思って頂けると幸いです

Rails Developer Meetupで「バス因子が自分でバス因子を脱するための方法」を発表した

Rails Developer Meetup 2018 2日Bトラックで、 「バス因子が自分でバス因子を脱するための方法」を発表してきました。

この規模の登壇は初めてで、すごい人が多い中だったので割と終始ビビっていましましたw

speakerdeck.com

思っていたより、会場や資料公開後のインターネット上で反響をいただいてびっくりしています。 最近良く思うのですが、自分が悩んでいたり陥ってる状態だったりは、大体多くの人が経験しているんだなぁ、という気持ちになりました。

この発表をするにあたり考えたことだったり、反響を見て考えたことだったりをゆるく書いていこうと思います。 整理するというよりかは、あーこんなことあったなーみたいなのの記憶をたどりながらという感じ。 ちなみに今、横に日本酒があるので文章読みづらかったらごめんなさいw

テーマを考えている時に同僚の@ujmさんに、 「具体的なエピソードを入れるとその人にしか発表できないものになるので、具体的なエピソードをベースに組み立ててもいいかもね」みたいな話をされて、 自分が経験したエピソードで他の人に話したいことはなんだろう?っていうのをまずは考えました。

また、去年の10月頃、会社で開発部のリーダーという役割をいただいたのですが、 リーダーはドメイン知識・運用知識に基づいて、組織を成長させる役割なので、 その時からスケールする組織にするにはどうすればいいのだろう?ということをすごく考えるようになりました。

そんな事を考えながら2ヶ月ぐらい過ごした後に書いた記事が会社のブログにあります。 in.fablic.co.jp

わりとモヤモヤしていて、なにかこう教科書になるようなものがないかな?と思っていた時に エラスティックリーダーシップという本を読みました。

その中にでてきたバス因子に対処するの章にすごく衝撃を受けました。 エラスティックリーダーシップには、なぜバス因子を減らさないといけないのか、バス因子のリスク、 そのためにマネージャーのような立場の人がどう動くべきかみたいな話が書いてあります。

「いや、私マネージャーじゃなくて当人なんだけどやべぇ(自分リスクかよ、みたいな)」

そういえばバス因子だと自覚したのはどういうときか聞かれていろんな回答をしましたが、本を読んだ時に割と明確化したのかもしれない。

属人化というキーワードがあると思うのですが、属人化って人によっていい意味(専門性という意味)で捉える場合もあれば、 割と誰でもできるのに一人の人がやっちゃってるみたいな悪い意味で捉えられている場合もある気がしていて、 属人化をへらすだと違和感があるなぁとおもっていて、 バス因子をへらすだと私は「(いきなり)いなくなったらやばい」という意味で捉えられるかなとおもっていて、そういうタイトルにしました。

ちなみにしばらくたつまで、恥ずかしながらトラックナンバーっていうキーワードの存在は知りませんでした。

なので、ちょうどリーダーと言う役割で組織をスケールするのと、バス因子を脱するためにやるべきことが一致しているなぁとおもっていたところだったのと、自分の具体的なエピソードが話せそうな旬な話題だったので、このテーマになったという感じです。

実際、発表内容を考えるのは結構難しくて、「こういう風にするべき」という理想論って沢山あるし思いつくんですけど、 それを章立てにしていくと、全然面白くない内容になっちゃってw 実は2月に一回短縮versionを恵比寿.rbで発表しているんですけど、どうもその時自分の中ではこれじゃない感がまだありました。 その後、エピソードを時系列にならべて作ってみたりもしたんですが、それも間延びして結局何がいいたいんだ?みたいになってしまって、 大分苦しんでいました。

そういう状態で、前前前日の木曜日に@ujmさんにもうだめだーとかいいながら、もうだめだ状態のものを見てもらってアドバイスをもらって。 その時には、生々しい話のほうがおもしろいけど、内輪ネタっぽくならないようにしないといけないからそのバランスが難しいね、でも日頃の積み重ねが出てくるので他の人には作れないおいしい話、みたいな話をしたりしました。

その時にでてきた雨漏りとバケツ置きの話を使いたかったけど時間の都合上お蔵入りしたのはちょっと残念w

それでなんとか立て直した状態を前前日の金曜日に会社でエンジニアの前で発表した(その時初めて30分全部喋った)んですが、そのときは、文字が小さい・文字が多い・内容がもりもり過ぎてついていくのが大変みたいな話になりました。

あとは30分だと定期的に「これについて話します」「こういうことについて話しました」を挟まないと聞き手が覚えられないよ、みたいな話を複数人からフィードバックもらいました。

それがすごく良くて、この話は自分が何を話したいんだっけ?っていうのを考えることになって頭の中が整理されました。

あと、文字をおおきくしてスライドをわけて、ココまでに収めたい文字数のワーディングにし直したりもして、 割とスッキリ見やすい形にはなったかなと思います。

土曜日にDay1に行って発表を見るときも、内容はもちろんのこと、 スライドの文字の大きさをチェックしたり、発表者の会場とのコミュニケーションを見たりといつもと違う視点で見ることが出来ました。 わりと「みんな現実てきなあるあるで共感できる」みたいな話がおおくて、安心したりしました。 Quipper における「関心の分離」の歴史に出てきた 「分断されたモノリス」というキーワードが、まさにうちのサービスはこれだ!と思って使わせていただきました...!

登壇で喋っている時は、割ともう覚えてない。。。w

登壇後、直接良かったよーといっていただいたり、twitterをみていると共感が思ったより多くてびっくりしました。 バス因子というワード自体があまりみんな使っていないっぽくて、エゴサーチしやすかったので割とだいたい目を通してみました。

バス因子は、実は空想とか願望とか思い込みなんじゃないか?みたいな話がちらちらあって、 最近、実はそうなんじゃないかなーって私もおもっています。 多分明日バスに轢かれて死んでも、サービスがいきなりなくなったりはしないと思う、それは間違いなくそう思います。 ただ、毎日ハードに使っている一台のPCがいきなりPCぶっ壊れたりしたらいろいろ不便になるような感じなのかなと。 (たとえが微妙かもしれないけど)

「いきなり」っていうのが肝かなっておもっていて、いなくなる日付がわかっていてじわじわいなくなるのとは別かなーと。 誰かが会社を退職すると、いくらその人が引き継ぎしてくれれてもちょっと違和感があるのと近いのかも知れないですね。 歯が抜けても間が詰まるかもしれないけど、大きい歯だと違和感があるというか。

あと、バス因子のひと、自分でバス因子になっていること楽しんでるでしょ?みたいなのは、 そうかもしれないなーと思っていて、好きじゃないとその状態にならないのかもしれない。

あとtwitterでみつけた、こちらのツイートに。

私ももちろん正義だと思ってやってきていて、そうやるのが自分の信念だったから本当になかなか習慣がぬけなくて、 未だに反応しないでおこうとおもうけど、すごくもやもやするし、手を出してしまったりすることもあります。

ただ、組織の成長フェーズであることを受け入れないとサービスの成長が止まってしまうことをすごく感じているので、 少々我慢しないといけない時期だなぁと思って生きています。

「客観的に見てどうするべきか」と「どうするべきかは置いといて自分がどうしたいか」っていうのがあるなぁとおもっていて、 私は自分でいうのもなんですが、超スタートアップ向きの人間なのでどうしたいかと言われたらもちろん自分の最高スピードで仕事がしたいです。

ただ、今は客観的に見てどうすべきかをする時期だとおもっています。もちろん心苦しいです。 やりたいことをするためには、期待役割を果たしてからだなぁと思っているので。 そして、やったことがないことをやってみるのも、又経験のうち出し、経験したことがないことはわからないので。

個人的には「客観的に見てどうするべきか」と「どうするべきかは置いといて自分がどうしたいか」が一致している状態だと すごくのびのびと仕事ができて良いなぁと思います。でもどうしたいかを考えるきっかけになったのですごく良かった。 この話はしだすとながくなるのと、この先書きたこともあるので一旦この辺に。

ブログにもかいていただいたみたいで、ありがとうございますm( )m blog.kyanny.me

そんなこんなで、発表を聞いていただいた皆様・資料を見ていただいた皆様ありがとうございました!

ちなみにRailsDMで質疑応答に使っていたamaで質問への回答をしています〜しばらく見ているので何かあれば。

https://railsdm.herokuapp.com/issues/25

ブログデザインを更新した

BEFORE

f:id:sinamon129:20160101232218p:plain


AFTER
f:id:sinamon129:20160101232226p:plain

主な変更点とか

  • 全体的なカラーリングの変更
    • ラベンダーから、ライトピンクに
    • 色味とか雰囲気とかは好きなファッションブランドのサイトを参考に
    • ベースカラー:#FDE3EC
    • リンク色:#FF80BD
    • あと普通の黒(#000000)と白(#FFFFFF)
  • ベースのテーマを変更
    • EpicからInnocent
    • カスタムはBlankInnocentのテーマ説明内にあったものを参考にさせてもらいました
    • 色味をベースカラーにあわせてcssで調整(背景・リンク・ボタンとか)
  • アイコンとかグラフィック周りの変更
    • イラレでぽちぽち作った
    • 本業じゃないのでノリで
    • ひさびさにカーニングしてみたけど苦手すぎるから余計なことした感ある
  • その他
    • ドラックした時に色かわるようにしてみたり
    • profileちょっとかいてみたり
    • analytics入れてみたり
    • descriptionとか書いたり
    • サイドバーちょっと調整したり

ひさびさにやったけど楽しかった٩(๑′∀ ‵๑)۶•*¨*•.¸¸♪

今年自分がかいたアドベントカレンダー記事まとめ

この記事はDark - Developers at Real Kommunity Advent Calendar 2015の23日目のエントリです。

こんにちはこんにちは、@sinamon129です。
いつもDarkのslackで光と闇の戦士たちを見ていますが、
だいたい土曜日は夕方まで寝てることが多い引きこもりので、もくもく会やイベントの出現率は低めです。
(来年はちょこちょこ顔を出したい(願望))

最近ごちうさにはまりました。まだ1期を見ていますが、チノちゃんがかわいくてしかたないです。

好きなことを書いていいらしいので、今年かいたアドベントカレンダー記事をまとめたいと思います。

12/07

Elasticsearch Advent Calendar 2015
mosowave.hatenablog.com

今年6月ぐらいに初めてElasticsearchを触って、パフォーマンスチューニングから全文検索エンジン用の辞書作成まで、色々やりました。
今年の後半はElasticsearchと一緒に歩んだと言っても過言ではなくて、書きたくて仕方なかったw
辞書作成話は、案外知見がネットにまとまってなくて、cookpadさんとハッカドールさんの記事をとっても参考にしていました。

12/10

Fablic Advent Calendar 2015
in.fablic.co.jp

会社のアドベントカレンダー。実はこの記事、夏にかいたまま眠っていた記事を修正したものw
デザイナーの後輩に、画像を色々修正してもらい、結構もりもりな締め会コンテンツの記事。
締め会のコンテンツ作り、毎回楽しんでもらえる物を作るのは難しいけども、ここでもプログラムを書いたりして楽しかったりするw

12/13

Geek Women Advent Calendar 2015
mosowave.hatenablog.com

GeekなWomenのアドベントカレンダー。Women系ネタがなかったので、ブログネタにしました。
他の人の記事、女性エンジニアという観点がどこかに入れられて書かれた記事も多くて、結構共感度が高くて面白い。
女子部系の活動も結構活発になってきてて、女性のエンジニアが居ないってそんなことないんじゃない?ってぐらい。

12/21

Fablic Advent Calendar 2015
in.fablic.co.jp

7日の記事のもうちょっと広い範囲版。
この仕事自体は結構がっつり取り組んだので、ぜひ記事にしたかった話。
まだまだやることいっぱいあるので、ぜひ私と一緒に検索まわりを....(ry



そんな感じで全4本(これを含めると5本)書きました。
結構書いたなぁ(当人比)
この調子で来年もブログかいていきたい(真顔)

明日は@moschanです!

ブログを比較的継続して書けるようになった話

この記事はGeek Women Advent Calendar 2015の13日目のエントリです。

こんにちは、しなもん@sinamon129です。

せっかくのGeekなWomenのカレンダーということで、
おそらくそれに入るであろうIT企業に勤めるエンジニアである私がどういう生き物であるかをまず書いておきます。

webとファッションが好きな社会人2年目エンジニアです。
悲しいことに初対面の人は大体エンジニアと思ってくれませんw(そんな世界を変えたい)
ファッションフリマアプリFRILを運営しているFablicでエンジニアをしています(2015年4月~)

いわゆるサービス思考のエンジニアで、技術をつかってよいサービスを作ることを生きがいに生きています。
ここでいう[よい]は、「ユーザーにとってよい」と「中の人にとってよい」の両方。
もちろんコードを書くのも大好きです。綺麗なコードが書けた時にはガッツポーズをしますw

さて自己紹介はさておき、
実は私、ブログを書くのがとっても苦手で...
でもいつも、Google先生にお世話になってたくさんの方のブログにお世話になっています。
お世話になってるからこそ、自分が引っかかってわかったことをブログに書いて誰かのために残したい。

でもブログがかけない...のループ。

ですが今年12本のブログを書きました。
苦手解消につながったかなとおもうことを書きます〜。

リレーブログを始めた

前職の同期と一緒にリレーブログを始めました。
4人で毎週代わる代わる記事を書いているので、大体1ヶ月に1回回ってきます。
書けないと1000円の罰金制度がある(後日の肉代として貯蓄される)ので、いい緊張感(ただ肉がたべたい)をもって書けます。
(ちなみに年の前半は書けなさすぎて罰金が溜まって肉寿司を食べに行った...w)
記事を書かないといけないとおもうと、意識してネタを考えたり、メモっておいたりするのでとてもよいです。

会社でまとめ記事やポエムをたくさん書くようにした

弊社ではQiita::teamをつかっていて、職種問わずいろんな人が投稿しています。
自分が調べたけど他の人に役立ちそう、自由研究でこういうことやってみたなどを投稿すると、いいねがついたりします。
結構これが励みで、よくいいねがついている人や、読みやすい文章を書いている人の投稿を参考に、書き方をかえてみたりして、
遠慮なく投稿するようにしました。
投稿から、いろんな新しい動きに結びついたものもあって、文章を書くこと以外にも利点がたくさんありました。
4月から70投稿してました。結構かいたなー。

      • -

文章を書く習慣がつくと、何か書かないといけない時にスムーズにかけてとってもいいなと思いました。
昨日かいたエントリ
FRILの商品検索をnGramから形態素解析にした話 - mosowaveを結構たくさんの方に読んでいただけたみたいで、
この習慣を継続的にして、もっといろんなブログから受けた恩恵を返していけたらな〜と思いました。

FRILの商品検索をnGramから形態素解析にした話

この記事はElasticsearch Advent Calendar 2015の7日目のエントリです。

こんにちは、ファッションフリマアプリFRILを運営しているFablicでエンジニアをしている@sinamon129です。

FRILの商品検索はElasticsearchを使っていて、最近nGramベースだったものを形態素解析ベースに変更しました。
その経緯やどういう手順で行ったかを書こうと思います。
主にユーザー辞書とsynonym辞書の構築の話がメインです。

どうしてnGramベースから形態素解析ベースに変更することになったか

関係ないものがなるべくひっかからないようにしたい

nGramだとファーで検索したときに、ローファーやローリーズファームが引っかかり、本当に検索したかったものが出てこないという問題がありました。
(実際は出ているのだけども、埋もれてしまっている状態)

同じ意味の単語の検索結果はなるべく同じにしたい

バッグ・バックやカシミア・カシミヤなど、表記が揺れる語があり、それらの検索結果を同じにしたいけどnGramだと上手くできないという問題がありました。

どういう手順を踏んだか

最初は、単語ごとに適合率と再現率を出すために、既存の商品データから正解データを作り、その適合率と再現率から改善を行おうとしていました。

しかし、正解データを作る作業はほぼ人力で行うしかないのでコストが高く、また作業者の主観が入るという問題があったのと、nGramの結果を前提として引っかかって欲しくないものが引っかからないようにする方が効率が良いことに気づき、nGramでの検索hit数をみながら辞書の構築を行うことにしました。

analyzer設定

index用のanalyzerとsearch用のanalyzerを用意して、index用のanalyzerのみにsynonymの設定を追加しました。
またchar_filterにicu_nomalizerを追加したことで、文字の正規化をやってくれるようになったので、とても辞書追加が楽になりました。
(半角カタカナや全角英数字や大文字を辞書に登録する必要がなくなったので)

index_analyzer

  • kuromoji_tokenizer
  • search mode
  • char_filter
    • icu_normalizer
  • filter
    • cjk_width
    • pos_filter
    • kuromoji_baseform

search_analyzer

index_analzerにsynoymを追加

ユーザー辞書とsynonym辞書の構築

FRILの商品情報や検索ワードには、ファッションブランドや洋服に関する単語、モデルの名前などデフォルトのkuromoji辞書には載ってないような単語が多く、デフォルトの辞書では引っかからないものが増えてしまいます。

検索ログからの辞書追加

実際に検索されたワードのログを貯蓄しているので、まずはそこから辞書データを作っていきます。
ですが、生の検索ワードログには以下の問題点があります。

  • フリガナがない
  • 間違っているワードが入っている
    • ミスタイプ・勘違い等

そのため、そのまま辞書データにするのは良くないと判断し、mecabと[mecab-ipadic-neologd](https://github.com/neologd/mecab-ipadic-neologd)を用いて、形態素解析した結果、フリガナが存在する名詞のデータだけを辞書に登録しました。

本番データでindexを構築して漏れを見つける

mecabで分解できた範囲では足りない&不安なので、本番で動いているクラスタ形態素解析版のindexを載せて、チェックしていきます。

nGramモードのキーワードのhit数と、形態素解析モードのhit数とで、あまりにもかけ離れていているものをベースにチェックしてきます。
(この時、影響範囲が大きいものから潰したかったので、検索数の多いものから順にチェックしていきました)

hit数が減ってる場合は以下のような場合があります。

  1. そもそも引っかかってはダメだったものがたくさんひっかかっていた場合
  2. ワンピ(ワンピースの省略形)など、nGramから形態素解析になったことによってひっかかる数が減ってしまった場合
  3. 形態素解析で分解されたが、その分解され方がおかしい場合

1の場合はそのままで大丈夫ですが、その他の場合は、実際にワードを検索したり、inquisitorプラグインで単語を分解しながら、適宜ユーザー辞書やsynonym辞書に単語を追加していきました。

社内テストで抜け漏れを見つける

上位数千ワードぐらいが大体大丈夫だろうというところで、社内ユーザーが検索する時は先ほどつくったindexを参照するようにapiの実装を変更しました。
実際に使ってもらって、ひっかからなくなった単語や、この単語で検索した時とこの単語で検索した時は同じ結果になってほしいなどの要望をもらい、ひたすら辞書を更新していきました。

FRILでは、Ruby on Railsからsearchkichというgemを使っているので、商品検索indexは基本的に商品データの更新時にリアルタイム更新されているのですが、テスト用に作ったindexは手動更新だったため、社内ユーザーがほぼいつも通り使えるように15分に一回更新するようなバッチを書いて対応しました。

本番適応後

本番適応してからは、検索結果からの商品遷移率を見ながら辞書を修正してきました。
関係ないものが引っかかると検索結果から商品への遷移率が落ちる傾向にあるので、nGramの時の遷移率よりも下がっているものを探しながら修正を行いました。
またhit数が0になっているワード等を確認し、必要に応じて辞書の修正を行いました。

副産物

検索レポート

GoogleBigQueryに溜まっている検索ログを形態素解析モードの変更した時の影響等を観測したいので、毎日集計するようにしました。

f:id:sinamon129:20151206221603p:plain
検索ワードごとのdauや検索回数、検索結果からの商品ページへの遷移率を観測できる画面や、デイリーランキングをslackに通知したり等、社内で今何が検索されてるかを確認できる状態になりました。
f:id:sinamon129:20151206215623p:plain:w300

辞書登録システム

ユーザー辞書ファイル・synonym辞書ファイルはメンテナンスしていかないといけないものなので、自分以外も更新できるように辞書登録システムを作りました。カナが同じワードをだしたり、部分一致したワードを出すことで、類義語設定がとてもスピーディーにできるようになりました。

f:id:sinamon129:20151206213857p:plain

特に苦労したこと

データが綺麗じゃない

商品名や商品情報をユーザーさんは自由に書くので、顔文字や絵文字はもちろん、商品に関係ないことがたくさん書かれます(`・д´・ ;)

辞書追加作業が大変だった

ファッションブランドや流行りのファッションワードは、どこかにまとまっていることが少ないことが多く、ニコニコ大百科wikipediaからデータを作る、みたいなことがしづらくて苦労しました。。。

また、FRILユーザーでそこそこ洋服が好きな自分がみても、ぱっと見何かわからないワードも多く(知らないブランド・アーティスト等)これはどの表記が正しいのかなどを必死にググりました。

まとめ

nGramモードから形態素解析モードに変更するために辞書を必死に作った話でした。
日本語全文検索のための辞書構築の話はなかなか知見として公開されなくて、自分としてもどうやってやっていくか手探り状態だったので、参考になれば幸いです。