関数型言語を採用し、維持し、継続する

• 実際に関数型言語を業務で採用し、維持し、継続するにあたって重視している価値観、手続き、手法などをざっくばらんに紹介します
• なんとか5年はやってこれた
• 次の5年もやっていきたいがためのやつ

• 最新の開発組織規模
  • フルタイム – 5名（筆者含む）
  • 週3日程度 – 2名
  • 週2〜10時間程度 – 8名
  • 学生アルバイト – 3名
• 1日あたりの平均デプロイ（master push, GitHub Flowなので）回数
  • Copilotにお願いして雑に集計したら4.94だった

$ set start_date (git log master --reverse --pretty=format:'%ad' --date=short | head -1); set end_date (git log master --pretty=format:'%ad' --date=short | head -1); set days (math (date -j -f "%Y-%m-%d" $end_date "+%s") - (date -j -f "%Y-%m-%d" $start_date "+%s")); set days (math "ceil(($days/86400)+1)"); set commits (git rev-list --count master); math "$commits / $days"
4.941361

• CTOとかFounding Engineerが技術構成を選ぶにあたっての観点
  • まともなモノを継続的に提供するに足る機能があるか
  • それを実際につくるヒトを継続的に集められるか
• 加えて「スタートアップ」なら、
  • （上記2点を説得材料として）カネを集められるか

• 良いと感じた技術があって、良いモノを作れると検証できたのであれば、あとは自分がやるかどうかでしかない
  • というか、勝手に機会が降ってくることがない
• ある種の狂気を必要とする点で、非メインストリームな技術採用はスタートアップ起業自体と似ている
  • その試み自体が仮説検証であり、失敗にもまた学びがあるが、結局は勇気と周りを巻き込んで走り続ける力

• とはいえ「この技術がイイらしい、とりあえずやってみよう」はいかにも爆発しそう
  • そこまで無根拠なのは蛮勇
• 何が支えとなって一歩を踏み出せるのか？

筆者の考えとしては：

• 本チャンの業務で採用する前に「検証」は必須
  • 言うまでもないこと？
  • 個人プロダクトでも、別業務内の軽いツール開発などでもいい
  • そこそこ大きなコードベースを作って勘所を押さえておくこと
  • 先行しているOSSのコードを読んで、先人の開拓した領域に触れておくこと
• 筆者の場合は…

• 世の中の採用事例とかを情報として集めておくのも（自分以外に対する）説得材料としては役に立つ
• …が、究極的には主観だと思っている
  • この言語で5年10年戦えるか？実現したい要求に叶うか？飽きないか？
• プラス、「何らか行き詰まったときに捨てやすいか？」という観点もある
  • これは言語自体というよりアプリケーションアーキテクチャで担保する側面か？
  • 未だ大規模にコードを捨てたことがないのでここについては未経験領域

• 何らかの技術要素を採用して業務に挑もうとするとき、必然的にFounding Engineerはコードレビューをする立場
  • 自分がいいと思う技術であっても、それを「伝道」できなければあとが続かない
• **健全で有意義なコードレビューのやり取りがどのようなものか？**という経験とその内面化

• 何をもって「できている」と言えるのかがそもそも難しい
  • ここでも主観が大事だし、ずっと研究が続く
  • マジで環境に依存すると思うので若いエンジニアには特に言っている
  • 筆者の個人的な経験としては前職（新卒入社）のチームが本当に素晴らしかった…そこで私のすべてが形作られた
• この話は直接次の章につながる

• 「ライブラリや有名サービスのSDKがない」
  • 非メインストリーム言語においてツラミとしてよく挙がる
• これについては「ないときに自分で作りやすいか」「作ったものを腐らせずに維持しやすいか」まで含めて言語の評価点と捉えたい
  • Elixir/Elmでいうと、意外と典型的なニーズに応えるライブラリは揃っているのであまり困った経験はなし
  • とはいえこれは作ろうとしているサービスの特性にも左右されるので注意
• 後述するが、コミュニティ貢献へと直接つながる

• 非メインストリーム技術採用は狂気ドリブンで機会を自ら作り出すもの
• 事前検証と伝道師としてのコードレビュー技術が支えになる
• ないものは作れ

ルーチン業務で重視する要素

• コードレビューに終わりはない
  • 人は忘れる（レビューする側も、される側も）
  • 新しい人は入る
  • 一度言っただけで身につくことは誰であれ、ない
• 言葉を尽くして、繰り返し対話し続ける

