たにしきんぐダム

プログラミングやったりゲームしてます

キャリアと給料

生活

(自分の気持ちを整理するために考えをダンプしただけの雑文です)

日本のエンジニア達は海外に出なければいけない｜Kei というブログを見た。日本より海外の方がソフトウェアエンジニアの給料が一般に高いので海外に行こうという話

僕は今ポーランドの会社にコンパイラエンジニアとして(日本からリモートで)働いていて、コンパイラバックエンドやIDEなどの開発をフルタイムでしている。"海外" に関する話だけど上記ブログに載せられているスクショにはポーランドが見当たらないですね。

上記のブログのソースとなった Average Software Engineering Salaries by Country [2022] を見てみると、 Japan $36,024 に対して Poland $22,740 で日本のほうが200万円くらい平均が高い。実際、日本でフリーランスとしてWebアプリケーションとか書いてたときのほうが給料は良かった。

現職の待遇に不満はないけれど、英語が話せてそれなりに技術力のある自分はもっとお金もらおうと思えばもらえるのかなと思うと、上記のブログみたいなのを見ると結構刺さる。止めてくれカカシ、その術はオレに効く。

効いてしまったので、今の自分の考えを brain dump しておく

  • 海外(ってどこやねん)移住そのものに強いあこがれはない
    • ポーランド: 公用語が英語じゃないの結構きついなというのを1ヶ月住んだだけで思ったので難しそう。あと寒すぎる
    • アメリカ・カナダ: 行ったことないので分からん。バンクーバー移住している人たちを最近よく見ていて良さそうとは思うけど、移住するなら転職しないと今の給料だと餓死しそう。あと寒いの苦手なので冬は死んでしまうかも
    • オーストラリアとかニュージーランドは昔行ってめちゃくちゃ良かったので気になる。日本からの時差が少ないし比較的近いのがいいね。
    • 全体的にエアプなのでなんも分からんみたいなのがある
  • 日本に大切な人や友人が多いので、その人達とすぐに会えなくなるのは嫌だなぁみたいな気持ちが勝っている。地元最高！
  • 社交的な性格ではないので、頼れる友人も家族もいないところにいきなり飛び込むのは普通に勇気がいる。(これは移住した人たちすごいなぁと思う)
  • ポーランドに移住したらオフィスに通勤できて今より働きやすくなるとか、北米のほうが給与高いとかあるけど、仕事のために住む場所制限されたくない。むしろ気候(すごく大事)・治安・公用語などによって決めたい。
  • 今の仕事は結構いろいろ自由にやらせてもらえて気に入っているので、しばらくは現職にしがみついていそう。
  • いつか将来に転職するとして、今後もコンパイラやその周辺ツールに関わる仕事がしたいですね。
    • そう思って、最近はScalaコンパイラバックエンド(LLVM)などの仕事を始めた。
    • 以前はIDEとか作ってて、めちゃくちゃ楽しいんだけれど、開発の過程で得た知識があまりポータブルじゃない(他の言語に知識を活かせるほど抽象化できる部分がちょっと少ない)気がしていた。コンパイラバックエンド自体前から興味があったし、コンパイラバックエンドはかなり煮詰まった分野なので、そこで得た知識が他の言語でも活かせそう。
  • アメリカとかカナダでコンパイラエンジニアの仕事は(移住したいかどうかはともかくとして)できるもんならやりたいけど簡単に言うな。現職でもっと修行します。
    • まあ行動を起こさないとチャンスは訪れないのですが
    • 逆にそういう国でお金もっとたくさんもらえるけどWebバックエンド開発してもらいます。とかだとあまり魅力的ではない。
  • ところで住むなら絶対暖かくて日照時間の長い場所に住みたい。晴れの国宮崎県出身なので、その点でポーランドは厳しそうだなと思った
  • 日本の良いところはアニメ・マンガ文化がかなり日常に浸透しているところな気がする。少なくともポーランドやらではアニメ見る人増えてきてるけど、なんだかんだいってまだ好きな人が見てるって感じで、20年以上前の日本って感じな気がする

