Posted by この記事は GRIPHONE Advent Calendar 2019 11日目の記事です。
こんにちは、サーバーサイドを担当させていただいている皆田です。
まだまだ『担当している』というにはおこがましいスキルしか持ち合わせていないのですが、フロントエンドからサーバーサイドに転向してみたときに、やってみたこと、困ったことなどを中心にお話させていただこうと思います。
はじめに
ひとことに「転向、キャリアチェンジ」と言っても様々なケースがあると思います。
この記事をお読みの方の認識を合わせるため、少し単語の説明をしておきたいと思います。
フロントエンドと逆の言葉ではバックエンドという方がしっくりくるでしょう。
そしてバックエンドを厳密に分けると、サーバーサイドとインフラに領域を分けることができます。
まずはここでいう「フロントエンドとバックエンドの定義」を簡単にご説明します。
フロントエンドとバックエンドの違い
フロントエンド、バックエンドは同じエンジニアではありますが、決定的な違いは業務分野の違いにより、使用する言語が異なるところではないでしょうか。
上図のような感じで私が担当していたフロントエンドはひと昔前のWebブラウザ（クライアント）に向けて目に見える部分を作る人とイメージしていただいて良いかと思います。
対してバックエンドはクライアントの目には見えない部分を作る人とイメージしていただければ良いかと思います。
サーバーサイドの領域
バックエンドの中でも、 データベース構築やシステムの動作の部分を担保する領域をサーバーサイドと呼んでいます。
インフラエンジニアの話まで及んでしまうと本記事から逸脱してしまうのでこの辺にさせていただきますね。
フロントエンドでやってきたこと
ツールは SublimeText を使う人が多い印象です。
私は netbeans を愛用しておりました。Git の履歴を見るのにかなり便利な機能があったため、その機能に依存していたところが大きいです。
作業的には、Sass/Compass と HTML（Smarty）を主にいじっており、たまに JavaScript を編集することがあったでしょうか。サービスとしてもガラケーとスマホに対応するため、HTMLを使い分ける知識なども必要となっていました。
今年7月からサーバーサイドとしての業務を開始することになりました。
以前のプロジェクトでも PHP を使用しており、このとき PHP7 に書き換えられた経緯もあったのですが、当時コードレビューで普段からPHPも読んでいたので、楽観的に読めばわかるんじゃないかと思っていたところもありました。
サーバーサイドにチャレンジ！
7月～8月はユーザー様からのお問い合わせに対しての調査を行いました。
これはアプリの内容、データベースの構造を知るためにも効果的でした。
DataDog でログを見たり、Athena で調査してみたり。
実装されいてる管理画面を見て、使い勝手を知る意味でもやってみて良かったと思います。
9月からはデバッグメニューや管理画面の中身を改修する作業に入りました。
その前にやっていた調査系タスクからこうした方が良いとか、こういうものがあるというのは分かっていましたし、改修内容としてWebフロントに近いところを触らせてもらっていたので、中身を理解しながら作業は比較的慣れのある部分だったのでストレスは少なかったです。
困ったのは、PHP 側のコードで PHP5 にはない PHP7 特有の記述（型指定など）とオブジェクト指向プログラミングであること、ツール操作の不慣れなところでした。
これらでつまづいたことで、サーバーサイド作業の習得を効率化するにはもっと手を動かさなければならないと痛感しました。
記事執筆現在は新規イベントの開発を担当させていただいて業務を進めています。
そして、習得へ
「そんな簡単に習得できたら苦労しないよね」と思う人は大多数だと思います。実際、私も簡単だとは思っていません。
エンジニアとしての生き残りを考えると習得して損になるモノなんて何一つありません。
というわけで、施策を担当するにあたりこんなことが効果的だと感じました。
- コードリーディング（Github 上でレビューしてみる）
- ツール習得（IntelliJ を使ってみる）
- ペアプログラミング
これらに加えて読書も進められているのですが、まだできていないです。
別途、PHP7 初級試験 を受けようと勉強しているので、その辺の話は別途させていただこうと思います。
コードリーディング
実際やってみると同じ PHP7 とはいえ、記法も前プロジェクトで見ていたものとは全く異なり、「オブジェクト指向」の要素が強く、PHP5 時代のソースに比べると SQL の秘匿性も強く、感覚的に理解が難しいものでした。
GitHub でコードレビューしながら、質問したりして理解を深めました。
前述した管理画面担当時も GitHub 上で突っ込みをいただいて理解度が上がったということもあります。
ツール習得
IntelliJ という有償ツールを使えるということで、それまで無料ツールを渡り歩いていたので、使いこなせればかなり良いのでは？とワクワクしながらインストールしてみました。
ツールの変更による「できること」の増大がこんなにも苦労することになるとはこのとき思いもしませんでした。
これまでは IDE を使っていたとはいえ、フロントエンドに特化した使い方をしていたため、「どんなことがしたい」という操作が異なっていて、「こういう使い方がある」を想像するのも大変でした。
少しずつではありますが、チートシートを参考にショートカットから覚えていってます。Windows と mac とでも感覚的に異なるので mac ユーザーからアドバイスを受けようにも「これ Windows なので、ちょっとやり方がわからない」という話をされることもありました。
この IntelliJ の習得は現在必須事項なので、鋭意使い倒せる準備中です。
エディタ以外のツールの話としては GCP の利用経験はありましたが、 AWS の利用経験がなく、AWS でのツール名の呼び方、どんな使い方ができるかというところも覚えなければなりませんでした。
これも実際使い方を聞いてやってみるに限ります。
他には、アクセスログ、アプリログ、SQLログなど、サーバーサイドならではの目には見えないところでどんなエラーが起きているかを追跡するための手段を覚える必要もあります。
ここら辺に関してはフロントエンド時にもCUIでログ出しながら作業していたりもあったので、「見ること」に関してはあまり苦労しませんでした。
ペアプログラミング
コードリーディングだけで短時間で システム毎に特有の ソースを素早く理解するのはとても厳しいものがありました。
そこでペアプログラミングの出番です。
プロジェクトを理解している人にナビゲータになっていただき、覚える側がドライバになる方法が効果的だったと感じます。
ある程度同レベルのメンバー同士であればどちらがドライバになるかは相談の余地があるかもしれませんが、知識がない人間がナビゲータになれるはずもないので、手を動かすドライバに専念する方が良いと思います。
プロジェクト内の暗黙のルールを知ることもできますし、ちょっとした疑問で最初は牛歩になってしまいますが、勿体ない妙な躓きは早期解決することが可能です。
ペアプログラミングを終えて、実作業してみても同じように躓くことは多々あります。
しかし、このペアプログラミングしたときの手を止めたタイミングで考えたことを思い出し、要件と方法を確認することで、身についてきていることを実感できます。
ペアプログラミングによって、自分では使ってなかったツールの使い方も知ることができるため、前述した IntelliJ の使い方という面でも近道ができました。
考え方は人それぞれなので、可能ならいろんな人とペアプログラミングしてみるのはスキルの幅を広げるのに一役買いそうだなと感じました。
効率的なステップアップ方法
キャリアチェンジする上で最も重要なのは、何でも聞いちゃう！ということ です。考えなしに質問するのは意味のないことなのですが、経験則で理解した気になって誤った方向に進んでしまうことが最も工数をロスします。
「知らなくて当然」なので、知ったかぶりをしないことが一番です。
これは異業種に転職する際のコツでもありますね。
また、プロジェクトそれぞれに特有のルールがあると思います。
それら特有のルールを否定的にとらえず、まずはやってみる。
やってみた上で自分のやり方を探していくというスタンスを取っていれば、どうにかなるものですよね。
さいごに
エンジニアは「わからないこと」を理解し、紐解くことに喜びを感じる生き物だと思います。
今回、フロントエンドからサーバーサイドに転向する機会を与えていただいたCTO、エンジニアリーダー、ペアプログラミングなどに親身に付き合ってくださっているメンバーには感謝しかありません。
今後、良いサービスづくりに貢献できるよう精進していきたいと思います。
