35歳で3回目の転職をしました。

SESの開発現場から、大手のコンサルファームへ移ります。

不満があって辞めたわけではありません。

2年言い続けても変わらなかったこと、そして次にやりたいことが見えたことが理由です。

全15回で、決めるまでと決めたあとを書きました。

この記事はその目次です。

書いている人

文系の学部を出てから、独学とスクールを経てIT業界に入りました。

そこから10年、だいたいこんな順番で働いています。

1. 業務システムの保守・改修
2. 事業会社のIT企画部に常駐して、要件定義、業務フロー設計、RPAでの業務改善、システム導入支援など
3. 事業会社の社内SE
4. SESで客先常駐の開発

転職は今回で3回目です。

1回目は給与が動機で、2回目は残業で体調を崩して辞めました。

そして3回目が、このシリーズの話です。

第1部　なぜまた動いたのか

今の会社に強い不満はありませんでした。

人間関係も悪くありませんし、給料も前職を超えています。

それでも動いた理由から始めます。

2年ほど「開発を抜けたい」と言い続けて、変わらなかった話です。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

商流を上げても消えなかった限界について書きました。

#2 SESで感じた限界 3年前に「SESやめとけは本当?」という記事を書きました。 そのときの結論は、商流を上げれば解決するというものです。 そこから実...

10年でいちばん楽しかった時期の話です。お礼を言われたことはありませんでした。

#3 情シス時代がいちばん楽しかった理由 IT業界10年で、いちばん楽しかったのは事業会社のIT部門にいたときです。 ただ、感謝されたから楽しかったわけではありません。 ...

第2部　開発現場の3年

ここだけは転職の話ではありません。

客先常駐の現場で、技術以外にやっていたことの記録です。

転職活動の話だけ読みたい方は、第3部から読んでもらって大丈夫です。

ただ、未経験の職種に移れた理由はこの2本にあると思っています。

残業でチームが重くなったときに、お菓子を配っていた話です。

#4 残業70時間のチームでやっていた3つのこと このシリーズは転職の記録ですが、この記事だけは転職の話ではありません。 客先常駐の開発現場で、技術以外にやっていたことの話です。 ...

自分のテストをすり抜けたバグを、自分で見つけたときの話です。

#5 総合(システム)テストフェーズで気づいた、単体テストで見逃していたバグの話 開発の現場で、いちばんショックだった出来事の話です。 総合テスト（システムテスト）のフェーズに入ってから、自分が担当したプログラム...

第3部　転職活動編

実は、前の年にも転職活動をしています。

そちらは何も決まらずに終わりました。

その反省と、今回の準備の話です。

職務経歴書のテンプレートも、この部で配布しています。

13社受けて書類は全部通ったのに、何も決まらずに終わった年の話です。

#6 2025年の転職活動はうまくいかなかった 今回の転職の1年ほど前にも、転職活動をしていました。 結果は、内定2社を辞退して、本命には最終面接で落ちるというものです。 つま...

キャリアの王道から外れる不安について。今も消えていません。

#7 SEの王道を外れるのが怖かった話 PG から SE、そして PL・PM、その先にコンサル。 これがSEの王道だと、ずっと思っていました。 そして自分は、そこから外...

全12ページの構成と、書き方で変えたところです。テンプレートも置いています。

#8 35歳SEの職務経歴書 書き方で変えたこと 職務経歴書は、転職のたびに書き方を変えてきました。 今回はSEからコンサル寄りの職種に移るので、見せ方もそれに合わせています。 ...

聞かれたことと、こちらから聞いた逆質問6つをそのまま載せました。

#9 コンサルの面接で聞かれたこと 逆質問は6つに絞った 未経験でコンサルの面接を受けました。 しかも1次と2次が1回にまとまったので、聞ける機会は1回きりです。 なので逆質問は6つに絞...

第4部　決断

このシリーズの中心になる4本です。

引き留められて本気で悩んだ話も、ここに入れました。

実は数年前、同じ会社を書類選考の段階で辞退していました。

#10 一度辞退した会社に結局入社することになった 今回入ることになった会社は、実は一度こちらから辞退しています。 しかも面接を受ける前、書類選考が通った段階で断りました。 それが...

シリーズの中心になる記事です。会社ではなく経験の置き場所を選びました。

#11 35歳未経験でコンサルを選んだ理由 3回目の転職で、大手のコンサルファームに行くことにしました。 コンサルは未経験です。 会社の名前で決めたと思われるかもしれません...

退職を伝えたら、未公開の事業計画を見せられた話です。かなり迷いました。

#12 退職を伝えたら3か年計画を見せられた話 退職を伝えたあと、事業部長と1対1で1時間話しました。 そこで引き留めていただいたのですが、正直かなり心が動きました。 不満があ...

上がった理由と、前回は逆に下げて入っていた話を書きました。

#13 転職で年収が約200万上がった 3回目の転職で、年収が約200万上がる見込みになりました。 数字だけ見ると、なかなか景気のいい話に見えると思います。 ただ、手放...

第5部　その後

退職が決まってからの1か月と、10年の振り返りです。

引き継いで終わるはずが、最後がいちばん忙しくなりました。

#14 退職が決まってからの1カ月がいちばん忙しかった 退職が決まったら、あとは引き継いで流しながら終わるものだと思っていました。 実際は、最後の1カ月がいちばん忙しかったです。 土曜...

強い後悔はないけれど、小さいものが積み上がっていた、という話です。

#15 10年で後悔していることと、40歳までにやりたいこと シリーズの最後に、10年を振り返っておきます。 先に書いておくと、強く後悔していることはありません。 ただ、小さいものがチリツモ...

前回までの転職の記録

1回目と2回目の転職も、同じように記録しています。

あわせて読むと、判断の変わり方が分かると思います。

1回目は給与が動機で、2回目は体調を崩して辞めました。

同じ人間でも、選ぶ基準はけっこう変わるものですね。

7年目で初の転職活動! 2カ月で内定獲得した記録(目次) 私はつい先日、7年ほど勤めた会社を退職して、新たな会社へ転職しました。 コロナ禍という、一般的に見れば逆境？の中で内定もい...

(目次)東南アジアをバックパッカーしながら転職活動をした記録 東南アジアをバックパッカーしながら転職活動を約1カ月ほど行いました。 周った国は、タイ、カンボジア、ベトナムです。 ...

このシリーズで書かなかったこと

先に断っておきます。

転職先の社名は書いていません。

前職や、受けて落ちた会社の名前も出していません。

在籍中の会社が特定されると困る方もいますし、私自身もまだ働いている段階で書いています。

なので、会社の情報ではなく、判断の中身を読んでもらえたらと思っています。

年収についても、上がった幅だけを書いて金額そのものは出していません。

まとめ：1年後に答え合わせをします

正直に言うと、この転職が正解かどうかはまだ分かりません。

未経験の職種なので、やっていけるかの不安もあります。

このシリーズは決めるまでの記録なので、結果は書けていません。

なので1年後に、続きを書くつもりです。

うまくいっていればそう書きますし、そうでなければそれも書きます。

同じように迷っている方の、判断材料になれば嬉しいです。

3回目の転職をすることにしました。

次は大手のコンサルファームで働きます。

ただ、今の会社に強い不満があって辞めるわけではありません。

むしろ退職を伝えた後に引き留めていただけるくらいには、悪くない関係でした。

#12 退職を伝えたら3か年計画を見せられた話 退職を伝えたあと、事業部長と1対1で1時間話しました。 そこで引き留めていただいたのですが、正直かなり心が動きました。 不満があ...

それでも動いたので、その理由を書いていきます。

今回は「不満があって辞める」転職ではなかった

2回目の転職は、残業が半年平均で60時間になって体調を崩し始めたことがきっかけでした。

(目次)東南アジアをバックパッカーしながら転職活動をした記録 東南アジアをバックパッカーしながら転職活動を約1カ月ほど行いました。 周った国は、タイ、カンボジア、ベトナムです。 ...

あのときは、辞める理由の方がはっきりしていました。

今回は違います。

人間関係で困ったことはありませんでした。

客先からの評価も悪くはなく、上流の工程も任せていきたいと言ってもらえていました。

給料も3年で前職を超えていました。

それでも動いたのは「次が見えなかった」から

前回の転職活動で、退職理由と転職理由は別物だと学びました。

転職して1年半後、1ヶ月で複数内定がもらえた理由 面接は相互理解 転職活動×東南アジアバックパッカーの目次ページはこちらです。 23年4月末でから有休消化をしつつ、転職活動をしまし...

辞めたい理由がなくても、次にやりたいことがあれば動く理由になります。

今回はまさにそのパターンでした。

逆に言うと、辞めたい理由がないぶん、決めるまでにかなり迷いましたね。

「開発を抜けたい」と2年言い続けたけど変わらなかった

今の会社はSESで、客先に常駐して働く形です。

入社した理由は、求人の内容がPMやコンサル寄りの案件だったからです。

ただ、応募のときにこう言われていました。

「最初は開発の案件から入ってもらいます」

私は開発の経験が1年ほどしかなかったので、これは納得できる話でした。

1年くらいならむしろ経験になるな、と思っていたんですよね。

実際、開発の経験はしっかり積めました。

ただ、そこから抜けられませんでした。

2年目に入るときの1カ月の待機

最初の案件が終わったとき、次の現場が決まらず1カ月ほど待機になりました。

当時は営業の人数が少なく、社内があまり上手く回っていない時期でもありました。

とりあえず受けておいて、と言われた面談はこんな内容です。

• インフラ案件で、セキュリティパッチの適用やシェルを作る現場
• 大手企業の傘下の開発枠を丸ごと受けて、PMとして一人で入る案件

方向性、バラバラですよね。

結局決まったのは、医療系の装置の組込開発でした。

会社として売上が必要なのは分かるんです。

ただ、案件の選び方が適当すぎると思ってしまいました。

人事給与システムの現場は悪くなかった

その次に入った、大手企業の人事給与システムの案件は良い経験でした。

1年と少し在籍して、設計から総合テスト、リリース作業まで一通りやりました。

残業は月30時間から75時間くらいです。

離任の直前には、休日出勤も2回ありました。

忙しくはありましたが、業務も知ることができて悪い経験ではありません。

むしろ、色んな機能の設計や作業の段取りをがっつり経験できたことは良かったと思っています。

それでも、次もまた開発だった

離任のタイミングで、次の現場の話を聞きました。

大きい会社ではありましたが、聞いた内容からおそらくまた開発だろうと分かりました。

私は2年ほど、営業や自社のリーダーにこう言い続けていました。

