インタビュー後編では「LIGフロントエンドエンジニア誕生秘話」をテーマに、LIGにおけるフロントエンドの役割、チーム体制ができるまでの道のりを語るお2人の声をお伝えします。
- 1. デザイナーやサーバサイドとの間に壁があると、フロントエンドに意味はない
- 2. 情報は海外から。本になる頃にはもう遅い
- 3. フロントエンドの立ち位置を変えるために、会社の制度も仕事の進め方も全部変える必要があった
- 4.「提案型」エンジニア集団を目指して、現在は意識改革の真っ只中
- 5. これからのCSS設計はスピードよりも拡張性・保守性が重視される時代に
1. デザイナーやサーバサイドとの間に壁があると、フロントエンドに意味はない
－LIGさんでは、デザイナーとフロントエンジニアでどのような線引きがなされているのですか？定義分けというか。
林：定義分け・・・まあ、業務上の違いは多少ありますが、そもそもデザイナーやフロントエンドとの間に壁があること自体問題だと思っているんですよね。
要は、結局どちらも「クライアント、ユーザが見る画面を設計する」という点では共通の仕事なんです。
そこは共有して、一緒に画面を作っていかないといけない。境目があってはいけないなって思います。
－なるほど。呼び名の違いこそあるものの、分けるのはナンセンスだっていう。
林：はい。
フロントエンドエンジニアが出てきたそもそもの背景は、フロントのコンテンツがすごくリッチになってきて、コーディングの領域が広くなってきた所にあります。
今まではデザイナーとサーバサイドでなんとかなってきたところにフロントエンドっていう中間の職種が出てきたってことは、結局お互いの繋がりを強くしていかなきゃいけないということで。
そこに壁があると、そもそも中間の職が出てきた意味が無くなってしまうので
両方の素質を持っているのがフロントエンドの大事な所かなと。
あえてここに壁を作る場合は「コーダー」という領域の人になるんだと思います。コーディングをする人ですね。
－では逆に言うと、役割をきちんと認識せずに自分で壁を作ってしまうと、フロントエンドエンジニアとして生きていくのは難しいと。
林：そうですね。フロントエンドはデザインもサーバサイドも広く知識を持っているのが理想のポジションだと思っているので。
－フロントエンドの方でデザインもサーバサイドも広く理解されている方って、そんなにいらっしゃるのでしょうか。あまりたくさんいるイメージがないのですが・・・
林：決して数は多くないと思います。実際、求人を出してもそこまでの人はなかなかいないですね。サーバサイドが得意だとどうしてもデザインが欠けてしまったりとか、逆にデザインが得意だとデータベースとかが「んー」ってなっちゃう人が多い。
まだフロントエンドって職種の人間が少ないのは、やっぱりその守備範囲の広さが1つ理由としてあるのかな、とは思います。
－「フロントエンドエンジニア」という言葉だけで受け取っちゃうと、フロントに特化していればいいみたいなイメージになりがちですが、決してそうではないと。
林：そうではないですね。やっぱりデザイン的な部分とか、使う人の気持ちも考えながらやらなきゃいけないことも多いですから。
－では、そういう方が理想として、LIGのフロントエンジニアチームもそういう人が集まる集団にしていきたいと考えているんですか？
林：実はあんまりチームには極端に「広くが理想」とは押し付けていなくてですね。
要は、「守備範囲が広い」ということは「やりたいことがやれる状態」だと思うんです。
デザイン中心でやりたければデザインに寄れますし、サーバサイドがやりたければサーバサイドに寄れるポジションなので、そこは自由に決めてもらっていいと思っています。
2. 情報は海外から。本になる頃にはもう遅い
－ちなみに、フロントエンドのノウハウ収集はどのようになさっているんですか？
林：Webの情報はやっぱり海外の方が早いので、海外の情報でキャッチアップしたものをこっちに持ってくる感じですね。
そうすれば、日本語で本が出た時点では「もうそんなの知ってるよ～」くらいの感じになるので。
－簡単そうに聞こえますが、それってかなり難しいことですよね。
林：そうですね。フロントエンドの人たちは結構そうせざるを得ないですね。
でも、最近は海外からの情報が輸入されてくることも多いですし、情報は取りやすくなってきたなと思います。
－そうなると、当然英語のスキルも必要になってくるわけですね。
堀口：そうなんですよ（苦笑）
林：少なくともリーディングに関してはそうですね。
3. フロントエンドの立ち位置を変えるために、会社の制度も仕事の進め方も全部変える必要があった
－ところで、LIGさんでフロントエンジニアのチームができたのはここ最近のお話だと伺いました。
林：今年の4月ですね。
堀口：以前からチームの前身のようなものはあったんですけど、上手く機能していなくて。
「これはちょっと柱になる人が来ないとあかんぞ」みたいな。そこに林先生が来て、リーダーになってからようやく形になってきたって感じですね。
そもそもは、デザイナーから転向した僕と、づやさん（LIGのCTO高遠氏の愛称）でチームを作ろうって始めてたんです。
でもまあ、僕は当時転向したばかりだし、づやさんは元々バックエンドがメインだったということもあってなかなかフロントエンドチームとして体制が上手くいってなかったんです。そんなところに入ってもらって。
－まさに救世主現る、ですね。
林さんは、当時のチームにどういう印象を抱いていましたか？
林：どう・・・ですかね、チームが存在している感じかしなかった（笑）
堀口：なんせ2人でしたから（笑）
林：むしろ、何も無かったって言ったほうが正しいかもしれないです。フロントエンドチームとして。なので逆に言うと、自分が作りたいように作っていけたっていう良さはありました。過去の変なしがらみみたいな、凝り固まったものが無かったので。
もう本当に、耕しただけの畑のような（笑）
堀口：これから種を蒔こうと思ってたんですよ（笑）
－チームを1から作り上げるところから始まったんですね。その中で特に苦労したエピソードがあれば伺いたいです。
林：苦労した点・・・なんだろ。でも、入ったばかりでチーム作りに関わっても「なんなんだこいつ」みたいな空気感は感じませんでしたね。
あれ、気づいてないだけ？
堀口：ありませんでしたよ。何をおっしゃいますか（笑）
林：そういう部分は特に心配なかったんですけど。
大変だったのは堀口もまだ転向したばかりだったので、やっぱりスキルレベルというか、知識の部分でまだ基礎ができていない状態だったんですよね。教育の部分が大変でしたね。基本的なことですが。
あとは大幅に体制を変える必要があったのでスピード感をもってやりたかったのですが、そのスピードに対して周りがなかなかついてこれるか？っていう。そのスピードの調整は気を遣いつつでしたね。
－大幅に変えたかった部分って、具体的にはどの部分ですか？
林：フロントエンドエンジニアの立ち位置ごと変えたかったので、会社の制度や仕事の進め方まで全部変えるっていう。もっと上流の階層から、ディレクターもデザイナーも。いわゆるウォーターフォール型をアジャイルに近い形に変えていきたかったので、チーム全体の制度を変える必要があったんですね。
はじめは「アジャイルとは」みたいなところから徐々に布教活動して、教え込んで、こんなメリットあるよっていうのを各所に吹き込みながら根回しをして。
で、フロントエンドエンジニアがより広く活動できるように調整していきました。
デザイナーの守備範囲を徐々にフロントへ取りにいって、サーバサイドの方も同じく取って。狭まっていたフロントエンドの領域をガーっと広げていかなきゃいけなくて、そのために制度ごと変えていきました。
－たとえば、意思決定ミーティングにフロントエンドエンジニアも参加するとか、そのあたりも含めるイメージでしょうか。
林：それもそうですし、自分からその会議を設定するっていうところからですね。
堀口：これまではディレクターがワイヤーフレームを作って、デザイナーがデザインを作って、そこからようやく「コーディングよろしく」って言われるんです。
それだと指示通り組み立てるだけで、単なる作業者になってしまいがちです。
だから、僕らも一緒に考えるところから作っていければ、そっちの方が楽しいしクオリティの高いものも作れると思ったんです。
それで、今では上流工程からアサインさせてもらってます。
林：受け入れ側であるディレクターと提案していくフロントエンド、両方の意識改革が必要があって。
ディレクター側には「こういう理由で、フロントエンドも入ったほうが効率いいので入れてください」って調整し、フロントエンドには「何おどおどしてるんだ意見言って来い！」って後ろから蹴りを入れるようにして（笑）
徐々に成果を上げながらやっていく感じですね。
4.「提案型」エンジニア集団を目指して、現在は意識改革の真っ只中
－そうやって体制をつくり始めてから数ヶ月、現状はどうですか？
林：まあ以前に比べたら回るようになりましたが・・・
堀口：社内だけじゃなくて業界全体で言えることだと思うんですけど、やっぱりコーディングっていうのは一番最後の方に行われるものっていう意識は多分まだ残っています。
確かに作業自体の順番はそうなんですけど、「設計の部分から関わらないと良いWebサイトは作れない」という意識がもっと広まればいいなって。そしたらもっと浸透していくのかなって思います。なので・・・もう一歩ですね。
－では、今後LIGのフロントエンドチームとして、どういう風になっていきたいですか？
堀口：「提案」ができるチームになっていきたいなっていうのがあります。言われるままコードを書くだけじゃなくて、「こういう風にしていきましょう」というアイデアがどんどん出てくるエンジニア集団、っていうところを目指しています。
－林さんはいかがですか？
林：うーん・・・悩んでいます。むちゃくちゃ悩むんですよ。
まずはチームというよりも、個々が成長していけばいいなっていうのがあります。
それは好きなことを自分なりに見つけて欲しいっていうのもそうですけど、やっぱり守備範囲が広いので、自分のポジションを自分で作っていかないといけない。
チームで言うと、フロントエンドっていうもの自体がまだ出たばかりなので
「フロントエンドってすごく大事なポジションで、こういうことをやっているんだよ」
っていうのをもっと世の中に知ってもらいたいですね。それを広めていけるメンバーになっていければいいなと思っています。勉強会とかを通して、少しでも知ってもらいたいですね。
5. これからのCSS設計はスピードよりも拡張性・保守性が重視される時代に
－今回の勉強会（ヒカ☆ラボ）ではCSSをテーマということなんですが、CSSが盛り上がっている背景を教えていただけますか？
堀口：これまでのCSSは「ちゃんと綺麗に書ければ良い」程度の扱いだったと思うんですけど、Webサイト、Webアプリケーションがリッチになるにつれて、CSSも複雑化が進んできました。
それで最近では、CSSを書くこと自体よりも「設計」することが重要になってきています。
複雑なCSSを設計抜きに構築してしまうと、複数人でコーディングする場合、他の作業者がどこをどう編集したらいいのかわからない状態になってしまいます。
また、リリース後に新規機能を実装したり、サイト内の一部を改修しようとした時に設計がなされていないと、余計な部分まで影響してしまってスタイルが崩れるなど、さまざまなトラブルが発生するんです。
そういうことを起こさないためにいかに拡張性・保守性が高いCSSを書くか、ということにいち早く取り組んだ人たちがOOCSSやSMACSSやBEMといった考えを提唱して、そうしてCSS設計が注目されるようになってきたんじゃないかと。
でも、OOCSSやSMACSSは概念であって、具体的にこう書こう！というのがないんですね。
具体的な方法論といえばBEMやその派生のMCSSなどは比較的支持率は高いですが、書き方が独特なので好き嫌いが分かれたりします。
だから、その方法論を企業や案件ごとにみんな模索している状態が現状なのかなって思います。
－実際にLIGさんでは導入を？
堀口：そうですね、してますね。
－導入したことで何か変化はありましたか？
堀口：ありましたね。最近ですと・・・もしそれをやっていなかったら大変なことになっていた案件もちょくちょく出てきています。
なので、目先のタスクに追われてバーっとスピードだけを意識して書かないで、できるだけ最初は時間をかけて綺麗なソースを書くことに注力しています。
こういう所をしっかりやっておかないと、たとえば「納期まで間に合わない！」って急遽人を増やそうって時にプロジェクトの内容を何も知らない人が突然アサインすると、余分なコミュニケーションコストが発生しちゃうんですよ。
「このコードどういう意味ですか？」とか「このデータいじっても大丈夫ですか？」とか。
人を増やしたは良いものの余計に時間かかっちゃった、ということにもなりかねないです。
設計をキレイにしておけば、最低限の説明でソースを見れば理解できるので
「コミュニケーションコストをいかに低くするか」という点も考えつつ、頑張って書くようにしています。
－勉強会当日はそのあたりのお話も詳しくお話いただけるってことですね！
堀口：そうですね！
－楽しみにしております！本日はありがとうございました。
堀口・林：ありがとうございました。
ITエンジニア・Webクリエイターの転職ならレバテックキャリア
レバテックキャリアはIT・Web業界のエンジニア・クリエイターを専門とする転職エージェントです。最新の技術情報や業界動向に精通したキャリアアドバイザーが、年収・技術志向・今後のキャリアパス・ワークライフバランスなど、一人ひとりの希望に寄り添いながら転職活動をサポートします。一般公開されていない大手企業や優良企業の非公開求人も多数保有していますので、まずは一度カウンセリングにお越しください。
転職支援サービスに申し込む
また、「初めての転職で、何から始めていいかわからない」「まだ転職するかどうか迷っている」など、転職活動に何らかの不安を抱えている方には、無料の個別相談会も実施しています。キャリアアドバイザーが一対一で、これからのあなたのキャリアを一緒に考えます。お気軽にご相談ください。
「個別相談会」に申し込む
