転職透明化ラボ-ここが残念だよ採用企業&応募者 カジュアル面談編 参加レポート
5/14に開催された、転職透明化ラボ-ここが残念だよ採用企業&応募者 カジュアル面談編に参加してきました。 詳細はここのページで。 rtlabo.connpass.com
内容メモ
- カジュアル面談とは、会社を知ってもらうためのもの。選考ではない。いわゆるイケてる企業は理解しているが、そうでない企業もある。理解ある企業なら事前準備は会社を軽く調べておくこと、そうでないなら経歴書を一応持っていた方が良い。
- 求職者に会って話し、会社を知ってもらい、ミスマッチでないことを確認する場でもある。ミスマッチは会社側も求職者側も不幸になる。ミスマッチなら、この時点で切る。
- カジュアル面談後に面接に進み、カジュアル面談の内容が面接官に伝わってない場合があるので、自分からカジュアル面談で話した内容を話して認識があっているか確認する。カジュアル面談の内容が面接官に伝わっていないことは、求職者側からは会社に危険信号が点る(人事とエンジニアの距離)。
- ベンチャー企業の人事は、少ない人数で回しており忙しいので応募を見逃すこともある。
感想
採用担当者と求職者が参加したイベントでした。求職者側は選考フローがどうなっているのか知りたくて、採用担当者側は選考の仕組み自体に興味があり、どちらも満たせていたのではないかと思います。カジュアル面談で会社と求職者のマッチングを確認するのはコストがかかりますが、会社側は面接をするよりコストが低いなら小さな失敗で済みますし、求職者側は面接の前に質問ができ、よく会社を知ることでモチベーションが上がることもあるでしょうしミスマッチと言われればこれからの努力の方向性を考えるきっかけをもらえるのではないかと思います。カジュアル面談は、オープンソースなどのエンジニア業界全体を良くしていこうというエンジニア文化が表れているものでもあると思います。
採用担当者の方がよく言っていたのが、求職者に会ってみないとわからないということでした。その人が経験してきたものによって考え方・文化・熱意・行動力などが異なります。それらは書類ではわからず、実際に会ってみないとわからないです。会社に合っているかどうか、確認してお互いに不幸にならないようにしようということでした。
懇親会ではストラップの色で求職者なのか採用担当者なのか分かるようにしていたため、お互いにスムーズに会話や質問ができていたように思います。良い試みだったと思いました。採用担当のエンジニアではあるが、転職活動をしている人はどっちになるのだろうか、と思いました。
ゲームセンターを楽しむ技術(仮)の原稿募集
合同誌で有名なonestopシリーズの編集長おやかたさん協力の下、ゲームセンターに関する合同同人誌を書きます。合同誌とは、一人で本を書くのではなく、複数人の書いた原稿をまとめて一つの本としたものです。その原稿を募集します。よくやっているゲームセンターのゲーム、楽しみ方をぜひ書いて下さい。次回のコミティア129での頒布を目指しています。落ちたら・・・委託します。
なぜ合同誌?
自分の文章を発信したいと思った時、思いつくのはSNSです。しかし、SNSよりも本であった方が多くの人に届く可能性が高いです。ですが、本にするとなると内容も量も求められることになります。1人だと大変ですが、複数人で本を書くことを考えましょう。内容の面では、人は今までの背景によって持っている知識・経験が違います。その人がうまく書けると考えて書いた内容ばかり書くことで、内容の濃い本となります。量の面では、例えば100ページの本を書くとします。1人が4ページしか書けなくても、25人いれば100ページの本が書けます。
今回はゲームセンターに関する内容です。私はDDRプレイヤーのエンジョイ勢なので、他のゲームジャンルについてやガチ勢が心がけていること・上達法はわかりません。ぜひ力を貸してください。書いていただける方はごまなつ まで連絡ください。
なぜこの本を書こうと思ったのか
ゲームセンターは経営が苦しくなっているようで、閉店が続いています。このままでは客が少なくなり、ゲームセンターがなくなってしまうと思います。今の状況を何とかしたいです。 そのためには、ゲームセンターに来たことがない人や昔行っていた人に来てほしいです。そのための、ゲームセンターの楽しさ・楽しみ方、ゲームセンターの現状、あるいは歴史的経緯をまとめた本を作りたいと思ったからです。ゲームセンターに行かない人がわからない部分をこの本で分かるようにしたい。ここが一番大きいところです。 タイトルは「ゲームセンターを楽しむ技術」を仮で考えています。
目次案
あくまでも案ですので、内容追加などどんどん提案をください。楽しみ方と上達法を分けていますが、各ゲームジャンルごとに楽しみ方と上達法を書いていく方がいいのか迷ってます。
ゲームセンターの歴史
- 昔のゲームセンターの面白かったところ
- ゲームセンターのイメージと今のゲームセンターの違い
- ゲームセンターの現状
ゲームセンターの楽しみ方
- 全般的な楽しみ方
- 音楽ゲーム(ダンスゲームはここに入れる)
- ゲーム自体がやりたい?曲を聴きたい?
- 格闘ゲーム
- コントローラ、2Dと3Dの違い
- クレーンゲーム
- プリクラ
- メダルゲーム
- クイズゲーム
- ガンシューティング
- シューティング
- レース
- アーケードカードゲーム
- アクション(ベルトスクロールとか、ビデオゲーム筐体でやるタイプのアクションゲーム)
- パズルゲーム(ぷよぷよ、テトリスなど)
- 初心者と上級者の付き合い方
ガチ勢とエンジョイ勢の楽しみ方
- 上達法(目標設定とPDCAなど)
- モチベーションの維持方法
- エンジョイ勢としての楽しみ方
- コミュニティ
ゲームセンターでのふるまい方
- 連コなどのマナー
- コミュニティなど人間関係
- マナーが悪い人への対処法
その他
- あなたの知らないゲームセンターの楽しみ方 ‐ 自分が好きなゲームセンター、良いゲームセンターの観点、各ゲーム好き向けのゲームセンター
- ゲームセンターじゃないとできない体験とは
- ゲームセンターに行くようになって経験した楽しいこと、変わったこと
- 本当にゲームセンターはお金がかかるのか?(ほかの趣味と比較して)
執筆・配布スケジュール
- 募集・環境構築終了 6月上旬
- 章目次確定:6月中旬
- 本文初稿:6月末日
- レビュー&追記:7月末日
- 入稿:8月上旬 発行 コミティア
を大枠なスケジュールとしたいです。(多少前後します)
形式
Re:View+Github+CI出力のpdfを基本。 当該リポジトリに招待しますので、GitIDを連絡ください。https://github.com/onestop-techbook/GameCenter 招待なくてもPRは上げられると思います。セルフマージOKなので、参加しておいたほうが便利かも、くらいのはなしです。
MD・プレーンテキスト、Word等での提出もOK。こちらでコンバートします。
想定ページ数:100ページ前後(上限なし)
原稿料
メイン記事 5000円/人+打ち上げご招待(ページ数によらず。ただし、3ページ程度以上を想定。(1ページ1000~1200文字相当)
コラムのみ:打ち上げご招待
原稿料支払いタイミング
発行後。(Amazonギフト券または打ち上げ時現金) 完成した本:3冊進呈。
免責事項
- 実際の案件・事象等について触れる場合、例示等に使う場合は、各章・コラムの著者の責任において情報の公開・秘匿範囲を定めてください。編集者、その他著者は、その点については一切責任を負いません。
- それぞれの執筆分担分における著作権は、著者に帰属します。
- その他については、適宜相談の上定めるものとします。
- 印刷費の著者負担はなし
同人誌発行主体
ごまなつ
想定印刷部数 未定
落ちた場合も委託予定
Gitリポジトリ
キーボードの話で登壇してきた話
今更ですが、4/2に「あなたの知らないキーボードの世界」というタイトルでサポーターズcolabで登壇しました。資料はこちらです。
なぜこの登壇をしてみようと思ったのか
エンジニアの方は、コードを書くのでキーボードを触っている時間が長いです。長く触れている椅子にはこだわる方が多いのに、キーボードにこだわる方は少ないです。さらに、PC操作をするのであればキーボードだけでなく、マウスに触れています。つまり、エンジニアでない方でもキーボードとマウスにこだわる意味はあります。今回は、キーボードについて話してみようと思いました。
反省
資料の話ではないですが、まだ話慣れていないなと感じました。聴衆の方がずっと黙って聞いてくださったのですが、あまりに反応がないためだんだん不安になっていきました。後半のキーバインド設定の話は、説明がうまくできませんでした。スライドにコードのようなものを載せる際に注意することを確認しておくべきでした。この2つによって、後半がしどろもどろになってしまいました。最後までうまく話しきれるように努力していきたいと思います。
発表内容に関しては、うまく伝わっていたかどうかはわからないですが伝えたいことを伝えられるように努力していきたいと思います。
『はじめる技術 つづける技術』を読んで
技術書典6で購入した中の1冊、『はじめる技術 つづける技術』を読んだ感想です。私は、何かを続けようとして習慣化しようとして失敗した人に特に読んでほしいと思います。
はじめることについて
やりたいことがないのは、やりたいことになるであろうことを知らないだけです。知ることから始めましょうということでしたが、その通りだなと思いました。趣味は、突然はまっていくことが多いですが、その時がやりたいことを知った瞬間なんだなと思いました。やらないことを選んでいるのは自分であり、やらない理由を探しているというのは、まさに自分だなと思いました。何かを始めるには、今始めるのが一番早いです。他人と比較せず、自分のペースで進め、過去の失敗にとらわれすぎないというのも重要だと思いました。未来について、失敗を恐れすぎず、失敗してもいいような状況にして失敗するのが良いと思います。しかし、一番重要なのは無理して始めようとしないことです。体調、心理状態もあるし、それが自分にとってやらなければならないことなのかということも考えようと思いました。
私は、ある物事をやる前に判断してしまうことがあります。それは自分の先入観によるものなので、先入観を持たないように、やっていないのに判断しないように心がけようと思います。
つづけることについて
やる気がないときはやらない!それについて罪悪感を持つ必要はない。続けるのはつらいことなのだから...... 確かにこれが重要だと思いました。習慣化するのが良いと聞き、習慣化しようとしたときに少し失敗したときに罪悪感を感じやめてしまうことがありました。やるにしても休むにしても自分で選ぶことで、考えるきっかけを作るようにしたいと思います。
周囲を意識してしまう、これは承認欲求ですね。SNSは簡単に情報発信とレスポンスができるからこそ、この悩みに直面する人が増えたと考えています。これで頑張れるなら無理しないよう注意する、心が折れるならほかのことをしてそちらの評価を待ったり、気分転換する。また、タイミングが悪かっただけかもしれないという要素が考えられることを知り、私が承認欲求とどう向き合うか考えていこうと思いました。効果については、成長にかかる時間・やり方を考え、内容について悩むことで止まってしまわないようにしたいと思います。
続けるのはつらいことです。よって、休むことの重要性に気づく、決めたことを守れなかったことで悩んで立ち止まらないということをこれから心に留めていこうと思います。
あとがきについて
これらの技術を紹介したあと、なんでこの本を書いたのか説明されていました。それは、はじめて続けて、楽しさを感じ、それを誰もが発信している世界が最高だからそうしたいとのことでした。私もこの本を読んで書いてある技術を実践し、何か楽しいことを発信する一人になれるよう頑張ります!
Go言語学習記録
ポインタ
C言語と同じようにポインタがある。
ポインタ型変数宣言は
var p *int = &n
ポインタの処理はCと同じ。メモリ番地と値の関係になっている。 アドレスの値を見たいときは*nのようにする。
s := make([]int, 0)は[]int m := make(map[stirng]int)はmap[string]int ch := make(chan int)はchan int var p *int = new(int)は*int var st = new(struct{})は*struct{}
makeとnewの違いは、ポインタを返すならnew, そうでないならmakeということ。
構造体
type Vertex struct{ X, Y int } func main(){ v := Vertex{X: 1, Y: 2} } fmt.Println(v.X, v.Y)
で1 2が表示される。 構造体の要素の名前が大文字だとpublic,小文字だとprivateになる。
var v4 Vertex v4 := Vertex{} v6 := new(Vertex)とv6 := &Vertex{}
はそれぞれ同じ意味になる。
func changeVertex(v Vertex){ v.X = 1000 } v := Vertex{1, 2, "test"} changeVertex(v) fmt.Println(v)
では、{1 2 test}が表示される。値は変わっていない。構造体の値を渡しただけで、本体は変わっていないため。
v2 := &Vertex{1, 2, "test"} changeVertex(v2) fmt.Println(v2)
では、&{1000 2 test}が表示される。fmt.Println(*v2)にすれば、{1000 2 test}が表示される
メソッド、ポインタレシーバー
//関数の書き方 func Area(v Vertex)int{ return v.X*v.Y } //メソッドの書き方 func (v Vertex) Area() int{ return v.X*v.Y }
構造体vがArea()という関数を持つようにするイメージ。 呼び出すときはfmt.Println(v.Area())でできる。 メソッドがvに紐づけられるので、v. とすると補完でArea()が出てくるようになる
func (v *Vertex) Scale(i int){ v.X = v.X * i v.Y = v.Y * i }
v.Scale(10)で呼び出せるが、もしこの関数のVertexのをなくすとこの関数が読まれなくなる。 この関数をポインタレシーバーという。普通の関数は値をもらうので値レシーバーということがある。
Embedded
goには継承がないが、Embeddedというものがある
type Vertex struct{ x, y int } type Vertex3D struct{ Vertex z int }
こうすると、Vertexにⅹとyは組み込まれているので、Vertex3Dはx,y,zを持っている. 書き方は
func (v Vertex3d) Area3D() int{ return v.x * v.y * v.z } func New(x, y, z int) *Vertex3D{ return &{Vertex{x, y}, z} }
goには継承がないが、Embeddedで同じことができる。
type MyInt int func (i MyInt) Double() int{ return int(i * 2) } func main(){ myInt := MyInt(10) fmt.Println(myInt.Double()) }
structではない自分だけの型のメソッドを作ることもできる。func (i MyInt) Double() intの中のiの型はmain.MyIntになっている。
ダックタイピング
type Human interface { Say() string } type Person struct { Name string } func (p *Person) Say() string { p.Name = "Hi, " + p.Name fmt.Println(p.Name) return p.Name } func DriveCar(human Human) { if human.Say() == "Hi, Mike" { fmt.Println("Run") }else{ fmt.Println("Back off") } } func main() { var mike Human = &Person{"Mike"} var x Human = &Person{"X"} DriveCar(mike) DriveCar(x) }
interfaceで指定したメソッド(今回はSay())を持っていないとエラーになる。絶対持っていてほしいメソッドを指定するときに使う。 Say()はポインタレシーバーになっているので、アドレスを渡す。func (p *Person)に&Person{"Mike"}を渡すということ。 この例では、 DriveCar(human Human)の時に、Humanは絶対にSay()を持っていなければならないというものになっている。 interfaceで指定したメソッドを絶対に持っていなければならないようにすることをダックタイピングという。
interface型、タイプアサーション
func do (i interface{}){}
のようにinterfaceを引数にするとどの型も受け取れるようになる。しかし、
func do (i interface{}){ ii := i * 2 }
はエラーとなる。interface型は四則演算ができない。そのため、
ii := i.(int) ii *= 2
としてタイプアサーションをしなければならない。つまり、interfaceには何でも入るが、入った段階ではinterface型なので、タイプアサーションをするひつようがあるということ。 stringは
ss := i.(string)
とする。 switch type文があり、これを用いて
func do (i interface{}){ switch v := i.(type) { case int: fmt.Println(v * 2) case string: fmt.Println(v * "!") default: fmt.Printf("I dont know %T\n, v) } }
とすると、どんな型でも受け取れる関数ができる。 goでは、一般的なキャストをタイプコンバージョンということもある。interfaceの要素に型をつけるのは、タイプアサーション。
type Person struct { Name string Age int } func (p Person) String() string{ return fmt.Sprintf("My name is %v", p.Name) } func main(){ mike := Person{"Mike", 22} fmt.Println(mike) }
こうすると、出力結果はMy name is Mikeになり、Ageを出力しないようにできる
カスタムエラー
type UserNotFound struct{ Username string } func (e *UserNotFound) Error() string{ return fmt.Sprintf("User not found: %v", e.Username) } func myFunc() error{ //something wring ok := false if ok{ return nil } return &UserNotFound{Username: "mike"} } func main(){ if err := myFunc(); err != nil{ fmt.Println(err)
とすると、自分で決めたエラーメッセージを表示できる。UserNotFoundがポインタになっているが、これをポインタにしなくても実行はできる。しかし、エラー内容の比較を行う際に問題が起きる。違うエラーとして定義して比較してもtrueになる。 ファイル入出力に使うライブラリにioがあり、その中にio.EOFがある。(EOFはEnd Of File)自分でErrors.New("EOF")として作っても、io.EOFとは違うEOFになることに注意する。エラーにはポインタを用いること。
倉貫義人 × 沢渡あまね トーク&ワークセッション「新しい組織・働き方のあり方」参加レポート
3/27に開催された、倉貫義人 × 沢渡あまね トーク&ワークセッション「新しい組織・働き方のあり方」に参加してきました。私のメモをまとめたものになります。うまく整理されていないかもしれませんがご了承ください。
管理とは?
日本語の管理は英語の3つの意味を持っている
- Management(やりくり)
- Control(統制)
- Administration(事務執行)
良い管理、悪い管理とは?
良い管理は、本来価値に振るコミットする仕掛けを作るため、本来価値へのコミットの障害を取り除くもの。 悪い管理とは、管理職が管理職であるためにやるもの。無駄な決裁など。
- 大企業になると、決まったことに経理、総務などが「法人をかませてください」などといった本質を見ていない管理が入る。子会社、支社だと、親会社、本社から本質を見ていない管理が入る。それに気づいた人は、本社飛ばし、親会社飛ばしをしている。
- 役割、部署が何のためにあるのか、本質を見ていない
- 社員を管理したいなら、それはコンピュータが得意なので任せればよい。わざわざ紙に印刷して人間が確認といった手間は無駄。
管理は必要悪である。しょうがないから管理をしている。しかし、管理はお金を生まない。管理がなくても生産性が上がるなら、管理に使っていた管理職の人件費が要らず、それが利益になる。管理は減らすべき。
管理の中にManagementがあるモデルはいまの時代に合っているのか
Managementは、「なんとかする」という意味。管理ではない。しかし、Control, Administrationは管理に近い。たくさん手を動かした人が成果を出せる仕事なら、管理すると成果が多く出る。しかし、今の仕事は毎日違う仕事をするし、誰もが同じ仕事をしていない。つまり、再現性が少ない仕事が増えてきたため、管理ではMagagementできない。Managementのほうが管理よりも上位概念なのでは?今の時代にはManagementの手段に管理が合わなくなっている。管理の仕方が昔と変わっていないのが問題。産業革命時代の製造業であれば、管理をすればするほど成果が出た。現在の日本では管理が製造業型であるため、このような状況になっているのではないか。
評価について
同じ仕事をしていないのにできる?実際は高い評価をつけるための作文ごっこや、ノルマが上がらないように評価をすり合わせたりする。まさにごっこ。出世をする人を決めないといけないので評価に差をつけろと指示が出る。しかし、みんな優秀だし、低くなった人はモチベが下がる。評価はもともとはランク付けするためではなく、気持ちよく仕事するためのものだったのでは?評価するよりも、その人のキャリアを一生懸命考えてあげることが必要。
性善説の管理になぜできる?
ソニックガーデンの採用基準は厳しい。入社前にかなり審査している。応募があってから入社まで1年から1年半かかる。その間は友達になる期間と考えている。友達になれるほど信頼しているから、性善説ができる。他にも、会社のビジョンと共鳴していれば、信頼できて性善説ができる。
性善説のいいところ
オペレーションコストが下がる。従来では信頼関係が構築できたのに、ガチガチなコミュニケーション(性悪説)をしているので管理コストがかかっている。 コストをどこにかけるのかの問題で、性善説は採用にコストをかけて、管理にコストをかけていない。 なぜ従来のようになるのかというと、入社ハードルが低いから、管理コストがかかる。管理はその人がいる間ずっとしなければならないので継続的なコスト。 採用コストは採用するときの一過性のものだからこのほうが効率いい。実質、友達であることが重要。
職場で本音を言えていますか?
一言で言えば心理的安全性があるかどうか。評価をなくしたのでやりたいことと業務のすり合わせの面談をしているが、そこでは何でも言っている。
本音が言えない背景6つ
- 勇気がない、怖くて言えない
- わざわざ言わない(時間かかる)
- 言語化できない(もやもやのままになっている)
- 気づかない、気づけない
- この人たちに言っても仕方がない(無力感)
- 得をしない
言えなくても、景色を合わせることができると簡単に解決することがある。それぞれの立場で意識はずれているので、現場に来てもらうなど景色合わせをすると良い。立場の話だと、もし自分が上司なら、自分から本音を言うと相手も本音を言うようになる。
組織の問題解決
今の自分の組織の問題点をみつける。働き方改革は言葉が重過ぎる。小さな課題でもいい。KPTのふりかえりをする。問題に対して考える、振り返りから始める。 自分たちで自分たちのことを認識しないと始まらない。 仕事のやり方を変えていくことを考える時間を作る。 進捗が遅れるのは何か悪い構造があるのではないかと考える。
木こりの斧
木こりが一生懸命木を切っているが、かなり遅い。旅人が見ると、斧がさびている。「斧がさびているから、研いだらどうか」「そんな時間があるわけないだろ」 これがどこでも起こっている。時間を手続きに置き換えてもよい。人間は意識では変わらないので、あらかじめ予定に入れておく。予定に振り返りの時間をあらかじめ決めておく。自分の気持ちに行動を頼らず、予定を入れておくと行動できる。
肯定ファースト
人間は肯定されることを望んでいる。肯定することから始める。相手に対してまず肯定する。褒めるのが難しくても、存在を認めること。何を言われても「そうか」、という。生産性が最も高いのは心理的安全性が高い状態である。
論じてばかりで実行されない
- そもそも、問題を言語化できていない可能性
- 自分なら、実行する。他人なら、ほっとくと良い。どういうことかというと、他人に期待しすぎている。自分を変えられるのは自分だけ、これはすべての人に当てはまるので他人を変えることはかなり難しい。
問題解決の仕方
相手のキーワードを見つける。リモートワークを認めれば優秀な人が採れるとか。部署と役割で定義をした瞬間動かなくなる。総務がこうなるからというと戦えなくなる。 人の名前で考えてその人のところに行けばいい。人対人は話せる。それで動かないから仕方ない。会社を変えるために提案の形をとってはいけない。 上司は何か言っておかないととなる。相談の形で行く。こうするべき、という提案をするとと反発される。これで困ってるんですけど、どうしたらいいですかね…と相談するとよい。提案より相談。別に上の立場が下に相談してもよい。そのほうがやる気が出てうまく回る。
最後に
自分の力で他人をコントロールすることはできない。が、変わるきっかけを作ることはできる。目の前でできる人がいると変われる可能性がある。つまり、自分の周りでできることをやっていく。周りとコラボレーションするか、自分でやるかは自分で決める。自分のことを何とかしていくしかない。自分が成長実感を持つ。ロールモデルを見つける。自分がつぶれない、染まらないようにする。絶対にアウトプットする。
感想
まず、何よりもお二人のお話が面白く、聞いていてとても面白かったしためになりました。性善説の管理の話はすごく腑に落ちました。当たり前ではありますが、能力があるから、信頼できる人であるからそのような管理ができるということですね。採用にコストをかけて管理にコストをかけないというのはとても合理的だと思いました。自分にできることをやっていく、自分を何とかするというのは今の自分のテーマなので、地道に自分がコントロールできる範囲で努力していこうと思いました。
転職LT #4 参加レポート
はじめに
3/25に開催された、転職LT#4 〜春の転職まつり〜 【はじめてのイベント参加歓迎】に参加してきました。最初にイベント初参加の方~?という質問があったのですが、多くの方が初参加でした。初めての方にも優しいイベントということが分かる出来事だったと思います。
スポンサーLT
スポンサーLTではありましたが、転職に関する知見もお話しいただ来ました。ありがとうございます。
株式会社DIVE INTO CODE様
転職したいというエンジニアは、転職したい、という未来へのことに目が向きがちです。しかし、転職をするのであれば
- 今まで何をやってきたか、今どうしているか、長所と短所という過去と現在の棚卸を先に行い、先の5年、3年、1年それぞれでWill,Want,Mustを具体的に言語化します。
- その後、理想の自分を達成するため、具体的な行動指針を決めよう。
というお話しでした。
株式会社giftee様
転職はしていないが起業した@i7a16kさんのお話しでした。同期の起業を手伝うことで起業しましたが、起業はガチャ要素が大きいです。 起業は、以下の点を考えようということでした。
- 副業からかかわる形を検討
- 事業への興味があるか
- メンバーと働きたいか
- 事業の将来性があるか
- ファイナンス知識を持っておく必要がある
- 自分なりの撤退ラインを決める
転職活動の際に、SIerだからと卑下しなくてよいというお話もありました。VTRyoさんからSIerのスキルはB向けに活きるため、B向けSaasの企業にはSIer出身は重宝されるという補足もありました。
株式会社リブセンス様
GWは長い時間をとることができるので、そこで
- 自分は何ができるか(それを示すためのアウトプットの方法)
- 自分は何がしたいか(どんな会社?どんな技術使いたい?どんなエンジニアになりたい?なぜ?)
をしっかり考えることができます。
転職活動することに意味があるので、転職活動を楽しんでやっていこうということでした。
転職成功者LT
@ryokky59さん
- 退職してからエンジニアになるための勉強を始めた(1日10時間以上勉強)
- 転職活動中、エージェント経由で面接を20回以上こなしていたため、Twitter転職をした際に面接で将来どうなりたいかなど、難しい質問を答えることができた
- twitter, qiitaで学んだことをアウトプットしていたため、Twitterで転職宣言すると声がかかった。
行動力がすごい方だと思いました。アウトプットしていると、自信がついていくんだということもわかりました。Twitter転職は、自信があって客観的にスキルがあると思われないと成功しないものなんだなとあらためて思いました。
VTRyoさんの補足:githubだけで勝負しても、コードしか載っておらず、全部を見ることが難しい。自分でエラーを解決したかどうかがわからないので採用側は不安要素になる
@okash1nさん
所属企業にTwitterアカウントがバレている状態でTwitter転職の宣言をした結果、企業に混乱をもたらしてしまったというお話しでした。 気を付けることは、
- 退職が受理される前にツイートしない
- 会社が自分についてどう考えているかを考える(不義理になる)
です。現在、会社に依存しない時代だからこそ、人付き合いが大切です。SNS転職だからこそ、人付き合いが大切になります。入りたい会社の人が主催、参加している勉強会で関係構築しておくと良いのではないかということでした。
一般LT
@nomizoooneさん
職務経歴書、フォーマット決まってないんだから自分で作ろうよ、というお話しでした。実際に@nomizoooneさんの用いた職務経歴書は、とても見やすいものでした。また、面接では高確率で自己紹介が一番最初なので、自己紹介の練習はしておこう、緊張しにくくなるよということでした。
VTRyoさんの補足:Wordのスキルを証明するために、職務経歴書を自分でWordで作成した人がいた
tofu511さん
転職を始めた当初は内定が出なかった。Railsに挫折したが、Javaを用いていたためScalaはできた。Scalaを用いてポートフォリオを作ると順調に進んだ。転職できると、自分がコントロールできないことで思い悩むことが減った。自分で変えられる環境に行ければ、前向きにどう変えるのがいいか考えられるようになる。転職活動は失敗して、学んで改善していくことが重要。困ったら周りに助けを求めるようにしようということでした。
最後にVTRyoさんからひと言
行動力が重要。人と絡んでいく姿勢がいつか実を結ぶ。
感想
転職成功した方は、行動力が本当にすごい人たちだと思いました。自分も、行動力を高めていきたいと思います。とりあえず、GWにはまとまった時間が取れるので、過去、現在、未来のキャリアを考えて、具体的な方策を考えようと思いました。また、アウトプットをして自信をつけていったり、人とのかかわりを大切にしていこうと思います。