「開発を抜けて、PMやコンサル寄りの案件にシフトしたい」

1on1でも評価面談でも、言い方を変えながら伝えてきたつもりでした。

でも、変わらないんですよね。

開発未経験の人が、PMOの案件に入っていた

もうひとつ、引っかかっていたことがあります。

社内を見ていると、開発の経験がほとんどない人がPMOやコンサル寄りの案件に入っていました。

もちろん、その人たちに問題があるという話ではありません。

ただ、自分は何で入れてもらえないんだろうとは思っていました。

開発をやったぶん、むしろ遠ざかっている感覚すらありました。

怒りというよりは、じわじわと諦めになっていった感じです。

熱が落ちていたところに、前に辞退した会社から連絡が来た

正直に言うと、このときの私は転職したい熱が落ちていました。

諦めていたので、しばらくは今の現場で経験を積もうと思っていたからです。

そこに、コンサルファームから面談の案内メールが届きました。

以前、書類選考の後に辞退していた会社だった

実は同じ会社の選考を、以前に一度受けたことがあります。

そのときは面接を受ける前、書類選考が通った段階で辞退しました。

理由は2つです。

• 選考の期間が長かった
• バックパッカーから帰国したばかりで、早く仕事に就きたかった

なので、今回は2回目のご縁になります。

BPOだと思っていたら、BPRだった

前回見送ったのは、私の職種の理解が浅かったことも理由の一つでした。

私はその部門を、BPO（業務を外から請け負う仕事）をやるところだと思っていたのです。

でも、改めて話を聞くと違いました。

やるのはBPRで、業務のやり方そのものを作り変える仕事でした。

その対象がBPOの領域だった、ということです。

これは私がやりたいことと重なっているな、と思いました。

ここで熱が戻りました。

残業が月30時間まで下がって、考える余裕ができた

もう一つ、タイミングも大きかったです。

このとき現場の稼働が下がっていて、残業が月30時間ほどになっていました。

前の案件のように月70時間を超えている状態だったら、たぶん読まずに流していたと思います。

忙しいと、キャリアのことなんて考えられないんですよね。

体調を崩す前に余裕を作っておくことって、思っている以上に大事だなと感じます。

動かない選択肢も6〜7割は本気で考えた

実は、残る方向もかなり本気で考えていました。

感覚としては6割から7割くらいです。

残るメリットも小さくなかった

• これまで1年くらいのスパンで現場が変わり、知識が定着していなかった
• 人事給与システムの知識は、どの会社にもある業務なので汎用性が高い
• 次の現場も大きい会社だった
• 所属していた部署自体が伸び始めていた

伸びていく組織に賭けてみるのも悪くないな、とは思っていたんですよね。

ただ、3年賭けてうまくいっていなかった

冷静に考えると、私はすでに3年ほどこの会社に賭けていました。

その結果が、「開発を抜けたいと言い続けても変わらない」という状態です。

同じ賭けをもう3年続けるのか。

それとも、大きいコンサルファームに入って実力をつけるのか。

考えた結果、後者の方がキャリアとして確実にプラスになる可能性が高いかなと思いました。

35歳は不利ではなかった ただ「最後かも」とは思った

年齢そのものに不安はなかった

35歳という年齢に、不安はありませんでした。

気になったのは年齢ではなく、今の私の経歴がコンサルファームで通じるのかという点です。

未経験の職種に行くわけなので、そこは当然の不安だと思います。

「今なら間に合う」ではなく「今が最後かも」

よく「今なら間に合う」と言います。

ただ、私の感覚は少し違いました。

今が最後のチャンスなのかな、というのが正直なところです。

40歳を超えてから未経験の職種に移るのは、さすがにしんどいだろうなと思ったからです。

経歴を棚卸ししたら、意外といけそうだった

不安だったので、経歴書を作りながら冷静に棚卸ししてみました。

1. システムの保守・改修
2. IT企画部や事業会社のシステム部門で、要件定義と案件のハンドリング
3. 開発現場で、設計から総合テスト、リリースまで

こうして並べると、ITに関わる一通りの工程を経験していることが分かりました。

一つひとつは、専門の人に比べたら深くないかもしれません。

ただ、上流から下流まで全部を通して見たことがある人って、意外と多くないんですよね。

これならまあまあ行けるのかな、と思えました。

3回目でいちばん変わったのは、年収を気にしなくなったこと

おかしなことを言っていると思われるかもしれません。

ただ、今回の転職活動でいちばん変わったのは年収をあまり気にしなかったことです。

1回目と2回目は、いくら上がるかを見ながら活動していました。

今回は、先々のキャリアで今の経験をどう活かすかばかり考えていました。

そう考えるようになった理由はAI

理由としていちばん大きいのは、AIが出てきたことだと思っています。

開発現場にいると、意外とAIに触れる機会はありませんでした。

ただ、自分でサイトを立ち上げたり、動画を作ったりする中で実感しました。

AIのレベル、思っているよりずっと上がってるんですよね。

もちろん、開発として人が必要なところは残ると思います。

ただ、手を動かしてシステムを作る仕事が、今後そこまで伸びていくとは思えませんでした。

生成AIでシステムエンジニアの仕事が消えた瞬間を垣間見た ～ツール作成をAIで行ってから感じたこと ここ最近、私が参画している開発案件と、過去に所属していたプロジェクトの両方で、 「AIがエンジニアの働き方を変えていく」という...

だったら、業務を作り変える側にシフトしておきたい。

そう考えた結果が、今回のコンサルファームでした。

#11 35歳未経験でコンサルを選んだ理由 3回目の転職で、大手のコンサルファームに行くことにしました。 コンサルは未経験です。 会社の名前で決めたと思われるかもしれません...

まとめ：不満がなくても動いていい

3回目の転職は、不満が理由ではありませんでした。

言い続けても変わらなかったことと、次にやりたいことが見えたことが理由です。

正直に言うと、ITコンサルが自分に合っているかはまだ分かりません。

合う合わないは人によって違うので、これが正解だとも思っていないです。

なので、1つの参考情報として読んでもらえたら嬉しいです。

このシリーズでは、転職活動の記録や、開発現場で苦しんだこと、引き留めで悩んだことも書いていきます。

同じように「このままでいいのかな」と思っているSEの方の、材料になればと思います。

3年前に「SESやめとけは本当?」という記事を書きました。

そのときの結論は、商流を上げれば解決するというものです。

そこから実際に3年SESで働いて、その結論は間違っていなかったと思っています。

ただ、それとは別の限界があることも分かりました。

今回の転職理由にも直結しているので、書いておきます。

3年前に書いた結論は、間違っていなかった

当時書いたのは、だいたいこんな内容です。

SESは多重構造なので、下の階層にいるほど給料が安くなる。

だから商流が上の会社に移れば、給料もストレスも改善する。

SESやめとけは本当? 対策は転職にある SES(System Engineering Service)は良くないという記事は多いです。 SESは顧客に対してSEと...

これは実際そのとおりでした。

客先からの評価が上がって単価も上げてもらえましたし、3年で前職の給料を超えています。

#13 転職で年収が約200万上がった 3回目の転職で、年収が約200万上がる見込みになりました。 数字だけ見ると、なかなか景気のいい話に見えると思います。 ただ、手放...

給料の話に限れば、SESでも普通に上がるんですよね。

なので「SESは給料が上がらない」という言い方は、少し雑だと思っています。

上がらないとしたら、それは商流の位置か、評価の伝わり方の問題です。

それでも残った限界は「次の案件が選べない」

商流を上げても消えないものがありました。

それが次にどの現場へ行くかを自分で決められないことです。

案件は「希望」と「枠」の掛け算で決まる

SESで次の現場が決まる仕組みは、たぶんどこも似ています。

自分の希望があって、会社にはそのとき売れる枠があります。

そしてその2つが重なったときだけ、希望が通ります。

営業が悪いわけでも、会社が冷たいわけでもありません。

売れる枠が無ければ、どうしようもないんですよね。

営業から来る話は、会社の都合とセットになっている

これも当たり前の話ではあります。

私のところにも、こんな打診が来ていました。

「大きいお客さんに1人目として入って、そこから広げてほしい」

会社としては、新しい取引先を開拓できるので当然やりたい話です。

同じ時期に、単価を上げるために決まった時期で離任させる、という方針も動いていました。

どちらも会社としては正しい判断だと思います。

ただ、自分がやりたい仕事とは、まったく別の軸で動いているんですよね。

希望を伝えることはできます。

でも、決まるときは会社側の事情のほうが先に来ます。

2年言い続けても変わらなかった

私は入社して1年ほど経ったころから、ずっと同じことを言い続けていました。

「開発を抜けて、PMやコンサル寄りの案件にシフトしたい」

1on1でも評価面談でも、言い方を変えながら伝えています。

伝わっていなかったとは思いません。

ただ、伝わっていることと、枠があることは別でした。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

「1年ごとに現場が変わる」の何がしんどいか

業務知識が積み上がらない

私はこの3年で、いくつかの業種の現場を経験しました。

装置の組込開発もやりましたし、業務システムの開発もやっています。

技術の幅は確実に広がりました。

ただ、業務知識のほうは積み上がりません。

1年前後で現場が変わると、次の現場ではまた一から業務を覚えることになります。

しかも業務は、覚えかけが一番しんどいです。

全体が見えていないので質問の仕方も分からず、聞くたびに時間を取らせてしまいます。

やっと全体像が見えて面白くなってきたころに、離任の話が出てくる。

この繰り返しが、地味に効いてきました。

逆に、当たりの現場を引くと残りたくなる

面白いのは、その逆もあることです。

直近で入っていた人事給与のシステムは、どの会社にもある業務なので汎用性がかなり高いです。

ここにあと2〜3年いたら、けっこう強い武器になると思っていました。

実際これが、転職せずに残る理由の一つになりかけています。

どちらに転ぶかも、自分では決められない

ここが一番しんどいところです。

当たりの現場に長くいられるかどうかも、結局は枠の話になります。

実際、私は単価を上げるという理由で、決まった時期に離任することになっていました。

現場の評価が良かったことと、そこに残れることは別なんですよね。

むしろ評価が良いほど、次の単価を上げるカードとして使いやすくなる面もあります。

頑張った結果が、そのまま今の現場を離れる理由にもなる。

ここは少し複雑な気持ちになりました。

同僚が辞めた理由が、全部を表していた

同じ現場にいた若手のメンバーが、転職していきました。

理由を聞いたら、こう言っていました。

「チームで開発現場に入りたかったんです」

一人で常駐する案件が続いていたそうです。

