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

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

しがないラジオ sp #79 場外乱闘編

TL;DR

2月頭にゲスト@2周目として収録してもらったエピソードが公開されたのでshow noteには書いたけど話さなかった内容をつらつらと書いておく。

場外乱闘編

以下、話してないこと

coinhive「プログラムはウイルス」2審は有罪判決

  • 時事ネタなので入れた。
    • rebuild.fmでよくある時事ネタを真似てちょうどその前日に判決がでていたので時間か興味があれば話すネタによさそうだなと思ったので追加した。
  • 体感でいうなら「なんじゃそら」という不当な判断と言わざるを得ない。
  • 一方でそれだけではなく合理的に判断し、その結果今回残念な結果になったっぽいという現状を踏まえるといまぼくらが扱う環境に大いに影響がでそう。

趣味

  • 去年の夏くらいからサックスはじめた。

    • はじめた経緯はブログに書いたので興味あればどうぞ。
    • サックスやり始めたあたりからYoutubeみるようになった
      • サックスの技法や練習方法をみることが多い
      • たまに京都橘高校吹奏楽部の動画みたりHapa英会話みたりしてる
      • 最近困ったらYoutubeで検索してることがあり、youtubeは大変便利なツールなのだなと10年ぶりくらいに理解した。
        • と同時に昨今の動画コンテンツの隆盛を実際に自分がユーザになることで体感した。めちゃくちゃ便利。
  • 人生初TOEICの模擬試験した

    • 385点でめちゃくちゃ笑った、伸びしろしかないやつ(白目)
    • スタディサプリ(リクルート)が不満はありつつも教材として必要十分
      • やっていて楽しい
      • こういうちまちま単語帳倒すのがレベルあげのためにスライム倒すみたいで割と飽きずにやれてしまう性格
    • よく知ってる単語はリスニングでも脳内でシュッと紐付けできるけど脳内メモリに乗ってない単語は何度も聞き直さないとわからないということがわかった。
    • ディクテーションという問題が結構楽しい。頭と耳をそれぞれ鍛えられる感じがしており楽しい。なおわからない単語と綴りは何回やってもわからなかったりしてレベルの低さを実感する。

漫画アニメゲーム枠

  • 空挺ドラゴンズ@アニメ
    • 存在しない龍という幻想生物の味を想像してお腹が減る
    • フードポルノアニメ
  • ブルーピリオド@漫画
    • エンジニアに憧れていたときのことを思い出して悶そうになる
    • はくどーさんに勧められた8等分5等分の花嫁はまだ読めてない
  • リングフィットアドベンチャー@ゲーム
    • 買えない……頼む、買わせてくれー!!!
    • ちなみに社員の自己紹介のときにリングフィットアドベンチャー買うか悩んでるっていったら社長に笑われた

kyoto.goコミュニティーを作ったった

TL;DR

三行で説明すると

  • Umeda.goが休日開催で厳しい
  • Kyotoにもご当地Golangコミュニティーがほしい
  • ないので作る

という流れで「KyotoにもUmedagoみたいなコミュニティーほしー!」ってTwitterに投稿してから 1週間で爆速キックオフイベントを開催して無事クロージングできたという話をします。

当日のまとめ

kyoto.goコミュニティーのページはこちら

kyotogo.connpass.com

当日のイベントの告知ページはこちら

kyotogo.connpass.com

活動内容ログはkyoto.rbのscrapbox活用がめちゃくちゃ気に入ってるのでそれを参考にした。 kyoto.go のscrapboxページはこちら

scrapbox.io

基本的にはScrapboxにまとめてあるのでそちらのログを眺めるとなんかやっとるな!という雰囲気がつかめると思います。 でもまとめだけみても1000%理解するのは無理。

scrapbox.io

0次会で決めたこと

  • 毎月第3週の水曜日の19時に開催すること
  • 形式としては1枠20分で前後半の2枠で行うこと
  • 最後に10分で当日イベントの振り返りを行う
  • 時間は1時間+ 30分
    • 30分はグループ換えの時間やトイレ休憩、クロージング作業などで発生するバッファ時間を考慮

キックオフイベントで成し遂げたかったこと

まず主催者としてやりたかったことがいくつかあって

  • 「変化することは絶対的に正しい」というはてなismな思想をコミュニティーの中心に据えたかったこと
  • 誰かに依存するだけのコミュニティーにはしたくなかったこと
  • kyoto.go の骨組みを作り上げる

幸いにして概ね期待したことは決められたなと思っていて、あとは文化の問題なので継続的に持続させるように頑張っていこうと思ってる。

