Category Archives: other

米国における就労ビザ(O1)を取得した話

少し前に米国で就労するためのO1ビザを取得しました。友人の何人かに内容を聞かれたことと、日本語による米国ビザ取得の話もあまりない為、ここに少し内容を残しておきます。どなたかの、今後の手助けになればと思います。 私はいくつかのきっかけが重なり、1年ほど前からある米国スタートアップでSenior Software Engineerとして働き始めました。米国における就労はビザの都合上できないため、ずっと日本の自宅から働いています。就労ビザ取得までには1年程度かかったことになります。流れとしてはH1への申請、その抽選に漏れてからのO1申請という形です。 ここでは、そのスタートアップで就労しはじめてO1ビザ取得までの全体の流れを残しておきます。O1ビザの取得にはUSCISが要件を出しています。この要件は見せ方など含めて移民弁護士との調整に依存することも多いので、ここではいくつか私の例に触れる程度にしておきます。また、ソフトウェアエンジニア以外の話はわからないので、ご了承ください。 私について ソフトウェアエンジニアとして米国で就労する場合、H1あたりを取得することがおおいと思います。O1はH1に比べて条件が多く、申請者の状況に依存します。そのため、ここではまず私がどういう活動をしてきたのかに軽く触れます。 私は2011年からソフトウェアエンジニアとして働き始めています。ソフトウェアテスト・品質方面に関わりたくキャリアを歩み始め、テスト・QAエンジニアから今ではシニアソフトウェアエンジニアとして自動テスト・製品評価やモニタリングを支援する環境を提供するスタートアップで製品開発を行っています。今のところ、一貫してソフトウェアテスト・品質の話題を主軸に関わり続けていることになります。 私は日本国内におけるソフトウェア工学の修士号を持っています。ただ、博士号や国際論文への実績はありません。2016年程度から、ある自動化を支援するOSS[1]のコアメンバーに入り、申請時点においても貢献を続けていました。そのOSS繋がりで、申請前の段階ではいくつか海外カンファレンスで発表したり、日本国内における国際カンファレンスの運営にも関わりました。また、ソフトウェアテスト・品質方面の活動では、日本国内でいくつかのカンファレンスで発表させていただいています。日本語ではありますが、寄稿や共著もあります。 [1]: iOSやAndroidが主ですが、WindowsやmacOSなど多数の自動化ツールのハブとして機能するものです H1とO1 H1やO1といったビザの種別の説明は省きます。こちらの公式ページを参照ください。 私もビザ申請前にO1ビザの取得可能性を調べていました。日本語、英語情報をみる限りでは、ソフトウェアエンジニアにおけるO1取得には博士課程の有無が言及されていることが多かったです。その為、私の実績で大丈夫なのか不安でしたが、結果としては大丈夫だったようです。いくつかおおまかな指標が要件に提示されていますが、実際に移民弁護士が提出した資料を見る限りでは国内や前職の実績以外にも、国際的な貢献も含めて実績があれば条件をクリアできるようです。 O1の申請において、H1同様にビザスポンサーが必要です。ビザの種類によって弁護士費用といった費用の差はありますが。O1では前職までの実績、公表されているような実績を提示し、米国にとって私が役に立つことを提示する必要があります。私は公表されているような実績の提示のみかと思っていましたが、弁護士の人曰く、前職までの社内含めた実績も必要とのことでした。例えば、何らかの賞を社内で取得していたり、社内で達成したこと、会社の名前を借りてカンファレンスなどの場で発表するなどです。 O1で特に重要なのは推薦書を集めることです。移民弁護士からもらったチェックリストには6~10程度の推薦書を、多様な人から集める必要があると書かれていました。集めた推薦書によって申請者の提出資料の信頼性を担保する形のようです。推薦者が何らかの立場を持っていたりすると良いようですが、それよりも申請者の実績を支援できるような立ち位置である/であったこと、その上で支援すると表明できる人であることのほうが単なる”距離のある立場を持つ人”よりも重要なようです。 私は2018年12月から現在の企業で働き始めたので、まずは時期的にも費用のかからないH1を受け、ダメだった時に他の手段(LかOなど)を考えようとなりました。結果、H1には選ばれませんでした。その為、O1の申請を進めることになりました。会社が移民弁護士などの対応を行ってくれた為、私は基本的に自身の実績や推薦状を書いてくれそうなツテなどを移民弁護士とやりとりしながら進めました。 時系列 H1からO1の流れを時系列でまとめます。 2019年 2、3月 H1の申請に向けた大学学部、修士時代の成績証明書、卒業証明書を取得 H1の申請 6月頭 H1の抽選に漏れたとの報告をうける 7月後半 LかOで申請が可能か検討する 所属企業の規模など含め、O以外は申請しても望み薄と判断される 8月前半 O1取得に向けて移民弁護士とやりとりを始める 受け取ったチェックリストを元に、私のもつ様々な実績や証明書を提供する 提出する資料は英語、もしくは英語訳（全文の直訳ではない）が必須なため英語情報をあつめる、もしくは英語訳を用意する 私の多くは日本語資料であったため、証明書関係以外は自分で英語の要約をつけ、必要なものには移民弁護士側で翻訳署名書の取得などしてもらいました 卒業論文のアブストラクト、証明書関係は日本の専門サービスを利用しました 8月後半 ビザの推薦状のテンプレートを受け取る（2名） 9月、10月 日本語資料の英語要約、その共有 ビザの推薦状テンプレートを受け取る（追加の2名） 11月後半 合計4枚の推薦状が揃う 日本に住む人から1枚、他3枚はカナダ、米国、英国に住む人たち 日本国内の私の活動を支援してくれる人、前職の実績を支持してくれる人、OSSなどにかかわる日本国外（強いては米国においても）実績を支持してくれる人 12月中盤 申請 カレンダーで14日以内に返信を要求できるpremium processingを追加費用を支払い申請 申請がない場合、3ヶ月程度以内に返信が来る（がいつ頃か具体的にはわからない）状態 後になり知ったのですが、このpremium processingの申請は途中から申請することも可能なよう 2020年 1月2日 Approval noticeを受け取る O1ビザの要件を満足していることを知らされる…More

