2022-07-16

SQL ServerをM1 MacのDockerで動かしたい

お久しぶりです。ぱいんです。

今日はタイトルの通り、SQL ServerをM1 Macで動かすためにやったあれこれを書き連ねていきたいと思います。

背景

以前はIntel Macを使ってSQL Serverのコンテナを立てて開発をしていました。ですが弊社の支給PCがM1 Macになったことで、今まで動かしていたSQL Serverが動かなくなってしまいました。そこで何とかM1 MacでSQL Serverを使うために色々試してみました。

SQL Serverが動かない

以下の公式の手順に沿って、SQL ServerをDockerで動かしてみます。

Docker:SQL Server on Linux 用のコンテナーのインストール - SQL Server | Microsoft Docs

手順通りにdocker pullと、docker runしてコンテナを表示してみると、コンテナが落ちてしまっています。

$ docker ps -a
CONTAINER ID   IMAGE                                        COMMAND                  CREATED         STATUS                     PORTS     NAMES
4150476cb784   mcr.microsoft.com/mssql/server:2019-latest   "/opt/mssql/bin/perm…"   5 seconds ago   Exited (1) 4 seconds ago             sql1

これだけだと原因がわからないので、ログを表示してみます。

❯ docker logs 4150476cb784
SQL Server 2019 will run as non-root by default.
This container is running as user mssql.
To learn more visit https://go.microsoft.com/fwlink/?linkid=2099216.
/opt/mssql/bin/sqlservr: Invalid mapping of address 0x4003816000 in reserved address space below 0x400000000000. Possible causes:
1) the process (itself, or via a wrapper) starts-up its own running environment sets the stack size limit to unlimited via syscall setrlimit(2);
2) the process (itself, or via a wrapper) adjusts its own execution domain and flag the system its legacy personality via syscall personality(2);
3) sysadmin deliberately sets the system to run on legacy VA layout mode by adjusting a sysctl knob vm.legacy_va_layout.

エラー文で検索してみると、同様の事例がissueとして上がっていました。 https://github.com/microsoft/mssql-docker/issues/668

issueによると、現状M1 MacでSQL Serverのコンテナを動かすことは出来ないようです。しかし、同じMicrosoftが提供するAzure SQL Edgeのimageを使ってSQL Serverを動かしている人がいるようなので試してみます。

Azure SQL Edgeを使ってSQL Serverを動かす

以下のimageを使って、Azure SQL Edgeを動かしてみます。 https://hub.docker.com/_/microsoft-azure-sql-edge

なお、Azure SQL EdgeにはARM用のimageと、x86(AMD64)用のimageが存在しています。両方のimageが存在している場合に普通にpullすると、実行している環境に対応したimageがpullされます。自分の場合はM1Macを使用しているため、ARM用imageがpullされます。

❯ docker pull mcr.microsoft.com/azure-sql-edge:latest
latest: Pulling from azure-sql-edge
Digest: sha256:7c203ad8b240ef3bff81ca9794f31936c9b864cc165dd187c23c5bfe06cf0340
Status: Downloaded newer image for mcr.microsoft.com/azure-sql-edge:latest
mcr.microsoft.com/azure-sql-edge:latest

❯ docker image inspect mcr.microsoft.com/azure-sql-edge
[
    {
...
        "Architecture": "arm64",
        "Variant": "v8",
        "Os": "linux",
        "Size": 1831484943,
        "VirtualSize": 1831484943,
...
    }
]

docker image inspectで確認してみると、 "Architecture"で"arm64"が選択されています。

M1 MacでARM用イメージではなく、x86用イメージを使いたい場合は--platform linux/x86_64オプションで明示的に指定する必要があります。

❯ docker pull --platform linux/x86_64 mcr.microsoft.com/azure-sql-edge:latest
latest: Pulling from azure-sql-edge
Digest: sha256:7c203ad8b240ef3bff81ca9794f31936c9b864cc165dd187c23c5bfe06cf0340
Status: Downloaded newer image for mcr.microsoft.com/azure-sql-edge:latest
mcr.microsoft.com/azure-sql-edge:latest

❯ docker image inspect mcr.microsoft.com/azure-sql-edge
[
    {
...
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 1133716277,
        "VirtualSize": 1133716277,
...
    }
]

"Architecture"で"arm64"ではなく"amd64"になっています。

まずはx86用のイメージで動かしてみます。

