見出し画像

変更容易性を高め、長期的にユーザへ価値提供したい。テックリードが見据えるフロントエンドの未来

Progate

Progateでは「プログラミングを学ぶ」以外の部分で詰まってしまう人を一人でも減らすため、学習体験にこだわっています。

今回、フロントエンドの立場からユーザーのことを徹底的に考えながらプロダクトの改善を進めているテックリードの舘野に、現在取り組んでいる課題や今後の展望について話を聞きました。

舘野 真(フロントエンド テックリード)
ぐるなびにてフロントエンドエンジニア、メドレーではフロントエンドからバックエンド開発を担う。現在、Progateではフロントエンドエンジニアとしてテックリードに従事。

Progateならではの難しさの一つは、画面構成の複雑性

ーProgateは複数言語のレッスンをブラウザ上でコーディングできることが強みですが、フロントエンド側での仕組みはどうなっているのでしょうか?

元々は1つのモノリシックなアプリケーションで構成されていたんですが、現在は分散型のアプリケーション構成にする方向で取り組んでいる最中です。具体的には、「Progateの演習画面」と「演習画面以外」とで分離しようとしています。両者は画面の複雑性が異なり、アプリケーションとして質が違うものなんですね。なので、技術スタックから大きく切り分けても問題ないという判断のもと、進めています。

使用している技術スタックに関しては「演習画面」も「演習画面以外」も基本的には同じで、どちらもReactアプリケーションです。演習画面の方がより複雑性があるのでReduxによる状態管理やWebSokectでの通信などの要素が含まれます。バックエンドとのやりとりについてはOpenAPIを用いたスキーマ駆動開発に取り組んでいます。

UIコンポーネントに関する部分ではCSS in JSのライブラリとしてstyled-componentsを利用しています。

また、テストに関しては、ユニットテストはもちろんインテグレーションテストも漸進的に取り組んでいます。具体的にはJestやTesting LibraryによるReduxの状態やReactコンポーネントに対するユニットテストやインテグレーションテストです。

ーフロントエンド観点で、特徴的なProgateの実装や設計はありますか?

いろいろあると思いますが例えば、画面構成上の複雑さですね。コースによって画面の構成が変わったり、そもそも同じコースでも、「この部分をハイライトする」など細かい単位で扱いが変わるので、フロントエンドとしてバックエンドと連携をとりながらどのように扱うか、というのが難しさとしてあります。また、エディタ、ターミナル、ファイルツリー、プレビューなどのコンポーネントとそれらを連携させてユーザの学習体験をWebブラウザ上で実現することが求められる部分も特徴的だと思います。

ーフロントエンドの開発を通して、現在達成したいユーザー状態、システムのゴールはありますか?

二つあって、一つは先ほど挙げた、演習画面をアプリケーションとして分離する取り組みを完了させることです。
分離する理由の一つは、「演習画面」と「演習画面以外」とで、同じ技術スタックで構成する必要性がなくなるというメリットがあるからです。例えば「演習画面」で今の技術スタックとは全く異なるものを追加したり削除したりするとき、「演習画面以外」の範囲にとらわれずに変更が加えられるようになると、作業が容易になります。

もう一つは、具体的な形としてあるものではなく個人的な思いの部分が強いですが、ユーザーにプロダクトとしての価値提供を安定的にすることです。
例えば、「Progateで新しい言語のコースを提供してほしい」「異なる構成の演習体験がしたい」といったユーザーの要望があってそれをプロダクトとして実現したい場合、いかに早く開発してリリースできるのか。さらに、ユーザーからのフィードバックを受け、それを改善してリリースするサイクルを回していくようにしたいですね。
なるべく変更容易性を極限まで高めて、外的な要因に左右されずに、価値提供し続けられる状態を目指しています。

目指すは“一貫性のあるUIを提供する”仕組み

ー他に取り組んでいる課題を教えてください。

「一貫性のあるUIを提供する仕組み作り」に取り組んでいます。分散アーキテクチャを進める上で、分散されたものに対して横断的に一貫したUIを提供する仕組みがないと、ユーザー体験が損なわれてしまいます。そうならないよう、一貫したユーザー体験を提供できる、具体的には社内で利用するUIコンポーネントライブラリを作ろうとしています。