聞いた瞬間、SESだとそうなるよなと思ってしまいました。

引き留める気にはまったくなりませんでした。

素直に納得できましたし、応援したいと思ったくらいです。

ちなみに私も、いた現場には自社の人間が私一人でした。

現場との調整も、全部自分でやることになります。

これも会社が悪いという話ではなく、単純に構造の話です。

会社も手は打っている ただ時間はかかる

誤解のないように書いておくと、会社も普通に動いています。

事業部の方針として、こんな話が出ていました。

• 2次請け・3次請けの比率を下げて、平均単価を上げる
• 一人常駐ではなく、複数名のチームで入る現場を増やす

方向としては、まったく正しいと思います。

私が感じていた限界に、そのまま効く話でもあります。

ただ、それが自分の次の1年に間に合うかは別なんですよね。

会社の3年と、自分の3年は別々に進みます。

私はこの3年で35歳になりました。

会社の変化を待つには、少し年齢が上がりすぎた感覚がありました。

20代なら、たぶん待っていたと思います。

構想が形になるのを見届けるのも、それはそれで面白い経験のはずです。

ただ今回は、自分の時間のほうを優先することにしました。

SESが悪いという話ではない

ここまで限界の話ばかり書きましたが、SESを否定したいわけではありません。

私にとっては、必要な3年でした。

そもそも、PM・コンサル寄りの求人で入った

そもそも私がこの会社に入ったのは、求人がPMやコンサル寄りの案件だったからです。

ただし「最初は開発の案件から」という条件付きでした。

入る前の私は、社会人10年目で開発の経験が1年ほどしかありません。

要件定義やベンダー調整はやってきたのに、作る側の中身を知らない状態です。

転職で上流SE・コンサルを目指した理由 エンジニアも仕事がなくなるかも 色んなところで技術の進歩によって、仕事がなくなるという話を聞きます。 IT業界にいる私たちも、その例外ではないのでは？と思...

なので、1年くらい開発をやってから移れるなら理想的だと思っていました。

その1年が、結果として3年になったわけですね。

幅広い現場に入れるのは、本当にメリット

1年で現場が変わることは、裏返せばメリットでもあります。

全然違う業種のシステムを触れるので、社内転職をしているような気分になれます。

これは3年前の記事でも書きましたが、今も同じ感想です。

実際、この3年で身についたものを並べるとそれなりにあります。

• C#での詳細設計から実装、単体・結合・総合テストまで
• リリース作業と、そのための段取り
• 課題管理とインシデント対応
• 基本設計や外部設計の一部

上流の仕事をしていたときは、正直このあたりをふわっとしか分かっていませんでした。

見積もりの感覚も、変更の影響範囲も、テストの重さも実感がなかったです。

今なら、開発側が何を嫌がるのかが想像できます。

いろんなことをやってみたいタイプの人には、かなり合っていると思います。

まとめ：目的と期限が決まっている人には向いている

3年やって思うのは、これです。

何を身につけたいかが決まっていて、期限を切れる人にはSESは強い。

決まっていないと、案件ごとに流されて年数だけ増えていきます。

私は「開発経験を積む」という目的で入って、それは達成できました。

たぶん、目的が達成された時点が出るタイミングだったんですよね。

実際には3年かかっています。

理由は単純で、目的は決めたのに期限を決めていなかったからです。

ちなみに、独立してフリーランスになる道も一度は考えました。

ITフリーランスに転身をしなかった理由　成長していくことが難しそうだった フリーランスのエージェント数社と面談を行い、実際に企業との面談の1歩手前まで活動をしました。 しかし、2カ月ほど色々と活動...

そちらを選ばなかった理由は別の記事に書いていますが、根っこは同じです。

案件を選べる立場になりたい、というところに行き着きました。

結局のところ、SESで感じた限界はスキルの話ではなかったんですよね。

技術も業務知識も、やれば身につきます。

選べないという一点だけが、どれだけ頑張っても残り続けました。

IT業界10年で、いちばん楽しかったのは事業会社のIT部門にいたときです。

ただ、感謝されたから楽しかったわけではありません。

むしろお礼を言われた記憶がないんですよね。

それでも楽しかった理由を書いていきます。

業務改善の一例：倉庫の検品業務

事業会社のIT企画部に常駐していたときの話です。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

この部署では、基幹システムの要件定義や、海外向けの販売管理システムの導入なども担当していました。

業務改善もRPA化も、対象になる業務はいくつもあります。

なので以下はあくまでそのうちの一つとして読んでください。

分かりやすい例なので、これを使って書いていきます。

まず、業務の流れ

当時の検品業務は、こんな流れで回っていました。

1. メーカーが商品を倉庫へ発送する
2. メーカーから本社へ、検品依頼書がエクセルでメール送付される
3. 本社で内容をチェックして、受付の連絡を返す
4. 検品依頼書を、倉庫が見る場所に配置する
5. 全体の進捗一覧に、新規の依頼を追加する
6. 検品結果を記入するためのエクセルを作成する
7. 倉庫の担当者が検品して、結果を記入する

このうち4番から6番が、本社の担当者がひたすら手でやっている作業でした。

エクセルを開いて、中身を見て、別のエクセルに転記して、また別のエクセルを作る。

商品が動いている裏で、人がずっとエクセルを触り続けている状態です。

しかも季節によって物量が変わるので、忙しい時期はここが完全に詰まります。

自動化したのは、この真ん中の3つ

やることは単純です。

届いたエクセルから必要な情報を取って、配置して、一覧に足して、記入用のエクセルを出す。

これをフェーズ1とフェーズ2に分けて進めました。

• フェーズ1（2週間程度）　依頼書の配置と、進捗一覧への追加
• フェーズ2（3週間程度）　検品結果を記入するエクセルの作成

作るもの自体は、正直それほど難しくありません。

エクセルを読んで、別のエクセルを出す。

RPAの中では、かなり素直な部類の処理です。

自動化の前に、業務のほうを変えた

ここが一番大事なところです。

調べてみると、検品依頼書のフォーマットがメーカーごとにバラバラでした。

項目の位置も名前も違います。

この状態では、そもそも自動化できません。

だから、フォーマットの統一を提案した

やったのは、共通フォーマットを決めて各メーカーに合わせてもらうことです。

社内の調達部門と一緒に、順番に切り替えてもらう調整をしました。

全部を一斉に切り替えるのは無理なので、切り替えが終わったメーカーから順にRPAに乗せる進め方にしています。

正直、ここが一番しんどかった

RPAを作るのは、実はそんなに時間がかかりません。

大変なのは、揃っていないものを揃えることのほうです。

社外の相手に「フォーマットを変えてください」とお願いするわけですから。

相手には相手の事情があるので、一方的に押し付けることはできません。

なので、なぜ変えてほしいのかと、変わったあとに何が良くなるのかをセットで説明しました。

「受付の連絡が今より早く返せるようになります」

そう言えると、話が進みやすくなります。

ただ、面白いのはここからで、フォーマットが揃った時点でRPAが無くても業務は軽くなっているんですよね。

自動化するために業務を整理したら、整理そのものに価値があった。

この感覚が、今もずっと残っています。

全部を自動化しようとはしなかった

もう一つ決めたことがあります。

対象は新規の依頼だけにして、修正が入った分は手作業のままにしました。

修正分は全体の5%ほどです。

残り5%に時間をかけない

修正のパターンまでRPAでカバーしようとすると、難易度が一気に上がります。

条件分岐が増えて、作るのにも直すのにも時間がかかるようになります。

100点を狙うと、たぶん完成しません。

95%を自動化できれば十分ですし、残り5%に時間をかけるくらいなら、次の業務に手をつけたほうが効果は大きいです。

このあたりの割り切りは、この案件で身につきました。

ちなみに、同じ流れの中にメーカーへの請求書作成という業務もありました。

こちらは難易度が高かったので、いったん別扱いにしています。

やる順番を決めるのも仕事のうちだと思っています。

ちなみに、この5%を手作業で残すことは最初に関係者へ伝えています。

後から「これはできません」と言うと、だいたい揉めます。

やらない範囲を先に決めて、先に言う。

これだけで、あとがかなり楽になりました。

効果は「パートの時給×時間」で出した

効果の計算は、難しいことは一切していません。

削減できた作業時間 × パートタイマーの時給

これだけです。

年間にすると、約500万円になりました。

数字にするのは、自分のためではない

効果を数字にしておく意味は、褒めてもらうためではありません。

次の投資を通すためです。

「これだけ減りました」と言える実績があると、次の改善の話がとても進めやすくなります。

逆に、効果を測っていない改善は、やった本人しか価値を知らないまま終わります。

これは開発費の判断でも同じでした。

たとえば開発に数百万かかるとして、何か月で回収できるのかを試算します。

その数字があると、上長も判断できますし、やらないという結論も出せます。

やる理由よりも、やらない理由を出せるほうが信頼される気がしています。

転職で上流SE・コンサルを目指した理由 エンジニアも仕事がなくなるかも 色んなところで技術の進歩によって、仕事がなくなるという話を聞きます。 IT業界にいる私たちも、その例外ではないのでは？と思...

ただ、お礼を言われたことはなかった

効果は大きかったと思っています。

ただ、正直に書くと感謝された記憶はありません。

言われていたのは「いつできるんですか？」

むしろ、急かされることのほうが多かったです。

依頼はどんどん増えていくのに、そこはあまり気にされません。

当時のIT企画部のリーダーや先輩は、その様子を見て少し苛立っていました。

「これだけやってもらってるのに、その言い方はないやろ」という感じです。

私はその横で、まあそういうものかと思っていました。

依頼している側からすると、目の前の業務を早く楽にしたいだけなんですよね。

悪気があるわけではないと思います。

ただ、こちらの作業量が見えていないので、際限なく増えていきます。

今振り返ると、仕方なかったとも思う

ただ、今になって思うことがあります。

私自身が、仕事を押し込まれやすい雰囲気を出していたんですよね。

頼まれると断らないし、やってしまいます。

そういう人のところに依頼が集まるのは、当たり前です。

相手からすれば、頼めば出てくる窓口ができたようなものだと思います。

ちなみにこの癖は、10年経った今も直っていません。

そこは今回の転職でもいちばん不安に思っているところです。

断れないままだと、どこに行っても同じことが起きます。

結局それで残業が増えて、前職では体調を崩しました。

それでも、いちばん楽しかった

楽しかった理由は、感謝ではありませんでした。

業務が実際に変わるところを、自分の目で見られたからです。

倉庫の人が何をやっているかが分かります。

どこで手が止まっているかも分かります。

