本を読書する技術

概要

Money Forward Kyoto Advent Calendar 2020の5日目、バックエンドエンジニアのluccafortでお送りします。

adventar.org

このエントリは読書する習慣を身につけるテクニックを紹介するエントリになります。 読書によって得られた知識は経験を媒介することで誰にも盗むことができない財産になります。 皆さんの財産が世の中のマネーをフォワードする一助になるとよいと思い、このエントリを書かせていただいています。

結論から

まず結論から。 このエントリは以下の書籍から得られたことや試したもの、読書を継続するのに重要そうな要素を抽出したものとなっています。

ですので、もし興味があるかたはこれらの書籍をお読みになられるほうが早くより正確だと思います。 ぼく個人としてもそちらをおすすめ致します。

学習効率のよい読書術を求められているかたは↓がおすすめです。

エンジニアの知的生産術は難しくてわかりにくかった、というかたには↓がほどよいかと思います。

想定される読者層

  • 読書が苦手なひと
  • 読書習慣がなく、身につけたいと考えているひと
  • ただ読書をするだけの状態を打破したいひと

発端

以前とある雑談の際に「いつそんなに本を読んでいるんですか?」という質問を受けたことがありました。 (おおよそですが、技術書で月に1〜2冊、一般書籍や自己啓発めいたものを含めると月に5〜10冊ほど読んでいます。読んでいる数そのものは決して多くないです。)

ぼくだけに向けた質問ではなかったのですがそのときたまたま「よく本を読む人」と「あまり本を読まない人」が半々くらいにわかれていて、「何故読書するのか、また読書する習慣を身につけるHowToにも価値がある」という気づきを得ました。 そのうちブログに書いてやろう!と思っていたところ、アドベントカレンダーでチャンス到来したので書かせてもらった、というのが発端です。

ぼく自身は決して読書の虫というわけではないのですが、それでも比較的本を読む習慣があるのでいわゆる「読書を楽しむことができる人間」側に属しています。 そこで現代社会の時間が限られた人間が本を読む時間を捻出するために実践しているいくつかの技術を紹介したいと思います。

前提条件

ここでいう読書とは読むことで「何かしらの知識を得られること」を前提とします。 ですので、娯楽小説などは後述する方法で読む必要はありません。 自分の読みたいように読んでいただいてよろしいと思います。

なんのために読書するのか?

まず本を手にとった、あるいは購入した理由を考えましょう。 なにを期待して本を手にとったのでしょうか?

なにか現状を変えること、あるいは変える可能性を期待して手に取るかたが多いかと思います。 その当初抱いたゴールを付箋やホワイトボード、ブログ……etc 媒体は何でもよいですがしっかりと言語化しておくことでより深く、脳がゴールを意識し効率がよくなります。

またゴールをしっかりと明確にすることで漫然とただ読むことを防止する効果があります。 可能であれば読書する前後でゴールが確認できるようになっているとよりよいでしょう。

ぼくはホワイトボードにカンバン形式でいま読んでいるもの、次に読もうとしているもの、読んだものを管理しています。 (カンバンがわからないかたは下記のwikipediaをご覧ください。)

ja.wikipedia.org

他にも制約として1ヶ月の間に買える技術書は3冊まで、ただし読了した技術書2冊につき追加で1冊購入できる…という縛りを課しています。 これらの管理や制約によって読む技術書の冊数や読みたいものをコントロールするようにしています。 ただこれはぼくにとって最適化されている手法なので人によっては合わないです。

他にも挫折してしまうケースとして、購入した書籍によっては自身が望むレベルに達していない、あるいは難解過ぎるということがあります。

そのようなケースで無理をして読む必要はありません。 いま読んでいる本はゴールに向かっているか?読書の前後で振り返りができるようになっているとレベルがあわなかったときの気づきを得るきっかけを作ることができます。

何故習慣化させるのか?

まれに勘違いされるかたがあるのですが、本をたくさん読むことが大事なのではありません。 本を読むことでゴールを達成することができるのであるかどうかが重要なのです。 その結果としてたくさんの本を読むことはあるかもしれないですが、たくさん読むことが目的化しないように注意しましょう。 大事なのは量を増やすことではなく、質を高めることです。 質を高めるのに量が必要でなければ量は必要ありません。

いつ読書するのか?

いつ読書するか?これは難しい問題です。 というのも読書する習慣がついているかたごとに「いつ」が異なるからです。

一例としてぼくの場合ですと以下のときによく読書しています。

  • 駅や電車、病院などの待合室
  • 休日の昼間、なにも予定がなくゆっくりしたいとき
  • お風呂に入っているとき

読書する習慣がないかたはあらかじめ本を読むルーティンを決めてしまうことをおすすめします。 読書する時間を決める、というよりは「就寝する30分前に読む」「通勤電車の中で読む」などの何かしらのアクションをトリガーとして読む時間を確保すると続きやすいです。

このとき「毎日22時から1時間読む!」としてしまうとできなかったときにネガティブになったり、 義務感になってしまい疲れてしまいます。

仮に今日は5分しか読めなかった、というケースでも問題ありません。 30分だけ読もうと思ったがもう少しで読み切れるので5分延長するなど人間は思った以上に時間にルーズです。 ですからゼロにさえしなければ習慣化され、ストレスなく読むことができるようになっていくでしょう。

まずは2週間、可能であれば1ヶ月続けてみましょう。 途中どうしても時間を確保できず中断してしまったとしても問題ありません。 できる範囲で習慣化していきましょう!

何故1ヶ月か?についての根拠は以下のTEDにおける動画が非常にわかりやすく、やる気を促してくれるのでおすすめです。

Matt Cutts: マット・カッツの30日間チャレンジ


マット・カッツの30日間チャレンジ

ただし可能なら1週間以上間を空けるべきではありません。 個人的な経験による確信ですが1週間やらなかったことは脳内で「やらなくてもよいこと」として認識されてしまうように感じています。

読書しても忘れてしまう…

読書しても前回から間が空いてしまって忘れてしまうことはないでしょうか? ぼくはよくあります。

