昔プログラミングの仕事をしていたけれど、その経験を今の職務経歴書に書いて意味があるのだろうか。
50代になって仕事を探していると、そんなことを考えることがある。
特にIT業界は変化が速い。
Python、クラウド、AIなど新しい技術が次々と登場する一方、昔使っていたVB6や古いデータベース技術を見ると、「こんな経験を書いても評価されないのでは？」と思ってしまう。
しかし最近、求人を見たり自分の職務経歴を整理したりする中で、少し考え方が変わってきた。
昔のプログラミング経験は、単なる「古い技術の経験」ではない。
書き方次第では、今でも十分に自分の強みとして使える。
今回は、昔のプログラミング経験を職務経歴書でどう生かせばいいのか、自分なりに整理してみたい。
「VB6を使っていました」だけでは弱い
昔の経験を書くとき、最初にやってしまいがちなのが使用言語だけを書くことだ。
例えば、
「VB6を使用したシステム開発」
これだけだと、採用する側には詳しいことがほとんど伝わらない。
VB6を使って何を作ったのか。
どんな機能を担当したのか。
データベースは何だったのか。
設計から担当したのか、テストだけだったのか。
既存システムの改修だったのか、新規開発だったのか。
同じ「VB6経験5年」でも、実際にやってきた仕事は人によって大きく違う。
だから重要なのは、言語名そのものよりも、
「その技術を使って何ができるのか」
を書くことだと思う。
古い技術でも現場では残っている
IT業界の記事を読んでいると、最新技術ばかりが目に入る。
しかし実際の求人を見ると、昔から使われているシステムの保守や改修案件もある。
企業や官公庁、金融などの大規模システムは、一度作ったからといって簡単に全部を新しい技術へ置き換えられるわけではない。
そこで古い技術を扱った経験が必要になることがある。
例えばVB6。
新規システムを今からVB6で作るケースは少ないだろう。
それでも、
既存VB6システムの保守。
仕様調査。
障害対応。
新システムへの移行。
VB6から別言語へのマイグレーション。
こうした仕事なら、昔の経験が生きる可能性がある。
つまり「古いから価値がない」と一括りにする必要はない。
むしろ、経験者が減っている技術だからこそ、そのシステムを知っている人が必要になる場合もある。
言語ではなく「やったこと」を分解する
自分の昔の経験を職務経歴書に生かすなら、一度仕事を細かく分解した方がいい。
例えばVB6なら、
画面開発。
帳票作成。
ファイル処理。
データベースアクセス。
Excel連携。
外部プログラムとの連携。
API利用。
テスト。
障害調査。
既存コード解析。
こうして分解すると、単なる「VB6経験」ではなくなる。
特に既存システムを読みながら原因を調査した経験は、現在でも使える能力だと思う。
プログラミング言語が変わっても、
「既存コードを読む」
「仕様を理解する」
「原因を切り分ける」
「修正する」
「テストする」
という仕事の流れそのものは消えないからだ。
データベース経験もセットで書く
プログラムだけを書いて終わらせるのも、少しもったいない。
業務システムではデータベースを扱うことが多い。
SQLを書いた経験があるなら、それも一緒に整理しておきたい。
SELECT文を書いた。
JOINを使った。
データを抽出した。
UPDATEやINSERTを扱った。
テーブル構造を確認した。
障害調査でデータを調べた。
こうした経験は、VB6とは別のスキルとして見ることもできる。
昔VB6と一緒に使っていたSQLの知識が、現在の別システムでも役立つ可能性はある。
「VB6しかできない人」ではなく、
「業務システムとデータベースを扱ってきた人」
として見せることが大切だと思う。
開発工程を書くと経験の厚みが出る
もう一つ重要なのが、どの工程を経験したかだ。
基本設計。
詳細設計。
製造。
単体テスト。
結合テスト。
総合テスト。
運用・保守。
同じプログラマーでも、製造だけを担当してきた人と、設計からテストまで経験した人では印象が違う。
昔の案件でも、工程経験までなくなるわけではない。
例えば20年前に詳細設計書を作った経験でも、
「設計書を読んでプログラムに落とし込む」
という経験自体は残っている。
長くIT業界にいる人ほど、技術名だけではなく、こうした工程経験を整理する価値がある。
「昔やった」で終わらせない
ただし注意したいこともある。
昔経験したからといって、今すぐ同じレベルでできるとは限らない。
10年以上触っていない技術を「得意です」と書けば、面談で詳しく聞かれたときに困る可能性がある。
だから職務経歴書では、
「実務経験あり」
「過去に○年間使用」
「直近では使用していない」
など、現在の状態が分かるようにした方がいい。
昔の経験を大きく見せる必要はない。
できることと、今は忘れていることを自分で把握しておく。
その方が面談でも話しやすい。
最近の経験とつなげる
昔の経験を生かすうえで、かなり重要だと思うのが「現在との接続」だ。
例えば、
昔：VB6＋データベースを使った業務システム開発。
現在：SQLを復習。
さらにPythonでデータ処理を勉強。
このようにつなげる。
すると、
「昔VB6をやっていた人」
だけではなく、
「業務システム開発の経験があり、現在も新しい技術を学んでいる人」
という見せ方ができる。
50代のIT人材の場合、この「昔＋現在」の組み合わせはかなり重要なのではないかと思う。
若いエンジニアと同じ方法で競争する必要はない。
長年の経験を土台にしながら、現在必要な技術を少しずつ追加していけばいい。
職務経歴書は「技術の年表」ではない
以前は職務経歴書を、
「どこで何年働いたかを書く書類」
くらいに考えていた。
でも仕事を探すようになって、少し違うと思うようになった。
職務経歴書は、
「自分をこの仕事でどう使えるかを相手に伝える資料」
でもある。
だから昔の案件をすべて同じ分量で書く必要はない。
応募する仕事に関係する経験を詳しく書き、関係が薄い仕事は短くする。
VB6案件へ応募するならVB6経験を前に出す。
SQLを使う仕事ならデータベース経験を強調する。
テスト中心の仕事ならテスト工程を詳しく書く。
応募先によって、見せ方を変えてもいい。
50代だからこそ経験を棚卸しする
20代なら職歴そのものが短い。
しかし50代になると、かなりの年月を働いている。
その中には、自分自身が忘れている経験もある。
昔作ったプログラム。
トラブルを解決した経験。
設計書を作った経験。
データを調査した経験。
利用者から問い合わせを受けた経験。
新人に仕事を説明した経験。
一つひとつは小さくても、全部を整理すると自分の強みが見えてくる。
新しい資格を取ることも大切だ。
新しい言語を勉強することも大切だ。
しかし、その前にすでに持っている経験を掘り起こすことも同じくらい重要なのではないだろうか。
まとめ｜昔の経験は「過去」ではなく材料になる
昔のプログラミング経験を、そのまま昔話にしてしまうのはもったいない。
VB6のような古い技術でも、
何を作ったのか。
どの工程を担当したのか。
どんなデータベースを使ったのか。
どんな問題を解決したのか。
現在のスキルとどうつながっているのか。
ここまで整理すれば、職務経歴書の見え方は変わる。
もちろん、昔の経験だけでこれからずっと仕事ができるとは思わない。
新しい技術も学ぶ必要がある。
それでも50代には、20代にはない長い実務経験がある。
「古い経験だから消す」のではなく、「今の仕事で使える形に翻訳する」。
これが昔のプログラミング経験を職務経歴書に生かす一番大切な考え方なのではないか。
自分自身も、昔やってきた仕事をもう一度整理してみようと思う。
忘れていた経験の中に、次の仕事につながる材料が残っているかもしれない。
コメント