• レビュー指摘項目のうち、自動的に強制できるものは自動化して機械にやらせる
  • Formatterで強制できるコードスタイル
  • Linterで強制できる観点

• これがやりやすいか言語か、標準ツールが存在するか、というのは当該言語に対する大きな加点項目
  • 少なくともElixir/Elmでは長いことformatの議論をしてない
    • Nearly-zero-configなformatterが標準
    • 公式formatterのスタイルが好きじゃない、という状況はたまにあるが、考えることを減らせるメリットのほうが大きいので割り切っている
  • Linterの話も後述

• ツールの導入はCIとセット
  • ＋エディタ連携
• 人間は忘れるのだから、忘れない機械に何でもチェックさせる
  • ビルド、テスト、FormatterやLinter以外だと：
    • 破壊的変更（DB-Server間や、Server-Client間）の検知
    • 自動生成コードのコミット漏れの検知
• 後の章で更に触れる

• 作ったプロダクトを顧客に届ける方法が確立されていて迷いが少ないのも嬉しい
• 非メインストリームな技術にあっては、このあたりで詰まらないのは障壁をだいぶ下げる

• Production build機能がコンパイラ同梱で、Dead-Code Eliminationを標準装備
• 基本的にはこれだけでも比較的小さい成果物が得られる
• 追加でMinifierをかけても良い
  • この辺はコミュニティ努力で知見が蓄積されているが、フロントエンド技術の進化に合わせてより良いツールに載せ替えることもあり
  • いささか周辺知識が必要なところ

• 恐怖症的にならずにこまめにやる
• バージョンアップ系作業がやりやすいのも言語の大きな加点項目
  • 依存関係解決が決定論的かつ高速にできる
  • 何ならDependabotなどに勝手にやらせられる範囲も広がる
• モダンな言語だとそんなに議論になることは少ないかもしれない

• Elixir, Elmはいずれも比較的優秀
  • mix (Elixir)のdeps解決は速いしわかりやすい
    • 必要に応じて脱出ハッチ（override）も使える
  • Elmはそこに加えてforced-semantic versioning
    • 少なくともインターフェイス非互換はやる前に防げる

• 何はなくともコードレビュー、永遠の事業
• 自動化・デプロイ手法の観点なしでは今の技術選択は語れない
• 変わること・変わらないことどちらに対しても態度を明確化して品質維持に務める

血道をあげろ！

• 関数型言語はAOTコンパイルが多い
  • ElixirもElmもそう
• プロダクトが育つとビルドやテストが遅くなりがち

• ユーザ側の努力でも高速化できる余地はあり、常に追求する
• 高速化に繋がりそうな更新情報の追跡も怠らない
• メンバーが増えるほどに、ローカル/CIいずれでもビルドやテストの実行時間短縮は乗算で大量の時間節約になる

• Elmのインクリメンタルコンパイルはデフォで比較的速い
  • これはDCEを有効化したprod buildでも同様
• が、コンパイル対象moduleが多いときはそこそこかかる
• しかも、特定の実装パターンがあると、構成module数が増えたときにGC時間及びメモリ使用量が増えるという現象に遭遇したことがあった

• AOTコンパイル言語、それもコンパイル時の機能（型検査含む）が豊富であれば、コードが育つほどに速度問題は不可避
• コンパイラの改善でほっといても速くなってくれることもあるが、基本的には自分でやる精神はここでも発揮する必要がある
• 速さと向き合え！

• まあ型は欲しくなる
  • 型があったらこのバグは起きなかった、みたいなことは定期的にある
• とはいえElmといっしょに開発し、多くのメンバーがなんだかんだElmも書いているという状況では、ありがたいことに多くの学びがある

• そんなこんなで言語間比較による恩恵はある程度受けていた
• 関数型言語によく出てくる概念は、単一の言語だけやってるとイマイチ腹落ちせず、いくつか言語をまたぐと得心できることが多いという経験則があり、その意味でも有用
  • 個人的には、Scalaで始まり、Elixirに入り、Haskellの手ほどきを受け、Elmで色々理解した、という関数型キャリアパスを辿ってきた

• 関数型言語のエッセンスを体得するには複数言語に触れたほうがいい
  • その意味でElixir/Elmのスタックは有用だったという振り返り
  • 両者の実装が自然と親和して、認知モデルを共有できる
• 型で考えていると型の方から（文字通り）やってくることもある

「アウトリーチ」

• 非メインストリームな言語はほっといても情報が入ってくるわけではない
  • 規模にもよるが
• それでも狂気を発露して採用に踏み切ったのなら、アクティブな情報収集は必須