うーん考えがまとまらないけど、以下のような感じなのかな。高い給与が欲しいみたいなのは無いけど、そもそも国によっては今の給与じゃ厳しそうとかもある。

  • バンクーバーやオーストラリアなどは移住先としてちょっと興味ある
  • 日照時間が長いのが重要
  • 日本のアニメ・マンガ文化の強みは最高
  • あるけど、そこでコンパイラなどに関する仕事できないなら移住しないでいいや
  • 今の仕事は場所にとらわれないので、現職のまま移住はありだけど、給与低いのでバンクーバーは無理、オーストラリアとかはいけるかもしれんけど知らん
  • 単身移住は嫌

あなたの幸福がお金に大きく依拠しているなら金のために海外行けばいいし、異なる文化で生活した良いならそうすればいいし、そうでもないなら何が自分の幸福につながるか考えて行動すればいいんじゃないですかね(自明)

コワーキングスペース向いてない / CAMPHOR-(学生団体)良かったなぁ

生活

ここ数年フルリモートで働いている。オフィスはポーランドにあるので気軽には出社できず基本的に家とかカフェで一人で仕事してる。しかし、今住んでいる家はあまり広くなく、生活スペースもゲームするスペースも仕事するスペースもすべてひとつの空間にあるので、家で仕事しようにもリラックスしすぎてあまり集中できない問題を抱えている。

何度かコワーキングスペースに登録するのを何回か(正確には過去に5回)やったことあるけれど、あまり良い体験を得られず1-2ヶ月足らずで退会するというのを繰り返している。

金額的にも馬鹿にならないし、同じ間違いを繰り返さないよう何が不満なのかとかをメモっておく。

  • そもそもオフィスに求めているのは同僚などとの雑談
    • 当然だけどコワーキングではそういうのは得られない。全然違う職種の人との会話はできるけど、内向的人間にはそういうのはかなり疲れる活動なので日常的には求めていない
  • おもむろに筋トレしたり、床に寝転がったりできない(ことが多い)
    • 飽きたときに体動かしたりしたい。申し訳程度に懸垂器があることもあるけど、なんかプランクとかダンベルしながらドキュメント読むみたいなことが奇行になるのでできない。
    • ずっと椅子に座ってるのが苦手なので、たまに態勢を変えたいのだけれど、だいたいのコワーキングスペースは椅子に座って仕事するモデルになってて窮屈。
  • 他人の通話音やでかいキータッチ音が気になる。これが一番でかい気がする。
    • これは普通のオフィスでもそうなんだけど...
    • カフェとかだとあまり気にならないので不思議。カフェは雑談してたり本読んでたりする人も多い一方コワーキングはみんなカチャカチャやってるからそういう音が余計気になるのかもしれない。
  • 高い
    • ちゃんとしたコワーキングだと月額2-3万くらいになってくるし、安いところはうるさかったり設備がしょぼかったり。
    • ビジター料金も1日で3000円とかいきがち。高すぎない???

ということで最近はカフェはしごして仕事しつつ家で頑張って仕事する感じになってる。

将来的な解決策は以下のような感じ?上2つはそのうち引っ越すので達成できるかもしれない?

  • もう少し広めの家に引っ越して、家で集中できる空間を作る(生活空間との分離)
  • カフェはしご戦略を続ける。カフェが多い地域に引っ越す
  • 信頼できる同業者とオフィス借りてコワーキング空間を作る
    • 楽しそうだけど流石に管理面倒そう

そういえば学生時代は CAMPHOR- という学生エンジニアコミュニティに所属していて、畳や縁側で寝転がってパソコンやったり、おもむろに(目立たないところで)筋トレするみたいな多少の奇行も許容される雰囲気で良かったなぁ。大学生のコミュニティなのに、ああいう部室的な空間が臭そうな感じにならずオシャレさを保っているの奇跡的な感じがする。

京都近郊のパソコン大好き学生は是非遊びに行ってみてね。

camph.net

"わたしからはじまる心理的安全性 リーダーでもメンバーでもできる「働きやすさ」をつくる方法70" を読んだ

生活

わたしからはじまる心理的安全性 リーダーでもメンバーでもできる「働きやすさ」をつくる方法70

わたしからはじまる心理的安全性 リーダーでもメンバーでもできる「働きやすさ」をつくる方法70

Amazon

www.shoeisha.co.jp

最近、id:Windymelt と一緒に Scalaわいわい勉強会という勉強会を開催した。