WIRED Vol 25に書かれてた多数決に関する話

WIRED（ワイアード）VOL.25 に多数決の話があったので読んでみた。 ここで扱う多数決は、対象の半数以上を大多数とする、という類のもの。幾つかの政治的な実例から多数決の正しさ、妥当さを考えた記事でした。また、コンドルセの多数決を取り上げていました。 こういう分野、行動経済学と確か呼ばれていますね。 多数決では独立性が非常に鍵で、他要素からの影響であったり不正確な情報が入る環境下では正しく判断できない(判断に重み付けが含まれる)というところが難しいところです。そして、WIREDにもここまで言及されていたところが良かったです。 内容自体は修士論文書いていた頃にすでに言われていた(論文として調べていた)ことなので目新しさはなかったのですが、こういう変わり種も載せてくれるところがWIREDの面白いところですね。More

システム自動化カンファレンス2015で登壇してきました

システムテスト自動化カンファレンス 2015で発表してきました。 今回はサービスを生業としている企業が少し目立つ感じで居ましたので、ビジネスの形態の違いから疑問を残したままの参加者もいるかもしれません。リリースに至るまでの文化の違いや、一見出してなんぼに見えすぎる世界など、その裏側の取り組みを除くとその疑問も拭えないものであるかもしれません。ですが、全体的に見慣れた風景とは違ったものが見えたのではないでしょうか。(そうだとうれしい) ところで… 私の発表は終わり頃で、聞かれている方々も結構お疲れだったのではないでしょうか。 1時間という長い時間が持ち時間だったので、入りの猫の画像であったり、所々少し誇張気味に表現しながらも、退屈せずに聞くことができるように工夫してみました。Twitterをみるに、概ね期待通りの効果が出たようでうれしい限りです。 発表 スライドは以下です。発表した感じ、想定した時間通りに、要素をかいつまみつつモバイルアプリの開発/テスト/ツール群/事例を共有できた気がします。 遊び ところで、最初の自己紹介のstruct( %{} )やパイプライン演算子など、モバイルとはほとんど関係ないElixirを取り入れていたことはお気づきだったでしょうか？ちょっとしたお遊び。 気づいてくれたかたもいたみたいです。 https://twitter.com/hayabusa333/status/675930652932308992 気づいたか。ついでにその前の%{}のところはstructです — KazuCocoa (@Kazu_cocoa) December 14, 2015 One more thing 発表の前にもスライドを公開しましたが、そちらには意図的に載せていなかったことがあります。One more thingです。正直なところ、いろいろ書いててもっと時間を使おうとも思ったところです。ただ、モバイル開発という文脈から距離のある方が多いと踏んで、情報過多になるだろうのでここはかなり端折りつつ、要点だけ載せるに止めました。 one more thing入れました #stac2015 https://t.co/8vwj30JcpG — KazuCocoa (@Kazu_cocoa) December 13, 2015 tgetterはこちら http://togetter.com/li/912197 最後に パネルのところでは、直前の1時間の発表で疲れてて、集中力に欠けてて申し訳ありませんでした… IoTの話は以前考えたことあるのですが、広い視野でみると分散系の話に落ち着いていくのではないかと思います。そこでは、研究でかじっていたビザンチン将軍問題も絡んでくるような分散ネットワークな話になると個人的には面白いと思っています。(大変ですが) 最後の砦というほど高尚な感じではなくて、そういう人がいるから開発時はそちらに集中できる環境になるといいなと思って進めています #stac2015 — KazuCocoa (@Kazu_cocoa) December 13, 2015 私よりも人格/スキル/能力共に高いかたが大勢いると思いますので、もし興味があるようでしたら一緒にこのような変化へ飛び込んで、さらにハッピーになりましょう。 この文化や取り組みに興味あるかたは一緒に働きましよう！ https://t.co/X9MCsSjN4n #stac2015…More

