ガジェット通信 GetNews

見たことのないものを見に行こう

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

▽ユーザの要望との認識齟齬
・作成した画面のレイアウトや表示形式が、ユーザのイメージと異なる場合に出戻りが発生すると予測した

■課題に対して自身が発揮したバリュー及び成果

 ▽キャッチアップのスピードと一歩踏み込んだ知識の獲得
 短期のプロジェクトだったため、業務外でのインプット(参考書、資格etc)、
 過去の類似案件や類似対応をもとに、早い段階で必要最低限の知識を身につける
 ことができた。
 また、その際に出た疑問点、不明点などは、既存の設計書やソースをもとに、
 自ら調査を実施した後に有識者にQAすることで、システム的にも業務的にも一
 歩踏み込んだ知識を身につけることができた。

▽作業の前倒しによる+αの顧客要望対応
上記のキャッチアップを元に前倒しで作業することができていたため顧客の要望を追加で引き出し、期間内に対応することができた。
作業途中で今回のスコープ外の既存のシステムでの問題点を発見し、調査を実施、改修方針や対応方法を立て顧客に提案、その後、顧客からの追加開発の承認を得ることができた。

▽成果物をベースにした顧客コミュニケーション
早い段階で動くモノ、見せれるモノ(簡単なモックetc)を作成し、それをベースにユーザとコミュニケーションを取ることで、お互いの認識の齟齬を減らすことができたこと。
予想していた出戻りもほとんどなかったこと。

■総括
顧客とのコミュニケーションの取り方としてお伺いベースではなく、提案ベースのコミュニケーションをする事を心掛けていたために案件を主導すること。
簡単なモックや画面イメージなど「動くモノ、見えるモノ」をもとに、お互いの認識をすり合わせることはよくあるが、加えていくつかのパターンで顧客に提案することで、顧客側でも最終成果物のイメージがつきやすくなること。
上記は今後のプロジェクトの進め方として参考になった。

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