Progateを一周した。Udemyの講座も最後まで見た。簡単なアプリも作ってみた。
それなのに、仕事では今日もExcelを開いて手作業をしている。
学んだ知識を使う場面が、どこにもない。そのまま半年が過ぎて、書いたコードの内容もだんだん思い出せなくなってきた——そんな状態になっていませんか。
転職サイトで求人を見ると「実務経験1年以上」と書いてある。社内で「この作業、自動化できます」と言ってみたら「まずは今の仕事に慣れてからね」と返ってきた。
どこにも入り口がないように見えます。
ただ、実務経験は誰かから与えられるのを待つものではありません。社内の小さな改善、副業、公開できる成果物。この3つの入り口から、自分で作ることができます。そして作った経験は、言葉にして初めて他人に伝わります。
この記事では、その3つの入り口と、作った経験を人に伝わる形にする方法を整理します。
「学んだのに使えない」と感じる場面
転職活動で「実務経験は？」と聞かれて言葉に詰まる
一番きついのは、面接や書類選考のこの瞬間だと思います。
「Pythonは書けます」と言っても、次に来るのは「業務で使った経験はありますか」です。ここで、学習用に作った成果物の話をしても、相手の反応が薄い。そんな経験をした人は少なくないはずです。
求人票の「未経験可」を信じて応募したのに、詳細を読むと「実務経験1年以上尚可」と書いてある。尚可と書いてあっても、実際には経験者が優先されているように感じる。
学習期間は無駄だったのだろうか、という気持ちになります。
社内で提案しても「まずは慣れてから」と言われる
社内で活かそうとしても、また別の壁があります。
「この転記作業、スクリプトで自動化できると思うんですが」と言ってみる。返ってくるのは「今のやり方で回ってるから」「何かあったら困る」。
悪意があるわけではありません。上司からすれば、本業をこなしている人が慣れない技術で何かを作り、それが壊れたときの責任をどう扱うか判断できない。だから現状維持を選ぶ。無理のない反応です。
ただ、こちらとしては行き場がなくなります。
実務経験がないのは、あなたの努力不足ではない
「未経験可」の求人ほど実務経験を求められる矛盾
まず知っておいてほしいのは、この状況があなた個人の問題ではないということです。
「実務経験がないと採用されない。採用されないから実務経験が積めない」
この循環については、転職メディアや企業の採用広報でも繰り返し指摘されています。特定の誰かが力不足だから起きているのではなく、構造としてそうなっている。
企業側にも理由はあります。未経験者を採用すれば教育コストがかかり、戦力になるまで時間もかかる。経験者を採れる状況なら、そちらを選ぶ。合理的といえば合理的です。
でも、その合理性の外側に立たされている人が、確実にいます。
同じ壁にぶつかっている人は多い
学習を終えた人が最初にぶつかるのは、たいていこの壁です。技術的な難しさではなく、「学んだものを使う場所がない」という壁。
なので、まず「自分の勉強が足りなかったからだ」と考えるのはやめていいと思います。もう一つスクールに通っても、もう一冊参考書をやっても、この壁の形は変わりません。
変わるのは、経験を「もらう」前提をやめたときです。
実務経験は3つの入り口から自分で作れる
待っていても声はかかりません。であれば、経験のほうを自分で作りにいく。入り口は大きく3つあります。
① 社内の業務改善で実績を作る
今の職場にある「面倒な作業」を、自分のスキルで軽くする。最も身近で、最も許可を取りやすい入り口です。
自分の担当業務であれば、大がかりな承認を待たずに始められる場合もあります。
② 副業や小さな案件に挑戦する
社外から報酬をもらって、期日までに納品する。金額が小さくても、他人の要求に応えて成果物を出したという経験は残ります。
ただし、これを「実務経験」と呼べるかについては意見が分かれます。後ほど両方の立場を紹介します。
③ 成果を公開して見える形にする
作ったものを、他人が見られる場所に置く。GitHubなどのサービスを使えば、コードごと見てもらえます。
①と②で作ったものを、③で第三者に伝わる形にする。この組み合わせが現実的だと思います。
社内の小さな困りごとを解決してみる
「困っている作業」を探すところから始める
ここで一つ、正直に書いておきます。
「社内の業務改善テーマの見つけ方」について、公的機関がまとめた体系的な手順のようなものは、調べた範囲では見つかりませんでした。個人が書いた体験談は多くありますが、それらは一般化できるデータではありません。
なので以下は「こう考えると探しやすい」という整理として読んでください。
探すときの目のつけどころは、自分が毎回「面倒だな」と思っている作業です。
- 毎月、複数の部署から届くExcelを1枚にまとめている
- 同じフォーマットの請求書を、名前だけ変えて20枚作っている
- 定例会議の前に、決まったデータをコピーして資料に貼っている
派手さは要りません。むしろ地味なほうがいい。他人の業務に手を出すと調整が必要になりますが、自分の作業なら、まず自分の中で完結します。
対象が決まったら、次は何で作るかです。マクロ、VBA、GAS、Pythonのどれが向いているかは作業の性質によって変わるので、営業・企画職向けにPython/GAS/VBAの使い分けを整理した記事も判断材料になります。
そして最初は「上司に提案する」よりも「自分の作業時間を削る」ところから始めるほうがスムーズです。成果が出てから「実はこうしています」と伝えるほうが、話が通りやすい場面もあります。
一点だけ注意があります。社内のデータやシステムを扱うスクリプトを、そのまま外部に公開するのは避けてください。会社の情報管理規程や、作ったものの権利がどこに属するかは、会社によって扱いが違います。公開したい場合は、社内データを含まない形に作り替えるか、事前に確認をとってください。
改善した内容とその効果を記録しておく
これが、後で効いてきます。
作業を効率化したあと、多くの人はそこで終わります。でも記録を残していないと、半年後には「何かやった気がする」以上のことが言えなくなります。
その場でメモしておきたいのは、こういう内容です。
- 元は何分／何時間かかっていたか
- 何を使って、どう変えたか
- 変えた後は何分になったか
- 自分以外に使っている人はいるか
「毎週金曜に40分かけていた集計を、Google スプレッドシートのスクリプトで自動化して5分に短縮」。この一行があるかないかで、後の職務経歴書の書きやすさがまったく変わります。Google スプレッドシートまわりの自動化から始めたい場合は、非エンジニア向けのGAS入門で仕組みと学習手順を確認しておくと着手が早くなります。
数字は厳密でなくて構いません。効果の測り方に決まった正解があるわけでもないので、自分が説明できる範囲の数字で十分です。
副業や小さな案件は「実務経験」と言えるのか
ここは意見が割れているところなので、両方の立場を紹介します。
副業を実務経験として書けるという考え方
プログラミングスクールを運営するWEBCAMP MEDIAは、未経験からプログラマーの実務経験を得る手段の一つとして副業を挙げ、副業案件は履歴書に書ける経験になると説明しています。
考え方としては分かります。クライアントの要望を聞き、仕様を決め、期日までに納品する。この一連の流れは、会社の中でやっていることと大きくは違いません。
「まずは正社員で」という慎重な考え方
一方、エンジニア村（tabmac.co.jp）は、未経験からエンジニアのキャリアを築くには、まず正社員として開発案件に携わり経験を積み重ねる必要があるという立場を示しています。
こちらの言い分も理解できます。副業の場合、どこまでの工程に関わるかは案件によって差があります。チームでの開発、レビュー、運用・保守まで含めて経験できるかどうかは、受ける案件次第です（この点についての統計的な裏付けは確認できていません）。企業が「実務経験」と呼ぶときに想定しているのは、そこまで含んだものかもしれません。
どちらを選ぶか
なお、この2つはどちらも営利事業者の見解です。片方はスクール運営会社、もう片方はエンジニア支援事業者。それぞれの立場が意見に影響している可能性は、頭に入れておいていいと思います。
現実的には、こう考えるのがいいのではないでしょうか。
副業経験は、書いてはいけないものではありません。ただし「実務経験1年」と同じ重みで受け取られるとは限らない。だから、規模・期間・自分の役割を正確に書く。盛らない。それだけです。
そして、応募先が正社員での開発経験を重視するタイプの企業なら、副業だけで勝負しようとせず、社内改善の実績や公開している成果物と合わせて見てもらう。組み合わせで補うほうが現実的です。
成果を公開して「見える実績」にする
GitHubに公開する3つのメリット
作ったものは、他人が見られる場所に置いて初めて実績になります。
その置き場所として使われているのがGitHubです。プログラムのコードを保存・公開できるサービス、とまずは考えてください。
レバテックキャリアは、GitHubで公開する利点として次の3つを挙げています。
- サーバーを自分で用意しなくていい — レンタルサーバーの契約や設定が要りません
- 成果物とコードを一緒に見てもらえる — 動くものと、その中身を同時に提出できます
- GitHubを使えること自体が評価される — 開発現場で日常的に使われているツールだからです
3つ目は見落とされがちですが、実は大きいところです。GitHubを使った経験があるというだけで、「入社後の説明が少なくて済みそうだ」と受け取られる場合があります。
料金については、公開設定のリポジトリ（プロジェクトの保管場所）は無料で使えるとWEBCAMP MEDIAが説明しています。ただし利用条件は変わる可能性があるので、始めるときにGitHubの公式ページで確認してください。
GitHub Pagesで簡単に公開してみる
作ったものがWebページの形なら、GitHub Pagesという仕組みを使って、そのままインターネット上に公開できます。
手順はZennやnoteで個人の方が記事として公開しているので、実際に作業するときはそうした記事を見ながら進めるのが早いと思います（例：Zennの「ポートフォリオサイトの公開と公開手順【GitHub Pages】」）。HTML/CSSの学習からポートフォリオ公開までの流れは、GitHub Pagesでのサイト公開まで扱ったWeb制作入門の記事でも順を追って整理しています。
最初は設定でつまずくことがあります。ここで止まる人は多いです。ただ、一度公開までたどり着けば、次からは同じ手順の繰り返しになります。
作った実績を「使える形」にする
ここが最後の、そして飛ばされやすい工程です。
やったことがあっても、言葉になっていなければ、相手には何も伝わりません。
STAR法で状況→課題→行動→結果を整理する
転職エージェントのJAC Recruitmentは、職務経歴書に実績を書く方法として「STAR法」を紹介しています。
難しい話ではありません。次の4つの順番で書く、というだけです。
- S（状況）：どういう状況だったか
- T（課題）：何が問題だったか
- A（行動）：自分は何をしたか
- R（結果）：どうなったか
たとえば、さっきの集計作業の例をこの形に当てはめてみます。以下は実在の事例ではなく、書き方を示すための架空のサンプルです。
営業部5拠点から毎週届くExcelを、担当者が手作業で1枚の表にまとめていた（状況）。作業に毎回40分かかり、転記ミスも月に数回発生していた（課題）。Google Apps Scriptで、指定フォルダのファイルを自動で読み込んで集計するスクリプトを作成した（行動）。作業時間は5分に短縮され、転記ミスはなくなった。現在は同じ部署の3名が使っている（結果）。
同じ出来事でも、「Excelの集計を自動化しました」と書くのとでは、伝わり方がまったく違います。
担当フェーズや使用ツールを具体的に書く
マイナビ転職が公開しているプログラマー向けの職務経歴書の見本では、担当フェーズ・開発環境・メンバー数・役割を項目に分けて書く形式が示されています。
つまり、採用側が知りたいのは「どこまでを、何を使って、どういう立場でやったか」です。
自分の場合に置き換えるなら、こうなります。
- 担当した範囲（要望を聞くところから？ 作るところだけ？ 運用も？）
- 使ったもの（Python、Google Apps Script、スプレッドシートなど）
- 関わった人数と、その中での自分の役割
副業案件も社内改善も、この形に落とし込めます。「一人で全部やった」ならそう書けばいい。規模が小さくても、範囲が明確なら評価はできます。
同様のテンプレートはリクルートエージェントやdodaも公開しているので、書式に迷ったら参考にしてみてください。
たたき台を人に見てもらって確認する
書き上げたら、自分以外の目を通してください。
自分で書いた文章は、自分にとっては分かりやすいものです。でも、その業務を知らない人が読むと「何をしたのかよく分からない」ということが起こります。
社内の人に見せづらければ、転職エージェントに登録して見てもらう方法もあります。ただし、書類添削の対応範囲や条件はエージェントごとに異なるため、登録前にサービス内容を確認してください。
見てもらうときのポイントは一つ。「この文章から、私が何をやったか分かりますか」と聞くことです。伝わっていなければ、書き直す材料になります。
今日からできる小さな一歩
大きな決断は要りません。今日できることを2つだけ挙げます。
身近な「面倒だな」を一つ書き出してみる
今日か明日の仕事の中で、「これ毎回やってるな」と思う作業を一つ、メモに書いてください。
書くのは、作業の名前・かかっている時間・どのくらいの頻度でやっているか。この3つだけです。
自動化できるかどうかは、まだ考えなくて大丈夫です。まず「対象を見つける」ところまで進めば、次に何を調べればいいかが見えてきます。
GitHubアカウントを作ってみる
まだアカウントがないなら、今日作ってしまってもいいと思います。
公開するものが何もなくても構いません。アカウントがあるだけで、「何かできたら置いておこう」という置き場所ができます。学習中に作った小さなスクリプトでも、置いておけば後で見返せます。
まとめ
実務経験は、待っていても回ってきません。社内の業務改善、副業、公開できる成果物。この3つの入り口から、自分で作りにいくほうが早いです。
そして、作った経験は言葉にしないと伝わりません。STAR法のような枠組みを使って、状況・課題・行動・結果の順に整理する。担当した範囲と使ったツールを具体的に書く。ここまでやって、ようやく他人に届く実績になります。
副業を実務経験と呼べるかは、意見が分かれています。どちらかが正解というより、応募先がどちらのタイプかを見て、自分の持ち札を組み合わせて出すのが現実的だと思います。
一気に全部やる必要はありません。今週は、面倒だと思っている作業を一つ書き出すところまで。それだけでも、半年前と違う場所には立てます。
コメント