この記事について

これまで学生時代のアルバイトを含めると10年以上のエンジニアキャリアを経験しました。ここでこれまで当たった各種壁や困難について振り返ってみようと思います。

文字コード

まず最初に当たったのが文字コードでした。shift-jisだとか、utf-8だとかそんなものを意識することはほとんどなかったので、文字化けに何度も苦しみました。素人時代は当初はとりあえずネットで検索して文字化けしたらこの設定せよなどして回避していたものの、実際に仕事でプログラミングを書いているときに本当に文字コードの仕様と向き合わないといけないときに直面しました。

内容としてはシンプルで、もともとのシステムがutf-8で書かれているのに、あろうことかshift-jisで拡張ライブラリを作っていました。運も悪くどちらのコードにも日本語のコメントなども一切ないので文字化けも起きず、ただ単に何度デバッグしても動かない。処理は正しいのになんでだろうという悪戦苦闘に見舞われました。当時学生で半分フリーランスで活動していたため助けてくれる先輩も上司もいなく、納期が間に合わないかもという責任に対する恐怖を初めて体験した経験でした。

ちなみに、結局、そこの部分の開発をいったん保留にして、ほかのモジュール開発に着手していたところ、ふと文字コードの設定に気づいてutf-8にしたら動くようになり無事納期にも間に合いました。しかし当時の恐怖を今でも覚えており、強い印象に残る経験でした。

今は基本UTF-8で統一するようにしているのでまず文字コードで苦しむことはないのですが、今でもcsvの取り扱いでSHIFT-JIS変換で苦しんだり、古いシステム故にeuc-jpで保存されているシステムがあったりすると、たまに変換処理に苦しむことがあります。

セキュリティ

文字コードとほぼ同じ時期に、プロとしての責任を追及される経験をさせれたのがセキュリティでした。同じく学生の頃の経験です。当時とあるECサイトの開発に携わっていたのですが、ふと一緒に働いていたメンバーに「ところで、セキュリティ大丈夫ですか？万が一バグを悪用されたらかなりまずいと思いますが...」と言われたのがきっかけでした。当時はとにかく動くものを作ればよいと思っておりXSSやCSRFなにそれ？という状態でした。プロとしての甘い考えを突かれた言葉でした。この言葉をきっかけに、納期を間に合わせるためにセキュリティ対策を猛勉強したり、万が一の保険として弁護士に責任範囲の相談したりとありとあらゆる手を尽くしました。その中で出会ったのが以下の徳丸先生の「体系的に学ぶ 安全なWebアプリケーションの作り方」で社会人になったあともしばらくセキュリティで困ったときはこの本を頼りにしていました。

ちなみにソフトウェアのセキュリティももちろんですが、コンプライアンスとしてのセキュリティでも痛い目にあったことがあります。同じく学生時代、とあるHPの開発受注をしていたときに無邪気にDropBoxで納品したところ、発注元のセキュリティコンプライアンス違反をしてしまったとしてとても怒られました。結局この仕事を最後に私への仕事の発注を打ち切られてしまったのでセキュリティやコンプライアンスの大切さを痛感する出来事でした。今でこそコンプライアンスの研修をしっかりやっていない人ならついやってしまうミスであり、ShadowITなど社会問題として騒がれていない時代だったから経験できたことでもありますが、当時の考え方の甘さは今振り返っても猛省するばかりです。

上記のような甘さは経験を通じてだいぶ緩和されたものの、セキュリティについては就職して本当の意味でのプロエンジニアになった後も、壁として何度も立ちふさがってきました。一方で皮肉にも、自然とISMSやOSSのライセンス管理など、守り領域の業務を主に扱うようにもなりました。おそらく法学部出身というバックグラウンドだけでなく、こうした学生時代の数々のセキュリティに関する痛い目を人よりも先行して受けて身に染みていることが影響しているではないかと思っています。

LinuxOS

もともとはMacさえも持たずWindows１本だった私にとっては、サーバサイドシステムの開発運用のためにLinuxOSを使いこなすというのも一つの壁でした。基本的なUnixコマンドこそ自然と覚えられたものの、用途に合わせてチューニングする際に、各種設定ファイルやプログラム本体がどこにあって、どこをチューニングしないといけないのか探すことが毎回毎回大変でした。

学生時代は専用サーバを持たず、VirtualBoxを使った仮想環境は重くてつらいということで、WindowsPCをデュアルブートにしてLinuxOSの勉強をしていたのですが、あるとき寝ぼけてLinuxOSで作業ながらWindowsのシステムファイルを削除してしまい、WindowsOSを起動させなくしてしまったことがありました。当時はまだWindows7時代で手軽にWindowsを再インストールすることもできず、お金もないので、しばらくLinuxOSを主として作業させられました。当時、ちょうど大学4年生で卒業論文を書いているときで、LinuxのLibreOfficeのDocumentで仕方がなく法学の卒業論文を書くという経験も今となっては懐かしい思い出です。

エラーハンドリング・テスト