togetter.com

開催するにあたって大事にしたいなーと考えていたのが、コミュニティの心理的安全性を確保し、多くの人が気軽に自分の学びを共有し(つまりブログを書いたり発表したり)、知らないことがあり間違ったことを言っても大丈夫なんだという雰囲気を作りたいなと思っていた。(協同主催者の id:Windymelt くんも同じようなことを考えていたようだ)

(なので、こう言ってもらえた感想をもらえたのはとても嬉しかった)

Scalaのコミュニティというか関数型プログラミング言語のコミュニティ、ふらっと参加するには恐れ多い印象があったのだけれども*1、 これくらいのノリであれば全然次回も参加したいな〜となるくらいの感じであったな。 ... 言ってることがわからない ことと わからないと表明することを咎められない ことが両立することはとても気持ちがいい Scalaわいわい勉強会 参加した - ふんわり放牧

よく心理的安全性の誤解みたいな記事で言われるように、心理的安全性のあるコミュニティというのはぬるま湯仲良しクラブで間違ったこといっても誰も指摘しない、みたいな状態ではない。

誰もが何かを知らないこと・間違ったことを発言することを恐れることなくアウトプットすることができ、誰かが間違ったことを言っていたらそれを指摘しても良いし、意見の相違が合ったらそれを対立意見を表明しても良い、そういったフィードバックをによって良質な知識の共有をするための土壌が整っていることが、技術コミュニティにおいて心理的安全性があるということなのではないかと思う。

参照: Software Engineering at Google - Knowledge Sharing - Setting the Stage: Psychological Safety

じゃあ心理的安全性を確保するために、多少影響力のある立場で勉強会の主催として、どういうことをすればいいのかというtipsが知りたくて読んだ。

内容としては

  • あいさつをしよう
  • 笑顔で安心感を生もう
  • まずは「ありがとう」を伝える
  • 良いところに目を向ける
  • ポジティブフィードバック
  • 腕や足を組まない
  • 「いろんな考えや意見を聞きたい」と伝える

など、そうだねって感じのものが多かったが、心理的安全性ってこういう小さなことの積み重ねの上に成り立つものだよなと再認識できてよかったし、感謝などのポジティブフィードバックは積極的に表に出していこうと思えてよかった。

一方、確かに心理的安全性は、対立意見を抑制するというものではなく、間違った意見があったらそれを正すみたいなフィードバックは良質な知識共有に欠かせないものではある。しかし、日本などの儒教文化圏はそもそも対立回避的な性質が強く、公の場で間違いを指摘されることを苦手とする人も多い。

tanishiking24.hatenablog.com

また、たとえ間違いを指摘することが相手を責めるつもりが無かったとしても、言葉であなたを責めるつもりはありませんと言っても、頭ではわかっててもどうしても責められていると感じてしまう人はいる。

そういった人たちが反対意見を受け入れてまた自分の意見を表明しやすいようにするためにも、little bit や maybe といったダウングレードする言葉を使って反対意見を表明するのは良いテクニックだろう。文化が違うのだから、異なる文化でうまくいっていることをそのまま日本でも適応する必要はない。

(もちろん、そういった人たちが議論に慣れて、反対意見の表明が自分/相手を責めることではないと感覚的に理解できると素晴らしいけど、すべての人がそうあるべきと期待するのは他人に対する期待が大きすぎるような気がする。)

他の参考文献

q.livesense.co.jp

toyokeizai.net

4年ぶりのScala国際カンファレンス、Scala Days Madrid 2023 に参加しました！

tech Scala イベント

画像元: https://twitter.com/scaladays/status/1701616520546206039

Scala の世界最大のオフラインカンファレンス、Scala Days Madrid 2023 に参加してきました。Scala Days は例年に2回、アメリカとヨーロッパで開催されており、今年は Madrid での開催でした。

scaladays.org

コロナ期間中 Scala Days は開催されておらず、2019年以来4年ぶりの開催!(前回はLausanne開催でした)

developer.hatenastaff.com

会場は世界中から集ったたくさんの人で賑わい、参加者の熱意の高さから感じられるとても良いイベントでした。その中で印象に残ったセッションの紹介を交えつつ、会場の様子をレポートしたいと思います。

