パイプライン処理はもう限界？UNIX哲学不要論から学ぶ現代のデータ構造に適したシステム設計

UNIXパイプラインは、grepやawk、sedといった小さなコマンドを|で繋ぎ、テキストストリームを逐次加工していくという思想のもとに設計されています。
「一つのことをうまくやる」というUNIX哲学は、確かに美しい設計原理でした。
しかし、この哲学が生まれた時代と、現代のデータ構造やワークロードとの間には、大きな隔たりが生まれつつあります。

現代のシステムでは、扱うデータの多くがJSONやProtocol Buffers、Parquetのような構造化データです。
テキスト行を前提としたパイプライン処理は、このようなネストされた構造や型情報を持つデータに対しては、本質的に相性が悪いと言わざるを得ません。
パースとシリアライズを繰り返すオーバーヘッド、型情報の欠落によるバグの温床、そして並列分散処理との親和性の低さ。
これらは、ストリーム指向の設計そのものに起因する構造的な課題です。

もちろん、パイプラインという概念自体を否定するつもりはありません。
問題の本質は、「テキストストリームこそが普遍的なインターフェースである」という前提が、現代のデータ環境ではもはや成立しにくくなっている点にあります。

本記事では、以下の観点からこの問題を整理していきます。

UNIX哲学が前提としていた設計思想とその限界
構造化データ時代におけるパイプライン処理の課題
型安全性とスキーマを重視した現代的なシステム設計のアプローチ

単なる懐古主義でも、逆張りの否定論でもなく、データ構造の変化という観点から、設計思想そのものを冷静に見直していきたいと思います。

パイプライン処理とUNIX哲学の基本を振り返る
1. 「一つのことをうまくやる」という設計思想
2. テキストストリームを前提としたコマンド連携
なぜ今パイプライン処理の限界が語られるのか
1. 現代アプリケーションが扱うデータ量の変化
2. マイクロサービスとの相性という新たな論点
構造化データとテキストストリームの根本的なミスマッチ
1. JSON・Protocol Buffers・Parquetが主流になった理由
2. パースとシリアライズの繰り返しが生むオーバーヘッド
型安全性の欠如がシステムにもたらすリスク
1. 動的型付けゆえのバグの温床
2. スキーマレス設計と品質担保のトレードオフ
並列処理・分散処理とパイプラインの相性を検証する
1. ストリーム指向設計がスケールしにくい理由
2. バッチ処理との比較から見える設計の分岐点
型安全とスキーマを重視した現代的なシステム設計
1. スキーマ駆動開発という選択肢
2. 静的型付け言語とORMによる恩恵
UNIX哲学不要論は本当に正しいのか
1. パイプライン処理が今も有効なユースケース
2. 哲学の否定ではなく設計思想のアップデート
実務で使えるアーキテクチャ選定の判断基準
1. プロジェクト規模・データ量から考える設計指針
2. クラウドネイティブ環境における現実的な落とし所
まとめ:パイプライン処理の限界とこれからのシステム設計

パイプライン処理とUNIX哲学の基本を振り返る

現代のシステム設計を批判的に検討する前に、まずはパイプライン処理とUNIX哲学がどのような思想のもとに生まれたのかを整理しておきたいと思います。
この設計思想を正しく理解しておくことが、後述する課題を論じるうえでの前提になるからです。

UNIX哲学は、1970年代にベル研究所で生まれた設計原則です。
当時のコンピューターは現在と比べて計算資源が乏しく、限られたメモリとCPUの中で、いかに柔軟かつ再利用可能なソフトウェアを構築するかが重要な課題でした。
その解決策として提示されたのが、「小さなプログラムを組み合わせて大きな仕事を成し遂げる」という思想です。

「一つのことをうまくやる」という設計思想

UNIX哲学の中核をなすのが、「Do One Thing and Do It Well(一つのことをうまくやる)」という原則です。
grepは検索に、sortは整列に、wcはカウントに特化しており、それぞれが単一の責務のみを担っています。

この設計には、以下のような明確な利点がありました。

各プログラムの実装がシンプルになり、バグが混入しにくい
単体でのテストや検証が容易である
他のプログラムとの組み合わせによって、想定外の用途にも応用できる

これは、現代のソフトウェア工学における単一責任の原則(Single Responsibility Principle)の源流とも言える考え方です。
オブジェクト指向設計や関数型プログラミングにおける関心の分離という概念も、根底にはこの思想が流れています。

