持続可能なフロントエンドについて

f:id:ventus-inc:20211211172607p:plain

はじめに

はじめまして、株式会社ventus Tech Leadの冬鏡と申します。現在は東大で修士をしていて、学年だと23卒という年代にあたります（大学だと量子計算の研究をしています）。この会社ではいろんなことをしてきましたが、主にフロントエンドの領域をやってきました。

今までこの会社でやってきたことを述べると、以下のようになります。

whooop!（前プロダクト）のフロントエンドの設計とコーディング
ORICALのwebフロントエンドやモバイルアプリケーションフロントエンドの設計とコーディング

会社に来る前は東京大学の駒場祭委員会や五月祭委員会で情報部門の統括みたいなことをしていました。（Wantedlyの個人ページを見ていただけるとその時の情報がちょっとだけ載っています。）現在やっていることは、ORICALの運用を効率化するための社内ツールの開発ですが、全体的にフロントエンドの設計や新規技術の導入みたいなことをやる傾向があります。

今回のブログでは、僕がずっと問題意識をもっていて、かつての会社の勉強会のタイトルにもした「持続可能なフロントエンド」について少しだけ書いてみようと思います（残念ながら勉強会そのものはコロナ禍の前に打ち切りになってしまいましたが…）。

フロントエンドの難しさ

フロントエンド、という分野を僕が最初に総体として認識し、活動をはじめたのは僕が大学2年生の頃、2017年の前半でした。そのときから5年が経過しようとしており、フロントエンドと呼ばれる領域は大きく変化しました。

その変化は進化と呼べるものであった一方、（『人月の神話』*1にもあるように）「本質的な難しさ」はほとんどそのまま保存されており、今でも多くの人が頭を悩ませていると思います。むしろ、当時よりもツールチェインやライブラリ、フレームワークなどのエコシステムが発達した分、その難しさは顕在化しているとみていいでしょう。つい最近JSConf JPが開催されましたが、そこでもいくつか「本質的な難しさ」に関わるような講演が採択されていました。

jsconf.jp

ではフロントエンドにおいて「本質的な難しさ」（そして、普遍的でもある難しさ）とはなんでしょうか。それは、設計であったり、人材の育成、開発手法、組織体系であったりといったソフトウェア開発プロジェクトであれば誰もが避けては通れないものから、「エコシステムの変化への追従」といったフロントエンドで特に起こりやすいものなど、多岐にわたります。

この会社で最初に携わったプロダクトであるwhooop!の開発では、設計の大切さを感じる出来事が多く、whooop!をリニューアルしたときには開発手法が、ORICALのwebフロントエンドを開発したときにはエコシステムの変化への適応、モバイルアプリフロントエンドを開発したときには人材がそれぞれ重要なテーマでした。そして、現在ventusでは組織体系を刷新し、より「スケーラブル」な組織を目指そうとしています。

では、スケーラブルな組織にとって、開発組織がフロントエンド領域でできることとはなんでしょうか？その答えの一つは、「持続可能である」ことだと僕は考えています。

「持続可能」とは何か

ある程度の経験年数（フロントエンドだと多分1,2年？）のある方は「技術的負債」なる概念を（自分の言葉で明確に言語化できなくとも体感している方が多いと思います。技術的負債を素朴に言語化を行うとすれば、「開発しているうちに、段々と新規機能の追加などが難しくなっていき、時間がかかるようになっていく現象」のことでしょう。この会社でも、この会社に来る前の大学の学園祭の情報部門でも、様々なプロジェクトが「負債」にゆっくりと変貌していく様子を僕は目の当たりにし、それがコンウェイの法則*2よろしく、対応する組織をゆっくりと「老化」させていくのを見ていました。（この話はそれ自体がケーススタディとして面白いという指摘をされたことがあるので、また別の機会に書くかもしれません）

幾度かのプロジェクトを経て、この「技術的負債」は、それ自体がより普遍的なケースの「開発プロジェクト版」なのではないかと思うようになりました。それは、「環境の変化に対する不適応」です。僕はかつて学園祭の組織で仕事をしていたとき、「コードを読むだけで書いた人を当てる」という特技を持っていました。これはかなり特殊なケースだと思いますが、開発されたソフトウェアを注意深く観察し、メタデータなども含めてひもといていくと、「コードが書かれた環境」をまるで地層のように紐解くことが可能でしょう。そして、「コードが書かれた環境」と「現在のコードを取り巻く環境」が食い違い、「不適応」が引き起こされるとき、それが技術的負債の発端になるのではないかと考えるようになりました。というのも、コード自体には問題はなくとも、時間が経過するだけだったり、極端なときには「書いた人が賢くなる」という完全な外部要因で技術的負債になるケースを観察したためです。

「不適応」は（開発に限らず）問題を引き起こします。そして、「式年遷宮」と揶揄されるような（とても痛みを伴う）リプレースの引き金になったりします。式年遷宮はまだマシで、同一性をたもっていないような変更もたくさんあるでしょう。そういった状態に陥らないということ、「常に適応し続ける」ことを僕は「持続可能である」と考えています。

「持続可能」のために

正直なところ、この部分は書きかけといいです。といっても僕自身「持続可能にする」ために何ができるのかをまだ模索している途中だからです。とはいえ、やっていることはいくつかあります。

例えば、社内で有志をあつめて（あえて）業務とは直接関係なさそうだけど有用な知識に関する輪講を開いたりしています。これは、適用するためには基本的に今までやってきた延長線上とはやや異なる方向性の知識が必要になることがあるためです。現在はマイクロサービスについての本をそろそろ読み終えようとしており、次の題材を探し中です。

また、現在携わっているプロジェクトでも、長期的に開発者体験をブーストするような「experimental」なサブプロジェクトに対して少しリソースを投下する、みたいなことをしています。（https://github.com/facebookexperimental のパクリです）プロダクトのリファクタリングやテストの充実だけでなく、プロジェクト管理方法を変えたり、周辺ツールの開発や、新たな開発手法の提案とそれに移行するためのロードマップなど、いろいろなことを試みています。