カンファレンス本体の話に移る前に、周辺イベントを紹介します。

Tooling Summit

Tooling Summitは、Scalaエコシステムにおけるコアツールの開発やメンテナンスに携わる人々の招待制の集まりです。サミットの目的は、Scalaエコシステムの改善のための問題やアイデアを共有し、Scalaユーザーの開発者体験を向上させる方法を議論することです。

Tooling Summit の様子

イベントのレポートはまだ公開されていませんが、以下のようなことをコンパイラチームとツール開発者で議論しました、今回の議論をもとにScalaの開発者体験を改善していきたいね。

  • The future of semanticDB, TASTy, and the overlap they have
  • Standardizing common directives (using directive の標準化)
  • Various worksheet implementations (worksheet の実装や仕様を統一したい)
  • Code coverage tooling (scoverageのメンテナ募集)
  • The state of editor support for scala-cli
  • Planning for sbt 2
  • Porting scalameta to Scala 3

(過去のレポート March 2023 - Scala Tooling Summit | The Scala Programming Language)

Scala Sprees

次に紹介するのは Scala Sprees です。これは、OSSメンテナーがメンターとなって、新しいコントリビュータのメンタリングを行い、OSSへの最初の一歩をサポートするイベントです（参加者には Scala Contributor Tシャツが配られます！）。

github.com

今回、僕は Metals のメンターとして参加しましたが、何やかやの事情があり、Scala Native のメンタリングも担当しました。当日中にはまだプルリクエストをマージすることはできませんでしたが、メンティーとして参加した人のPRは後日、無事にメインブランチにマージされました🎉🎉

github.com

イベント会場の大学の前で記念撮影 image from https://twitter.com/scala_lang/status/1702725975660748896

カンファレンス本体

Scala Days Madrid は3日間にわたり、1日目は Martin Odersky によるkeynoteとafter party、2日目と3日目は3つのトラックでイベントが進行しました。

カンファレンス中は軽食が提供されたり、企業ブースでTシャツなどのノベルティが配布されたりと、セッション以外でもいたるところで活発に会話や議論が繰り広げられていました！

https://github.com/keynmol https://github.com/lolgab 筆者 とご飯

The role of Scala in Programming Language Ecosystem

The role of Scala in Programming Language Ecosystem

  • Scala は 2004年にリリースされ、当時はOOPとFPのハイブリッドなんてありえないという反応だった
  • しかし、後発の言語などがScalaと同様な言語機能が取り入れるようになり、目新しさは小さくなってきた
  • 一方、多くの Scala や Rust の開発者が、値の変更や外部リソースアクセスの安全性のために、Rust に惹かれている
  • でも Rust は手続き型言語、Scala は関数型味を保ったまま、Rust のような安全性を取り入れられないか?

アフターパーティーの様子

GYOZA、企業ブース

Choose your own Scala Center roadmap

Choose Your Scala Center Roadmap / Scala3 の faster compilation の今後

このインタラクティブなセッションでは、Scala Center という Scala の発展を担うNPO団体の紹介から始まり、その活動と今後のロードマップについて話しました。

A Deep Dive into the Mill Scala Build Tool

このセッションは mill という Scala の簡単なビルドツールについてのお話。セッションの内容相当のブログ記事も公開されています。