ここからは、会社に入社し社会人になり、本当の意味でプロのエンジニアになってからの話です。最初に覚えたのはコード書く際のエラーハンドリングやテストでした。同期たちはこの２つで苦しんでいる方もおおかったのですが、自分自身は意外と抵抗なく習慣化しました。おそらく、学生時代に幾度となく苦い経験しているので、その経験があるからむしろ安全に開発、運用するための正しいプロセスや対策を知れたというところが大きかったからかなと思います。

本番機の操作・システム移行

一方本番サーバの操作やシステム移行は、私にとっては大きな壁でした。これまで単純にコードを納品するだけで運用がなかったり、運用も担当していてもメンテナンスによる停止OKのリスクの低いシステム運用ばっかりだったためでした。勤め先のWebシステムは原則24時間稼働なのでシステム停止させずにシステム移行作業を行わなければなりませんでした。

もともとかなり不器用なほうなので、IPを指定し間違えたりなど操作ミスがとても多く、しばらく先輩や上司のサポートをもらわないと作業できませんでした。今でもシステム移行系は苦手で、試験環境でシステム移行の練習を何度もしたり、（一般的には移行テストというのでしょうが、私にとってはもはやテストというよりは作業練習です）、手順書を事前に作成して誰かにダブルチェックもらったりしているほどです。CI/CDの潮流で自動化できるところも増えてだいぶ楽になりましたが、初めて自動デプロイを走らせるときなど、やはりシステム移行はいつも緊張が走ります。

メモリ管理

C言語も学んではいたものの、昔は実務、実践的なものはPHPやJavaScriptばかりで、基本的な処理ばかり作っていたためやメモリ管理なんて気にしませんでした。ただ、そのうち大規模なシステムを扱うようになるほど、オブジェクト指向ベースでDependncyInjectionなどの概念を使うようになり、参照渡しなどを意識してメモリやポインタを意識するようになりました。

さらに、長期的にアプリケーションを稼働させないといけないJavaやNode.jsを触るようにると、変数やオブジェクトのリセット忘れによるメモリリークなどの問題にも直面するようになりました。メモリ管理がへたくそだったときは定期的にプロセスを再起動させるという無茶なアーキテクトを組んだりしたこともありました。

ソフトウェアアーキテクト

ソフトウェアアーキテクトも自分のエンジニアキャリアにおいて立ちふさがることがしばしばありました。MVCとかシンプルなものならいいのですが、ドメイン駆動の厳格なアーキテクトをベースに、各種トリッキーなデザインパターンも組み合わさりしてあるシステムに出くわすときが問題です。これらはスパゲッティではないもののある種の芸術作品であり、コードが複雑すぎて一目でどうやって動いているのかわからないというものであることも多々ありました。

急遽助っ人して入ったシステムについてこれらの問題出くわすと、ちょっとした改修でいいと思っていたら、全体アーキテクトや設計思想をしっかり学習する必要がでてくるためとても苦労しました。

経験を積んでだんだんパターンを知ってこの手のコードに対する勘所もでてきましたが、新しいシステムを触るときはやはり、思わぬ地雷にあたらないか緊張します。

一方で反面教師として、自分が作るソフトウェアアーキテクト、システムアーキテクトは派手なことをせず、ちょっとの学習があれば開発と運用ができるように低コストでいこうということは日々心掛けるようにしています。

負荷分散

Webサービスの宿命ですが、負荷分散も戦いとなったことがしばしばありました。セキュリティとからんである程度知名度のあるサービスだとやはりいたずらが多かったり、一時的にSNS拡散がおきてスパイクが発生するときもあります。経費の問題もあるので無邪気にサーバ増設しましょうというだけでなく、ミドルウェアやフレームワークの選定、キャッシュの利用を意識することも必要であったりします。面白い領域である一方で、うっかり計算間違うと痛い目にあう領域のため設計段階でもこのあたりは緊張することが多いです。

サービス貢献・コミュニケーション

最後にWeb企業に就職して改めて感じたことですが、Webサービス企業に入ると単純にPJに入って作れと言われたシステムを作っただけでは、そのPJや組織において本当の意味での評価はもらえません。せっかく期日通りにリリースしても、当該サービスが不発に終わると十分な評価がもらえないからです。

そのために、エンジニア領域にとどまらず、ビジネス的なところでも各種提案をしていかないといけません。もちろん、サービスの成功という観点でエンジニア的なアプローチを変更しないといけないときもあります。例えば、実証実験的なサービスであるならば、プロダクトオーナーとしっかり話し合い、単純にオーダーされたものを開発するだけでなく、時には削ったほうが工数が下がり、企画のピボットがしやすいですよといった提案もしていかないと本当の意味での成功は得られません。

これがどうしても嫌となると、純粋なSierやフリーランスなどで純粋な開発受託に専念せざる負えなくなります。一長一短あるのでどちらが働き方として正解ともいえませんが、Webサービス全般に携わりたいという方でしたらやはりエンジニア職にとどまった活躍にこだわることは正解とは言えないと思います。

終わりに

以上です。現在の勤め先からはややエンジニアという立場から離れてしまいましたが、副業などでは引き続き開発しているので、これからも様々な壁に当たると思います。今後も話せる範囲で印象に残る出来事があれば記事にしてみようと思います。

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

Photo by: Nicole De Khors on burst