そして自分が作ったものが、来週から普通に使われています。

このスピード感が、たぶん自分には合っていました。

半年後にリリースされるものより、来週から効くもののほうが面白いです。

作って納めて終わり、では味わえない

開発の現場に3年いて、この違いがはっきり分かりました。

システムを作って納めたあと、それが業務をどう変えたかまでは、たいてい見えません。

社内SEに転職後、退職した経験から分かった 社内SEに向いている人 転職活動記の目次ページはこちらです。 1年半で退職してしまいましたが、私は中小SIerから社内SEへ転職しました。...

どちらが偉いという話ではないです。

ただ、私の場合は「その後」まで見えないと物足りないだけなんですよね。

今回コンサル寄りの仕事を選んだのも、結局ここが理由でした。

#11 35歳未経験でコンサルを選んだ理由 3回目の転職で、大手のコンサルファームに行くことにしました。 コンサルは未経験です。 会社の名前で決めたと思われるかもしれません...

まとめ：感謝はされなくても、変化は残る

情シスやIT企画は、正直かなり感謝されにくいポジションです。

うまくいって当たり前、遅いと言われる。

これは情シスを経験した人ならだいたい共感してもらえると思います。

ただ、業務が変わった事実だけは残ります。

そして数字にしておけば、それは自分の実績としても残ります。

実際この検品業務の話は、5年近く経った今でも面接で使えています。

転職して1年半後、1ヶ月で複数内定がもらえた理由 面接は相互理解 転職活動×東南アジアバックパッカーの目次ページはこちらです。 23年4月末でから有休消化をしつつ、転職活動をしまし...

お礼を言われなくても、やったことは消えません。

そう思えるようになったのは、この仕事のおかげかもしれません。

もし今、社内で改善をやっていて報われていないと感じている方がいたら、効果だけは数字にして残しておいてください。

感謝はされなくても、その数字はあとから必ず効いてきます。

このシリーズは転職の記録ですが、この記事だけは転職の話ではありません。

客先常駐の開発現場で、技術以外にやっていたことの話です。

転職活動の記録だけ読みたい方は、この記事は飛ばしてもらって大丈夫です。

ただ、私がコンサル寄りの仕事を選んだ理由にもつながっているので、残しておきます。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

参画したときのチームは、とにかく静かだった

今の会社はSESなので、客先に常駐して働きます。

#2 SESで感じた限界 3年前に「SESやめとけは本当?」という記事を書きました。 そのときの結論は、商流を上げれば解決するというものです。 そこから実...

初めてその現場に入った日、島全体がシーンと静まり返っていました。

でも、仕事の話は笑顔でしていた

ただ、よく見ていると少し違和感がありました。

仕事の話をするときは、みんな笑顔で喋っているのです。

つまり、仲が悪いわけではないんですよね。

前の転職では社風や雰囲気を重視して会社を選びました。

なので、雰囲気って変えられるものなのかな、というのは前から気になっていたんですよね。

雰囲気がそうさせているだけかもしれないと思いました。

こっちからボールを投げてみることにした

試しに私から話を振ってみると、笑顔で答えてくれます。

向こうからも、いろんなことを聞いてくれるようになりました。

なので、ボールを投げる数を増やして、どんな反応が返ってくるか見てみようと思いました。

これが最初にやったことです。

見積もりが甘くて、全員が月40時間以上の残業になった

最初に入った開発プロジェクトは、正直に言うと見積もりがかなり甘いものでした。

開発期間は半年ほどでした。

稼働が始まって1カ月目から、開発メンバー3名全員が40時間以上残業していました。

一番多いときで、私は月75時間ほどです。

他の方も60時間から70時間くらいでした。

そりゃあ、チーム全体の雰囲気もかなり重くなっていきます。

やったこと①　ハッピーターンを配った

雑談から会話を盛り上げて、少しでも明るい雰囲気にできたらと思って始めました。

やり方は単純です。

週に2回ほど「ハッピーですか？」と聞いて回ります。

「ハッピーでない」と返ってきたら「ハッピーになれ」と言ってハッピーターンを渡します。

「ハッピー」と返ってきたら「もっとハッピーになれ」と言って渡します。

ハッピーターンを選んだ理由は語呂だけ

なぜハッピーターンなのかというと、単純に語呂が良かったからです。

分解するとハッピー＋ターンで、ハッピーに転換する、という意味になります。

あとは、渡し方を想像すると単純に面白かったからです。

本当に、それだけの理由なんです。

先にキャラを作っておいたのが大きい

これ、いきなりやってたら確実に引かれてたと思うんですよね。

私は案件に参画した時点から、冗談を言ったり、少しおかしなことを言ったりしていました。

意識的に自分のキャラ付けをしていたのです。

そのおかげか、最初に渡したときも「少し驚いて、少し笑う」くらいの反応で済みました。

1年で5回だけにした

やったのは、1年いた中で5回ほどです。

毎日お菓子を配っていると、ありがたみも意味もなくなってきます。

なので、雰囲気が重くなってきたタイミングを見てやるようにしていました。

ちなみにお菓子代は自腹です。

自分を助けるという意味でも、自腹で買うのは悪くないと思っています。

「ハッピーじゃないです(泣)」から始まった

一番最初に渡したときは、みんなかなり忙しくてしんどい状態でした。

PLからは「ハッピーじゃないです(泣)」という回答が返ってきました。

まあ、その通りだろうなと思いました…

ただ、翌月に同じことをしたときは違いました。

少しずつ雰囲気も明るくなり始めていて、「ハッピーです」と言ってもらえたのです。

そのうち、お互いにお菓子を渡し合うことが増えていきました。

やったこと②　ホワイトボードで書き出した

私は社会人8年目くらいから、小型のホワイトボードを持ち歩いています。

きっかけはコンサル会社の人たち

1社目のとき、事業会社のIT企画部に常駐していました。

そこでシステムの入れ替えを手伝ってくれていたのが、あるコンサルティング会社の人たちでした。

その方たちがホワイトボードを使っているのを、よく見ていたのです。

10歳上の先輩に説明が伝わらなかった

もう一つきっかけがあります。

現場に10歳ほど年上の先輩が入ってきたとき、説明がなかなか理解してもらえませんでした。

口で言うだけだと、どうしても限界があるんですよね。

構造的に理解してもらえるようにと思って使い出したら、これがかなり便利でした。

それ以来、持ち歩くようにしています。

会議が空中戦になりかけたとき

開発が遅れて、メンバー3人とチームリーダーで会議室に集まったことがありました。

議論が空中戦になりかけている気がしたので、後ろにあった大きなホワイトボードを使いました。

まず、各々が持っている開発のタスクを人別に書き出していきます。

リーダーは、優先順位をつけて潰せるものから効率的に潰したいと思っていたようでした。

なので「では、優先順位はどれですか？」と聞きながら進めました。

優先順位が高いものから番号を振って、赤・青・緑のペンで色をつけていきます。

終わったあと、リーダーからは「ありがとうございます、助かります」と言ってもらえました。

やったこと③　口頭で終わらせずエクセルに残した

口頭だけだと、体感で2割は認識がずれる

詳細設計から結合テストの間は、口頭中心の連絡がとても多くなります。

その結果、伝え漏れや認識の齟齬が起きます。

体感ですが、不具合の2割くらいは認識のずれが原因だったと思っています。

#5 総合(システム)テストフェーズで気づいた、単体テストで見逃していたバグの話 開発の現場で、いちばんショックだった出来事の話です。 総合テスト（システムテスト）のフェーズに入ってから、自分が担当したプログラム...

「通勤時間は必ず入る」と聞いていたのに、空白で来た

分かりやすい例があります。

グループ会社のシステムが出力する、通勤経路の申請ファイルを取り込む開発をしていました。

自転車通勤の交通費申請について、通勤時間は確実に入ってくると聞いていました。

なので、駐輪場代を取り込むかどうかは「通勤時間があるかないか」で判定する作りにしていました。

ところが、実際に流してみると違いました。

ユーザー側にも認識違いがあり、通勤時間が空白や0で来るパターンもあったのです。

結果、判定の条件を作り直すことになりました。

通勤時間の有無だけで見るのをやめて、申請額と他の3区分を合わせた4つを統合して判定する形に変えました。

誰かが嘘をついたわけではありません。

「確実に入る」という言葉の理解が、聞いた側と話した側でずれていただけなんですよね。

離任した案件から「2日以内に直して」と来たこともある

もう一つあります。

すでに離任した案件でインシデントが起き、それが私の担当していたプログラムでした。

2日以内に直すよう依頼が来ました。

正直、抜けた案件の依頼が来ることには少し不満もありました。

ただ、原因をたどると当時の修正依頼が不明瞭で、私の確認が甘かったのです。

どちらが悪いという話ではなく、口頭で終わらせたことが原因なんですよね。

結合テストの不具合をエクセルにまとめた

そこで、システムテストの調査からはドキュメントに残すようにしました。

まとめたのは、結合テストのフェーズで出てきた不具合です。

自分たちが開発した処理を流したあと、後続の給与計算の処理でエラーになるものでした。

ある程度分かっていないと理解が難しい内容だったので、自分が理解するためにもエクセルにしました。

リーダーがそれを持ってユーザーに説明に行った

結果として、そのドキュメントをリーダーがユーザーへの説明に使ってくれました。

これは作ってよかったなと思いましたね。

その後、仕様に関する会話も終盤には練度が上がりました。

不要な改修を避けられたり、根本解決に近い修正案が出るようになった気がします。

もちろん、滑ったこともある

冗談が変な空気になった

病院に行くために早く帰る日がありました。

その理由を説明したときに、こう言ってしまいました。

「ほら、僕って頭おかしいじゃないですか。なので頭が痛かったり耳鳴りがするので病院に行ってきます」

これは、しっかり変な空気になりました…

首を突っ込みすぎて止められた

参画した序盤のことです。

他のメンバーが行き詰まっていることや、保守案件の障害にも首を突っ込んでいました。

どんな内容なのか、どこが問題なのかという話をしに行っていたのです。

当時は自分の案件もかなり忙しい時期でした。

なので、リーダーから「今は自分のやるべきことに集中してもらった方がいいです」と言われました。

おっしゃる通りですよね(笑)

やることをやったうえでやらないと、ただ邪魔をしているだけなんですよね…

まとめ：これはコンサルのスキルではないと思う

正直に言うと、私は今でもこれをコンサルっぽいことだとは思っていないんですよね。

ただ、物事を構造的にとらえて整理して、分かるように伝えることは、他の業界の仕事でも使えるものだと思っています。

