64
21

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エンジニアになるということ。

Last updated at Posted at 2023-03-08

はじめに

3月末で今の職場を去るにあたって、この1年半余りで気づけたことを形にしたいと思いました。

技術的成長について

体感として、インターン時代と今とを比べた時、技術的な成長はあまりしていないと思っている。
理由としては、

  1. 元いたインターン先の技術力が高く、Geek 集団だったので常にフロントエンドやサーバーサイドの最先端を労せず知ることができた。
  2. リファクタリングをなるべくしない。
  3. 時間的制約がある中で、安定したコードを書く必要がある。

1 つずつ書いていく。

  • 1 について

    • これはそのままです。
    • 小学生(昭和)の頃からコーディングしていたり、MS-DOS 以前のコンピュータを使っていたエンジニアを親にもつ連中は、いわばエンジニア界の鈴木一朗だ。やっぱり、いつになっても技術が好きだし、設計の思想や美しさに強いこだわりがある。もはや宗教の領域だと思う。でも何かに強いこだわりや執着があるからこそいいものは生まれるのだろう。
  • 2 について

    • 今の会社に入社して初めて部長や他のエンジニアと意見がぶつかったのが、このリファクタリングをなるべくしないである。
    • これは当時、相当衝撃を受けた。web 系と組み込み系(うちは組み込みではないが)決定的な違いと言っても過言ではないだろう。
    • リファクタリングをしない理由は明確である。
      • すぐに修正できない。
      • デグレが発生する可能性がある。
        • 製造業や組み込みの製品というのは、webアプリのようにすぐ直せない。一度あるリリースバージョンを納品したとする。このバージョンはテストも全てクリアしていて、いくらコードがスパゲッティだろうが、汚かろうが正常に動いているという事実と実績がある。もしこのコードをリファクタリングしたら、再度膨大な量のテストを限られたリソースの中でしなければいけない(自動化した上で)。では、その工数を会社(経営サイド)が納得するだろうか? これに関しては、会社によると思うが、経営サイドにリファクタリングをするにあたっての費用対効果を明確に説明できなければGoサインは出ない。事実、リファクタリングは、今後を見据えたコード品質の向上やメンバーのエンジニア筋の増強にはなるが、すぐに日の目を見るわけではなく、表面上は、工数分の時間全く何もしていないのと同義である。さらにデグレが発生する可能性すらある。(デグレったらおわり。)
        • 経営サイドは超絶忙しい。私も忙しい。双方の忙しさの合間を縫って、上長と経営サイドにリファクタリングの必要性を力説する気にはなれなかった。(こっそりちょっとずつやった)
        • これに対して web 系は違う。「ん?バグかいな。 すぐに修正して Deploy するやで!」 で終わってしまう。
      • 扱う製品の特性によって、リファクタリングが薬となるか毒となるかが決まるような気がした。
  • 3 について

    • どの仕事にも時間的制約はある。
    • しかし、自前のサービスのリリースデッドラインが決まっている製品の納品とでは時間的制約の意味合いが違う。
    • 技術インターンの時は、2週間を1スプリントとして、全力で走り切る。という開発スタイルだった。
      • 当時を振り返ってみても、全力スプリントだったし、毎日夕方のスクラムミーティングは進捗が良くなかったりすると、脇汗がうっすら滲み出てくることはそこそこあった。
      • それでも、品質が良い(と思っている)コードが Merged されるし、スプリント内で自分が宣言したのにできないタスクは、自分よりもできるエンジニアに巻き取られたり、次回スプリントに持ち越されたりする。いわば自分との戦いだった。
      • しかし、デッドラインが決まっている製品の納品の場合は違う。残念ながら持ち越せない。次がない。よって、「コードの綺麗さが〜♪」など言ってられない状況が往々にしてある。なりふり構ってられなくなるのだ。また、チームで開発してはいるが、フロントエンドとサーバーサイドに関しては、一人だ。もう昔のように、頼りになる先輩や屈強なエンジニア筋を持つ上司、夜通し語り合った同期はいない。一人なのである。一人で乗り越えなくてはいけない。誰も詳細な部分で助けてくれる人はいない。
      • 入社2ヶ月目あたりの仕事帰り、人生で初めて、プレッシャーによって嘔吐いた。自己完結する物語なら、ここまで追い込まれることはないだろう。しかし、この物語は、営業が命懸けで取ってきた案件で、それまでに莫大な時間投入されており、バックエンドの開発やその他の開発も間に合っている中、自分の担当領域だけが未達なのだ。これによって失注すれば、何千万円単位の損失につながってしまう。次に持ち越しという選択肢は始めからないのだ。

手に入れたものは?

では、上記に述べたように、技術的成長をあまりしていないのなら、何を手に入れたのだろうか。
私は以下の3つを手に入れつつあると思っている。

  1. 見通し能力
    • タスクを細切りに分割し、散逸した問題を解決しているだけでは、身につかないと思っている。(私は身につかなかった。)
    • 幸か不幸か、要求から設計・実装まで一人だったので、ある機能追加に対して、何営業日(何h)掛かったのか?から、徐々に見積もりの精度を向上させることができた。
    • 決してギリギリにならないように計画を立てる。
    • 当たり前ではあるが、上長の物言いに、引っ掛かるか掛からないかスレスレのバッファーも追加する。
  2. 相談 & 交渉 & 提案能力
    • 認めたくはないが、私の技術力はお世辞にもレベルが高いとは言えない。
    • 認めた上で、どこで折り合いをつけるかというと、営業や上長との交渉と提案である。
      • 営業は、内部の設計や実装が綺麗かどうかなどは一切気にしない。
      • 安定して要求を満たすコードのみが、彼らの正義である。彼らの要求を満たすのが難しい時は、代替案を提示する。
        • 大体の代替案は、難なく通る。
        • もしくは、その要求が本当に正しい要求なのかまで戻り、「こっちの方がええよ!」と猛烈にアピールする。
    • 交渉 & 提案が通らない時は、それなりの時間を要求し、向こう側にも覚悟してもらう。
  3. なんとかなった経験
    • 経験というのは、思ったより大きい資産だった。
      • この経験の蓄積がエンジニアとしての自信を醸成するんだろう。
      • ベテランエンジニアがなぜ強いのか? に対する私なりの解は、これらの経験を数多繰り返しているから である。

最後に

少し大袈裟に書いた気がしますが、振り返ってみると、全て、私にとって大切な経験です。
楽しさや嬉しさ、気持ちよさを棄てて、死に物狂いになって仕事をするという経験は多分必要ないですし、ずっとこの状況はどうかと思います。
しかし、エンジニアとして飯を食うにあたっては、こういった経験をすることも、うまく言えないですが、大事だと思っています。

窮地に追い込まれた時、どう戦うか。
その時、きっと本当の私に出会える気がします。

最後まで読んでくださりありがとうございました。

(宣伝)

超最近自分の趣味のメディアを仲間と一緒に作りました!
よかったら雑に立ち寄ってくれたら嬉しいです!
https://www.wai-ware.com/

以下の記事で、私が未経験からエンジニアになるときの戦略を書いてます。
良かったら読んでください。

64
21
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
64
21

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?