❯ docker run --cap-add SYS_PTRACE -e 'ACCEPT_EULA=1' -e 'MSSQL_SA_PASSWORD='passw0rd' -p 1433:1433 --name azuresqledge -d mcr.microsoft.com/azure-sql-edge:latest
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
88dcadd90e3d139f3079dd075a8216e1dc0a98f91612a9d51e874cbf8a4e82cf

❯ docker ps -a
CONTAINER ID   IMAGE                              COMMAND                  CREATED         STATUS                     PORTS     NAMES
88dcadd90e3d   mcr.microsoft.com/azure-sql-edge   "/opt/mssql/bin/perm…"   3 seconds ago   Exited (1) 2 seconds ago             azuresqledge

こちらだとコンテナが落ちてしまいます。logを見てみるとmssqlと同じエラーが出ています。

❯ docker logs 88dcadd90e3d
Azure SQL Edge will run as non-root by default.
This container is running as user mssql.
To learn more visit https://go.microsoft.com/fwlink/?linkid=2140520.
/opt/mssql/bin/sqlservr: Invalid mapping of address 0x40092f5000 in reserved address space below 0x400000000000. Possible causes:
1) the process (itself, or via a wrapper) starts-up its own running environment sets the stack size limit to unlimited via syscall setrlimit(2);
2) the process (itself, or via a wrapper) adjusts its own execution domain and flag the system its legacy personality via syscall personality(2);
3) sysadmin deliberately sets the system to run on legacy VA layout mode by adjusting a sysctl knob vm.legacy_va_layout.

次に、ARM用イメージで動かしてみます。 image名は事前にdocker tagを使って変更しています。

❯ docker run --cap-add SYS_PTRACE -e 'ACCEPT_EULA=1' -e 'MSSQL_SA_PASSWORD=passw0rd' -p 1433:1433 --name azuresqledge -d mcr.microsoft.com/azure-sql-edge:latest
066e3272b85227f6f29e1a2083f2794e2e3faca41ef07600aa2275c98513d5cb
❯ docker ps -a
CONTAINER ID   IMAGE                COMMAND                  CREATED         STATUS         PORTS                              NAMES
066e3272b852   azure-sql-edge-arm   "/opt/mssql/bin/perm…"   3 seconds ago   Up 2 seconds   1401/tcp, 0.0.0.0:1433->1433/tcp   azuresqledge

こちらのイメージは正常に動いてそうです。 M1 MacでSQL Serverが動くことが確認できました。

注意点

sqlcmdが無い

ARM用imageだとsqlcmdが入ってないので別途sqlcmdを動かす方法を考える必要があります。

[!NOTE] sqlcmd tool is not available inside the ARM64 version of SQL Edge containers. https://hub.docker.com/_/microsoft-azure-sql-edge

azure-sql-edgeの関連リポジトリとしてmssql-toolsがあります。このmssql-toolsにsqlcmdが入っているので、sqlcmdを使って初期化用SQLを流したいといった場合には、azure-sql-edgeでSQL Server用コンテナを立て、mssql-toolsで別途コンテナを立てて別コンテナからsqlcmdでSQLを流すという方法を取る必要があります。

Azure SQL Edgeでサポートされていない機能がある

Azure SQL Edgeのイメージで一応SQL Serverを動かせることができますが、元のmssqlイメージとは別物であるため、サポートされていない機能もあります。詳しくは下記のドキュメントにサポートされていない機能についての記述があります。

Azure SQL Edge でサポートされる機能 | Microsoft Docs

まとめ

とりあえずM1でSQL Serverを動かしてみただけなので、業務などで使う場合には本当にこのAzure SQL Edgeで大丈夫なのかというのは確認が必要だと思います。 mssqlイメージがM1対応してくれると嬉しいんですけどね。

https://hub.docker.com/_/microsoft-mssql-server

M1が出てから結構な期間が経って、様々なライブラリやツールがM1に対応してきていますが、中には未だに対応していないものもあるため遭遇した際には中々辛いものがあります。。。

2021-12-13

無料枠で使っていたAmazon EC2を停止させてたら料金を請求された話

プログラミング

こんにちは。ぱいんです。

本記事は琉大Advent Calendar 2021 13日目の記事になります。

adventar.org

先日AWSからこんなメールが来てました。

Greetings from Amazon Web Services,