特に、人を引っ張る立場や案件を進めていく立場になると必要になってくると思います。

メンバーを一つの方向に向かせる、同じ視点にさせる、という意味でです。

SEの転職面接で必要なコミュニケーション能力 理解して伝える力 転職活動記の目次ページはこちらです。 面接で落ちることは誰しもが経験することです。 その理由の1つに面接のコ...

技術で突き抜けられなくても、現場でやれることはあります。

AIが進んでいく中では、むしろこちら側の方が残るのではないかとも思っています。

そしてこういう話は、転職の面接でも何度も聞かれました。

SEの中途面接対策！ エピソードから回答を作る方法 転職活動記の目次ページはこちらです。 コロナ禍の2021年、私は転職活動を2カ月して、内定をいただくことができまし...

派手なことは一つもしていませんが、同じように静かな現場にいる方の参考になれば嬉しいです。

開発の現場で、いちばんショックだった出来事の話です。

総合テスト（システムテスト）のフェーズに入ってから、自分が担当したプログラムのバグを見つけました。

しかもそれは、単体テストの時点からずっと残っていたものでした。

つまり、自分のテストをすり抜けたまま、結合テストも通過していたことになります。

この一件で、仕事の見方がけっこう変わりました。

自分の単体テストをすり抜けていた

当時、案件は総合テストのフェーズに入っていました。

そこで出たインシデントの対応をしていたときのことです。

調べている途中で、報告されていたものとは別の不具合を見つけました。

どこから出ているのかをたどっていくと、答えははっきりしていました。

単体テストが終わった時点から、ずっと残っていたものです。

単体テストも結合テストも通っていたのに、総合テストまで誰も気づいていませんでした。

誰にも怒られていないのがきつい

しかも単体テストは、自分でやったものです。

何か月も気づかれないまま、そのまま動いていたことになります。

誰かに指摘されたわけではありません。

自分で見つけたぶん、余計にきつかったです。

「ちゃんとテストしたつもりだったのにな」というやつですね。

ちなみに私は、社会人10年目で開発の経験が1年ほどしかない状態から今の現場に入っています。

なので、テストの観点を自分で組み立てた経験もほとんどありませんでした。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

なぜ見逃したのか

落ち込んでいても仕方ないので、原因を考えました。

技術的に難しかったから、ではありません。

自分の担当範囲だけを見ていた

私が見ていたのは、仕様書に書かれた「この機能」だけでした。

入力を入れて、出力が想定どおりか確認する。

そこで終わりにしていたんですよね。

前の処理も、後ろの処理も見ていませんでした。

当時の私の感覚だと、それは他の人の担当なんですよね。

実際、担当は分かれています。

ただ、データはつながって流れていきます。

自分の出力が誰かの入力になる以上、そこで切ると見えないものが出てきます。

書いてあることだけを見ていた

実は、似たようなことを別の対応でもやっています。

インシデント一覧に、修正内容が1機能ぶんだけ書かれていました。

なので私は、それが対象範囲だと思い込んで着手しています。

調べてみたら、実際には2つの機能に影響していました。

書いてある情報が足りなかったのは事実です。

私はそのプログラムを作った本人でもなかったので、全体像も分かっていませんでした。

そのとき、PLに怒り口調で言ってしまった

ここは反省点です。

私はPLに「これ、一覧からは読み取れないですよね」と言ってしまいました。

言い方に、明らかに苛立ちが混ざっていたと思います。

でも、あとから考えるとどうでしょうか。

範囲を狭く見たのは、私のミスでもあるんですよね。

着手する前に一言確認すれば済んだ話です。

資料が足りないなら、足りないと分かった時点で聞けばいい。

それをせずに進めておいて、あとから資料のせいにするのは違いますよね。

この一件は、今でもわりと覚えています。

そこから、見方を変えた

やったことは単純です。

部分的に見るのをやめました。

自分の担当かどうかではなく、仕様全体としておかしくないかを見るようにしました。

実際にやっていること

バグを見つけた回では、こんな確認をしています。

1. 開発した処理で、実際にデータを取り込む
2. そのあとに動くバッチ処理まで流す
3. 別の画面を開いて、結果がどう見えるか確認する

自分の担当範囲を出て、データが最後にどうなるかまで追いかけます。

正直、時間はかかる

テストの時間は、体感で倍近くになります。

環境の準備もいるので、単純に面倒です。

ただ、あとから直すコストのほうが確実に高いんですよね。

しかも終盤に見つかるほど、周りの時間まで奪います。

テスト工程で出た不具合は、原因の調査から始まります。

作った本人以外が調べると、そこだけで何時間もかかるんですよね。

自分の担当外の問題まで見えるようになった

見る範囲を広げたら、思わぬ副作用がありました。

自分が担当していないところの問題まで、目に入るようになったんです。

実際に見つけたもの

• 前日のデータを溜める処理に削除がなく、月末になると重くなる作りだった
• 土日は不要なデータまで毎日送っていて、処理時間を押し上げていた
• 基本設計の段階で、リリース前にデータを整えておく必要があることに気づいた

どれも、自分の担当だけ見ていたら気づけないものです。

リーダーに言われた感謝の一言

このうちのいくつかを確認しに行ったとき、こう言ってもらえました。

「そこまで見てくれていると思わなかった」

別の場面では、こうも言われています。

「設計は完璧ではないので、気になったことを確認してもらえると安心です」

この言葉は、けっこう効きました。

確認するのは、疑っているからではないんですよね。

むしろ、聞かれない設計のほうが不安なんだと思います。

自分が設計する側になったときも、これは覚えておきたいです。

同じことを、あとから入った人に説明した

しばらくして、チームに新しいメンバーが入ってきました。

異業種から転職してきて、開発の現場は初めてという方です。

システムテストのテストデータ作りで、完全に詰まっていました。

見ていると、私が最初にやっていたミスと同じことをしていました。

単体テストと同じデータでは足りない

単体テストは、その機能が仕様どおり動くかを見ます。

一方、システムテストは実際の業務の流れでデータを作る必要があります。

申請して、承認されて、締めて、連携する。

この流れに沿っていないと、そもそも後続が動きません。

「なぜ単体と同じデータではダメなのか」を説明したら、反応がかなり良かったです。

説明しながら、自分の理解も固まった

このときは、持ち歩いている小型のホワイトボードを使いました。

仕様とデータの流れを書いて、どこで何が起きるかを一緒に追いかけます。

2時間ほどかかりましたが、やってよかったです。

人に説明できないところは、自分も分かっていないんですよね。

教えるほうが勉強になる、というのは本当でした。

#4 残業70時間のチームでやっていた3つのこと このシリーズは転職の記録ですが、この記事だけは転職の話ではありません。 客先常駐の開発現場で、技術以外にやっていたことの話です。 ...

ミスの原因は、技術ではなかった

1年ほど同じ現場にいて、不具合の出方を見ていて思ったことがあります。

技術的に難しくて解けなかったものって、あまりなかった気がします。

難解すぎて読み解くのに時間がかかるものはありましたが。。。

多かったのはこの3つです。

• 業務や既存システムの知識が足りない
• 関係者どうしの認識がずれている
• 単純に伝わっていない

しかも、こういうミスは終盤になるほど効いてきます。

リリースが近いほど、一つの手戻りが全体を止めます。

だから、着手前に聞く回数を増やした

今は、着手する前に一度だけ確認するようにしています。

「これ、どこまでが対象ですか」

「この前提で合っていますか」

たったこれだけで、手戻りがかなり減りました。

聞くのは一瞬ですが、直すのは半日かかります。

転職で上流SE・コンサルを目指した理由 エンジニアも仕事がなくなるかも 色んなところで技術の進歩によって、仕事がなくなるという話を聞きます。 IT業界にいる私たちも、その例外ではないのでは？と思...

まとめ：見逃したことより、見方を変えられたか

あのバグを見つけた日は、本当に落ち込みました。

ただ、今振り返るとあそこで見方を変えられたことのほうが大きかったです。

未経験に近い状態で開発に入ると、最初は担当範囲を守るだけで精一杯です。

それは仕方ないと思います。

ただ、少し余裕が出てきたら、範囲の外を見てみてほしいです。

そこから見つかるものは、たぶん自分の評価にもつながります。

実際、客先からの評価にも「上流の工程も任せていきたい」と書いてもらえました。

やったことは、範囲を少し広げて確認しただけです。

SEの中途面接対策！ エピソードから回答を作る方法 転職活動記の目次ページはこちらです。 コロナ禍の2021年、私は転職活動を2カ月して、内定をいただくことができまし...

ちなみにこの話は、転職の面接でも使いました。

失敗の話は、そのあと何を変えたかとセットにすると通ります。

転職して1年半後、1ヶ月で複数内定がもらえた理由 面接は相互理解 転職活動×東南アジアバックパッカーの目次ページはこちらです。 23年4月末でから有休消化をしつつ、転職活動をしまし...

今回の転職の1年ほど前にも、転職活動をしていました。

結果は、内定2社を辞退して、本命には最終面接で落ちるというものです。

つまり、何も決まらないまま終わりました。

ただ、あの1年がなかったら今回の転職もなかったと思っています。

なので、うまくいかなかったほうの話も書いておきます。

数字だけ見ると、悪くなかった

まず結果から書きます。

• 応募　13社
• 書類通過　13社
• 面接　13社
• 内定　2社

はい、書類は全部通っています。

2023年と比べると、かなり違う

2回目の転職活動（2023年）のときは、こうでした。

応募26社に対して、書類通過は11社です。

通過率でいうと42%から100%になっています。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

理由は2つあると思っています。

1つは、応募する数を絞ったことです。

2023年は「とりあえず出す」に近い応募も混ざっていました。

今回は、求人を読んで自分の経験と重なる会社だけに出しています。

もう1つは、職務経歴書の書き方を変えたことです。

どんな規模のチームで、どんな立場で、何をやったのか。

ここを具体的に書くようにしたら、通り方が変わりました。

ただ、ここで勘違いをしていました。

通ることと、決めることは別

書類が全部通ると、正直ちょっといい気分になります。

「あ、自分けっこう需要あるのかも」という感じですね。

でも、実際に決まったのはゼロです。

通過率と満足度は、まったく別のものでした。

受かるかどうかは、書類と面接の技術でなんとかなる部分があります。

でも「ここで働きたいか」は、まったく別の話なんですよね。

内定2社を辞退した理由

当時、転職エージェントからこう言われていました。

「ビジネスに関わるITコンサルへ進むなら、まず開発の経験を積んだほうがいい」

