【あの人は今】30代未経験エンジニアの半年後を追ってみた。

※記事中のDIVEINTOCODEリンクはアフィリエイトです。アフィリエイトお嫌いな方はご自身でgoogle検索下さい。

33才からエンジニアになっても無事働けるのか？

以前、こんな記事を書きました！

【33才未経験】30代からフリーランスエンジニアに転向した元青年海外協力隊員に話を聞いてきた。

さて気になるのはその後。

前回インタビューから約半年が経過しましたが、無事トラブルもなく働けているのでしょうか？

今回、元青年海外協力隊（赴任地はモロッコ）から33才でフリーランスエンジニアに転向した青木さんに、生々しい話を寄稿していただきました。

未経験からエンジニアに転向希望される方、人生に迷っている30代の参考になれば幸いです。

では以下より寄稿文でございます！

スキルがあればエンジニアになれるわけじゃない

プログラミングスクール「DIVEINTOCODE」を卒業してからはスクールのメンターと受講生の使うシステムの開発に携わっていた。

しばらくして、フリーランスの案件探しを始めたが、

• エンジニア経験が浅いこと
• おそらく年齢が高めであること
• 元来面接面談というものが苦手であること

が災いし、なかなか案件を見つけることができなかった。

そんな中、先輩フリーランスエンジニアがエンジニア業の傍ら、フリーランスエンジニア転向のコンサルサービスを始めたと聞き、早速お世話になると、これが起死回生の一手となり、無事に案件にたどり着くことができた。

コンサル内容は、

• フリーランス現場目線でのアドバイス
• スキルシートだけでなく見た目の改善
• 面接のマメすぎるフィードバック
  （↑ボイスレコーダーまで使って超ストイックにやるらしい）

などかなり実践的。スキルだけあれば転職できる簡単な世界ではないということがよく分かった。

▲左：before　⇒　右：after　全然印象が違う！・・・笑

求人サイトのサービス開発現場に入る

紹介された案件というのは自社サービスとして求人サイトを運営していて、その開発をRuby on Railsで行っていくというものだった。

現場に入って、環境構築を終えて、二日目の途中から早速に開発に入る。

まず思ったのは、システムの全体像がわからないということ。

求人サイトということしかわからない。

膨大で複雑なコード群に戸惑う

3桁にも及ぶ膨大な数のテーブル、複雑なアソシエーション。

「●●の画面の修正」と言われても、まずユーザーとしてその画面にたどり着けない。

どれが関連するファイルなのか、プロジェクトのファイル群からなかなか探し出せない。

どうにか見つけても、モデルもコントローラーもスクロールバーがやたら長い。

ビューも部分テンプレートが幾重にもネストされている。

今ブラウザで見ているものとビューファイルが本当に一致しているのか確信が持てない。

手がかりになりそうな、見出しさえ、ビューファイル上では変数として書かれていたり、モデル名の英語表記だったり（ユーザーが見る画面では日本語に翻訳）する。

ソースコードに登場するメソッドがわからずにググっても出てこない。独自のメソッドやスコープだからだ。

メソッドらしきものを見るたびにRubyやRailsに元々あるものなのか、独自のものなのか判断に迷う。

自分に十分な知識があれば「こんなメソッド知らない、独自メソッドだ」という即断できるだろうが、そこまでの知識も経験もない。

一つのタスクを終えるのにとんでもない時間がかかる。

いつの日か、これらを瞬時に繙き、スマートにコードを書いていく日が来るのだろうか。

既存仕様を把握する重要性を感じた2ヶ月目

そんな風に思いながらも日々の業務をなんとかこなしていく。

2ヶ月に入ると、人のコードを読むことの重要性をさらに痛感していく。

業務内容は機能の追加やバグの修正。

すでにシステムがリリースされて、ある程度安定して使用されているからだ。ゼロからシステムを作り上げることではない。

だから大前提として既存の仕様をきちんと把握するところから始まる。

中途半端な理解で修正すると、かえってバグが増えるかもしれない。

