「ドメイン駆動設計 モデリング/実装ガイド」を読んだ

技術書展が中止になり、オンラインで開催された技術書応援展で購入して積んでいた「ドメイン駆動設計 モデリング/実装ガイド」を読了した。

booth.pm

読む前に期待していたこと

元々数年前に、DDDを導入したプロジェクトに参画していたことがあり、その際にエリック・エヴァンスのドメイン駆動設計を初めて読んだ。 当時は経験も浅かったし、DDDやらScalaやらAWSやらAngularやらと、これまで触れてこなかった技術のオンパレードで、大混乱している中で、初めてエリック・エヴァンスのドメイン駆動設計と触れ合った。

洋書技術書特有の、謎の筆者のエピソードが挟まれながら解説される謎の書きっぷりにより、全く理解できず頭がパンクしたことは今となっては懐かしい思い出になっている。 当時は一緒に働いていたメンバーに超強い人がいたこともあり、常に焦りと不安がある中で、全く理解が進まなかったので、DDDについては若干のアレルギーだけが残る結果となっていた。

それから数年が経ち、いくつかの経験を積む中で、当時の超強い人が言っていたことがなんとなく体験を持って理解できるようになり、DDD再入門してみようと思うようになっていたところで、ちょうどこの本に出会った。

紹介ページに書かれている「迷子になる」とか「非常に重厚かつ難解」といった記載を見て、

それな!!!

と感じた僕は、当時の僕の悩みを理解しているこの書籍であればDDDに再入門できるのではないか?ということで、購入して、積んでいた。

読んだ感想

なにこれすげぇ分かりやすい。というのが率直な感想だった。

実際に入るプロジェクトでこれをすぐさま応用できるか?はわからないが、少なくとも理解できたと感じることができたのはとても大きな収穫だった。 だってドメイン駆動設計本は理解がまずできなかったのだから。

ページ数も多すぎず、6ポモドーロサイクル(つまり3時間)で読了することができた。

目的ありきで方法論を丁寧に解説してくれるので、まさに迷子にならない設計だった。

次にやること

ただ、一度読んだきりで実践できるとは到底思えないので、継続学習が必要だと思う。 ちょうどよく筆者の人がオンラインで勉強会を開いているようで、しかも動画で後から見れるようなので、ありがたく拝見することにしよう。

ddd-community-jp.connpass.com

ここで得られた知識を持って、ドメイン駆動設計本にもいつかチャレンジしてみよう。

社外で初めてモブプロやってみたら辛かったのですごく学びになった話

モブプロやったことないので、流行りに乗って体験しようとしたら、想像以上に辛かったというお話です。

TL;DR;

目の前のプログラムで解くべき問題に全く集中できなかった辛い。

モブプロとブレストは似て非なるもの。マインドを変えないとできないかも。

よい学びだった。

前提

自分はモブプロ初参加。 チームに参加する人たちとはほぼ初対面。

なんかフワフワ機能を作ってたけど、出来上がったコードくそだったよ辛いなんでや

まずはサクッとFizzBuzzでもやりますかーと始めました。

モブプロ未経験者が多かったので、と、とりあえず始めましょっかーってことでプログラムを書き始めたわけです。

進めるときにずっとおもってました。

なんかこう、普段の何倍もの時間をかけて進み、かつクソコードになっていく。。。って。。。

なんでや。

辛かったこと

口頭で伝えるのむずい

コード書けたら早いんですけどね。 うまく説明できませんでした。

事前に設計するなりして認識が揃っていると違うのかも。

今回は事前設計なんてなかったので、説明が難しかった。

人間系の問題に配慮するあまり、プログラミングで解くべき問題に集中できない感覚

初対面な人たちの集まりなわけで、お互いのことは全く知りません。 その中でチーム作業をするので、結構お互いに気を使って進んでいきました。

せっかく参加しているわけですし、どうしたらみんながやりやすいかな?というのが気になってしまって、コーディングに全然集中できなかった感覚が残りました。

これって生産性あがってるのか?

TDDで難しいことが、より大きな問題として影響してきた気がする

うちのチームはTDDで進めました。

