この記事について
アイ・ケイ・ケイ株式会社のシステム部に所属している@t_yanoと申します。
30歳実務未経験からエンジニアへ転職し、ちょうど1年が経ちました。
今回はプログラミングスクール入学からこれまでの実務を振り返り、今までに行ってきたことを記事にしました。
この記事で取り扱う内容
- スクールの感想
- 転職活動の実績
- 実務内容について
- 自己学習について
この記事で取り扱わない内容
- スクールの比較や紹介
- 転職活動の進め方
- 具体的な技術説明
- 効果的な学習方法
- etc...
本記事で紹介するのは実務内容が中心です。
駆け出しエンジニアがどんな仕事をしているのか、興味をお持ちの方はぜひご覧ください。
思った事・感じた事をつらつらと並べているだけのポエムですが、最後までお付き合いいただけると嬉しいです。
目次
0. 自己紹介
- 関西の文系大学を卒業（2留して24歳）
- ホテルマンとして5年間勤務
- 29歳で退職し某プログラミングスクールへ入学
- 30歳目前で現在の職場へ内定
至って普通ですね。
エンジニアを志望した動機は、より多くの人の助けになれる仕事をしたいというありがちな動機です。
前職ではお客様と直に接するよりも、業務効率化による同僚のサポートに大きなやりがいを感じていました。
ちょうどエンジニア転職が流行りだした？タイミングで、情報収集してみると自分がやりたい事にピッタリ合うなと。
ドットインストールでHTMLやJavaScriptを勉強しても抵抗は無く、向いてる！と思い転職を決意しました。
1. スクール入学と転職活動編
1-1. なぜスクール入学を選んだのか
私がスクールへの入学を決めた理由としては以下の3つです。
- 時間効率に優れていると感じた
- 体系的に学習できると考えた
- 転職サポートがあった
未経験の業界へ転職活動をする上で、20代と30代では難易度が大きく違うと思っています。
30歳目前だった当時の私としては、独学で手探りに学習を行うよりも、スクールに入って学習を行い開発経験を積むべきだと考えました。
1-2. スクールの感想
結論、入学して良かったです。
昨今スクールへの風当たりが強いように感じますが、サービスには十分満足しています。
浅く広くとはいえ1つのアプリケーションを完成させる流れを体験できたこと、良くも悪くも周りと自分を比較できたことが大きな理由です。
特に後者については独学ではなかなか機会が得られない部分なので、自分より明らかに格上のエンジニア志望者と関われたことは非常に良い刺激になりました。
「スクール入学か独学か」
この論争をたまに見かける事がありますが、本当にその人次第だと思います。
1つだけ言えるのは、生涯学び続ける覚悟をお持ちの方であれば、どちらを選んでも大差無いと思います。高額な費用を支払う必要がない分、独学の方が優勢でしょうか。
1-3. 転職活動の記録
- 期間：2020年5月～2020年7月
- 応募：約100社（スクール経由・Wantedly・リクナビ）
- 内定：3社
最終的には複数内定を獲得できましたが、全て最後の1ヶ月間で決まったものです。
そのため5月6月は合計100社近く連続で書類落ち（返答無し含む）や面接不合格でした。
この時期は絶望感しかありませんでしたが、根気強く続けた結果現在エンジニアとして働くことができています。
転職活動をしている方に1つだけアドバイスをさせていただくなら、ありがちですが自走力を挙げます。
私が考える自走力は以下の項目です。
- 意欲的に学び続ける力
- 自分で物事を考える力
- 自分で仕事を生み出す力
特に「意欲的に学び続ける力」については、エンジニアとして必須だと思います。
入社後に内定理由を聞かせてもらったのですが、「しっかり学習を続けられそう」というのが大きな理由だったようです。
この点を上手く伝えようとすると難しいと思いますが、日々しっかり学習を続けていれば自然と伝わる部分だと考えています。
面接は巡り合わせの要素も大きいと思うので、もし似た境遇の方がこの記事を読んでくれているのなら、辛くてもどうか諦めずに続けて下さい。
きっといつか報われると信じています。
2. 実務編
2-1. 業務について
Salesforceを基盤に婚礼営業支援システムのリプレイスを行っています。
婚礼業界はIT化が遅れていると言われていますが、弊社もその例に漏れず、他社が開発・提供しているシステムを組み合わせて運用を行っていました。
そのため非効率な部分も多く、実際にお客様と関わる部署（以下営業部）のスタッフが「業務」に追われ、お客様と向き合う時間が削られてしまうことが課題でした。
その状況を打開すべく、ノーコード・ローコードでの開発が可能なSalesforceでシステムを内製化して、より当社に合わせたシステムを構築して業務を効率化し、お客様へより大きな感動を提供するための時間を最大化することが現在のプロジェクトの目的です。
実際にシステムを使用するのは社内のユーザがメインですが、「最終的にはお客様のために」という思いを胸に開発に携わっています。
「Salesforceってコード書く機会あるの？」と疑問に思った方もいるかもしれませんが、日々バリバリコードを書いてます。
もちろんノーコード・ローコードでも十分開発は可能ですが、より柔軟にカスタマイズをしようとするとコーディングが必須です。
正直私もSalesforceが実務の中心になると知った時は、コードでの開発機会が全然無いんじゃ、、、と不安がありましたが、実際はしっかりエンジニアらしい業務に携われており満足しています。
2-2. 実務詳細
1年間の実務内容を大きく3つの期間に分けて紹介します。
補足として、弊社システム部はほとんどがIT業界未経験の人員で構成されているため、一般的な未経験エンジニアが1年目に携わる実務内容とは恐らく異なります。
こんな環境もあるんだ、という視点で読み進めていただけると幸いです。
【1】2020年9月～2020年10月
この期間は学習と機能調査がメインでした。
入社時はシステムリプレイスの基盤がSalesforceにほぼ決定しそう、という段階です。
翌月からは社内公募でIT研修を受けたメンバーが開発チームに4人合流する予定でしたが、そのメンバーを含め社内にはSalesforce経験者は1人もいない状況でした。
そこで同じスクール出身生で同期の@a-im-mrさんとTrailhead（Salesforceの学習用プラットフォーム）で学習を開始しつつ、機能調査を行っていました。
また翌月にメンバーが合流した時に、どのような手順で学習を進めるべきなのか道筋を示す必要もあり、多大なプレッシャーを感じると共に、それ以上に楽しんで仕事に取り組めました。
まさか未経験入社で人に教える立場になるとは思っていなかったですが、目的意識・アウトプット意識を強く持てたこともあり、効率よく順調に学習を進められたと思います。
【2】2020年11月～2021年2月
この期間は要件定義・設計・プロトタイプ開発を行っていました。
開発チームの体制が決まり、CIO1名・PJM2名・開発担当4名（私はここに所属）・ベンダー3名（準委任）の計10名でプロジェクトを進めます。
まず、既存の業務フローと営業部からの要望を元に、どのような機能が必要か洗い出すことから始まりました。
PJMとベンダーの方がメインで行っていましたが、開発担当も新業務フローの作成・提案など、一部でも関われたことは良い経験になりました。
続いてベンダーの方に基本的なオブジェクト設計（Salesforce上のDB設計のようなもの）を作成してもらった後で、どのように機能要件を達成するか大まかな設計を行いました。
「この要件はローコードのカスタマイズで達成できそう」
「いやこの部分だけはコーディングしないと難しいんじゃない？」
「業務フローをこんな風に改良すれば問題無くなる気が、、」
「改良可能かどうか営業部とのミーティングで確認します！」
このように開発チーム全員が主体的に考え、既存フローや要件に囚われないアジャイル的な思考を持って業務に取り組んでいました。
開発チームが成熟している会社だと、未経験エンジニアが設計に携わることはほぼ無いと思います。
その中で、設計書通りにただ開発するのではなく、どのように機能を実現するか考えて開発を行えたことは今後も自分達の財産となる経験だったと思います。
プロトタイプ開発についても同様で、一度出した設計の中から実装方法が不透明なもの（実装できるか不安が残るもの）に対して、工数見積を行った上で検証のための開発を行いました。
この時点ではロクに開発経験が無かったため、必死で勉強して何とか機能要件を達成することで頭が一杯だった記憶があります。
この頃に書いたコードを見返すと、今の自分でも目を背けたくなるようなコードばかりですが、そう感じられるのは成長している証拠（だと信じたい）。
【3】2021年3月～2021年9月
この期間は9月の初回リリースに向けた開発とテスト（単体・統合）を行っていました。
開発の流れとしては、スケジュール・要件・実装方法が決まっている中で、各々相談しつつ実装を進めていきます。
要件と言っても1から10まで記載してある定義書はなく、必須機能・補足や考慮事項が記載されている資料と現在の業務内容を元に、各自PJMと要件確認を行いつつ開発にあたっていました。
これはスケジュールの都合もありましたが、100%完成した要件定義書を元に開発を進めるのではなく、要件・要望へ柔軟に対応して開発を行うアジャイル思想を取り入れる狙いもあったようです。
開発・テストと共通して、この期間は自分の考慮がどれだけ不足しているかを思い知る機会になりました。
「このパターンだとどういう挙動になりますか？」
「極稀にあるこのパターンでも問題なく動作しますか？」
などの質問を受けてやっと気付く実装の不備がいくつかありました。
プロトタイプ開発を経たこともあり、機能の実装自体は何とかできるようになりましたが、特にこのあたりの考慮がまだまだ未熟だと感じています。
原因としては以下の点だと考えています。
- 社内業務（ユーザの利用場面）の理解不足による前提条件の欠落
- 異常系パターンへの考慮漏れ
- この機能はこの条件下でしか使用されないだろう、といった思い込みと確認不足
対応策としては、
- 一朝一夕で解決することではないため、まずは疑問に思ったことは確認して知識を埋めていく
- マトリックス図やフローを用いて自分の中でパターンを整理する
- 要件確認時、自分から積極的に色々なパターンが有り得るか確認を行う
ひとまずこちらを実践しているので、少しずつ改善されてきていればいいなあ、、、といった現状です。
2-3. 個人開発と実務のギャップ
個人的に1番大きなギャップだと感じたのは、規模感の違いによる保守性の重要度です。
「人間が理解し易いコードを書く」
「プログラムは変更に対して強くあるべき」
一度は聞いたことがあるような文言ですが、私は実務を経験するまでこれらの重要性を理解できていませんでした。
個人開発でポートフォリオを作成していた段階では、自分が書いたコードなら読めるし変更があっても問題無い、そもそも変更の発生頻度は多くない、と思っていました。
しかしいざ実務に入ると、要件の変更・解釈の齟齬による修正が頻繁に発生し、一度実装を完了した機能に手を加えることが度々ありました。
そこで過去の自分が書いたコードを目にするのですが、
「この変数には何が入ってるの？」
「なんでこんなロジックになってるの？」
「この処理ってなんのためにあるんだっけ、、」
と途方に暮れることがしばしば起こります。
私がポンコツなだけの説もありますが、結構あるあるだと信じています。
また修正を加えようとすると別のクラス・メソッドに影響が出ることが分かり、影響範囲全てに手を加えることもありました。
最初の段階で適切に分割できていれば容易だった作業・不要だった作業が、過去の技術的負債により重くのしかかってくるんです。
変更に強いプログラムを作るのは容易ではないと思いますが、「変更が発生することを前提に」というのが実務で学んだ1番大きな事柄だと感じています。
3. 学習編
3-1. 自己学習時間について
業務時間外の自己学習は、基本は1日平均3時間、週1日は平均8時間を確保しています。
1年間通算で1300時間ぐらいです。
これが多いか少ないかはさておき、まだまだ全然学習が足りないというのが感想です。
この1年は業務に直結する内容をメインに学習していたため、かなり分野を絞ってもこの有様です。
私の学習効率が悪い可能性は多分にありますが、この程度の学習時間ではたかが知れているということだけ伝われば幸いです。
「エンジニアは業務時間外の自己学習が必須か」
という論争が行われることがありますが、私個人の意見としては必須ではないと考えています。
しかしそれは「最低限エンジニアとして仕事ができるか」という次元での話です。
エンジニア志望者の増加や義務教育化により、この先今まで以上にエンジニアの絶対数は増加するはずです。
もちろん仕事の絶対数も増加が見込まれているので（AIに仕事を奪われる～といった話は考慮しません）、選ばなければ仕事自体はあると思います。
しかしただの作業者ではなく、一端のエンジニアを目指すのであれば、自己学習は必須だと思います。
3-2. 学習方法について
- 書籍
- 動画
- Trailhead
- 技術記事
上記がメインでした。平凡ですみません。
体系的な知識を得たい分野については書籍を選択しています。
そして唐突ですが、特に業務に役立った書籍を紹介し、学習編を締めたいと思います。
1. オブジェクト指向でなぜつくるのか
オブジェクト指向とは何なのか、理解できると何が良いのか、どのようにコードに落とし込むのか、少しだけ理解できるようになった気がします。
オブジェクト指向について言語化できない方にはぜひ読んでほしい一冊です。
2. エリック・エヴァンスのドメイン駆動設計
すごくざっくり説明すると「プログラムを適用する領域 = ドメインを中心に開発を進める」だと認識しています。
一見当たり前の事に思えますが、何が問題となっているのか、問題解決に必要なモデルは何か、など考え出すと切りがない複雑な分野に感じました。
「オブジェクト指向でなぜつくるのか」に比べると難易度が高いと思いますが、必ず業務に活きる知識なのでおすすめです。
4. さいごに
取り留めのない文章に最後までお付き合い下さりありがとうございます。
この記事が皆様の今後に少しでも役立てば幸いです。
そして最後に、少しだけ告知をさせて下さい。
人財拡充による組織作り・システムの内製化からリリースまで、本記事で紹介した業務内容の基盤構築を手掛けた弊社CIOの小田がウェビナーを開催いたします。
少しでも興味を持っていただけた方は、ぜひ奮ってお申し込み下さい。
2021年9月22日(水) 15時から、30分間の開催を予定しています。
※ウェビナーは終了しました
こちらは当社の取り組みに内容に関する記事です。
お時間があればぜひご覧下さい。
そして重ねて告知で恐縮ですが、弊社は経験者・未経験者問わず、共に働く仲間を募集しています。
現在取り組んでいるシステム開発だけに留まらず、ITに関してもウェディング業界No.1を目指し、これから様々なプロジェクトに挑戦していきます。
もし話を聞いてみたい、と思って下さった方は、こちらのTwitterへDMをお送り下さい。
立て続けに告知を挟んで申し訳ありません！
大変長くなりましたが本記事は以上となります。
最後までご覧下さりありがとうございました！