テキストストリームを前提としたコマンド連携

もう一つの重要な要素が、「テキストストリームこそが普遍的なインターフェースである」という前提です。
UNIXでは、プログラム間のデータ受け渡しに標準入出力を用い、|によってこれを連結します。

cat access.log | grep "ERROR" | awk '{print $1}' | sort | uniq -c

このように、各コマンドが標準入力からテキストを受け取り、加工した結果を標準出力へ流すことで、複雑な処理を段階的に構築できます。
プログラム同士が互いの内部実装を知る必要がなく、テキストという共通言語さえ守れば自由に連携できる点は、疎結合な設計として非常に優れていました。

しかし、この前提が成立するのは、あくまで扱うデータが一次元的で構造の単純なテキスト行である場合に限られます。
次章以降で見ていくように、この前提こそが現代のデータ構造との間に軋轢を生む要因となっています。

なぜ今パイプライン処理の限界が語られるのか

UNIX哲学が誕生してから半世紀以上が経過しました。
その間、コンピューターの計算資源は飛躍的に向上した一方で、私たちが扱うデータの量と複雑さもまた、当時とは比較にならないほど増大しています。
ここでは、パイプライン処理の限界が語られるようになった背景を、具体的な観点から整理していきます。

現代アプリケーションが扱うデータ量の変化

1970年代のUNIXが想定していたのは、せいぜい数メガバイト規模のログファイルやテキストデータでした。
しかし、現代のシステムが扱うデータ量はその比ではありません。
IoTデバイスから絶え間なく送られてくるセンサーデータ、数億件規模のユーザー行動ログ、リアルタイムに更新され続けるトランザクションデータなど、ペタバイト単位のデータを日常的に扱うことも珍しくなくなりました。

このような大規模データに対して、単一プロセス内で逐次的にテキストを処理するパイプラインの手法は、以下のような問題に直面します。

課題	従来のパイプライン処理	求められる要件
処理単位	行単位の逐次処理	分散並列処理
データ形式	フラットなテキスト	ネスト構造を持つデータ
スケール手法	単一ホスト内での最適化	複数ノードへの水平展開

つまり、データ量の増大に対してパイプライン処理は本質的にスケールしにくい設計になっているのです。
これは、CPUやメモリを増強すれば解決する問題ではなく、処理モデルそのものに起因する構造的な限界だと考えられます。

マイクロサービスとの相性という新たな論点

もう一つの論点が、マイクロサービスアーキテクチャとの相性です。
現代のシステムは、単一の巨大なアプリケーションではなく、独立してデプロイ可能な小さなサービス群として構築されることが一般的になりました。

一見すると、マイクロサービスの思想はUNIX哲学における「一つのことをうまくやる」という原則と親和性が高いように見えます。
しかし、実際にはいくつかの重要な相違点があります。

マイクロサービス間の通信は、多くの場合gRPCやREST APIを通じたJSONベースの構造化データである
サービス間の契約(コントラクト)を型定義やスキーマとして明示的に管理する必要がある
非同期メッセージングやイベント駆動アーキテクチャでは、単純な逐次処理では表現しきれない状態管理が求められる

このように、マイクロサービス環境で求められているのは、テキストストリームの受け渡しではなく、型付けされた構造化データの安全な流通です。
パイプライン処理が前提としていた設計思想と、現代の分散システムが要求する設計思想との間には、無視できない乖離が生まれつつあると言えるでしょう。

構造化データとテキストストリームの根本的なミスマッチ

前章では、データ量の増大とマイクロサービスとの相性という観点から、パイプライン処理の限界を概観しました。
本章では、より根本的な問題として、扱われるデータの構造そのものがテキストストリームと相性が悪くなっている点を掘り下げていきます。

JSON・Protocol Buffers・Parquetが主流になった理由

現代のシステム開発において、データ交換フォーマットの主流はJSONやProtocol Buffers、そして分析基盤ではParquetといった構造化フォーマットへと移行しています。
これらのフォーマットが選ばれる理由は明確です。

ネストされたオブジェクトや配列を自然に表現できる
型情報をスキーマとして明示的に定義できる
バイナリ形式であれば、パース速度やデータサイズの面でも効率的である