SQuBOKv2読破会と私

最近開いたTestingに関するイベントを行ってから、感じること、気づくこと、つながりといったところを考えるこの頃です。 さて、SQuBOKv2読破会 Advent Calendar 2015、5日目の記事です。4日目はSQuBOKによる無知の知の体験でした。 この会は、有志何人かが集まってソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)を読み、議論し、より良いソフトウェアを創造していくための足がかりを得るものです。そこら辺の概要は1日目の記事を参考にすると良いでしょう。 この本自体はより良いソフトウェア開発を対象とした、組織的な大局話からプロジェクト個々の話、コード品質やテスト技術と局所的な話に至るまでの全般な話を扱っています。コードの実装やテスト実施などの実施の時代によって移り変わりが激しいところは適度に抽象化されて、時代に流れすぎない形でまとめられています。 今回は、この読破会と私、ということで少し書きます。 きっかけ 私は過去、WACATEと呼ばれるソフトウェアテストに関わる人たちの集まりに参加しました。2014年の冬でしょうか。その頃、夜の分科会を(確か)テストエンジニアのこれから、という少しざっくりとした話題で開かせて頂きました。その時に色々話をしました中にいた、@masskanekoに誘われる形で参加しました。 当時、SQuBOKv2は軽く読んでいました。ただ、やはり量が多いので個々の要素は詳しく読んではいませんでした。自分の必要な箇所だけかいつまんで読む、それ以外はこれから必要になったときに時折読む、という感じでした。 そんな折、この読破会への誘いを受けました。結果、一人で読んで積読に近いものになるよりは良いかな、という気持ちで参加してみました。 参加して SQuBOKは知識体系と言われますが、実態は 困った時に過去の経験を素早く参考にすることが可能な indexのようなものです。内容の情報量からしてもそうは思っていたのですが、この会で読んでその認識がさらに強くなりました。この過去の経験、というのは1990年代の産業が成長し始めている頃からの様々なトライアンドエラーの塊です。 例えば、Web界隈では最近開発プロセスの変化や組織の移り変わりの話など含めてマネジメントの話、プロセス改善の話をよく聞きます。そのあたりは、小さな個人の開発からチーム/組織な開発に業界全体が遷移しようとしている時代だからであったり、はたまたスタートアップが増えているからでしょう。そこでよくある改善の取り組みやアンチパターンなんかは、私の経験と照らし合わせてもこのSQuBOKに同様なことがすでにまとめられていました。(マネジメント特化、などになるとまた話が変わりますが。) 失敗するよくある形、それを防ぐために先人はどのような取り組みを行ったのか、というものをざっと知ることができました。その具体は時代や周辺環境に差があるので全く同じではない、というのは自明です。それを踏まえた上でも、やはり役立ちます。 手段としてのツールや環境は変わろうとも、人による創造的な取り組み自体は今も昔も大差ない、ということのようですね。そこら辺の取り組みが巨大化・形骸化して今に至ったのだとしても、前を向いて前進していた熱い時代では変わらぬ改善への取り組みを行っていたようですね。ここら辺は大学時代に教授らから話を聞いてはいましたが、改めてなるほどねーという感じでした。 合宿 開発者の中には開発合宿を開いたこともあると思います。それと違わず、この読破会も同様な合宿を夏頃に行いました。ただ、開発者合宿でよくあるプログライングが伴うものではありません。 ソフトウェアメトリクスなどの、ソフトウェア製品自体の計測をどうするか、どんな研究があるか、というところを話題の中心に、色々議論していました。参加した人たちの経験などを色々議論しつつ、非公開な情報を共有したりと、本だけでは得られない知見を得られました。 アルコールや温泉などは言わずもがな 、です。 今生かされていること これらの経験は、今の実際の業務に生きています。 例えば、私は立場上プロセス改善などを主導する位置にもいます。また、チーム作り、採用などの先も考える必要もあります。そのような組織に寄った活動を日々のそれなりに多忙な開発実務と並行して行うには、経験が全てではやっていけません。(少なくとも私は無理そう)。そのような時、直接的な解答をあたえてくれることは少ないですが、それにつながる過去の事例を提供してくれる体系はとても役立ちます。 少なからず私たちが進めようとしていることに対してよくない匂いに気づくアンテナを広げることにも役立っています。取り組んでいることがハズレではないこと、不安なら参考になりそうな過去の経験へのアクセス手段までたどり着けることがわかっていることは、行う取り組みに対して背中を後押ししてくれます。 開発言語やそれらを取り巻くツールのように動きの早いもの、人に関する古くから研究されていて動きの穏やかなもの、それぞれを上手い具合に取り入れながら活動を継続したいですね。 最後に 今の自分、環境は特別である。過去の先人とはまったく違う。 こういう思想を持っていない人にとっては、SQuBOKのような体系はなんらかの形で恩恵を読者にあたえてくれると思います。これは新規サービス開発といったサービス自体の話ではありません。すでに研究され続けている人の関わる系に関する話です。 この書籍に限りませんが、よくある失敗として目的と手段のはきちがいがあります。また、前例にとらわれて思考が停止してしまうこともよくあるでしょう。そこに言及することは不毛なので立ち入りませんが、一応注意点としては残しておきます。 では、手短な内容となりましたが以上になります。次回は 吉田東京 さんです。引き続き宜しくお願いします！More

