「勉強会に行ってみた!」第24回「【ヒカ☆ラボ】月間ユーザ数400万人のメディアを支える裏側とは!!」
event

「勉強会に行ってみた!」
第24回「【ヒカ☆ラボ】月間ユーザ数400万人のメディアを支える裏側とは!!」

2016.05.02

今回は、ポート株式会社のCTOと研究開発者の2名がそれぞれ、マネジメントと研究開発という性格の異なる話を教えてくれる勉強会です。技術者のマネジメントも難しいですし、研究開発をどう進めるべきかも難しい。各社試行錯誤しているなかで、実例として具体的な話が聞けるのは貴重な機会だと思います。

(三土たつお)

会場は渋谷ヒカリエのレバレジーズ社でした。

こんなところです。最近のIT系の会社がこんなふうにオシャレなのはもうすっかり慣れてしまいましたね。

■ベンチャー企業のエンジニアマネジメント(ポート株式会社CTO 浦田祐輝氏)

まずお話してくれるのは、ポート株式会社のCTOである浦田さんです。

ポート株式会社の浦田さん

まずはエンジニアの育成の話からです。

浦田さんの会社では Ruby on Rails で開発をしています。そして新しく入ったRailsの未経験の人には、とりあえずOJTでRailsを書いてもらっていたそうです。

しばらくすると、なんとなく書けるようにはなります。
でもいわゆる Rails Way で書けているかみたいなことは分かりません。

Rails が書ける人は増えたものの、それでは育成フローが回っているとは言えないと感じたそうです。

そこで、まずは Rails チュートリアルをしっかりやってもらって、Rails Way のようなものを身につけてもらうことにしました。さらにそれをプロジェクトで実践しつつ、周りからレビューしてもらいます。

これをやったところ、意外と成長のPDCAが回り始めたなと思いました。

予習、実践、復習。言われてみればそのとおりと思うのですが、実際には日々の開発に追われてできないことが多いですよね。実践ばかりずーっとやってる感じ。

PDCAっていう言葉はあまりに言われ過ぎているので、最近ではちょっと揶揄されたりもしますが、じゃあ自分は出来てるかっていうとできてない。やっぱり大事ですよね。

次は制度の作成についてです。

制度をつくるときは、現場の課題や要望に応じてボトムアップで作るほうがいいです。

たとえば検証端末がないという課題に対しては、「検証端末購入補助制度」を作りました。また、プロジェクトの改善をしたいという要望に対しては、改善活動などができるよう水曜日の午後を空ける、「研究制度」というものを作りました。

頭ごなしに、制度作ったから使えって言っても、結局使われないんですよね。

これはなるほどと思いました。トップダウンで制度を作っても、結局意図を理解されず使われないのでは意味がないですよね。また、そうやって作った制度が実際に使われているかどうかを定期的にチェックする、といったこともしているそうです。

■ポート株式会社の研究開発(ポート株式会社 斎藤卓真氏) 浦田祐輝氏)

ポート株式会社の斎藤さん

次は、同じくポート株式会社の斎藤さんによる研究開発の話です。

自社製品の開発に直接関わるのではなく、その土台や基盤を作る研究開発の部署は、ベンチャー企業でも持っているところはあると思います。具体的にはどんなことをしているのでしょうか。

研究開発のミッションは、何かの問題を解決して社会に還元することです。
でも場当たり的に力任せでやるんじゃなく、できるだけ数学的に定式化して、汎用的な解決を目指します。

研究開発といっても、ふだんは普通にプログラミングをしているんだそうです。でもその進め方が普通とはちょっと違うとのこと。どんなふうに違うんでしょうか。

具体例はこんなふうです。日本中の会社の採用ページを収集して、採用条件などをもとに検索できるようなサイトを作ろうとしたときのこと。

採用ページは、特定のサービスによって同じHTMLテンプレートから作られているものが多くあるそうです。そこで、集めてきたHTMLが同じテンプレートから作られているかどうかを調べたい。どう調べるか。

正規表現とかで個別に調べようと思えば、頑張ればたぶん出来ちゃうんです。
でもそういう力技はやりたくないんですよね。

なるべく汎用的に解きたい。そこで、HTMLの木構造が似ているかどうかを調べることにしました。

