何でも屋エンジニアになるというキャリア
タビアンの難波です。
タビアンはエンジニアの会社で、プロダクト作りの専門家集団です。
この記事では、自分のエンジニアとしてのキャリアを振り返ってみたいと思います。
何でも屋エンジニアとは何か
私は、自称「何でもやるエンジニア」です。
コーディングだけでなく、エンジニアリングに関わることだったら何でもやるので、何でも屋エンジニアです。
エンジニアリングが専門で、小さい頃からコードを書いていて、プログラムのことを良く理解しているのですが、仕事の範囲はプログラミングに閉じていません。
ドキュメントも書きますし、打ち合わせにも出ますし、企画もやってますし、営業もやってます。
会社を経営していますので、経営者もやってます。
フロントエンドからスタートする
私のエンジニアとしてのキャリアは、HTMLとCSSを書くフロントエンドからスタートしています。
エンジニアになる前は、BASICやVisual Basic、Delphi、C/C++などを書いていました。
HTMLとCSSを書き始めたのは、シンプルな理由でした。
VBで作るWindowsアプリケーションよりも、（見た目が）カッコいい画面を作ることができる———
そんな単純な動機からフロントエンド・エンジニアの道に入りました。
その後、サーバーサイドに降りてきて、PHPやVB.NET / C#.NET、Java、Node.jsを経験しています。
サーバーサイドはだいぶやりこみました。
下のレイヤーに降りる
作ったプログラムを動かすために、Linux（BSDから入ってCentOSに行った）が動作するサーバーをメンテするようになって、Windows Serverも運用したりしました。
そのままインフラまで降りていって、VMwareの上で動作するサーバーを構築したり、データセンターに行ってガンガンに冷えた部屋の中でサーバーをメンテナンスしたり、ミドルウェアを構築したりしてきました。
ITシステムは、フロントエンド、サーバーサイド、インフラ、という階層構造に例えて表現されます。フロントエンドは一番上の層、サーバーサイドは真ん中の層、インフラは下の層です（その下には、物理という、家に例えるところの土台にあたる層があります）。
この階層の考え方は、上の層は下の層を知らなくても動くように設計するという、ITの基本的な考え方に基づいています。上の層だから偉いとか、下の層だから卑しいとか、そんなことはありません。
慣例的に、上の層から下の層に移動することを降りると表現します。「レイヤー」とは、層のことです。
AWSが普及してからは、AWS上にフルサイズの基盤を作ったり、CloudFormationで全部書き直したり、ガチガチのAWSエンジニアをやっていました。
AWSはどちらかというとIaC（Infrastructure as Code）の考え方に親和性が高いので、フロントエンドやサーバーサイドを専門にしてきたエンジニアさんでも、馴染みやすいインフラです。
最近はすっかり物理層に関わることが少なくなってきましたが、サーバーのサイジングをして調達し、ラッキングやキッティングをすることもあります。
サーバーラックを設置するときは、電源容量を計算してUPS（無停電電源装置）を選定したり、ラック内で取り回すネットワークケーブルの長さを見積もったり、周辺機器をセットアップするのはおもしろいです。
この前の案件では、ケーブルを選んでスイッチングハブを選んで、競技施設にネットワークを敷設するお仕事をしました。
コードを書いた後のプロセスに興味を持つ
ソースコードを書いて、無事にサービスがリリースされると、運用が始まります。
サービスの運用が始まると、遅かれ早かれシステム障害に遭遇することになります。
障害対応で向き合うことになるのが、システムから吐かれる大量のログです。
システム障害に何度も向き合ううちに、ログから障害ポイントを見つけ出す力が鍛えられました。
また、障害対応がしやすくなるようなログの書式・内容が分かるようになったり、障害・バグに繋がりやすいアルゴリズムやアーキテクチャーのNGポイントが分かるようになったり、障害が発生したときに切り分けしやすいソースコードのモジュール設計について考えるようになったりしました。
リリースしたサービスが、実際に使われているのかどうか、利用者が伸びているのかどうか、目の当たりにすることができるのが、システム監視です。
実際に使われているのかどうか
システムは、使われることで役に立ちます。
人に使ってもらうことを想定するWebサービスの場合、人に使ってもらわないと存在意義が失われます。
システムの状態を、グラフなどで可視化するメトリクスでは、サーバーや関連機器が、処理を捌ききれるのか、故障していないのか、システムの状態を数値化して監視します。
それだけでなく、サービスが当初予定していた使われ方をしているのか、使ってくれる人が増えていくのか、システム面以外の情報もメトリクスで可視化することができます。
Google Analyticsなどのアクセス解析ツールを用いて、ユーザーがサービスをどのように使っているのか、動向を分析して対策を考えていく仕事は、本来はWebマーケティングの領域です。
とはいえ、アクセス解析だけでは取りきれない情報もあります。
ソースコードを書くエンジニアだからこそ、システム内で精緻な情報を出力・蓄積できるように作りこんで、マーケティングの専門家と連携することもできます。
コードを書き始める前のプロセスに興味を持つ
タビアンでは、プロダクト作りに関わるお仕事に携わっています。
プロダクト
ここで言うプロダクトとは、スタートアップや事業会社が自社で開発・提供するITサービスのことです。
多くの場合、サービスのユーザーとして自社や関係会社ではない人たちを想定します。
プロダクトを作るプロセスでは、プログラムを書く「開発」に入る前に、頭を使って考える要素がたくさんあります。
プロダクトのコンセプトを詰めたり、解決するペイン（痛み）をシャープにしたり、ユーザーのペルソナ（具体的な人物像）を定めたり、MVPにするプロダクトの範囲を議論したり。
ビジネスモデルを一緒に考えたり、マーケットへのアプローチ方法を練ったりすることもします。
開発するべきプロダクトの形が決まった後でも、コードを書き始める前に取り組まないといけない課題があります。
プロダクト作りを進める組織体を作ったり、稟議を上げて開発が始められるように調整したり、開発するエンジニアにお金が払えるように予算を取ったり。
ソースコードを書き始めてしまうと、後戻りができなくなってしまいます。
開発しようとしているプロダクトが、ずっと動き続ける＆現役で活躍し続けられるようにするためには、スタート地点を間違えないようにすることが大切だと思います。
プロダクト作りを始める最初期からディープに関わることで、プロダクトを作る！とコミットしている人たちが、良く知られた落とし穴に陥らないように、0→1のプロダクト作りの専門家としてサポートしていく…。
それが、私たちのミッションだと考えています。
フルスタックエンジニアと違うのか
エンジニアの世界では、フロントエンドとサーバーサイドの両方を経験して、単身でシステムを構築することができる技術を身につけた人のことを「フルスタックエンジニア」と呼称します。
どこからどこまでできたら「フルスタック」なのかは、厳密な定義がありません。
インターネットを散策すると、いろんな論旨で述べられている記事が見つかります。
フルスタックを論ずる時には、「フルスタックなエンジニアは何ができるのか」という、技術や経験を取り上げているように見えます。
何でも屋エンジニアの方向性は、より広い領域に取り組んでいこうとする、エンジニアのスタンスを表現していると考えています。
エンジニアは技術を好きであるべきか
ついこの間まで、自分のことを技術が好きなエンジニアだと思っていました。
タビアン取締役の東出と、よもやま話をしていたとき、「なんちゃんは、実は、三度の飯より技術が好き、って人じゃないんじゃないか」と指摘されました。
社内では、なんちゃんと呼ばれています。
競技プログラミングの問題を毎日解くことを習慣にして、GitHubコントリビューションに草生やすことを1年間継続して、毎年新しい言語を習得して、OSSにコミットして、コントリビューターとして名前が出る。
私が尊敬するつよつよのエンジニアさんは、技術の研鑽を重ねて、よりディープなエンジニアリングの世界を極めるための活動をされているように思います。
競技プログラミング
与えられる課題を、プログラムを書くことで解く競技のこと。オンライン上で簡単に挑戦できるようになっていて、エンジニアの間で普及しています。
GitHubコントリビューションに草生やす
GitHub（インターネット上のソースコードが集まっているサービス）に自分のアカウントを作成すると、365個の□が表示されて、ソースコードを書いた日の□は緑色で塗りつぶされます。緑色に塗りつぶされた□が増えてくると、草が生えてきたように見えるので、毎日ソースコードを書いて緑色の□を増やすことを「草生やす」と表現するようになりました。
OSSにコミットして、コントリビューターとして名前が出る
【OSS】オープン・ソース・ソフトウェア。OSSは、有志がソースコードを持ち寄る「集合知」で作られ、運用されています。
【コミット】ソースコードを書いて他のエンジニアさんたちに公開すること。
【コントリビューター】ソースコードを書くなどしてOSSに貢献し、運用するコアメンバーに認められた人。エンジニア界では絶大な影響力を持つ称号です。
一方で、自分はこのような活動をしたことがありませんし、ぶっちゃけこういった習慣化にあまり興味がないタイプのエンジニアさんだと思います。
技術にコミットして、技術を極めるエンジニアに、すごく憧れる気持ちはあります。
でも、自分の興味は、もっとできることを広げていきたい、という方向に向かっているようなのです。
技術を楽しみたい
エンジニアのキャリアとしては、私は、何でも屋エンジニアという方向性を目指すことになりました。
とはいえ、小さい頃から親しんできた技術は、興味を尽きさせることなく、いつでも楽しませてくれます。
技術は日進月歩で進歩するので、先を見通すためには、いつでも「巨人の肩の上に立つ」ことが求められます。
何でも屋エンジニアとして、興味の赴くままにエンジニアリングを広げながら、技術を学び続けていきたいと思います。
この記事が気に入ったらサポートをしてみませんか？