未経験から中途でエンジニアになりメガベンチャーに入るまでの軌跡を振り返った

僕は未経験からエンジニアになり、今はメガベンチャーでエンジニアとして働いている。

未経験からエンジニアになるのはそれなりに難しく、願いが敵わないパターンも多くあると聞く。 そんな中、なぜ自分はエンジニアになり、メガベンチャーで働くことができるようになったのかを分析するため、未経験からエンジニアになるまでに歩んだ道のりのポイントポイントで抱えていた悩み、頑張っていたことなどを思い出し書いてみる。

今、未経験からエンジニアを目指している人がいれば参考になるかもしれない。
（時代や運の影響もあるのであくまで参考程度に)

webデザイナーブラック期（スクール、契約社員）

大学新卒から4年、僕はITとはまったく異なる業種で働いていたのだが、ある理由で転職することにし、転職先職種に「WEBデザイナー」を選んだ。

時期的には2008年あたりだが、今で言う「エンジニアブーム」みたいな感じで「WEBデザイナーブーム」みたいなものがこの頃はあった（ように思っている)。

僕はPCには興味がある方だったのと、自分が「なんかカッコいい職」に就けるのに高揚感もあって踏み込んだ。あまり深くは考えてなかった気がする。

転職までの準備期間として、働きながらWEBデザイナーのスキルを教えてくれるスクールに通った。
教えてもらったのはHTML/CSSの基礎とPhotoshop, Illustratorの使い方の基礎。デザインについての授業はなかった。
カリキュラムを終えたタイミングで退職し、転職活動を始めた。

やはり未経験からはなかなか職が決まらず、約半年の無職求職期間を経て契約社員で雇ってもらうことができた。
風俗ポータルサイトの運営を行っている会社だった。

業務内容は「ポータルサイトの風俗店の情報更新作業」がメインで、付随して「バナーデザイン」「企画ページのデザインと構築」があった。

「風俗店の情報更新作業」とは日中ずっと行う必要がある作業で、常時営業から新しい女の子のプロフィールや画像が送られてきて、それをポータルサイトに反映させるといったものだ。
基本はコントロールパネルからデータ入力を行ったり、Photoshopで顔にボカシを入れる程度の作業なのでhtmlの知識もデザイン力もいらない。

「バナーデザイン」とは、ポータルサイトのバナー表示枠に表示するバナーをデザインする作業だ。
表示枠を購入した風俗店から女の子の画像と載せてほしい内容が送られてきて、いい感じにバナーデザインに落とし込む。
バナーには数種類のサイズがあるので、一つデザインを作成したら、デザインを微調整しながら各種サイズバナーを作成する。

「企画ページのデザインと構築」とは、ポータルサイトに掲載する読み物コンテンツのページデザインとHTML/CSSによる構築を行う作業である。
「〇〇店の体験特集」とか「紳士の嗜みとしての風俗特集」みたいなやつである。

企画と掲載する内容は別部署から上がってきて、それを見栄えするようにデザインし、そのページをHTMLとCSSで組み上げる。
こういうのはHTML/CSSの知識も要るし、まさにページデザインも行う必要があるので、大体はデザイン力のある先輩デザイナーがやってた。
少しだけ自分も携わった。

余談だが、風俗店への直接電話営業までさせられたりしていた。

悩んでいたこと

デザインができない

まず、僕はデザインができなかった。

僕は前述したとおり、HTML/CSSとAdobeツールの使い方を学んだだけで、デザインについては素人だったのでデザイン業務は苦労した。
簡単なバナー作成の仕事にしても、頭ではカッコいいレイアウトとかイメージできているつもりだったのだが、いざ形にしてみるとクソダサデザインにしかならず、どうすればまとまった見た目になるのかまったくわからなかった。

時間をかけてもかけても全く完成に近づいていかず、冷や汗を書きながら自分でもイマイチなデザインを上司レビューに上げては直しを食らって、、をひたすら繰り返していた。そんなことを繰り返していると上司からのアタリもキツくなってきた。

残業

職場は慢性的な残業体質だった。
自分の手が遅すぎるのもあったと思うが、ほかメンバーや他の社員もずっと残っていたのでそういう風土があったと思う。
日中は主にポータルサイトの情報更新作業で時間がとられるので、定時後になって更新作業が落ち着くとやバナーデザインや企画ページデザインを行っていた。

最初は「一人前になるためなら多少のキツさは覚悟の上！」みたいなつもりでやってたが、ずっとダメ出しを食らっているような状況なので成長も感じられずただひたすら辛かった。
デザインはなかなかOKが出ないが締切もあるので、終電後家に持ち帰って3時頃までレイアウトをこねくり回したりしていた。
「そろそろ終電なんで帰ります」とよく言っていた気がする。

頑張っていたこと

特に戦略を持ってなにかを頑張っていたものはなかった。
言われた指示に従ってデザインOKをもらうことで精一杯だった。上記したように、持ち帰って作業もしていた。
ダメ出しを食らうのがわかっていてデザインを提出するときは惨めに思ったし、精神的にかなり疲弊していたが会社は休まないようにはしていた。

それでも最終的に音を上げて転職した。

