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

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

By 松澤 有 (ymtszw) (Siiibo証券株式会社 CTO)
@関数型まつり2025 (2025/06/14) ^[1]

---

Siiibo証券株式会社

• 2019年創業、筆者はfounding engineer / CTO
• ↓の構成で社債専門の証券システムを作り上げてきた

---

このセッションでは

• 実際に関数型言語を業務で採用し、維持し、継続するにあたって重視している価値観、手続き、手法などをざっくばらんに紹介します
• なんとか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点を説得材料として）カネを集められるか

---

「メインストリーム」

• ElixirやElmを含む関数型言語の多くは「メインストリーム」とは目されていない[^要出典]
  • 10年前のEvan氏: "Let's be Mainstream!"
• モノ・ヒト・カネの要素を自信を持って揃えるには弱い...

---

...とか言ってられるか

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

---

「支え」となるもの

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

筆者の考えとしては：

---

その言語での「良いコード」に対する土地勘

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

---

Elixir

• そもそも前職でかなりElixirを業務で書いて自信をつけていた
  • access-company/antikythera - Elixir製マルチテナントアプリケーションプラットフォーム
• 個人的にも業務内外でElixirをかなりの時間書いた
  • blick - Antikythera上で動く勉強会スライド集積アプリ
  • hipchat_elixir - 今は亡きHipChatのclientをSwaggerから自動生成
• 現職でも必要に応じてOSSリリースしている（後述）
  • siiibo/assert_match - Pipeline-friendlyなassertionマクロ

---

Elm

• こちらは業務採用には至らなかったがやはり相当書いたし、今も新しいことを試す場をいくつか持っている
  • ymtszw.cc - Elm & elm-pagesで書いてる個人ページ
  • elm-xml-decode - XmlのApplicative-FunctorなDecoderパッケージ
  • setem - 直接Elm製ではないが、Elmのコード生成をするツール

---

主観は大事

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

---

コードレビューの技術

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

---

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

---

「自分でやる」精神

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

---

狂気の章のまとめ

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

---

コードレビュー / CI / Upkeep

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

---

コードレビュー

• 「どういうコードが（チームにとって・製品にとって）良いコードか」の伝道事業
  • 伝「道」であることが大事
  • 感覚・信念として共有できる状態に持っていきたい
• よく引き合いに出す資料：
  • How to Pull Request by Google Developer Experts
  • レビュイーとレビュワー、両方の視点で意識すると良いことがまとまっている

---

永遠の事業

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

---

自動化する

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

---

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

---

CI

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

---

CD

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

---

CD: Elixir

• mix releaseによってパッケージ化し、あとは仮想サーバなりコンテナなりに置いて実行するだけ
  • 2020年のv1.10で導入されて大変やりやすくなった
  • DockerのMulti-stage buildによる軽量化とも相性が良い
• しかもreleaseスクリプトには、remote console機能が同梱されていて、インフラがECSならECS Execと相性抜群
  • デプロイ環境でのデバッグに重宝する

---

CD: Elm

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

---

Upkeep

• 「維持費」の意、好きでよく使ってる
  • 個人的にはゲームWarcraft 3で覚えた
• 製品を作ってコードが育つとき、必然的に伴ってくる：
  • 依存ライブラリのバージョンアップ
    • Discontinuationにおける移行
  • 言語のバージョンアップ
  • その他諸々...

---

Upkeepしやすさ

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

---

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

---

Elmの特記事項

• Elmはもう5年以上メジャーアップデートされていない

  If you like what you see in 0.19.1 now, that’s pretty much what Elm is going to be for a while!
  — Status Update - 3 Nov 2021

• この「変わらなさ」を受け止められるかは、少なくともElmの採用に関しては大きな試練だろう

• 個人的にはProudly Unchangedとうそぶいている

---

• Elmの良いところは、Elm-runtimeで区切られた内部世界は純粋なので、その範囲では脆弱性の導入される余地がないこと
  • 少なくとも現行のアーキテクチャが確定したElm 0.18以来10年くらい経つが、筆者の認知している範囲ではこの前提は破られていない
• サプライチェーン攻撃に耐性があると言える

---

関数型言語のルーチン業務を支える技術の章のまとめ

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

---

ビルドとテストの高速化

血道をあげろ！

---

コンパイル速度

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

---

高速化し続ける

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

---

高速化: mix test

• mix testはElixirの標準テスト実行経路
• 純粋なunit testも、背後のDBや外部サービス等の存在下で行うintegration testも書ける
• master merge前のCIではDBのみ存在する前提で記述しているmix testを必須としている
  • SMLテストサイズで言うところのMediumくらい
    • 参考: ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方

---

• 該当するmix testの件数は最新のコードで4,500件ほどある
• かなり多くの割合がDB I/Oを含む
• これを少なくともApple Silicon MacBook系のローカル開発機では1分程度で実行できるよう維持している

---

• 実際にやっているのは、
  • テストの並列実行
  • 並列実行を可能にするための、
    • DBの複製
    • Test fixtureの独立化
    • Sandbox接続の利用
  • DB初期化を高速にするためのsnapshot活用

---

• 並列実行自体はmix testの標準機能
• DB接続のSandboxingもEcto（ElixirのORM+Query Builder）の標準機能
• ただし、
  • module単位でしか並列実行できない
  • 自然体だと同じDBを使うので、sandboxingしていてもWRITE操作の内容によってはdeadlockする

---

• そこで、
  • テスト同士の相互依存をなくすために、必要なfixtureデータはsandbox内で独立して作成する
  • テストDBを実行並列度に応じて複製する
  • テストごとに利用DBをcheckout/checkinする機構を設ける
    • EctoのDynamic Repo機能がこれを可能にしてくれる

---

