「『はたらく』のインフラ」に近づく実感。株式会社タイミーで追求するプロダクトエンジニアの在り方

＼15年超の実績を持つレバテックが運営／

ITエンジニア就活支援サービスに登録する

 

苦難の末に、待望の機能をリリース。ユーザーからの期待がモチベーション

――入社後の業務についてお聞かせください。

江田　現在はバックエンドエンジニアとして、Ruby on Railsというフレームワークを使ってWeb APIの開発をしています。これまでフロントエンドも担当することはありましたが、業務の9割はバックエンドですね。

『タイミー』には、アルバイト求人と求職者をマッチさせるマッチング領域と、請求書の発行や出退勤の仕組みなどを司るスポットワーク領域が存在するのですが、私はスポットワーク領域の方を担当しています。そこでは出退勤機能の改善や、給与計算の仕組み作り、勤怠の管理などを中心に取り組んでいます。約10人ほどのチームで構成されていて、『タイミー』にとって優先度の高い課題から対応するような形です。

創業期は各エンジニアがすべての領域を見ていたのですが、事業やチームの規模が徐々に大きくなるにつれ、特定の領域に絞り込むようになりました。1つの領域により専念できるので、ユーザーが何を求めているのかを各フェーズごとに深く探求できるようになったと思いますね。
 

――創業期と分業制になった現在を比べて、何か変化はありましたか？

江田　本質的な部分は変わらないのですが、各フェーズごとでユーザーが感じていることにもっと深くダイブしていき、「本当に求めているものは何か」や「より理想に近い体験って何だろう」というのを、各プロフェッショナルのチームが探求できるようになったのは、良い点だなと思います。もちろん以前もそのような取り組みはしていたのですが、すべての体験を1人のエンジニアが頑張ってみている状態だと、1つのフェーズに専念できるリソースにやはり限界があって。より磨き込むとか、 より理想の世界に近づけるということは、最低限クリアしているレベルにとどまっていたんですよね。

実は『タイミー』は、世間的にはただのマッチングプラットフォームに見えていても、労働に関連する法律や規制も含め、働くことに関する本当に広範なものが複雑に絡み合っていて、そこをクリアしながら運営しているんです。タイミーのエンジニアとして働くには、そうしたドメインを深く理解することが大事で、さらに理解したものをどうシステムで表現するかというのが、 エンジニアの腕の見せ所なのかなと思っています。
 

――ちなみにバックエンドとフロントエンド、両方やってみて感じた違いなどあれば教えてください。

江田　そうですね、バックエンドエンジニアはデータベースとの距離がより近くなるので、データのモデリングや設計がとても大事になるんです。なので、まずは適切なデータ設計をできるようなることが求められます。そのためにも、世の中で起きている経済活動や、『タイミー』で起きているイベントを言語化して、適切にシステムに落とし込む過程が必要になってくるんですね。

よく「フロントエンドはクライアントで、バックエンドはサーバー」と言われるのですが、クライアントから受けた注文をサーバーが返す、という関係性になっているんですね。内部がうまく作れていないとフロントエンドに良いアウトプットは渡せないので、責務としてはバックエンド側の方が事業の根幹を担っていると個人的には思います。

フロントエンドだと、思い出に残っているのはUIの刷新プロジェクトに参加したときですね。人は見た目に大きく左右されるというのを改めて理解できたプロジェクトでもありましたし、UIを変えた後に社内外からポジティブな声をたくさんいただけたのは、フロントエンドならではの魅力だと思いました。
 

――これまでに、業務で大変だったことはありましたか？

江田　グループ機能の開発が1番大変でした。グループ機能というのは、事業者側が特定の条件でワーカーをピックアップしてグルーピングし、その求職者に対して限定求人を公開できるという機能です。この機能を作っていたときに、『タイミー』のアプリを開いても求人が公開されず、サーバーが落ちてしまう障害が発生したんですね。内部処理で負荷がかかりすぎてしまい、データベースがパンクしてしまったのが原因だったのですが、それを解消するのに苦心しました。

データベースにはインデックスという、目的のデータにたどり着きやすくするための仕組みがあるのですが、これを適切に活用できていないとデータベースに負荷がかかってしまうんです。なのでまずはインデックスを愚直に見直して、追加したり削除したり、試行錯誤を繰り返してなんとか解消しました。
 

――何をモチベーションにして乗り越えられたのでしょうか？

江田　「自社の条件に合ったワーカーをよりマッチングできるようにしたい」という事業者側の要望に応える待望の機能だったことが、一番のモチベーションになりました。この要望は営業担当を通して耳にしたり、エンジニアである私にも直接リクエストいただいたりしていた機能だったので、その必要性はひしひしと感じていました。

それに加え、タイミーとしては珍しくリリースするタイミングを宣言した上で開発していた機能でもあったので、「絶対に納期に間に合わせたい」という強い思いもありましたね。
 

――タイミーだからこそ得られる経験や、仕事の醍醐味は何ですか？

江田　ある機能を作る時に、タイミーではtoBの開発（法人ユーザー向けの開発）とtoCの開発（個人ユーザー向けの開発）の両方が必要になるんですよ。いわゆるツーサイド プラットフォームというものですね。このように事業所側の開発とカスタマー向けの開発のどちらも経験できるのは貴重な経験だと思いますし、両者の考え方や考える内容の違いも実感できるので、その違いも個人的には面白いです。

例えばワーカーの方が事業者よりも多い状態なので、先ほどのエピソードのようなパフォーマンスチューニングに関する技術というのは、toC開発ではより顕著に求められます。一方toB開発では、どうやっていろんな事業者の課題を1個のアイディアで解くといった力をより強く求められるので、「いかに事業の差分を吸収して、より良い洗練されたプロダクトを生み出していくか」といったことがtoB側の醍醐味になってくるかと思います。

その他には、事業者からの声がフィードバックとしてもらえることも、タイミーならではの経験だと思います。タイミーに入社するまでは、「企業の中の人はあんまり自分の感情を外に見せることはない」と思っていたのですが、『タイミー』を使った企業から「人が来てくれて助かりました」と喜んでもらえると、事業主も1人の人間なんだなと改めて実感がわきました。そうした経験ができるところにも、仕事の楽しさを感じます。

さまざまなバックグラウンドを持った事業者が『タイミー』を利用しているのを見ると、プロダクトの開発がうまくいっているなと感じられますし、今後もこの良い状態をキープしながらプロダクトを発展させていきたいですね。