This e-mail confirms that your latest billing statement, for the account ending in *******, is available on the AWS web site. Your account will be charged the following:

Total: $58.44

料金請求のメールでした。

え？なんで料金が請求されてるの？無料枠だったのに？ EC2は停止させてたはずなのになぜ？

原因

原因究明のためまずはAWSコンソールからBillingの請求書を見に行きました。

請求書についてはマイ請求ダッシュボードから見れます。 f:id:pine619:20211111062401p:plain

そして料金明細へ。 f:id:pine619:20211212090421p:plain

原因はNATゲートウェイとElastic IPでした。

NATゲートウェイ

サービス概要

ドキュメントによると、

NAT ゲートウェイは、ネットワークアドレス変換 (NAT) サービスです。NAT ゲートウェイを使用すると、プライベートサブネット内のインスタンスは VPC 外のサービスに接続できますが、外部サービスはそれらのインスタンスとの接続を開始できません。 NAT ゲートウェイ - Amazon Virtual Private Cloud

インターネットに接続できないプライベートサブネット内のインスタンスがインターネットへ接続するためのサービスです。インスタンスからインターネットへ接続はできるが、外部からインスタンスに対して接はさせたくないときに使われます。

今回はEC2でDBサーバーを立てていて、インストールやアップデートなどインスタンスからインターネットへ接続はしたいが、外部からDBサーバーへアクセスはさせたくないってことでNATゲートウェイを使用していました。

料金

VPCの料金を記述してあるページにNATゲートウェイの料金についても触れられていました。

VPC 内に NAT ゲートウェイを作成することを選択した場合は、ゲートウェイがプロビジョニングされ利用可能であった "NAT ゲートウェイ時間" に対して料金が請求されます。データ処理料金は、トラフィックの送信元か送信先にかかわらず、NAT ゲートウェイで処理されたギガバイト単位で適用されます。1 時間未満の NAT ゲートウェイ時間は、1 時間分として請求されます。また、NAT ゲートウェイを介して転送されるすべてのデータに対して標準的な AWS データ転送料金が発生します。NAT ゲートウェイへの課金を止めたい場合は、AWS マネジメントコンソール、コマンドラインインターフェイス、API を使用して NAT ゲートウェイを削除します。料金 - Amazon VPC | AWS

ということでNATゲートウェイには以下の2種類の料金があります。

NATゲートウェイ時間に対する料金
NATゲートウェイで処理されたデータ量に対する料金

アジアパシフィック(東京)の場合は、執筆時点(2021/12/12)のレートだと以下のようになります。

	USD	JPY
NATゲートウェイ時間に対する料金	0.062 USD	0.7 JPY
NATゲートウェイで処理されたデータ量に対する料金	0.062 USD	0.7 JPY

NATゲートウェイはEC2ではなくVPCに紐付いているため、EC2の停止をしてもNATゲートウェイは動いています。そのためNATゲートウェイ時間に対する料金が発生します。

Elastic IP

サービス概要

Elastic IP アドレスは、動的なクラウドコンピューティングのために設計された静的 IPv4 アドレスです。Elastic IP アドレスはユーザーの AWS アカウントに割り当てられ、解放するまでユーザーのアドレスになります。 Elastic IP アドレス - Amazon Elastic Compute Cloud

AWSで固定IPアドレスを使うためのサービスです。

NATゲートウェイはインターネットへ接続するためにElastic IPを割り振る必要があります。 NATゲートウェイを作成するときにElastic IPの割り当てというボタンがあり、それを押すことで自動でElastic IPを取得します。 f:id:pine619:20211212095339p:plain

料金

Elastic IPは特定の条件を満たすと料金がかかりません。その条件が以下です。

Elastic IP アドレスが EC2 インスタンスに関連付けられている。
Elastic IP アドレスに関連付けられているインスタンスが実行中である。
インスタンスには、1 つの Elastic IP アドレスしかアタッチされていない。
Elastic IP アドレスは、Network Load Balancer や NAT ゲートウェイなどのアタッチされたネットワークインターフェイスに関連付けられます。

Elastic IP の料金を理解する

今回の場合はEC2インスタンスではなくNATゲートウェイにElastic IPが関連付けられているため課金対象となります。

料金としてはEC2インスタンスに紐付けられていない場合は1時間あたり0.005USD(0.57JPY)です。

まとめ

約6800円の痛い勉強代になりました。。。しっかりと料金請求の条件を確認しないと思わぬ出費が発生してしまうので気をつけましょう。