これは、たぶん正しいアドバイスです。

なので、開発ができる会社を中心に紹介してもらっていました。

聞いてみたら、今の会社と変わらなかった

面接では、開発現場の具体的な中身を聞くようにしていました。

どんな案件があるのか、どういう立ち位置で入るのか。

自社のメンバーは何人くらい一緒に入るのか。

配属はどうやって決まるのか。

このあたりは、実際に入ってみないと分からないことが多いです。

なので、聞けるだけ聞くようにしていました。

聞いていくと、だいたい同じ答えに行き着きます。

2次請け・3次請けの比率が高いんですよね。

つまり、案件のガチャ要素は今の会社とまったく同じです。

年収は上がる予定だった

条件だけ見れば悪くありませんでした。

年収は、30万から50万ほど上がる見込みです。

正直、これは小さい金額ではありません。

ただ、構造が同じなら3年後も同じ場所にいると思いました。

#2 SESで感じた限界 3年前に「SESやめとけは本当?」という記事を書きました。 そのときの結論は、商流を上げれば解決するというものです。 そこから実...

給料のために転職して、また同じ不満を持つ。

それは1回目の転職でやっているので、さすがに繰り返したくなかったです。

転職活動中に内定・選考辞退をした理由 応募者も選ぶ立場 転職活動×東南アジアバックパッカーの目次ページはこちらです。 転職活動をしていく中で、内定辞退、選考辞退をした企業...

本命は、最終面接で落ちた

一番志望度が高かったのは、専門商社の社内SEの求人でした。

しかも幹部候補という位置づけです。

条件も理想に近いものでした。

• 業務内容ヒアリング→優先順位付け→改善計画化→実行→効果検証
• AIや小さな社内ツールの開発も自分でやる
• 年間休日が多い
• 残業がほぼない
• 少人数のチームで、裁量が大きそう

やりたいことと、働き方と、経営との距離。

全部がそろって見えました。

スカウトメールをもらった時点で、正直かなり前のめりになっていたと思います。

カジュアル面談から最終まで、けっこうな回数を受けています。

面接の手ごたえは「ビビった」

ただ、面接を受けた直後の感想は、はっきり覚えています。

ビビった、というのが正直なところでした。

質問がとにかく深かったんですよね。

「なんの業務を、どれくらいの規模でやったんですか」

こういう聞き方を何度もされました。

自分の経験を、数字と規模で説明できるかを見られていたんだと思います。

私は「やったことがあります」とは言えるのですが、規模まで即答できませんでした。

このときの反省は、今回の転職活動でかなり効いています。

経歴書を作り直すときに、人数と期間を全部書き出すようにしました。

もう一つ、会社の構成にもビビった

不安だったのは質問の深さだけではありません。

聞いていくうちに、会社の構成が見えてきました。

社員数は1桁で、しかもその8割が営業メンバーです。

当然、求められる数字や結果もかなりシビアだろうなと感じました。

そこに慣れていないと、正直きついと思います。

そしてもう一つ。

SEのことを知らない人しかいない会社に、一人で入って価値を出す。

しかも、その価値を理解してもらう。

想像すると、これはけっこう大変そうなんですよね。

理想に近い求人ではあったのですが、この不安はずっと消えませんでした。

落ちた連絡は、エージェント経由で来た

結果は、エージェントからの連絡で知りました。

一番志望度が高かったので、ここで打ち止めです。

他に決められる会社もなかったので、転職活動そのものを止めました。

正直、しばらくは求人を見る気にもなりませんでした。

理想に近いものを一度見てしまうと、他がどうしても見劣りするんですよね。

落ちて分かったことのほうが大きかった

しばらくしてから思ったことがあります。

一社の不採用は、市場全体の評価ではないんですよね。

当たり前なんですが、落ちた直後はそう思えません。

何を求めていたのかが、はっきりした

なぜあの求人があんなに理想に見えたのか。

あとから分解してみたら、求めていたものは4つでした。

1. 経営との距離が近いこと
2. 自分で決められる範囲が広いこと
3. 業務改善そのものが仕事であること
4. 健康的に働き続けられること

この4つを同時に満たそうとしていたわけです。

そりゃあ、なかなか見つからないですよね。

しかもこの4つは、わりと相性が悪い組み合わせです。

裁量が大きい会社は、たいてい忙しいです。

働き方が整っている会社は、決められる範囲が狭いことが多いです。

全部そろう会社を探すより、どれを優先するかを決めるほうが早いと気づきました。

社内SEに戻りたいわけではなかった

もう一つ気づいたことがあります。

実はちょうどこの時期に、前職の事業会社の課長から直接電話がありました。

戻ってきてくれないか、という話です。

ポジションは社内SEで、内容も以前とほぼ同じでした。

ベンダーや社内の業務部門とやり取りしながら開発案件を進めて、問い合わせにも対応する。

正直、声をかけてもらえたのはかなり嬉しかったです。

辞めた人間に連絡をくれるというのは、それだけでありがたい話ですよね。

ただ、答えは自分の中で早めに出ていました。

私は「社内SEに戻りたい」わけではなかったんです。

前職の社内SEは2人体制で、結局は残業で潰れています。

社内SEに転職後、退職した経験から分かった 社内SEに向いている人 転職活動記の目次ページはこちらです。 1年半で退職してしまいましたが、私は中小SIerから社内SEへ転職しました。...

戻りたいのは職種名ではなく、業務と経営の間をつなぐ役割のほうでした。

同じ場所に同じ形で戻れば、たぶん同じところで詰まります。

#11 35歳未経験でコンサルを選んだ理由 3回目の転職で、大手のコンサルファームに行くことにしました。 コンサルは未経験です。 会社の名前で決めたと思われるかもしれません...

結局、何も決めずに終わった

そこから転職活動は止まりました。

熱もだいぶ落ちて、しばらくは今の現場で経験を積もうと思っていました。

止めたことは、間違っていなかった

今振り返っても、あそこで妥協しなくてよかったと思っています。

納得しないまま決めていたら、たぶんまた1年半で辞めています。

実際、1回目の転職ではそれをやりました。

決めないという判断も、判断のうちなんですよね。

転職活動は、始めたら必ず転職しないといけないものではありません。

止まっていた1年で、やっていたこと

転職活動は止めましたが、止まっていたのは活動だけです。

現場では、基本設計から総合テストとリリースまで一通り経験しました。

客先からの評価も、それなりにもらえるようになっています。

あとは、個人で作っているサービスの開発を進めていました。

結果的に、これが次の材料になった

1年経って気づいたのは、話せることが増えていたことです。

規模も、役割も、工程も、具体的に説明できるようになっていました。

つまりエージェントの「まず開発経験を積め」というアドバイスは、正しかったわけです。

ただ、そのために転職する必要はなかっただけなんですよね。

今いる場所で積める経験を、わざわざ他社で積み直すことはありません。

このあたりは、当時はうまく整理できていませんでした。

まとめ：うまくいかなかった1年が、次の判断を作った

13社受けて、何も決まりませんでした。

数字だけ見れば、時間を無駄にしたようにも見えます。

ただ、この1年で自分が何を求めているかがはっきりしました。

今回の転職でほとんど迷わなかったのは、あのときに一度全部を並べたからです。

もし今、転職活動が止まっている方がいたら、そこまで悲観しなくていいと思います。

決まらなかった理由を言葉にできれば、その活動はちゃんと前に進んでいます。

私の場合は、それに1年かかりました。

PG から SE、そして PL・PM、その先にコンサル。

これがSEの王道だと、ずっと思っていました。

そして自分は、そこから外れている自覚があります。

先に結論を書いておくと、この不安は今も消えていません。

消えていないまま転職した話を書きます。

「王道」のイメージはどこから来たのか

そもそも、なぜ王道だと思っていたのか。

振り返ると、出どころは2つでした。

会社の等級制度

どの会社にも、等級や職位の定義があります。

そして中身を読むと、だいたい下流から上流へ順番に上がっていく形で書かれています。

製造ができる、単体テストができる、詳細設計ができる、基本設計ができる。

そういう順番です。

毎年その表を見ていれば、それが正しい道に見えてきます。

しかも評価面談のたびに、その表を使って話をします。

「次の等級に上がるには、この工程ができるようになってください」

そう言われ続けると、順番以外の進み方があるとは思わなくなるんですよね。

周りのエンジニアの経歴

もう一つは、実際に見てきた人たちの経歴です。

先輩も、同期も、現場で会う人も、だいたい同じ順番で進んでいました。

誰も外れていないなら、外れるほうがおかしい。

当時はそう思っていました。

今思えば、単に自分の見ている範囲が狭かっただけです。

同じ会社と同じ現場にいれば、似た経歴の人しか目に入りません。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

ただ、王道を歩いていれば上がれるわけでもなかった

同世代で、きれいに王道を歩いている人はいます。

ただ、よく見るとみんなが上がっているわけではありませんでした。

ほとんどの人は、設計からテストまでの仕事をしています。

何年やっても、そこは変わっていません。

本人たちが上に行きたくないのかというと、そうでもないと思います。

単純に、そういう仕事が回ってこないだけなんですよね。

能力とタイミングの両方がいる

上流の工程まで進めている人には、共通点がありました。

まず、単純に能力が高いです。

そのうえで、案件や業務のタイミングが重なった人だけが上がっていました。

その時期に上流の枠が空いていたか、任せてもらえる人がいなかったか。

つまり、順番に並んでいれば上がれるという話ではないんですよね。

これに気づいたとき、王道という言葉が少し軽くなりました。

順番に並んでいても、前が詰まっていたら進めません。

そして枠が空くかどうかは、自分ではどうにもならない部分が大きいです。

SESだとなおさらで、そもそも次にどの現場へ行くかも選べません。

逆のパターンも見た

1社目に、1つ上の先輩がいました。

その先輩は、開発をしっかりやりきらないうちに、受託案件の見積もりを任されるようになります。

そして、かなり苦労しているのを横で見ていました。

上流だけ先に行くのも、それはそれで危ない

見積もりは、作ったことがないと根拠を持てません。

「この機能なら何人日」という感覚が、どうしても持てないんですよね。

聞いて回るしかなくなるので、時間もかかります。

私が開発の経験を積みたかった理由の一つも、まさにこれでした。

転職で上流SE・コンサルを目指した理由 エンジニアも仕事がなくなるかも 色んなところで技術の進歩によって、仕事がなくなるという話を聞きます。 IT業界にいる私たちも、その例外ではないのでは？と思...

上流に行きたいから、逆に下流をやっておきたかったわけです。

