その案件の主な言語とフレームワークは何か
最後に案件で使用した主な言語とフレームワークを追記しましょう。
私がこの業界に入った頃はフレームワークはまだまだ発展途上の段階でした。
過去に自分が作ったライブラリをどれだけ持っているか、コーディングレベルのお作法を知っているか、など言語の経験が重視されていました。
開発は人に依存する部分がとても多かった記憶があります。
しかし、現在の開発は色々なDB、バッケージを組み合わせシステムを構成し、更に外部システムやクラウドと連携したりします。
一つ一つを個人が開発していたら到底期限に間に合わず、それらを統合するモデルやフレームワークがなければ莫大な費用と時間がかかってしまいます。
フレームワークを扱ったことがあるということは、ものすごく仕事を効率的に進められますと言っているようなものです。
その案件で何を学び習得したか
前回までの「自分はどういう人間で何が得意でどう貢献できるか」、「何業界で仕事をしたのか」、「その案件での立場と主なタスクは何か」の3つのポイントで業務経歴書はほぼ完成しています。
もうひと押ししましょう。
IPA、独立行政法人情報処理推進機構(https://www.ipa.go.jp/)という経産省管轄の組織が、毎年IT白書やIT人材白書といった白書を発行しています。
白書では日本や諸外国におけるITの状態が分析され、将来こうなるよとわかりやすく説明されています。
そして、その白書に必ず出てくる言葉に
自己研鑚
があります。
その案件での立場と主なタスクは何か
何業界でどんな仕事をしてきたのかで、相手に同じ業界を経験したことをアピールし、安心感と親近感を持ってもらうことができました。
今回の面談が設定された案件について、話の切っ掛けを散りばめていきましょう。
担当者が欲しいという人材に合致するかどうかの判断は、案件の長さによって観点が変わり大きく2つに分類できます。
既に開発案件が始まっていて今すぐ人が欲しい短期の場合と、ビジネスユニットや部署の欠員を補充したい中長期の場合です。
案件の期間が長いほどどういう立場だったのか、短ければどのようなタスクだったのかが重視されます。
何業界でどんな仕事をしたのか
どんな言語を使ってきたのか? も重要ですが、どの業界の案件をやってきたのかの方がよほど重要です。
各経歴のタイトルにはどの業界のどんな仕事をやったのかを必ず書きましょう。
前回も書かせていただきましたが、人は相手に自分と同じ部分があると分かり合えると感じます。
もし今面談をしている担当者の方と過去に同じ業界の仕事をしていれば、その方は「言葉が通じるな」と安心します。
例えばこんな感じです。
自分はどういう人間で何が得意(好き)でどう貢献できるか
経歴を説明する前に簡単に自分を紹介しましょう。
もし相手が長期の契約を考えている場合は特にどのようなキャリアパスを考えているのかを気にします。
お互いのニーズを一致させ長く仕事をしてもらいたいからです。
SES(システム・エンジニアリング・サービス)はお客様に技術者を派遣することでその技術を提供するサービスです。
本来SESは専門家として技術者が得意とする技術を提供すればよいのですが、ほとんどの場合は派遣される会社の一員として技術者、兼ビジネスパーソンとして働くことになります。
経験の浅い技術者や面談で上がってしまう技術者は、この人とは一緒に仕事はできないなとビジネスパーソンとしての部分で断られてしまうことがあります。
