組織と技術選定

本稿は以前 【mediba社合同勉強会】コネヒトマルシェオンライン「祝書籍出版！両社のフロントエンド事情大公開」 - connpass で発表した内容についての補足となります。

発表内容について

現代の選択肢が多くある Web フロントエンドにおいて、これまでどのような選定をしながらやってきたのか？という話です。スライド内では年別でその年のトレンドなども合わせながら社内で導入した技術やその経緯などについて説明しています。

選定時の組織の構成やメンバーの技術スタック、現行システムなどを考慮した上でどういった意思決定をしたかなど、そういったコードからは感じづらい部分での共有知を作ることができればいいなと思いオープンなイベントで発表しました。

本稿の内容

スライド上の文章だけでは「◯◯を使っています」という部分にフォーカスされており、当時どういう状態にあったのか？という面の説明が上手く伝えられていないためその部分を埋めようと思っています。イベント当時は喋りながら発表したため聞いてくださった方にはある程度お伝えできたんじゃないかなと思っていますが、あとから気になって見てくれた人には伝わらなさそうだなという気が今になってしてきたのでアドカレの枠を埋めるという目的も兼ねてこのタイミングで書くことにしました。

(2016 〜) 入社時

• 一応 MVC (Backbone) だが、C と M の使い分けはハッキリしない
• import/export などはなくて、gulp 実行時にファイル結合するのみ
• ESLint などは導入しておらず書き方などが統一できていなかった

当時はこれでも割と普通だったと思います。今となってはそんなことあるんか？くらいの内容ですが。時代的には jQuery から Backbone, Angular1 などに移行したあとのタイミングで React や Vue のビッグウェーブがくる直前、といった感じでしょうか。

上記のようにフロントエンドアーキテクチャが洗練されアップデートされ、新たなフレームワーク・ライブラリが登場していく中でツール群も目覚ましい進化を遂げていました。代表的なものでいえば webpack や Babel です。ES 最新仕様への追従やバンドルして配信する、といったことが容易に実現できる世界になり始めた年でした。

また、今後メンバーが増えていくことを想定したコーディングスタイルの定義とその仕組み化などに注力した年でもありました。しっかりと土台を整えた上で次に繋ぐことを意識していた気がします (多分)。

(2017 〜) React を導入した

2016年はとにかく基盤整備！という気概で取り組んでいたためコードそのものの秩序、みたいな部分は特に解消しないまま終わりました。その上で2017年でどれだけテコ入れできるのか？というのがテーマです。

Flux が本格的に流行り始めたのがこのあたりだったと記憶しています。また、Flow や TypeScript で型付けようといった記事も多く見られるようになりました。社内でもその辺の流行を取り入れたり、いよいよ技術スタックを Backbone から React に変えていく、といった動きをし始めました。ここから facebook/flux と Flow もあわせて使うようになりましたが今となっては Hooks (useContext & useReducer) や TypeScript を選ぶようになったのでこの辺は先見の明がなかったなと反省しています。

ただ、このタイミングで React や Flux を使い始めたことは大きな一歩でした。それまで複雑なクライアント側のロジックを一生懸命 $.on で紐付けていた作業がなくなりコンポーネントという単位で扱えるようになったことや Flux によるデータフローの単一化が行われたことで開発のしやすさはグッと上がりました。チャレンジしたこととそこから設計思想などを学べたのはチームとして大きな収穫だったと思います。

(2018 〜) 習熟度を上げる

使い始めた技術たちをより手になじませながら開発体験をよりよくするフェーズに入りました。

大枠は変えずに周辺のツール群などについての学習、試行錯誤を繰り返しながら「どうすればもっと効率よく開発できるか」「よりよいコードが書けるか」といったことを考えていました。また、この辺から基本的には React を使って新規アプリケーションを実装していく流れが生まれました。1年間書いてみてメリットが感じられたこと、jQuery で書いていた時に比べてちゃんと設計がそのままコードに落ちていること、などが大きな理由です。