忘れてしまうこと自体は決して悪いことではありません、ありませんが良いこととはいいがたいですよね。 特に読書した内容についてであれば、なおさらです。

忘れたくて忘れているひとはまれだと思うのでどうすれば忘れにくくなるのか?というアプローチを紹介します。

脳は「2週間に3回使った情報は、長期記憶される」という性質があるそうです。 これは冒頭で紹介した「学びを結果に変えるアウトプット大全」の中で「アウトプットの基本法則1」で紹介されている内容になります。

面白いのは1度きりだと2週間でも1ヶ月でも大きな差がなかった、という結果がでているそうです。 (1週間と2週間では明確に数値が違うのに!)

ぼくは基本属性が怠け者なので予定として抑えておかないとすぐに怠けてしまう傾向があります。 そこで本当に大事で忘れたくないと考えているときは同じ本の特定の章だけでを初日、7日後、14日後の3回読むようにしています。 翌日にはその次の章を、更に翌日にはその次の次の章を…という感じで特定の章だけを読む日を設けるようにしています。

可能であれば2週間後にこのインプットした情報をブログでもノートでも付箋紙でも構わないのでなにかにアウトプットするとより高い効果が見込めます。 これも「学びを結果に変えるアウトプット大全」の中でアウトプットの基本法則2として紹介されている内容となります。

インプットの反復だけではなくアウトプットすることでより強固に「脳にこれは重要な情報である」と教える必要があります。 機械学習は詳しくないですが仕組みとしては強化学習と同じだと考えています。

まとめ

完全に自己啓発する怪しい話になってしまった気がします。 「読書する」ことはスキルで補えます。

昨今だと「努力するものは楽しむものに勝てない」という論調があります。 これ自体は事実であると思いますが、努力することは無価値ではなく、それどころか素晴らしいことです。

楽しめるようになるために努力していくというアプローチもあるでしょう。 本を読書する技術を身につけることで「努力する」から「楽しむ」ことができる一助になるとよいなと思い今回アドベントカレンダーに参加させてもらいました。

本は買うことに意味があるのではなく、本を読み、知識として取り込むことで価値を最大化します。 この知識には「知らなかったことを知る」ことや「自分がわかっていないことがわかった」ことも含みます。 もちろん本に書かれた内容が全て理解できる必要はありません。 いままで認識できなかったことが認識できればそれは十分に読書の価値を得られていることになります。

最後に宣伝

マネーフォワードでは福利厚生の一環として「書籍購入補助制度(まねふぉ図書館)」というものがあり、理由が常識的なものであれば同じ書籍を複数冊購入してもよいという非常に嬉しい制度があります。 このおかげで輪読会や読書会なども活発に行われているのではないかと思います。

その他にもさまざまな福利厚生や制度があるので気になるかたはこちらを御覧ください。

corp.moneyforward.com

この話をみて興味を持っていただけたかたは是非カジュアル面談などでお話をしてみてください!お待ちしてまーす!

マネーフォワード京都開発拠点のサイトがあります。 もし京都拠点に興味を持っていただけたらこちらもみていただけるとよりぼくらを知ってもらえるのではないかと思いますので、年末のお供にご利用ください。

kyoto.moneyforward.com

明日はマネーフォワード京都でインターンをしてくれている Ken さんのインターン生から見た京都拠点のお話です!お楽しみに!


今年も本家アドベントカレンダーもやっています!

adventar.org

京都アドベントカレンダーはこちらです。

adventar.org

京都開発拠点では引き続き積極的に採用を行っております。ご応募お待ちしております!

マネーフォワード京都開発拠点

kyoto.moneyforward.com

中途採用 | 株式会社マネーフォワード京都開発拠点

kyoto.moneyforward.com

インターン | 株式会社マネーフォワード京都開発拠点

kyoto.moneyforward.com

GopherCon2020の個人的注目ポイントなどを抜粋してみた…の巻。

TL;DR

先日社内で↓のようなエンジニアブログを書くので協力お願いできませんか?という話があり「よっしゃ!!!」と二つ返事をしたところ、思った以上の量になってしまった。 会社ブログのほうは抜粋されたものが掲載される、ということだったのでより詳細なものは個人ブログで書いてしまおう、ということになりこっちでも個人的なGopherCon2020の「これは聞いておきたい!」と思ったものを勝手に紹介していきます。

moneyforward.com

あまり意識したことはなかったけども、RubyKaigiやPHPConferenceなどの大きなカンファレンスに参加するときは無意識に「これをみる、何故ならこういうことが知りたいから」みたいなメモを書いてることが多い事に気づきました。 まあこれはあとでブログ書くときのネタにするため、という側面が強いけど。

GopherCon2020で何を得たいと考えているか?

期待することとしては大きくエンジニア視点で3つ、個人として2つ。

Goに対する理解を深める

どういう課題を解決したいのか? 何故そうなったのか? その背景はなにか?

これらを理解することで実際に自分たちがそれらの言語仕様を使って何かを実装するときにとり得るアプローチに差が出ると思います。 知識の補強、そして背景への理解、よりよい最適解への道筋などの知識理解度を深めることを期待しています。

GopherConに参加することを通してMF内でGoのプレゼンスを上げる

マネーフォワードの京都開発拠点では主に同僚が主体となって活動してくれていますが やはり世間一般のエンジニアにとってマネーフォワードといえば?と聞くとどうしてもRuby/Railsなイメージが強い。 それ自体は悪いことではないけどマネーフォワード内外におけるGoの存在感をより光を当てていく。 それによって今後あとに続くひとが社外だけでなく社内からも増えることを期待して、その一助になればと考えています。

そもそもGoが好き

Goの何が好きか?と言われると返答に困るのですが、普段Ruby/Railsを書いている反動なのか型があり、無用なところで議論が発生しにくいGoという言語が好きです。 また簡潔に書きやすいところが個人的に気に入っています。 テストがrspecに比べて愚直になる傾向があるのでそこはもう少し頑張ってほしいなと思うことはありますけどね! (↑同僚から炎上しそうだから消したほうがいいかも、と言われたw)