TDDってテストのstepをどう刻むかって結構難しいというか感覚が大事な気がします。

TDDでのstepは、自分の感覚で、自分が自信をもって進められる幅で進めていこうということだったはずなので。

モブに当てはめると、モブが自信をもって進められる幅ってことなんだろうけど、他の人たちの力量もわからなかったので、なんか数倍難しい気がします。

その結果、細かくしすぎて必要以上にテスト書くような形になった気がしたし、時間が無駄にかかった感覚を受けました。

なんかちがうなーこれ。。と。

あと、リファクタへの意識が低かったので、ひたすらアドホックに機能を継ぎ足してコード書くような状況になってしまったのもよくなかったです。

TDDはテスト先に書いたらTDDなわけじゃなくて、Red=>Green=>Refactorといサイクルを回すものなのですが、そこが意識できなかった。

テスト通ったらみんなで逐一拍手してたんですが、テストじゃなくてRefactorが終わったら拍手するサイクルのほうがいいのかも。

拍手したらリズム止まって、じゃあ次何テストしようかってなるので。

いやいやなんか設計おかしいぞこれ。。。と思っている人も結構いたと思うけど。。。

メンバーの一人が、そもそも設計これ見直しましょうよって流れぶったぎって言ってくれるまで、変な方向にひたすら進んでいた気がします。

なんか設計変だなー変な方向に行っちゃってるなーという感じがあったのですが、強く言い出せず。

会話のなかで方針転換するにはどんな発言をすればいいんだろう。。ということをずっと考えていたので、疲れました。

考えたこと

解くべき問題によってはモブプロはそもそも合わない説

2セッション目はちょっと挑戦であまりみんなが触ったことのない言語を選択しました。

するとコンパイルがそもそも通らないよーどうやったら通るんだーという状態に。

コンパイルを通すための方法って一意に決まるわけで、そのタイプの問題を解くためにはモブプロはあまり合わないのでは?と感じました。

というのも、各々が平行して調べて、各々の環境で試して、うまくいったらその人の方法を採用すれば事足りるわけです。答えは1つなので。

これに対してモブで進めていくことに利点があるとは思えませんでした。

使ったことないライブラリーの理解とか、そんなのもモブでやるよりは各々で試すほうが良いのではないかな?どうなんだろう。

逆に、実現方法はいくらでもあって、その中からどれを選択するか?といった課題であれば向いているのかもしれません。

1セッション目にチャレンジしたFizzBuzzもそういう意味ではみんな頭の中に大体実装あるでしょうし、向いていなかったのかも。

ブレストとモブプロは似てるけど正反対のものなんじゃないか説

ブレストは意見が出やすいように、人の意見を否定するの禁止というグランドルールで行われることが多いですよね。

僕はブレストいっぱいやってきているので、そっちで育ってきたわけです。

モブプロはそれでいいのだろうか?という疑問が。

意見をぶつけ合うなかで良いものにしていくのが必要なのかもと感じました。

ブレストみたいに、その意見もいいねーいいねーだとうまくいかないです。 コードがカオスになる。

そもそもブレストでは、発言しにくくならないようにという配慮で、意見の否定は禁止していたりします。

ですが、モブプロでは意見の対立を認めないといけないのかも。 そのうえで、対立があっても発言し続けないと、モブの人はバリューが出せません。

このためには、あくまでコードの否定であり人格否定ではないんだようという、1段階成熟したメンタルモデルが各々に必要になると思いました。

全員初対面でこれをやるのはちょっとつらいわ。。。

というか、普段会社のメンバーでじゃあそれできるの?と言われると、すぐには自信ないです。。

リーダー的な役割必要なのかも?

意思決定が難しかったので、リーダー的な役割はあってもいいのかもと思いました。

なんかお互いに遠慮しあってしまう雰囲気があり、なかなか物事決まらなかったんですよねーなんか。

どうします?うーーん。。。どう思います?的なやりとりが結構多くなってしまった印象でした。

エディタとインタフェース

各自の端末でできるようにしたほうが絶対良い。これは間違いない。

今後の展望