実感として成長は感じることは出来なかったが、長時間労働に関する感覚は得ることが出来た。

webデザイナーマッタリ低賃金期（ECサイト管理）

転職先はECサイトの管理業務だった。

会社はペットフードの卸業を行いながらECサイト（楽天・Yahooショッピング・自社EC）で販売を行っていた。
僕はYahooショッピング担当として「商品ページの作成」「時期ごとのキャンペーンページの作成」「問い合わせ対応」「メルマガ作成」「商品在庫管理と発注・入庫作業」「庭の草刈り」を行っていた。

大体はルーティン作業で、仕事自体は苦労なくこなすことが出来た。

デザイン作業として、キャンペーンページやキャンペーンバナー作成が必要だったが、この会社はデザインについてこだわりがなく、適当にそれっぽくレイアウトしておけばレビューは通ったので、それほどデザイン作業で苦労することも無かった。

残業もまったくなく、まったり働くことができた。

ECサイト管理業務だけではなく、広く雑用として利用され、試供品をデパートで配ったり、アイスクリームチェーン店（オーナーの持ってる事業の一貫）の呼び込みも特に憤りなくやったりしていた。

悩んでいたこと：

低賃金

前職と違って、業務で悩むことはあまりなかったが、とにかく低賃金だった。
そもそも前職も低かったがそれ以上に。。月収15万だったので手取りで13万とかだったと思う（翌年は1万昇給した）。実家ぐらししていたのと、前職のトラウマでそれでもそれほど不満なく働いていた。
年頃だったので彼女とデートなどのイベントもあったが、一度デートに行くとその月はちょっと厳しい、、みたいな感じだった気がする。
これでは結婚もできないなぁとか思ってた。

頑張っていたこと

JS,PHP,SQLを自習した

この頃、なぜかJSやPHPやSQLに興味を持って自分の時間を使って学んでいた。（毎日定時退社だったので時間はあった）
FC2レンタルサーバの無料枠を使ってJSとPHPとMySQLを使ったちょっとした実験サイト（DBから取得したデータでページを出力する）みたいなものを公開してみたりしていた。
SQLを学んだので、会社の業務でもACCESSでSQLを使って在庫データをいい感じに見れるようにしたりしていた。 （特に社内で展開せず自分だけで使ってニヤニヤしていた）

特に仕事に不満はなかったが、とにかく低賃金だったのと、JSやPHPをちゃんと使える環境を求めて転職先を探し転職した。 （Yahooや楽天ではJSやCSSを使うのに制限が多く、もっと色々試せる環境で仕事してみたくなった）

JS触れるwebデザイナー期

転職先は、自社サービスを運用開発（正確には受託だったが自由度が高かった）していたので、自社サービスの運用開発についてのノウハウを色々体験することができた。
当時、関西で自社サービス開発を行っている会社ってそれほどなかったように思う。自分がどのようにその会社を見つけて応募したのか全く覚えていないが、何社か受けてなんとなくおもしろそうと思って入った気がする。

オフィスも広くて、和気あいあいとした空気感で、皆若かった。 エンジニアもたくさんいた。

その会社はチーム単位で一つのWEBサービスを担当しており、僕は動画コンテンツの売買サービスを担当している4人ほどのチームに入り、サイトデザインのリプレイスや、新機能のUIのデザインとHTML, CSS構築を行ったりしていた。

エンジニアとの分業を体験し、gitも初めて触った。

悩んでいたこと

デザインが苦手

この会社では求められるデザインのレベルが高かった。

僕は、前述したようにデザインはもちろん、UIについても全く素人だったので（なんで採用されたんだろう。。）ここでもやはり苦労した。
サービスデザインのリプレイスでは、WEBサービスの勘所を外しまくったデザイン案を副社長（副社長はデザイン職のTOPだった）まで上げて「こいつは駄目だ。。上長達はこれをほんとに良ししたのか？」と大事に発展させてしまった。

それ以降も、そこまで大事になることはなかったが、なかなかバシッとしたデザイン案を作ることができなかった。
デザインを作成した自分に自信がないものだから押しが弱く、そうなると皆意見を出してくれるのだが、それ故方向性が四散しデザインがまとまるまで苦労することが多かった。

デザインには自分のデザインに対する自信と、案を押し通す説得力が必要だったが、僕はそれがなかなか得られず苦労した。

頑張っていたこと

デザインについて学んだ

上記のようにデザインで本当に苦労したので、デザインについては相当学んだ。

学んでわかった事がある。
デザインにはロジック的な要素と、フィーリング的な要素がある。

ロジック的な要素に関しては書籍で学べた。
どのように要素を配置すれば人の視線を誘導できるか、ストレス無く操作してもらえるか、というようなものである。

デザインを完成させるにはコレでは足りず、ここにフィーリング的な要素が必要になる。
ロジック的な要素をしっかり盛り込んで、ユーザーが（もしくは作り手側が）目的を果たせるようにした上で、どうやって「わくわく」させるか、「高級感」を感じてもらえるか、「おっ」と思わせて気を引けるか、をデザインするのである。