例えば、Protocol Buffersでは以下のようにスキーマを定義し、フィールドの型を厳密に管理します。

message User {
  string id = 1;
  string name = 2;
  repeated string roles = 3;
}

このようなスキーマ定義があることで、データの整合性をコンパイル時、あるいはシリアライズ時点で検証できます。
テキスト行をパースして値を取り出すという手法では、このような型の保証を得ることは原理的に困難です。
行の区切り文字やカラムの順序が変わっただけで、処理全体が破綻するリスクを常に抱えることになります。

パースとシリアライズの繰り返しが生むオーバーヘッド

パイプライン処理では、コマンドを|で繋ぐたびに、標準出力への書き込みと標準入力からの読み込みが発生します。
テキストストリームであれば、このコストは比較的小さく済みますが、構造化データを扱う場合には事情が異なります。

構造化データをパイプラインで受け渡す場合、各ステージで以下のような処理が繰り返されることになります。

構造化データをテキスト、あるいはバイナリ形式にシリアライズする
次のプロセスがそれを読み込み、再びオブジェクトとしてデシリアライズする
加工を行った後、再びシリアライズして次のステージへ渡す

このパースとシリアライズの往復は、単純に見えて無視できない計算コストです。
特に、ネストの深いJSONデータや大量のレコードを扱う場合、このオーバーヘッドは処理全体のレイテンシを大きく圧迫する要因になります。

さらに厄介なのは、この過程で型情報が失われやすいという点です。
一度テキストへ変換されたデータは、再度パースするまでその構造を保証できません。
結果として、実行時になって初めて型の不整合が発覚するという、本質的に脆弱な処理パイプラインが出来上がってしまうのです。

このように、構造化データとテキストストリームの間には、単なる表現形式の違いを超えた、処理コストと安全性の両面における根本的なミスマッチが存在していると言えるでしょう。

型安全性の欠如がシステムにもたらすリスク

前章では、構造化データとテキストストリームの間に存在するミスマッチについて論じました。
本章では、その延長線上にある問題として、型安全性の欠如がシステムの信頼性にどのような影響を及ぼすのかを掘り下げていきます。

動的型付けゆえのバグの温床

パイプライン処理において受け渡されるのは、あくまでテキストという無型のデータです。
各コマンドやスクリプトは、受け取った文字列を実行時に解釈し、必要な値を取り出したうえで処理を行います。
この構造は、シェルスクリプトだけでなく、動的型付け言語で書かれたデータ処理コードにも共通して見られる問題です。

例えば、以下のようなPythonコードを考えてみます。

def calc_total(record):
    return record["price"] * record["quantity"]

このコードは、priceとquantityが正しく数値として渡される限り問題なく動作します。
しかし、上流のパイプラインで形式が変わり、priceが文字列として渡されてきた場合、このコードは実行されるまでエラーに気づくことができません。

動的型付けの言語やスキーマレスなデータ構造には、以下のような共通のリスクが潜んでいます。

型の不整合が実行時まで検出されない
テストケースで網羅しきれないデータパターンによって、本番環境で初めて不具合が顕在化する
リファクタリング時に、影響範囲を静的解析だけで把握することが困難である

これらは、開発初期のスクリプトのように小規模で使い捨てのコードであれば許容できる場合もあります。
しかし、長期間運用される大規模システムにおいては、致命的な障害の原因になりかねません。

スキーマレス設計と品質担保のトレードオフ

スキーマレスな設計には、開発初期のスピード感を高めるという明確な利点があります。
データ構造を事前に厳密定義する必要がなく、柔軟に仕様変更へ対応できるため、特にプロトタイピングの段階では重宝されます。

一方で、この柔軟性は品質担保の観点からは大きなトレードオフを伴います。
以下の表は、スキーマレス設計とスキーマ駆動設計における品質担保のアプローチの違いを整理したものです。

観点	スキーマレス設計	スキーマ駆動設計
不整合の検出タイミング	実行時	コンパイル時・ビルド時
ドキュメントとしての役割	別途整備が必要	スキーマ自体が仕様書になる
変更時の影響範囲把握	手動での確認が中心	静的解析によって自動化しやすい

このように整理すると、スキーマレス設計は初速を優先する代わりに、品質担保のコストを開発の後工程、あるいは運用フェーズへと先送りしているに過ぎないと捉えることができます。
システムの規模が拡大し、関わる開発者の人数が増えるほど、この先送りされたコストは複利的に膨らんでいきます。

