「フロントエンドエンジニア」という立場でチームに関わる時に私が大事にしてきたことの話
こんにちは。MIOです。本業はフロントエンドエンジニアをやりつつ週末でイラストを描いたりしている人間です。
この記事を読んでいる方でご存知でない方もそうでない方も色々いると思いますが、この度、2020年2月19日を持ちまして、2年間ほど勤めていました面白法人カヤックを退職します。
この2年間を通じて色々な人とご縁が生まれたし、一応節目だし、ご連絡的な意味で退職エントリーを書こうかな、と思ったのですが、いざ話題を考えた時、なんとなく、それを書くのは私の役割じゃないのでは・・・？と感じていました。
なぜそう感じたかというと、正直な話、私は前職でめちゃくちゃ有名な実績を残した！とか会社に変革を起こした！とかではない、スター選手ではない方の人間だと自覚していたからです。さらに言えば、会社の掲げる「面白法人」らしい人間かと言われると、特別ぶっ飛んだ何かがあるわけではないし、なんでも面白くアイディアとして昇華することが得意かと言われたらもっと社内に猛者がいるし・・・という感じに、自信持ってイエスが言えないような人間です。（あ、会社の技術ブログでこんな感じやこんな感じに自分の好きなことをヲタク語りすることに関しては得意な方でした。地味めなセールスポイント・・・）
ただ私は、「スター選手じゃない人間なりに、どうやってこの会社の中で必要とされる人間になるか」ということは割と意識していた、と退職を前にした振り返りの中で気づきました。実際に私はそのおかげで、フロントエンド未経験で入社した一年後には、案件のリードエンジニアやテクニカルディレクターの立場を任せてもらえたり、色々なプロジェクトに関わらせてもらうことができました。（もちろん、会社の方々が色々と快くチャレンジの機会を与えてくださった、という周りの方の協力があってこそですが）
そして、以前からもくもく勉強会でお世話になっていたあすかさんの主催するなんでもLT大会にて、前述の気づきを元に「私の２年間を通して考えたフロントエンドエンジニアの案件での立ち回り」をテーマにLTを行ったところ、ありがたいことに出席者の方から予想よりも興味関心を持ってもらえたので、「あ、多分私が役割的に話すべきことはこれだな」と感じました。
そんなわけで、今回はフロントエンドエンジニアとして案件にどう関わっていくかの個人的な見解について書くことで、私の退職エントリーとしたいと思います。
LTとして話したスライドはこちら
基本的にはこのスライドの内容の話をしますので内容重複しますが、この記事の中ではLTで補足的に話した内容も織り交ぜての構成で綴っていきたいと思います。この記事はそれなりの文章量なので（すみません・・・）、さくっと読みたい方はこちらにアップしているスライドを読むことをおすすめします
制作会社のフロントエンドエンジニアになって個人的に感じたこと
一番、全く異なる色々な職種のメンバーと関わるポジションだと感じました。
そもそものコンセプトや企画、制作物の構成を理解し、クライアントと密に連携を取っているディレクターorプランナー。制作物のビジュアルに関しての責任をもつデザイナー。要件によっては裏側で色々な処理を捌いて、かつサイトの公開のための土台を整えてくれるサーバーサイドエンジニア・・・フロントエンドエンジニアは少なくともこれだけの人間に関わります。つまり、全く異なる専門分野や趣向をもつ人々にそれぞれ合わせてコミュニケーションを取っていく必要があるということです。それぞれの専門分野の相⼿に応じてどうコミュニケーションをとるか、何を⼤事にして関わっていくかは、⼀緒に案件をやる上で結構重要な姿勢でした。
そのため、案件の数を経ていく中で、自分の技術力を上げていくのはもちろん、メンバーとやりとりするときに「この相手にはこういう出方 / 心構えで臨もう」という心がけや対処術を、同時並行で自分の中に蓄積していました。
それぞれの職種とどのような心がけでコミュニケーションを取っていくか
では私がそれぞれの職種に対して何を大事にして案件に臨んでいたか？を紹介していきたいと思います。
・対ディレクター / プランナーの場合
• とにかく、ワイヤーフレーム（WF）周りは督促。WFで気になったところはすかさず指摘して確認しにいく
• 仕様が降りてきたとき、どれくらい⼯数的にかかるかがパッと伝えられるようにしておく
• この話結局どうなったんだ？と思ったら、すかさずアラートをあげる
• 技術的な懸念点が上がってきた時は、相⼿が理解できるレベルまで噛み砕く⾔語⼒または図解⼒がいる
• 一番制作物の本質を理解している相手なので、成果物のチェックは必ず⾒てもらうようにする
仕様の重要性を⼀番わかっているのはエンジニア！というスタンスで意見を提示するようにしていました。
一番クライアントに近い立場なので、彼らからの意見は制作物の本質となり得るものである場合がほとんどです。ただ、彼らは企画やコンセプトづくり、クライアントとの対コミュニケーション能力が高いですが、技術や設計に関してはこちらの能力の方が高い場合が多かったです。（ディレクターやプランナーがエンジニア上がりの場合だと多少話が変わってきますが）
ウェブサイト制作の場合、設計の要となるのがワイヤーフレーム。このワイヤーフレームで考慮漏れがないか、仕様的に破綻したことが書かれていないかなどは必ずチェックしていました。仕様的にわかりにくいところがあったら真っ先に相談しにいき、必要であれば仕様をわかりやすい資料に落とし込んだりもしていました。
また、懸念点やクライアントからの仕様の相談があった場合に、
・それが可能かどうか
・可能な場合は、どれくらいの工数がかかり、何が懸念点となりうるのか
・不可能な場合は、なぜ不可能なのか
ということを、技術専門ではない相手でも理解できるレベルに砕いて伝えるための力や手段を持っておくことも重要でした。図式化やスプレッドシートに表でまとめる、わかりやすい解説記事を持ってくる、などは個人的によくやってました。
・対デザイナーの場合
• マークアップや画⾯がある程度仕上がった段階でデザイナーさんにズレがないかなどをチェック
• 「画⾯が可変する」観点から⾒せ⽅を提案する
• デザインデータが原因で実装が難しい場合はすぐに相談
• 演出にこだわりたいサイトの場合、アニメーションのイージングの雰囲気などを探れるサイトや、デザイナーさんも扱えるようなGUIツールを⽤意して塩梅を⼀緒に⾒ていく
デザインを尊重しつつも、⾒せ⽅や演出をこちらから提案する、という姿勢で臨んでいました。
エンジニアが画面を見る時と、デザイナーさんが画面を見る時では気がつく観点が異なると感じていたのと、私が基本的にデザイナーさんのあげてくださったデザインをしっかり再現したい精神だったので、マークアップ、演出入れ込みなど、画面がステップごとに仕上がってきたタイミングで都度確認してもらうようにしていました。
そして、演出の入れ方などはこちらから提案することが多かったです。なぜそういう動き方をしたかというと、私自身が演出を考えるのが好きだからというのもありますが、デザイナーさんによっては「⽌め絵」でのインパクトを出すのが得意だけれども、「画⾯が可変する」ということを踏まえて網羅できてない場合があったからです。基本的に「画面は動くもの」想定で組んでいるこちらから提案して詰めて行った方が、実現可否なども同時に考慮できるためスムーズでした。
また、画面の演出や見せ方にこだわる場合、必要に応じてGUIツールの導入で自分以外の人間が演出の塩梅を探れる環境を作っておくと良いです。
・対サーバーサイドエンジニアの場合
• 問題点や仕様の重要性は理解してもらえている分結託しやすいので、まず最初に味⽅につける
• サーバーサイド的には何がどこまでやれるか、を聞き出して、フロント側でどうやって対処すれば仕様を満たすために⼀番スムーズになるのかを共に落とし所を⾒つける
• こっちが何がどこまでできるかをも分かってもらうのも⼤事
• フロントエンドでも、ネットワーク周りだったり、データベースの知識を持っておくとよりお互いに協⼒しやすくなる
何がどこまで対応可能か、どういう⾵に繋いでいけばいいかをしっかり認識合わせしておくことを重視して動いていました。
同じエンジニアという⽴場でもあるので、仕様や設計の重要性は最初から理解してもらえます。なのであとは、お互いの仕事の分担をはっきり明確にしていくことが重要です。仕様の実現に向けて協力関係を結ぶことを目標に、フロントである自分が何ができるかということと、サーバーが何ができるかということをお互いに理解できるよう、コミュニケションをとっていました。
ちなみにこの際、どちらか、または両方がフロントとサーバーの知識を持っているとかなり意思疎通がスムーズになります。個人的に、前職でサーバーサイドエンジニアをやっていた経験と知識が相互理解の促進に繋がったことは結構ありました。
・どの職種にも共通して⾔えること
• 仕様、認識のすり合わせはできるだけFace To Face（ですが、昨今のコロナ事情を鑑みてここをどうしていくかな。。。と考えています）
• 必要に応じて「伝えるためのツール」を使ってコミュニケーションを補強
• どんな時でも、自分ができないorやってない領域の責任を持っている相手に対する尊敬の気持ちは忘れないように
他の職種の人とコミュニケーションを取っていく中で注意すべきなのは、認識相違の発生です。個人的に、認識相違の発生はお互いの言葉の解釈の違いだったり、言葉が足りないことによって発生することが多いと感じていました。そのため私は認識を合わせるときはなるべく対面で話すことを心がけていました。対面で話すと、その場ですぐに自分の疑問や確認に対するフィードバックが得られるのと、チャットなどの文章では伝わらない相手の表情や声音から得られる情報をもとに自分の対応をもっと工夫することができるという利点があります。あと、長文のチャットで打つ時間よりも対面で話したときの時間の方が認識合わせにかかる時間が短いことが多かったのと、話す回数が増えると自然とチームメンバーとの信頼関係が生まれやすくなったので、個人的に可能であれば対面で話すように動いていました。
この話をすると、「その場の会話に参加していなかった人に対しての共有はどうするのか？」と聞かれたことがありました。その場合は、その時話した内容をまとめとしてチャットツールで議事録として共有する、という試みをしていました。そうすることで、その場にいなかった人にとっては情報共有となるだけではなく、その場にいた人にとっては認識相違がないかの確認にもつながったからです。
ただ、昨今のコロナ対策的な観点だと対面では難しくなってきてしまうことが増えてきそうなので、今後はチャットとオンライン会議でのコミュニケーションの取り方も色々と模索していきたいと思っているところです。。。
あとは、相手に対する尊敬や感謝の気持ちを忘れないこと。これは個人的に反省したことなのですが、自分が忙しいと「自分ができないこと、やってないことを、別のチームメンバーが責任をもってやってくれてる」という事実を忘れてしまいがちになってしまいます。ただ、その当たり前の事実を頭の中にいれて相手と接した時、自分がコミュニケーションで選ぶ言葉や行動が自然と相手を思いやったものに変わります。チームで動いている場合、この尊敬と感謝の気持ちは自分の仕事の質の向上と相手からの信頼度の向上につながるのです。
私が実際に使ってコミュニケーションに役に立ったツール
Miro
オンラインで共有できるホワイトボードツールです。私はこのツールで何か図式化したり共有資料を作ったりするときに使っていましたが、とても便利でした。テンプレートでカスタムジャーニーマップやフローチャートなどが用意されてるので、職種に応じて様々な使い方ができるのが特徴です。
dat.GUI
GUIツールはエンジニアの人ではなくても使い方さえ覚えれば誰でも画面の変化や変化した時の感触を確かめることができるので、何か一つ押さえておくといざという時便利です。個人的にはdat.GUIを好んで使っていました。在職中に書いたテックブログにどうやって使っているかをまとめた記事がありますので、興味を持った方は是非こちらもどうぞ。
ーーーーーーーーーーーーーーーーーーーー
以上がフロントエンドエンジニアとしての2年間を通じて大切にしてきた行動指針です。
技術だけではなく、各職種別のコミュニケーションのコツも押さえていれば、他の⼈たちが安⼼して仕事ができるし、⾃分の存在価値も⾼まると個人的に感じていたのでやってきたことですが、もし誰かにとっての参考になるなら幸いです。
せっかくならいいチームで制作していきたいという気持ちは誰しもあると思います。そのために、⾃分のコミュニケーションや動き⽅によって状況を多少なりとも変えることはできる。私は退職後、別の制作会社にて引き続きフロントエンドエンジニアとして従事していきますが、この信条は変えずに自分のできることをどんどんやりつつチャレンジして行こうと思います。
最後に…
私がこのような気づきや学びを蓄積する機会をくださった前職の会社と、お世話になったみなさまに、心から御礼申し上げます。
ありがとうございました！
読んでいただきありがとうございます。とりあえず温かい目で見守ってくださると嬉しいです。