1
/
5

「デザインと実装の最高の妥協点を見つける」one visaフロントエンドエンジニアの本音【前編】

登場人物紹介

名前:馬場敏気

担当:バックエンドを中心に開発

経歴:大学時代に映画「ソーシャルネットワーク」をみてエンジニアを志す。

新卒でHRテックのベンチャー企業に入社し、新規事業の開発を中心に担当。

開発言語オタクで、言語の思想などに思いを馳せるのが好き。最近のブームは、Scala, Python, Dart(Flutter)。通称ばばーる

名前:土谷光

担当:フロントエンドを中心に開発

経歴:SI業界で金融や物流企業の基幹システムをJavaで作る仕事からキャリアをスタート。その後GMOペパボ、CAMPFIREを経てone visaに参画。

フロントエンドエンジニア採用強化中!開発チームの実体を公開

馬場:はい!今回はone visaでフロントエンドエンジニアを絶賛採用強化中ということで、現在フロントエンドを中心に開発されている土谷さんにインタビューをしようというコーナー。

題して「one visa フロントエンドエンジニアの本音」です!

前編と後編に分かれていて、前編は主にバックエンド開発をやっている僕と土谷さん、後編はデザイナーの西垣さんと土谷さんでお送りします!

土谷:急に堅くなったな(笑)

馬場:髪切った?!

土谷:真面目にやりましょう(笑)

SPA開発とフロントエンドエンジニア

馬場:では早速ですが、フロントエンドエンジニアという職種は業務範囲が会社によって異なるケースが多いですよね。

前職では基本的には僕がバックエンド、デザイナーの方がコーディングを担当しつつも、フロントの細かなロジックは、僕が担当したりしていました。

土谷:僕もフロントエンドを名乗って専門的にやり始めたのはここ2年位ですかね。

それ以前はデザイナーがいわゆるフロントエンドエンジニアがやる業務領域を担っていたり、”Webエンジニア”みたいな大きなくくりでよしなにやる形式が多かったですね。

馬場:土谷さんはもともとiOSエンジニアもやられてたじゃないですか。なんで今フロントをやられているんですか?

土谷:僕は昔からフロントエンドの方が好きというか、UIとかの実装をメインでやっていきたいなと言うのがあり、特にWebフロントエンドの領域が好きでした。

SPAについては2011年くらいからさわり始めたのですが、その頃はまだ一般的なアーキテクチャではなく「APIっていうのを作ったほうがいいらしいぞ」という感じで手探りでした。

馬場:そうですよね、画面に変数を渡すという発想から、APIから取ってくるというような発想への変化。

土谷:当時はクライアント側とバックエンド側で両方同じ実装の仕方をしないといけないことへの問題意識がありました。

例えばAjaxでページングを行うけれど初回描画はサーバーサイドで行うような、今でいうSSRのようなことをしたい場合、テンプレートもバラけるし、ロジックもバラけてしまいます。

クライアント・バックエンド両方で同じ動きをするように揃えていかないといけないのは開発効率も悪いし、バグりやすいというのもありました。

そのころは中途半端な”ちょっとだけSPA期”で、既存の開発手法に対する問題意識もバーっと出てきた感じですね。

当時業務で触っていたのは2000年代中盤とかそれ以前に作られたプロダクトだったので、それを一気にSPA化するのは難しかったです。one visaはその点新しいサービスなので、その辺0からできてすごくいいです。

馬場:ほんとそうですね。新規プロダクトは作りやすいですもんね。

one visaの開発に関して「ビザのサービス特有の開発手法というのはない」

馬場:one visaってドメインが特殊なので、「高度専門職」みたいな専門用語とか、「在留資格とビザの違い」みたいな専門知識とかが求められるケースが多いじゃないですか。

フロントエンド開発の観点から、特にこういう能力が必要とか、意識されていることってありますか?

土谷:特別はないですね。国籍や文化など様々なバックグラウンドを有する人たちが使うので、国際化対応とかは意識していますが、ビザを扱うサービスだからこういうUI・UXじゃないといけないみたいなものはないですね。

馬場:深いですね、逆に。

土谷:強いてあげるとすると、one visaってビザを申請する外国籍社員と、その進行管理をする人事、更に実際にビザの申請等を行う行政書士が登場人物としていて、1回のビザ申請で、ボールがこの間を行ったり来たりするため、「今誰がボールを持っているのか」を分かりやすくするのは肝だと思っています。

あとは今後多言語対応をしていくにあたって、日本語とは逆の方向に書く言語に対応するとかだと話は別ですが(笑)

馬場:確かに、サイドメニューどっちに置くんだ、とか議論の余地がありそうですね。

土谷:国によって色味やテイストが与える印象も違うでしょうし。

馬場:この色はこういう印象を与えやすいとか、国の背景にある文化によって色々意味が異なりそうですもんね。

まあでも、one visaの場合そういうデザインの深いところは西垣(デザイナー)がやってくれますからね。

土谷:そうですね、とても助かります。

デザインと実装の最高の妥協点を見つけるのがフロントエンドエンジニアの役目

馬場:one visaのフロントエンドエンジニアが担う役割って、実装それ自体よりもデザイナーやプロダクトオーナーと画面について話したりする部分が大きい気がしています。

デザイナーの西垣さんが作ったモックはありますが、それをエンジニアの知識を持ってUIに寄り添って「バックエンドはこういうデータの持ち方しているからこうした方がいい」とか、そういう議論をしてくださってますよね。

