皆様こんにちは。
最近、Oasisが再結成すると聞いてウキウキしている、SPIDERPLUSエンジニアのコモドドラゴン(別名：コモドオオトカゲとも呼ばれる)です。
私の経験を軽くご説明いたしますと、
- サブコン現場監督：2年くらい
- インフラエンジニア：3年半くらい
- Webエンジニア←イマココ：5ヶ月くらい
です。（奇妙！）
そんな私が今回ブログ記事として、執筆させていただくテーマは、、、
エンジニアとして働くうえでの心の装備（心がけていること）
です。
なぜ、このようなテーマになったのか、少し背景をお話しますと、
我らがチームリーダーXから、「エンジニアとしてとてもいい動きをしているのでどういうマインドで普段の仕事をしているのかを他の人にも知ってほしい」というアツいアプローチによるものでした。大変おこがましい限りですが、もし、現場でうまくいってない方、自分のキャリアで悩んでいる方のお役に立てればと思い筆を走らせます！
私は新卒でサブコンの現場監督として入社し、その後、IT業に異業種転職しました。
未経験からのITエンジニアというのは今ほど間口が広いわけではなかったので、今思えば運が良かったと思います。
その企業は、いわゆるSES企業でしたので、3ヶ月程度の研修を経たのち、各プロジェクトに参画し、そこからはいくつかの現場でさまざまな技術をキャッチアップし、今では自分の財産となっています。
今回は大きく分けて
- SES編
- スパイダープラス編
での経験をお話したいと思います。
SES編
未経験からのIT業ということで、最初は右も左も前も後ろも何も分かりませんでした。
なので、まずは仕事を覚えることに集中（早く慣れる）し、 PDCAを軸に以下を心がけていました。
※PDCAについて詳しく知りたい方は、過去記事「みんなで回そうPDCAサイクル！」を、ご参考ください！
- 指示されたタスクは漏らさない
必ずメモを取り、時間単位でいつ何のタスクをどこまで完了させるかを自分なりに設定しました。運用業務において、決められた時間に決められたことができることを意識しました。 - プロパー、チームリーダーへのホウレンソウを確実にこなす
逐一報告することで、課題の進捗や不明点などを事前に自分で整理する時間が生まれます。また、解決に向けての方向性も話し合えたり、相談しやすい関係性の構築にも繋がります。 - 業務上進めないような不明点や課題があれば速やかに相談する
当然未経験であれば、分からないところが沢山出てきます。そんなときは自分の考えと併せて知りたいことを質問するようにしてました。大事なのは、忙しくなさそうなタイミングを見計らって声をかけること！
~~~↑↑↑↑に慣れてきたら↓↓↓↓を実践~~~ - スキマ時間にシステム構成、ミドルウェア／アプリケーションの仕様、運用業務をキャッチアップする。
多分これが一番大事です。たまたま先輩エンジニアと同じチームになった（これも運がよかった）ので、日々のサーバー運用や問い合わせ対応などは教えていただきました。時間があるときは、シェルスクリプトを一緒に眺めたり、パイプでつなげた自作コマンドを披露したりしていたのはいい思い出ですｗ
あとは、月に何回か自社に帰社し、研修時代の講師の方にシステム構成やミドルウェアの構成、リリース手順などを自分の言葉で説明し、それに対するフィードバックをもらって理解度を深めるようにしていました。
休みの日は、現場と同じ構成のWebサーバーを自宅PCの仮想マシンにそっくりそのまま構築してみて、ひとり「なるほどな！」なんて思ったりもしていました。
- 環境にこだわる
ひとつの現場にいると、業務のマンネリ化は避けられません。なので、自身のキャリアを構築するうえでどんな技術を学びたいか、どんなエンジニアになりたいかを考えます。私は現場に参画しつつ、ある程度技術をキャッチアップした段階で、次の技術を学べるように、不定期で営業や同僚のエンジニアとキャリアについて話す機会（ただの飲み会とも呼べる）を設けていました。
スパイダープラス編
スパイダープラスに入社してからも、初めのうちは前述の1~3を心がけていましたが、
そこは、やはりSaaS企業。サービスが成長していく速度はこれまで経験したことのないものでした。（どれくらい速いかというと、体力低下時のティ◯レックスが怒り状態に遷移するくらいの速さです）
このままでは、タスクがどんどん積み上がってしまうと考え、業務への取り組み方を変えることにしました。同時に、インフラ面からだけだとサービスの仕様を理解するのが難しいという問題も抱えていました。
これまでの、PDCAのような取り組み方では、一歩進むのに時間がかかってしまいます。
そこで、思いついたのが「とにかくやってみる！」ということです。
単なるP→D→C→Aではなく、DDDD→C→A→P→DDDD（いわゆるトライ＆エラー）を繰り返すことです。
このトライ＆エラー手法は、
- 期待値が予測できないような大きな課題
- スコープを分割するための情報収集
- そもそも仕様を把握しきれていない
- 大枠だけわかっているが踏み出せない
という場合に有効です。
実体験では、新システムの負荷試験をする際に、システム構成やAPI仕様などが完全には把握出来ていないところからのスタートでしたが、この手法のおかげで理解度がかなり深まり、システム構成やAPI仕様、実行時の負荷がどこにかかるのか、などを他のメンバーに説明できるくらいサービス全体を把握することができました。
D（Do）は、自分の解釈としては実行というより、経験値獲得（ハンターランク上げ）だと思っています。
肌感覚としては、Dの部分を繰り返していくうちに、だんだん仕様がわかってきて、理解度が深くなっていきます。一旦整理する時間が必要なのでC→Aを振り返りとして、再び、P→Dへ戻ります。
その他には、問い合わせ対応、アラート調査や障害対応などの緊急クエストは積極的に対応することを意識して、システム・アプリケーションのボトルネック（村に潜む危険）を察知し、解決（討伐）に向けて策（弱点が何なのか？）を巡らせました。
※常に捕獲も視野に入れています
> 問い合わせ対応、アラート調査や障害対応などの緊急クエストは積極的に対応すること
これらは、開発業務においてはメインタスクではありませんが、エンジニアとしては大変貴重な経験になります。
基本的に構築案件の場合、こういったシステム・アプリケーションが孕んでいるリスクに気づくのは難しいです。
事業としてサービスを運用している会社であるからこそ、「サービスが正常な日 🌤️」と「緊急対応に追われた日 ⛈️」に敏感になれます。
また、緊急対応をすることでエンジニアとしての判断力、課題解決能力の向上にも繋がります。（画面外から思わぬ攻撃を受けてやばい！と思った時でも絶妙なタイミングで閃◯玉を投げてくれるような人がチームにいると頼もしいですよね！）
まとめ
とにかくやってみて、分からなかったら人に聞いたり、うまくいかなければやり方を変えたり、というのを何度も繰り返してきました。
振り返ってみると、泥臭くないもっと効率の良い取り組み方があったような気もしていますが、自分自身、Webエンジニアとして新たにキャリアをスタートさせたということもあり、目標に向かって誠実であれば自ずと道は開けてくると信じています！
さいごに
スパイダープラスでは仲間を募集中です。
SaaS企業に興味がある方、建設DXのパイオニアになりたい方など大歓迎です。
ぜひ、お気軽にご連絡ください。
