未知のプログラミング言語を導入してでも、成したかったエンジニア組織づくりへの挑戦
こんにちは。Fringe81 note チームの横山です。
今回は、Fringeのエンジニア組織づくりのお話です。
Fringeの技術開発本部長である関が挑んだ「壁のないエンジニア組織づくり」について、関に振り返ってもらいました。ぜひ、ご覧ください！
（関の紹介は以下の記事をご覧ください）
＋＋＋
プログラミング言語が境界性となり「技術の壁」が生まれる
こんにちは。Fringe81の関です。
僕は最近、技術開発本部長として、組織の目標管理や制度整備などを仕事としていますが、これまでの数年はフロントエンドのスペシャリストという役割を担ってきました。
スペシャリストというと「技術の細かいことがわかる専門家」という風に見られることが多くて、それは間違っていないのですが、僕が意識していたのは「組織をよくする」ことでした。つまり、技術開発本部長であったり、スペシャリストであったりと役割は変わっても、大事にしていることは変わらず「組織」であったのです。
今回は僕がスペシャリストであった時の話をします。特にこだわりをもっていた仕事のひとつに「プログラミング言語選定」というものがありまして、その仕事を通して意識していたのは、やはり「組織をよくする」ことでした。
一般的に、プログラミング言語選定時に重視される項目として、よく耳にするのは「問題が少ない、信頼性が高いもの」「みんなが使い慣れていて生産性が高いもの」「枯れていて安定しているもの」などがあるかと思います。当然なのですが「道具としての機能性」の部分です。
では、僕の場合ですが、「道具としての機能性」に加えて「組織の中での機能性」「情緒性」「タイミング」ということも強く意識をしています。
具体的には技術を通してみんながコミュニケーションしやすい、仲間と一緒に研究できる、奥行きがあって好奇心を刺激される、今の我々にあっている、といったことです。
せっかく技術を選ぶ機会があるのであれば、「良いもの」であることはもちろん「うれしいもの」であって欲しいなと思うのです。
今回のお話しは、「プログラミング言語で壁のない組織を作る」という５年ほどに及ぶ仮説検証に関するものです。
「壁」とは何でしょうか？集団で仕事をしていると部署の壁、階層の壁などができることがあると思います。
エンジニアの場合、扱う技術にJavaとかRubyとかハッキリとした名前がついているので、この境界に「技術の壁」というものができることが結構あるのです。もっと大きなくくりでバックエンド、フロントエンドという壁もあれば、スキルレベルの壁というものもあります。
さらに、個人の内面で考えても、以下の記事にあるようなコンフォートゾーン（既知）とラーニングゾーン（未知）の境界に「技術の壁」ができやすいと思っています。自分にとって慣れた技術に留まってしまい、新しい学習ができなくなってしまうイメージです。
僕はこれまでの経験の中で、技術者集団というのはとにかく壁ができやすい構造になっていると思っていて、そしてこの壁に働くことの楽しさを阻害されてきたと感じることがしばしばありました。そして、この技術の壁をなくすこと、感じさせないこと、これは技術を選定する自分のミッションであり、自分にしかできないことだと思っていたのです。
５年間の仮説検証の結果、仮説「プログラミング言語で壁のない組織を作ることができる」については「YES」である、一定の成果が出た、と感じています。
フロントエンドとバックエンドに橋を架けて、
言葉や知識の自由貿易を実現したかった
2014年ぐらいのことですが、Fringeでは長い時間をかけてバックエンドはScalaを使っての開発に注力してきました。Scalaは半端じゃなく豊かな表現力を持っていて、機能と拡張性に優れた言語(個人の意見です)である一方、みんなで思い思いに実装するとあっというまに一貫性がなくなります。そんな性質もあって社内勉強会ではScalaを理解して、意識を合わせてOOP、FP、DDDなんかを実践しようという機運が高まっていました。
かたや、簡易で、コンパイラなどなく「まず動かそうぜ」的なJavaScript(個人の意見です)。当時、なんとなくフロントエンド開発者の負い目というか、理論を理解しても「実践するための環境(言語)」が少ないなと感じていました。また「初心者はフロントエンドから」みたいな登竜門的扱いもイヤ！とも強く思っていたものです。ざっくり言うと、 フロントエンドの矜持 を確立したかったわけです。
その中で個人的にScalaやHaskellを学びながらフムフム＆悪戦苦闘。フロントエンドの側からもScalaメンに有用な知識を提供したり、共通世界観をもつことで会話が弾むようになったり、そんな言葉や知識の自由貿易を実現したいなと夢想していました。
TypeScriptで「型」という橋を架ける
当時（2015年）、若いメンバーと仕事をすることが多かったんですが、レビュー時にこんなコードをよく見た気がします。
function f(bool) {
return bool ? 10 : "foo";
}
呼び出す側からすると、返り値の型が曖昧で扱いにくいコードです。そんな時、フィードバックをするのですが
「JavaScriptにも型というものが一応あってだね...云々カンヌン」
↓
「はぁ、なんとなくわかりました」
↓
(しばらくすると似たようなコードが上がってくる)
うーん、やはり具体的に型を可視化して日常的に触れていくことと、それによるメリットを享受したり失敗を経験しないとイカンなと。そこでTypeScriptを導入することにしました。
具体的には、既存サービスの４人フロント開発チーム、段階的にTypeScriptにリプレースしながら、学習で一定の理解が進んだメンバーからTypeScriptコードに触っていくという流れを作りました。
これにてフロントエンドとバックエンドに関係なく全てのエンジニアが「型」を扱っている状態になりました。フロントエンドとバックエンドの組織の壁に「型」という橋を１つ架けることができたのです！
新規事業（Unipos）の開発に、あえて未知のプログラミング言語Elmを導入
TypeScript導入までの流れにより、フロントメンのコード表現力はだいぶ高まり、少しはバックエンドとフロントエンドの壁はなくなってきたように思いました。
しかし、またしても勉強会の場。Scalaメンは「関数型プログラミング」とそれにまつわる概念の議論を白熱させていました。
僕は思っていたものです。
「もう大概は大丈夫、俺たちは同様の概念をシンプルに扱う術を手にしているのだから！」と。。
ちらりとフロントメンを見やります、、、、、ね、眠そう...！！！ ガーン
いろいろとリサーチをしていくと、
「現状のコードのどれが関数型的なアプローチなのか今イチわかんない」「しらない言葉がでてくる」
「脊髄反射的についていけないので徐々に置いていかれる」
などなど。
うーん、やはり具体的に関数型を可視化して日常的に触れていくことと、それによるメリットを享受したり失敗を経験しないとイカンなと。。。
奇しくも、2016年の秋、Fringeは新しいサービス「Unipos」を立ち上げる機会に恵まれました。そこで俺内セレクションを、幾度も繰り返して選び抜いた精鋭、純粋関数型言語Elmの導入を画策したのです。
Elmを魅力的に感じた点は
- 純粋関数型言語であり、常に式が値を返し、不変であり、参照透過性を確保出来る点
- コンパクトな言語設計により、学習コストは記憶よりも思考に多くを払うことになる
- Elmアーキテクチャという優れた枠組みが実装されていることにより、アプリケーション基盤の構築コスト(ライブラリの組合せ・依存解決・バージョン管理)がグッと下がる。
などがあります。
色々な言語やフレームワークの利用を模索しましたが、将来的に大きな広がりを見せる可能性や、言語自体の面白さにビビッと来て、チームを強くし・共に成長していける技術はコレが最高だ！と感じました。
当時は、始まって４年という若い言語であるという点や、プロダクト導入に踏み切っている企業は殆ど無かったので、導入に至れるかは全くの未知のチャレンジでしたが、僕はそれを逆に面白いと思いました。
『なぜやるのかで』未知への橋を架ける
ちゃんとサービス完成にこぎつけられそうかの検証を重ねましたが、もう一つ重要な戦いが。みんなにElmの魅力を感じてもらい、個人の内面にある既知と未知の壁に、いかに橋を架けるかということです。
そして僕は、全エンジニアの前で50枚くらいのプレゼンテーションを披露しました。さらに「しくじったら俺が全てリプレースします！」という決意表明。その時、使ったスライドがこんな感じです。
組織のスペシャリストという要所を任せてもらう責務を果たす上で、Elmという言語を用いる理由を目新しさで片付けたくはなかったため、「なぜやるのか」という理由を全力で伝えました。
更に、「道具としての機能性」だけではなく、メンバーの力を伸ばすという、「いまの組織にとってElmを導入することのタイミング的重要性」を中心に訴えかけることにしたのです。
さて、結果は。。暖かく受け入れられました！
「やってみたい！」と鼻息荒めに言ってくれるメンバーもチラホラ。。。😂
なんて素敵な仲間なんだ！！！と胸を熱くしたのでした。
カリー化、パターンマッチ、直和型、型アノテーションといった「ことば」の浸透もしていきましたし、純粋関数のあつまりでアプリケーションをつくる、ということを理屈だけでなく、まさしく体得できるような環境が整ったと思います。
(若手が送ってくれたファーストインプレッションレポート)
橋を架けて見えてきた新しいフロンティア
さて、プログラミング言語の選定を通して、技術の壁に橋を架けてきましたが、その結果、どんな世界が見えてきたのでしょうか？
①Elmのフロントランナーへ
いまFringeではたくさんのメンバーが業務でElmを書いています。ちゃんと文化として根付くに至ったのではないかと思います。
昨年は、僕と若手エンジニアの海老原でWEB+DB PRESSにElmの記事を書かせて頂いたり、
若手エンジニアの泉が「Elm Europe 2019」というヨーロッパで開催される大きなElmカンファレンスのセッションでUnipos開発についてのプレゼンをしたり、
弊社のオフィスでElm Meet upが開催され100名近い方が来場されたりと、
いつの間にか、ElmといえばFringeと言われるような状態に近づいたのではと思っています。
②相互依存できる組織へ
この数年、何人ものエンジニアがフロントエンド⇔バックエンドへのスムーズな領域スイッチを果たすに至りました。それぞれがしっかりと自立ができているうえで、状況によっては、お互いに依存し合うこともできる組織に近づいたと思います。
③学習する組織へ
Elmを導入したことで、組織内に色々と化学反応があり、新しい発見に出会うこともできました。
・若手エンジニアが中心となって定例勉強会を開催。「どうしたらもっとElmと仲良くなれるか？」を積極的に学びあう
・社内SlackでElmの最新動向のキャッチアップや、それにまつわる議論が活発に行われる
いろいろありますが、これらが僕にとってはとても嬉しいことで！僕の思いを一言でいうと「仲間たちがとっても心強い」んです！
今、「Elmを採用して一番良かったことは？」と問われたら、このElmersの活発な姿を見ることが出来たことと答えます。これからさらに仲間が増えていくと思いますし、更にどんなワクワクに出会えるのかとワクワクしています(笑)
長い時間をかけた結果でもあり、これはジンワリ嬉しい結果でした。結論、「プログラミング言語で壁のない組織を作る」は、ある程度出来たのではないかと思っています。「やりたいこと」がベースにあって、その時に「最適な道具の扱い方を素早く習得する」ことのハードルは下げることが出来たと思いますし、領域や言語を跨いだコミュニケーションもある程度は実現出来たのではないかと。
しかし、引き続き様々な工夫をしていかなければならないなとは思っております。人数が増えれば、新たな目に見えない壁はどんどん生まれてくるもの。これからも壁に橋を架け続けていきたいなと思っています！
＋＋＋
いかがだったでしょうか。Fringeでは、未知なる領域を一緒に探検してくれるExplorerを募集しています！ご興味のある方は、お気軽にご応募ください！！