型安全性を軽視した設計は、短期的な開発速度と引き換えに、長期的な保守性と信頼性を犠牲にするリスクをはらんでいるのです。
次章では、この課題がさらに並列処理や分散処理という文脈でどのように顕在化するのかを見ていきます。

並列処理・分散処理とパイプラインの相性を検証する

前章までで、構造化データとの相性、そして型安全性という二つの観点からパイプライン処理の課題を確認してきました。
本章では、これらの問題がさらに深刻化する領域として、並列処理と分散処理の文脈におけるパイプラインの限界を検証していきます。

ストリーム指向設計がスケールしにくい理由

UNIXパイプラインは、本質的に単一ホスト上での逐次的なデータフローを前提とした設計です。
|で接続された各プロセスは、確かにOSレベルでは並行して動作しますが、その並行性はあくまでパイプの前後関係に縛られたものであり、真の意味での水平スケーリングとは異なります。

分散システムにおいてスループットを向上させるためには、以下のような要件を満たす必要があります。

データを複数のノードへ動的に分割し、並列に処理できること
各ノードの処理結果を、順序性を保ちながら、あるいは意図的に順序を無視して集約できること
一部のノードで障害が発生しても、処理全体を継続できる耐障害性を備えていること

ストリーム指向のパイプライン設計は、これらの要件のいずれに対しても親和性が低いという特徴があります。
特に、あるステージの処理結果を次のステージが逐次的に待ち受けるという構造そのものが、ノード間の負荷分散や動的なスケールアウトを難しくしています。
プロセス間の依存関係が強く結びついているため、一部のボトルネックが全体のスループットを引きずり下ろしてしまうのです。

バッチ処理との比較から見える設計の分岐点

このような課題を踏まえると、大規模データを扱う現代のシステムでは、逐次的なストリーム処理ではなく、バッチ処理を前提とした分散処理フレームワークが選ばれる場面が増えているのも自然な流れです。

以下の表は、ストリーム指向のパイプライン処理と、分散バッチ処理の代表的な違いを整理したものです。

観点	ストリーム指向パイプライン	分散バッチ処理
処理単位	行単位・逐次処理	データセット全体をまとめて処理
並列化の粒度	プロセス単位に限定	データパーティション単位で柔軟に分割
耐障害性	障害時の再実行が困難	タスク単位での再実行が容易

もちろん、バッチ処理が万能というわけではありません。
リアルタイム性が求められる用途では、ストリーム処理の考え方自体は依然として有効です。
ただし、その場合であっても、単純なテキストパイプラインではなく、型付けされたイベントストリームを扱う専用のフレームワークを用いるのが一般的になっています。

重要なのは、処理対象のデータ量や求められるリアルタイム性、耐障害性の要件に応じて、逐次的なパイプラインと分散バッチ処理を適切に使い分ける視点です。
UNIX哲学が前提としていた単一ホスト内の逐次処理モデルを、そのまま大規模分散環境へ適用しようとすること自体に、そもそも無理があると考えるべきなのかもしれません。

型安全とスキーマを重視した現代的なシステム設計

これまでの章では、パイプライン処理が抱える構造的な課題を、データ構造、型安全性、そして並列分散処理という三つの観点から検証してきました。
本章では、これらの課題に対する現実的な解決策として、型安全とスキーマを重視した現代的なシステム設計のアプローチを紹介します。

スキーマ駆動開発という選択肢

スキーマ駆動開発とは、データの構造をコードよりも先にスキーマとして明示的に定義し、そこからコードやドキュメントを生成していくという開発手法です。
この手法の核心は、データの契約を人間の解釈に委ねるのではなく、機械的に検証可能な形式で固定してしまう点にあります。

代表的な実装として、以下のような技術が挙げられます。

Protocol BuffersやAvroによるバイナリシリアライズのスキーマ定義
GraphQLにおけるスキーマファーストなAPI設計
OpenAPI(Swagger)によるREST APIのインターフェース定義

これらに共通しているのは、スキーマそのものが単一の情報源(Single Source of Truth)として機能し、送信側と受信側の双方がそのスキーマに従ってコードを生成、あるいは検証できるという点です。
テキストストリームのように、受け取った側が独自の解釈でデータを読み解く必要がなくなるため、パイプライン処理で問題となっていた不整合のリスクを設計段階で大幅に排除できます。

