failure

駆け出しエンジニア時代の失敗談

はじめに

Hello World😊東京都中野区在住の中野です😃

巷では、成功体験がたくさん出回ってますが、駆け出しエンジニアは一体業務でどんな失敗をするのか? 考えたことがない方もいると思いますが、もしかしたら何かの役に立つのでは?と思うので私の失敗談を書いていきます。

前提情報

2014年枠の新卒(技術が何もわからない状態で)エンジニアとして採用されました。

何も技術を知らない私は社内研修に参加するも何も分からず詰んでいました。 採用された理由を怖くて人事に「なんで採用されたんですか?」が聞けませんでした。 当時の人事だったEさん、もし機会があれば飲みにいきましょう。6年かけて心の準備しました。大丈夫です。

さて、私はそんな状態で入社して退職するまでに色々やらかした。 当時は沢山の方にご迷惑をおかけすることになったと思います。

さて、本当に何も知らない私はエンジニアとしてどんな失敗をしていくのか?

しくじり先生 俺みたいになるな!!

ステージ環境のデータを消したら本番で障害発生した

アプリケーションがリリースされるのには大きく3つのレイヤーを通ります。

①開発環境 開発者が自分だけの環境を作ってアプリケーションの開発及び動作確認をします。 ②ステージ環境 作ったコードが本番環境のコピーで正常に動作するかデプロイして確認します。 ③本番環境 問題ないコードはリリースされて本番環境にデプロイされます。

本番環境に何か作業するときはその前にステージ環境で同じことをやって問題ないかを確認します。 そして、私はステージ環境で不要なコードを消してデータベースのデータを消しても正常に動作することを確認しようと作業したのですが対象がステージではなく本番を向いていました。

向き先を確認しないでクエリを実行し無事死亡しました。

そのあとは作業する前にかならず実行環境の確認をするようになりました。

リリースを失敗してサービスを停止させた

担当していたサービスBはバージョン管理はgitを使っており、リリース作業自体はある程度仕組み化されていました。 しかし、仕組み化されていると言っても自動化されているわけではありません。 資料はもちろんなく、先輩に見てもらいながらSourceTreeで作業していました。

そんな中、サービスAのリリースも振られます。 サービスAのバージョン管理はgitではなくsubversionでした。 さすがにもう死語ですよね?ね?

違いはもちろんありますが、この記事では書かないので気になる方はググってください。 アプリケーションの思想の違いがあるので用語が同じでも意味が異なります。

gitでのリリースもギリギリの中に突然出てきたsubversionにより事故が起きます。 当時のリリースフローは各部から保守運用していた私に「コレをリリースしてくれ」とチケットが送られてきます。 それらを全てマージしていきますがコマンドの意味を理解しない中で、リリース準備をしていきます。 この時、叩くコマンドが間違っていたためリリース作業は失敗し本番環境で障害が発生します。

そのとき誰かが私の耳元でこう言いました。 「あーあー数百万の損失だね。」

その後、リリースフローを変更しリリース準備からリリースまで自動化しました。

先輩の開発環境(オンプレ)の.bashrcにexitを書いた

私はコードを書くところから始めた人ではなくてアプリケーションの開発ができる環境つくりに関心があり、そっちから入った人なので自然とLinuxやシェルスクリプトを見様見真似で勉強していくことになります。

徐々にシェルスクリプトの魔力に引き寄せられて行きます。 何も力を持たない人間が力を持つと何をするのか。

さっそく覚えたコマンドを使って何かおもしろいことをやろうと考えました。 そこで.bashrcの末尾にexitを追加された先輩はどんな反応をするのか。 ということが気になり気づいたときには先輩がよく使う開発環境の.bashrc全て追記してました。

「ん?入れない?んん?」 「どうかしました?」(内心爆笑) 「環境入れる?」

テッテレー(ネタバラシ)

そのあとガチギレされました。 技術を悪用するのはダメ絶対。

カスタマイズで半年以上もの時間を溶かした

私はエンジニアになってエディタには種類が複数あることを知り、メモ帳以外のエディタを使うようになりました。 その中でも特にギークな感じがしてかっこいいなと思ったのがvimでした。

vimはカスタマイズ性が高く.vimrcに設定を書けば自分独自のエディタになります。 そこで私はvimのカスタマイズに情熱を注ぎ始めます。

この情熱はとどまることを知らず、bashrcにzshrcにtmuxにとにかくカスタマイズできるならする。

そして、ある日の情熱が潰える時が来ます。 適当に作った設定ファイルたちに幾層にも重なったプラグインたち お互いが干渉しはじめ終わりは早かったです。人間の記憶力はあてにならない。 どんなオリジナリティあふれるものでも便利でもメンテナンスできなければ意味がない。

そうして私は全ての設定ファイルを削除し、IDEを購入しました。

このあと保守運用のことを考えてどうするのがベストプラクティスなのかを求め彷徨います。 リーダブルコードを読み可読性の高いコードを学び、そこからどう表現すればいいのかを試行錯誤してるうちに設計の沼に落ちていったと思います。

このしくじりは今後エンジニアを続けていく上で私の中で1つ大きな転機だったと思います。

さいごに

「そんなしくじりあるか?」って思われるものや「あるある」などたくさん失敗してきました。 今回は駆け出しだった頃にしくじった中でも特に記憶に残ってるものを書き出してみました。

胃が痛くなることも多々ありましたが、なんだかんだこの仕事は楽しいですね。

明日も私は分析して設計してコードを書いてると思います。

git

subversion

フリースペース

© 2020, yutanakano