個人的な理想像としては大学のサークルや部活をイメージしていて部長がある程度の年数で代替わりしていく循環がある組織であるとよいなと思っている。 ある程度育った人が居座り続けることもできるし、そうでなく卒業していくこともできる、なんなら戻ってくることや不意に遊びに来ることも出来るそんなコミュニティーが理想。

コミュニティーとして決めたかったこととしては0次会のアジェンダにも書いたけど3つあって

  • 開催目的はなにか?
  • 開催頻度と開催日をどうするか?
  • 定期なのか不定期なのか

を最低でも決めたかった。

幸いにして当初ぼくが考えていた「平日夜19時から、内容はディスカッション形式で20分枠*2の振り返り10分で1時間コース、頻度は1ヶ月1回くらい」とざっくり考えてたことに対して

「開催する日程はある程度固定しておきたい、そのほうがスケジュールの都合がつけやすいから」や「休日も平日もやりたい、うちのオフィス使えます」などなどぼくが考えてもいなかったことがポコポコ生まれてきて最高の体験でした。 この段階で「勝ったなガハハ!」という気持ちだった、いえーい!!✌️✌️✌️

良かったこと

  • 人徳がなさすぎたのでコミュニティー作ってからほぼ毎日引用RTとかで「人徳が毎日2づつインクリメントされている、圧倒的成長!!!」みたいなアホ発言してたら最終的に46票も投票してもらえていた。
  • リモートでtenntennさんが参加してくれた!(このあとめちゃくちゃTwitter上の反応が上がったのでインフルエンサーつよい!ってなった)
  • キックオフイベントみたいな技術的なことでないイベントに11人ものGopherが集まってくれてしかも時間通り開始できた、最高!
    • 出席率100%で初回としてはこれだけで大成功といってよいのでは?ってくらい主催者としては非常に嬉しかった。
  • 一方的にぼくだけがしゃべるということがなく、意見や疑問などがでてコミュニティーらしさが出ていた
  • 発起人特権としてイベントの最後に「振り返りだけは絶対にさせてくれ!」という強い意志を表明して受け入れてもらえるようお願い(強制)した。
    • 継続的なコミュニティー運営や意見の吸い上げ、変化を促すには振り返りは必須だと思ってるのでここだけは独裁官としての権利を行使した。
  • Twitterでキックオフイベントやるよ!ってアナウンスしたら有識者が協賛してくれそうな雰囲気になってきた

改善したいこと

  • イベントを開催するの脳内前提条件をきちんと書き出しきれていなくて「これってそもそも〜」という聞かれることが多かった。
    • 定期か不定期かはまだわからないけどイベントの開催内容に関しては継続的にブラッシュアップする場を設けようと考えているので次回は脳内条件をちゃんと書ききっておこうと思った吉宗であった。
  • 締め切り時間の想定を舐めてた
    • 正直10票いけばいいと思っていたのでTwitterの締め切りを「イベント日の前日には結果みたいよなー」と思って当日0時で設定したら「投票できなかったです……」みたいなことになってしまった。
    • connpassの応募期間をイベント日の0時に設定していたら当日に「投票できないけど参加するにはどうすればいいですか?」という問い合わせを発生させてしまった。
  • 困ったときに知り合いの人に話しを振ってしまった、ちょっと馴れ合いっぽくなってしまって良くなかった。
  • コミュニティーへの貢献のお願いとしてブログやSNSでの告知、Slackの参加などの案内を時間になったらシュッと出来るようテンプレート作っておくのが良さそう
    • 人が来るたびに会場案内とかをしてしまったけど意味ないし疲れるのでイベントの開始時点の1回で終わらせるのが最良。

わかったこと

  • 京都にもGolangをやりたい人はそこそこいる
  • みんなもっと技術的なことでワイワイできる場があるとよいと思ってくれている
  • 金銭が絡まないので主催者の負担がだいぶ少ない
  • もっと学生や若くて勢いのある社会人に訴求していきたい
  • Wifi情報がSNSに上がるのはよくないと思います!!!……ごめんなさい。
  • Twitterの投票結果と参加者のやりたいことが真逆になってて面白かった
  • プログラミング初心者枠をいくつか設けてもいいかなという気がした
    • 運営としても初心者が多いか少ないかでイベントの傾向を事前に変えることができそうなので有用そう。

まとめ

ということでキックオフイベントで概要が決まったのでなにはともあれイベントページを用意しました! キックオフイベントと違ってまだまだ猶予があるので今回のように突然で都合があわないというケースも多少少なくなるはず!

ここからが本番なのでやっていくぞい!

kyotogo.connpass.com