静的型付け言語とORMによる恩恵

スキーマ駆動開発と相性が良いのが、静的型付け言語による実装です。
TypeScriptやRust、Kotlinのような言語では、データ構造をコンパイル時に厳密に検証できるため、実行時になって初めて型の不整合が発覚するという事態を未然に防げます。

例えば、TypeScriptでは以下のようにインターフェースを定義することで、構造化データの形状をコード上で明示できます。

interface User {
  id: string;
  name: string;
  roles: string[];
}

function greet(user: User): string {
  return `Hello, ${user.name}`;
}

このように型を明示しておくことで、User型に合致しないデータが渡された時点で、実行前のコンパイル段階でエラーとして検出できます。

また、データベースとのやり取りにおいては、ORM(オブジェクト関係マッピング)の活用も型安全性を高める有効な手段です。
ORMを用いることで、テーブルのスキーマとアプリケーションコード上のモデルクラスを一致させ、SQLクエリの結果を型付きのオブジェクトとして扱えるようになります。
生のSQL文字列を組み立てて実行するアプローチと比較すると、カラム名の誤りやデータ型の不一致といった問題を、開発の早い段階で発見しやすくなるという利点があります。

パイプライン処理が前提としていたテキストベースの緩やかな結合とは対照的に、スキーマと型を軸とした厳格な契約に基づく設計こそが、現代の複雑なデータ構造とシステム規模に適したアプローチだと言えるでしょう。

UNIX哲学不要論は本当に正しいのか

ここまで、パイプライン処理やUNIX哲学が現代のデータ構造との間に抱える課題を、さまざまな角度から論じてきました。
しかし、これらの課題を根拠に「UNIX哲学はもはや不要である」と結論づけるのは、いささか性急な議論だと私は考えています。
本章では、一度立ち止まってこの主張の妥当性を検証してみたいと思います。

パイプライン処理が今も有効なユースケース

まず確認しておくべきは、パイプライン処理が今なお高い実用性を発揮する場面が数多く存在するという事実です。
特に、以下のようなユースケースにおいては、その有効性は現在でも揺らいでいません。

ログファイルの調査やサーバー運用における一時的なテキスト解析
CI/CDパイプラインにおける、ビルド・テスト・デプロイといった一連のタスクの連結
小規模なデータに対する、使い捨てのアドホックな集計作業

例えば、サーバーの障害調査でエラーログを素早く絞り込みたい場合、以下のようなコマンドは今でも非常に強力な手段です。

journalctl -u myapp --since "1 hour ago" | grep -i "timeout" | wc -l

このようなケースでは、スキーマを定義してコードを書き、コンパイルして実行するというプロセスは、むしろ過剰なオーバーヘッドになりかねません。
パイプライン処理の持つ即時性と簡潔さは、探索的なタスクにおいて依然として代えがたい価値を持っています。

哲学の否定ではなく設計思想のアップデート

ここで重要なのは、UNIX哲学そのものを全面的に否定することと、その適用範囲を見直すことは、まったく別の議論だという点です。
「一つのことをうまくやる」という単一責任の原則は、現代のマイクロサービス設計やモジュール分割の思想にも脈々と受け継がれています。
問題の本質は、この原則自体にあるのではなく、「テキストストリームが普遍的なインターフェースである」という、もう一方の前提が現代のワークロードに合わなくなってきている点にあります。

つまり、私たちに求められているのは、UNIX哲学を捨て去ることではなく、その適用範囲を正しく見極めることだと言えます。
小規模かつ探索的なタスクにはパイプライン処理を、大規模かつミッションクリティカルなシステムにはスキーマ駆動の型安全な設計を、というように、課題の性質に応じて設計思想を使い分ける姿勢こそが求められているのです。

不要論というセンセーショナルな主張の裏側には、こうした地に足のついた設計思想のアップデートという、より本質的な議論が横たわっていると私は考えています。

実務で使えるアーキテクチャ選定の判断基準

これまでの議論を踏まえると、パイプライン処理とスキーマ駆動設計のどちらか一方を絶対視するのではなく、状況に応じて適切な選択を行うことが重要だと分かります。
本章では、実務でアーキテクチャを選定する際に、具体的にどのような判断基準を用いればよいのかを整理していきます。