[Elixir in Action]Erlang/Elixirの再帰計算におけるnon-tail recursionとtail recursion

ちょっと印象的だったので。 再帰計算を行う関数の最後が、別の関数呼び出しかどうか、という違いです。 non tail recursion https://github.com/sasa1977/elixir-in-action/tree/master/code_samples/ch03 tail recursion https://github.com/sasa1977/elixir-in-action/blob/master/code_samples/ch03/sum_list_tc.ex Dive to source code Elixirには、再帰表現をまとめたコードとして Enum.reduce(collection, acc, fun) なんかを提供しています。 この中身を少しみてみましょう。 Elixirの の再帰箇所は以下のように書かれています。 Erlangの資料によると、 :lists.foldl(Fun, Acc0, List) はtail recursionとのこと。 こちら foldl/3 is tail recursive and would usually be preferred to foldr/3. ということは、 Enum.reduce(collection, acc, fun) はtail recursionなのですね。 コード追うと Enum.reduce/2 も Enum.reduce/3 を結局は呼ぶので、reduceはtail recursionで実装されていて、巨大なリストに対してもちゃんと再帰計算ができることを重視されているのですね。 Elixirの List.foldr/3 や List.foldl/3…More

[Elixir]パターンマッチやcase文でのwhenにおけるguard clauses

Elixirの記述に慣れるため、exercism.ioで簡単な問題を解きながら時間の合間に遊んでいます。 そこで少しエラーを何回も出してしまったのでメモ。 以下の通り、Elixirではguard clausesの中におけるbooleanの式ではand or not を使う必要があるみたいですね。 Note that while boolean operators such as and, or, not are allowed in guards, the more general and short-circuiting operators &&, || and ! are not. from: http://elixir-lang.org/getting-started/case-cond-and-if.html 他言語だとビット演算云々で私は || とか && を使うことに慣れていたのでつまづいてしまった… あと、同じように以下の[ここ]と書いている箇所。判定を読みやすくするために独自の関数を作ってみたのですが、guard clausesの中ではそのような独自な関数はちゃんとマクロ組んで作らないといけないのですね。 あらかじめこのwhenの中で使える関数が用意されていますが、それを超えるものはマクロ組んでいく必要があるみたい。ただ、それは可読性を損なう恐れのあるものなので、個人的には case example do のexampleをうまいこと表現したいですねー。 もう1個。以下のようなcaseを使った関数、パターンマッチを組み合わせた関数でも記述することができます。 case文 パターンマッチ whenの中に記述できる処理式には限りがあるので、複雑な分類であれば case を使うほうがよさそうですが、簡単な when で区分できる場合、関数自体を分けたほうが責務が明確になってよさそう。…More