土谷:そうですね。

馬場:僕から見ていると、フロントエンドエンジニアは潤滑油で”プロダクトをつくる”ことと”システムを組み上げる”ことの両輪を回さなくてはいけないので、間に入って板挟みなイメージを持っています(笑)

土谷:もしかするとネガティブに聞こえるかもしれないんで、これ書かなくてもいいんですけど(笑)

馬場:書かなくてもいいんですけどって書かれますよ(笑)

土谷:言葉を選ばずに言うと、フロントエンドエンジニアって「妥協をするのが仕事」みたいなところがあって。

システムの要求とデザイン(=ユーザー)の要求の折り合いをつけるのがフロントエンドエンジニアの仕事だと思っています。

両方100点でいければ当然最高なんだけど、そうすると現実的にいつまでもリリースできないという面もあり。リリース時期と、システムの都合と、ユーザーの要求のこの3つの折り合いを付ける必要があるんですよ。

その中でフロントエンドエンジニアとして、”最高の妥協点を見つけること”を意識していますね。

多少我慢するところが出てくるけど、現実的に誰も不幸にならない、一番いいポイントを探すという感じですね。

馬場:今取り組んでいるシステムの改修だったら、何のためにやっているのかでリリース時期を優先するのか、UXを高めにいっているのかによって、妥協のポイントも変わってきそうですもんね。

土谷:そうですね、なのでプロダクトオーナーと話す時は必ず”何のためなのか”を確認するようにしています。

フロントエンドは特に設計が大事。デザイナーとの認識を合わせるためにも議論から逃げない。

馬場:フロントエンドは特に設計をどうするか、ってかなり大事ですよね。

どう作っておくのが後から使いやすいのかをかなり意識しないといけない気がします。

土谷:3画面くらい作ってから「あ、この設計まずかったな」って気づくとかありますからね。

馬場:そういう時って、実際のコードを見ながら「こことここ共通化できそうだな」となるのか、デザインデータを見て、使い方が似ているから共通化しようとなるのかだと、どっちが多いんですか?

土谷:コンポーネントの粒度みたいな話ですよね。西垣さんとの間では、最初にコンポーネント名をお互いに言い合うみたいなことはやっていますね。

お互いに画面を見て、その画面の中に登場するコンポーネントを指して「これってどういう名前?」っていう質問をお互いにします。そうすると面白いことに結構ずれるんですよね。共通化の視点がエンジニアとデザイナーだとぜんぜん違う。

エンジニアからすると、見た目がほとんど同じだから同じ名前で共通化していても、デザイナーからすると、特別な役割を担っているコンポーネントだという風に捉えていたりします。

馬場:見た目は一緒だけどぜんぜん違う役割を持っていると。なるほど。

土谷:名前を出してみると、すごく具体的な名前が付く場合と抽象的な名前が付く場合があるんですよ。そうすると、名前を見るだけでこれはある程度共通の要素として使用されるコンポーネントなのか、特定の場面でしか使われないコンポーネントなのかが分かるじゃないですか。最初にその認識を揃えるというのはよくやりますね。

馬場:それめっちゃいいですね。

フロントエンドとバックエンドが議論し合うチーム

馬場:話は変わりますが、以前バックエンドエンジニアの数が増えた時、APIの設計に対して僕が全部レビューしてたじゃないですか。そこに今、(フロントエンド担当の)土谷さんが入ってきてくれていますよね。あれ良いですよね。

土谷:すごく良いと思っています。

馬場:僕が前職でiOSをやってた時は、すでにドキュメントがあって、それを実装してた感じだったんですよ。

土谷:僕も一人で表も裏も両方開発していた時は、自分が扱いやすいように書いていたんですが(笑)

API側の都合もあるだろうから、最低限この画面実現できないよってレベルじゃないと、APIをそのまま使ってしまいますよね。

馬場:いまはAPI設計の段階でフロントエンドの方から意見くださっているのが、すごくやりやすいです。

土谷:今はドキュメント駆動でやってますが、僕とばばーるの二人で開発してた時は、わざわざコミュニケーションをドキュメント化する必要もないだろう、くらいな感じで開発してましたよね。

馬場:ここ欲しいですって言われたら僕が「はい!」って感じで即リリースしてましたね(笑)

土谷:あれはあれで、すごく楽ではありましたが。

馬場:一方で、開発に携わる人数が増えたときに、いかにスピード保つかを考える必要があります。

開発チームで共通語を作るためにも、バックエンドからだけじゃなくてフロントエンドからの意見も聞いてAPIドキュメントをしっかり作っていくというのは続けていきたいですね。

土谷:今のやり方で、レビューの時点でこうだったらいいなというのを言うことは出来るんですが、フロントエンドからAPIドキュメントに対してプルリクエストを投げる、というのもありかなとも思っています。

馬場:あーそれ面白いですね!

あんまり画面に依存しすぎるのもAPIなので良くないかなと思いつつ、オープンAPIではないのでフロントエンドから見た理想って知りたいかもしれないですね。

僕は割と聞いちゃいますが「これ配列で返すのとオブジェクトで返すのどっちが使いやすいか」みたいなの、どんどんフロントエンドの方から投げていただいて、それを見た上で僕らはデータベースとお話するので。

後編につづく!

↓以下のインタビューも御覧ください。

株式会社one visa's job postings
3 Likes
3 Likes

Weekly ranking

Show other rankings