Fringe81のリレー記事ということで、たまにはお仕事での意思決定の話でも書いてみようかと思います。
僕はここ4年ほど、フロントエンドの技術選定をしてきましたが、今回はその中でも「言語」に関して、どういう軸を作ってやってきたのかということを振り返ってみたいと思います。
(生産性が高いもの選びという観点は前提だと思っているので本記事ではあえて除外します)
で、何を大事にしていたのかなーという事を改めて言葉にしてみると、僕は技術選定を通して、「壁のない組織」 というイメージをずっと追っていた気がします。
今日はその視点で各技術を入れてきた目的と結果を書いてみたいと思います。
すでに技術選定している方や、これからやりたいなーと思っている方の参考になればうれしいです。
ES5時代
よくうちの会社では社内全kaエンジニア勉強会を実施しているのですが、その時に一つ感じていた大きな壁がありまして。
僕にとっての長きに渡る強敵となるもの、**「言語の壁」**であります。
Fringe81では7年ほどバックエンドはScalaを使っての開発に注力してきました。
Scalaは半端じゃなく豊かな表現力を持っていて、機能と拡張性に優れた言語(個人の意見です)である一方、みんなで思い思いに実装するとあっというまに一貫性がなくなります。そんな性質もあって社内勉強会ではScalaを理解して、意識を合わせてOOP、FP、DDDなんかを実践しよーというトピックが盛り上がっていました。
かたや、簡易で、コンパイラなどなく「まず動かそうぜ」的なJavascriptさん(個人の意見です)。
当時、なんとなくフロントエンド開発者の負い目というか、理論を理解しても「実践するための環境(言語)」が少ないなと感じていました。。
また「初心者はフロントエンドから」みたいな登竜門的扱いもイヤ！とも強く思っていたものです。
ざっくり言うと、 フロントエンドの矜持 を確立したかったわけです。
その中で個人的にScalaやHaskellを学びながらフムフム＆悪戦苦闘。
フロントエンドの側からもScalaメンに有用な知識を提供したり、共通世界観をもつことで会話が弾むようになったり、そんな言葉や知識の自由貿易を実現したいなーと夢想しておりました。
ここからしばらくは JSメンがScalaメンと同じことばを持つための技術選定工夫バトル を繰り広げることになるのでした。
ES6(具体的にはbabel) 2014〜
ES6に関しては、classの登場によってデータモデルを専用構文とセットで意識できるようになったり、アロー関数の登場によりArrayの関数がシンプルに書けたり、constや(ES6では無いですが)immutable.jsの登場によって不変データを駆動させやすくなったりと、思いをコードに込める時の表現力が格段に上がりました。
勇んでScalaメンにJSの進化っぷりを共有すると、、
「へぇ、進化してますねぇ(僕にとっては当たり前のことが多いですが)」。。
coolな反応。。
なんか悔しいっす！🔥🔥🔥
しかしモジュールロードとか開発ツールも充実してきて、フロントメンの夜明けは近いぜよ！と自らに言い聞かせ修練を続けるのでした。
TypeScript 2015〜
当時、若いメンバーと仕事をすることが多かったんですが、レビュー時にこんなコードをよく見た気がします。
function f(bool) {
return bool ? 10 : "foo";
}
呼び出す側からすると、返り値の型が曖昧で扱いにくいコードです。
そんな時、フィードバックをするのですが
「JSにも型というものが一応あってだね...云々カンヌン」→「はぁ、なんとなくわかりました」→ (しばらくすると似たようなコードが上がってくる)
うーん、やはり具体的に型を可視化して日常的に触れていくことと、それによるメリットを享受したり失敗を経験しないとイカンなと。
そこでTypeScriptの登場です！
既存サービスの４人フロント開発チーム、段階的にTypeScriptにリプレースしながら、学習で一定の理解が進んだメンバーからTSコードに触っていくという流れを作りました。
これにてバックエンド・フロントのエンジニア関わらず、全てのエンジニアが「型」を扱っている、という状況が出来上がりました。
このとき、僕らの組織は**「型の壁」**を崩壊させることができたのです(力説)！！
また、JSをバックグラウンドとして持っているメンバーには「コンパイラがコードチェックしてくれるっていいですね！」という言葉をもらうこともありました。
僕はその昔、Javaを触っていた時はコンパイラのせいで実行までたどり着けなくて苦しい、、と思っていた時期がありました。
型が当たり前にある世界にいると、その良さに気づけないこともあるかと思いますが、最初からありがたいと思えるのっていいなと思います。
TypeScriptはコンパイラ設定で型判定を甘くしておいて、段階的に型判定をキツくすることが出来たので、「必要なチェックを必要なだけ導入する」ということが出来たのもよかったのかもしれません。
Elm 2016〜
TypeScript導入までの流れにより、フロントメンのコード表現力はだいぶ高まり、少しはバックエンドとフロントエンドの壁はなくなってきたように思います。
しかし、またしても勉強会の場。Scalaメンは「関数型プログラミング」とそれにまつわる概念の議論を白熱させていました。
僕は思っていたものです。「もう大概は大丈夫、俺たちは同様の概念をシンプルに扱う術を手にしているのだから！」と。。
ちらりとフロントメンを見やります、、、、、ね、眠そう...！！！ ガーン😫
いろいろとリサーチをしていくと、「現状のコードのどれが関数型的なアプローチなのか今イチわかんない」「しらない言葉がでてくる」「脊髄反射的についていけないので徐々に置いていかれる」などなど。
うーん、やはり具体的に関数型を可視化して日常的に触れていくことと、それによるメリットを享受したり失敗を経験しないとイカンなと。。。
奇しくも2016秋、我々は新しいサービスを立ち上げる機会に恵まれました。
そこで俺内セレクションを幾度も繰り返して選び抜いた精鋭、純粋関数型言語Elmの投入を画策したのです。
List.headがMaybe型を返すその徹底ぶりにシビれて憧れつつ、ES->TSの時のような地続き感は全くなかったので、導入に至れるかは全く未知のチャレンジでした。
ちゃんとサービス完成にこぎつけられそうかの検証を重ねましたが、もう一つ重要な戦いが。
みんながElmに魅力を感じてくれるのか！？
そして僕は全エンジニアの前で50枚くらいのプレゼンテーションを披露しました。さらに「しくじったら俺が全てリプレースします！」という決意表明。
(こんなプレゼン)
さて、結果は。。
暖かく受け入れられました！
「やってみたい！」と鼻息荒めに言ってくれるメンバーもチラホラ。。。😂
なんて素敵な仲間なんだ！！！と胸を熱くしたのでした。
カリー化、パターンマッチ、直和型、型アノテーションといった「ことば」の浸透もしていきましたし、純粋関数のあつまりでアプリケーションをつくる、ということを理屈だけでなく、まさしく体得できるような環境が整ったと思います。
(若手が送ってくれたファーストインプレッションレポート)
２年かけ、今うちは10人以上のメンバーが業務でElmを書いています。
ちゃんと文化として根付くに至ったのではないかと思います。
いまでは僕を介さずにハンズオン勉強会を運営していたりします。
言語の壁は破れたのか？
さて、ここまで色々なものを組織にぶち込んできました。
成果はどうだったんでしょうか？
勉強会で、Elmを扱っての関数型アプローチの話をしてくれる仲間もチラホラ出てきました。
また、この2年、6人のエンジニアがフロントエンドからバックエンドへのスムーズな領域スイッチを果たすに至りました。
いまスイッチ準備中のメンバーも何人か控えている状況です。
Scalaメンのトレーニングをしているメンバーに習得状況をヒアリングして見ると、「みんながつまづくポイントを鮮やかにクリアしていきました」的な話を聞くことができ、
スイッチを果たしたメンバーも「当事者なんでよくわかりませんが(笑)、移行は苦ではなかったです」的な話をしてくれました。
長い時間をかけた結果でもあり、これはジンワリ嬉しい結果でした。
結論、ある程度の「言語の壁」の崩壊は出来たのではないかと思っています。
「やりたいこと」がベースにあって、その時に「最適な道具の扱い方を素早く習得する」ことのハードルは下げることが出来たと思いますし、領域や言語を跨いだコミュニケーションもある程度は実現出来たのではないかと。
これからは、仲間の熱意ある「やりたい！」も応援し、実現できるような環境も作っていきたいなと思います。
人数が増えれば新たな目に見えない壁はどんどん生まれてくるもの。
これからも破壊し続けていきたいなと思っています。