"転職"投稿一覧

Shinichi Kogiso

デザイナー

副業で良いと思う会社は以下の点です。

1. オーナーシップを持ってもらえる
2. 裁量を（ある程度でも）与えてくれる
3. 期待値調整を都度してくれる

基本的に副業は本業と比べると稼働時間がどうしても短くなります。
そのため、キャッチアップの支援はもちろん、動きやすくアテンドしてくれたり、コミュニケーションを取ってもらえるの... 続きを見る

Kono Naoko

デザイナー

自分は4社くらい掛け持ちしてるけど、まあそこからどうするかだなあ。
ケチな会社は辞めるし、社長の人柄と金払いじゃないかな。
倒産しそうなところからは逃げるけど、きつい業務、人間関係とかは、ある程度耐えられるので、上記2つが重要です。良いところは、業務を増やして、いやなところは業務を減らす。こうすれば、まあ良いところだけ残るよ。最初から、良いかどうかはわからない。

Taketo Yoshida

エンジニア

ただ経験を話すのではなく、何を考えて普段仕事しているかを伝えるようにしています。
特に数字などを入れる事を中心に考えていますね。

ABEChan@iOS/Android Developer

プロジェクトマネジメント

エンジニアが採用に関わる上で、人材の調達の観点でいうとやはりリファラルでしょうか。
またそのリファラル採用を後押ししてくれるような制度(社外の人とでもランチにいって少しでも自社のお話しをできたら対象)などもあるとなお良いかと思います。

都内SE

エンジニア

費用対効果、採用までの時間観点では、自社メンバーや付き合いのある人からの紹介が一番効果的でした。

新田智啓

エンジニア

元々何をやっていたか
どんなエンジニアがターゲットか
などの文脈によって打ち手は違います。

ですが、どんな場面でも効果があるのは報酬を1.5倍にするのが良いでしょう。
期待するエンジニアが来ない多くの原因は報酬が低いことも多いかなと思っています。

HIU Naoki

エンジニア

抽象化能力、これが全てです。

BON

エンジニア

自分が、興味あるかどうか。これに尽きると思います。興味がないと覚えないし、理解も遅いことが多いので。
人に興味なければ、コミュニケーションも大変でしょうし、新規技術に興味なければ知識が増えても対応力が減ることも。

Yamashita Shinichiro

エンジニア

副業で非同期メンバーが集まるとどうしてもコードレビューやライブラリアップデート、テストカバレッジなどCI/CDがいい加減になりがちなので、その辺の目線合わせが大事かなと思います。（これが腐っていくと色んなことがうまく回らなくなって人が離れる）

個々のメンバーが高い意識を持てればいいですがなかなか難しいので、強い意志をもって全体を俯瞰できるようなマネージャーの方が常に間に立つ、... 続きを見る

北山 淳也

エンジニア

日本国においては基本情報技術者試験/応用情報技術者試験など、情報処理技術者試験に含まれるものがいいのではないでしょうか。

情報処理技術者試験は、「情報処理の促進に関する法律（第７条）」に定められている経済産業大臣が実施する国家試験ですから、その他の国家試験ではない何かしらの検定などとは前提が異なるものです。
続きを見る

kentaro haneda（jumbo）

エンジニア

選考する側からするとgithubでの活動はOSSへの貢献などある程度、目的や背景がないとそれ自体から読み取れることが少ないので難しく思います。
githubでの活動量が多いことがネガティブになることはないですが、自分の実績やこれまでの活動をしっかり言語化して説明できる・履歴書から読み取れることの方が大事かなと思います。

Kono Naoko

デザイナー

a. Webデザイナーとしての仕事において、特にやりがいを感じる瞬間や楽しみを教えていただけますか？

（エンジニアやコンサルと比べ時給が低いので、達成感はないというのは置いておきます）

お客様から質問がほとんどない（わかりやすい）
お客様の申し込みが増える（サービスにもよる）
アクセスが増える（SEO的に成功している）
続きを見る

Kono Naoko

デザイナー

I get English headhunting from LinkedIn, Heys, Bizreach, etc.

Kono Naoko

デザイナー

自分はエンジニア～UX～デザインすべてやっています。
一つの会社で契約して、そのままどんどんできそうな仕事を任されるのが良いかと思います。
私は、マーケターとして採用され、デザイン、プログラミング、サポート、契約管理まですべてやっています。
先方としても、UXしかできない人より重宝すると思うので。
ただし、切られた時の保険として3社ほど契約しています。

Taketo Yoshida

エンジニア

- 採用側はGitHubのコードをどれくらい重要視しているのでしょうか？

端的に言えばコードに関してはそこまで重要視はしていません。業務時間内を多く使って見るほどの事をしていないですね。しかしプロフィールページは一応リンクがあればちゃんと見ます。そこで何か活発に活動されたり、レポジトリが並んでいると印象は良いです

・リポジトリやコードをチェックする際、何... 続きを見る

kentaro haneda（jumbo）

エンジニア

履歴書に記載があれば参考程度に見るかなとは思います。
ただ公開されているコードや参加したプロジェクトの背景などの情報が読み取れないので、あくまで参考や面接での会話のタネくらいにしています。それ単体で阪大することは基本的にないです。
個人の考えや意志がどれくらい含まれているかなどはなかなかリポジトリから読み取るのは難しいとおもます。ただOSSでの活動や、コミットの仕方、PRの投げ... 続きを見る

ABEChan@iOS/Android Developer

プロジェクトマネジメント

GitHubのリポジトリはあくまでも面談の際の話題の種として提出いただいております。
GitHub上のコードを厳密に精査して何かを判断するというよりは、そのリポジトリに関してお話しを広げていくことが多いです。なぜそのツールやOSS、機能を作るのにその言語やフレームワークにしたかやアーキテクチャーはどうしてそれを採用したのかなどお話を深掘りした際にどのようなお話しが対象者とできるかという観... 続きを見る

北山 淳也

エンジニア

・どういう課題をみつけたのか、どういう課題が存在していたのか
・それについてどのようなアプローチを行ったのか
・自身のアプローチによってどのように改善したのか、その後どうなったのか
・どのような成果につながったのか
・どのような評価を受けたのか
について具体的なエピソードを添えて書くことで、職務経歴書を読んでくれる人には「おっ」と思ってもらえやすい... 続きを見る

北山 淳也

エンジニア

Hey there!
Totally get how tough it can be searching for a job in Japan without knowing Japanese. Not sure what kind of gig you're after, but if you're into app development, companies like Rakute... 続きを見る

北山 淳也

エンジニア

公開できるコードが充実していること以上にアピールになることはない前提で、
コードを書くことが仕事の全てではないケース（マネジメントなど）においては
・記事執筆
・勉強会やLT会での登壇資料の公開
・具体的な課題発見/課題解決のエピソードが添えられている職務経歴書
かなと思います。
実際に、私の記事を見て〜と言ってアプローチをいただいた経験... 続きを見る