こういうフィーリング的な要素はデザインの全体感やディティールのこだわりで醸し出され、まさにアイデア勝負な部分である。 できるデザイナーは、普段からデザインについて考えており、そういうネタ（ちょっとした飾りつけとか、全体テーマとか、小物とかのアイデア）をたくさん持っている。 そういう細かい、まさにプロのあしらいが、自分のデザインとの雲泥の差を産んでいた。

僕は、ロジック的な部分はある程度カバーすることが出来るようになったが、フィーリング的な部分に関しては最後まで克服することが出来なかった。

JS絡みを頑張った

そんな感じで、デザイン業務に関してはパッとしなかったが、JSが絡むページ構築は張り切っていた。 JSができるデザイナーが他にいなかったので、そこにアイデンティティを見出して頑張っていた。

とはいっても、この頃は「JSといえはjQuery」みたいな時代で、ボタンを押すと表示が開いたり閉じたりするくらいの動きをさせる程度だった。 コードも全然プロレベルではなかったと思うが、チーム内のエンジニアは単にめんどくさかったんで僕に任せて自由にさせていたんだと思う。

自分でWEBサービスとか作っていた

この会社もそれほど残業なかったので、自分の時間を使ってWEBサービスとか作っていた。

この頃は、自分のサービスを作って一発当てて不労所得ガッポガッポな話も今よりありふれていたし、自分もそれに憧れていた。 また、会社のまわりのエンジニアがそういうこと（自分でサービスを運用する）をやっていたので、それに刺激されたというもの大きいと思う。

その頃僕はWEBスクレイピングを知って面白さにハマっていたので、アダルトアフィリエイト商材をスクレイピングしてDBにデータを蓄積し、WordPressを改造してアダルト商材アフィリエイトサイトとして運用したりしていた。

また集客施策として、TwitterAPIを使って「アダルト関連のアカウントをフォローしているアカウント」を自動的に片っ端からフォロー（相互フォロー狙い）していき、そのアカウントでアダルト商品の紹介（リンク先は自分のアフィリエイトサイト）を自動的につぶやかせたりしていた。

少しはお金が入ったりもして、なかなか楽しかった。

他にも色々個人サービス開発をやったがこれのお陰で色々体験できた。

既存サービスに改修を入れるのとは違う（それはそれで難しいシーンもあるが）ゼロからコードを組む難しさを体験できた。

運用し続ける難しさも体験できた。 開発しているときはコードの隅々まで理解してるんだけど、ちょっと放置して他のサービス開発やってると見事に全部忘れている。 たまにうまく動いてない事に気がついて修正しようとするのだが、

• コードがどこにあるか忘れている。
• 開発環境がどうなっていたか忘れている。
• サーバーへの入り方を忘れている、キーとパスを忘れている。
• サーバーがどこだったか忘れている。
• デプロイ方法忘れている。
• 構成を忘れている。
• とにかく全部忘れている。

ちょっと複雑な手順はもう二度と思い出せずロストテクノロジーとなってしまう。 運用に必要な手順などはすべて自動化するなりしてコードに落とし込んで置かないといけないことを学んだ。

何事もコツコツ進めた

サービス作りはとにかくやることが多いのでなかなか進捗してないように感じるが、毎日コツコツやることで確実に進捗し、出来たときはとても嬉しいということを体験した。 何かを運用しているという状態が楽しく、次はああしよう、こうしようと少しずつ改良していく事が楽しかった。

この頃あたりから、エンジニアとして仕事をしたいと強く思うようになった。

エンジニア入門期（駆け出しエンジニア期）

普段から「エンジニアになりたい」と吹聴しながら、JS使った簡単なフロント実装やったり、たまにちょっとしたサーバーサイドの機能改修をPHP使って開発させてもらったりしていた。

そういう普段からのアピールが効いたのか、ある新規サービスをゼロから開発する企画が立ち上がったとき「じゃあデザイナー兼、エンジニア入門でやってみるか？」と開発を担当させてもらえる事になった。 その当時上司にあたるポジションのエンジニアに指導されながらの形だった。 （今思えばよくやらせてくれたよなと思う。自分の仕事もありつつ未熟なエンジニアに新規サービス作らせるとか、負担倍増どころの話じゃない気がする。。）

僕は張り切って、デザインも含めてサービス構築を頑張った。

悩んでいたこと

無限に発生してくる問題に対処しきれない

開発していると、上司エンジニアからのレビューで「この場合どうなる？」「こういうケースあるけど対応できてる？」みたいに無限に問題箇所を指摘された。 ツッコミ一つ一つが当時の僕にとって難問で解決策がなかなか浮かばず、悩んだ分だけ進捗が遅れていく。 ただでさえ「サービスを完成させる」というゴールまでの見通しもたってなくて焦っていたところにそういうツッコミが無限に入るので、非常に追い込まれていた。

出来たと思ってもこれではダメだと突きつけられる。 指摘点を潰しても「じゃあこの場合は？」とダメ出しを食らう。 開発の進捗がとまる。。そもそもどのように対応していいのかわからない。 今までアイデンティティとして持っていた「少しプログラミングできる」という自信はゼロになり、自尊心も失われてつらい日々となった。