プロジェクト規模・データ量から考える設計指針

アーキテクチャの選定において、まず考慮すべきはプロジェクトの規模と扱うデータ量です。
以下の表は、想定される状況に応じた設計方針の目安を整理したものです。

状況	推奨されるアプローチ	理由
個人の検証やアドホックな集計	パイプライン処理	即時性が高く、実装コストが極めて低い
中規模のWebアプリケーション	静的型付け言語 + ORM	開発速度と保守性のバランスが取りやすい
大規模分散システム・基幹システム	スキーマ駆動開発 + 型安全な言語	長期的な保守性と信頼性を優先すべきである

このように整理すると、判断基準は単純にプロジェクトの規模だけでなく、そのシステムがどの程度長期間にわたって運用され、どれだけ多くの開発者が関わるのかという観点からも検討する必要があることが分かります。
短命なスクリプトであれば、型安全性への投資は過剰なコストになりがちです。
一方で、数年単位で運用され続ける基幹システムであれば、初期投資としてスキーマ定義や型設計にコストをかけるほうが、結果的にトータルコストを抑えられる場合が多いと考えられます。

クラウドネイティブ環境における現実的な落とし所

クラウドネイティブな環境でシステムを構築する場合、コンテナオーケストレーションや分散メッセージングとの親和性も、アーキテクチャ選定における重要な判断材料になります。

現実的な落とし所として、私は以下のような使い分けを推奨しています。

サービス間の永続的な通信は、Protocol BuffersやOpenAPIによるスキーマ駆動のインターフェースを用いる
コンテナのビルドやデプロイといった運用タスクは、シェルスクリプトによるパイプライン処理を活用する
ログ集計やモニタリングなど探索的な分析には、必要に応じてパイプライン的な手法を併用する

例えば、Kubernetes環境でのデプロイスクリプトでは、以下のようなパイプライン処理が今なお日常的に使われています。

kubectl get pods -n production | grep -v Running | awk '{print $1}'

このように、システムの中核となるビジネスロジックやサービス間通信には型安全な設計を採用しつつ、運用や調査といった周辺タスクにはパイプライン処理の簡便さを活かすというハイブリッドな構成こそが、現実的かつ持続可能な選択だと言えるでしょう。
重要なのは、思想的な純粋さを追求することではなく、目の前の課題に対して最も合理的な手段を選び取る姿勢なのです。

まとめ:パイプライン処理の限界とこれからのシステム設計

ここまで、パイプライン処理とUNIX哲学が現代のシステム設計において直面している課題を、複数の観点から検証してきました。
最後に、本記事全体の議論を振り返りながら、これからのシステム設計に向けた実践的な指針を整理していきたいと思います。

UNIX哲学が生まれた1970年代と現代とでは、扱われるデータの量、構造、そしてシステムの規模があまりにも異なっています。
当時想定されていたのは、せいぜい数メガバイト規模のフラットなテキストデータでした。
しかし現代のシステムは、JSONやProtocol Buffers、Parquetといったネスト構造を持つ構造化データを、ペタバイト単位で扱うことも珍しくありません。
この前提の変化こそが、パイプライン処理の限界が語られるようになった最大の要因だと言えるでしょう。

本記事で確認してきた課題を、改めて整理すると以下のようになります。

構造化データとテキストストリームの間には、パースとシリアライズを繰り返す構造的なオーバーヘッドが存在する
動的型付けやスキーマレスな設計は、型の不整合を実行時まで検出できないという品質上のリスクを抱えている
ストリーム指向の逐次処理は、並列分散処理やマイクロサービスアーキテクチャとの相性が本質的に良くない

これらはいずれも、UNIX哲学そのものの欠陥というよりも、「テキストストリームこそが普遍的なインターフェースである」という前提が、現代のワークロードにそぐわなくなってきていることに起因する問題です。

一方で、パイプライン処理を全面的に否定することもまた、誤った結論だと私は考えています。
ログ調査やCI/CDの運用タスクのように、即時性と簡潔さが求められる場面では、パイプライン処理は今なお極めて有効な手段です。
重要なのは、思想的な二項対立に陥ることなく、課題の性質に応じて適切な設計を選び取る姿勢です。

実務における現実的な指針としては、以下のような使い分けが有効だと考えられます。