テーマをもうちょっと考えて、普段一緒に働いているメンバーでモブやってみたいなと思いました。

あと、できたらモブが成功しているチームに見学とか行きたい。 現状では上手くいくイメージがなかなかできていない。

おわり。

2019アーバンデータチャレンジ京都 in NDL関西に参加した話

地域課題解決を目的としたオープンデータの利活用を目的として、自治体が企画するコンテストであるアーバンデータチャレンジ2019への応募を目指したイベントである、アーバンデータチャレンジ京都に参加してきた。

2019/11/9に1日かかりでアイディアソンを実施し、2019/12/7にハッカソンが実施されるスケジュール。 アイディアソン終了後のハッカソン開催日までの1カ月間は好きに開発すすめてくださいねーという感じのイベントだった。

ハッカソンでは各チームが色々と事前準備をしてきていたので、最終的なアウトプットはどのチームもすごかった。

アイディアソンの様子。 2019アーバンデータチャレンジ京都 in 関西館 | NDLラボ

うちのチームのピッチ。 https://lab.ndl.go.jp/dataset/UDC2019/ideathon1_MyPlace.pdf

うちのチームはWebアプリを作った。 リポジトリはこちら。 https://github.com/masamasah/my_place

参加した経緯

今期の個人的な目標として、なんしかモノとしてアウトプットするところまでもっていきたいというものがあり、取り組むテーマを探していたところ、たまたま見つけた。 でもなんか一人で参加するのいややなーと思っていたので誰か誘ってみようと思った。

普段から仲の良い同僚から勉強したいけど何作ったらいいかわからず手が止まってしまうという相談を受けていたこともあり、ちょうどいいかもということで誘って3人で参加した。

アイディアソン

まずは自治体が提供しているオープンデータの説明があった。 いろんな種類があって正直すべてを覚えてはいないけど、国会図書館ということもあってかなり興味深いデータがあることがわかった。

これらのデータを活用してどんな地域課題が解決できるか?をブレストしてアイディアだしし、出てきたアイディアをクラスタリングして、各クラスタに興味のある人たちがあつまってチームを形成した。

チームに分かれてからはチームごとにアイディアをブラッシュアップして、ハッカソンで作るべきものの青写真を作った。

ハッカソンまでの過ごし方

もともと開発の勉強がしたいというモチベーションで集まった3人なので、ハッカソン当日までに集まって開発をすすめた。

普段の業務では一人チームで開発しているので、チーム開発ができたことが個人的には凄く楽しかった。

全体的な足回り(インフラ系とか開発環境とか)の整備とPythonでのWebAPI提供を主担当し、Angularでの画面開発なんかも行った。

チーム3人で開発の勉強がしたいということで合意できていたので、成果物を追い求めるというよりは、技術的な解説や不明点の深堀など、知識習得に重きを置いて進めることができた。

ハッカソン当日

学び

ペアプロするうえでは大きいモニタが必須。13インチのMacbook airでは限界がある。

説明することで学びが深まるので、良い機会だった。 普段の業務でもチーム開発がしたくなった。

今回は開発を学びたいという目的でチームが合意できていたが、ペアプロを進めるうえでは方向性を合意しておくことは大事かもしれない。 細かいことは置いといて開発進めようぜ!ってならなくて良かった。 ここの認識があっていないとチームがギスギスしたりするのかな?と思った。

課題

学びが目的であったが、それでも最後のほうはモノとして整えるために急ぐことになった。 もうすこし余裕をもって進められたよかったなぁと反省。 これによって最後のほうは全員が全員理解して進める構造にならないケースがあった気がする。

他のチームのアイディアや実装はかなりユニークなものもあり、もっともっと発想を飛ばせるといいなぁと思った。

最近個人プロジェクトの進捗があまり出せていない。 モチベーションが若干下がってしまっている気がする。

ので、目標達成とかそういう系統の本をまとめて3冊ほど読んでみた。

テーマを固めて一気読みするのはかなり良いかもしれない。

読んだのはこちら。

やり抜く人の9つの習慣 コロンビア大学の成功の科学

やり抜く人の9つの習慣 コロンビア大学の成功の科学