海外のカンファレンスに参加する敷居を下げる

ぼくは頭が良くないので英語に対してどうしても苦手意識があります。 いままでは現地にいくしかなかったわけですが、言葉が通じないという不安がつきまとうので敬遠してきた過去があります。 ただ今回、飛び込む機会を得られたこと、日本にいながらにしてイベント参加ができることでだいぶ心理的ハードルが下がりました。 これが契機になって次回以降海外カンファレンスにも臆せず参加できるようになれば、知識の吸収する場がグンと増えるのでそうなるとよいなと期待しています。

英語学習に対するモチベーションのブースト

前述しているように英語が苦手です。 得意だ!というかた以外は概ね賛同いただけると思うのですが、英語学習ってとにかく続かないですよね。 モチベーションの維持がしにくく、また日本国内で生活していると上達具合もなかなか体感しにくいです。 以前知り合いのエンジニアが「海外カンファレンスに行って英語が全く聞き取れなかった、悔しい」といってその悔しさをバネに1年後カナダへ留学するほどの熱意を発揮していました。 留学がしたいわけではないのですが、人間お尻に火がつかないとなかなか頑張れないので、そういう意味で発破をかけていきたいと思ってます。

ぼく的GopherCon 2020の見どころ

本題です。

TOP3 in GopherCon 2020 all days

まず結論から。

  • Day1の「Write Once, Use Many: A Simple & Useful Package to Call Internal APIs」
  • 同じくDay1の「Reordering 59 Million New York Times Publishing Assets Using Go and BadgerDB」
  • Day2の「How to Write a Self-Hosted Go Compiler from Scratch」

全日程を通して特に期待しているのは上記3つになります。 理由は後述してありますが、これら3つのセッションはタイトル、そして説明をみているだけでワクワクしてくるものがありました。 他にも魅力的なものはあり、悩んだのですがどうしてもTOP3を選べ、と言われたらこうなるかなと。

以降、各日程ごとに期待しているセッションTOP3を記載しています。

Day1(11月11日)

Typing [Generic] Go

f:id:luccafort:20201105003525p:plain

いままでRob Pikeの思想によって散々議論されてきたGenericsがついにGoに採用される。 これは今までのGoの世界にとって大きなパラダイムシフトになり得る、そういう意味でみんなが注目しているだろうけどもぼくもやはり注目している。

Write Once, Use Many: A Simple & Useful Package to Call Internal APIs

f:id:luccafort:20201105003710p:plain

正直なところタイトルで釣られた感があるが紹介文をみてより強く興味を引かれたのがこのセッション。 実務として使うことが予想されるInternalなAPI、それをシンプルに書き、拡張や保守を容易にしている、という文言に自分が今後作る、あるいは保守をするサービスに活かせる知識を知る、あるいは補完することができるのではないか?と期待しています。 (自社の素晴らしいパッケージ紹介で終わってしまう、という可能性を少しだけ危惧しています、少しだけね!)

Reordering 59 Million New York Times Publishing Assets Using Go and BadgerDB

f:id:luccafort:20201105003811p:plain

世界でも有数の記事データ量を誇るNYT、その5900万件のイベントをどのようにしてメモリ内で並べ替えたのか?というセッションのようなのでこれはMFという巨大データを抱える我々にとってもよい教訓が含まれているのではないか?ということで期待しています。 BadgerDB というのは寡聞にして聞いたことがないので軽く調べたのですがGoだけで作られたKeyValue型のDBのようです、これがどう活かされているかはセッションの中で語られることでしょう。いまから楽しみです。

https://github.com/dgraph-io/badger

Day2(11月12日)

Deterministically Debugging Go Programs

f:id:luccafort:20201105003902p:plain

あまりGo開発者にも知られていないデバッグの簡単&パワフルなdelvesについて、そのエレガントな問題解決を紹介してくれる、ということでGoビギナーなぼくにとって知りたい&実務で役立つ知識になりそうと判断しました。 効率の良いデバッグを知ることは効率の良い開発が出来ることにつながるので期待しています。

Pardon the Interruption: Loop Preemption in Go 1.14

f:id:luccafort:20201105003941p:plain

Go 1.14では、スケジューリングとガベージコレクションのためにゴローチンが先取りされる方法が大幅に変更された、ということでその詳細から言語仕様、設計思想、ベストプラクティスを学べる機会だと感じたため、恐らく難解であることを覚悟で聞きたい!と思いました。

How to Write a Self-Hosted Go Compiler from Scratch

f:id:luccafort:20201105004038p:plain

タイトルをみてメルカリのDQNEOさんだ!と気づいてしまったやつ。 DQNEOさんはPHPを書かれていた頃からウォッチしているエンジニアの1人であり、今回登壇されると知って絶対に聞きたい!!!と思っていたので当然聞く。

それだけではなくGoのエクスパートでもコンパイラのエクスパートでもないDQNEOさんがGoでコンパイラを実装し、そこから得た学びとは何なのか? それはぼくにとってもエンジニアとして還元することが出来るものではないか?というエンジニアとしての成長につながるなにかがあるのではないか?と期待しています。とても楽しみ。

Day3(11月13日)

Functional Programming with Go

f:id:luccafort:20201105004114p:plain

関数型プログラミングが現実問題をどう解決するのか、関数型プログラミング特有の概念をどうGoで表現するのか?を理解することを期待。 Ruby/Rails(OOP/MVC)とは思想からして異なるのでいまいちど原点に立ち返るのはよいかもしれないと考えたのが理由です。

Working with Errors

f:id:luccafort:20201105004228p:plain

プログラミングはエラーとの戦いだと思う。 そのエラーについて過去の経緯やどうあるべきか、なども含めて知ることが出来る貴重な機会。 紹介文をみていると丁寧にエラーについて話す予定のようなのでそれだけでも価値があると考えました。

Optimizing Performance using a VM and Go Plugins

f:id:luccafort:20201105004241p:plain

