これは、AlloyのDaniel Jacksonが昨年新たに出版した本の書評です。
元々この個人ブログに書くつもりだったんですが、諸々の都合で会社のブログに書きました。
てことで、ご興味あればぜひ読んでみてください。
たまたま入った近所の自転車屋さんが凄かった話
これは、僕が実際に近所の自転車屋から聞いた話です。
昔、会社のSlackに貼ったテキストをちょっと改訂して載せています。
その自転車屋さんに、ある小さい子供連れのお母さんがやってきました。
なんでも、トイザ○スで買った子供用の自転車のブレーキが効かないので、ブレーキを交換して欲しいと。
でも、いくらブレーキパッドとかその周辺とか見ても、どこも悪くないし、手元で試しても特に問題ない。
困った自転車屋さんは、実際にその子に目の前で自転車に乗ってもらって、それを観察してみることにしたらしいのです。
そしたら、実は原因がぜんぜん違うところにあったと気づいたそうで。
原因は、ハンドルのとこのブレーキレバーが開きすぎてて、その子の小さい手ではまともに握れなかったことだったと。
なので、ブレーキレバーがあまり開かないように締めてあげたら無事ブレーキが効くようになりましたとさ。
顧客理解と要求分析ってこういうことよな、と僕は事あるたびにこの話を思い返すようにしています。
要はこれですね。
ちなみにこれ、僕が自転車がパンクして困って、たまたまその近くにあって駆け込んだ自転車屋さんで聞いた話です。
僕がパンクした自転車を預けて帰ろうとしたら呼び止められて、「修理の間ここで付き合ってほしい」と言われました。で、この話をされて「それ以来、どんな小さな修理の依頼でも、修理している間はお客さんに見てもらって、その間お客さんとなるべく話をするようにしている」とのことでした。
僕は某メーカーの研究所でソフトウェア工学の研究をしながら社内コンサルをしていた時代、こういう教訓は先輩たちから幾度となく聞いたんですけど、この自転車屋さんは1人でその重要性を見抜いたのだから、本当にすごいなと思います。
確認を取るソフトウェア開発
僕もいい歳してオタクなのでオタクな絵をSNSで眺めてたりしてるんだけど、そういうオタク界隈でよく絵師さん（イラストレーターさん）が描きかけで没になった自作の絵を「供養」と称してTwitterに晒していることがよくある。
で、このブログ記事も趣旨は割とそれに近いもので、僕の昔の仕事を供養するためのものだ。
といっても大昔で、2002年頃、社会人3年目に自分が書いた資料が最近部屋の中を整理してたら出てきた。僕は当時東芝の研究所にソフトウェア工学の研究者として勤めていたのだけど、それは東芝の社内に適用するために考えた独自のソフトウェア開発方法論の提案だった。
んでそれを見たら、めちゃくちゃびっくりしてしまった。
まぁ20年前に没になったものなんで公開しても問題なかろうと思うので公開してしまうが、タイトルは「確認を取るソフトウェア開発」というものだった。
で、その提案内容なんだけども、
- 開発プロセスのどの工程かに関わらず、session（インタビューや話し合い、報告）とwork（作業）を繰り返す
- 開発項目や課題はカードに書いて、カードごとのステータスで進捗を管理。ステータスはsession時に更新して、「確認」になったらその項目は終了
とある。
それで今、僕は業務でスクラムマスターをしているのだけど、その視点で見ればこれはびっくりするほど今どきのスクラムをやってるのである。
1つめは原始的なスプリントぽい何かだし、2つめは今見るとプロダクトバックログをカンバンで管理するのと事実上変わらない事を言ってて、今どきのアジャイルで採用されている各手法とエッセンスとしては大して違いはない。もちろん細部は違うけど。
スクラムとの大きな違いはウォーターフォール型の開発を念頭に置いていたことだ。だって当時はアジャイルといえばXPが出てきたばっかりで、東芝のような大企業が採用するようなものとはみなされていなかった。東芝が社内でアジャイルを採用し始めるのはこの10年くらい後の話である。
で、アジャイルは基本的に反復型開発を前提にしていて、1スプリント内で設計も実装もテストもやってしまうことを想定しているけれど、僕のこの提案手法はそうではなかった。ただ、設計やって実装やってテストやって、という長大なプロセスを何ヶ月もかけてやったとしても、設計工程も実装工程もテスト工程もブチブチに短く切ってしまって、短い間隔でsessionとworkを交互に繰り返すことで管理すれば良いと考えた、ようだ。当時の僕は。
長いプロセスをかけて作った場合の要求とと成果物に大きな意識のずれが生じるのが問題だと僕は考えていたので、間を細切れにして、その都度話し合いをして齟齬を修正してなくしてやればいいのでは、って考えた、ようだ。資料を見返すと。
当時バックログもカンバンも知らなかった（てか、バックログって当時なかったかも？）のに、ワイやるやん。筋は全然悪くなかったやん。
……などとつい自画自賛してしまうと同時に、自分みたいなのが独立して考えても同じような思想に行き着いたのだから、結局ソフトウェア開発は、同じ問題意識を持つ人間が真面目に考えたら誰でも今どきのスクラムのような形になったのかもしれない。
そういう意味では、現代のスクラムはそうなるべくしてなっているのかも。
僕はこの発想は当時出てきたばかりのアジャイル開発ではなく、梅棹忠夫氏の京大カードをソフトウェア開発に応用できないか、という辺りから着想したようだ。ソフトウェア開発で発生する課題とそれを解決するためのコミュニケーションを円滑にするために使える、と当時の僕は思ったらしい。
というので、関連書籍として京大カードの本を置いておく。
あと京大カードは直接関係なかったかもしれないが、一緒に当時読んでたカードに関する本。部屋を整理したときに一緒に出てきた。
でもボロボロだったので、捨ててさっきKindleで買い直した。
青山幹雄先生の訃報に際して
遅まきながら、南山大学の青山幹雄先生がお亡くなりになったのを今知りました。
訃報連絡（故 青山 幹雄 南山大学理工学部ソフトウェア工学科・教授）
私は大学院生のときに先生の著書を読んで感銘を受けたのが、先生とお付き合いすることになった最初でした。
それで私がぜひその御本で扱ってるテーマで修論を書きたいと当時の指導教官だった米澤明憲先生に言ったら、米澤先生が青山先生に直接話をしてくださったようで、当時青山先生がおられた富士通研究所にしばらく修行で通わせてもらえることになりました。
（当時はインターンという制度は日本では全く一般的でなく、当然富士通研にもそんな制度はなく、異例中の異例の対応だったと思います）
そのときから、「せっかくお世話してあげたのに東芝行っちゃった今井さんね」なんて軽口を叩かれつつも、何だかんだずっと同じ分野で20年以上お付き合いさせていただきました。
今私が深く関わっているMLSE（機械学習工学研究会）も、元はと言えば2017年のSESで先生がオーガナイズされたパネルセッションに感銘を受けた私が、感想をFacebookに投稿し（これ）、そのリプライ欄で意気投合した人達が立ち上げたものです。
理論的なものを志向しがちな私と違って、先生はもっと、ソフトウェアと社会、あるいはソフトウェアと人間との関わりを志向する方で、研究的興味が何もかも同じという訳ではなかったのですが、それでも私の研究者人生には、この20年で何かしら常に示唆を与えてくださる方でした。
訃報を先程知ったばかりでまだ実感が湧いていないのが正直なところですが、今はただ心より追悼の意を表したいです。
ベッドから起き上がれなくなっていた男が完全復活を遂げた話
びっくりすることに1年半ぶりのブログです。どんな文体で文章書いてたかももう思い出せないレベル。
というか、ここ1年くらいSNSに顔を出す頻度が激減してました。
たまに出てきたと思ったら虚無なツイートをしたりして、もしかしたらご心配してくださってた方々もいるかもしれません。
今日はそのへんの話をしてみようかと思います。端的に言えばタイトルにある通りなんですけど、自分でも未だに信じられない体験をしました。
自分の身に起こっていたこと
実は、去年の夏頃からまともに仕事が手につかなくなってしまい、秋に1ヶ月半ほど休職してました。
元々睡眠障害を抱えているため昔から体調は崩しがちではあったんですが、でもそれまで全く経験したことのないような症状にずっと悩まされていたんです。
主だった症状は、極度の疲労でした。とにかくだるくて眠い。
日中、仕事しようと思って机に向かっても、10分もしないうちに身体中がだるくなって、辛すぎて椅子に座っていることすらままならない、という日々がずっと続いていました。
勤め先は元々フルリモートでの勤務がOKな上にコロナ禍の影響もあって、2020年になってからはほぼ家にこもって在宅で仕事してたんですが、椅子に座ってられないので、ベッドやソファに寝転がってMacBookで仕事する、なんて日も少なくありませんでした。
でも、そのうち寝ながらの仕事すらもできなくなり、ただ辛くて転がってるだけ、起き上がるのも厳しい、といった日が増えていきました。
流石に会社からも心配されて、メンタルクリニックにも相談に行き、結果、しばらく休職することにしました。
休職中、とにかく何もせずひたすら休息していたら、それなりに疲労が取れてきて動けるようになったので、1ヶ月半くらいで一応復職しました。
ところが、仕事部屋で机に向かっての仕事を再開して何日かすると、また同じような症状に見舞われ始めたんです。
何とか無理して働いてましたが、どうしても成果が出なかったり、何日も休まざるを得なかったり、という日々が続きました。
妻の助言で○○○をしたら治ってしまった
ある日、ふと気づくと、休職前よりももっと症状が悪化していました。
ベッドの上で身体を起こすのも辛いし、酷いときは思考が鈍りきってて何も考えられない、ただベッドに転がっていたら1日終わってた、みたいな状態の日もありました。
で、流石にまずい、と思ったんです。これじゃ仕事ができないどころか、まともな社会生活すら送れないじゃないか、と。
そう思って、とりあえず外に散歩くらい行こう……と思ったんですが、その日はベッドから動けず失敗。
次の日、自分ひとりでは無理だと思ったので、妻に一緒に散歩に行こうと誘ったんです。
それで何とかベッドから起き上がって、リビングにまではたどり着いたんですけど、そこからどうしても外に行けませんでした。
3時間くらい粘ったんですが、どうしても無理だったんです。
そんな折、その様子をずっと見ていた妻が、見かねて、こう言ったんです。
「そんなに外に出るのがツラいなら、代わりにそこのベランダに出て陽の光でも浴びれば？」
あぁそれならできるか、と思い、すぐ横の窓を開けてベランダに出ました。
既に夕方4時くらいで日は傾いてましたが、いい天気で、お日さんも照っていました。
それで、そのベランダに置いてある椅子に腰掛けて、ぼーっと空を眺めてました。やっぱり身体中がだるくて、手足が重いなぁ、って思いながらだったのを覚えています。
ところが。
いつの間にか、その手足の重さが感じられなくなっていました。
それどころか、なんか気分まで軽くなってたんです。
不意に、仕事しようかな、と思いました。 それで、ベランダにMacBookを持ち込んで、お日さんの下でカチャカチャやりはじめたんです。……何の問題もなく、普通に仕事できました。
結局、日が沈む6時前くらいまで、正味2時間弱の間ベランダにいたんですが、それですっかり元気になってしまいました。
さっきは3時間粘っても外に行けなかった男が、その後普通にコンビニに買い物に行ったりしていました。
あれだけ苦しんだ身体のだるさは雲散霧消していました。
あまりに劇的な変化に自分でもびっくりして色々ぐぐってみたんですが、どうもIT系の人は慢性的な日照不足の人が多いらしく、なので、SEがなる鬱の多くは日光浴で治るらしい……みたいなことを書いているページがいくつか引っかかりました。
本当にそうなのかは素人なのでよくわかりません。僕が掛かっていたメンタルクリニックの医者は、まさか日光浴だけでそこまでの効果があるとは、と驚いていましたし。
ただ、気づいたんですが、僕がリモートワークのとき仕事部屋に使ってた部屋はほとんど日光が入らない部屋だったんです。
で、仕事に熱中してると、ほぼその部屋と寝室を往復するだけ、みたいな日も多かったんです。
寝室は、本来は午前中に陽が入るんですけど、当時はカーテンを1日中閉め切っていたので、日光が差し込むことはありませんでした。
なので、考えてみると確かに、ほとんど日光を浴びないで過ごす、という日々が何日も続いていたんです。
それ以降、相変わらず家で仕事していますが、仕事部屋は使わず、日光の入るところを求めて家の中を移動しながらMacBookで仕事するようになりました。寝室のカーテンもずっと開けていて、なので朝は日の出とともに起きる感じです。（最近日の出が早すぎて5時前に起きるんですが）
だるさは時折あったんですが、それも、10分間日光浴をすれば消えました。あまりに簡単に消えるので、さすがにプラシーボか何かか、と思わなくもないんですが……。
そのうちだるいと感じること自体が少なくなっていって、今はほとんどだるさを覚えることはなくなりました。
というので、現在はめちゃくちゃ元気に仕事しています。
悩みといえば、ちゃんとしたワーキングチェアに座らず、色んな所で胡座かいたりしながら仕事してるんで、以前より肩が凝るようになりました。
あと、毎日日光を浴びているせいか、最近お肌が焼けてヒリヒリしています。
MLSEの来年に向けた取り組み
この記事は、機械学習工学／MLSE Advent Calendar 2019の25日目の記事です。
最終日ということで少し趣向を変えて、技術の話ではなく、MLSE（日本ソフトウェア科学会 機械学習工学研究会）の現在の取組みに関する話を書こうと思います。 なので、書く場所をQiitaでなく自分のブロクにしてしまいました。
僕はMLSEの立ち上げメンバーの1人ではあるんですが、特に夏頃からまたMLSEへの取り組みを本格化しました。
というのは、自分から見てMLSEの色々な課題が見えてきたからです。
特にそれがはっきりしたのが、今年7月に行われたMLSE夏合宿2019でした。
今年の夏合宿に参加して
夏合宿に参加して、参加者といろいろ話して気づいたのですが、1年以上前と変わらない課題意識を抱えてる人が沢山いたのです。
たとえば、
機械学習プロジェクトの標準的なプロセスを定めたいですよね。
といったコメントなど。
私たちは研究会として正式に発足する前、2017年の11月頃からずっと活動しているのですが、このようなコメントは2017年も、2018年の第1回ワークショップでも聞かれたものなのです。
新しい発見が出ないと前に進まない独自研究ならともかく、こういった活動は誰かが着手すれば進むのですが、みんな「欲しい」「やりたい」と言うものの、実際に手をつける人がいなかったわけです。
また、少し関連しますが、MLSEに参加を希望する方はすごく多いのですが、実際に自ら研究して成果を発信する人の数が少ないな、という印象もありました。これは僕だけではなく、数人のMLSE運営委員からも聞かれた話です。
MLSEは、各々が研究した成果を発表し合う場を提供する、というのが本来の趣旨です。もちろん分野の裾野を広げるために、自ら手は動かしていないが興味を持って情報を仕入れに参加する方もwelcomeなのですが、ただ情報をgiveできる人がまだまだ少なく、情報をgiveする人とtakeする人のバランスが現在非常に良くないのです。研究分野が機能するためには、もっと自らの手で研究する人が必要です。
今年の夏合宿は特に論文の査読なども行わなかったこともあり、発表された研究の成熟度・完成度は非常にまばらでした。研究成果を発表してくださる方を増やすには、発表の数を増やして裾野を広げることも重要ですが、質も重要です。これは我々がきちんと担保していく必要があります。
ワーキンググループの設立へ
先ほどのような問題はひとえに、現在の我々MLSE運営の至らなさだと思いました。
昨年、立ち上がったばかりの研究会に非常に多くの方に関心を持ってもらい、たくさんの方に参加してもらったので、どこか慢心というか、勘違いしてしまっていたのだと思います。
まだできて2年目なので、自ら研究してアクティブに参加してくれるプレイヤーが少なくて当たり前だったのですが、そこに気づかず、ただ発表の場だけを用意すれば勝手に色んな人が発表しに来てくれると思いこんでしまっていました。
ですので、単なるイベントの開催だけをやるのではなく、年間を通じて継続的に研究をサポートしていく必要があると考え、WG（ワーキンググループ、作業部会）を設置することにしました。
そして、いくつかのテーマを元に、複数の方に幹事になっていただくべく声をかけさせていただき、結果、3つのWGが発足しました。
- プロセス・事例収集WG
- システム基礎WG
- 本番適用のためのインフラと運用WG
詳細はこちらに書いてあります。
来年の夏合宿
そして、来年の夏合宿についても、実施内容に色々手を加えました。（あ、僕は実行委員長に立候補しました。）
既にCFPが公開されていますが、こちらでもう少し動機づけのあたりを掘り下げて書いていこうと思います。
最近、特に機械学習関連分野の研究はarXivやストリーミングの普及もあって、新しい研究の情報はオンラインですぐ共有されます。ですので、特に国内学会が研究集会を開催する意義が昔とかなり変化している、あるいは変化させなければならないと僕は思っています。
それは僕が思うに、オフラインで交流するメリットを活かした、まだ活字などの形にならない萌芽的な研究やちょっとしたプラクティスの情報、あるいは課題意識を、参加者の間で共有し、議論することです。
ですので次回の夏合宿は、論文を募って発表してもらういわゆる研究発表会と、皆で議論をするワークショップのハイブリッドを目指すことにしました。
今まではシングルトラックで1泊2日の合宿だったのですが、マルチトラックで2泊3日とし、分厚い内容にしようと思っています。
このうち、セッションの企画を提案してくださる希望者には、（もちろん実行委員の審査の上ですが）好きなテーマ・内容で1セッションの運営をお任せすることにしました。（以下のフォームで募集しています。）
なお先ほどご紹介したWGからはそれぞれセッションの提案が義務となっていますので、これらのテーマのセッションは必ず開催されます。
一方、投稿してくださる論文の質の向上を促すため、今回からPC委員会を設置し、厳正な査読を行うこととしました。 採択本数よりもクオリティを重視し、夏合宿に採択されることがこの分野でのステータスにしてもらえるようになったらいいな、と考えています。
おわりに
ということで、MLSEまだ2年目（最初期の活動からは3年目）ですが、これからも色々活動内容をブラッシュアップして、この新しい分野の発展に寄与していきたいと思っています。
ぜひ、これからも奮ってご参加頂けると嬉しいです。
『Practical Developers』読みました
技術評論社様から献本いただきました。ありがとうございます。
![Practical Developers ――機械学習時代のソフトウェア開発[ゲームアプリ/インフラ/エッジ編]](https://images-fe.ssl-images-amazon.com/images/I/517cfsnY5VL._SL160_.jpg "Practical Developers ――機械学習時代のソフトウェア開発[ゲームアプリ/インフラ/エッジ編]")
Practical Developers ――機械学習時代のソフトウェア開発[ゲームアプリ/インフラ/エッジ編]
- 作者: 飯塚健太郎,大川徳之,keno,古賀理,田中一樹,徳永拓之,西田圭介,森田和孝
- 出版社/メーカー: 技術評論社
- 発売日: 2019/08/09
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
献本されたからとか、筆者に個人的にゆかりのある人が多いからとかではなく、純粋に、読んで面白かったです。
僕は（ご存知の通り）機械学習工学研究会（MLSE）なる、機械学習システムをどう構築するかっていう工学を考える研究会にどっぷりかかずらわっているんですけども。
この本のサブタイトルが「機械学習時代のソフトウェア開発はどう変わったのか」になっていて、まさにこの、機械学習工学的な興味に照らしてどんぴしゃな内容だったわけです。
6章を7人が、それぞれの経験を元に色々書いていて、目次見たときはもっと簡素な事例集かと思ったんですけど、各章非常に中身が濃く、そこいらではなかなか得られないような気づきも多く含まれた、非常に良質なプラクティスの塊だなぁという印象を持ちました。
ということで、本当に純粋に、機械学習工学に興味を持つ人、機械学習を使ったソフトウェアの開発に興味を持つ人にオススメしたい本です。
以降はもう少し詳細に語っていこうかなと思います。
全体的な話
面白いと言うか、よくこんな構成にしたなと思ったのは、6章あるうちの3章がクラウドサービス構築に関する話、でもう3章が、よくエッジAIとか言われる、小さいデバイスでディープラーニングを走らせる話に関連した内容になってることです。
両方とも機械学習が関わってるとはいえ、興味を持つ人が分断するんじゃないかなと。前半しか読まない人とか後半しか読まない人とか出そうで、本を企画する側としてはどういう気持ちでこうしたんだろうな、などと思ってしまいました。
あと、各章それぞれの執筆者に自分の開発環境がどうなっているか（使っている計算機、モニタ、エディタの種類、etc.）を書かせてるのが地味に面白かったです。
読者にとって役立つ情報かどうかはわからないですが、みんな他人がどういう環境で開発してるかは気になりますよね。
1章 ゲームアプリ『逆転オセロニア』の開発
個人的には非常に読ませる内容でした。改めて思ったんですけど、ゲームって機械学習のアプリケーションとして向いてますよね。
機械学習って確定的な出力結果を期待できなかったり、リコメンドシステムみたいなものだと返ってくる結果が合ってるのか間違ってるのかも定かでなかったり、という意味で、ロジックをバッチリ組むビジネスアプリケーションと相性が悪いところがあるんです。
そういう点で、ゲームというのはプレイヤーの満足度をいかに上げるかっていう感性が全てなので、開発者もそういうモードで接しやすいと言うか。
そのためか、非常に機械学習を使いこなしてるなぁ、という印象を持ちました。
機械学習モジュールに周辺のシステムをすり合わせていくような開発過程など、一般的なアプリケーションの開発でも参考になる点は多いと思います。
2章 Indeedのインフラ構築
こういうのを、最近国内では MLOps と呼ぶようになりました。
機械学習システムの運用をどう円滑に進めて、そのためにどういうインフラを構築しなければいけないか、など。
この方面は、エンジニアの人達はさかんに勉強会を開いたりしてるんですが、残念ながらアカデミックにちゃんと研究してる人が少なくて、国内ではゼロに等しいのです。
海外ではOpMLなんて国際会議も開かれたりしてるんですけどね。
この章を読んで頂ければわかるんですけど、本当に機械学習関連のインフラ周りは奥が深いようで（僕は普段タッチしないので間接的に聞いてる話でしかないですけど）やはり多くのエンジニアが興味を持つのでは。
3章 フィンテックでの大規模データ処理の自動化
こちらも2章に比較的近い話なのかな。フィンテックと書いていて、具体的なサービス名などは明らかになってないようですが。
いやー、こちらも僕は専門外ではあるんですけど、奥が深そう。すごくマニアックなことを色々書いていて、ちょっと感動しました。ファイル名の名前の付け方で日付が後ろのほうがいいとか、非常に細かい話が書いてあります。
このdockerやAirflowに特化した話を、他社の人がどれだけ参考にできるかわかりませんけども、筆者がどうしてこういうことを考えたのかな、という思いを巡らせると、いろいろ得るものは大きそうな気がします。
タスクを冪等に設計する／しないなんて話は、そういうこと考えるんだ、というちょっとした感動が個人的にはありました。
4章 Ideinの深層学習のエッジ推論高速化
はい、私の勤め先です。
執筆者の大川さんは会社で私の隣りに座っている人なので、なので開発環境が書かれているとおりになっているの、ここだけは自分で確かめられました。
これも身内贔屓じゃないんですけども、非常に内容が濃いですよね。
大川さんとか、その他Ideinエンジニアがよく議論していることが本当にそのまま書かれていて、結構太っ腹だな、とか思ってしまいました。
ぜったい他社の人も参考にしてほしいって思うことも書いてるし、依存型モリモリ使ったHaskellの型検査が遅いとか、他社では絶対参考にならんやろ、とか思う情報もふんだんに載ってますけど。
まぁ、大川さんは普段こんな細かいことを意識しながら開発してるんだ、っていうのをぜひとも汲み取ってほしいです。
あと、2章のIndeedのところで「計算資源のコストより開発コストを下げる方を優先」って書いてあったんですけど、このIdeinの章を読めばそういう富豪的な開発はエッジ向けには採用できないということがわかっていただけると思います。どちらが間違いとかではなく、やはり製品・サービスごとにトレードオフがあるということですね。
5章 TVM
ここだけは、うーん、僕はあまり面白いと思えなかったです。森田さんごめんなさい。
というか、ここだけノリが違いません？ 他は製品なのにここだけOSSってのもあるかもしれないですけど、他は製品をどう作るのかって話が主眼なのに、ここはTVMそのものの紹介しかしてないと言うか。
どちらかというと、森田さんにはTVMを開発する上でどういう苦労があるかとかをもっと密に語ってほしかったかな……あるいはTVMの中の人じゃなくて、TVMをサービスに組み込んでる AWS SageMaker Neo の中の人に、TVMをどんな工夫を凝らして組み込んでいるかを語ってもらうとか。中の人英語だろうけど。
国際的なチームによるOSS開発ならではの苦労とか、色々あると思うんですけどねえ。
僕自身がTVMに少なからず関わっていて、この章の内容はほぼ既知の内容だったってので面白さを見いだせなかったのかもしれないですけども。
6章 LeapMindでのFPGAとか量子化とか
はい、私の以前の勤め先です。
だからというのもあってか、ここは多分他の人と僕は読み方が違っていると思います。あー徳永さん育児休暇取ってたんだ、とか。
Blueoilのワークフロー書いてましたけど、あれ、それlmnetじゃない？ dlkはどうなってるんだろう？とか。
（僕は在籍時、dlk開発のリードとかしていました）
まぁそんななので、フェアに書けることが割と少ないんですけど、ただエッジAI開発であっても学習環境が重要だっていうのは #02 あたりを読んで頂ければわかるのではないですかね。
僕がいた頃からLeapMindには優秀なインフラエンジニアの方がいまして、彼らがみんなの開発を支えていた面が多分にありました。
おわりに
改めてですけど、これは非常におすすめです。開発で機械学習使ってたり、機械学習プロジェクトに関わってたりする人は読んでみるといいのでは。
続編が読みたいかというとそうでもないんですが（この内容で十分おなかいっぱいになれる）、機械学習工学研究会をやってる人間からすると、これを踏み台にしていろいろ研究する人とか出てきてくれないかな、と思ったりします。