時間術大全 人生が本当に変わる「87の時間ワザ」

時間術大全 人生が本当に変わる「87の時間ワザ」

UCLA医学部教授が教える科学的に証明された究極の「なし遂げる力」

UCLA医学部教授が教える科学的に証明された究極の「なし遂げる力」

3冊の関係性

【成し遂げる力】では、行動を3つに分類している。 無意識に実施しているような行動を「自動行動」、衝動的にやってしまうような行動を「衝動行動」、その他を「一般行動」が3つ。 【9つの習慣】は衝動行動と一般行動を対象としたイメージで、【成し遂げる力】は3つそれぞれを対象としている。

【時間術大全】は他の二冊と比べると日々の実務よりで、tips集に近い。

3冊はそれぞれ根本にあるのは似たような考え方に感じる。 【成し遂げる力】より【9つの習慣】の方が圧倒的に読みやすくはあるので、【9つの習慣】を読んで実践しつつ、日々の行動のサポートとして【時間術大全】を使うようなイメージが良いと思う。

成し遂げる力と9つの習慣

【成し遂げる力】の方がより広い領域を扱っている印象を持った。 実例が豊富なので、実例を得たいならおすすめ。個人的にはちょっと実例が多すぎた。

どちらも目標を具体的にすることの大切さを説いている。 曖昧な目標ではなく具体的にすることが大事。 【9つの習慣】ではあまり理由づけがなかったが、【成し遂げる力】を読むとリンクする部分が多く納得感が得られるかもしれない。 目標を具体的にしておくことで、実現可能な「十分に小さい」タスクに切り分けることができる。

トップダウンでタスクを小さくしておくことでロードマップが引かれるので、実施に際して簡単な状態(実施時に複雑なことを考えなくてもタスクを倒せばいい)にできるのが大きな効果。 これによって成し遂げられる確率が高まる。

具体的な目標に落としていく際に注意が必要なのが「人はどんなサイズの目標に対しても3〜10個のtodoしか思いつけない」ということ。 目標を具体化する際には【成し遂げる力】の梯子モデルを取り入れてタスク化していくことが大事だと思った。

【9つの習慣】ではif-thenプランニングが紹介されているが、これも【成し遂げる力】で「簡単な状態を保つことが成し遂げるために役立つ」という点とリンクするだろう。 ルーチン化された行動は継続が簡単になるし、if-thenの形で行動をあらかじめ決めておいて自動で実行できるような仕組みが目標達成には好ましいんだと思う。

意志力を使った方法はどちらの本でも否定されている。 意志力を使わなくても実現できるようにしておくことが継続のためには重要。

達成するためにはその対象を「魅力的」に感じていることも大切。 重要なことであり価値があることだと信じることができると良い。 この具体的な方法は【9つの習慣】にはないので【成し遂げる力】を参考にすると良いのかもしれない。

脳の可塑性周りの話はどちらでも出てきた。 固定化された知性ではなく、知性は大人になってからも変わるというマインドセットをもって、成長することを大事なことと捉えるのが大切な習慣なのかも。

時間術大全

ここまでで作ったタスクをその日の「ハイライト」として日々倒していく。 なんの戦略もなく日々を過ごすと、せっかく作ったタスクを進める時間が取れない。 これを防ぐために【時間術大全】を参考に、時間を作る。

意志力に頼って集中しようとするのは難しい。物事は簡単な方が良い。 なので気を散らすものはそもそも消してしまおうといったことで、「レーザー」の章が参考になる。

体調が悪い中で意志力に頼って集中しようとしても難しい。 なので集中できる体調を保つために「チャージ」の章も参考になる。 ここで言われていることは【最高の体調】という本で言われていることとも繋がっている。 人の進化の過程に生活を合わせ直そうというような趣旨。 ここに興味があれば【最高の体調】を読むことをお勧めします。

最後の「チューニング」の章は自身へのフィードバックについてのお話。 時間術としていろんな取り組みを実験して、その結果を振り返って次の実験内容を考えるようなものになっている。

このフィードバックのタイミングで【9つの習慣】で述べられていた「目標との距離をフィードバックする」を取り入れても良いのかもしれない。