みんな大好きパフォーマンス改善! Goにぼくらマネーフォワードが期待することの1つにパフォーマンスの向上があります。 だが如何に言語のパフォーマンスがよくても実装したコードが駄目だと無用にパフォーマンスを劣化させてしまう。 そこでこのセッションで避けるべき実装、真似るべき実装を学ばせてもらう。

まとめ

ここであげた以外にも気になるセッションはありましたが全日程で3つ、各日程ごとで3つという縛りを課して選んでみました。 業務に近い、あるいはエンジニアとしての成長につながるだろうと感じられるセッションが多く選出された傾向を感じています。

逆にインフラやSREな領域のようなセッションへの興味は薄めだったかなと感じています。 興味はあるけどあまり前のめりじゃない、そんな雰囲気でした。

さて、初めての海外カンファレンス!(オンラインだけど)に参加できるというだけでいまからワクワクしてきますね。 当日が楽しみです!!!

よければ皆さんもGopherCon2020で期待している内容をブログに書いてみませんか?!

地道にご当地コミュニティーを運営していたら知らない間に紹介してもらえて報われた

2020年10月17,18日に開催していたGDG DevFest 2020のLT大会でぼくらが運営しているKyoto.goが「日本のGoコミュニティ活動状況 [2020年10月版]」として紹介されました。

www.slideshare.net

正直なところ東京やUmega.go、Fukuoka.goなどに比べてまだまだGo力が低いのが京都の現状だと思います。 低いからこそ継続が大事だなと思い、月2回(第2、第4水曜日開催)を初期に決めて定期的に行う、というように運営した結果が報われたなと感じて嬉しくなりました。

これもひとえに参加してくれるかたがいるから続けられたことだと感じています。 1人しか参加者いなかったら泣いて途中でやめちゃってたと思う。

これからもっと良くしていきたい、もっとGo力をあげていきたい、Goを通してKyoto.goという場が成長につなげていきたいなどなど思うところは諸々ありますが今後もやっていきの精神で継続していこうと考えています。

日付的には変わってしまったけど今日でuber-go/guideの輪読会は完走になりました。 次回は TheAlgorithms/Go で実際に手を動かしながらアルゴリズムの復習と実装をやっていこうと考えています。

よければご参加ください。

github.com

来月のイベントページはこちら。

kyotogo.connpass.com

kyotogo.connpass.com

気づいたら3ヶ月くらいブログ書いてなかった。

割とブログを書くネタはいっぱいあったんだけど忙しかったり、会社のテックブログ(みてね!)を書く方に注力していたら全然個人のブログを書いてないことに気づいた。

moneyforward.com

以下、雑に直近やってたこと。

  • 技術書典9にまねふぉ執筆陣として「まねふぉテックブック」に寄稿しました。

techbookfest.org

  • とある事情でGoを2ヶ月くらいみっちり書いてました。大変だったけど楽しかった。この辺の話は会社のテックブログに経緯とかその成果とかをそのうち書こうと思ってる。

  • Kyoto.goを細々と毎月2回くらい開催している。いまはUber社のGoガイドを読む輪読会している。

  • ISUCON10予選に出場したがほぼなにもできずに敗退してしまった。この話はもう少し落ち着いたらブログにするかもしないかも。

  • 知り合いの Nkzn に頼んでフロントエンドの勉強会&ハンズオンを開催してもらった。テックブログに経緯とかも書いたので良ければどうぞ。

moneyforward.com

  • ヴァイオレット・エヴァーガーデンを観た。最高に美しいストーリーだったので観てない人は早くみるのだ!

  • Fire HD 8 Plusを買った。思ったより純粋のAndroid OSと違ったりアプリがなかったり(Youtubeとか)で結構面倒だなと思って早くも公開し始めてる。

  • 星を継ぐものを読んだ。これはいい名作SF。

  • Go言語による並行処理を読了した。並行処理について少し知識が身についたが体得したとはいえない状態なので実際にコード書いて覚えていく必要があるかなって感じてる。

  • PS5争奪戦に敗れて今年中に手に入らなそうだったのでヨドバシでGoPro9 Black買って徳を高めた。

みたいなことをしてました。 他にも多分いろいろやってて書けることはあるんだけど書きすぎてもダルいし時間がかかるので今日はこれくらいにしておく。

ねんがんのアルトサックスをかったぞ!

TL;DR

アルトサックス買った。 お金が吹っ飛びました。 練習する場所なくて困ってます。

駄文

SELMERというメーカーのAXOSというモデルのアルトサックスを買いました。

www.nonaka.com

↓のエントリが去年の7月なので音楽教室に体験入学してからだいたい1年くらいで楽器を購入したことになる。

luccafort.hatenablog.com

本当は3ヶ月前の2月末に通っているサックスのレッスン教室の先生に購入したい旨を伝えていたのでそこで選定→購入となるはずだった。 ……がちょうど世間でコロナが騒がれていた時期で小学校や中学校が休校になったり、企業もリモートワーク推奨したりで世間がワチャワチャした結果、レッスン教室自体も休校になってしまい、伸びに伸びてしまいました。残念。 まさか3ヶ月も時間が立つとは思ってなかった。

その後、休校明け一発目にもう一回選定おなしゃす!ってリクエストしてようやく購入ということに相成った。 ところでレッスン教室に一緒に通っていたかたが退校されたそうで、コロナの傷跡は現在進行系で日本経済を蝕んでいるなと実感しました。 選定にはYAMAHAのサックスが3本、購入したSELMERの楽器が1本あって普段練習でレンタルさせてもらってるのが一番安くて今回買ったのが一番高かったです。

選定のときにまず自分で吹き比べてみたところ

YAMAHA 練習で使ったタイプ→普通、いつもと変わらん

YAMAHA ちょっとお高いタイプ→めちゃくちゃ吹きやすい!

YAMAHA 持ってきてもらった中ではお高いタイプ→少し吹きにくさを感じるがサックスらしい音

SELMER 持ってきてもらった中で一番高いやつ→指だとかマウスピースだとか諸々違いすぎて音がまともにでない!

みたいな感触でした。 この段階で①と③は選考から落としていて買うなら②か④だなと考えていました。