実際、開発を3年やってみて、この判断は正しかったと思っています。

変更の影響範囲がどこまで広がるか、テストにどれくらい手間がかかるか。

このあたりの感覚は、やってみないと絶対に身につきませんでした。

エージェントには、やめたほうがいいに近いことを言われた

転職エージェントに相談したときは、はっきり言われました。

「急にITコンサルになって、苦労する人をたくさん見てきました」

だから、まずは開発の経験を積んだほうがいい。

そういう方針で求人を紹介してもらっていました。

#6 2025年の転職活動はうまくいかなかった 今回の転職の1年ほど前にも、転職活動をしていました。 結果は、内定2社を辞退して、本命には最終面接で落ちるというものです。 つま...

今思うと、話が噛み合っていなかった

このアドバイス自体は、間違っていないと思います。

ただ、あとから気づいたことがあります。

「ITコンサル」が一括りにされていたんですよね。

実際には、けっこう幅があります。

• 1から受託で開発をするタイプのコンサル
• 業務プロセスそのものを変える、BPR寄りのコンサル

私が行きたかったのは、後者でした。

前者なら、たしかに開発経験が足りないと苦労すると思います。

一方で後者は、業務を聞いて整理する力のほうが先に要ります。

ここは事業会社のIT部門でやってきたことなので、まったくの未経験ではありません。

ただ、これは自分の説明不足でもある

とはいえ、当時の私もそこを分けて説明できていませんでした。

「上流に行きたい」「コンサルに興味がある」としか言えていなかったと思います。

ぼんやりした希望には、ぼんやりした助言しか返ってこないんですよね。

相手が悪いわけではありません。

今回の転職活動では、ここをかなり意識しました。

「業務の課題を整理して、ITで解決するところまでやりたい」

そう言えるようになったのは、一度ぼんやりした希望で失敗したからです。

いちばん怖いのは「強い分野がないこと」

1社目の当時の上司とは、今でもたまに飲みに行きます。

そこでキャリアの話になったときに出たのが、この話でした。

うまくいかない人の理由の一つは、ここという強い分野がないまま、色んな仕事をしてしまうこと。

聞いた瞬間、わりとドキッとしました。

その上司は、私を責めるつもりで言ったわけではないと思います。

ただ、心当たりがありすぎました。

これは、そのまま自分にも当てはまる

私の経歴はこうです。

1. システムの保守・改修
2. IT企画部で要件定義やシステム導入
3. 事業会社の社内SE
4. SESで客先常駐の開発

幅は広いです。

ただ、ここが強いと言い切れるものがあるかというと、正直あやしいです。

社内SEに転職後、退職した経験から分かった 社内SEに向いている人 転職活動記の目次ページはこちらです。 1年半で退職してしまいましたが、私は中小SIerから社内SEへ転職しました。...

たとえば「この業界のこのシステムなら詳しい」と言える状態ではありません。

技術で突き抜けているわけでもないです。

王道を外れる不安の正体は、たぶんこれなんですよね。

順番の話ではなく、何者にもなっていないことへの不安です。

#11 35歳未経験でコンサルを選んだ理由 3回目の転職で、大手のコンサルファームに行くことにしました。 コンサルは未経験です。 会社の名前で決めたと思われるかもしれません...

それでも動いた理由

最初に書いたとおり、不安は消えていません。

転職を決めた今も、同じことを考えています。

ただ、前より勝率は高いと思っている

直接の答えではないかもしれませんが、こう考えています。

コンサルファームであれば、顧客側もシステムを知っていることが多いです。

つまり、システムの話が通じる相手と会話ができます。

これは、SEを知らない人ばかりの会社に一人で入るのとは、だいぶ違います。

もう一つは、周りに先輩がいることです。

やり方を見て学べますし、詰まったときに聞ける人がいます。

未経験の職種に移るときに、これはかなり大きいと思っています。

前の職場でも、経験の浅いメンバーが詰まったときに助けていたのは周りの人でした。

「一人で価値を証明する」状態ではありません。

なので、何となくですが、なんとかなるんじゃないかなと感じています。

根拠としては弱いです。

ただ、不安の大きさを比べたときに、こちらのほうが小さかったというだけの話です。

前の年に本命だった会社は、社内にSEがほとんどいない環境でした。

そこで一人で価値を出すことを想像したときのほうが、正直こわかったです。

まとめ：不安が消えてから動く必要はない

この記事に、きれいな結論はありません。

王道を外れる不安は、今も普通に持っています。

ただ、消えるのを待っていたら、たぶん一生動けないと思いました。

なので、消えないなら少しでも勝率が上がる場所を選ぶ。

今回やったのは、それだけです。

同じように「自分は王道から外れている」と思っている方がいたら、一つだけ。

周りを見た限り、王道を歩いている人も、全員が上がっているわけではありません。

答え合わせは1年後にするつもりなので、そのときにまた書きます。

職務経歴書は、転職のたびに書き方を変えてきました。

今回はSEからコンサル寄りの職種に移るので、見せ方もそれに合わせています。

結果として、全体で12ページになりました。

前回は7ページだったので、5ページ増えた計算です。

中身は出せないので、型と考え方だけ書いていきます。

先に、テンプレートを置いておきます

私が使っている型を、中身を空にしたWordファイルにしました。

職務経歴書テンプレート（Word）

書き方のメモもグレーの文字で入れてあるので、不要なら消してください。

そもそもこの形は、最初の転職のときに担当してくれたエージェントの方がくれたものです。

以来ずっと、この項目立てを使い続けています。

自分で1から考えたものではありません。

もらった型をそのまま使い続けているだけです。

ただ、6年ほど使ってみて、項目としてはこれで足りると思っているんですよね。

会社ごとに区切って、中に案件を入れる

まとめ方は、ずっと迷っていました。

会社ごとに書くのか、案件ごとに書くのか。

最終的には、会社という区切りの中に、案件を入れ子にする形にしました。

ただ、それだけだと読みにくい

会社ごとに並べると、時系列や全体像が見えにくくなります。

とくに私のように転職が複数回あって、1社の中に案件が何本もあると厳しいです。

読み手は、いきなり細かい案件の説明から読まされることになります。

逆に案件ごとに並べると、今度は所属がどこだったのか分かりにくくなります。

SESだと、自社と客先の区別もつかなくなるんですよね。

だから、先頭に目次を作った

そこで、いちばん最初に職歴タイムラインの表を置きました。

書くのは3つだけです。

• 期間
• 在籍企業
• 担当した案件の概要

そして、この表からWordの内部リンクで各案件へ飛べるようにしました。

クリックすると、その会社の詳細までジャンプします。

読み手が全体像をつかんでから、気になるところだけ読めるようにしたかったんですよね。

12ページもあると、順番に読んでもらえる前提では書けません。

#6 2025年の転職活動はうまくいかなかった 今回の転職の1年ほど前にも、転職活動をしていました。 結果は、内定2社を辞退して、本命には最終面接で落ちるというものです。 つま...

ちなみにこの表は、面接のときにも役立ちました。

画面共有で経歴を説明するとき、ここを開いておけば流れを一度で説明できます。

開発の案件も、素直に全部書いた

コンサル寄りの職種に応募するので、開発の話は減らそうかとも思いました。

ただ、今の会社では開発案件しか入っていません。

隠しても仕方がないので、そのまま書いています。

ただし、書き方は変えた

工程名を並べるだけにはしませんでした。

「詳細設計をした」「単体テストをした」だけだと、誰が書いても同じ文章になります。

なので、業務内容のところにこういう行を混ぜました。

• 対応する案件の優先度づけを行った
• 課題が発生したときに、チーム内で認識を合わせることを率先して行った
• 業務運用を踏まえた観点で仕様を確認し、修正案を提案した

どれも、言われたからやったことではありません。

メンバークラスの役割としては、やらなくても怒られない範囲の話です。

未経験の職種に応募するなら、ここを書けるかどうかがかなり大きいと思っています。

技術力では専業の人に勝てないので、それ以外で何をやったかを出すしかありません。

#4 残業70時間のチームでやっていた3つのこと このシリーズは転職の記録ですが、この記事だけは転職の話ではありません。 客先常駐の開発現場で、技術以外にやっていたことの話です。 ...

チーム体制は、最初から書いていた

項目の中に【チーム体制】があります。

これは、もらったフォーマットの記入例に最初から入っていました。

なので特に意識せず書いていたのですが、これがかなり効きます。

「何人の中の、どの立場で」は必ず聞かれる

面接では、ほぼ毎回この質問が来ます。

前の年に受けた会社の最終面接では、こう聞かれました。

「なんの業務を、どれくらいの規模でやったんですか」

このとき、私は規模を即答できませんでした。

書いてはいたのですが、自分の中で整理しきれていなかったんですよね。

それ以来、人数と期間だけは全案件ぶん書き出すようにしています。

書き出してみると、自分でも忘れていることがけっこうありました。

「あの案件って、結局何人だったっけ」となるんですよね。

面接の直前に思い出そうとしても、まず出てきません。

自己PRは3つ書く

これは前回の転職からずっと続けている方法です。

転職して1年半後、1ヶ月で複数内定がもらえた理由 面接は相互理解 転職活動×東南アジアバックパッカーの目次ページはこちらです。 23年4月末でから有休消化をしつつ、転職活動をしまし...

1つだけだと、応募先の求めるものとズレたときに拾ってもらえません。

3つあれば、どれか1つは引っかかるんですよね。

今回書いた3つ

中身そのものは書けないので、テーマだけ紹介しますね。

① 間に立ってスケジュールを引いた話

ある決済サービスの切り替え案件で、リリース時期を動かせない状況でした。

こちらの都合ではどうにもならない期限だったので、間に合わせるしかありません。

追加要望が出る中で、タスクを分解して優先順位をつけて、本番に最低限必要な機能を見極めました。

② 効果を最大にするために調整した話

RPA化のときに「全部を自動化してほしい」という要望が来ました。

全部やると数か月から1年かかります。

一方、効果の高い7割だけなら、短い期間で大きな削減が出せます。

そこを切り分けて提案した話です。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

③ 業務の目的を確認して、不要な改修を避けた話

海外の売上管理システムを入れたとき、カスタマイズなしが前提でした。

ところが、ある項目が標準では500文字までなのに「業務では1000文字必要」という要望が出ます。

何のために必要なのかを聞いていくと、実際は300文字で足りることが分かりました。

10年ほど前の運用がそのまま残っていただけで、数年前から必要なくなっていたんですよね。

3つの役割を分けておく

私の場合、1つ目はどの職種でも通じる内容にしています。