無駄な作業をしてしまう

コレで行けるはず、、と数日ほど実装を進めていくと「あ、、これではダメだ、、」と気がついたりする。 順調に作業が進んでいると思っていたのに、今までの作業が無駄だったと判明し、スケジュールが急に厳しくなる。

そんなことを繰り返し、精神的に追い詰められてパニックに陥ったりしていた。 作っても作っても完成に向かっている感覚を感じられなくなっていた。

頑張っていたこと

がむしゃらで、特に何を頑張ったとかはなかった。 眼の前も問題にひたすら向き合っていた感じ。 向き合ってはいたが自分の中から回答が導けなかったものも多いので、頑張り方としてはあまり効率は良くなかった気がするが、他に頑張り方がわからなかった。

業務時間だけでは足りなかったので土日も作業していたし、お盆に奥さんの実家に行ったときもお義父さんの書斎を借りてずっと作業したりしていた。 （そんなに自分の時間をさいてやって、それが突然無駄な作業であったと気がついたときの精神の落ち込みようは凄かった。）

ずっと「どうやれば完成するだろう、問題に対処できるだろう」ということを考えていた気がする。

最終的には、上司エンジニアも開発に入ってくれて、ガッと完成まで持っていった気がする。自分に余裕がまったくなかったので、どういうサポートをしてもらったのかも認識できていなかった。。

そうやってサービスはリリースまで行ったが、その後は企画自体があまりうまく行かず、サイトもしばらく開発凍結みたいな状態になって、エンジニアタスクがなくなった僕はまたデザイナータスク中心な状況に戻ることになった。 この時点でもう僕はデザイナー業務を行う気力は残っていなくて、なんとかエンジニアとして仕事を続けるために転職した。

正式に職種がエンジニアになった期（駆け出せたエンジニア期）

転職先はなんとなく「受託ではなく自社開発」にこだわって探していた。

それなりに大きなところにも挑戦したが、やはり正式なエンジニアとしての経験が足りておらず苦戦していた。 今振り返ると「新規サービスを開発した」と言っても、DB設計や、ミドルウェアの構築や、AWSでのEC2払い出しとか、全部やってもらっており自分がやってたのはコード書いてただけだった。デプロイもやってもらってた気がする。。 新規サービス開発経験を必死にアピールしていたが、たしかに一人前のエンジニアとしては程遠かったように思う。

色々受けてなんとか入れてもらえたのはWindows用の業務アプリを自社開発している会社だった。

後で知ったが、採用の基準は「プログラムが好きそうかどうか」だった（のちに自分も面接官側をやらせてもらったときに知った）。 そもそも応募が少なく優秀な人は来ない。せめてプログラムが好きであれば伸びしろがある、という理屈であった。

自分でアダルトアフィリエイトサービスを開発運用していることをアピールしていたのが活きた。

余談だが求職活動の中でアダルトサービスを運用している事をアピールしたのはなかなか有効だったように思う。 書類で印象に残るのと、面接には意外にちゃんとした人（僕はパッと見ちゃんとしてそうに見える）が来るのでギャップ効果もあってハマるところにはハマるらしい。 入社してからも話のネタとしてかなりお世話になった。 もちろん、ダメなところは全くダメだと思う。

悩んでいたこと

システム開発の流れに翻弄された

この会社では、数年前から新規開発しているWindowns業務アプリがあったのだが、これが難航していた。 僕もこの開発に参加し、割り当てられた担当分をこなしていた。

この会社でのWindowsアプリ開発はモダンなWebシステム開発と比較すると利用している技術も古いものが多かった。 痒いところに手が全く届かない状況のなかで不満もありつつ、僕は与えられた担当分の開発をコツコツ進めていた。

未熟だった僕は、与えられた担当分以外については無関心だった。 自分の範囲だけ順調に開発を進めていたが、開発全体としての進捗はあまり意識していなかった。

自分も悪かったが、僕が全体を意識しない要因としては、全体進捗に触れる機会がほとんど無かった、というのもあったと思う。 そもそも当時の僕は、システム開発がどんなふうにマネジメントされて進捗していくのか知らなかったので気にならなかった。 「担当分をしっかりやってればうまくいくんだろう」くらいに思っていた。

さらに、自分は関西で、他のメンバーは関東で開発していたので余計に意識する機会が無かった。

今思えば、システム開発に関わっているメンバー全員で情報を共有し、スケジュール通りに進んでいるか、なにか問題が起きていないかなどを確認し、問題が起きているとわかった場合にはそれを潰す解決策を検討するなど、わりと頻繁に会議が必要なはずである。 そういうのがほぼ無かった。

毎週定例会議は開催されていたが形式的な内容であまり進捗どうこうの話はなかった気がする。

この開発は以前から予定完成時期をリスケリスケで来ていたのだが、既存メンバー一人の離脱（退職）を期に改めてスケジュールに不穏な空気がながれ、社長がいい加減しびれを切らしてマネジメントに乗り出してきた。

スケジュールが改めて仕切り直され、それと同時に他メンバーの担当だった部分の大部分が僕に担当替えされた。