理由としては②は吹きやすく扱いやすそうに感じたこと、自分は初心者なので扱いにくいとすぐに挫折するのではないか?という不安から。 ④は単純に一番吹きにくかったが慣れの問題っぽかったので慣れれば一番音色が綺麗で好みに感じられたから。

その後、先生がそれぞれのサックスを吹き比べてくれたんですが率直に↑の2本で考えていることとその理由をお伝えしたら「じゃあ④がいいですね」と言われて即決しました。 JEUGIAのAPEXという管楽器?などを専門に扱う部署で買ったのですがレッスン教室自体がJEUGIAさんで行われているため、生徒割ということで1割ほどお安く買えました。

JEUGIAの店員さんからは「同じモデルでも個体差があるので日を改めて複数お持ちして吹き比べますか?」と言われたんだけど自分がその違いを理解できるとは思えないし それがわかるようになったと言えるならサックスを始めた当初のレベルはクリアしてるだろうと思ったこと、いつまた自粛で買えなくなるかわからなかったので

「これでいいです、正直多分個体差とかわかるレベルにないので!」

といって購入しました。「デカい買い物なのにそれでいいのか……?」みたいな店員さんと先生の感情が透けて見えた気がしました、が気にしない。

ということで念願の自分のサックスを購入することができましたチャンチャン。

で、まあ楽器が手に入ったら練習したくなるじゃないですか? なので家で試しに軽く吹いてみたらめちゃくちゃ音がデカくてびっくりしました。

