こんにちは。フロントエンド、最近はWebディレクター的な仕事をしているしているナッツです。
今日は20代後半未経験でフロントエンドエンジニアに挑戦した僕が、
- 最初の半年で任された仕事
- 業務で大変だと感じた事
- 持っておいた方が良い考え方
これらについて、僕の実体験をもとに書いていきます。
これから未経験でWeb業界に転職を考えている人、Web業界の実情を知りたい人は参考にしてもらえたらと思います。
初めに、当時の僕のプロフィールを書いておきます。
就職時（3年前）
- 年齢・・・28歳（現在31歳）
- 経験職種・・・営業経験のみ
- PCスキル・・・基本操作のみ
- その他・・・有料の職業訓練学校には通った
- 彼女在り（現在の嫁）
就職した会社は当時10人規模で、Webデザイナー、フロントエンド、Webディレクターの3つの部署がある感じでした。 主に受ける仕事はホームページの制作・保守、システム開発（バックエンドは外注）といった体制になりました。
最初に任された仕事
最初に任された仕事は、
- Webサイトの修正作業
- デバッグ
- LPのコーディング
になります。
Webサイトの修正作業
最初に任された仕事はホームページのテキスト修正、画像差し替えといった、軽微な修正作業でした。
作業内容さえ覚えてしまえば、誰でもできる簡単にできる作業になるので、こういった仕事は新人に任せられることが多いです。
Web制作を行っている会社は、月額でこういった保守業務の仕事依頼を受けている所が多く、毎月安定して売上げが上がる案件になる為です。（毎月の売り上げが安定するのはとても大事なことなのです）
当時の修正作業は、テキストの差し替えをするときは、修正ファイルをFTPソフトでダウンロードしてきてローカル環境で修正、先輩にソースコードや表示を見てもらい問題なければ修正ファイルをアップするという感じでした。（今でこそgitというバージョン管理ツールを使用していますが、当時はFTPでダウンロード⇒バックアップファイルを作成⇒修正してファイルをアップロード、というアナログな作業をしていました。）
ホームページの規模が大きかったりすると、サイト構成が複雑になるので構成を把握するのに苦労したのを覚えています。
構成を理解しておかないと、
- どのファイルを修正しないといけないのか
- 修正して他の箇所に影響が出ないか（cssの修正など）
上記のことで困ることになります。
修正作業を重ねサイト構成を理解していくことで、ホームページがどういう運営をされているかを理解することができるようになっていきます。
デバッグ
入社してしばらく経つと、先輩が作っていたシステムのデバッグをやりました。
デバッグとは、作ったシステムやホームページに不具合がないかを確認する作業の事です。
先輩に仕様を教えてもらい、
- 仕様通りの動作をするか
- イレギュラーな操作をした時に不具合が起きたりしないか
などの事を確認していきました。
当時は「もっとホームページ制作案件をやりたい！」という思いが先走っていた為、デバックなんてしたくない、という気持ちがあったので辛い作業でした…。（理由は単純で地味だから…）
ただ、今となってはシステム開発・ホームページ制作におけるデバッグの重要性を死ぬほど理解し、大事な作業という考え方が身に沁み込んだので、嫌いな作業では無くなりました。
理解したのは、デバッグが不十分だったことが原因で、大きなトラブルの経験をしたからです。
デバックの時に見つけられてさえいれば、防げたことなのに…
こういう後悔を何度もしてきて、やっとデバッグが持つ重要性が理解できたのです。
ランディングページの作成
HTML、CSSの基礎ができてきたらランディングページを作る仕事を任されました。
ランディングページとは1枚物のホームページの事で、新商品・サービスの宣伝や広告などて使用されるウェブサイトになります。
一枚物なのでCSS設計を深く考える必要がないのと、短期間でできるという為、新人に任せやすい仕事です。
当時は初めての実務コーディングという事で、不安と楽しさが入り混じっていた事を覚えています。
初めてのランディングページ案件は、コンテンツ量が多くて制作期間は1週間くらい与えてもらえました。
現在の僕では1日でコーディング完了できる内容も、当時は3~4日かかっていたりするなどしていました。
ただ、それでも間に合いそうにないので、最終的に途中から先輩に引き取ってもらい迷惑をかけてしまいました…
初めての実務のコーディングでは、どういう風に作るのが最適解なのかが判断できずに、無駄に考えてしまう事が多くなると思います。
指導をしてもらえる環境であれば、
どういうコードを書くことが最適なのか、その背景にある考え方は何なのか。
という事を聞ければ早く成長ができると思います。
業務で大変だと感じること
- 調べるということ
- スケジュールがタイトになる時
調べるということ
ホームページの保守業務を行なっていると、
「今まで表示されていたページが突然移らなくなったんだけど、直してくれない？」
「こういった機能を追加してほしいんだけど実装できる？」
といった調査業務が必ず発生します。
そういった時にまずやるべきは、分からない時はまずググる、ということです。
この行動がエンジニアには必須になり、自分で調べて解決をしていく事が本当に大切になります。
ただ注意して欲しいのは分からないからといってずっと一人で抱え込むのは良くないという事です。
よく言われているのは30分調べて分からなかったら相談しましょう、というものです。
それ以上は時間の無駄という事で人に聞いてしまった方が早いです。
質問の仕方で、コイツはできるやつだと思われるので、できると思われる質問の仕方にまとめてあります。
タイトなスケジュールの案件の時
タイトなスケジュールで制作を進めないといけない時も大変です。
エンジニアは常に納期との戦いをしています。突発的に決まった案件なんかは特にタイトなスケジュールです。
今の業務の隙間に何とかねじ込んだり、残業覚悟でスケジュールで組まないといけない時もあります。
また、同時進行で他の案件も進めないといけない時もタイトなスケジュールになります。
少人数の会社ほど1人あたりの仕事量が多くなります。新人ほどタイトなスケジュールの影響を受けやすく、それは詰まった時に自分で解決ができる事ができないからです。
少し慣れ始めてくると、「この仕事○○日迄にお願いできるかな？」という依頼も当然来ます。
自分は任せられるのが好きな為、なんでも喜んで受けていましたが、キャパオーバーだと思っても、自身の成長につながると思い喜んで仕事を引き受けていました。
僕は成長のためにはキャパオーバーは必要なものだと思っていて、仕事は勉強やスポーツと一緒で、ある程度負荷を掛けないと、飛躍的な成長はできないと考えています。
タイトなスケジュールになる事は大変ですが、その分、他の人よりも早く成長ができると思って仕事に取り組むのが、僕の好きな考え方です。
持っておいた方がいい考え方
未経験でWeb業界へ転職、エンジニアになるうえで持っておいた方が良い考え方は、
- 同じ作業を効率化できないか考える
- 分からない時は聞く前にまず調べる
になります。
作業の効率化をできないか考える
僕が考える効率化とは、共通化だと思います。
一見ことなる作業でも共通点を探して、その共通点を短縮できる方法を考える。
これに尽きると思います。
例えば、
- コードを書く
- メールの文章を作る
- 資料を作る
という事に関しては「キーボートを打つ」という作業が発生しています。
もし、ブラインドタッチができる人・できない人で比べた場合、できる人の方がすべての仕事が早いという事になります。
仕事が早い＝たくさん仕事を回せる＝人よりも早く成長ができる というサイクルを生み出せるので、「キーボードを打つ」という作業だけ早くするだけで、他の人よりも早く成長できる機会があるのです。
未経験の場合は作業の種類が多いと思うかもしれないですが、共通化できるところを見つけて効率化していけば、きっと生産性が上がるはずです。
分からない時は聞く前にまず調べる
エンジニアには必須といえる能力が自分で調べる力です。
仕事になると自分の知識では分からない事がたくさん出てきます。
任せられた仕事は、まずは自分の力でやり切ろう！ という意識を持つことが大事だと思います。
ただ、人に聞かずに抱え込んでしまう人もいると思います。（僕もその傾向がありました。）
しかし、抱え込んでいたが為に納期に間に合わない！といった事になるのが一番最悪です。
そこでお勧めしたいのは、30分調べても分からなかったら人に聞くということです。
聞くうえで、「ここが分からないです」と聞いただけでは乱暴な質問になってしまい、質問の受け手がヒアリングして内容を把握する、という受け手にストレスが生じさせることになってしまいます。
コツは質問を受けた側は
- どんなことをしたいのか（こういう機能を実装したいなど）
- その上でどんなことを調べたのか（仮説でOK）
- その上で分からないところはどこなのか（こんなことを試してみたがこういうエラーが出てうまくいかない）
ここさえ受け手に伝われば、ストレスなく回答をしやすくなります。
新人の時には、とくにこの聞き方を意識するのが良いと思います。
いかがでしたでしょうか。
ここに書いた内容は、自分が経験してこうしておけばよかったと感じたことです。
もしこれから同じように未経験でWeb業界に行かれる方の役に立てれば幸いです。
コメント