残ったメンバーが、新卒2,3年目という戦力だったのもあり開発の進捗が良くなく比較的開発を進捗させられていた自分に大きく振られた、という形だったのかもしれない。

そうして仕切り直されたスケジュールだが「このアプリは全部で24画面あるから来年リリースするとして、1ヶ月2画面を作れ」みたいなスケジュールだった。 このスケジュールプランに僕は悩むことになった。

1画面を完成させるには、そのアプリ全体で必要になる機能の8割程を完成させる必要があり、画面単位で分割して開発を進めるのはナンセンスであることを主張したが取り入れられなかった。（もう開発に対しての信頼がなかったのかもしれない）

そもそも、以前から開発部分の担当分けを画面単位で行っており、画面単位で開発を進めるのが文化にとして根付いていたっぽい。

以降、毎月の進捗定例（月イチで社長に報告する必要があった）で、なぜスケジュール通りに進捗していないのかを説明するあたりで悩んでストレスだった。

頑張っていたこと

どうあるべきなのかを追い求めた。

上記のようにスケジュールに苦しんでいたが、他にも色々苦しんでいた。

その中の一つは既存コードの構造である。 画面単位で担当を分けて開発を進めてきた影響だと思うが、実装の多くはViewとビジネスロジックが密結合した状態だった。 複数の画面で共通して必要な機能（例えばDBから特定のデータを取得する機能とか）が単独の機能としては存在しておらず、各画面と密結合した形でそれぞれに独自に実装されていた。 そのため、新しい画面を実装するときにこの機能が使いたくても微妙な画面構成の違いによりコードを使い回せなかった。 他にもストアドプロシージャの多用や、グローバルに存在するイベントハンドラを介したイベントドリブンな全体設計に苦戦していた。

そうやって色々悩んでいたのだが「じゃあどいういうものだったら自分は悩まずに済んだのか」に強く興味を持つようになり、DDDやクリーンアーキテクチャにのめり込み始めた。 他にもプロジェクトを失敗させない為にやるべきことは何なのか考えるようになった。 学んだアーキテクチャや開発手法は個人開発で取り入れて検証などを行い、搾取選択して自分なりの考えを固め始めた。 （以下を書いたのは最近だが、この時期から考え始めていたことである。） https://yaruki-strong-zero.hatenablog.jp/entry/development_priority

この頃は、これらの考え方について自信が無くまだ個人開発で検証していた程度だった。 しかし後々これらの考え方は実業務で実践する機会があり、それらでの実績も得て、今ではそれなりに有効な考え方であると自信を持てている。

自分で必要と思うことは行動していた

デザイナーの頃は受け身的に仕事をしていることが多かった気がするが、この頃から仕事自体をある部分は楽しみ始めて、自分から色々動くようになってきた。 根底のところでデザイン作業は好みではなく、エンジニア仕事は好きだったんだと思う。 実装を進めるに当たって仕様に不明点があれば、それを明らかにするのに自分的に最適に思える手段を提案しつつ相談などするようになった。 今までこんな動きはしていなかったと思う。

使っている技術について表面的な利用方法だけではなく、一つ深い動作原理の部分の理解に努めるようになった。 この時は開発環境はWindowsだったのだが、Windows周りの技術の理解には苦戦することが多かった。 なかなか良い感じに体系的にまとまっている情報がなかった。Microsoftのサイトでさえ、日本語訳が変だったり、リンクが切れていたり、良さげなページを見つけても続きがなかったり。。（英語で探せばあったのかもだが、この頃は日本語しか読む気がなかった。。） Windowsについての理解が進まない鬱憤をLinuxに向けたりしていた。そうして次第に「やっぱLinux上で動くものを開発したいな。。」と思うようになっていった。

そんなことをしていたら、業務上での評価はそこそこ得られていたので嬉しかった。（スケジュールの件で社長評価はイマイチだった気がするが。。）

そんな感じで頑張ってはいたが、社長がマネジメントに入ってきてからの要求スケジュールはどうやっても守ることはできないので、そうなると当然評価されないし、その状態が長く続くのは避けたいと考え転職先を探すことにした。

エンジニアの深淵に触れた期

相変わらず、なんとなく自社開発やってる会社で転職先を探した。

今回の会社選びでは以前よりも少し手応えがあった。 以前はぜんぜんだめだったけど、今回は面接もなかなか手応えがあって、最終的に2つの会社から同時に内定をもらった。 ちなみに、この時も個人開発アダルトアフィリエイトサービスに関してはアピールしており、そこそこ効果があったように思う。 アダルト抜きにしても「自分でなにか開発して運用している」っていう事をしている人は意外に少ないらしい。

どちらの会社にするか色々悩んだけど最終的には給与で決めた。

この会社で自分は課金周りのシステムを担当する事になった。 契約更新のバッチ処理が回って、更新分の請求をかける。 基本機能は上記のバッチ処理なのだが、付随した機能がてんこ盛りで全体を把握するのがかなり難しかった（というか、できなかった）。 このシステムはruby on railsで組まれていた。ここで始めてRubyに関わることになった。