普段レッスン教室は防音なので音がだいぶ吸収されてるんだなってわかったよね。 あと、いまグループレッスンで参加しているので一人だと、レッスン時は出来たつもりになってたところが全く出来てなかったことが判明して(´・ω・`)って気持ちになります。

ベルと呼ばれる部分にタオルぶっこんで試してみたりしたんだけどほとんど変わらなかったので吹奏楽の人たちは一体どこで自主練していたのだ…って気持ちになりました。

ということで世の中はいろいろ大変だし、多分どこかのタイミングで第2波・第3波が来るのは避けられないと思ってるんだけど そのときに心の栄養が取れるようにだけはしておきたくてサックスを購入したよ!という自慢話です、えっへん。

楽器がようやく手に入ったので頑張って練習していく所存です。 鴨川で「週休7日」Tシャツ着て下手くそなサックスを練習してる人がいたら90%くらいの確率でぼくです、よろしくでしょでしょ。

やっていくぞい!!!

初めてのGraphQL

TL;DR

いつもの読書ログです、読了しました。

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

この本を読むことで得られる期待値

  • GraphQLを採用するメリット・デメリットが理解できる
  • 何故GraphQLが開発されたのか説明できる
  • 自社プロダクトに組み込むと想定したときに具体的にどこで効きそうか、あるいはどの辺りは効かなさそうか判断できる
  • GraphQLいくつかのAPI共通で利用される機能(ファイルアップロード/ダウンロード、ログイン/ログアウト、アクセス権限制御など)をどう実装するか
  • N+1問題などのフロントエンドがクエリを組み立てることで発生する問題にどう対処するのか?

以下、感想

GraphQLはデータのあり方をクライアントサイドから再定義することで従来のサーバーサイドが行っていた不可侵領域を崩した。 これは今までサーバーサイド側の責務だったデータ設計がクライアント主体になることでクライアント側の問題を図る意図があった。

これは画面設計を行うときにデータ設計の不備が見つかることがあったので割と納得感がある。

書籍で明言されてなかったと思うがGraphQLはクライアント・サーバーサイドのどちらかに責務を寄せるのではなく、柔軟なレイヤーを一枚挟みたかったのではないかと思う。 その柔軟なレイヤーを共有することで責務がレイヤーという抽象化された概念に集約され、結果としてインターフェイスとしての責務が明確になる、みたいな。 …というようなことを読みながら考えていた。

反面、クライアントからみたデータ設計になるため、いままでとは異なる問題がサーバーサイドで起こるのではないか?という懸念をこの時点で抱いている。

GraphQLは「クライアントとサーバーサイドのパフォーマンス向上」と「データ構造の要件を満たす解決策」を目指して開発された。 つまりこれによって副次的にクライアントの開発速度が向上することが見込まれたり、エンドポイント管理の複雑さから開放される、というようなことが期待できる。

ただ結局のところ、最も目指したかったところはパフォーマンスの向上、そのためのデータ構造のユビキタス化なのだろうと思う。

GraphQLによって以下のような状態が解消されると書籍では紹介されている。

  • 過剰な取得、user.name がほしいだけなのに user.* が取れてしまうみたいなやつのこと。
  • 過小な取得、今度は逆に user が持つアイテムが知りたいだけなのに inventryfavoriteitemみたいに複数回リクエストしてしまうみたいなやつのこと、らしい。
  • エンドポイント管理の煩雑さ、RESTなサービスの難点の1つにRoutingがあると思う。GraphQLではエンドポイントは単一なので管理そのものが実質的になくなるためこのURLは実態を表すのに相応しくない、というような喧々諤々な言い合いがなくなる。

書籍内では「GraphQLはただの仕様(Specific)だ」と紹介されている。 これはクライアントとサーバーの仕様を定義するものでしかなく、アーキテクチャのようなものではないと理解している。 その分根本的な解決には難しいケースがありそうだと思う反面、取り入れやすさ(変更しやすさ)があるのだろうと理解した。

GraphQLのクライアントはサーバーサイドとはまた別に目的があるらしい。

  • 開発チームの作業効率の向上
  • アプリケーションのパフォーマンス向上

この2つが主となる目的だと書かれていた。 それを実現するために「ネットワークリクエストデータのキャッシュ」、「ユーザインターフェイスへのデータ注入の肩代わり」が行えるようになっているそうな。 (そういえばユーザインターフェイスのデータ注入の肩代わりって具体的にどういうことだったんだろう?)

GraphQLには大きく分けて2派閥あってRelayとApolloというフレームワークがあるが書籍ではApolloを使われている。

そもそもGraphQLの特性とはなにか? 元々グラフ理論というものがあり、その文脈として「グラフは多くのデータを必要とするアプリケーションと相性がいい」と書かれている。 有向グラフ、無向グラフあたりで調べると良いかもしれない。 書籍にも簡易だがイメージがつくようにわかりやすい紹介があったのでグラフ理論の名前を聞いたことがない、あるいは名前しか知らないという人でも安心して読めると思う。 少なくともぼくはそうだった。

GraphQLには大きく3つの機能がある

  • Query(取得)
  • Mutation(更新)
  • Subscription(購読)

わかりやすくいってしまえば

QueryはSQLにおけるSELECT文のことだし、 MutationはINSERT/UPDATE/DELETE文のこと。 SubScriptionはデザパタにおけるPubSubのこと。

ゾルバはDBだけを参照するものではない。内部APIや外部APIから受け取ったレスポンスなどを返すことができる。 だとするとクライアントがクエリを組み立てるのに懸念があるケースはDBモデルではなく専用に用意したリゾルバを参照されることで実装的には内部APIを叩いて負荷の少ない実装結果を参照させることができるのではないか? →後述される複雑さ(complexity)で解決しようぜ!って言われてたのでこの対応は筋が悪いのかもしれない。でも以前みた GraphQLでWebAPIを作っているでは graphql-batch 使え!みたいな話があった。これはそもそもの比較がおかしいとは思うんだけどリクエストさせない対応が複雑さで、とはいえN+1発生するようなリクエストって起こり得るよね!ってときに使う解決策が graphql-batchなのかなーって思いましたまる

patorash.hatenablog.com

mutation時にバリデーションエラーが発生したらどうするのだろう? →明確な答えは書かれていなかったがGraphQLにおけるエラーハンドリングの仕方を読んだ感じ 200 OKを返しつつmessageにエラーメッセージを詰める……みたいな対応するしかなさそう。

techblog.zozo.com

GraphQLにおけるテストは通常(既存)のテストと同じでよいのか?それとも気をつけることがあるのか? →特にテストへの言及はなし。pockeさんが書いてくれているGraphQLのクエリを自動的にテストするというのが参考になりそう。エンドポイントが1つしかないので今までと同じ……というわけにはいかなさそう。

qiita.com

トリビアルゾルバを最上位に追加するという説明で最上位にズラズラ書いてしまうのは嫌だなーという気持ちになり、なんかでまとめられないかなーとか思ってた。 →これに関しても言及がなかったけど多分探せば何かしらあるはず。

GraphQLでDatetimeはどう扱われるのか?タイムスタンプ?それとも文字列? →カスタムスカラー型を定義しましょう、と書籍で紹介されていたのでそれ読めばよい。

GraphQLでファイルのアップロード/ダウンロードが行えるのか? →結論からいうと行える、どうやるかについては書籍内の7章で言及されているのでそこ読めばよい。

apollo clientのキャッシュはデフォルトローカルに保存されると書いてあったが保存可能な最大サイズはどれくらいか?またそれはどこに保存されるのか?キャッシュ先をRedisなどに指定することは可能なのか? →明言されてないがどうにもInMemoryっぽい雰囲気。ただlocalStorageなどを指定もできる?という感じではっきりしていない。Apolloの公式ドキュメントをあたるのが良さそう。

apollo clientのキャッシュはページ遷移しても有効なのか?失効するタイミングやそのコントロールはどうするか? →InMemoryだと仮定して話すとページ遷移してもなくならない(はず)。失効するタイミングやコントロールに関しては書籍の7章に記載があるのでそちらを参照すればよい。

fetch policy: cache-onyってどういうときに使うもの?キャッシュがなければ例外が投げられるということだけどキャッシュがなかったら普通はリクエストしてデータをみにいくものじゃない?どういうケースのときにこれを使うことがあるの? →Queryコンポーネントなどをキャッシュする(サーバへの問い合わせがいらないもの)のときに使われる、ということだった。これも書籍に記載されている。

まとめ

基礎の基礎は理解できたと思う。 いくつか細かい疑問などはあるのだけどそれは実際に触ったり公式ドキュメントを読んだりしていけば解消しそうだなという気がしています。

この書籍ですが非常に読みやすい日本語だったことと、イメージの説明の仕方がうまいなと感心しながら読んでいました。

この書籍を読んで期待することのうち4/5は達成されたと思います。

N+1問題などのフロントエンドがクエリを組み立てることで発生する問題にどう対処するのか?

これに関してはもう一度↓のエントリなどを読み直して情報を整理しようと思います。 恐らくそれでほぼほぼ疑問に思っていることは解消するはず。

employment.en-japan.com

patorash.hatenablog.com

マネーフォワード 京都開発拠点からこんにちわ

前回のブログエントリから2ヶ月近く経過してしまった。 やってることとしてはそんなに何か大きなことが起こっていたりはしない。

Railsのコード書いたり、バグ対応に追われたり、普通にエンジニア・カイシャインしている。 カイシャイン・プリキュアは月曜の朝に死ぬ。

近況報告

近況でもないんだけどマネーフォワード 京都開発拠点に2020年1月からサーバーサイドエンジニアとして勤務してます、いえい!

本当は試用期間が終わったあとにブログエントリでも書こうかなと考えていたんだけどちょうどその前後で担当しているプロダクトのリリースがあったり今回のコロナ騒動があったりでなんかいろいろワチャワチャして書くのを後回しにしていました。

POが書いてたエモい記事がこれ

note.biz.moneyforward.com

実際に社内で使ってもらったあれこれの感想はこっち

note.biz.moneyforward.com

ちょうど面接を受けたのが年末の12月で活動し始めが11月の中頃。 内定をもらえたのがちょうど12月中旬だったので本当に1ヶ月くらいで転職活動から内定までのスピード転職でした。 ちなみに何社か受けたけどマネーフォワードが今回の転職活動の記念すべき1社目でした、なので最速で終えられたって感じです。

いまGoogle Calendarを確認したら

転職活動開始が11月の3週目 マネーフォワードの面接1回目が12月1週目 マネーフォワードから内定もらったのが12月3週目

でした。 マネーフォワードの面接1回目から内定までがだいたい2週間くらいなのでだいぶスピード感ある転職活動だなって感じです。

前職楽しそうにしてたのになんで辞めたの?

前職のトマルバを辞めた理由はいくつかあるんだけど一番大きいのは自分のメンタルが病んだから。 理由としては自分で「やらないといけない!」って抱え込んでしまってパンクしたって感じ。

こういうと仕事しすぎ?ってなるけどそうじゃなくて、なんか強迫観念的な状態で誰かに任せるとかの逃げの行動ができなくなっちゃってた。 抱え込んだまま仕事して失敗して、そして自分は駄目なやつだもっと頑張らないと!でも行動が伴わなくて結局自分で自分の心を殺してしまうみたいなわけがわからない状態になってた。 CTOのtangoさんと何度か話して最初は休職してから復活する予定だったんだけど、ぼくの精神状態とか諸々考えるとOffの日に会社のことを気にしないみたいなことは難しそうと言われた。 ボク自身もそう思っていたし、辞めたくないので休職という選択肢が取りたかったんだけど、結局休職から戻ってきても根本的な部分が変わってないから問題の先延ばしにしかならんなという結論になり、期限を切ってそれまでに返答する……ということで期限締め切り日を幾日か過ぎたあたりで辞めることを伝えた、みたいな経緯です。

トマルバという会社自体はとても好きだし、そこで働く人たちもとても好きです。 オフィスの京町家はめちゃくちゃエモいので京都に来る機会があったらぜひ利用してほしい。

ホテルに泊まるよりもいい体験ができると思う、お値段がその分高くなってしまうので4〜5名で泊まるといいかもしれない。 ホテル業界なのでそのあたりの業種を絶賛募集しているのでもし興味がある人がいたら応募してくれると元社員として嬉しい。

www.wantedly.com

マネーフォワード@Kyoto に入ってから

マネーフォワードに入社する以外にも選択肢はいくつかあったんだけど(その中にはライバル会社のfreeeさんもあった、最終的に技能面談で落ちたけどw)一番いいオファー条件を出してくれていたこと、元々Kyoto.rbなどで現職のボスである 谷口さんを通していろんな情報を意図せず吸収できていたのでそのあたりの安心感もあって入社することに決めました。

候補の1つにはてなさんがあってぼくにとってはある種の憧れみたいなものがあって受けるか随分悩んだ(入社できるかどうかは別として)んだけど最終的に「受けない」という選択肢をした。 恐らく成長という意味でははてなのほうができたのかな?と思う面がなくはないんだけど、それよりも自分がそこで働くという具体的なイメージが持てなかったので受けないという選択をした。 onkさんやdaiksyさん、他にも何人もはてな社員のかたを知っているので文化的なミスマッチは少なそうだったのでそういう意味では少し残念ではある、武者修行的に社会人留学生制度をそのうち京都のはてなさんとマネーフォワード京都拠点でできるといいのかもしれないなーとか少し考えたりすることがある、これは以前にonkさんが似たようなことを仰ってていまくらいならリリースもできたしこちらとしての体制が整いつつあるのでできるかも、という気持ちでいる。

さて、マネーフォワードに入社した経緯はもしかするとそのうちマネーフォワードのテックブログやnoteに書くことがあるかもしれないので割愛するとしてマネーフォワードに入って行った大きめのことを紹介していく

Money Forward Techbook #2 のまねふぉ執筆陣に参加した

Money Forward Techbook #2 のこと。しかも何故かトップバッターになっててウケる。

マネーフォワードが技術書典で書籍を出しているのは知っていたのでそれに参加したいなーみたいな雑談をしたところ、執筆陣(実態としては部活)のチャンネルを紹介してもらえた。 個人的には技術書典8にはもう間に合わないだろうから、秋頃にある技術書典9から参加したいなーみたいに考えてたら「じゃあ書きますか!」となって入社後2週間くらいで執筆陣入りしていた。

めちゃくちゃ焦った上に締め切りがそこそこ近かったので大変苦労した、チームメンバーにはそのせいでリリース間近なタイミングで迷惑をかけてしまったなと今にして反省している。 でも次回も参加する予定だけどね!テヘペロ

1月6日入社で17日に執筆陣チャンネルで「こんにちわこんにちわ」してたわ、圧倒的スピード感!!!

マネーフォワード クラウド会計Plusのリリース立ち会った

まあリリース直前にジョインしただけでなにかしたって言えない気もするけど微力ながらリリース前の駆け込み時期にスケジュールを遅らせることなくリリースまでこぎ着けたのは偉業なんじゃないか?って思ってます。 偉業なのでKyashとかで39円ください、皆様の温かいお気持ちお待ちしてます。

f:id:luccafort:20200517175915j:plain

京都開発拠点は実質お金稼いでるプロダクトがまだこれしかない状態なので稼ぎ頭です。 やれること、やりたいこと、やらないといけないことまだまだいっぱいあるので興味ある人は下のほうに会社の宣伝おいておくので連絡ください。

ちなみにぼくのブログを読んでいても特に加点とかないですし、別にぼくにリファラル紹介料はいるわけでもないです。

フルリモートに移行した

コロナ騒動で意図せずではあるのですが完全リモートワークに移行しました。 そら社員はそうだろ!って人もいると思うんですがなんとインターン生やお仕事を手伝っていただいているパートナーのかたも含めフルリモートする体制になっています。

出社するひとがいるのか?については京都開発拠点には1人もいないです。 オールフルリモートです、これはPOである杉浦さん(Not エンジニア&Not デザイナー)も含んでいます。

たまーに冷蔵庫の中身や会社においてある書籍を取りに行くひとが月に1回あるかないかくらいの頻度です。 でも仕事はいまオフィスではしてない状態です。

フルリモート、ぼくはあまり好きじゃなくて、週2回くらいまでが許容範囲かなーと思ってます。 そんな中フルリモートになったのでPCとか私物のやつだとスペック落ちちゃうなぁ…と思ってたら「今回は緊急時なので」という特例で会社PCを家に持ってお仕事できています。 MacBook Pro 16インチ 64GBなので潤沢にメモリ使えてハッピーハッピーです! ✌✌✌✌✌

反面、家においていた技術書をオフィスに移動させたところだったので手元にほしい技術書がなくてたまーに困ることがあるくらいです。 基本的に業務に関係しそうな書籍に関しては持ち帰ったので大丈夫のはずではあるんですがふとしたときに手元になーい!ってなることがあります、仕方ないね。

元々京都拠点はリモートで働くかたが何名かいらっしゃってそこで課題がいくつかあったのでいろいろ試したり、スクラムで開発しているので誰がなにしているのかがわかりやすかったり、モブワークでタスクを進める実験的な試みを行っていたなどの経緯もあり、課題はありつつもスムーズに移行できました。 このあたり前職でリモートワークしていた知見を共有して「とりあえず試そうぜ!」と声を上げた過去の自分を褒めたいです、よくやったな!

ちなみに拠点で勉強会をすることがあるんだけどそれもいまはフルリモートで行ってる、意外となんとかなるもんだ。

お金扱うんだからガチガチなんじゃないの?

やったことじゃないんだけどたまに質問されるので答えておく。 正直自分も入る前は金融系SIerみたいな堅苦しさがあるのかと思ってました。 いくつかの点でどうしても堅くせざるを得ないものはあるけどそれも必要最低限って感じに収まってます。

例えば……

セキュリティー的な点でカフェで仕事する!みたいな自由さはない。 これは扱うデータの特性上認められないので当然だと思ってる。

会社PCを持って帰る、これも上記のセキュリティー案件でNGです。 リモートワークするときは申請してリモートワーク用のPCからアクセスしないといけません。 ただし条件があえばワークフローを提出することで持ち出し可能。 今回のコロナ騒動は特例的にワークフローすらなしで持ち帰りOKでした、杓子定規な対応ではなく柔軟に対応してくれて非常に助かりました。

自宅から会社にアクセスするのにVPN繋がないと駄目。 「いまどきサーバはAWS/GCP、外部からもガンガンアクセスされるしVPN不要でしょ!」という向きがあるのは理解しつつもぼくらの扱うデータの特性上これは看過できないです。 ということでVPN不要なソリューションを提供していただける最高に優秀なエンジニアカモン!

でも、その他に関してはいろいろな人が苦心してくれてるおかげで非常に自由度高い状態を維持してもらってます。 この点は入社前とあとで印象が180度違う好例ですね。

そういう働きやすい職場をいろいろ苦心して作り上げてくれているのがすごくわかるので 入社してすぐに知り合いのエンジニアに1人声をかけました、よく考えるとこれ人生で初のリファラルかもしれない。 手放しでうちよいよ!って言えたのはいまのところマネーフォワードだけ。

だいたいあなたには来てもらいたいが満足するオファーが出せない、という理由でいままでリファラルの紹介をしたことがなかったりします。 お金、お賃金の話でいままでいた会社を手放しで知り合いに紹介するのは厳しかったですね。 その点マネーフォワードはメルカリやLINEほどの高給は難しいかもですが、東京水準での給与は保証できる会社なので安心して提案できます。

まとめ

他にも細かい話でいうと

  • 社内勉強会が充実していること
  • オフィスの環境、特に京都拠点は贅沢
  • ランチに鴨川散歩できてエモい
  • 社内チャレンジシステムがあること(POの杉浦さんが経理からジョブチェンジしてる)
  • POがドメインエキスパートなので優先順位が明確
  • いろいろなバックボーンを持ったエンジニアやデザイナーが揃っている

みたいな話があるんだけどなかなか伝えきれない文化の面なのでテキストだと難しいです。 そういうYoutubeチャンネルとかあると面白いのかもしれないけど……どうかな?わからん! 特にぼくはやりたいと思わないので、やりたい有志がいればやってくれるんじゃないかなきっと。

あえていままでブログで明言はしていなかったんだけど本当によい会社だと思っている。 話す内容は尽きないんだけど濃厚、濃密な3ヶ月を経て、ステップアップのための3ヶ月に突入したなと思っています。 今後もよりよいプロダクト開発のために邁進していく所存でござる。

なお、環境が変わったからかチームメンバーの影響なのか精神面でまいっていたのが 入社1ヶ月後の1on1で自分に対する評価を聞いてからほとんどなくなった。 自分ができなくてもチームのみんなが頼れるって気持ちになれたのがぼくには良かったのかもしれない。

元々は2〜3ヶ月くらい転職活動しながら精神を整えられるといいなと思ってたんだけど 逆に忙しく、はっきりとした目標に邁進していたのが余計なことを考える時間を減らしてくれて結果としてよかったのかもしれないっていまは思ってます。 そういう意味でもリリース直前、直後に関われたのはいいタイミングだったのかも。

ただの会社紹介で終わってしまったけどまあそんな感じで楽しく働いてます。 あと何故かマネーフォワードに入ってから以前までは1mmも上がらなかったLAPRASのスコアが微増しています。 書いてるコード量はむしろ減ってるし、技術的な難易度もどちらかというと前職のほうが高かったはずなのに……何故? (推測としてはレビューしているユーザとレビューされているユーザの数が何かしらの係数になっててそれで増えてるのではないかと疑っている)

会社の宣伝

会社の紹介資料はこちら

www.slideshare.net

京都拠点の紹介はこちら

moneyforward.com

京都拠点の求人はこちら、いまメインで募集している職種はRails/Goのエンジニアなんだけど他にこういうことがしたい!って人がいたらまずはカジュアル面談とかで希望を伝えてもらえるともしかすると東京や福岡、ベトナムなどの他の開発拠点をお伝えすることができるかも。 ただ京都にいるけど他拠点のエンジニアとして働く、みたいなのはいまの体制だと厳しい(いまは逆にフルリモートになったからそういう人にはチャンスかも)

www.wantedly.com

www.wantedly.com

www.wantedly.com