明日は@matac42の記事です！皆さんお楽しみに！

2021-12-09

5月から始めた内定者バイトを振り返る

こんにちは。ぱいんです。

社内ではたかとんと呼ばれています。(ぱいんにしようと思ってたら既にぱいんさんが居た。。。)

本記事はZOZO Advent Calendar 2021 9日目の記事になります。

qiita.com

今年の5月から内定者バイトをしており、約8ヶ月間が過ぎたので内定者バイトの振り返りを書いていきたいと思います。

なんで内定者バイトしようと思ったのか？

内定者バイトをしようと思ったきっかけは以下の2点の理由です。

会社の雰囲気を知りたかった
技術的についていけるか不安があった

会社の雰囲気が知りたかった

第一の理由です。面接のお話の中で開発の進め方やチームの雰囲気について聞けたのですが、やっぱり実際に現場の雰囲気を知りたかったというのがありました。

技術的についていけるか不安だった

第二の理由です。就活イベントに参加したり他の内定者の方々を見て「みんな強そうなエンジニアに見える。。。」と思い、自分がそんな方々と一緒に働けるのかと不安でした。

そのことを人事の方に相談したところ、「内定者バイトをしてみたらどうかな？」と言われてやってみようと思いました。

どんな部署でバイトしてるのか？

マーケティングオートメーション(MA)に関する部署で、セール通知や値下げ通知などの配信を行うためのツール・基盤を作成してます。

職種としてはSRE/バックエンドエンジニアとしてJOINしました。

内定者バイトでやったこと

タスクとしては以下のものを行いました。

開発環境インスタンスの自動停止・起動ツールの作成
配信データ連携の速度改善
配信用インスタンスのメモリリークの調査・改善

タスク以外には23卒向けの就活イベントに参加し、内定者としてLTをする機会もありました。

そのときの資料を貼っておきます↓

speakerdeck.com

上記以外にもチーム内でのMTGやモブプロ、勉強会などにも参加して色々と経験させていただいています。

内定者バイトをやってみて

実際に内定者バイトをやってみて先述したきっかけで挙げていた会社の雰囲気や、技術的な不安が解消されたのかについて。

会社の雰囲気について

まず会社の雰囲気について。こちらに関してはチームの皆さんの人当たりがよく、とても良い雰囲気で働けています。

バイトを始める前はリモートということもあって「わからないことを聞きづらいのではないか？」という懸念がありましたが、実際に働いてみるとそんなことは無かったです。

チームでは、業務時間中はslackのハドルミーティングにマイクミュートの状態で参加するのが基本となっています。そのため聞きたいことがあればマイクONにして喋るだけでOKです。これによって聞きやすい環境になっています。

また、チームで作業ログを導入しており、前回やったこと・今日やることを投稿し、そのスレッドにログを書き連ねています。これによってマイクONにして聞く前にチームの先輩が私の作業ログを見てアドバイスをしてくれるので、非常に助かっています。

最近チームの先輩が作業ログ運用を便利にしてくれたので良ければその記事もご覧ください。

qiita.com

技術力の無さの不安について

次に技術力の無さの不安について。

こちらについては実際に働いているチームメンバーや他部署の方々を見て、より力不足を痛感しました。

しかし不安についてはタスクをこなしていくうちに解消されていき、今は強い諸先輩方を見てモチベーションが上がっています。

上司からはおすすめの技術書や、キャッチアップの仕方、エンジニアとしての情報収集の仕方などを教えてもらったので焦らず一歩ずつ技術力を高めていきたいと思います。

まとめ

内定者バイトをすることで会社の実際の雰囲気や業務についていけるかなどの不安を解消することが出来ました。同じような不安を抱えている方で、内定先で内定者バイトの受け入れがあればやってみることをおすすめします！

最後まで読んでいただきありがとうございました！

2021-10-03

AWS EC2へのscpでPermission Denied

プログラミング

scpを使ってローカルからAWS EC2インスタンスへpemファイルを送るときにPermission Deniedが発生した。

% scp -i ~/.ssh/ec2-key.pem ec2-key.pem ec2-1XX-XX-XX-XX.ap-northeast-1.compute.amazonaws.com:~/ec2-key-for.pem
user@ec2-1XX-XX-XX-XX.compute.amazonaws.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
lost connection