• しかしEcto migration（よくあるパッチ方式のDB migration機能）を複製DB全てに適用するのは時間がかかる...
  • そこで、最新のDB schema snapshotを定期的に取得しておき、新規のテストDB作成時にはsnapshotから開始できるようにして高速化
• ここまで見てきたように、Ectoの諸機能は快適なテスト実行に大いに寄与しており、こいつがデファクト・スタンダードとして存在していることはElixirの大きな強み

---

高速化: elm make

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

---

• 自分でやる精神のもと、社内で調査
• ここはメンバーの@tsukimizakeが大活躍
  • プロファイラーを有効化してコンパイラをビルド
  • プロファイラーオプションを調整してボトルネック調査
  • Excessive GCを引き起こしていた実装パターンを特定
  • 当該パターンを回避できるようにコード生成系を改修

---

• そもそも、このあたりをまるっと改修できるよう、コード生成系が整備されていたのも大きかった。この点は後述
• elm-meetupでも発表された
  • tsukimizake/elm-compilation-time-slide
  • tsukimizake/elm-compilation-time-slide の続き
• 得られた知見はフォーラムにも展開
  • Improving Compilation time: Insights from Elm Compiler Internals - Show and Tell - Elm

---

高速化の章のまとめ

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

---

静的型付けでない言語と型の話

---

Elixirやってると思うこと

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

---

直和による表現、パターンマッチによる分岐

• Elmは言語機能が少ない静的型付けの純粋関数型言語
  • 典型的な実装イディオムとして、直和型とパターンマッチが頻出する
  • 昔書いた記事: 「ADT, 直和・直積, State Machine」 - Qiita
• Elixirはその点、
  • 型の静的検査はない
  • 直和を表現する専用の言語機能はない

---

• が、Atomを使った「直和的な」データ表現はかなり頻出で（Erlang/Elixirの標準ライブラリ内でも！）、そのことに自覚的になると「自然な」実装パターンが見えてくる（主観）
  • 筆頭は{:ok, value} | {:error, reason}
• 「Elmだとそういえばこう書いてたな、これElixirでもやれないの？」はそれなりにやれる
  • 特に副作用の絡まない関数では表現を似せられて腹落ちすることが多い
  • Result型に対する諸APIはElixir側にも実装してある

---

Pipeline-friendlyなassertion

• elm-testではExpect系関数をpipelineで受けて書かれる

String.split " " "Betty Botter bought some butter"
    |> Expect.equal [ "Betty Botter", "bought", "some", "butter" ]

• 一方mix testではassertマクロを手続き的に並べて書くことが多いが、場合によってはElmからの影響もあってpipeで書きたくなる

---

• siiibo/assert_matchはそのような日常的洞察から生まれたOSS
• 手前味噌ながらこのassert_matchマクロは結構強力で、どのような構造に対してもパターンマッチとしてassertionを書けるので、
  • pipeで書けて気持ちいいし
  • Elixirの強力なパターンマッチ機構を活かせるし、
  • 「関数とは入力と出力なのだ」という意識が高まる
  • （主観）

---

天から型が降ってきた

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

---

• とはいえ章冒頭の通り、Elixirに静的型検査がないことには定期的につまらなさを感じていたのだが...
• なんとElixirのコンパイラが静的型検査を始めるという大本営発表がなされたのだ！
  • My Future with Elixir: set-theoretic types (2022/10/05)
  • Gradual set-theoretic types
  • The Design Principles of the Elixir Type System

---

• Elixir v1.18で一部型検査機能がすでに有効化され、早速既存コードベースでもいくつかの潜在バグを発見・解消できた
• Elixir v1.19でもさらに入る：
  • Type checking of protocol dispatch and implementations
  • Type checking and inference of anonymous functions
• ついでに大規模コードベースでのコンパイル速度改善施策も入る
• Upkeepをこまめにやるのは、このような新施策をすぐ採用できる強みに直結

---

静的型付けでない言語と型の話の章のまとめ

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

---

情報収集 / コミュニティ還元

「アウトリーチ」

---

情報収集

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

---

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

---

コミュニティ還元

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

---

採用の話

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

---

アウトリーチの章まとめ

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

---

新しい手法を取り入れる

---

E2Eテスト

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

---

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

---

E2Eテスト: Flakinessとの終わりなき戦い

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

---

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

---

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

---

elm-review

• elm-reviewは、Elmでルールを書けるElmプロジェクトのためのLinter
• Elm 0.18時代に存在していたelm-analyseやAtom Editorのelmjutsuに搭載されていたLint機能の多くを引き継いでいる
• Linterとしては、前述の通りCIでのチェックとセットで開発プロセスの屋台骨になる

---

elm-review: 強力な正体

• 実はelm-reviewはLinterというよりは、Elmのコード変換ツールであるという捉え方ができる
  • 内部的にelm-syntaxが使われていて、ElmのASTを走査・操作できる
  • コンパイラの内部表現と直結してない外部ツールなので実行時間のオーバーヘッドはそこそこ大きいが

---

elm-review: コード生成

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

---

コード生成に対する考え方

• ちなみにコード生成で（何ならマクロ含めて）陽に目に触れないコードが肥大化していくのってどうなん？という観点はある
• 初学者にとって障壁になりがちなのは間違いない
• が、最近はエディタ補助機能の進化によって、手書きであろうと自動生成であろうとマクロであろうと、コードの来歴・経路を辿りやすくなり、迷子になりにくくなった
  • 必要なら節度を持って使えばいいという立場
  • 「力には責任が伴う」ことの意識は必要

---

新しい手法を取り入れるの章のまとめ

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

---

覚悟

---

続けていく気概

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

---

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

---

結び

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

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

脚注

1. この発表資料はZennで公開しつつ、Marpスライドとして作成しているので水平線がいっぱい入っています