初めまして。
この記事はディップ株式会社の Advent Calendar 2025の22日目です。
はじめに
speakerdeckって最高じゃないですか？
暇な時に技術系のスライドを漁るのが好きです。
タイトルの通りですが、その中でも特に今年勉強になったスライドを３つ共有させてください。
- 『質とスピード』
- 『The Clean ArchitectureがWebフロントエンドでしっくりこないのは何故か』
- 『関数型プログラミングと型システムのメンタルモデル』
なぜこの３つなのか
今年は自分のキャリアにとって色々と学びの多い年でした。
0→1のプロダクトで開発チームリーダー的な役回りで設計、計画〜実装までを担当したり、
自分の主導していた既存プロダクトへのフロントエンドフレームワークの導入が一旦完了したりと、今まで以上に設計やアーキテクチャについて考える機会が多かったです。
そんな中で抱いていた疑問を解きほぐすきっかけとなったのが今回共有するスライドでした。
以下はその疑問と対応するスライドです。
- チーム開発においてどうすればベロシティを落とさずにコード品質を担保できるのか。
- 『質とスピード』
- なぜフロントエンドではアーキテクチャのベストプラクティス的なものが調べても出てこないのか。（オニオンアーキテクチャとかを当てはめるのはダメなのか。）
- 『The Clean ArchitectureがWebフロントエンドでしっくりこないのは何故か』
- フロントエンドの世界で関数型プログラミング的な実装がスタンダードになっている理由がイマイチ掴めない。（元々バックエンド寄りの人間なので）
- 『関数型プログラミングと型システムのメンタルモデル』
『質とスピード』
t_wadaさんのスライド。 以下の記事も読む際の参考になりました。
学んだこと
- 「質 vs スピード」という捉え方は根本的に間違い。
- 開発において、質（内部品質）とスピードはトレードオフではない。
- 開発スピードは内部品質に依存し、外部品質は開発スピードによって生み出された学びのループに依存する。
- "品質とは誰かにとっての価値である。" -- Gerald Weinberg
- 外部品質：顧客にとっての価値
- 内部品質：開発チームにとっての価値
- 内部品質（≒保守性）を落とせば、結果としてはスピードが落ち全体として悪循環に陥る。
- 「出来るエンジニアは早くてもある程度の品質のコードを書いてくる」らしい。
- スライド内で紹介されていたエリートパフォーマーとローパフォーマーの生産性調査の数字が衝撃（2021年）
- リードタイム：エリートはローより6750倍短い
- デプロイ頻度：エリートはローより973倍高い
- MTTR：エリートはローの1/6570の速さ
- 変更失敗率：エリートはローの1/3の確率
- 品質と開発スピードがトレードオフではないことがデータで示されている。
- 内部品質への投資の損益分岐点は1ヶ月以内に現れる。
- 想像以上に早い。
- つまり保守性を犠牲にするという決断は、１ヶ月以内に自分たちの首を絞めて逆効果になる可能性。
- 「スプリントの20-30%をリファクタリング用に投資すると決めた。」と言うキャディ株式会社の事例が興味深い。
- 初期はベロシティが落ちたが、1-2ヶ月後にはデリバリー速度が高まった。
- 💡 この方法を取り入れるのはありかも！
- 似たようなものとして、スプリントプランニングで技術負債解消アイテムに固定の枠を設けると言うログラス社の事例の紹介もあった。（スプリントの10%の工数を負債解消に充てる）
- スライドの結論としては、開発チームの力量を上げる（＝メンバーの教育、DevOpsへの投資、新しい技術への投資（今ならAIツールとか？））ことで、「質（内部品質）とスピード」を一緒に向上させていこうと言うことだと理解しました。
- 一個人レベルの話では、「勉強せえ。」と言うシンプルな訓戒だと感じました。
- 開発を委託すると一時的な納期がゴールとなって質を軽視される可能性があり（受託側からすれば長期的視点で内部品質を気にする必要性が低い）、やはり開発内製化は重要だなとも感じました。
『The Clean ArchitectureがWebフロントエンドでしっくりこないのは何故か』
t_wadaさんのスライド。
学んだこと
-
まずはソフトウェアアーキテクチャの目的（何のためにあるのか）を理解することが大事
-
そのあと、フロントエンドアーキテクチャを駆動する（決定する）品質特性と制約を理解することでモヤモヤははれるかも。（適切なアーキテクチャや技術を選択する評価軸が得られるかも）
-
アーキテクチャとは、
- コンポーネントを組み合わせて相互通信できるように配置したシステムの「形状」
- 望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかの設計判断の集合
-
品質特性とは、
- 何らかのアクションをどれだけ上手く行うかを定義。（〜性, 〜itiy）
- 外部から見えるもの・運用に対するものに分けられる。
- つながる世界の ソフトウェア品質ガイド - IPA に分かりやすい図があります。
- アーキテクチャの選択とは、促進したい品質特性を選択すること。 促進したくない品質特性は控えめに扱うか取り除く。
『つながる世界の ソフトウェア品質ガイド』 p.30より抜粋
- 制約とは、
- 選んだか与えられたかによらない変更できない設計判断のこと。
- ビジネス観点 / 技術観点から、フロント・バックエンドなどそれぞれの分野に特有の制約がある。
- 制約は選べず、自動的にアーキテクチャ選択に影響を与えるクリティカルドライバー。
-
アーキテクチャを考える上では、まず求める品質特性とその分野の制約を特定するべきだということに気が付きました。
- 品質特性と制約だけがアーキテクチャの決定要因ではないですが、要因の中では特に影響度の大きいものであると考えて以下の図のように単純化しました。
- フロントエンドにおける品質特性は、
- 保守性：コードベースを安全で効率よく継続的に進化・運用していく上ではフロント・バック関係なく必要。
-
Webフロントエンド版DX Criteriaを参考にすると、その他に以下の観点がフロントでは必要。
- パフォーマンス：ユーザー体験に直結
- アクセシビリティ：プロダクト価値にユーザーがアクセス可能であることの保証
- セキュリティ：Webフロントエンド領域特有の多角的で複雑なリスク
- プライバシー：Webブラウザにおけるユーザー情報の取り扱い
- デザイン：一貫したユーザー体験の提供と開発効率の両立
- つまりフロントエンドにおける品質特性は、
- 保守性
- セキュリティ
- 使用性
- 性能効率性（時間効率性）
- フロントエンドにおける制約は、
- スライドで紹介されていたもの
- ブラウザ・デバイスの制約：さまざまな環境で動作する必要
- ネットワーク制約：通信環境に影響を受けやすい
- フロント特有のセキュリティ制約：XSS・CORFなど
- プログラミング言語の制約：ほぼJavaScript一択
- SEOの制約
- 上記を考慮すると以下の品質特性も必要になる。
- 性能効率性（資源効率性）：SEO観点
- 信頼性（障害許容性）：ネットワーク観点
- 移植性（適応性）：ブラウザ・デバイス観点
- スライドで紹介されていたもの
- つまり制約も考慮したフロントエンドの品質特性は以下のようになる。
スライド p.46 を参考に作成
-
品質特性と制約がバックエンドとは異なるのでクリーンアーキテクチャがしっくりこないのは当然
- クリーンアーキテクチャ（オニオンアーキテクチャ）はバックエンドの畑で生まれた。
- バックエンドはビジネスロジックの複雑さに対抗するためDDDやクリーンアーキテクチャという戦術を育んできた。
- フロントエンドはUIの複雑さ（デザイン・状態管理）に対抗するためにコンポーネント指向という戦術を育んできた。
- スライドで紹介されていたこちらの記事もとても参考になりました。
- 「ビジネスルール、ビジネスロジックとはソフトウェア上で業務ルールを表現し、データの整合性を保つためのロジックとここでは定義します。」 -- 以下記事より引用
- この定義に従うならば、確かにフロントエンドにあるのはビジネスロジックではなく単なる状態管理+UI用ロジック
- バリデーションについても、その目的がフロントではUI管理のため・バックではデータ整合性のためと考えるとフロントにおいてはビジネスロジックから外れる。
-
スライドの結論としては、「品質特性と制約を考慮すれば、フロントエンドのアーキテクチャ・システムの形状は当然『The Clean Architecture』で紹介されているもの（バックエンド）とは異なるが、紹介されている原則などは参考にできる」ということかと思います。
-
『The Clean Architecture』は一度読みましたがまだ消化不良の部分も多いです。また最近はフロントの仕事が多かったので棚に積まれっぱなしでしたが、フロントにも役立つ知識を吸収すべく頑張って再度読み込みたいと感じました。
『関数型プログラミングと型システムのメンタルモデル』
株式会社 一休の伊藤さんのスライド。
学んだこと
- 自身のプログラミングのメンタルモデルを更新 or 新しい視点を取り入れてみないか？
- "それぞれが持つメンタルモデルの多くは初めに触った言語や、その次に触った言語あたりに大きく依存していることでしょう" -- p.4から引用
- 多くの人が最初に学んだのは、大抵この10~15年の世の中でメジャーな立ち位置を占めていた言語なのでは。（JavaScript, Python, Ruby, PHP, Java, C++）
- 上記の言語は、構造化プログラミングとオブジェクト指向のパラダイムに影響受けている。
- 我々多くのエンジニアのメンタルモデルもまた構造化プログラミングとオブジェクト指向に強い影響を受けているはず。
- メジャーなメンタルモデル（コンピュータの操作に焦点を当てる）
- 「蓄えられた値を変更することで結果を得る」モデル
- 変数を定義して、値を代入する。書き換える。
- オブジェクトを生成して、プロパティを設定する。プロパティの値を変更する。
- 状態を保存する箱を用意して、値を設定する。更新する。
- メモリに値を蓄えて計算すると言うコンピュータアーキテクチャに近いモデル。
- ある意味自然に思いつきやすいモデル。
- ハードウェアのモデルをソフトウェアやプログラムにも適用した。
- これが一般的に「命令的」と呼ばれるモデル。
- 命令（~文）の記述を通して値を設定・変更・読み取りする。
- for文, if文 ...
- 命令（文）はあくまで「手続き」なので、それ自体は値を返さない。
- 「蓄えられた値を変更することで結果を得る」モデル
- 型とは「取りうる値の集合」
- 型はある値の適応可能な計算や操作を定義している。
- string：
length(),toUpper()・・・ - number：
round(),max()・・・
- string：
- つまり型は値の集合として捉えられる。ベン図が描ける。
- 型はある値の適応可能な計算や操作を定義している。
- 新しいメンタルモデル（ロジックに焦点を当てる）
- 「関数によって値を変換する」モデル
- 値の変換 = 型の変換 = 別の集合への写像
- 文と比較して、式は必ず値を返す。
- 式は値を受け取って値を返す。つまり値の変換（対して文は値を直接内部的に書き換えがち）
- 関数型プログラミングにおいて関数は式なので、関数と型で明示的な状態の変換を表現できる。
- 引数と戻り値によって値（状態）の変化を明示的に記述できる。
- リンタやコンパイラによる静的解析で開発時点で状態の変化を追うことができて安全。
- 逆に、命令的だと状態の変化が暗黙的リスクがある。（命令的に書くことを全否定しているわけではない。）
- 関数による値の変換でプログラムを組むことで計算（ロジック自体）に焦点を当てることができる（宣言的）
- 「関数によって値を変換する」モデル
- コンピュータという詳細を気にする必要がないのでより純粋にビジネスロジックを記述できる。
- 状態遷移の関数を純粋な言語機能によるPure Codeでプログラムを組み、コンピュータとのI/Oをフレームワークなどに任せることで、ビジネスロジックに集中して開発できる？
- 現代のフロントエンドフレームワークは状態管理をDOMから切り離し、宣言的に状態遷移を記述できるようになった。（フレームワークがよしなにDOMを管理してくれるのでロジックに集中できる）
- 最近の記事ですが、以下もとても参考になりました。
- 型の表現力を上げることでより厳格に値（状態）の変換を定義できるようになる。
- 積（AND）だけでなく和（OR）も表現できるモダンな型システム（TypeScriptのUnion型など）
- 積（継承や合成）だけではMECEに型を定義できず、仕様上あり得ない状態が定義できてしまう。
- 和を使えることでMECEでより厳密に型を定義でき、コンパイラにもそれを伝えることができる。（今なら値の取りうる範囲を厳密に伝えることができるという意味でAIコーディングにも有益かも？）
- Type ChallengesというTypeScriptの型の実装クイズがあるらしい。
- 型実装力・設計力を上げるには良いかも。
- 一休さんはフロントエンド開発において先進的な取り組みをされているなという印象です。
- 以下の記事なども参考になるので、ぜひ自分でもお試し実装などしてみたいと思いました。
さいごに
他にも勉強になったスライドはたくさんあるのですが、今年の自分の経験を反映した3つに絞りました。年末年始、皆さんもコタツでみかんでも食べながらspeakerdeckを漁ってみては如何でしょうか。
それでは皆さま良いお年を。
Discussion