とりあえずsshのログを見てみようということで、サーバー側にて

% sudo cat /var/log/secure

接続に失敗した該当箇所を見てみると、以下のような記述があった。

sshd[7899]: Invalid user ユーザー名 from IPアドレス port 54937
sshd[7899]: input_userauth_request: invalid user ユーザー名[preauth]
sshd[7899]: Connection closed by IPアドレス port 54937 [preauth]
sshd[7902]: Invalid user ユーザー名 from IPアドレス port 54946
sshd[7902]: input_userauth_request: invalid user ユーザー名 [preauth]
sshd[7902]: Connection closed by IPアドレス port 54946 [preauth]

よく見てみると上記ログのユーザー名のところが、サーバー上のユーザーの名前じゃなくてローカル上のユーザーの名前になっていた。

ということでscpの送信先でサーバー上のユーザーを指定して実行。

% scp -i ec2-key.pem ec2-key.pem ユーザー名@ec2-1XX-XX-XX-XX.ap-northeast-1.compute.amazonaws.com:~/
ec2-key.pem          100% 1704    45.6KB/s   00:00

無事ファイルがローカルからサーバーへ送れた。

原因は送信先ユーザーの書き忘れ。 scpでは送信先のユーザー名が省略可能になっていて、ユーザー名を省略した場合はローカルのユーザーを同じユーザー名が使われる。

割と初歩的なミスだと思うが、案外ハマりそうなので忘備録として残しておく。

2021-09-29

就活終了したので

就活

はじめに

皆様お久しぶりです。ぱいんです。

前回の記事を書いてから約9ヶ月ほどが経ってしまいました。

前回は就活の第一歩として面談イベントについて書きましたが、それから大分月日が流れて就活終了したので久々にブログを書こうと思います。

長めな記事になりそうですが良ければ読んでくれると嬉しいです。

アジェンダ

就活の流れ
実際やってたこと
受けた会社
終わりに

就活の流れ

就活のスケジュール感は以下の感じでした。

就活イベント参加、カジュアル面談(12月)
がっつり面接期間(1月)
内定承諾、就活終了(2月)

就活イベント参加、カジュアル面談(12月)

就活イベント参加

就活を始めたのは、12月中旬くらい。

友達にサポーターズさん主催のエンジニア1on1面談イベントに誘われたので軽い気持ちで応募したのが就活の第一歩でした。

そのときのレポは別記事に書いてあるので良かったら読んでください。

pine619.hatenablog.com

当時はぼんやりと大学院進学を考えていましたが、ちょっとは就活を経験してみようという感じでした。

簡単にエンジニア1on1面談イベントについて説明すると、

学生と企業がそれぞれ面談志望度のアンケートを提出し、その内容で面接社数・面接企業が決まり面談を行うというイベントです。また、イベント終了後に企業からスペシャルオファーとしてカジュアル面談や、選考招待などがあります。

私もありがたいことに5社くらいからスペシャルオファーを頂き、そこからカジュアル面談や選考へ進んでいきました。

カジュアル面談

イベントで知り合った企業とのカジュアル面談を12月後半くらいにやってました。

イベントは1社あたり25分という限られた時間だったので、カジュアル面談でその企業の詳しい話を聞いたり、逆に自分の詳しい話を話してました。

カジュアル面談ということでどの会社も終始和やかな雰囲気で面談という感じでしたが、聞かれる内容は今までの開発経験だったり、自分の長所・短所など結構面接でありがちな質問が多かったので、カジュアル面談だからといって油断は禁物だと思います。

カジュアル面談後、本選考に誘われたのですが大体一次面接免除やES免除でした。

おそらくカジュアル面談が一次面接のようなものなので、通常選考の一次面接やESが免除されたんだと思います。

がっつり面接期間(1月)

カジュアル面談を終え、1月からは本格的に選考に入っていきました。

ここからは会社名は伏せますが、簡単な会社の説明と選考結果、選考結果の分析なんかを書いていきたいと思います。

某社1

渋谷の会社。アドテクとか就活系サービスとか色々やってるみたいだけど就活サービスしか知りませんでした。

イベントで最初にマッチングした会社だったので、結構いい感じに行けるのでは？と思ってたのですが、初めての面接ということもあり、全然上手く喋れなかったです。質問に対してきちんと答えられず、質問の趣旨とは違う答えを喋ってました。

結果はお祈りメール。