また、後半は並行して新規システムの作成に関わることになった。 新規開発ではアーキテクチャから任せてくれていい経験になった。 なぜか最終的にリリースあたりの記憶が薄いのだが、なんか深夜に酷く緊張しながら切り替え作業を行った記憶あるし、このブログでも「やり切った」と書いていたのでやり切ったのだと思う。 後述するが、とにかく締め切りがシビアな重い差し込みタスクがしょっちゅう発生する職場環境だったので、常に脳に負荷がかかっており記憶が飛んだのかもしれない。

悩んでいたこと

短納期・高品質を求められるタスクが多かった

担当した請求システムはバグが存在していたりして不安定で、不定期に内外要因で請求バッチ処理が失敗していた。 失敗しても自動リカバリがないので復旧作業を行う必要があった。 失敗の原因は様々で既知のものばかりでは無いため、復旧には原因調査と復旧プラン構築が必要で、さらにこれをごく限られた時間内でやりきる必要があった。 失敗が発覚するのは請求バッチ処理が回ったタイミングであり、これを迫っている請求期限までに復旧させないといけないからだ。

そして、原因調査・復旧プラン構築以外にも以下のような重いタスクがある。

[請求金額の算出]
請求金額に修正を入れる場合にはあたりまえだが金額を間違えられないのだが、正しい請求金額の算出も難しい。 オプションがあったり、特別値引きがあったりするのだが、みな料金体系を隅々まで把握してるわけじゃないし、わかりやすい一覧表みたいなものもない。 正しい料金計算仕様は実装から読み解くしかないが、コード自体もなかなか素直に読める構造ではなくこれも難しい。 実装がバグっている可能性もあるので、これも100%信じるわけには行かない。

[復旧プランのレビュー]
金額に関わるので上長を含めて原因調査内容・復旧プランのレビューを行う必要がある。 このレビュー準備に時間がかかる。 現場レベルでは常からコンテクストが共有されているので状況は伝わりやすいが、上長や他の関係者に説明するとなると、前提知識の共有から行う必要があるのだ。 もともと期限がシビアな上にレビュー準備にも時間がかかるので、さらに作業・調査に使える時間は少なくなる。 また、上長の予定は基本埋まっているため予定を抑えるのも難しかったりする。

[復旧プランの失敗対応]
復旧プランを建て付けレビューを通して、いざ実施してもそれが失敗するパターンもままあった。 精神的に焦っているのに加えて、コード・データ構造が複雑なので実装や挙動を誤認識し、考慮できていなかったデータ状態が原因でテーブルが不整合を起こし失敗する。 そうなると、【復旧プラン構築 -> レビュー準備 -> レビュー -> 実施】のサイクルを再度まわさなければならない。

こういった割と重めの差し込みタスクが高頻度で発生していのだが、このタスクは脳を強制的フル回転・過度集中状態を強いてくる。 一時期これが常態化していた頃、もはやこの刺激がないと集中力を発揮できなくなるという症状を発症していた。 奇跡的に凪のような期間になるとなにもやる気が起きないのだ。バーンアウトだと思う。

そしてこれはあくまで差し込みタスクで通常タスクではない。 差し込みタスクを疲弊してこなした後は、残されたわずかな時間で通常タスクに取り組むことになる。 「先週は通常タスクに全く着手できなかったなぁ、、」みたいな感じが多かった。

会社の評価基準に自分の業務内容があってない

会社は新機能とか、新しい取り組みにチャレンジしたとか、そういうのをプラス評価とし、既存機能の保守作業はいくらやってもそれでプラス評価になることはない、というスタンスだった。

そして自分は（というか、自分が所属しているチームは）上記の通り、多くの時間で差し込み保守業務を行っていて、プラス評価につながるタスクに取り組める時間が少なかった。

バッチ処理が失敗したとき、放置するわけには行かないので対応に追われることになるのだが「でもこれ評価に繋がらないんだよな。。」と頭によぎって虚しくなったりしていた。（実際、こういう業務には関わらないメンバーもいた）

じゃあ僕は評価されてなかったのかと言えばそうでもなく、実際にはそれなりに評価されていたと思う。 たぶん直上の上長はそういった保守業務の難易度と重要度を理解してくれていたけど、さらに上に報告する際にそれが評価に繋がらない、ってことだったんだと思う。

だから評価用の作文をめちゃめちゃレビューしてくれて、時間をかけて練り上げていた。 ありがたい話ではあるが、ただでさえやること多くて時間ないのに、ここにも時間つかわなくてはならないのにも不満が募った。

「結局評価されてるのでいいじゃん」という考え方もあるかもだが、会社の掲げる評価基準に沿おうとすると「重い保守業務は他メンバーにまかせて自分はなるべく評価タスクをこなす」が最善手になるが、それって倫理的にどうなの？っていうジレンマがつらかったのと、保守業務が難易度高く高負荷でも、それをチームの頼れるメンバーと共に一眼となって乗り越えていっている状況をそれなりに誇っていたのに、評価につながらないとなると虚しく思えて辛かったのだと思う。

仕様がわからず、コードからも読み取れず、動かしてみることもできない

上記もしたように、差込トラブル時に必要になる詳細な仕様はシステムから読み取るしか無いが（あとは、前任者からの数点の資料や口伝があるが概要レベルで詳細な情報はない）その読み取りにずっと苦戦していた。