ある程度テーマを固めた上で何冊か読んでみる取り組みは結構色々考えるきっかけにもなるし良いかもしれないなぁ。

おわり。

自分の小さな箱から脱出する方法の読書メモ

自分の小さな箱から脱出する方法を読んだ。

自分の小さな「箱」から脱出する方法

自分の小さな「箱」から脱出する方法

  • 作者: アービンジャーインスティチュート,金森重樹,冨永星
  • 出版社/メーカー: 大和書房
  • 発売日: 2006/10/19
  • メディア: 単行本(ソフトカバー)
  • 購入: 156人 クリック: 3,495回
  • この商品を含むブログ (418件) を見る

ビジネス書図鑑で紹介されていた書籍で、特に他人を責めがちな考え方に毒されている自分がいるなぁと思っていた問題意識に刺さりそうだな?と感じたので読んでみた。

いい意味で自己啓発的な本だった。 この本を読むという体験を通して「他責思考」から抜け出すためのヒントが得られるし、(詳細は後述するが)抜け出すためのきっかけの一つになる。

一言で?

「こうしたほうが相手のためになる」という自分の考えを裏切ったことで、それを正当化する思考が働き、世界を見る目が曇る。この状態を「箱に入った状態」と呼ぶ。相手も自分もこの状態になっていると、それぞれが自己正当化の目線で相手を見るので、人間関係がドツボにハマる。これがチーム単位になり、会社単位になってくると、チームや会社の目標達成の大きな阻害要因になる。 箱から出るには、箱から出られている状態の時に、自己反省をして、相手を自分と同じく尊重すべき存在であると認識し直す。箱から出た状態を維持するためには、相手のためにするべきだと思ったことは素直に実践し、自分の考えを裏切らないように留意する。

詳細

箱に入るメカニズム

「相手のために〇〇してあげなくちゃ」と思った際に、それを裏切ると、それをしなかったことへの正当化が自分の中で起きる。

相手の欠点を考え始めて、「だから別に〇〇してあげる必要なんてないんだ!」と考えるようになる。 さらに、相手の欠点を深掘りし、「むしろこっちが被害者だわ。。」と考えるようになる。 さらにさらに、自分の良いところを過剰に評価して、自分を正当化しまくる。

このとき作成された箱は別の状況下でも持ち出されるようになる。

箱が強化されるメカニズム

相手が箱に入って自己防衛してくると、こちらも自己防衛のために箱に入るようになる。

箱の中は自分が正当化される心地よい空間である。

相手が自己防衛のための攻撃をしてくると、それを受けてさらに自己正当化がおこなわれ、心地よい箱の中がより心地よい空間として強固なものになる。一種の共犯関係みたいなもの。

つまり箱は原理的に強化されやすいっぽい。

箱から出るためには?外に居続けるには?

箱に入ってる状態ではぶっちゃけ何しても基本ダメ。 どんな人でも常に箱に入っている状態ではないので、箱から出ている状況の時に、自身を見つめ直し、自己反省することが大事。それによって相手を「自分と同様に尊重されるべき個なんだ」と思えるようになると箱から出られる。

箱から出たら外に居続けるためには相手のためにするべきかなーと思った自分の考えを裏切らないことが大切。

感想

「箱」について物語形式で進んでいく。通常の知識本とは異なり、整理されて書かれているというよりは、登場人物の学びを通して理解していくようなスタイルであり、本書の内容的にはそれがしっくりくると感じた。 また、箱から出るための方法として「箱から出た状態にある時に自己反省をする」というものがあげられているが、本書を通じてこの体験ができるように物語形式にしていると感じた。

普段の人間関係の中で、しがらみがある中で、箱から出た状態を意識的に作り、その際に自己反省をするというのは至難の技であると感じる。

まず箱から出た状態の人間関係にいる際に、そうではない相手のことを考えたりすることはあまりないし、考えたとしても自己反省をするという発想にまずならない。 箱から出た状態の人間関係にいる際に、その相手から、そうではない相手のことを考えて自己反省するように促されれば別だが、あいにくそんなことをしてくれる知り合いもいないし、正しく理解させてくれないとその相手に対しても箱に入ってしまいそうだ。