まあ最初の面接なのでしょうがないと割り切りました。

某社2

某携帯会社の子会社で、データを活用した事業やアドテクなんかをやってる会社。実は自分がやっていた開発系のアルバイトの親会社でもあったため結構行けそうな気がしていました。

面接するにあたり、前日までに履歴書の提出をしなければならなかったのですが、それをすっかり忘れており、面接10分前に気づきましたがもう既に時遅し。

面接開始に平謝りして、相手からは一応「大丈夫ですよ」と言われたが、この時点で落選確定だったと思います。

一応面接ということで一通りやったのですが、落選を確信しながらの面接は苦行でした。。。

結果は当然お祈りメール。

本当に申し訳ありませんでした。

某社3

検索エンジンを作ってる赤い会社。

ESは免除でコーディングテストがありました。

内容は言えないですが、コーディングテストが鬼難しかったです。大問が3~4つあったのですが、出来たのは一番簡単な最初の問題だけでした。

絶対落ちたなと思ってたのですが、奇跡的にコーディングテスト通過していたので次の面接に進みました。

次の面接は志望動機とか開発経験とかを聞かれると思って色々対策してたのですが、面接内容はコーディングテストについてでした。コーディングテスト全く解けてなかったので当然喋れず。

あと話しが全然噛み合ってる感じがしなかったので、面接官との相性も悪かったと思います。

結果はお祈りメール。

某社4

グループウェアを作ってる会社。

ES・一次面接免除で、二次面接からのスタート。

面接に慣れてきたのと、ホームページの企業理念とかを見ながらしっかり志望動機とかを話せたので手応えはありました。

手応え通り結果は二次面接通過で初の最終面接をすることに。

迎えた最終面接ですが、最初に開発経験を聞かれました。

そのときにバイトと大学どっちの経験を喋ろうか迷ってバイトについて喋り始めました。

ですが、バイトだと守秘義務があるため、深掘った質問をされたときに答えられない部分が多々ありました。なので上手く話せず雰囲気があまり良くなかったです。思い返してみると二次面接やカジュアル面談では大学の開発経験を話していました。その開発経験が評価されて最終面接に進めたのに、そこでいきなりバイトの話、しかも上手く話せないということでプレミをしてしまいました。

結果はお祈りメール。

初の最終面接落ちだったので結構メンタルがやられました。

某社5

ファッション系ECの会社。

最後の会社で、ここ落ちたら院進しようと思ってました。

今までの4社は全てイベント内で喋った会社だったのですが、この会社はイベント時には面談が組まれなかったので喋ってませんでした。

ですが、イベント終了後に「面談で話したかったけど残念ながら組まれなかったので改めてカジュアル面談をさせてください」とオファーがあったので面談しました。

面談にて事業内容や福利厚生などを聞いてみてよかったのでそのままエントリーしました。

一次面接、二次面接は無事に通過しました。

そして迎えた最終面接ですが、CTOと部長さんとの面接だったのですが、終始和やかな雰囲気でいい感じに喋れました。面接後の感触としては受かってる自信がありました。

朝イチで面接をしたのですが、夕方には担当してもらっていた人事の方から電話があり、無事内定を頂きました。

その後オファー面談をして、内定承諾をして現在は内定者バイトとしてチームに入り、色々勉強させてもらっています。

振り返りとしては、各面接が終わるごとにフィードバック面接があって、面接の振り返り・良かったところ・悪かったところ・次の面接の対策などをしてくれてサポートが手厚かったです。

終わりに

結果は5社受けて1勝4敗という結果でした。

手持ち最後の会社で運良く内定を頂き、事業内容・オファー内容・人の良さに納得できたので、院進はせずに学部で就職の道を選びました。

初めて就活系のイベントに参加してそこで知り合った企業と面接し、期間としては2ヶ月くらいで就活を終えているので就活に関しては運が良かったほうだと思います。

4月からは東京に住もうと考えていますが、東京に土地勘なし・今まで実家暮らしということで東京や引っ越しについて知見ある方がいれば教えていただけると嬉しいです。

最後まで読んでいただきありがとうございました。

2020-12-23

就活の一歩目を踏み出した

就活

はじめに

こんにちは！ぱいんです！これは琉大advent calendarの23日目の記事になります。初めてブログを書くので読みづらいかと思いますがよろしくおねがいします！

adventar.org

やったこと