簡易的なイメージ図

現在、「演習画面」と「演習画面以外」でフロントエンドのソースコードを明確に境界づけるように進めています。また、それらに対して横断的に一貫性のあるUIコンポーネントを提供するようなものを作っています。以前から近しいものはあったんですが、明確に仕組みとして機能するように整えていきました。これはnpmパッケージとして提供するようにしていますが、UIコンポーネントライブラリとしての信頼性を高めるために、Chromaticによるテスト含めUIテストを実施するようにしています。

UIコンポーネントの整備の一環でデザイントークンの整備も進めています。色や余白、フォントなど複数のコンポーネントやテキスト要素などUIを構成する最小単位の値を整備して出来たレゴブロックのようなものを組み合わせるだけで、画面を作ったり修正したりすることができるので、スピーディーに開発ができます。さらに、一貫したUIをユーザーに提供することが可能になります。

また、プロダクトのUIに関する共通言語として浸透していくことで、デザイナーやエンジニアなどプロダクト開発に関わる人々のコミニュケーションの助けになることを期待しています。

変更容易性を保つことで、将来の課題に備える

ーテックリードとして設計や実装を進める際に最も意識されている点を教えてください。

なるべく長期的な目線で、変更容易性が保たれているかを意識しています。
事業上の優先順位がどう影響してくるのか予想する努力もするべきですが、全てを予測するのは難しいので、どんな状況になってもなるべく対応可能な状態に保つことを常に意識したいなと思っています。

ーそのように意識するようになったきっかけはなんですか?

僕がエンジニアとして失敗を繰り返してきた経験に拠るところが大きいですね。
過去の経験として、変更したくても、テストがないので怖くて変えられない状況であったり、変更した結果として予測していなかった不具合を生んでしまったり。変更することが難しくなってしまった状況で取りうる選択肢は限られてしまって、最終的には全面リニューアルのような選択肢しか残らないこともあると思います。もちろんリニューアル自体が悪いわけではありませんが、それしか取りうる選択肢がない状態にしてしまうエンジニアリングに対して、未熟さを感じていました。

選択肢を減らさないにはどうしたらいいか?と考えた時に不足していたと感じたのが、変更容易性が保たれているかを長期的な目線で見ることだったんです。

プロダクト開発の課題を、自分ごとと捉えられるのが醍醐味

ー舘野さんが考える、Progateならではの難しさ、面白さはなんでしょうか。

先ほど話した画面構成の複雑さは、フロントエンドのエンジニアとして挑戦しがいがあると思います。

また、僕自身がプログラミングを独学でやってきたこともあり、会社のビジョンや方向性に共感する部分があったんですね。僕が一人で悩みながら勉強してきた過程を、少しでも軽減させるようなプロダクト開発は、エンジニアの人数が不足している日本社会にとって必要な取り組みだなと感じたんです。

今でもプログラミングを学ぶことに対する難しさ、壁の高さを感じています。どうすれば効率よく新しい言語を習得できるのか、新しい技術をもっと早く自分のものにできるのか…というのは常に感じていて。
40歳という年齢が見えてきた時、現役でいられる時間は限られているから、学ぶことを効率化してプロダクト開発に反映していくしかないと思ったんですね。だからこそ、効率的に学べるプロダクトを開発することは、まさに今自分ごととして課題感を持って取り組んでいます。

ー今後、どのような方と一緒に課題解決に取り組んでいきたいですか?

僕個人としては技術面よりも、プログラミング学習のプロダクト開発に対する想いを重視したいですね。
受託開発ではなく、自分たちで作るプロダクトなので、”想いを持っている方”が長期的に深く関わっていただけると思います。
より良いプログラミング学習サービスにしたいという想いを持って、そのためにはどうすべきか自問自答を繰り返し、出てきた課題に対して丁寧に取り組む人が、プロダクトを推進できると考えています。

Progateに関する情報やMeetyはこちら

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!