プログラミングのプの字も知らない29歳のアラサーがSEになった話
全然技術的な話ではないので Qiita の本旨とはあっていないかもしれませんが、初心者向けのITエンジニアのスタートアップ参考情報として書きます。
全ては私個人の感想と意見です🙏
実は、私、今でこそシステムエンジニア（SE）として悠々と楽しげに仕事をさせていただいているが、この記事を最初に書く時点から約2年前までは、SEとしてかなりのど素人だった。
私の Before 👉 After
SE 以前の私個人のバックグラウンド（背景）
- 学生時代は、ずっと共学の普通の学校（専門校とかでは無い。もちろん普通科）
- ●● 塾とか一切行ってない。資格もない（車とバイクと「英検２級」だけ持ってる）
- 大学は電気電子系の学部出身（サボりすぎて２回留年。情報系の知識は皆無）
- 実は、大学の選択科目で情報系の入門科目をとってみたけど、単語がチンプンカンプンで諦めて単位取らなかった
- 大学の授業でパソコンを触る事は皆無（当時の学校側のレポート複製・不正対策だった。手が筋肉痛になった）
- 社会人の最初の約５年は製造業だった（完全ハードウェア専門の部署。ソフトウェアはもちろん組み込みすらも知らない）
- 趣味：マンガ・アニメ、たまにゲームという平凡な男子
- 休日：美味しい店探すか、飲みに行く
要するに、「情報系」とは縁遠い環境で、特に前知識やベースになる下地などは一切無い。
転職理由
「じゃあなんでSEに？」
わかる、わかる。そう思いますよね。
理由は至極単純。
「IT のスキル覚えておいた方が手に職でイイ感じかな？」
何かを見て（もしくは知って）、こう思ったのがきっかけ。
漠然とハードの仕事やってただけだし、特に成長や刺激もなかったため。
あと、実はハードウェアのエンジニア以外にも、副業レベルで幅広く色んな挑戦をしたり、パート・アルバイトで興味があった全然別の仕事やってみたりとかしてました（工事現場とか、バーテンとか）。その結果、消去法的にもうあと挑戦できるのはITエンジニアくらいしか残ってなかった、…というのもありました。
SE 以前のスキルセット（というか当時思っていたこと）
- 「コンパイル？」 何それ？ オイシイの？
- Javaって「ジャバ」って読むのか。何かの頭文字４つかと思った。
- 「=」って数学のイコールだよね？ 代入になるとか頭おかしい。
- 参照型？値型？・・・うん、日本語でおk。
- IT業界の人って、横文字好きだなぁ…。
こんなことを真剣に悩んでいたレベル。
SE になった直後のスキルセット
- 研修は何とか卒業できたけど、現場に出たら全然仕事わかんない
- 英語で大量の赤い文章が突然出てきたけど、どうしたらいい？帰っていい？
- 「デグレ？」「プロキシ？」「ナイケツ？（尻？）」…おっけ、みんな落ち着け。日本語で話そう。
- 「工数を見積もれ」と言われても、何するのかもどんくらいで終わるのかもサッパリわからないから見積もれねぇよ。とりあえず１ヶ月って言っておけばいい？
現在のスキルセット
- SE として現場でバリバリ働いてまっせ
- 最近はPM（PdM）っぽいのもやるようにはなったよ
- ウォーターフォール開発もアジャイル型開発も一通り
- フロントエンドもバックエンドも実装からテスト・リリースまでやるようになったよ
- 軽い Web デザインも自分でやるし、オリジナルサービスも企画・開発するよ
- DB周りもバリバリ触るし、インフラ構築、ミドルウェア選定、要件定義も基本設計もやるよ
- 新規プロダクトのアーキテクチャ検討チームに入れてもらったり、技術選定とか任せてもらえるようになったよ
- 言語：HTML, CSS, JavaScript, TypeScript, Java, PHP, Ruby, Swift, Python, C#, Swift, Dart etc...
- FW： Angular, Vue, React, Node.js, Express, Flutter, NestJS, Laravel, Rails, Django etc...
- AWS, Azure, GCP（＋ Firebase） などメジャーどころのクラウドも一通り触るよ
- 簡単な Web アプリなら、一人でも仕事終わりの時間で１日で作るよ
- モバイルアプリも Flutter で作り始めたよ
- コールセンターで仕事してた知人の文系女子を、IT 現場でお客さんに評価される SE になるまで、転職アドバイス〜教育までしたよ
- 社内エンジニア教育プロジェクトの責任者もやってるよ
こんな感じでしょうか。
本題、ド素人の初心者は、最初何からしたら良いのか？
基本的に、プログラミング学習スクールや、特別な研修等は要りません。分厚い本を読むのも不要です。
（「要らない/不要」というのは、本当に必要ないって意味ではなく、「後回しでも良い」 という意味です）
最初は、以下のことを調べると良い。
<単にプログラミングやアプリ開発を学びたいレベルなら>
- そもそもプログラミング言語とは何か： アメリカ人には英語、日本人には日本語、コンピュータにはプログラミング言語。そんなイメージ。
- プログラミングとは何か： 機械やアプリ/ソフトウェアに理解できる命令文を作ること
- プログラミングをしてから、アプリやシステムが動くまでの流れ： プログラミング言語で書かれた言葉は、"0"と"1"だけの「機械語」に翻訳されて、コンピュータが動く。
-
次の言葉を調べて、何のことか＆何をしてるのかをざっくり理解する
- 「高級言語/低級言語」： 人間が理解できる言語/機械が理解できる言語(0/1)
- 「コンパイル」： 機械が理解できる言語(0/1の羅列)に翻訳すること
- 「コンパイラ/リンカ」： コンパイルしてくれるやつ/コンパイルした言葉に必要なものを集めて繋げてくれるやつ
- 「実行ファイル」： リンカが最終的に吐き出してくれる、動作するファイル
- 「ビルド」： コンパイルから始まり、実行ファイルを作るまでの一連の作業・処理
- 「バグ」： プログラムを動かしてみたら見つかったオカシイところ。不具合
- 「デバッグ」： バグを探し出して修正すること
-
設計とは何か： プログラミングするって言っても目的と方法が必要。それを決める工程
- どんなシステム？ Webアプリ？/スマホで動くアプリ？ 言語は何？ といったことを決める
- テストとは何か： プログラミングしたものをちゃんと動くか検査すること。その工程
<お仕事として考えている人は>
-
代表的な開発手法： １つのアプリやシステムがリリースされるまでの流れ。開発の仕方
- ウォーターフォール開発
- アジャイル型開発（今はまだ詳しく調べなくても良い）
- わざわざ「型」と入れているのは、「アジャイル」は 開発手法ではない から（＝開発手法だと誤解するから）
-
ウォーターフォール(W/F)開発の流れ（以下、上から順に流れることを知る）
- 要求分析：「何を作りたい？」「どんなことを実現したい？」
- 要件定義：「要求に応えるには、何を考えなければいけないか。何を作ればいいか」
- 基本設計：「要件定義を満たすためには、なんの機能があればいいか」
- 詳細設計：「基本設計で決めた機能は、どうプログラミングすれば実現するのか。（細かい数字や変数名まで全て決める）」
- 実装（製造orコーディングとも）：「実際にプログラミングしてみよう！」
- 単体テスト：「"実装"が詳細設計の通りか、おかしいところが無いか確かめる」
- 結合テスト：「基本設計の通りか確かめる」
- システムテスト（総合試験）：「要件が満たせているか確かめる」
- リリース：「作ったものを、世の中に公開しよう！」
- 保守・運用：「リリースしたものに問題とかあったら随時対応します！後から追加した新機能のリリースとかもします！」
-
W/F開発するときのポジション/役職なども知っておく（厳密な範囲はあとで学ぼう）
- PG： プログラマ。実装と単体テストあたりをやる。数人で手分けして仕事する。
- テスター： 本来そんなポジションはホントは無いけど、プログラミングせず結合テストとかばっかりやる人。数人で手分けして仕事する。プログラム知らないアルバイトとかがやる場合もよくある。
- PL： プロジェクトリーダー。PGなどを数人まとめて開発するチームのリーダー。PGと後述のPMの中間的な役割。チームのピラミッドのNo2くらいの位置。1人か、PGよりも少ない複数人。実装は、したりしなかったり。
- PM： プロジェクトマネージャー。開発チームのピラミッドのトップ。基本はチームに１人。開発スケジュールとお金管理系の仕事をする。資料作ったり、会議したり、依頼主のお客さんと関わる仕事がメインなので、全体に関わる「要件定義」や「システムテスト」あたりでしか出てこない。
- 最近は、工数管理などに特化した「PjM（プロジェクトマネージャ）」と、作るもの仕様決めなどに特化した「PdM（プロダクトマネージャ）」って棲み分けも出てきた。
- 一言で「SE」といっても、PM/PLのように"上流工程"をする人や、PG/テスターのように"下流工程"しかし無い人もいる。詳細設計もするならPGとは言わない。SEでいい。
<お仕事として面接や面談を予定している人は>
-
どういう人が、"欲しがられている"のかを知っておく（自分がまだ優秀ではない前提で）
- 開発現場にさえ入れれば経験が積める。まずは開発に参画させていただけるかどうか
- まずはプログラムのお手伝いレベルか、テスターでも構わない。
- 現場の経験知識は、どうせ本や学校では学べないので、採用者は根本的に「仕事についてこれるか」を心配している
- 「ちょっと教えれば大丈夫そうな人」と思われたら、お仕事させてもらえそうな可能性はアップ (￣ー￣)b
- ネガティブで後ろ向きな人は欲しがられない。
- 「できそう？」「大丈夫そう？」的な質問には、「調べたりできる環境があればいけます」と応える（実際は現場に入ったら、ネットで調べながら他人に聞きまくる）
-
未経験であることよりも、自分の"伸びしろ"を強調する
- IT業界には一切関係ない業界や過去の活動の中で、「円滑なコミュニケーションを図れること」と「吸収力/成長力」をアピールできる具体的なエピソードを１つ用意しておく
- わからないことがあっても、アピールした"コミュニケーション能力"と"吸収力/成長力"を使って周囲に質問しながら開発現場に「ついていける/追いつける」姿勢を見せる
- 質問には、先に簡潔な結論を答えてから、詳しい内容やエピソードを話す。
-
「業界では普通こういう意味」って単語も、実は微妙に意味が企業や現場で違うことがあることを知っておく
- 例えば、とある企業の営業が「SEっていのは普通〇〇するポジション、PGは〇〇までしかやらない」って言っても、違う企業の営業・違う現場の担当者、同じ企業の違う立場の人はちょっと違う意味や範疇で使っていたりする
- つまり、この業界で「普通はこう」っていうのは、あまり信じすぎなくていい（そういう人も多い、くらいに捉えておいた方がいい）
ちょっと細か目に書いたので、内容が多く感じるでしょうか？
でも、お仕事として考えるなら、これは最低限おさえておかないと話になりません。逆に言えば、ここをおさえておくと、研修などがある企業ならお仕事としてもやらせていただける可能性がグッと上がります。
あとは、その人と会社のマッチングの問題のみ。
新しい知識を覚える時のコツ
これは、プログラミングに限りません。現場の仕事の回し方も同様です。
まずは全体像をつかむことから始めるべし
- 何となくレベルで良い。スピード（短期間でざっくり理解を終わらせること）重視。
- 専門書を読んだり、細かい調査や調べごとは後回し。
- 厳密に正確に情報を覚えようとしない。間違ってもいいからイメージを先につかむ。間違って覚えたことはあとで修正できる
- 「絵」でアウトプットすること。自分で図解すると、文字よりも理解が早まる
- 最終的に「一言でいうと」レベルで、自分なりの説明にまとめる（別に間違っててもいい。あとで修正できる）
疑問は聞きまくれ。なる早で解消するべし
- ちょっとでも確信が持てなかったらすぐググる（ネット検索する）
- ChatGPT は嘘もつくので "参考情報をくれる奴" という認識で利用する
- "その道の方" がお知り合いにいたら、お時間をいただいて聞きまくる。
- 本や資料を参考にするときは、困った箇所だけ読んで済ませる（世の中の技術のバージョンアップは非常に早いが、本は出版までが遅い ＝ 情報が古くなる可能性がある）
「実際に触る」機会をつくるべし
- ネットや知人を頼りに、実際にソースコードを書くのが一番わかりやすい
- 結果がすぐ目に見える言語から試す(プログラミング言語ではないが、HTML等フロント側からやるのが楽しいかと）
- エラーが出たら喜べ。成長チャンスだ。エラーで諦めない。何でエラーなのか調べる（でも、一人で悩み続けるのはNG。有識者に聞くのが早い）
- 「結構調べたし、今日は無理だ」って思ったらその日はとりあえず諦めてもいい
自分の"育ち"や、環境・バックグラウンドは気にしない
- 「やったことない」という過去は気にしない。これから覚えればいい
- 文系出身とか関係ない（人間の脳の作りはみんな同じ。文系/理系だけでは脳構造は変わらない）
- 苦手かどうかは関係ない（朝が苦手な人間でも出勤時間は守れる。要はやる気の問題）
- 「私、パソコンとかITとか向いてないんだよね」っていうのはただの自己洗脳だから、その考えはやめた方がいい
- できない理由よりも、やる方法を考える（できない理由は、無限に作れる）
なんか技術だけじゃなくて考え方的なことまで書いちゃいましたが、これらに注意すれば、かなりの短期間でベースは掴めると思う。
（私の場合は、周囲に聞ける人いなかったので 3ヶ月くらいかかった。）
自分自身のことを、もっと知りなさい
- 何かに取り組み頑張るときは、取り組む対象について学ぶだけでなく、自分のコントロール方法を知っておかないとキツくなる
- 自分はどういう時にテンションやモチベーションが下がるのか（上がるのか）
- お酒と一緒で、どこまでいくと限界なのかを知っておき、その手前でバランス調整できるようにする
- やる気がなくなる時、作業が進まない時、その共通点やパターンを自分で見つけて対処することは大切です（人に聞いて癖を教えてもらうのでも良い）
- どうすればニュートラルな状態にリセットできるのか
- 映画やマンガなのか、ドライブや旅行なのか、散歩なのか、食事なのか、ゲームなのか、デートなのか、YouTubeで誰かの動画見ると良いのか、寝ればなんとかなるのか、…とか、そういうのを把握しておいた方がいい
- 今後、何がしたいのか。やる理由はなんなのか
- 積極的な目標で頑張れるタイプ：年収金額とか資格取得とか、何かを達成するために目指すと頑張れるタイプの人
- 消極的な目標で頑張れるタイプ：これをやらないとネガティブな未来が待ってる。自分が困る。それは嫌だ！だから頑張れる…てタイプ。（※ 筆者はこのタイプの人）
- 作業ゲーが得意なタイプ：とりあえず作業を初めてしまえば、好き嫌い関係なく無感情で淡々とこなせるタイプの人
- あと大事なのは、目標は途中でコロコロ変わってもいい ということ
- 自分のキャラクターを理解して、見合った取り組み方をする
- 例）無理しすぎると爆発するタイプは、ちょっと気が滅入ったら寝るとか予定を変更するとか、ちゃんとバランスを取れる調整を入れた方がいい
- 自分で自分のコントロールが難しい場合は、第三者に監視してもらう
- 他人に自分の状況を話さなければいけない状況を作って、心理的に自分をコントロールする
- 自分でプランを立てたり目標を決めても続かない人は、「一人で頑張りきる」という選択をそもそも諦めるべき
- 「自分の目標を開示し、月に２回会って話す機会を作ってもらう」とかを誰かと決めるだけでも、他人の目があるから多少一人よりは成長が進む（毎月お茶する約束とかするだけでもいい）
権威バイアスに気をつけろ
「権威バイアス」とは、【権威のある人や専門家の言動はすべて正しいと思い込み、深く考えずに信用してしまうこと】 です。
「エンジニア歴●●年」「有名なあの企業で活躍してた」「有名なあのアプリを開発してた」「●●界隈で有名な専門家だ」「フォロワー数●万人のエンジニア系インフルエンサーだ」っていうのが権威性に該当します。
これは、参考値として信頼材料の１つに留めるべきで、崇拝するようになってしまってはいけません。
彼らも皆、人間です。
間違ったことも言うことはあり得るし、感情も持っているし、技術以外のことはポンコツかもしれません。…って言うメンタルは意外と大事だと思います。
あくまで自分自身の成長と関心を進めるために、参考にさせていただく人たちというのがコツだと思います。ただ、自分の中で「あの領域ならこの人の意見も見てみよう」っていうのはいくつか揃っていると参考にはなります。
まとめ
要は「行動順序」が大切
人間は、「挫折」で成長するのではなく、「成功体験」（＝挫折からの〜乗り越え体験）で成長します。
ガチの IT ド素人 は HTML, CSS からやってください。そして、ちょっとだけ JavaScript をやってください。フロントエンドと言われる領域に触れる人は、この３つの技術が必ず根底にあります。
ある程度ショボい画面が作れるレベルになったら、もう Java や Python などのバックエンドに行っちゃいましょう。（１つにこだわって極めようとしない事がポイント）
結局、大切なのは 順番 と トライ＆エラー ＝ 行動 です。上記の内容が、長くて覚えられないと思う方は、最低以下の３つを覚えてください。
- ❶ 厳密で正確な理解は後回し。あとで修正できる
- ❷ まずは、手足を動かして行動し、自分がイメージできるレベルに持っていく
- ❸ 「エラーを出すこと」が初心者脱出の必須ステップ
加えて、お仕事として考えている方は、以下も覚えてください。
- ❹ どういう人が、欲しがられているのかを知っておく
現代は、12歳の子供がまるで新しいオモチャかゲームを遊ぶかのようにプログラミングに触れ、80過ぎたおばあちゃんが独学でアプリを開発し Apple 社のプレゼンで取り上げられたりする時代です。
安心してください。💁♂️
プログラミングは、極めるのは困難だが、習得はカンタンです。
あくまで個人的な意見が満載ですが、実際にこの内容を元に、私自身も、私の周囲も、ITのエンジニアとしてスタートを切ることができています。
プログラミングが、特殊で専門的な人間にしかできない時代はもう過去の話です。
これから初めてプログラミングを覚えたり、仕事としての選択肢を考えられている方にとって、少しでも参考になれば幸いです。
参考 YouTube
とみぞーHackTube（チャンネル）
プログラミング初心者にオススメのPCスペック・学習方法（動画）
プログラミング初心者が最初に学習すべき内容（動画）