ただし jQuery を完全に使わなくなったわけではなくて静的な LP だったりなどは jQuery を使うものもありますし、なんなら何も使わないという選択もありました。React (JSX) をコンパイルするために Babel やら webpack やらを引っ張り出してきて環境構築するメリットがあるのか？みたいなケースもあって、その辺は適材適所だなと今でも思っています。もちろん Scaffold から生成するという手もありますがそもそもほとんどコードも書かない、ファイルも1つで済むような規模のものに対して大量のツールを毎回使う気にはなれませんでした。ただコード圧縮はしたいなとかは思うのでそういう時は Parcel とかのゼロコンフィグなバンドラーを使うときもありました。

あとはコーディングスタイルの社内標準化とか Greenkeeper でバージョンアップ自動化とかをひとりでちまちまやってました。飛んでくる PR が多すぎて精神的に追い込まれていくのが辛かったので、今から始める人は Renovate がオススメです。

(〜 現在) 最近の開発スタイル

スライド内では 2019, 2020 は別セクションでまとめているのですがそれぞれそんなにやってることは変わらないので本稿ではまとめて紹介します。

過去に比べると (新たなライブラリ・ツールの台頭) そこまで大きな動きはないものの、環境は着実によくなっていってる感じがすごくします。去年だと React Hooks が使えるようになってより実装が楽になり、今年は Prisma が ORM としてリニューアルしていてしかもなんだか良さそうなのでバックエンドの JS 実装も変わってきそう、など。既存をアップデートすることで利用シーンが広がったりプラットフォーム (ブラウザとか) の進化に合わせてやれることが増えたりして、最終的にはそういった技術の進歩をサービスに反映していけるといいなと (現状うまく活用できている気はしない、PWA とかね)。

React Hooks が出てきてからは Class Component で書くことはほぼなくなりました、Hooks で書くのは本当に楽でよい。あとはディレクトリ構成をもっとイケてる感じにしたいなと思ったので Atomic Design の思想をインプットしてそれを実装に落とす、みたいなことをしました (Atomic Designを実践して得た学びと失敗 - コネヒト開発者ブログ)。未だにこの考えが役立っているのでやってよかったことの1つです。

今年に入ってからはチームとしてかなりパフォーマンスも気にするようになってきました。lighthouse-ci などを使って定期的に改善していくためにどうするか、などは結構議論してたりします。

組織に合わせる、情報は薄く広く拾っておく

上記で述べたディレクトリ構成の設計など、大きく技術スタックが変わらないのであればある程度設計にも型をつけてしまうのも手だと思います。現状、何チームもあるような大きな組織ではなく、ひとりで複数サービスを見ることが当たり前なのでそのたびに「じゃあ今回は Vue で次回は Angular 使おう！」とかやっていたら大変なことになってしまいます (チームごとに好きな技術スタックで攻められるようになったら全然アリだと思う)。とはいえ思考停止で量産し続けるわけではなく、こまめなチューニングやイケてない部分の改修なども入れつつ前進するようには意識しています。

本番投入について思うこと

スライドのまとめ部分の補足。

Web や関連技術に関する情報

フィードに流れてくる情報が多いので社内や社外の方とのフロントエンドランチを通して上澄みだけでもちゃんと摂取しておくことで「これは前に見たことがあるぞ」みたいな体験を増やすようにしています。こういう時に使えるライブラリって何かあったっけ？といった時に手がかりがあるかないかでその後の調べ物にかける時間が短縮できます。似たようなライブラリが複数あったりすると比較とか出すのも大変ですし。

技術選定における判定基準

個人の興味で◯◯使いたい、という理由だけで本番投入するんじゃなくて使うことで事業・組織にどういい影響を与えてくれるのか？という問いから入ったほうがいいと思います。個人的にやりたいこととかは自身の個人開発の環境とかのほうが自由が効くし、捨てたくなったらいつでも捨てられるので。