駆け出しWEBエンジニア（新人WEBエンジニア）の失敗談 - エンジニアアンチパターンNEXT

技術書典7で頒布した「エンジニアアンチパターンNEXT」は、私自身の失敗談から教訓を得るという同人誌です。

konosumi.booth.pm

新人のWEBエンジニアとしてキャリアをスタートした入社1年目から始まり、プロジェクトマネージャーとして炎上プロジェクトを経験するにいたるまで、主要な失敗という名の黒歴史を収録しました。

（↑ @kz_sueさんに描いていただいた裏表紙の4コマ）

Twitterでたまに反応を見る限り、失敗に対して共感してくれる方が、意外にも多かったです。 せっかくなので、その中から駆け出しWEBエンジニア（新人WEBエンジニア）としてキャリアをスタートした頃の失敗をピックアップして、ブログでも共有してみることにしました。

学生時代（WEBエンジニアになる前）

大学は情報工学科でしたが、アルバイトとゲームセンターに明け暮れていたため、真面目な学生ではありませんでした。 授業の記憶はあまり残っていないのですが、就職はしたかったので、資格だけは自分なりに勉強して取得しました。

• 大学1年：初級システムアドミニストレータ（現：ITパスポート）
• 大学2年：基本情報技術者
• 大学3年：ソフトウェア開発技術者（現：応用情報技術者）

「ソフトウェア開発技術者」の取得は、とくに就活で有利に働いたようで、就職先は比較的すんなり決まりました。 アルゴリズムをはじめとする、情報工学の基礎を学習できたのも良かったです。

ちなみに基本情報技術者は言語問題もあるため、学習過程で情報工学に加えて、プログラミング言語も学べる良い資格です。 スラムダンクの赤木が花道に語った「基本がそれほど大事かわからんのか！！」というセリフ程ではないにせよ、この段階で基本を勉強していたのは良かったと、今でも思います。

WEBエンジニア1年目

SIerの会社に入社しましたが、基本的な研修を終えて少し経ったある日から、とあるWEB系企業へ常駐することになりました。

配属先の企業がWEB系だったため、ここから駆け出しWEBエンジニアとして、キャリアをスタートすることになります。

前段：プログラミング言語の学習

WEBシステムの開発言語はPerlだったため、常駐先では始めに、オライリーの「プログラミングPerl（通称：ラクダ本）」を手渡されました。

Perlの学習に与えられた期間は約2週間でしたが、プログラミングPerlはVOLUME1とVOLUME2があり、VOLUME1だけでも700ページあります。 ひたすら読書を進めた結果、厚い技術書を読む耐性こそ取得できましたが、読破はかなり大変でした。

辞書のような厚さの本を読んでいると眠くなってくるので、実際にプログラムを書いて実行しながら、頑張って読み進めました。

なお私自身が新人エンジニアだったことも相まって、初歩的すぎる質問で怒られるのが怖く、基本的には黙々と読みました。 今思えば、もっとたくさん質問していれば良かったです。

ちなみにラクダ本は、Perlの開発者自身が執筆していることもあり、良書であることは間違いありません。 ただしラクダ本の第3版は2002年なので、Perlのバージョンアップによる新機能を網羅できていない弱点があります。

プログラミングPerl〈VOLUME1〉

プログラミングPerl〈VOLUME2〉

1年目の失敗談（プログラミング）：プログラムのパフォーマンスが悪すぎて、異常終了してしまう

仕事で最初に開発したのは、CSV形式の商品データを一括生成するバッチプログラムでした。 どうにか指示された期間内に開発は終えたのですが、結果は散々でした。

• 開発環境では動いたが、本番環境ではメモリオーバーでプログラムが異常終了する
  • （開発環境と本番環境の商品数の差により、開発環境ではメモリオーバーが起きず、リリースされるまで気づかなかった）
