体験を伝える―『ガジェット通信』の考え方

面白いものを探しにいこう 本物を体験し体感しよう 会いたい人に会いに行こう 見たことのないものを見に行こう そしてそれをやわらかくみんなに伝えよう [→ガジェ通についてもっと詳しく] [→ガジェット通信フロアについて]

レジュメの書き方でオファー金額がアップする!?―moffersのキャリアアドバイザーに聞いてきた!

オファーが届くレジュメは、何をどう書くといいの?

企業から年収を明示したオファーが届く、ITエンジニアのためのスカウトサービス「moffers(モファーズ)」。

エンジニア特化型のレジュメ(職務経歴書)スタイルなので、これまでの開発経験や使用技術だけでなく、プライベートで作ったプロダクトもアピールでき、そして自分の希望年収ややりたいことも伝えられます。

ただ、登録するときに困りがちなのが「レジュメって、何をどのように書けばいいの?」ということ。
今よりプラスアルファの年収がもらえたら嬉しい。
どうアピールすれば、自分の実力を年収に反映させられるかわからない。

でも、実は書き方ひとつで、オファーの年収提示額を上げたり、希望する業界や開発プロジェクトのオファーを受けたりできるんです!

ITエンジニアのためのレジュメノウハウを、moffersのキャリアアドバイザーアキコさん、moffersリナさんに、根掘り葉掘り聞き出してきました!


こんな感じでmoffersのレジュメを書いてみたんですけど……どうですか?

■プロジェクト概要(目的・人数・体制など)

 ▽プロジェクト概要
 金融系顧客の既存業務システムの改修、新機能の追加の短期プロジェクト

▽プロジェクト目的
既存システムとユーザ業務が乖離していたために、業務に沿うようにシステム改修が必要であった。
また、システムを用いたユーザ業務の中で、データの確認作業の負荷が特に高く、データをグラフ化するなどでユーザの業務負担を軽減する必要があった。

例)一見しただけでデータが変化している/していない、数値が大きい/小さいなどが分かるようにする。

▽顧客からの要望
ユーザが多用するシステムのために、FW型の開発ではなくユーザと密にコミュニケーションがとれるアジャイル型の開発で、柔軟に対応を進めてほしいと顧客からの要望があった。

▽チーム体制
オンショア1名、オフショア1名で、オン側はユーザとのコミュニケーションよりの作業、オフショアは実作業よりの分担。

■プロジェクトにおける自身の役割

 ▽役割
 ユーザコミュニケーション、関連システム&関連チームとの調整。
 設計~開発~テストと一連の全作業、+オフ側の成果物のレビューなど。

▽工程
基本設計、詳細設計、開発、テスト、リリース、各種調整など一通り全て担当。
※有識者のサポートあり。

■当時の背景/抱えていた課題等

 ▽知らないことばかり、分からないことばかりの状態でのスタート
 ・新チームにアサイン後すぐのプロジェクト
 ・新チームで担当しているシステム知識、業務知識の不足
 ・主として使用されている言語がVBAで未経験の言語 etc

1 2 3 4 5 6 7 8 9 10次のページ
CodeIQ MAGAZINEの記事一覧をみる
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。