1行のコードを確信を持って追加するために何十何百のコードを理解する必要がある。

それを頭ではわかっていても、どこかで

「きっとこうすれば動くだろうな、よし動いた！」

と安易に思ってしまう。

トラブル発生！の3ヶ月目

それがどんなに危険なことか、僕は３ヶ月目に入って思い知ることになる。

自分が機能を改修したコードでバグが発生し、現実にお客さんが困るという事態が発生したのだ。

それがクレームとなって、社内の仲間（顧客サポート部門）はお客さんから

「早くどうにかして、応募できないから」

とプレッシャーをかけられる。

当然、当事者の僕のところにやってきて

「いつまで改修できますか、お客さんに●時までに回答しないといけないんです」

とその場での回答を迫る。

言ってしまうと、それは社の回答として顧客に伝わる。責任が生まれる。

余裕を持った日数を回答したいが、そんなことを言わせない無言の圧力もある。

見かねて先輩エンジニアが入ってその場をおさめてくれる。

それどころか、「こうすればいい」とアドバイスをしてくれる。

先輩たちの尽力があって、どうにか乗り切るが、

僕は自分の無力さとエンジニアのたった1行1文字のコードの重さを思い知った。

それは本当にバグ・エラーなのか？

現場位に入ってから4ヶ月後、徐々に業務にもシステムにも慣れていき、なんとなく全体像が見えてくるとあることに気がつく。

先ほども使ったバグ、そしてエラーという言葉。社内のエンジニアと非エンジニアで、これらの言葉は違った意味で使われているのだ。

「●●を▲▲したら◆◆になったと問い合わせがあったんですけど、それってバグですか？バグだったら直してください」

と社内の非エンジニアから依頼がくる。

エンジニアとしては、それはバグではなく「仕様」だという時が少なくない。

システムの欠陥ではなく、想定した通りの動作をしているならエンジニアの言う「バグ」ではないからだ。

ただ、それはエンジニアの言い分であって、ユーザーにとって「こうなるだろう、こうなのだろう」という結果が得られなければそれはバグなりエラーであって、細かい言葉の定義はどうでもいいのだろう。

仕様であるものにバグやエラーと言われると自分たちの努力を否定された気になってしまう。

それはこんな僕にもエンジニアとして一端のプライドがあることの証明なのだろうか。

同時に、僕も(ITシステムに限らず）ユーザーの立場になった時には、同じようなことを言っているのだろうか・・・。

慣れからさらなる向上を目指す6ヶ月目

現場で6か月が経過した先日、「プロジェクト」についての勉強会が社内で開催され、改めてプロジェクトというものを見直す機会となった。

そして、それから数日後、社外でとあるセミナーに参加した。

ここ最近の僕を省みると、徐々に慣れてきたこともあって、仕事が良くも悪くもルーチンとなってきている部分がある。

僕は本当にベストのパフォーマンスができているのか、しようとしているのか。

僕は何のためにこの仕事をしているのか、自問自答をするようになった。

エンジニア経験が浅いにもかかわらず、いろいろな人のサポートがあって、今僕はフリーランスのエンジニアとしてやっていけている。

自分だけでは、とても不可能だった。

改めて、今まで以上に、結果を出していかなければと思う。

まとめ

青木さんにDIVEINTOCODEで活きた経験について聞いてみたら

＊デモデイ(自分の制作物発表会)に出たこと

との回答。自分の頭で考え抜いた経験は現場で活きているとのことでした。

逆にもっと勉強しておけば良かったことについて聞いてみると

＊Railsコマンドで実際に走る生のSQL・アクティブレコード

という回答。システムを高速で運用させるためにはムダなくデータベースとのやり取りをする必要があるため、実際にどんなSQLが走るのか理解しておくことが大事なようです。

生々しすぎる半年間のレポ。

プログラミングに関心を持ってたり学習中の方の参考になれば幸いです！

今日の一句

”動けばいい　そいつがもたらす　大惨事”