• どこかでメモリリークが発生しているらしく、メモリ消費量がどんどん増えていく
• プログラムが遅すぎて、いつまで経ってもCSVの生成が終わらない
  • （開発環境は商品数が少なかったこともあり、そこまで遅さを実感していなかった）
• 商品名にカンマがあると、CSVのフォーマットが壊れる
• ...etc

この件でとくに学んだのは、非機能要件の重要さです。 要件を満たしたプログラムを開発するのはエンジニアとして前提条件であり、その上で適切なパフォーマンスやセキュリティを発揮するプログラムの開発を目指すのが、WEBエンジニアとして大切なことであると学びました。

他にもメモリリークを調査する過程で、Perlのリファレンスカウント方式まで足を伸ばして、言語を学べたのは良かったです。

1年目の失敗談（データベース）：スレーブDBのレプリケーションが異常停止する

商品ページのコントローラーにとある機能を追加したところ、SQLの発行過多でスレーブDBのレプリケーションが過度に遅延してしまい、最終的に異常停止しました。 SQL自体はわりと単純な文だったのですが、検索ボットも含めて、すべてのユーザーアクセスにおいてUPDATEのSQLを発行してしまったのがダメでした。

最初に経験した「パフォーマンスの悪いプログラム」は、プログラム単体の問題であり、影響範囲は狭かったです。 一方で今回のデータベーストラブルは、WEBシステム全体に波及します。

稼働サービスのデータベースを壊してしまったという罪悪感で顔面蒼白になりましたが、常駐先のエンジニアさんの協力もあり、どうにかデータベース自体は復旧することができました。

この件で学んだのは、WEBシステムにおけるデータベースの重要性です。 基本的なSQL操作はもちろんのこと、テーブル設計やインデックスなど、データベースには知っておくべきことが色々あります。 その他にもDBのダンプデータを取得して、そのデータからMySQL（またはPostgreSQLなど）を復旧させてみるといったフローも、実際にやると勉強になります。

参照系（SELECT）が9割と言われことさえあるWEBシステムのデータベースの世界において、更新系（UPDATE）のSQLは負荷分散も難しく、コストの高い処理であると学んだ瞬間でした。

WEBエンジニア2年目

駆け出しWEBエンジニアとして2年目は、引き続きPerlのWEBシステムを開発していました。

2年目の失敗談（サーバー）：Linuxコマンドのタイプミスで、サーバー設定が消失する

開発したPerlのバッチスクリプトを、定期的に動かす必要があったため、Linuxのcrontabに設定を追加することにしました。 その際に「crontab -e(eはedit)」を、「crontab -r(rはremove)」とタイプミスしてしまったため、crontabの設定がすべて消えました。

手元に変更前の設定があれば復旧もできるのですが、crontabのバックアップすら取得せず作業してしまったため、元の設定を復元することすらできなくなってしまいました。 入社1年目に、自ら招いたデータベーストラブルで顔面蒼白を経験した私ですが、このときも同じく自分の失敗によってトラブルを経験することになります。

この件で学んだのは、事前に用意された手順書や、しっかりバックアップを取得することの大切さです。 今回のトラブルは、Linuxコマンドのタイプミスによって起こりました。

いわゆるヒューマンエラーであり、eとrはキーボードで隣同士という罠にも起因します。 これらは設定の自動化や事前の手順書作成により、コマンドの手打ちを抑制し、リスクを軽減できます。

またサーバーの設定を変更する際は、変更を実施する前に、設定のバックアップを取得（保存）しておくことが望ましいです。 その他にもcrontabであれば、プログラムとあわせてGitに保存してことも有効です。

さいごに

駆け出しWEBエンジニア（新人のWEBエンジニア）としてキャリアをスタートした1年目と2年目は、プログラミング・データベース・サーバー（Linux）と、すべてにおいて失敗を経験しました。

手痛い経験ばかりだったのですが、データベースやサーバー（Linux）管理の重要性を知るきっかけとしては、良い契機だったのかもしれません。

konosumi.booth.pm