• 言語公式フォーラム/ML/Slack/Discordのウォッチ
  • コミュニティがデカすぎないことを逆に活かして、ライブラリ開発者などがよく出入りしているトピックやチャンネルを購読しちゃう
  • 最新動向を嫌でも逃さなくなる
  • 社内にも展開する
• コンパイラや主要なライブラリのissue trackerも購読しちゃう
  • チーム内で抱えてる課題と似たような話題も出たりする
• X

• ウォッチしている経路での、質問者に対する回答
  • 聞いてるだけでなく回答もする
  • なにげに「自分が第一人者」「フロントランナー」である可能性を意識
  • 英語翻訳にはあまり困らない時代になった
• 国内外の勉強会参加
  • 何なら開催協力

• ここまで書いてきた「やれることやってる」環境を維持し、アウトリーチもすることは、とりも直さず採用に直結
• 何しろ非メインストリームな技術要素は、それを業務でちょっと触ってみたいと思っても会社の選択肢が少ない
• 選択肢がほしい・見識を広げたい人にとっては良いマッチング機会

• やれることはやる、近道はない
• 人口の少なさは好機でもある
• 全世界を対象にすれば意外とコミュニティは広い

• Autify→Playwright、という流れで2023年から導入
• 口座開設、社債購入等の主要なトランザクション部分のsmoke testをE2Eテストとして表現
  • VRTも要所に導入して意図しない表示崩れを防ぎたい箇所を検証
    • また、VRT画像を確認することでPRのレビューにも便利
  • 検証環境に対するE2Eテストのパスを本番デプロイの要件に

• Elmアプリはその純粋性故にE2Eテストと相性はいい（少なくとも概念上は）
  • 状態に対して描画結果が一意に定まる
  • E2Eテストのランナー環境をコンテナに統一すれば、OSごとのフォント描画差異なども解消できる
• ではflakinessは全くないのか？

• そんなことはない
  • E2Eでアプリ動作を検証する場合は、ネットワーク越しの処理遅延などで思わぬ未定義状態に落ちたりする
    • 特に、非同期処理は完了msgの到着順にupdate関数の評価が行われるというTEAの性質上、明示的に直列化していない処理（ローカル環境では暗黙的に順序が定まっていたもの）が、実環境では逆転が生じる、とか

• （続）
  • Playwright（使ってるChromiumブラウザ）のバージョンを上げると、描画の挙動が変わることがある→VRTが落ちる
  • そもそも、ブラウザのlayouting/renderingに若干非決定的（に見える）部分があって落ちたりもする
    • 深堀りしていくと一意に定められることも多いのだが、微妙なズレを解決しづらかったりもする

• 結局ここでも高速化と同じような話で、テスト安定性の追求にはコストを割くというチームの合意と決意が必要
  • E2Eテストが安定している時期のデプロイの安心感は高い
  • そもそも、小さなほころびであっても実際に顧客環境での問題に繋がっているというE2Eテストの意義が前提にある
• ついでにPlaywright Testを書く場合、Aria Roleを意識してマークアップを整えるとテストが書きやすくなる効果もあり、結局顧客価値にもつながっている

• この特徴を活かして、コード生成ツールとして使うのが実務ではありうる
  • 前述の通りElmの言語機能は意図的に少なく、コンパイル時コード生成のような機能は標準では提供されていない
  • 実務だとなんだかんだ必要になりがち
    • ボイラープレート生成
    • File-based Routing機構
    • APIクライアントmoduleの生成

• E2EテストにしろLinterにしろ、CI/CDとセットで価値が出るので環境整備は前提
• 安定化・高速化のための努力は怠らない
• 強力なツールは責任とともに

• ここまでほとんど定性的な話だったと思う
• 何であれ技術要素の採用にあたっては、
  • 周囲を巻き込んで積極的に環境・機会を作り出すこと
  • 維持するために必要な労力は怠らないこと
  • その姿を持って後続に道を示し続けること

• となると対象技術がメインストリームかどうかというよりは、結局言い出しっぺにケツを持つ気概があるかどうかじゃない？（雑）
• よくOwnershipとかLastmanshipみたいな言葉が使われるやつ
• こう言うと怖がらせるようでもあるが、アウトリーチを怠らなければ意外と世の中にちゃんと仲間がいるということもわかるので意外とやっていける

諸兄におかれましては、勇気（と狂気）を奮って関数型言語採用の裾野を広げてほしいと思うところであります 😤

ありがとうございました！