就活の第一歩としてサポーターズさんのエンジニア1on1面談イベントに参加しました。

talent.supporterz.jp

参加目的は、

~~面談するだけで1万円貰えるから。~~

就活の第一歩として色んな会社の話を聞いてみようということで軽い気持ちで応募。

選考制だったので、プロフィールやアンケートを書いて送ったところ、合格したので参加者用のslackへ参加することに。

slackではユーザ名を大学名＋名前にという指定があったのでみんなの大学名が見える状態でした。参加者を見ると東大、京大、東工大など軒並み強い大学の方ばっかりでえぇぇ・・・となっていました。

当日のスケジュールは、

時間	内容
10:00-10:30	ガイダンス
10:30-12:35	企業プレゼン
12:40-13:30	学生自己紹介
14:45-19:50	面談会 (25分×8回)

って感じ。

企業プレゼン

1企業につき5分間の企業プレゼンを聞いて志望度アンケートを出しました。この学生側が出した志望度アンケートと、企業側が学生プロフィールを見て出した志望度アンケートを元に午後の面談が組まれるということでした。企業側の志望度が低ければ、面談回数が8回以下になることもあるらしいので、めちゃめちゃ不安でした。

学生自己紹介

企業プレゼンの後は自己紹介でした。東大、京大などの強い大学に加えて、学生起業してますとか学生団体の代表やってますっていう人がたくさん居ました・・・。「そんな強い実績ねぇよ！」と思いつつ、無難に自己紹介をしました。

休憩＆面談企業決定

昼食休憩の時間に面談企業が決定しました。自分と面談してくれるところがあるかどうか不安でしたが、ありがたいことに8社と面談が決まりました。

面談会

お昼後からはこのイベントのメインである面談でした。 1on1面談と言いつつ、エンジニア、人事担当、自分の3人で面談する企業が多かったです。

1企業につき25分の面談で、そのうち最初の5分は自己紹介プレゼンをしました。自己紹介プレゼンは好きなものから開発実績、なりたいエンジニア像を書いてました。

企業の方はこの自己紹介プレゼンの内容を元に質問をしてくるため、これから参加する人はちゃんと考えて書いたほうがいいと思います。

次に企業側からの質問ですが、主に聞かれたことは、

開発の詳しい内容
開発でどこをどういうふうに担当したか(チーム開発の場合)
どういった体験からなりたいエンジニア像・企業選びの軸が決まったのか

特に変わった質問はされず、ありきたりな質問だったのでちゃんと準備していれば答えられる内容だと思います。

こっちから企業への質問は、

就活生のどういったところを重視して採用しているか
自分のやりたい分野ができるか
会社の雰囲気

などを聞いていました。

こちらは事前に企業のHPなどを見て予め質問を用意していたほうがいいと思います。

僕は面談の合間の休み時間の15分で企業のHPを見て、軽く質問を考えていました。

こんな感じの面談を8回やるというまあまあなハードスケジュールでした。

面談後に懇親会もあったのですが、8回連続面談で体力をかなり使ってしまったので、参加せずビールを飲んで寝ました。

面談後

面談後には企業側からフィードバックが貰え、自分の強みや就活のアドバイスなどを頂きました。

この1on1面談イベントには、面談終了後に企業さんからスペシャルオファーを貰えることがあります。

スペシャルオファーとは企業さんが学生ともっと話したい、選考にエントリーしてほしいと思った場合に送るメールです。

内容は企業によって違いますが、そのメールに応じると1社につき5000円の義援金が貰えるという何とも太っ腹な制度です。

ありがたいことに僕自身もいくつかの企業さんからスペシャルオファーを頂いたので、面談やエントリーをしたいと思っています。

　イベントに参加して

この1on1面談イベントのメリット・デメリットを挙げるとこんな感じです。

メリット

企業を知るきっかけになる
企業と繋がりができる
面接練習になる
特別選考に進める可能性がある
モチベが上がる
お金が貰える

デメリット

連続面談は体力的にも精神的にもキツい
プレゼンづくりがめんどくさい

就活を始めていない人も、もうガンガン就活してるよって人も両方におすすめできるイベントだと思います。

直近だと2/6にあるらしいので興味がある方はぜひ！

talent.supporterz.jp

最後に

自分的にはこれが就活の第一歩目で、これからエントリーして選考に入っていくので、その過程もブログにしていきたいと思います。

読んでいただきありがとうございました。