まず、コードリーディングによって理解するのが難しかった。

処理の流れは主にActiveRecodeのフックによって構築されていた。 処理Aによってテーブルα,βのデータが書き換えられたとき、それぞれのテーブル更新に設定されたフックで処理B,Cが動き出すのだ。

なので、処理Aと処理B,Cにぱっと見コード的な繋がりはない。 すべてのフックの登録状況と内容を把握していないと、次にどの処理が実行されるのかがわからない。 テーブル更新処理が入るたび、そこにフックが存在しないか、存在すればそれがなにか処理を実行しているか、その処理でさらにテーブル更新が入っていればそこにフックは存在しないか、、という感じなので非常につらかった。

実際、これが原因で障害復帰プランがよく失敗していた。想定していなかった思わぬ処理が動き出すのだ。

そんな感じなので、コードリーディングによって処理の流れをすべて理解し仕様を把握する、というのは難しかった。

リーディングが難しい場合、実際に動きを見て理解する、という手段があるが、これも難しかった。

このシステムはデータ、外部システムと密結合していたので、それらを正しい状態に整備しないと動かすことが出来ない。 そしてデータ・外部システムの正しい状態は、処理を理解できていないと用意できない。

例えば、バッチ処理には複数の種類の処理がある。新規請求や更新請求やキャンセルによる契約終了など。 これらはメソッドで処理が分けられてるんじゃなくて、突っ込まれるデータがどういう形なのかによって処理が分岐していた。 どういうデータだったらどの処理に入るのかを理解しないとデータを用意できない。

そして処理の一部は外部のシステムで実行されていた。 その外部システムとの連携仕様を理解していないと、正常な形で処理を動かすことができない。

そんな感じで、挙動を理解できないから動かしたい、でも動かすには挙動の理解が必要、というデッドロック状態になっていた。

そして、この複雑な状況に腰を据えてじっくりと取り組む時間的余裕もなかった。

頑張っていたこと

引き続き、どうあるべきかを追い求めて、部分的に実践もしていた。

前職同様、アーキテクチャについて引き続き考えつづけていた。

今回のシステムでイベントドリブンな構成が採用されていたが、イベントドリブンには相性があるのではないかと考えていた。 UIにおいてよくイベントドリブンな構成がとられているし、こちらは相性が良いのかもしれない。 この請求バッチ処理システムにおいては相性が良くないと思った。

一つ一つの処理がそれ単体で完結しているならイベントドリブンでもいいかもしれない。 例えばテーブルにデータが登録された際にフックでログを吐くなど。 これは「ログを吐く」で処理が完結しており、テーブルにデータを登録した処理とは直接何の関係もない。見逃されても問題ない。 しかし、フックで行われる処理も含めて一つの処理、となるとフック処理も確実に把握する必要があるのに、コード的に繋がっているように見えないのは弊害が大きいと考えるようになった。

クリーンアーキテクチャやDDDについても前職に引き続いて学んでいた。

特にレイヤーを意識する事の大事さをこの会社で身をもって体験することができた。 DBや外部システムとの結合部に注意する。依存性逆転の法則に感銘を受けた。 ここが曖昧になって密結合するとシステムがDBや外部システムに食い込んで、簡単には動かせない、ポータビリティの低いシステムになることを学んだ。

テスト駆動など、ロジックをテスタブルにすることにも心血を注いでいた。 すべては置き換えられないがせめて新規追加する部分に関してはテスタブルになることを意識して実装した。 これ以上苦しい状態にならないように気をつけていた。

評価システムや組織について考えていた

上記した、評価と業務のコンフリクトについてなぜ起こるのか、どうあればいいのか考えていた。 正しいのかどうかわからんが以下のようなことを思っていた。

評価とは、組織が行いたいことを実現させるため、社員をそちらに向かわせるための手法だと思った。 だから、会社としては新規な取り組みを行って、常に新しいことに挑戦して可能性を広げていこうとしていたのだと思う。

そこに保守業務は含まれていなかったわけだが、よく考えるとそれはそうかと思った。 経営層からは現場レベルの詳細な課題など見えないのだ。 請求バッチ処理が失敗して疲弊しながら復旧させて「今月も問題なく請求完了しました」と言っても「そらそうだろ。。」って感じだったのだろう思う。

実際はどうだったかと言えば、結果から言うと数人を専任で保守につけておかないと運用が出来ない状態だった。 しかも、起こった事象に対して早急に分析・対策・実施を行わなくてはならないので、誰でもできるというわけではない。そこそこ臨機応変さが求められるし、胆力も必要になる。これが滞ればそれなりにインパクトのある事象に発展したハズだし、実際上長からも危機感もった対応を迫られていたわけなので重要度としては高かったと僕は認識している。 そんな感じで現場レベルでは重要な業務だったが、それが経営レイヤーからは見えていなかったと考えられる。 （本当に重要でなかったなら、僕らもこんなことしたくなかったので喜んで別の業務をしていたはずである。）