その点本書はわかりやすく解説してくれているし、最悪本を閉じればその後の人間関係に影響はない。 本書に対して箱の外にいることができるなら、箱の外にいる状態で自己反省をするということが果たされるわけで、とても得難い機会になると思った。

余談だが、免疫マップの考え方とも近しいものを感じた。 箱を強化したい・自己正当化したいという裏目的を達成するために、相手をより攻撃的にしてしまうなどはまさにそれ。

本書は自己反省を経て相手を尊重すべきだという考えてこれを解消することを主張しているわけだが、これも裏目的の先入観を解消することで解決する免疫マップの考え方に近いと感じた。

なぜ人と組織は変われないのか読了メモ

冬休みを活用して「なぜ人と組織は変われれないのか」を読んだ。

免疫マップについて解説している本として有名(?)な本。

年末年始は扁桃炎で瀕死で実家に帰れなかったので、自宅にて冬休みの3日間をかけて読みました。

一言で

目標達成できないことを、意志力の欠如や能力不足や努力不足などと捉えずに、対立する別の目標を達成するための合理的な手段であると主張している。

このうえで目標を達成するためには、別の目標を支える固定観念を明らかにして、それを検証して必要に応じて修正していく必要がある。この作業を行うためのものが免疫マップである。

これを作る作業によって目標達成のみならず、主体的に捉えていた固定観念を客体的に捉えることができるようになるので、知性の発達のきっかけが得られる。

感想

400ページを超える大作で読み切れるか不安だったが、読み始めたら問題提起が面白くて、一気に読み進めてしまった。

目標達成できなかった時の無能感というか失敗感は誰でも味わったことがあると思うが、この本は目標達成できなかったことを合理的なこととして捉え、これを乗り越えるためにどうしたら良いか?を豊富な事例とともに説明してくれる。

若干、事例がしつこい感はあった。 「うん、わかった。じゃあどうしたらいいの?どうやったらその免疫マップ作れるの?」と思いながら読み進める展開は、ヒキはあったけど、分量がかなり多いのでちょっと。。。

チーム内で免疫マップを実践することで最大の効果が得られるような感じではあるが、自分の周りでこれを実践できるかどうかはちょっと自身がない。

免疫マップを作る取り組みはかなりのレベルで自己開示が要求される。

これを抵抗なく実施できる状況に自分はないなぁと感じた。

なので、チームでの実践は見おくりつつ、個人的な目標達成について考える際には免疫マップを作ってみようと思う。

免疫マップが向いている目標と向いていない目標というのもあり、資格取得しようといったような目標とは親和性が低いと感じる。どちらかといえば習慣的な目標達成についてどうしてもうまくいかない場合に免疫マップを作ってみると良いかもしれない。

自分の場合は筋トレを継続することがなかなかできていないので、筋トレ継続について免疫マップを作り、免疫を克服するように頑張ることでこの効果を実感できるかもしれないと思った。

読書しながらマインドマップを作った。

f:id:masamasah:20190106161339p:plain
なぜ人と組織は変われないのか

Sequence models & Attention mechanism

CouseraのDeeplearningコースの最終回. 長かった.

Various sequence to sequence architectures

Basic Models

センテンスの翻訳タスクを扱う基本的なモデルを図1に示す.

f:id:masamasah:20181015151629j:plain

このモデルはセンテンスtoセンテンスのタスクでよく使われる.

EncoderとDecoderの組み合わせは,センテンスtoセンテンスのタスク以外に,画像toセンテンスのタスクなんかでも使われる(図2).

f:id:masamasah:20181015151645j:plain

Picking the most likely sentence

LanguageModelを用いた文章生成では,各softmaxアウトプットの結果から,その確率に沿って単語をピックアップして,センテンスの生成を行っていた.

翻訳タスクにおいては,そうではなく,「一番確からしい」センテンスを得たい.

Greedy search

softmaxの値を参照し,初めの単語としてもっともそれらしいものを選択する. さらに,その結果を持って次の単語としてもっともそれらしいものを選択すると行ったように1つずつ単語を確定させていく方法をgreedy searchと呼ぶ.