残り2つは、応募する職種に寄せた内容です。

全部を志望職種に寄せると、逆に幅が無いように見えます。

それに、面接官が必ずしも志望職種の人とは限りません。

人事の方が読むことも、役員の方が読むこともあります。

開発経験は、強みとしては書かなかった

ここは少し悩みました。

せっかく3年やったので、強みとして押し出すこともできます。

ただ、やめました。

3年では、専業の人には勝てない

社会人経験が10年以上ある中で、開発は3年です。

同じ土俵で戦えば、10年開発をやってきた人には確実に負けます。

なので、開発経験は「技術力」としては売っていません。

代わりに売ったのはこの2つです。

• ITの全体を広く分かっていること
• 業務側にも理解があること

開発経験は、この2つを支える土台として置いています。

テクニカルスキルの表は、一番下に移した

以前は、テクニカルスキルの一覧を経歴書の先頭に置いていました。

今回は、それを一番下に移動しています。

参考情報という扱いです。

先頭に技術の表があると、技術で勝負する人に見えてしまうからです。

応募する職種によって、この位置は変えたほうがいいと思います。

開発の求人に出すなら、たぶん先頭のままにします。

同じ内容でも、置く場所で伝わり方が変わるというのが今回の実感でした。

待機期間は、そのまま書いた

SESなので、案件と案件の間に待機が1か月ほどありました。

これも隠さず、そのまま書いています。

結果として、触れられなかった

面接で突っ込まれることを想定して、説明は準備していました。

参画予定が1か月後ろにずれた、という事実の話です。

ただ、実際には聞かれませんでした。

12ページの中の1か月なので、気づかれていないか、気にされていないかのどちらかだと思います。

隠して後から出てくるほうがリスクが高いので、書いておいて良かったです。

まとめ：読み手が拾いやすい形にする

正直に書くと、今回は1社しか受けていません。

なので、この書き方が効いたのかどうかは分かりません。

ただ、コンサルファームに応募するにあたって、分かりやすい構成にしようと考えたのは事実です。

やったことをまとめると、この4つでした。

1. 先頭に職歴タイムラインを置いて、そこから各案件へリンクする
2. 工程名の羅列にせず、指示されなくてもやったことを書く
3. 自己PRは3つ、役割を分けて書く
4. 応募する職種に合わせて、項目の順番を入れ替える

12ページを頭から読んでもらえる前提では書かない。

読み手が、必要なところだけ拾える形にしておく。

今回いちばん意識したのは、そこだけだったかもしれません。

未経験でコンサルの面接を受けました。

しかも1次と2次が1回にまとまったので、聞ける機会は1回きりです。

なので逆質問は6つに絞りました。

聞かれたことと、こちらから聞いたことを書いていきます。

見られる基準は、事前に教えてもらえた

面接の前にフォロー面談があり、そこで何を見るのか教えてもらいました。

大きく2つです。

1. 論理的思考力　意図、判断軸、意思決定がロジカルか
2. コミュニケーション力　顧客との会話でズレないか

2つ目の理由が、聞いていてなるほどと思いました。

質疑がズレると、そのまま先のズレになるからだそうです。

基準が分かると、準備は絞れる

やったことは2つだけです。

1つは、3回分の転職理由をそれぞれ一言で言えるようにしたこと。

もう1つは、想定問答を18個用意したことです。

ちなみに、声に出す練習のようなことは特にやっていません。

SEの中途面接対策！ エピソードから回答を作る方法 転職活動記の目次ページはこちらです。 コロナ禍の2021年、私は転職活動を2カ月して、内定をいただくことができまし...

書いて整理するところまでで、あとは本番でした。

18個というのは多く見えるかもしれません。

ただ、実際に書き出すと似た質問がかなりあります。

転職理由、志望動機、強み、弱み、キャリアプラン。

この5つを軸に、聞かれ方を変えて並べただけです。

質問の意図を、先に確認するようにした

見られるのが「ズレないか」なら、やることは決まります。

ズレているかもしれないと思ったら、その場で確認する。

「こういう意味で合っていますか」から入る

意図が汲み取れないときは、先に確認してから答えるようにしました。

「こういう意味で合っていますか。それであれば、こんな経験があります」

だいたい、この形ですね。

実際、面接中に2回やりました。

分からないまま答えるより、確認したほうが早いんですよね。

以前の私なら、たぶん黙って推測で答えていたと思います。

そして途中で「あ、違うな」と気づいて、話を戻すことになります。

先に5秒使うほうが、結果的に短く済みます。

実例：部署同士の政治に挟まれたことはあるか

想定していなかった質問がこれでした。

そのまま答えると、たぶんズレます。

なので、まず確認しました。

「部門Aはこうしたい、部門Bはそうされると困る。そういう状態のことで合っていますか」

意図が合っていることを確認したうえで、正直にこう答えています。

利害がぶつかる場面はあったが、政治に挟まれたというほどの経験はない。

無いものを有ることにはしませんでした。

事業会社のIT部門と客先常駐の両方をやっているので、聞かれたのだと思います。

ただ、経験していないものは経験していません。

盛らないほうが、あとが楽

未経験の職種なので、少しでも大きく見せたくなります。

ただ、盛るとそのあと必ず掘られます。

「具体的にはどういう場面でしたか」と聞かれて、詰まったら終わりです。

私は前の年の面接で、規模を即答できずに落ちた経験があります。

#8 35歳SEの職務経歴書 書き方で変えたこと 職務経歴書は、転職のたびに書き方を変えてきました。 今回はSEからコンサル寄りの職種に移るので、見せ方もそれに合わせています。 ...

なので今回は、無いものは無いと言うことにしていました。

ちなみに、聞かれなかったこと

準備していたのに出番がなかったものもあります。

• ケース面接のようなものは、今回はありませんでした
• 案件と案件の間にあった待機期間も、聞かれませんでした

待機については説明を用意していたので、少し拍子抜けです。

とはいえ、準備していなくて聞かれるよりはるかにマシなんですけどね。

聞かれなかった質問の準備は、無駄にはなりません。

自分の経歴を整理する作業そのものが、答え方の土台になります。

逆質問は6つに絞った

前回の転職活動では、1回の面接で6〜10個は質問していました。

転職して1年半後、1ヶ月で複数内定がもらえた理由 面接は相互理解 転職活動×東南アジアバックパッカーの目次ページはこちらです。 23年4月末でから有休消化をしつつ、転職活動をしまし...

今回は1次と2次が1回になったぶん、時間が限られます。

なので、質問を絞る基準を先に決めました。

絞った基準

残したのは、この2つがイメージできる質問だけです。

• 実際の仕事の中身
• 入社した場合に、自分に期待される役割

逆に、会社の紹介を聞けば分かることは全部落としました。

事業内容や業績のような、調べれば出てくる話ですね。

限られた時間を、調べれば分かることに使うのはもったいないです。

逆質問はその人にしか答えられないことに使う。

今回はここを徹底しました。

聞いてよかった質問①：どんな人を採用したいか

1つ目は、求める人物像を現場目線で聞く質問です。

このとき、あえて一段下の職位の名前を使って聞きました。

いきなり上の役割を名乗るのではなく、下から入るつもりだという意思表示も兼ねています。

返ってきた答え

かなり具体的に話してもらえました。

• 自分と違う人。同じことをする人が増えても意味がない
• 論理的に考えて、説明できる人
• 失敗してもやり抜く力がある人
• 言われたことをやって終わりではなく、効果を出すところまでやる人
• ゴールから逆算して施策を作れる人
• 計画外のことは必ず起きるので、へこまず次の打ち手を考えられる人

「自分と違う人」という答えは、少し意外でした。

未経験で入る側としては、正直かなり心強い言葉です。

コンサル未経験でSE出身、という経歴が不利ではないという意味に聞こえました。

また、「効果を出すところまでやる」という部分も刺さりました。

作って納めて終わりではない仕事がしたい、というのが私の志望動機だったからです。

聞いてよかった質問②：1〜2年目で担当する業務

2つ目は、入社直後に何をやるのかを聞きました。

抽象的な話ではなく、具体的に何をするのかです。

返ってきた答え

• 現場に入って、改革を入れに行く
• 使われないシステムも多いので、メンバーを動かして進めることになる
• 業務の複雑さを理解する必要がある
• 現場の力学と、人のマネジメントを知っている必要がある
• 改善のリストを作って、工数とROIを試算していく
• 結局、人を動かすことがキーになる

想像していたのと、少し違った

正直に言うと、もっと資料を作る仕事を想像していました。

でも返ってきたのは、現場に入って人を動かすという話です。

これは事業会社のIT部門でやってきたことと、かなり近いんですよね。

#1 SESからITコンサルへ｜35歳SEが3回目の転職を決めた理由 3回目の転職をすることにしました。 次は大手のコンサルファームで働きます。 ただ、今の会社に強い不満があって辞めるわ...

この1問で、入社後のイメージがかなりはっきりしました。

同時に、大変そうだなとも思いました。

使われていないシステムを、使われるようにするわけです。

技術的に直すより、人を動かすほうが確実に難しいですよね。

微妙だった質問：私のどの経歴に興味を持ちましたか

失敗も書いておきます。

この質問は、あまりうまくいきませんでした。

相手が答えられない質問だった

理由は単純で、書類を見た人と面接の担当者が別だったからです。

なので「どういう経緯で書類が通ったかは分からない」という答えになります。

まあ、当然ですよね…

質問を用意するときに、相手が答えられる立場かどうかを考えていませんでした。

ただ、1つだけ収穫があった

そのやり取りの中で、こう言ってもらえました。

「経歴は見やすかったです」

職務経歴書の構成をかなり作り込んだので、そこは報われた気がします。

全体で12ページあるので、読みにくければそこで終わっていたはずです。

聞き方は失敗しましたが、結果として知りたかったことの半分は分かりました。

まとめ：手応えは半々だった

終わったあとの手応えは、正直半々でした。

聞き直した場面が複数回あったので、そこは気になります。

ただ、最終的にはちゃんと会話になりました。

分からないことでも、詰めて理解していける。

そこは伝わったかな、と思っています。

とはいえ、35歳から未経験でやっていけるのかという不安はありました。

#7 SEの王道を外れるのが怖かった話 PG から SE、そして PL・PM、その先にコンサル。 これがSEの王道だと、ずっと思っていました。 そして自分は、そこから外...

その不安は、面接が終わっても消えていません。

ただ、分からないことを分からないまま進めないという姿勢は、たぶん一番大事なところです。

面接で意図を確認したのも、入社してからやることも、根っこは同じだと思っています。