じゃあ、これを上に伝えるのは誰が行うべきだったのか？ もちろん現場の僕らが声を上げるのは必要として、こういう組織設計はもう少し上のレイヤーの仕事だと僕は考えた。

保守業務の実態（システムが不安定で保守コストがかかっていることと、これが失われたときに起こりうる事）を知った上で不要であるならば、システムを切り捨てるなりなんなりしてこの工数を別のものに向けるなどすべきだったと思う。

最終的に僕はそこに不満を持ってやめたわけなので、組織運用としては失敗していたのかなと考えた。 そこまで認識した上で、それで会社を去る人は不要、と割り切っているというのも戦略としてはありえるかもと思ったが、誠実ではないなと思った。

新規のシステムを開発した。設計からやれたので今まで学んだベストプラクティスを詰め込んだ

技術面に関するリードを行うポジションで新規システムの開発に関わる機会があった。 ここまでにも書いていたような自分なりのベストプラクティス（仮説）をここぞとばかりにすべて込めてみた。 それらはすべてうまくいった。自信につながった。

そんな感じで3年ほど頑張っていたが、色々疲弊して転職活動し始めた。 何にそんなに疲弊していたのかもうあまり覚えていない。軽く絶望していた気がする。 最終出社日にも緊急対応作業を行っていたのは覚えている。。

メガベンチャーエンジニア期（現在）

今回の転職活動は大手中心に応募した。 大手であればそれなりの職場環境だろうから失敗は少ないと考えた。 年齢的にも転職は最後（むしろもうタイムリミットが過ぎている）と思っていたので失敗はできないと思っていた。

大手中心の転職活動の手応えはそこそこ良かった。 コーディング試験はパスできたし二次面接まではスムーズにいけることが多かった。技術的な質疑にもそれなりに答えられたと思う。 このあたりは、前職でおこなった新規開発の経験がかなり活きたと思う（大手を受けるときはさすがにアダルトアフィリエイトサービスの事は言及しなかった）。 しかし、内定には一歩届かず二次面接でのお祈りが数社つづいた。 やはり、エンジニアとしてのセンスもあるわけではなく経験も少ない自分が大手に入るなど不可能だったのだ、と諦めかけていたころ、あるメガベンチャーから内定がでた。なにが決めてになったのかと問うと「人柄だ」と言われた。

担当することになったシステムはJava（Spring）で組まれていた。Rubyの自由な書き方に疲弊していた僕には、それは輝いているように感じた。

さすが大手は色々と環境が整っていた。 技術面では、PaaSやk8s基盤などの社内プラットフォームが存在していたし、CI/CDやテストコードがちゃんと存在していた。 また、システムがマイクロサービス化していて、担当システムの責任範囲がコンパクトだった。 これは人員と資金があるから実現できているように思う。 前職ではコストの兼ね合いで、ほんの数人で巨大な責任範囲のシステムを担当せねばならず掌握できていなかったし、（主にバグによる発生した事象の復旧対応で）周辺環境を整えるための時間的リソースも捻出できていなかった。

組織面でとくに驚いたのが「課題をエスカレーションするとちゃんと検討され、そして課題が取り除かれる」事だった。 いままで「課題はエスカレーションしても基本取り除かれない。調査タスクなど仕事が増えるだけ」という経験を多くしてきたので本当に感動した。 やはり、大きな会社にはそうあれるだけの理由があるのだ、と思った。

こうして、僕は未経験からメガベンチャーで働くエンジニアになれた。今は社会人生活のなかで一番よい状態で働けていると思う。

まとめ

いろいろな会社を渡り歩いてきたが、最後に振り返ってどの行動が良かったのかを自画自賛で考察してみる。

まず、その時その時でそれなりに投げ出さず頑張ってた。毎朝どん底の気分で出社していた事もあったが、すぐには逃げ出さず常にどうすればこの状況を打破できるのかを考えていた。 結局はその会社では解消しなかった事も多かったが、次の会社でその経験がすごく役に立ったりもした。

そして、頑張ってもうまく行かない状況が長期で続くと、見切りをつけていた。 デザインに関しては「好きじゃないな、プログラミングの方が好きだな」と見切りをつけたし、業務上の悩みも、自己努力したり上長に掛け合っても効果が見えないなとなったら会社を変えていた。 実際のところ、悩みの少なくない部分は環境によるものだと思う。 あまり他責にしすぎても良くないが、権限もないただの社員が社内環境に与えられる影響などしれている（自分にとってはつらくても、他の人にとっては良い環境であるという可能性もある）。 それならある程度で見切りをつけて、合う環境に自分を移していくというのも悪い戦略ではないと思った。 実際、転職で正式にエンジニアになれた。転職しなければいつまでもWebデザイナーをやっていたと思う。

ダメ元でチャレンジしたのも良かった。 正直、自分がメガベンチャーの水準に達しているとは思っていなかったが、最後の転職になるだろうことから記念受験的に有名所に応募したのがこの結果に結びついた。

最後に、これが一番大きいと思っているが、僕にはエンジニア適正があった。 ロジックを考えるのが好きだった。 エンジニアに付きものである自己学習にも苦もなく取り組めている。 好きなので頑張れている。

あと、運もよかった。 以上です。