これは,センテンスを文の先頭から見て決めて行くものであり,センテンス全体として確からしいものが得られにくいという課題がある.

これを解決するのが次章で説明するBeam Searchである.

Beam Search

Greedy Searchの問題を解消する.

簡単に述べると,選択肢をB個(ハイパーパラメータ)しながらセンテンスを最後まで形成し,その中で一番それらしいものを選ぶと行った方法である.

まず,センテンスの初めの単語としてふさわしいであろう単語をB個選択する. 次に,それぞれ選択されたB個が与えられた際の各単語の事後条件を求める.

その事後条件から,改めてB個を候補として記憶する.

さらに,それぞれのB個の単語の組み合わせが得られた際の,各単語の事後条件を求めて,TopB個を候補として記憶する.

センテンス終端文字が得られるまでこれを繰り返し,最終的に得られたB個の候補センテンスから,もっとも確からしいものを採用する.

これによって,初めに先頭単語を決めて,順番にその次の単語を決めて行く方法に比べて,全体を通してより確からしいセンテンスを選択することが可能になる.

Refinements to Beam Search

前述の方法を定式化すると図3のようになる.

f:id:masamasah:20181015151702j:plain

式を見るとわかるが,これをそのまま実施すると,短いセンテンスの方が有利になるという問題が起こる.

これを補正するために,翻訳語センテンスの長さTyを使った補正ずみの式を図4に示す.

f:id:masamasah:20181015151713j:plain

Error analysis in beam search

RNNでモデルを学習し,そのモデルから得られた確率を用いてBeamSearchでセンテンスを完成させる.

プロジェクトを進める上で,ボトルネックになっている箇所を見つけるために,ErrorAnalysisを実施する必要があり,ここではその方法を述べる.

方法は簡単で,以下の通り.

最終的に得られた翻訳結果y(微妙に間違っているもの)と人間が翻訳した正解翻訳結果yを考える. まず,RNNを用いてP(y|x)を求める.次に,P(y|x)を求める.

この結果,P(y|x)>P(y|x)であれば,RNNはyをより確からしい翻訳結果だと主張しているとみなせる.逆にP(y*|x)<P(y|x)であればRNNはyをより良い翻訳結果だと主張していることになる.

つまり,前者であればRNNは正しく翻訳を評価できているため,問題はRNNの後にセンテンスを整形してるBeamSearchのアルゴリズムにあると思われる.この場合はBの値を大きくして精度を高める必要があるかもしれない.

逆に後者であれば,RNNが正しく翻訳を評価できておらず,RNN側の性能改善が求められる.

以上がBeamSearchとRNNについてのErrorAnalysisの進め方である.

Attention Model Intuition

これまでのモデルでは,センテンスの翻訳を,翻訳元の文章全てを見てやってきた.

だが,長い翻訳元の文などについてこれを実施するのはあまり実用的ではない.

構造的に近しい箇所の翻訳元センテンスだけをみれば,正しい翻訳は実施できるからである.

ということで,全ての文章を見て判断するのではなく,翻訳済みセンテンスの1単語を決める際に,どの程度の範囲のinputの情報を参考にすれば良いか?ということをうまく調整してくれるのがAttention Modelである.

Attention Model

AttentionModelを図5に示す.

f:id:masamasah:20181015151727j:plain

α<t, t'>は,単語tを決定するのに,翻訳元のt'番目の単語をどの程度考慮すべきかと言った重みを示す.

Speech recognition

Speech recognition

音声認識システムでは,図6のようなモデルが使われる.

f:id:masamasah:20181015151739j:plain

ここで得られたttthh_ee_ qqq__みたいなアウトプットを整形して,"The quick brown fox"といった正解を導き出すことができる.

Trigger Word Detection

Alexaのようなトリガーする単語の検知システムも似たようなモデルになる. 図7にイメージを示す.

f:id:masamasah:20181015151757j:plain

こんな感じで,Many-to-Manyのアーキテクチャでトリガーワードが検知されたら1を返すようなスタイルになる.