プログラミングができない。
SEなのに。
この2行がずっと引っかかったまま、俺は客先常駐で4年働いた。
先に結論を書いておく。
書けないことは、辞める理由にはならなかった。
4年のあいだ、書けなくて困った場面は一度もない。
上司には「今更コーディングは必要ない」とまで言われた。
じゃあ何も問題がなかったのかというと、そうでもない。
困ったのは、会社の外に出たときだった。
この記事は、コードが書けないまま4年やった人間が、
何に困らなくて、何に困ったのかを順番に書いたものだ。
新人研修のJava課題を、最後まで完成させられなかった
未経験でIT業界に入って、最初にぶつかったのがこれだ。
新人研修で出た課題は、生年月日を入力すると年齢を返すアプリを作るというものだった。
ただし、書いて動かせば終わりという課題じゃない。
要件定義からリリースまでの作業をWBSに落として、そのとおりに進めるところまでが課題だった。
完成させられなかった。
いま振り返ると、この課題は面白い形をしている。
俺がこの後4年やることになる工程が、丸ごと入っていたからだ。
要件定義も、進捗を管理して期日に間に合わせることも、後に仕事になった。
当時できなかったのは、真ん中にある作るところだけだった。
同期は、あっさり終わらせていた
隣にいた同期は、すぐに完成させていた。
その同期は情報学部の出身で、プログラマーとして働いた経験もあった。
しかも俺より2つ下だ。
「俺とは違うな」と思った。
そのとき頭に浮かんだのは、こういう言葉だった。
自分、やっぱり才能ないな。
IT業界でこのまま続けていけるのかな。
不安だった。これは正直に書いておく。
それでも、2つ下の同期に気兼ねなく聞くことにした
ここが、たぶん分かれ目だった。
年下に教わるのが嫌で黙っていることもできたと思う。
でも俺は分からないところは気兼ねせずに聞くと決めた。
経歴で言えば向こうが先輩だ。
年齢を持ち出したところで、コードが書けるようになるわけじゃない。
プライドを守ると、質問ができなくなる。
質問ができなくなると、できないことがそのまま固定される。
才能がないことより、そっちの方がまずい。
ちなみに、書けるようになる機会自体は3回あった。
学生時代の講義、転職前のスクール、そして新人研修。
3回とも途中で止まっている。
未経験からIT業界に入るまでの流れは未経験からIT転職するロードマップに書いた。
書けないまま4年もったのは、根性じゃない
よく聞かれそうなので先に答えておく。
気合いで乗り切ったわけじゃない。
答えは単純で、最初からコードを書かない職場だと知って入ったからだ。
入社前の時点で、コーディングもなければ、コードを読むこともないと聞いていた。
だから「業務で詰まることはないだろうな」と思って働き始めた。
実際、そのとおりだった。
配属されてからの4年、業務にコードが1行も出てこない
正確に書いておくと、Javaに触ったのは新人研修が最初で最後だ。
あの課題が終わってから、業務でコードを書いたことは一度もない。
客先常駐で何をやっていたかを並べるとこうなる。
テストから始まって、テストリーダー、要件定義の主担当、そしてPM補佐。
仕事の中身は4年で確実に上がっている。
その全部が、コードを書かずに成立した。
書けないことがバレて困った場面もない。
そもそもバレるような場面が来ない。
上司には「今更コーディングは必要ない」と言われた
コーディングの話になったとき、上司から言われたことがある。
「今更コーディングは必要ない」
必要ないんだ。
そう思った。
この言葉は、当時の俺にとってはありがたかった。
弱点だと思っていたものを、上司の側から「気にしなくていい」と言われたわけだから。
後でこれが効いてくる。
書けないのに、社内では普通に評価されていた
ここも書いておかないとフェアじゃない。
コードが書けない4年間、俺はお荷物扱いされていたわけじゃない。
むしろ任される範囲は年々広がっていった。
求められていたのは、書く力じゃなかった
実際にやっていたことを思い返すと、こういう仕事だ。
- 後輩2名を育てて、レビューする側にまわる（2年目）
- 業務要件を聞き取って、IF仕様書に落とし込む（3年目）
- 関係部署のあいだに立って、話を1つにまとめる（3〜4年目）
- 開発ベンダーに発注して、進捗と品質を見る（4年目）
並べてみると分かるが、全部が人とのやり取りだ。
要件定義は、客先の担当者が何を言いたいのかを引き出す仕事だし、
PM補佐は、作る人と使う人の間に立って調整する仕事だった。
物流で電話を取り続けた経験が、そのまま効いた
意外に思われるかもしれないが、ここで効いたのは前職の経験だった。
物流時代の俺は、配車の担当としてドライバー・荷主・上司と、
一日中まったく違う立場の人と話し続けていた。
遅れそうな荷物があれば、こちらから先に電話して謝る。
自分が起こしたわけじゃないトラブルを、自分の口から報告する。
IT業界に来て思ったのは、これだ。
結局、コミュニケーションが取れる人の方が強い。
コードが書けるかどうかは、その次に来る話だった。
少なくとも、俺がいた場所ではそうだった。
だから「書けないからSE失格だ」とは思わなくていい。
書けないことと、価値がないことは別だ。
ただし——ここで安心して止まると、後で俺と同じところで詰まる。
その話は客先常駐SEは底辺なのかにも書いた。
プログラミングスクールに30万払って、得たのはコーディングスキルじゃなかった
IT転職を決めてから、プログラミングスクールに3ヶ月通った。
費用は30万くらいだったと思う。正確な数字は正直あいまいだ。
中身は、週1回1時間の対話だけだった
どんなカリキュラムだったかというと、こうだ。
- 週1回・1時間のオンライン
- メンターと1対1の対話
- 内容は、1週間でやった内容の報告 → 疑問点の解消 → 雑談
教室に通うわけでも、講義を受けるわけでもない。
基本は自分で学習して、週に1回それを報告する形だった。
3ヶ月なので、合計しても12時間ほどということになる。
俺がいちばん聞いていたのは、技術の話じゃない
ここは正直に書く。
毎週の1時間で俺が食いついていたのは、雑談の方だった。
聞いていたのはこういうことだ。
- IT業界って、実際どんな感じなんですか
- やっぱり激務なんですか
- リモートって、みんな本当にやってるんですか
物流にいた頃の俺は、IT業界のことを何も知らなかった。
調べても出てくるのは求人広告みたいな話ばかりで、実感が湧かない。
中にいる人に直接聞けたのは、あのときが初めてだった。
スクールを勧めるかと聞かれると、答えは「目的による」
コードが書けるようになりたくて払うなら、俺のケースは参考にならない。
書けるようにはならなかったからだ。
ただ、無駄だったとも思っていない。
未経験で業界を変えるときにいちばんしんどいのは、中の様子が分からないことだ。
それを聞ける相手が3ヶ月いた、というのは判断材料になった。
それと、これは効いた。
面接で「スクールに入って学習しました」と形にして示せたことだ。
未経験の転職では、熱意を口で言っても届かない。
やったという事実の方が話が早い。
物流からIT業界に移ったときの話は物流からの転職方法｜物流→SE→ITコンサルで年収600万円にまとめてある。
困ったのは社内じゃなく、外に出たときだった
ここからが、この記事でいちばん書きたかったところだ。
上司は「資格なんていらない」とも言っていた。
実務が重要だから、と。
コーディングの話と同じ理屈だ。
そして俺は、その言葉を素直に受け取った。
結果、IT業界に入ってからの4年間で、資格を1つも取らなかった。
転職活動で、その4年を指摘された
動き始めてから、そこを突かれた。
IT業界に入ってからの4年間、資格を取っていないという指摘だ。
念のため書いておくと、資格そのものは持っている。
ITパスポート・簿記3級・FP3級だ。
ただ、ITパスポートを取ったのは未経験からIT業界に入るタイミングだ。
つまり4年前で止まっている。
指摘されたのは「資格がない」ことじゃない。
IT業界に入ってからの4年間が、空白に見えることだった。
社内の物差しと、社外の物差しは別だった
社内では、実務さえ回っていれば評価される。
毎日どんな仕事をしているか、上司には見えているからだ。
でも社外の人には、その4年が見えない。
見えないものを判断するときに、相手は分かりやすい印を探す。
その1つが資格だった、というだけの話だ。
資格が実力の証明だとは、いまも思っていない。
でも自己研鑽しているかどうかの指標にはなる。
あった方がいい。
これは実際に突かれてみて、はっきりそう思った。
社内で「いらない」と言われたものが、社外に出た瞬間に評価軸になる。
上司は嘘をついていない。ただ、社内の話をしていただけだ。
本当にしんどかったのは「書けない」じゃなく「作ったことがない」
4年やって分かったことがある。
コードが書けないこと自体は、思っていたほど問題じゃなかった。
刺さってきたのは、もう少し別のところだ。
中身は、ブラックボックスのままだった
先に断っておくと、俺は何もしていなかったわけじゃない。
テストケースは自分で作っていたし、要件定義は主担当だった。
問題は、そこじゃない。
テストの話をすると分かりやすい。
俺が作っていたのは、UAT・STで「この値を入力してください」と指示するテストケースだ。
IF仕様書に則って、入力と出力の組み合わせを設計する。
つまりコーディングは見ない。
システムの中の設計書を読むわけでもない。
この値を入れたら、連携してこういうアウトプットが返ってくる。
そこまでが範囲だった。
どういう仕組みでそれが返ってくるのかは、知らなくてよかった。
受け取る側だったからだ。
要件定義もPM補佐も、構図は同じだ。
仕様を決めるのは客先で、作るのは開発ベンダー。
開発の中身については、ベンダーに任せっきりだった。
コーディングをする環境どころか、プログラムを見られる環境すらなかった。
4年やって、そのシステムには相当詳しくなった。
でも詳しくなったのは外から見た振る舞いであって、中の作りじゃない。
作ったことがない人間の数字には、根拠が持てない
これが具体的にどう効いてくるか。
たとえば見積もりだ。
この機能にどれくらい工数がかかるのか、その数字が妥当なのか。
判断しようとしたときに、自分の中に基準がないことに気づく。
俺が持っていた根拠は、こういうものだった。
「このくらいって昔ベンダーに言われたから、このくらいかなあ」
数字は出せる。
でも出した数字を、自分で裏付けられない。
妥当性の根拠が薄いまま、それっぽい数字を置いているだけだった。
マネジメントを伸ばしていきたいと思ったときに、ここが引っかかった。
見積もりも工数の妥当性も、結局は作った経験の上に乗っている。
だから次の会社は、開発の現場も経験できるところを選んだ。
書けるようになりたかったからじゃない。数字に根拠を持ちたかったからだ。
「書けない」に悩んでいる人は、一度こう置き換えてみるといいと思う。
自分が困っているのは、書けないことなのか。作ったことがないことなのか。
この2つは、必要な打ち手がぜんぜん違う。
プログラミングができないから辞めたい、と思っている人へ
最後に、俺がやった順番と、やっておけばよかったことを並べておく。
- いま困っているのが「書けない」なのか「作ったことがない」なのかを分ける。ここを混ぜたまま悩むと打ち手が決まらない
- 今の職場でコードを書く場面が本当にあるのかを確認する。俺の場合、4年間一度も来なかった
- 年下でも経歴が上なら、素直に聞く。プライドを守ると、できないことが固定される
- 社内で「いらない」と言われたものを、鵜呑みにしない。それは社内の物差しの話だ
- 外の物差しを、辞める前に一度見ておく。転職するかどうかは、その後で決めればいい
4は、俺が実際にやらかしたところだ。
「資格はいらない」を4年間そのまま信じて、外に出たときに指摘された。
言った上司が悪いわけじゃない。
物差しが1つしかないと思っていた俺の問題だ。
最後に1つだけ、先の話を書いておく。
これは転職した後の話になるので詳しくは書かないが、
開発をずっとやってきた人より、要件定義やマネジメントをやってきた人の方が高く評価される場面を、実際に見た。
コードが書けないことは、外に出てみると思っているほど不利じゃない。
いま不安の真ん中にいる人には、それだけ先に言っておきたい。
まとめ：書けなくても辞めなくていい。ただし外は見ておく
コードが書けないまま客先常駐で4年働いて、分かったのはこれだけだ。
- 書けないことは、辞める理由にはならなかった。困った場面は4年で一度もない
- もったのは根性じゃなく、最初から書かない職場だと知って入ったから
- スクールで手に入ったのはコードじゃなく、業界の実情を聞ける相手だった
- 社内で「いらない」と言われたものが、社外では評価軸になっていた
- 刺さってきたのは「書けない」より「作ったことがない」の方だった
プログラミングができないことを弱点だと思っている人へ。
その感覚は、たぶん間違っていない。俺も4年ずっとそう思っていた。
ただ、弱点があることと、辞めた方がいいことは別だ。
やることは、辞める決断じゃない。
自分がどの物差しで測られているのかを、外から確かめることだ。
同じ客先常駐の4年をまるごと総括した話は客先常駐SEは底辺なのか、
辞めたいと思ってから実際に動くまでの順番は客先常駐をやめたいと思ったらに書いてある。
年収が下がる転職をどう受け止めたかは給料が下がっても転職してよかったと思える理由にまとめた。
