先週、1/18〜19にあったウィンターワークショップ2018の参加報告記事を、会社ブログに書きましたんで、こちらでも備忘録がてら紹介。
参加報告に絡めて、今やってる機械学習工学とは何なのか、について語ってみました。
なお、当日の様子や議論内容は、こちらにまとまっています。
先週、1/18〜19にあったウィンターワークショップ2018の参加報告記事を、会社ブログに書きましたんで、こちらでも備忘録がてら紹介。
参加報告に絡めて、今やってる機械学習工学とは何なのか、について語ってみました。
なお、当日の様子や議論内容は、こちらにまとまっています。
今朝書いた、下記記事の続きです。 bonotake.hatenablog.com
一旦は「Facebookで議論すんのしんどいから」という理由でやり取りを打ち切ったはずでしたが、この記事に対してアジャイルコーチの守田さんが「SCRUM BOOT CAMP THE BOOKをお読みなら話が早い」と仰って、結局その後もFB上にて守田さんとやり取りしてました。
結構長々とやり取りしたんですが適当にまとめます。
Scrum*1で「チーム内の属人性は排除する」と考えるのは誤りらしい。本当?
従来型:バッチ処理の担当者に必要なスキルと、バッチ処理技術ルールをドキュメント化して、属人性を排除する。
要は、各メンバーが多能工化するのはするんだけど、エクストリームに何でもできるようになる訳じゃないと。 ある程度はスキルを共有して、共有できた範囲で属人性を排除するということのようです。
blog.fenrir-inc.com 「ある日突然トラックに轢かれてもプロジェクトが停止しないメンバーの数」らしい。(後述する同僚のEは初めて知ってめっちゃウケてました。) 僕はとっさに「トラック転生するから何人でも大丈夫では」とか考えてしまい(ry
トラックナンバーは当然1だとまずくて、ただ2, 3確保すればとりあえずはOK、なんでしょうか? 言い換えれば「1人の人が2,3のスキルを身につけるって感じ」だと。
この程々感がまぁ、アジャイルっぽいっちゃ、アジャイルっぽい(小並感)
似たようなものは BOOT CAMP本でも登場してました。
なので、「チーム内の全員が同じスキルを持つ」という前提はないし、「属人性の排除」でなく「スーパーエンジニアを評価して、その人から学ぶ事で、チームの能力を向上させる」と捉えるべきである、と。
今日たまたま、このイベントで「Scrumと属人性」にまつわるセッションがあったそうで。
チェックしてた守田さんによると 「とことん掘り下げた尖った人を集めて、ポートフォリオで(必要なスキルを)揃える。そうでないと、今時の次々に新しい技術やフレームワークがでてくる状況に対応できない。」という話だったようです。ふむ、見事に今回の話題につながっておる。
とまぁ、基本守田さんが色々と解説してくれ、まぁ肯けるところは肯けるし、ふむふむと僕がもっぱら聞き役になっていた感じではあったんですが。
ここでふと、会社で隣に座ってる同僚のEにこの話を振ってみました。というのも彼、前職ではずっとScrumで開発を回しており、その経験から、来月からの我がチームでおそらくスクラムマスターを勤めることになるだろう人物だったからです。
拙い英語で*2「チーム内の属人性とかスキルの偏りとか、どう考えるべきなの?」と聞くと、
「traditionalな*3Scrumでは、チーム全員同じスキルを持つって考えるのが基本だよ」
うぉーい話がひっくり返っとるやないかーい!
Eによれば、チーム内の各人のスキルの持ち方は”T-shape”であるべき、なんだそう。つまり1点では深い専門知識を有する(かもしれない)けど、その他のスキルについても広く浅く有しているべき、だと。
あれー話がおかしくなったぞ、と思いつつも。 ふとこのとき、以前職場でScrum導入するかどうか皆で話し合ったときの話を思い出したんですよ。
そのとき別の同僚が「チーム内で各人が持ってるスキルも熟練度もバラバラなのに、どうやってチームのベロシティ*4を評価できるの?同じタスクでもAさんがやるのとBさんがやるのとで速さ違わない?」と質問して、それに対するEの回答が「Scrumではみんな同じスキルを持つと考える」だったんです。
これこそ、僕が「チーム内全員同じスキル」が非現実的だと思いつつ納得した瞬間だったんですよね。彼の説明は筋が通ってる。非合理だけど。
てか、そう考えないと「ベロシティ」って概念こそが非合理になってしまう。
一応Eが話したことも、かいつまんでFBに書いたんですが、守田さんの反応は
誤解と思われます。
まぁ、話食い違ってますもんね、明らかに。
その後も色々なんで「誤解」か説明してもらったけど、ここではざっくり省略。
僕は結局、2つの「正解」の前にわからなくなってしまった、というのが正直なところで。 守田さんとは、そのうちEも入れて一緒に議論&情報交換しましょう、といった感じで話は終わったんですけども。
晩になって、ふらりと旧友のNがそのスレッドに現れ、こんな書き込みを残していきました。
N おそらく言うまでもなく、「チーム全員全知全能」が理想形で、その場合当然属人性は排除されてて、現実そこに至らないときに、個々人の能力を広げてカバレッジを上げるのか、マニュアル化でスキルがなくても出来るようにするのか、業務をスキルがなくても出来る範囲で設計するのか、アプローチが違うだけなんでしょう。実際にはどのアプローチも程よく必要だと思いますが。
何やらうまいことまとめおって。
結局N的視点から言えば、(前回の記事の話に立ち戻って)アジャイルも伝統的WFも、「アプローチの差」でしかないと。 アジャイル信者でも否定論者でもない僕からすれば、この立ち位置が一番バランス取れてて腑に落ちる感はありました。
まぁやっぱ、Scrumは一見シンプルなようでいて、奥が深いというか底が知れないというか。イマイチまだ疑問は残ったままではありますが、そのうち「やればわかる」的境地に達する……といいな、とは思っています。
【追記】 西尾泰和さんが僕の前回の記事の記事を読んでくれて、以下みたいな記事を書いてくれました。 scrapbox.io 「二種類」とも、Nの言及した「アプローチ」に含まれていますね。
【追記おわり】
*1:見出しにはカタカナで「スクラム」としましたが、どうも個人的にはScrumと書くのが好み(というかカタカナ書きがイマイチ好きじゃない)ので本文はScrumです。でもスクラムマスターは「スクラムマスター」です。統一感なくてすいません。
*2:彼は東欧人で、うちの会社に来るまではずっと英国で働いてました。なので彼とは基本英語でやりとりしてます。「属人性」とか訳すのめっちゃ辛かった。
*3:彼は結構、Scrumの亜流というか派生版というか、そういうものにも色々詳しいようなのです。
*4:スプリントごとにチームがこなせる仕事量のこと。間違ってたらスイマセン。正確な定義はちゃんとScrum知ってる人の書いたものに譲ります。適当にググってくだせい。
昨晩、このような記事を読みまして。
この中に、このような話が。
江草氏がたどり着いた答えは、「属人化を排除するのはよくない」だ。少人数のエンジニアが開発したものが大規模に普及している現実がある。
これについて、僕がFacebookの限定公開の記事にて、こう書いたんですよね。
ソフトウェア工学の基本思想とは相反するんだけど、一面の真実なんですよね……
すると、守田憲司さん(アジャイルコーチな方)からコメントが。
一言で「属人性の排除」と言ってもいろんなコンテキストが有りますが、一昔前のソフトウェア工学で言われた属人性の排除は、現在では概ね否定されていて、相反するって事は無いと思います。
(強調は筆者)
おおう、これは、ついこないだまでソフトウェア工学の研究者だった者にとっては聞き捨てならないぞ。 ということで掘り下げて聞いてみました。以下ログ。
Takeo Imai > 現在では概ね否定されていて
というのは、どのへんで言われてることなんでしょう?
Takeo Imai 僕自身、ついこないだまでソフトウェア工学の研究者だった(今も研究自体は続けてる)ので、ちゃんとしたソースを知っておきたいです
守田 憲司 端的には、CMMIなどは使われなくなって、アジャイル開発が一般的になってるという事です。
アジャイル開発自体は、現実には、従来型以上に属人性は排除されますが、ちょっと意味が違います。この記事のように。
従来のソフトウェア工学の流れも続いてると思いますが、それら全体が使われなくなって来ていると思います。
Takeo Imai > 現実には、従来型以上に属人性は排除されますが、ちょっと意味が違います。
この辺がよくわからなくて、もう少しきちんと教えて頂ければ……たとえばScrumだと、基本的にチームの構成員は「みんな同じスキルを持っている」(=チーム内に属人性はない)という考え方がベースにあると思いますが、これはどう「ちょっと意味が違」うのでしょうか。
守田 憲司 『Scrumだと、基本的にチームの構成員は「みんな同じスキルを持っている」(=チーム内に属人性はない)という考え方がベースにある』というのはよくある誤解です。
基本的にクロスファンクショナルチームなので、混成員のスキルが様々な事が基本です。
まぁ典型的なWFと比較すれば、多能工を志向しますが。
守田 憲司 大きな違いは、ドキュメントでしょうかね。従来型だと、ドキュメントを整備して、それに沿って作業すれば誰でも、作業ができる事を目指しますが、アジャイル開発では、そこが暗黙知になってる事を許容する代わりに多能化して、誰か居なくなっても大丈夫なようにします。
この時点で、「FBでやり取りするのは難しい」ということになって、「またお会いしたときに!」となって終了したのですが。
僕もわかったようなわからないような、何とももやもやした感覚。
ざっくり要約+補足すると、
僕自身はそこまでアジャイル信者でもない(否定論者でもない)ので「アジャイル開発が一般的」と言われると、ちともにょってしまうのですが。ただ、より多くの現場に普及しつつあるのは確かにそうでしょうね。
結局、誤解を恐れず、守田さんの言葉をざっくりまとめると要は「アジャイルでは属人性は排除されない」ということでよろしいか(誰に聞いてる?)
で、Scrumでの「チーム内の属人性は排除」は「よくある誤解」とあって、いや実は僕自身、Scrumに違和感感じていた点でもあるんですよね、このへん。 ただやっぱり、説明されてもよくわからず。「多能工を志向」すると、究極的には全員が同じスキルを持ってしまわないのだろうか……
例えば、以下の記事。 qiita.com ここには、
スクラムでは生産性を上げるためにも「自立や向上」を目指している。
そのためには、属人化を出来るだけ排除する必要がある。
とあって、属人性を排除してるように読めなくも。
あるいは以下。
デメリットとして最近感じているのは属人化を排除することで同時に個々人の責任感も削り落としてしてしまったのではないかという点である。
属人化の排除と責任感のトレードオフについて - MogLog
もっとも、「属人性」と「属人化」がまた違うものを指しているような気もして、そこがミソなのかもしれないけど。守田さんのいう
誰か居なくなっても大丈夫なようにします。
は、「属人化の排除」なのかな。
それに、僕がScrum勉強した(うちの1つの)この本を今ざっと読み返すと:
ううーん、やっぱりよくわからん。今度守田さんにお会いしたときに、がっつり聞いてみよう。
【追記】続きです↓
【追記おわり】
一昨日、このような記事を書きました。 bonotake.hatenablog.com
そしたらまぁ、自分の想像を遥か超える勢いでバズりまして。1日も経たないうちにブクマが軽く100を超えてしまいました(これ書いてる時点で171)。 今まで、1記事につきブクマ1桁しかもらったことないんで、いやはや、びっくりです。
それ以外にも色々なところから反響ありました。
『仕事ではじめるディープラーニング』が出るらしいですよ皆さん!!!(と煽る業界の老害) https://t.co/bmPFQvbeF9
— TJO (@TJO_datasci) 2018年1月7日
あのTJOさんに煽られました。
他、紹介した『仕事ではじめる機械学習』著者の方々からも。
ディープラーニングをやる人向け『仕事ではじめる機械学習』のオススメと注意点 - bonotakeの日記b.hatena.ne.jp本にも書きましたが古典的なMLは特徴エンジニアリングがDLはネットワーク設計が大事ですね。教師データは規模の違いはあれど両方重要かなあ
2018/01/08 07:18
仕事ではじめるディープラーニング、めっちゃ読みたい
— ところてん (@tokoroten) 2018年1月7日
ディープラーニングをやる人向け『仕事ではじめる機械学習』のオススメと注意点 - bonotakeの日記 https://t.co/MFLWHmLgww
いや、ありがとうございます。
しかし、何でこんなバズったんだろう……ベストセラー本に手をつけたから? 「ディープラーニング」ブームだから? 最後に「俺が本出すぜ」アピールしたから?
一緒に本の企画している編集者さん(私の過去いた界隈では知ってる人は知っている、Sさんです)曰く
あのブログの煽り力が秀逸ですw
煽ったつもりはなかったんですが……まぁいいや。
それはともかく、ちょいちょい気になる反応も頂いたんで、ここに追記という形で言及しておきます。
昨日の晩くらいに、会社のSlack経由で、同僚の1人から感想もらいました。曰く、
なんかだいぶDL案件への感覚が違いますね
ええ〜(;´Д`)
で、他の人も巻き込んでSlack上で議論してたんですが。とりあえず、その方から指摘されたのは2点。
1つめについては、その方曰く
だいたいベースラインとしては、公開されたネットワークを使いますが、その後は、あれこれネットワークの層を削ったり、レイヤーを変えてみたり、分岐の場所を変更したり、っていうのをよくしますね。
との事。なのでこれについては、僕の経験不足だったということで、前の記事を訂正しておきます。(既に前回の記事内にも訂正を入れています。)
2つめについては、これは僕の本意ではないです。確かに「極めて時間がかかる」とは書いたし、感覚としてMLよりはDLの方が時間かかると思ってますが、そこが「一番」時間を食うというつもりではなかったです。
じゃあ、何が時間がかかるか、というと、前処理と学習データ(教師データ)の作成、評価指標の選定とテストデータの作成、あたり。
この辺は僕としても全然異存はなくて。ただ、この辺はMLもDLも一緒で、『仕事ではじめる〜』にも書いてあることそのものなんですよね。僕は『仕事ではじめる〜』と「違う」ところを書こうとしたために、そっちばかりが強調されて読めてしまったのかもしれません。
とりあえず、学習に一番時間がかかるわけではないことと、前処理、学習データの作成、評価方法のセットアップが一番大変というのはここに強調しておきます。
Twitter眺めてると、ごく少数ですが、僕の記事が『仕事ではじめる〜』を否定しているかのように捉えてる方がいましたが。
ぜんぜん違います。むしろみんな読めです。
肌感覚ですが、DLでも書いてあることの7割以上は通用すると思ってます。細かい個々の手法などはともかくとしても、プロジェクトの回し方や、ML/DLに対する基本的な考え方なんかはほとんど同じです。どうぞ誤解なきよう。
最後に、僕が今企画してる本ですが……皆さんがあまりに「『仕事ではじめるディープラーニング』読みたい!」とおっしゃってくださるので、若干気が引けてきました(笑)
一応お断りをしておきますが、そこそこ近い路線を狙ってはいますが『仕事ではじめるディープラーニング』そのものではないです。多少趣旨は変えているというか、違う攻め方をしたいと思っています。まぁそれなりにはタメになる本にしたいと思ってますので、どうか宜しくお願い致します。
今後、本の進捗などあれば、ここなどでちょくちょく書いていこうと思います。
明けましておめでとうございます。今年もよろしくお願いします。
たまたま昨年末に、Facebookの謎な対応により始めてしまったはてなブログ、「次書くかどうかわからない」とは書きましたが、次も書いてみることにしました。
なぜそう思ったか、理由は2つあります。1つは、日頃はTwitterかFacebookばっかりやっている自分ですが、そっちだとどうしても書いたものが流れてしまって、あとから自分で見返したくても見返せないこと(特にFacebook。TwitterはTwilog使ってるのでまだマシ)。
もう1つは、とある本について、どこかに書き留めておきたいなぁ、と思ったこと。
その本の名前は、『仕事ではじめる機械学習』です。
この本、最初は同人誌だったものが、オライリーから昨年10月に電子書籍として発売されたところ、ベストセラーとなって、今月1/16に紙の本(ソフトカバー本)が改めて発売するとのこと。
僕はこの本、電子書籍が出た割と直後くらいに買いまして、非常に感銘を受けました。
早速、機械学習(ディープラーニングですが)でメシを食っている勤務先にも布教しました。会社でも電子書籍を購入しまして*1、エンジニアだけではなく、ビジネス開発やセールスのメンバーにも読んでほしい、と、社内Slackで宣伝しまくりました。
ただ、一方で。
「機械学習」でなく「ディープラーニング」を飯の種にしている人間からすると、多少気になる点があり、ついこんなツイートを。
そしたらその後、著者の1人である有賀さんに初めてお会いしたとき、いきなり「ディープラーニングだとどこが違うんですか?」などと質問され、(わーおしっかりチェックされとるやんかーい!)と冷や汗をかいたり……この本、すごく面白いんだけど、やっぱディープラーニング周りだとちょっと違うな、と思わせることも / 仕事ではじめる機械学習 有賀 康顕 https://t.co/HUNFsHsvhk
— takeo (@bonotake) 2017年11月26日
そんなこんながありましたんで、(たぶん沢山有るので今更ですが)簡単ながらこの本の紹介と、普通の機械学習(ML)でなくディープラーニング(DL)を使う人の場合、どういう点に注意して読めばいいのか、という辺りを書きたいと思います*2。
この本、何がいいかといいますと、あくまで「ビジネスで機械学習システムを組む人のための本」、になっているということです。
「機械学習」ではなく、「機械学習システム」*3であることがポイント。機械学習をすることが主目的ではなく、あくまで、実現したい製品/サービスのために機械学習を用いる、というスタンスが首尾一貫している、ところがいいのです。
ですので、機械学習そのもののテクニカルな説明は、要点は押さえつつも最低限に抑えられています。それよりも、機械学習をどう使うか、機械学習プロジェクトをどうマネジメントするか、機械学習製品・サービスをどう構築するか、のノウハウ解説に力点が置かれています。こういう本は、洋書を含めて他にないのではないでしょうか。
特に1章『機械学習プロジェクトのはじめ方』には「機械学習をしなくて良い方法を考える」という項目があります。そこでは機械学習をシステムに組み込むデメリットもしっかり書かれています。一般企業の中で機械学習を使おうか、と考えるときには、当然こうした、メリット・デメリットを天秤にかけた冷徹な視点が必要です。
まぁ私のいるディープラーニング専業の会社では「ディープラーニングを使わない」=失注、なわけですが(汗)、ただ、お客さんに「ディープラーニングならなんでもできるに違いない」といった過度な期待とともに依頼されて「何だよできねーのか」と失望される、よりは、冷静にこうした視点で臨んで頂いたほうが、僕らも助かりますし、いま過熱気味のAI/DL業界にとっても、その後のハイプの暴落度合いが小さくなるんじゃないか、と思っています。
一方で、MLでなくDL視点で読んだ場合、この本がどういう点で「違う」のか、を、僕なりにさらっとまとめてみます。
この本の後半(第7~9章)、応用事例として挙げられているのは、「映画の推薦システム」「Kickstartarの分析」「マーケティング資源の効率化」です。いずれも、データ分析とその応用、の話です。MLを用いるのは殆どの場合データ分析なので、これは当然です。
一方DLに興味がある人がやりたいのは、ある種のデータ分析もあるとは思いますが、多くは「画像認識・生成」「音声認識」「自然言語処理」といったものへの応用じゃないかと思います。 データ分析、といえばその通りなのですが、恐らくピンと来ない人も多いのではないかな、と思います。 なのでDLに関しては、もっと違った応用事例を読みたいな、と思ってしまいます。
あと敢えて述べるなら、この本では主にWebがフロントエンド、DBがバックエンドにあるシステムが想定されていて、MLは確かにWebシステム・Webサービスで用いることも多いのですが、DLの場合はどうなんだろう?とは思います。これは僕の会社が主に組み込み系を主体にやっているせいもあるんですが、相対的にWebシステムへの応用度合いは、MLより低いのでは?と思います(この辺はあくまで僕の肌感覚で、実際のところはわかりません)。
MLにおいては、特徴量の設計(feature engineering)が、品質の良いシステムを構築するための重要なファクターになります。特徴量とは、「機械学習の予測モデルに 入力をする情報のこと」(同書より引用)です。どの特徴量を選ぶか、どう機械学習に組み入れるかで、機械学習の精度がガラッと変わってしまいます。
一方DLでは、どの特徴量を用いるかも学習されるため、DLシステムの開発者が気にする必要はほとんどありません。よって、DLではこの工程は事実上省かれることになります。
DLでは、MLの「アルゴリズムの選定」に相当する「ネットワークの選定」が最初のポイントになってきます*4。多くは、これまで様々な大学・企業が色々なアプリケーション向けに設計した既知のネットワーク(画像からの物体検出なら「YOLOv2」、とか)のうち良さそうなものを選定することになります。場合によってはオリジナルのネットワークを組む人もいるかもですが、「実際に性能が出るのか」の評価から行わないといけないので、ごく稀です。【1/9追記】ここ、同僚からツッコミがありました。ベースラインとしては既知のネットワークを使うけど、そこに色々手を加えてカスタマイズすることはよくあるとのこと。なので訂正しときます。【追記おわり】
あとは、教師データの準備がML以上に大きな比重を占めます。特徴量などを人手で設計する必要がなくなった分、DLでは大量の教師データが必要で、これをどこからどうやって調達するか、が実は一番大変だったりします。
その後は、ひたすら計算機をぶん回して学習させます(バッチ学習の場合)。ここが極めて時間がかかる(場合によっては数日とか)ので、DLを専業にしている会社は学習時間をいかに短縮するかのノウハウが色々あったりするようです。
……ん? ウチ? あれ、どうだったかな(汗)
やはりDLもMLの一種ですし、共通点は多いです。教師データをどう準備するか、(ハイパー)パラメータのチューニング、実システムにおける問題点への対処方法、などなど。
過学習や汎化性能などの問題も当然ありますし、恐らく気にしている人は気にしているかもですが、DLは一般的な傾向として汎化性能が高いこともあって、普通のMLほど敏感になる必要はないかもしれません。ただし、「トレンドの変化などで入力の傾向が変化する」(同書より引用)可能性は、アプリケーションによってはDLでも発生し得て、なのでやはりDLシステムでも気をつけなければなりません。
ということで『仕事ではじめる機械学習』、極めて面白いしオススメなのですが、僕の感想は究極的には、次の一言に尽きます。
いやホント、誰か書いて。誰か「仕事ではじめるディープラーニング」書いてください
— takeo (@bonotake) 2017年11月26日
……と、こういう場合の典型的な切り返しが「言い出しっぺがやれ」だったりするんですが。
実は水面下で、「ディープラーニング版『仕事ではじめる機械学習』になるかもしれない本」の企画を進めています。まったく同じ趣旨になるかどうかはわかりませんが、ディープラーニングで仕事をしたい人向けの本を世に出すべく、画策中です。
そんなすぐには出ないかもしれませんし、企画がポシャるかもしれませんが、まぁ、乞うご期待、ということで。
【1/9追記】かなり反響あったんで、補足を書きました。↓ bonotake.hatenablog.com 【追記おわり】
*1:「紙で読みたい」という人もいたので、ソフトカバー本発売決定にあたり、そちらも予約注文しています。
*2:読み終わってから少し時間が経っているので、詳細に突っ込んだ話はしません。読み終わった当時は色々と思っていたこともあったのですが、今は若干記憶がぼやけ気味なのが残念。もう少し早くにまとめておくべきだった。
*3:この用語が本で用いられているわけではありません。ただ前回の記事でも述べましたが、僕は現在「機械学習工学研究会」(機械学習のためのソフトウェア工学を研究する会)を立ち上げようとしてまして、そのコミュニティの中で僕はこういう用語を使っています。
*4:1/8追記:有賀さん(chezouさん)からブコメ頂いてる通り、この辺は『仕事ではじめる機械学習』でも軽く触れられています。
元々これは、Facebookに友達限定で書いた記事を、一般公開向けに少し改訂したものです。なぜこんなことをしているかというと、FBに書いた記事、FBからスパム認定食らって削除されてしまったもので……なんで??!!(1/2追記:本日スパム認定は取り消されました。)
長文すぎたのか、とか、マネーフォワード推しすぎたのか、とか、色々想像は膨らむのですが、はっきりした理由はわからず。
で、今回はたまたま他所で下書きしてて、たまたまその下書きが残っていたので、折角なので……とこっちに転載することにあいなった訳です。
なお、僕は元々『たけをの日記@天竺から帰ってきたよ』なる「はてなダイアリー」を過去に書いていたのですが(今回はてなブログ開設にあたって記事をこちらにインポートしています)、ほとんどtwitterとFacebookに軸足を移したため徐々に更新頻度は落ち、最後の記事から3年以上更新は止まっていました。
そういう意味で、今後も更新するかどうかはわかりませんので、どうかご承知おきを。
さて、新年まであと数時間となったところで、ここに今年の振り返りをしておこうかと。 今年は大きく3つの出来事がありました。
何を置いてもまずはこれ。人生の大きな転換期になりました。
きっかけは、まぁ僕の前職をご存じの方は(ネット上に細かい経歴載ってますので、簡単にわかります)お分かりのとおり、勤めていた会社の経営不安にあったのですが。結果としては、会社飛び出して大正解だったな、と。今んとこ。
今から思えばここ何年か、何とも言えない停滞感に苛まれていたというか、色々がんじがらめの会社の中でどこか汲々としていて、自分に対する自信もかなりの部分失っていたように思います。
環境変えて、しかも大企業から急成長しているベンチャーに飛び込んで、新しい空気を吸えたことで、今まで失っていた色々を回復しました。
新しい会社も、もちろん問題はないとは言わないけど、今のところ、皆目標に向かって自律的でアクティブに動いてるし、アットホームな雰囲気もあるし、すごく気に入ってます。
ベンチャー特有の?「自分が頑張らないと潰れるかも……」というプレッシャーも適度なスパイスになってますw
多少転職に絡まなくはないんですが、始まったのは転職前のことです。
前職でも、今まで培ってきたソフトウェア工学の知見を機械学習に活かせないか、といったモチベーションで潜航的に研究をしていたのですが、そこに来て、今年のSESでのパネルが非常に面白く、Facebookに感想エントリーを書いたのでした。
https://www.facebook.com/bonotake/posts/1504893489556668
そしたら、このエントリーがきっかけで、実際に「機械学習×ソフトウェア工学」を考えるコミュニティを作ることに。
そしていくつかの偶然が重なって、結果として、来年度に日本ソフトウェア科学会傘下で、新たに「機械学習工学研究会」(MLSE)を立ち上げようと今動いています。
長らく研究職に携わってましたが、まさか自分が研究会の立ち上げに回るとは思ってもおらず。
前はとにかく、自分が論文を書いてpublishすることが唯一の貢献の手段だと思っていたし、周囲からもそれが求められていたのですが、幸か不幸か、公的には研究職を離れたことでその呪縛からも逃れ、こういう、もっと違うアプローチで貢献するのもアリだな、と、一段俯瞰した視点で考えられるようになりました。
特にこの「機械学習のためのソフトウェア工学」という分野は、特に国内では誰も手を付けられていない研究分野だと思っていて、そういう意味で、国内での研究の萌芽を促していきたいです。自分が論文を書くことはなくても(機会があったら書きたいけど)、他の人が次々に研究をし、論文を書ける土壌を作れればいいな、と。
内向きの仲良しクラブ的な研究会も存在しますが、MLSEはそういう風潮には陥らず、多くの研究者やエンジニアに開かれた、オープンな活動をしていきたいな、と思っています。
話はガラッと変わってしまうのですがw 地味にこれが生活を変えました、っていうか非常に助かってます。
使い始めたきっかけは、前職で給料減らされてw 色々節約したくて、まずは家計簿つけるか、と考えたのが始まり。
しかしこれが、使い始めてみると非常に便利で。単なる家計簿という枠を越えて、ありとあらゆる手持ち資産を一括管理できるのです。これ使うまで、自分の手持ち総資産がいくらか、ということもまともに把握できてなかったし。各所に散らばった口座を全部まとめて、どこにいくらあるのかわかるし、どこでいつ何をいくら買ったのかとか、全部可視化できるようになりました。Fintech万歳。
そしてこれが地味に影響があったのが、やはり転職のときのドタバタで。前職では企業年金もあれば給与引き去りで財形貯蓄ができたりとかしたところ、そういう制度が一切ないベンチャーに移って、その手の資産運用を自分でやる必要性が出てきました。ほんの僅かですが、退職金も出たし。
今までだったら、そのへん全部とっ散らかって終わってたと思うんですが、マネーフォワードがあるお陰で1円単位で管理できるので、ズボラな自分でもすごくやりやすい。
まぁまだ「運用」なんて大げさなものはやってないし、今年は色々手続きしただけで終わってしまいましたが、来年からは自分でもなんとかなりそう。
そんなこんなで、何かとっ散らかってしまいましたが、今年の3大出来事でした。
前回の続きです。正確には、前回の続きの後の檜山さんのブログ記事に対する更なる「合いの手」です。
一連の記事を読んでいろいろ考えているうち、実は直和だけでなく直積も問題だということがわかりましたw
ということで、前回とほぼ同じノリで直積も考えてみます。今回も使ったAlloy記述全文はGistに貼りました。
あと、上記檜山さんの記事の「関係圏を観察してみる」以降を適時引用します。Alloyは関係をベースにした言語なので、関係圏とは相性がとてもいいのです。
さっき問題あるとは書いたものの、直積は直和と違い、Alloyにはちゃんと言語機能としてあります。集合A に対して A->A と書きます。
なんで直積なのに関数型みたいな書き方すんの?という方にはこちらを。関係圏では(翻ってAlloyも)集合の直積は冪とか関数(関係だけど)とほぼ同一視できるようです。
ということで、このAlloyの直積を議論の対象として扱います。檜山さんの記事に合わせると、テンソル積と呼ぶべきですかね。
関係圏Relでは、ホムセット Rel(A, {0, 1}) はAのベキ集合にはなりません。Rel(A, {0}) がAのベキ集合なのです。{0}は単元集合1です。1は、関係圏においては始対象でも終対象でもありません(始対象=終対象=空集合です)。1は、テンソル積(集合の直積でした)の単位対象として特徴付けられます。
だ、そうなので、単元集合を持ってきましょう。
Alloyには特別特定の単元集合があるわけではないので、1からこさえます。と言っても1行で終了ですが。
one sig Unit {}
冒頭のoneで、必ず1個だけ存在する、すなわち単元集合であるという宣言をしております。
で、これがテンソル積の単位対象になってることを確かめてみます。
……といっても、単純じゃないんですよねこれ。要は、 Unit->A ないし A->Unit が Aと同型になっているって言えばいいんですけど。
同型であることの証明ってAlloyで書きづらい……*1
てなわけで、「集合のサイズが等しい」っていう、間接的な形で確認することにします。
ということで、以下のアサーションを。反例出ないと思います。
check { all a: set univ { #(Unit -> a) = #a #(a -> Unit) = #a } }
対角ですが、こんな感じで。直和の時とほとんど感覚は同じです。
fun diagP (a: univ): univ -> univ { a -> a }
適当な集合Aに対して、A->Aを作って返してやるだけです。
一方余対角ですが、ないらしいので、
論理積∧は、p, q:A→1 に対して、δA;(p×q);ρ と定義する。ρ:1×1→1 は、テンソル積の単位法則に伴う自然同型。
にあるρ:1×1→1 (ここまでの書き方に沿えば、ρ:(Unit->Unit)->Unit)をこさえましょう。こんな感じです。
fun ro (r: Unit -> Unit): Unit { Unit.r }
rの頭からUnitと結合して、r: Unit->Unitの後ろ側の成分(第二成分)だけを取り出して返します。
え?第一成分は要らないの?これでいいの?? とお思いになるかもしれませんが……一般的にはダメかもしれません。しかしAlloyの矢印型直積を使う分には、これで構いません。この理由は後で述べます。
で、せっかくなので、上記の論理積 δA;(p×q);ρ を作ってしまいましょう。 まずは δA と (p×q) を結合するために、次のような関数をこさえます。
fun joinL (a: univ->univ, r: (univ->Unit)->(univ->Unit)): Unit->Unit { (a.univ).(r.univ.univ) -> (univ.a).(univ.(univ.r)) }
aの第一成分とrの第一成分、第二成分と第二成分を結合して、改めて -> でつなぎなおします。これも、直和のときに考えた結合と、基本的な理屈は同じです。
以上の diagP(δA)とjoinL(結合子 ; )、ro(ρ)をつないで、さっきの論理積の定義を書き下します。
fun prodL (f,g: univ -> Unit): univ -> Unit { {x: univ, u: Unit | u = x.diagP.joinL [f -> g].ro } }
こうして、論理積 f ∧ g が定義できたんですけども。
これって結局、やっぱり、Alloyでいうところの
f & g
と同じなんですよね。実際、以下のアサーションは反例出ないです。
equiv_product: check { all f, g: univ -> Unit | prodL[f, g] = f & g }
ということで、直和の時とオチもほぼ同じでした。ちゃんちゃん。
ちなみに、以前紹介したドメイン付きクリーネ代数のAlloyモデルですが、命題をPropのべき集合(set Prop)で与え、論理積はその間の集合積 & で書いてました。この辺とややつながった感じ?
で、上記 ro の定義がなんであんないい加減でいいのか、というお話ですが。
実は、ひとくちに「直積」と言っても、ビミョーな差でいくつか種類があるのです。それで「Alloyの矢印型直積を使う分にはこれで構わない」なんてビミョーな表現をしたのです。
ro の引数 r: Unit -> Unit (=Unit×Unit)ですが、具体的に何種類の値があるかわかります?
Unitが単元集合だったので、Unit型の引数にはたかだか1要素しか入りません。なのでUnit×Unitなら、第一成分、第二成分それぞれに「ある」(Unitそのもの)か「ない」(空集合 none)かの2択しかなく、よって r は 4種類。
……と見せかけて、実はAlloyの場合、2種類しかありません。Alloyの直積はstrictな直積(スマッシュ直積とかいいます)になっていて、片方の成分が空集合なら、ただちに全体も空集合になります*2。なので、第一成分、第二成分とも「ある」か、両方ともなかったことになるかの2択なのです。
一方、一般的な集合の直積、集合圏の直積はstrictではなく、なので片方が空集合というだけで全体が空集合と完全にイコールにはなりません(同型にはなるけど)。ということで、ビミョーに違うんですね。
なので roは、本当なら「第一成分と第二成分がともに空でない場合に単元集合を返す、そうでなければ空集合を返す」と書くべきなんでしょうが。現実的には、どっちも空でないかどっちも空か、しか選択肢がないので、片方だけ参照する、という上の定義で成り立ってるわけです。
Alloyプリミティブの直積 -> じゃなくて、新たに一般的な直積を起こせばよかったのかもしれませんが、面倒くさかったのでした。はい。