ポッドキャストの紹介
こんにちは、シニアソフトウェアエンジニアのリドルです。
こんにちは、リドルソフトウェアエンジニアのひびのです。
このポッドキャストでは、僕たち2人で、主にIT企業に関する様々なことを語って、
IT業界のリアルを届けていこうという趣旨の番組です。
その内容は、コラボ会!コラボ会!
イエーイ!イエーイ!
実はですね、今回ゲストをお招きしておりました。
誰ですか?
実際にまずは登場していただきましょうか。
ほうれん草ボンバーさんです。
イエーイ!
初めまして。ほうれん草ボンバーと申します。
はい、あの、お前誰やねんっていう感じだと思うんですけど、
えっと、リドルさんの共通のポッドキャストのイベントで知り合って、
はい、あの、今回ゲストとして参加させていただきました。
はい、普段はフロントエンドエンジニアをやっております。よろしくお願いします。
お願いします。
ついに僕たちのゲストを真似てましたよ。
そうっすね。で、今日何をやるかというと、ひむさん何でしたっけ?
今日の最初の内容はですね、
ほうれん草ボンバーさんにフロントエンドミドルクラスエンジニア総統の技術面接をしよう!
イエーイ!
技術面接ですよ。燃えてきますね。
今回想定の企業としてはどんな感じでしたっけ?
今回想定の企業、まあ、想定の企業っていうのは決めていない。
あ、まあ、僕がちょっとあの、面接こんなこと聞こうかなみたいなのを考えてきて、
で、想定の企業っていうのは基本的にはないんですが、
まあ、僕が今働いてるミクシーで、えっと、
まあ基本的にはその、そこのミドルクラスエンジニアくらいかなとなんとなく頭に思い浮かべて考えてきました。
ミドルクラスエンジニア。
じゃあ自社開発系で中等系ですかね?
そうですね。中等でミドルクラス、まあ、20代後半、30代前半の方向けですかね。
はい。じゃあそれをまあガチな感じで面接していくというのが今回のコラボの内容です。
今本物の面接よりもちょっと緊張してますね、本当に。
確かにこれあれですもんね、インターネットに放流されるんですもんね。
放流されちゃいますから、下手なこと言えないぞというのはすごい緊張しますね。
面接の流れ
ちょっと下手なこと言っちゃったらさすがにパッとさせていただこうかなと思います。
いや、僕も緊張しますね。そんな自分が面接するところをインターネットに放流されるなんて滅多にない機会ですもんね。
確かにこの面接のやり方パーハラじゃねって思われてしまう可能性もあるかもしれないから。
やばい、やばい、やばいよ。
気をつけながらやろう。はい、まあじゃあそんな感じで。
ちなみにほうれん草ボンバーさんはこれまで面接受けられたことはあるんですか?
はい、あります。実は今絶賛転職活動中なので。
いいのか、それって。
なるほど、なるほど。じゃあすごくいいです、ホットな時。
いいですね、はい。明日も本物の面接があるので。
いいっすね。
ちょうど、明日の面接のことを考えると、今日これだけ緊張できた面接が受けられれば明日の面接は余裕だなと思ってください。
確かに、いいウォーミングアップにできるといいですね。
じゃあこっちな感じでいきますか。
じゃあ早速いこうと思います。
はい、じゃあどうしよう。
じゃあちょっと私がマネージャー総統として最初にファシリとかをやりますので、その後技術周りが木村さんの方から質問という感じでお願いします。
技術周りじゃないな、全般的にだ。
そうですね、はい、わかりました。
はい、はじめまして、私リドルと申します。今回は株式会社ホイホゲの面接にお越しいただきましてありがとうございます。
簡単にですがですね、今回の流れについて説明させていただければと思います。
最初に私どもから自己紹介をしますので、その後ホレソボンバさん、今回は長いのでボンバさんと省略させていただきますが、
ボンバさんからの自己紹介と自己PRを10分ほどでお願いできればと思います。
その後ですね、面接官の我々からの質問をさせていただきまして、最後に本来は逆質問ということを用意するんですけれども、
今回は想定していないのでカットという感じでお願いいたします。
今回ですね、リモートでの収録となっておりますので、お互いに反応が遅れることがあるかと思いますけれども、
その際は特に気にしないでいただきたいですと。また資料を見ながらしゃべっていただいても構いません。
こちらはですね、いろいろメモを取らせていただきますので、ちょっと視線が外れたりとか、
違う方向に行ったりとかする可能性もございますが、ご了承ください。
また適宜水平補給などを取っていただいても問題ございません。
もしお手元にないようでしたら、今取っていただいても大丈夫です。大丈夫ですか?
大丈夫です。
はい、ありがとうございます。ではですね、今回はですね、ホレソボンバさんのいいところを存分に聞き出せたと思いますので、
詰まったりとかですね、緊張されているなら、一呼吸をおいていただいても全然構いませんので、ゆったりと自分のペースでお話しください。
はい、では早速自己紹介させていただきたいと思います。
私はリドルと申します。株式会社ホゲホゲで、シニアソフトウェアエンジニアとして、バックエンドとかインフラとかやっております。
はい、じゃあ日比野の方からお願いします。
はい、はじめまして。日比野と申します。
リドルと同じく株式会社ホゲホゲのホゲホゲ事業部において、リードエンジニアの方をさせていただいております。
専門はウェブフロントエンドとモバイルアプリで、3つの辺りの技術全般を今見ております。
今回は技術的な質問、自分の方からさせていただきます。よろしくお願いします。
よろしくお願いします。
はい、ではホレソボンバさんの方からお願いいたします。
はい、ホレソボンバと申します。株式会社ホニャララで、フロントエンドエンジニアをやっております。
エンジニアとしては今3年目、ミドルエンジニアとして今回応募させていただきました。
普段はSESとして大規模なウェブアプリ開発の現場で、フロントエンドメインで携わっております。本日はよろしくお願いします。
お願いいたします。
よろしくお願いします。
では早速ですが、今ちょっとお話しいただいた内容で深掘りをさせていただきたいんですけれども、
フロントエンド開発の経験
今実際に行っている大規模なウェブ開発というのは、差し支えない範囲で構わないんですけれども、どういったことをされているんでしょうか。
はい、まず直近では、AIプラットフォームのアプリ開発の環境に入っています。
OSSのDeFiっていうOSSがあるんですけど、そのDeFiを使って自社サービスのプロダクトを開発しています。
私は担当としては、自社開発のアプリのUI UXの向上のところを担当しています。
なので、ダッシュボードの作成であったり、あとはログイン周りの認証認可の実装というところを担当いたしました。
ちなみにこのお仕事はどれくらいの期間にやられているんですか。
今ちょうど1年ですね。去年の10月から参加しています。
その時の参加のタイミングとしては、ほんと立ち上げの時からなのか、どの程度のフェーズの時からですかね。
企画段階からですね。そもそも何のOSSを使ってどういうサービスを作ろうかなというところから携わっていますね。
もともと企画の段階としては何ですかね。どういう要件があって、どういうゴールを目指されているプロジェクトだったんですかね。
もともとは社内でDX推進家のところの新しい部署ができまして、その部署でSSAを使った新しいサービスを作ろうというすごく抽象的なテーマから始まりまして、
そこから具体的にどういったOSSとかサービスを利用してサービス展開するのかっていうところを進めていきました。
基本的には企業向け、主に観光庁ですね。観光庁向けのサービスを作ろう。
それは結構キャッシュフローとして安定してくるので。そういうところで自治体向けのサービスを作ろうというので、業務効率化のツールというので、DIFIが選ばれました。
実際にDIFIで作られているのは、そのDIFIを使ってワークフローを自分たちで組んで、そのワークフローを使う権利みたいなのを自治体さんに提供するというか、売るというような感じですかね。
そうですね。それよりも権利を与えるというよりも、アプリ自体をこちらで作成して、自治体さん向けに便利なツールとして提供するという形を取っています。
ちょっと具体的に言うと、交通費生産の自動化のアプリを今、自治体さん向けにちょっと作っていますと、写真で領収書、交通費の領収書をパシャッと取ると、もうその写真を添付すると自動的に経費生産ができて、自分たちの銀行に給与として振り込まれるというワークフローを組んで、それを自治体さん向けに今展開しているところですね。
それだけを聞くと、DPである必要性があまりピンとこなかったんですけど、どういうところでDPである必要性というか、主に役立っているみたいなところってありますか。
そうですね。DPの一番の強みとして、エンジニアではない方でも簡単に自分が好きなようにワークフローが組める、Ui、Uxが優れているというところが一番の強みになっています。
なので、今交通費生産のアプリを作って自治体さん向けに展開していますが、これが自治体さんの方で交通費だけじゃなくて、例えば他の経費に対しても同じように使いたいっていう要望があったときに、自治体さんの方で自分たちで好きにカスタマイズできるので、
そこがディーフィー、カスタマイズ性の拡張性の高さというところがディーフィーの強みですね。
なるほど。てっきりSaaSみたいなものを作って、それを自治体さんの方にサブスクみたいな形で契約してもらって使うみたいなことを勝手に想像したんですけど、それよりかはディーフィーを含めた全部をパッケージングしてどうぞみたいな感じで売るみたいな。
そうですね。パッケージ化して売ってるってイメージの方が強いですね。
ありがとうございます。その中でフロントエンド的なお仕事でいうと、最初に紹介いただいたUIXのところと認証周りというのがメインですかね。
そうですね。あとは統計情報を見やすいようにダッシュボード画面を新しく作成しましたね。
その中でご自身の尺度で構わないんですけれども、フロントエンド的に一番難しかったとか時間かかったなみたいなところってどのあたりになりますか。ちょっとそのあたりのエピソードをいろいろとお伺いしたいです。
ログイン機能の実装
一番はやはりそのログイン周り、認証認可のログイン周りのところの実装が、これが非常に時間がかかりましたね。
その理由としては既存のOSSのコードに改良を加える形で、自分たちの認証認可の機能を新しく追加しているので、まずはそのOSSのソースコードをどうなっているのっていう理解が、これが2ヶ月ぐらいひたすらソースコードを読み込んで、
ログインの処理の実行ってこうなっているんだっていうことを理解しましたね。その上で自分たち自治体スタン向けなので、よりセキュリティ面で2段階認証とかセキュリティ面を強くしたログインの実装をしないといけなかったので、
結局そのログイン周りの実装だけで3ヶ月近くかかりました。
そこのログイン周りに登場したOSSだったりソフトウェアってどんなものだったかちょっと参考までに教えていただいてもいいですか。
そうですね。まず2段階認証に使ったのがAWSのCognitoを2段階認証に使いました。
元のDeFiのOSSの方ではJWTトークンでの認証方法が行われていました。
なのでそのJWTトークンの認証とCognitoの認証をこの2つを結合するときにですね、
要はうまくいかなかったんですよ。何回も何回もエラーが出て、うまくいかなかったので非常に苦労しましたってところですね。
最終的にどうやって解決されたんですか。具体的にお話いただけると助かります。
最終的にですね、正直な話を言うとちょっとこれフロントエンドの私では厳しいですっていう話をマネージャーの人と相談して、
そしたらインフラエンジニア、AWSスペシャリストのインフラエンジニアの方が早速登場してくれて、
Cognitoはこういうふうに一旦DeFiのOSSの方でログインした後にもう1回Cognitoの方に飛ばせばいいんだよっていう設計をしてくれて、
その方が解決してくれたっていうのは正直なところですね。
ログインを2回するようなイメージですね。
DeFi側でログインする際はあれですか、ユーザーのIDパスワードみたいなのをDeFi側のデータベースの方に持っていて、そこで絶望してOKで、
その後に再度同じユーザーとパスワードでCognitoにも行くみたいな、そういう感じなんですか。
同じである必要はないんですが、DeFi側のIDパスワードとCognito側のIDパスワードを結局別のデータベースで管理することになりましたね。
分かりました。ありがとうございます。ひめのさんありますか。
チーム構成と開発環境
そうですね。ID基盤の方についてもう少し深掘りさせていただきたいんですが、
設計的にはDeFiのユーザーのデータベースとCognitoで管理しているAWSのIAMみたいなものと2つID基盤がある状態ですよね。
それはどういう使い分けのされ方をしているんですか。
そうですね。使い分けとしては、DeFiっていうのがアプリを作成するっていう面と、あとアプリを利用するっていう大きく分けて2つの機能があるんですね。
アプリを作成する方に関しては、DeFiのログインと2段階認証でCognitoのログインを使って、確実に社内の人だけ、その自治体の人だけっていうのが保証されるように実装しています。
アプリの利用に関しては、別に自治体以外の人も利用するっていうケースがあるんですよね。
自治体の人が一般の人向けにアプリを作成するっていうケースもあるので、そこに関してはCognitoを通さずに、DeFiのログインだけで完結しているという形になります。
なるほど。つまり、アプリを作成する権限がある方に2段階認証をかけるためにCognitoの基盤を使っているということですね。
そうですね。作成者と利用者で認証の仕方を分けているって形ですね。
なるほど、なるほど。なんとなくわかった気がする。ありがとうございます。
このまま技術的な話に入ってもいいですか?
はい、なるほど。
じゃあ実際にそのDeFiを使ったアプリケーションについて、フロントエンドのスタックで、例えば今だとWebフロントエンドどういう技術スタックを使っているか、ざっくり聞かせていただいてよろしいでしょうか。
はい、ざっくりとフロントエンドでは、まずNext.jsで、言語はTypeScript、あとはCSSに関してはTailwindを使っています。ざっくりとこの3つの技術スタックを利用して作っています。
なるほど、ちなみにNext.jsはWebフロントエンドを作成したらどこかホスティングする必要があると思うんですが、どういうところにホスティングされているかわかりますか。
はい、AWSでKubernetesを使ったEKS上にホスティングしていますね。
なるほど、Kubernetesの中にエンジンエックスとか何かしらWebフロントエンドのホスティングシステムを作っているということですね。
そうですね、はい。
なるほど、じゃあこの今の技術選定もBomberさんのほうで選定されたという状態でよろしいでしょうか。
もちろんメンバー間で話し合った上で決めています。技術選定に関しては、僕たちが選んだというよりも元のOSSのDefiっていうソースコードがあるので、そのソースコードに沿って選んだという形になります。
理解しました。ありがとうございます。今ちょっとチームという話があったので、そのDefiを使ったアプリについてどういうチーム構成、例えばフロントエンドエンジニアご自身含めて何人、サーバーエンジニア何人くらいの流度でお聞かせいただけますか。
はい、フロントエンドエンジニアが僕含めて今2名体制です。バックエンドも2名体制。ちょっとチーム構成変わってまして、インフラ側のエンジニアが今5名います。
なるほど、面白い構成ですね。
なんでそんな多いんですか。
これも理由がありまして、やっぱり自治体向けなので、何よりもセキュリティが重視されるんですね。なので、環境、ちゃんとネットワーク上絶対に外に出ないよねっていう環境構築に非常にマネージャーが力を入れていて、
なので、開発を進めるよりもまずはセキュリティな環境を作ろうというので、インフラエンジニアが積極的に採用されて、このようなチーム体制になっています。
なるほど、なるほど。ってことは先ほどおっしゃってたプロダクトの納品っていうことについては、自治体A、自治体Bに納品するにあたってそれぞれ専用のインフラを構築しなければならないみたいな。
おっしゃる通りです。自治体ごとに専用の環境を用意して提供していますね。
なるほど。もうじゃあ契約は済んでいて、そこにもう作りに行く仕事になってるってことですか。その自治体との取引が済んでいて。
はい。今正確にはPOC、実証実験段階なので、まずはトライアルとして使っていただいて、これいいじゃんってなったら実際に実運用に耐えるような本番環境を提供しているって感じですね。
なるほど、なるほど。じゃあある程度その今はPOC中で、はじめにBomberさん含めフロントエンドサーバーの方がアプリケーションを作る。で、インフラエンジニアの方が実際に各自治体向けに納品して効果を図っている段階ということですね。
技術スタックの詳細
なるほど、なるほど。先ほどBomberさんがWebフロントエンドのログイン機能と、あとそこから入るダッシュボードですかね、を作成されたっておっしゃってましたが、それぞれWebフロントエンドとしてはざっくりとどういうアーキテクチャーを採用されたかお聞かせいただけますか。
そうですね。
本当にアーキテクチャーとして名前がなくても、こういうレイヤーがあってこういう関係くらいでも問題はないです。
はい、Next.jsで言ったらアップルーターのディレクトリ構成をしています。で、アーキテクチャー、そうですね、設計のところで結構基本的なWeb側はNext.jsで、バックエンド側はPythonで、あとはDatabase、AWSのDatabaseという基本的なWeb3層構成のアーキテクチャーになっています。
なるほど、ありがとうございます。
エンド単体に特化すると、例えばルーティングの他にも状態管理だったりとか、あとはWebアプリケーションのUIコンポーネントの構成とか、いくつかアーキテクチャーとして考えられるものがあると思うんですけど、例えばそうだな、例えば状態管理だとどういうライブラリを使われていますか。
状態管理はツースタンドを使っていますね。ZUから始まるじゃないですか。
ツースタンドって読むんだ。
ツースタンドで状態を持って、例えばそれをどうやって、どういう段階を経てWebフロントエンドのUIになるしているのですか。
状態管理のトップレイヤーで状態を管理してログインしているかどうかなどのユーザーの状態を管理して、それを各仮想のコンポーネント、ボタンなどの最小のコンポーネントのところでユーザーの状態を取得して、ボタンの非表示、表示っていう切り替えを行っていますね。
なるほど。状態としてログインしているかどうかを持っていて、それによって情報がそもそも表示できるかどうか変わってくる。
全体の設計としてはシンプルに状態とコンポーネントっていう構成という理解であったんですかね。
そうですね。
なるほど。ありがとうございます。
ちなみにコンポーネント、例えばシンプルに完全に状態と、あとは仮想ドームに特化したコンポーネントっていう分け方もあれば、
例えばプレゼンテーショナルコンポーネントみたいな、ある程度コンポーネントと処理が一層分かれているような構成もあると思うんですけど、
その辺りはどういった構成を取っているのか分かりますか。
そうですね。コンポーネントに関しては主にレンダリングと、あとAPIの取得のロジックの部分に分かれています。
なるほど。
今思い出したんですけど、アーキテクチャで重要になってくるのが、APIの取得のところで結構データ量が膨大になってくるので、
1回のAPI疎通でデータが取得できるように、フロントからバックエンドへのAPIは1回で済むけど、
バックエンドから複数のAPIを飛ばして、1回のAPI疎通で目的のデータが取得できるっていう設計にしています。
なるほど。API、データ通信のやり取りを減らすという工夫をされている。
そうですね。
いいですね。ちなみに興味が入ってきてしまった。1回のAPIリクエストで複数の違ったデータ、違った種類のデータが取得できるということですよね。
それは具体的にはどういう技術を使っているんですか。
具体的にはUseSWRっていうライブラリを使っています。このライブラリを使って、まずデータのキャッシュができるので、
フロントエンドの技術選定
一度取得したデータは一定期間キャッシュされて、APIのレスポンスが速くなります。
あとは、データベース上の複数のテーブルに分かれているデータを一つのAPIで取得することによって、
バックエンド側のSQLの処理時間を短くしたりして、レスポンスの時間を短縮しています。
ちなみに質問なんですけど、例えば5種類のAPIを呼ぶっていうのを束ねてくれるとして、
1個だけ再呼び出し、要するにキャッシュを使いたくないみたいなケースがあった場合って、どう制御するんですか。そしてどうそれを知るんですか。
なるほど。それに関しては正直今の回答になると、1つだけキャッシュを使いたくない。
そのAPIは分けますね。4本と1本っていう形に分けますね。
そうなると、要するに同じ周期で更新される可能性があるAPIを束ねるみたいな感じに使うっていう感じだと思うんですけど、
それは割とバックエンドの事情というか、その辺を知っていないと束ねられないかなと思っていて、どうやって束ねる束ねないの判断をされてるんですか。
それはもうバックエンドエンジニアとAPIどれにすると、本当地道に話し合うっていうところになりますね。
なるほど。じゃあフロントエンド側でこういうの使いたいんだけど、どれだったらまとめてもいいかなみたいな会話をされてるってことなんですね。
はい、そうです。
バックエンド側はあれですね、おいそりと変えられないですね、APIのその動きというか仕組みみたいなの。
そうなのと、なんか割とBFFとかでやるパターンとかは効くんですけど、こういうやり方もあるんですね。
アップデータを使っているので、それ自体がBFF的な役割を果たしているとも言えますね。
ちなみに、ということは基本的にこのフロントエンドの構成はほうれい草ボンバーさんのメインで技術設定されたという理解でいいですよね。
そうですね、状態管理を何にしようかとか、あとデータフェッチング、APIの取得のところどうしようかっていうのは、私含めメンバーと話し合って決めたところになります。
なるほど、じゃあもし今この全く同じシステムを一から作るとしたら、この技術構成は採用すると思いますか。
やっぱり実装してみてですね、まず状態管理に関しては、わざわざ外部のライブラリのツースタンドを使う必要なかったなっていうのが反省点としてありますね。
なるほど、なるほど。
単純にリアクトについているユーズコンテキストで状態管理する、今回のアプリに関しては十分だったなと思いますね。
なるほど、じゃあツースタンドについてはトゥーマッチなAPIを使ってたっていうことですね、ご自身のアプリ開発として。
なるほど、じゃあツースタンドだとトゥーマッチで、ユーズコンテキストで十分だったみたいなところ、具体的にはどういうユースケースでお気づきになられたか聞かせていただいてもいいですか。
そうですね、状態管理する変数がそれほど多くなかったっていうところがちょっとトゥーマッチだったなと思う理由です。
そうですね、状態管理するのがユーザーのログイン情報であったり、あとはアプリの今のアクティブかアクティブじゃないかっていうようなアプリの情報であったり、
10個程度とか10から20個ぐらいの状態管理で済んだので、
トゥースタンドを使ってちょっと複雑な実装にする必要はなかったかなというのが実際にやってみた感想です。
なるほど、いいですね、意気地が。じゃあ逆にトゥースタンド、僕実はトゥースタンドを使ったことがなくて、今回のユースケース、トゥースタンドだとどういうことが逆に利点だと聞かせていただいてもいいですか。
そうですね、トゥースタンドだと一言で言うと複雑な状態管理をするような場合、採用しても良い技術かなと思います。
要はグローバルな状態管理を100個も200個もしないといけないような時に広報の一つになってくるツールだと思っています。
なるほど、そういう意味で今回のアプリケーションでは想定よりもそれほど管理すべき状態が多くなかったという感じですかね。
はい。
なるほど、ありがとうございます。
ちなみにご自身で例えば今のプロジェクトに参画する前とか、あとはもちろん趣味プロジェクトとかでも他にどういった状態管理ライブラリーを使ったことがあるとかありますかね。
他は個人開発の時に使っていたのがユーズコンテクストです。
他の状態管理ライブラリーはごめんなさい、ないですね。業務で初めてトゥースタンドを使って、個人開発レベルであればユーズコンテクストでも十分なので、他の状態管理ライブラリーはちょっと使ったことないですね。
業務でご自身で使った経験があるっていうのも十分なんというか、今のチームのケイパビリティにあっているという意味では技術選定の材料の一つにはなるかなと思うので、それはいいと思います。
はい、じゃあ一旦前半としてはここまでとしないと思います。後半は実際に想定課題としてシチュエーションをお渡しして、この構成の時にどういう技術採択をしますかとかどういう設計にしますかみたいなところをお話しできればと思いますので、
状態管理の経験
次回もお楽しみにという形で今回は終わろうと思います。ありがとうございました。ありがとうございました。ありがとうございました。