www.lihaoyi.com

  • ビルドシステムはなぜ難しいのか? ビルドパイプラインは純粋関数のcomposeのようだが、以下のような質問に答える必要がある
    • どのタスクが何に依存するのか？
    • 入力ファイルはどこから来るのか？
    • 何がどのような順序で実行される必要があるのか？
    • 何が並列化できて、何が並列化できないのか？
    • タスクはどこでディスクを読み書きできるのか？
    • クロスビルドはどのように処理するのか？(ScalaのバージョンやJVMのバージョンなど）
    • ...
  • これらはとても複雑で、特定のビルドツールが特定のことをどのように行うかを学ぶために、何十ページも必要になる...
  • Mill はできる限り、何十ページものドキュメントを読まないと使えないという風にならないようデザインしている(詳しくは上のブログ)
  • CoursierやScala-CLIのようなメジャーなプロジェクトはMillを使って作られている！Mill は実用性があるのだ〜

An Intro to Generative Art with Scala

  • Flow Fieldsとは、ノイズフィールドから2Dベクトル場を生成するアルゴリズム
  • step by step の live coding で Flow FieldsをScalaで実装！
  • Processing 4はMaven Centralに公開されていないためハッキーな方法で Processing を利用している。giter8 template使ってね

こちらの発表もブログが公開されています

www.chris-kipp.io

Explaining Different Coroutine Flavours using Scala Native

LLVM stackless coroutine

Supercharge Your Performance with the Optimus Cirrus Platform

Morgan Stanley の人達による発表

  • Optimus Cirrus という並列分散処理のためのプラットフォームを内製開発している
  • ビルドという関数の参照透過性を実現できれば、このプラットフォームを利用して、容易に分散ビルド・ビルドキャッシュのためのビルドシステムを構築できる!?
    • デザインとしてはBazelのような Artifact Based Build system と同じ理屈
  • やりました(!??!!??)そして、OSS化予定です
    • BSP を利用して IDE サポートもうまくいっているらしい。すごすぎる

OSS化、楽しみ〜〜

Build Tool Design Principle

Batteries-included Scala with Scala Toolkit

Scala Toolkit を利用して、Pythonのように Batteries Included (scalaをダウンロードしたら、ライブラリの選定とかせずにすぐに基本的な開発のためのライブラリ一式が利用できる状態)を実現します！という話。

Batteries-included Scala with Scala Toolkit

Scalaの初学者を遠ざける理由の一つに、何かをするために利用するライブラリがたくさんあって、何を利用すればいいのかわからないという問題があるので、toolkitで厳選した簡単なライブラリを提供することで初学者がスッとScalaの開発に入っていけるようになるのはいいですね。

Closing Panel

Closing Panel

Scala はどこか大きな組織や大学の研究機関が大量のリソースを投入して、なんかすごいエンジニアが作っていると思われるかもしれませんが、実際は（だいたいのコンパイラはそうなのですが）、数少ないエンジニアがパートタイムまたはフルタイムで、あるいは趣味の時間を使って開発されているに過ぎません。

今後のScalaの開発継続のためにも、Corporate Membership（1500CHF＝約25万のone-time bucket-level donationも）での協力をお願いします！

scala.epfl.ch

終わりに

4年ぶりの開催となったScalaDaysは、様々な国から多くの人が集まる熱気あるカンファレンスとなり、世界のScalaコミュニティの活発さを実感することができました！

日本のScalaコミュニティは活発であることが認識されており、ScalaMatsuriのオフライン開催を期待する声や、より多くの日本のScala開発者が世界のScalaイベントに参加してくれることに期待が寄せられています。来年のScalaDaysに参加しようという方、ぜひ一緒に行きましょう。

最後に、ScalaDays チームが作成したカンファレンスの素晴らしいまとめ動画で締めくくりたいと思います。

〇〇(自分の経験したことや得意なこと)は重要であるという認知の歪み

生活

最近Twitterで次のような発言をいくつか目にした(〇〇にはその人が得意とすることや経験したことが入る)

  • 〇〇という本を読んでないやつは☓☓としてダメ
  • 社会人なら〇〇くらい一度はやっておくべき
  • 〇〇もできないとかヤバいだろ

自分が正しい選択をしたのだ・自分は重要な人間なのだと思いこむために、自分が既に経験したことや習得しているものをとても重要なものだと思い込む認知の歪みから、こういう発言に繋がっているのかなと思った。

例えば自分もソフトウェアエンジニアやるなら英語はある程度読み書き出来たほうがいいのでは?みたいな風に思うことがあるけれど、これは自分がすでに英語がある程度読み書き喋れるからそう思っているのであって、もしそうでなかったらこうは思わないだろうな思う。 別に英語以外にもソフトウェアエンジニアにとって重要な物事はたくさんあるのに、自分が既に習得しているものだけを特別重要視しているような気がして、自分の認知の歪みに気づいてとても恥ずかしい気持ちになった。

謙虚に生きよう

自分のスキルや経験が自信に繋がるのは良いことだけど、それを他人に対して〇〇すべきと考えるのは認知が歪んでいる気がするね。こういう認知の歪みを表すXX効果みたいな心理学の言葉とかってあったりするのかな -> 確証バイアスとかはちょっと近いかも