転職や副業について調べると必ずと言っていいほどオススメの職業・スキルとして「プログラマー」「プログラミング」という単語を見かけます。
しかも「未経験OK」や「文系歓迎」という言葉が続いていることも少なくありません。
しかし、実際に未経験でプログラマーになったとして、どうやって仕事が出来るようになるのか具体的にイメージ出来る人は少ないのではないでしょうか。
ここでは入社後から実務に馴染むまでのひとつの具体例として、筆者の「保守運用」業務での体験談をご紹介します。
プログラマーがどのような作業を求められるのか、気になっている方の参考になれば幸いです。
記事を書いているのはこんな人
私はIT業界に転職して今年で5年目になるシステムエンジニアです。これまで複数の企業でSIerとして2年半、SESとして2年、受託開発として半年程務めてきました。
現在は客先に常駐し、情報システム部門の技術者として主に社内システムのメンテナンスや新しいシステムの開発・導入作業を行っています。
この記事ではプログラマーとしての目線で、転職時の入社後研修～OJTまでの約1年間の内容を書いていきます。
バリバリに新規開発を行うタイプのプログラマーとは異なりますので、あくまで一例として見て頂けると幸いです。
26歳、スキルを求めてIT企業に応募
筆者の業務経験は中途の応募から始まります。
それまでは4年制大学を卒業後、アルバイトや事務職を転々としており、入社前にプログラミングについて勉強をする機会はありませんでした。
強いて言えば事務レベルではExcel関数をいじるのが好きな人、くらいに周囲に思われていたかもしれません。
「未経験OK」で「入社後研修あり」
先述の通り20代後半までフラフラしていた筆者は、ようやく将来のことが気になり始め、正社員の就職と潰しがきくスキルを求めて地元のハローワークや合同企業説明会に通っていました。
そんな折、とある求人イベントで「未経験OK」「入社後研修あり」というIT企業を発見し、「これだ！」と感じた私はすぐさまブースに駆け込んで最前列で説明を聞き終えると、その場で企業の方に応募の意思を伝えました。
浅ましい考えかもしれませんが、何よりも給料を受け取りながら技術を習得出来ることに強く惹かれての応募でした。
入社前には面接の他、SPI試験や適性検査等がありましたが特に対策を行うことなく合格が決まり、無事に入社出来る運びとなりました。この流れは今思えば非常に幸運なことだったのかもしれません。
基礎レベル、でも手厚い社内研修
入社後の3か月間は、プログラミングに必要な知識や技術についての研修を受講し、基本情報技術者試験レベルの知識やアルゴリズムに関する講義の他、以下のような内容を座学・実習を交えて学習しました。
- Javaの基礎
- オブジェクト指向の考え方
- サーブレットの考え方
- MVCモデル
- データベース（Oracle）の基礎
参考書5冊分程の内容の研修を3か月で行ったため内容はかなり充実しており、学生時代にC言語を学んだことのある同期でも、まったくの未経験組と一緒になって苦労していたように記憶しています。
この辺り、「プログラミング言語を知っている」と「プログラミングが出来る」には大きな違いがあるということがよく分かります。
いざ実務開始！……の前にまた学習
入社後研修を終えた後は担当部署に配属となり、すでに稼働中の案件でOJT＝実務を兼ねた研修を行うことになりました。
ただし配属後数週間は、案件で使用するメインの言語や案件で扱うシステム仕様に関する学習がほとんどで、実際の業務と呼べる作業にあたったのはそれらが終わってからでした。
このシステムの仕様に関する内容を頭に入れることがとても重要で、かつ最も苦労した部分でもあります。
稼働中の案件に初参加？
初めて参加した案件は業務系基幹システムのリニューアルと保守を行う案件でした。ただしその案件は、扱うシステムのコードがJavaではなくC#という言語で書かれていたため、C#が分からないと仕事が出来ないという場所でした。
ネットでよく「プログラミング言語は1つ分かれば他の言語もだいたい分かるようになる」という話を見かけますが、それは実務が分かっていることが前提であり、当時の筆者のような初心者には当てはまらない話です。
役に立てないのではと不安を抱えたまま配属先に向かった私を、先輩方は暖かく歓迎してくださり、そして一冊の分厚い本を手渡してくださいました。「独習C#」というまっ黄色の学習本でした。
本の内容を2週間で叩き込むのが、そのままでは仕事が出来ない筆者に与えられた最初の業務でした。
「実機」「ソースコード」「仕様書」
2週間を待たずに何とかC#の本を終わらせると、続いて業務系システムに欠かせないデータベース（その中でも特に問い合わせ）とコーディングに関する学習を行い、その後にやっと案件で扱うシステムについて知るフェーズとなりました。
分厚いA4ファイルに閉じられた紙の仕様書はとにかく分かりづらく（書かれた方には申し訳ないです）、理解が進まないため先輩に相談したところ、プログラムの内部コード（ソースコード）を読み、検証用のシステム（実機）を動かしながら、仕様を把握するようアドバイスを頂きました。
アドバイスに従いシステムのソースコードを見てみたものの、基礎を学んだはずのC#で書かれているにも関わらずさっぱり理解出来なかったことで、当時の筆者は悟りました。
結局、実機で画面を操作したりデータを入力したりして動きを確認し、その結果からソースコードや仕様書の意図を読み解くという、本来あるべき手順とは逆の方向から仕様把握に務めるようにしました。
与えられた2つの詳細設計書
システム仕様書が何とか読めるようになり最低限の開発準備が整った筆者は、案件のリーダーから2つの詳細設計書を受け取りました。
詳細設計書とは料理のレシピのようなもので、その内容通りにコードを書けば正しいプログラムが完成する（しなければならない）という、プログラマーの作業に欠かせない大事な資料です。
詳細設計書が2部あることから、当時の筆者は2つの機能について開発を任された状態となります。
マスタ管理は初心者の定番
担当機能の1つ目は「マスタ管理」と呼ばれる種類のシンプルな機能でした。
構造がシンプルなので仕様書の内容は少なく、しかも先に作られた同じような機能があったため、1つ目の開発はあっさり終えることが出来ました。
紙とペンでプログラミング
2つ目は、数値が条件に当てはまるかチェックしていくような「判定処理」の機能でした。
先に開発したマスタ管理よりも複雑な上に、今度は参考に出来る機能も存在せず、とりあえずコードを書き始めてみても何が正解なのかもはっきりせず深みにはまるばかり。
筆者が頭を抱えそうになった時に、そういえばある先輩が時々、紙にペンで何かを書きなぐっていたことを思い出します。
先輩はまさに、紙に図を書いてプログラムの内容を整理していたのです。
この時に筆者は、紙にアイデアを書き出して頭の中を整理し、答えが見つかったらその答えだけをキーボードで入力すればいいという、作業の効率化に欠かせないを学びを得ました。
その他まとめ
その後もC#の案件が2年半程続き、それ以降はASP.NETやVB.NETという言語をメインに、今日までで約2年半程業務にあたって来ました。
さらに、Webシステムに欠かせないhtmlやcssは上記の言語と並行して4年と半年程扱っています。
以上が筆者が未経験入社から約1年間に体験した大まかな流れとなります。こうして見ると、期間全体を通して学習や仕様把握のために読み物をしている時間が多かったんですね。
実際、筆者個人の体感でも、保守運用におけるプログラマーは「書く力」よりも「読む力」が重要なように感じています。
資料にしてもコードにしても、誰かが書いたものを読み解いてプログラムを理解することが出来れば、立派にプログラマーとしてやっていけるのではないでしょうか。
他人が書いた資料やコードをたくさん読んで答えを探すのが主な仕事なのだと思います。
多少知識に不安があっても、ネットで検索して解決出来ればOKなのです。
記事の内容が少しでも皆様の参考になれば幸いです。
そんなこと言って入社したらすぐ現場で開発とかじゃないの？