同じテンプレートなんですから、中身の文字は違っても構造はほとんど同じはずです。
そこでテキストを比較する diff とおなじように、木構造を比較してその近さを計ればいいと思いました。

これは頭いいですよね。確かにそのとおりです。しかも、個別に正規表現を書くのとは違って、汎用的にいろんな場合に対応できます。

二つのテキストの近さを測るのには、編集距離(Edit Distance)という有名な考え方があります。一方のテキストを一文字ずつ追加、変更、削除して他方に一致させたとき、その回数が少ないほど近いというものです。ゲノム解析とかでも使われていますよね。

じゃあ木構造についても同じように編集距離が定義できるんじゃないか。ということで調べたところ、「Tree Edit Distance(木の編集距離)」という考え方が既にあったんだそうです。

Tree Edit Distance を測るプログラムをpythonで実装したところ、うまく動きました。
今はさらなる高速化を目指しています。

かっこいいですねー。ふだんの開発仕事もできればこんなふうにやりたいものです。

こんどは、そうやって集めてきた採用ページのテキストから、会社名や給料などの情報を抜き出したい。ただ、構造化されてない自由な文章ですから、抜き出すのは簡単じゃありません。

人が目で見て力技で抜き出すこともできるかも知れませんが、できれば汎用的に解きたい。

力技でやるのは非効率ですし、応用が効きません。できれば効率的に汎用的に解きたい。そのために必要なのは、問題を数学的に定式化するということです。

会社名みたいな情報を抜き出すということは、文章の構造を抽出するということです。
それは、文章のなかに隠れた”会社名”や”人名”といったラベルを推定するという問題に定式化できます。

上のスライドにあるとおり、「ポート株式会社の斎藤と申します」という文章に対して「{会社名}(ポート株式会社)の{人名}(斎藤)と申します」のようにラベルを振ることができれば、会社名を抜き出せたのと同じです。

こうやって定式化することができれば、数学な考え方やツールを適用することができるようになります。

ラベルを推定する問題は系列ラベリングといって、いくつか解き方があります。
今回は隠れマルコフモデルを使うことにしました。
形態素解析ツールのmecabが品詞を特定するときにも使っている方法です。

ここ、すごくないですか。単に力技でやるのがかっこ悪いから数学的に解いてるわけじゃありません。そのほうが数学的に蓄積されたツールも援用できるし、汎用的に解けるからなんですね。

実装の方法としては、再急勾配法ではなく準ニュートン法でL2正則化項つき、特徴量としては word2vec で200次元のベクトルを使いました。

このあたりは「日本語でOK」という感想でしたが、とにかく C++ で実装したところ正解率は80%を達成したそうです。すごいですね。

勉強会の後の懇親会でも、斎藤さんは具体的な技術論について質問攻めにあっていました。やっぱり技術者は技術が好きなんだなと思いました。

■まとめ

浦田さんのお話からは、育成のPDCAをちゃんと回すっていうことが確かに大切だなーと思いました。ひたすらDoだけやっているのでは成長がありません。斎藤さんのお話からは、ふだん場当たり的な解決ばっかりやっているのをちょっと反省しなきゃなと思いました。あともう一つ、「ツールを使うにしても、その理論的な背景をしっかり理解しておく」ということも言っていて、これも聞いていて耳が痛かったです。

なお、勉強会のタイトルは「月間ユーザ数400万人」となっていますが、4月末時点では900万人まで増えたそうです。すごいペースですね。

今回行った勉強会:「【ヒカ☆ラボ】月間ユーザ数400万人のメディアを支える裏側とは!!ポート式”エンジニアのマネジメント方法”と、技術の裏側を支える”レコメンドエンジン”、自然言語処理や統計モデルを用いた”採用エンジン”についてお話いたします!」
http://www.zusaar.com/event/12337005

三土たつお。1976年生まれ。プログラマー、ライター。プログラマーとしてはふだんPHPを書いてます。
ライターとしてはニフティのデイリーポータルZとかで書いてます。
http://mitsuchi.net/

この記事はどうでしたか?

おすすめの記事

キャリアを考える

BACK TO TOP ∧

FOLLOW