「わかりやすさ」「説得力」は有害（Harmful）である

はじめに

「わかりやすさ」「説得力」は有害（Harmful）である^[1]

最初に告白しておくと、このタイトルは耳目を集めるための挑発である。
一般に「良い」とされている概念に対して強い否定の言葉を用いることで、注意を引く狙いだ。

だが、本稿の狙いは逆張りそのものではない。「わかりやすさ」「説得力」といった美辞麗句の下に、不確実さや曖昧さがどのように隠されているのか、その構造を検討することである。
つまり批判の対象は、「わかりやすさ」「説得力」そのものではなく、それを上位の評価軸として掲げた結果、不透明性を正当化する構造である。

本稿では、そうした態度が具体的にどのような問題を生むのかを確認したうえで、それに対する代案として「透明性の倫理」という考え方を提示する。

なぜ「わかりやすさ」「説得力」が害を生むのか

少なくとも私の見てきた日本語圏のソフトウェア技術記事では、「わかりやすい説明」がしばしば上位価値として扱われてきた。 「説得力のある説明」もまた、テキストの「価値」を高め、より多くの人に主張内容を受け入れてもらうために重要なものとみなされてきた。

書籍・ブログ・入門記事の多くが、「わかりやすく」「説得力がある」テキストを書くことで、「読者が理解した“気”になれること」を目標としている。実際、ネットを見ても「わかりやすく説明する方法」「わかりやすい説明にする方法」などを解説する記事が散見される。

しかし、この「わかりやすさ」「説得力」が、構造的に誤解を生む場面がある。
以降では、いくつかの例を踏まえてその構造を説明していく。また、例について説明する際に参照した資料は、本稿末尾に参考資料として列挙している。

観点1. 比喩は概念を削り、滑らかさと引き換えに本質を歪める

わかりやすさを優先すると、説明に不要とみなされた部分は切り捨てやすくなる。

わかりやすい説明として頻繁に用いられる比喩は、 概念の一部を切り落とし、ときには置き換える ことで成立する。そのため、比喩がうまく聞こえるほど、本来の概念から離れていく危険がある。

ここでは代表例として 「クラスは設計図、インスタンスは製品」 という比喩を取り上げたい。これは入門記事の定番比喩だが、オブジェクト指向における実際の関係・位置づけとは乖離している。以下では、その乖離を3つの点から整理する。

問題1. クラスは固定された静的存在ではない

「設計図」は通常、変更されない前提で語られる。
しかし現実のオブジェクト指向プログラミング言語（以下、OOPL）の中には、クラスは 動的に再定義可能 であり、メタクラスを通じて構造や振る舞いを後から変更できるものも存在する。

例えばSmalltalk 系のOOPL、あるいはRubyでは、クラス自身も“オブジェクト”であり、動的操作の対象だ^[2][3]。その他、JavaScriptにおけるclassもその実態は「特殊な関数」オブジェクトであるから、やはり動的操作が可能である^[4]。

クラスを「設計図」として例えた時、そこではクラスそれ自体の動的性質（メタプログラミングや、実行時再定義の可能性など）は切り捨てられて語られている。

問題2. インスタンスは受動的な“製品”ではない

製品は通常、能動的に振る舞いを持たない物体である。
しかしオブジェクト指向におけるインスタンスは メッセージに応答し、主体として振る舞うというのが本義である。

“製品”という比喩を用いている場面では、オブジェクトの主体性・自律性は無視されている。

問題3. クラスとインスタンスは一方向の固定関係ではない

現実のオブジェクト指向では、言語にもよるが、継承・プロトタイプチェーン・ミックスイン・トレイトなど多様な構造が存在する。
“設計図 → 製品”のような一方向・1対1の関係では説明できない。

特にRubyやSmalltalkのような「クラスもまた別のクラス（メタクラス）のインスタンスである」というある種の再帰的な構造は、設計図と製品という静的・一方向の関係ではほとんど捉えられない。

---

一見わかりやすい比喩ほど、本質を切除し、理解を固定化し、思考の幅を狭める危険がある。比喩は「類似点に着目して語る」という性質上、どうしてもこうした情報の切り捨てが発生するからだ。
しかし「わかりやすい」ことを上位の価値と位置づけてしまうと、こうした危険を無視ないし矮小化することを正当化する口実となってしまう。

比喩それ自体を全面否定したいわけではない。入門フェーズでの粗い足場としては有用な場面もある。
ただし本来は、その後に「ここから先は比喩を捨てよう」「この比喩では表現しきれない部分がある」という更新フェーズが必要だ。
その更新を怠ったまま比喩だけを量産すると、そこで理解が固定化される。

観点2. 説得力は、内容の正しさとは無関係に操作できる

説得力を指標にすると、『どれだけ正しいか』より『どれだけ筋が通っているように見えるか』が先に評価される。

説得力とは、内容の正しさではなく 読者が受け取る印象の強さ である。「説得力」とは「印象操作」と切り離せない側面も持っている。そのため、論理が粗かったり根拠が薄かったりしても、「説得力がある文章」は書けてしまう。

たとえば次の文章を考える。

関数型言語では副作用は禁止されている。
なぜなら、副作用は状態を乱し、バグの原因になるからだ。

関数型プログラミング言語に明るくない人にとっては、説得力を持った文章として映るだろう。
しかし、実際には以下の問題がある。

問題1：前提が誤っている

関数型言語は「副作用を禁止」しているというのは、少なくとも一般化としては正確ではない。
副作用を 分離 したり、明示 する仕組みを持っていることは多いが、これらはいずれも「禁止」とは異なる。

例えばHaskellでは入出力という副作用を IO モナドの型の中に閉じ込め、純粋な計算と副作用を型レベルで分離している。入出力という副作用の利用そのものが「禁止」されているわけではない。^[5][6]

文章の“強さ”が内容の“正しさ”を保証しない典型例と言える。

問題2：論理構造が曖昧でも「筋が通っているように見える」

「Aは禁止されている。なぜならBだからだ。」

安易に用いられがちなこの形式自体が、一見しての“確からしさ”を演出してしまう。しかし実際には、以下の問題がこの一文には混在している。

• 「副作用を禁止している」という事実誤認
• 「副作用は状態を乱す」という一般論
• 「ゆえに禁止」という飛躍

それでも関数型言語に明るくない読者なら、文章のリズムだけで「なるほど」と感じやすくなってしまう。

問題3：根拠の薄弱さが隠される

この文章には情報源が示されていないが、説得力は、しばしば情報源の欠如すら隠してしまう。これを濫用すれば、「根拠は薄弱にもかかわらず、他人の心情に訴えかける説得力あるテキスト」が作成できてしまう。

---

説得力は、論理と独立した“印象操作”である以上、それに頼った説明を行ったり、それに頼った説明を鵜呑みにするのは危険である。

観点3. 情報源の不透明性が隠蔽される

“誰が言ったか”を添えるだけで説得力が増す文化では、「書名＋偉い人の名前」だけでもう十分だと見なされやすい。
そして「細かいページ番号や節までは書くと読みにくい」という理由で、“わかりやすさ”の名目で細部が削られていく。

「◯◯とは〜〜である。X氏が提唱した。」

この形式の文章は、あたかも一次情報をきちんと参照しているかのような印象を与える。しかし、実際にどの文献のどの箇所を見たのか が示されなければ、そこには不透明性がある。

ここでは、特にドメイン駆動設計（以下、DDD）文脈で頻出する「値オブジェクト」を具体例として扱う。値オブジェクトについて、以下のような説明を考えてみる。

プリミティブ型をクラスで包み、immutableにしたオブジェクトが、値オブジェクトである。
これはMartin Fowlerによって提唱された。

この説明も一見してもっともらしく、近しい説明すら見かけることがある。しかし出典を実際に辿っていくと、この定義は少なくとも不必要に狭い定義であると言って良い。

問題1. 「等価性」という概念が、二次情報で欠落する構造

Martin Fowlerによる著作『エンタープライズアプリケーションアーキテクチャ』（以下PoEAA）の「バリューオブジェクト」を参照してみよう。

ID に基づいた等価性を確保していない、Money やDate Range などのシンプルな小型オブジェクト。
(中略)
参照オブジェクトとバリューオブジェクトの主な相違点は、等価性の処理の方法である。(中略)バリューオブジェクトの等価性の概念はクラス内のフィールド値に基づいている。2つのDateオブジェクトで日、月、年の値が同じ場合は、等価ということになる。^[7]

先に提示した説明例では「等価性」という性質への言及は含まれていない。結果「出典を遡らない限り、"等価性"という中心概念にはたどり着けない」という事態に陥っている。

問題2. 実装スタイルが「定義」として誤読される構造

今度は、DDDの提唱者であるEric Evansの著書『エリック・エヴァンスのドメイン駆動設計』（以下、エヴァンス本）を参照してみる。

あるオブジェクトが、ドメインにおける記述的な側面を表現し、概念的な同一性を持たない場合、そういうオブジェクトは、値オブジェクトと呼ばれる。
(中略)
値オブジェクトは、他のオブジェクトが組み合わされてできていることもある。
値オブジェクトはエンティティを参照することもできる。^[8]

エヴァンス本によれば、値オブジェクトはそれ自体複数のオブジェクトで構成されることもありうるのだから、「プリミティブ型をクラスで包む」という記述は不必要に定義を狭めている。
ここでは「出典を遡らない限り、本来不要な制約に縛られてしまう」という事態が生じている。

問題3. 推奨レベルの話が「必須条件」に格上げされる構造

Martin Fowlerのブログ"martinFowler.com"にも、Value Objectについての言及がある。

To avoid aliasing bugs I follow a simple but important rule: value objects should be immutable. If I want to change my party date, I create a new object instead.
(中略)
While immutability is my favorite technique to avoid aliasing bugs, it's also possible to avoid them by ensuring assignments always make a copy. Some languages provide this ability, such as structs in C#.^[9]

Fowler自身によっても、immutableにするのはあくまでオブジェクトを共有する際の不具合を回避するための一つの手法であり^[10]、immutableにする以外の方法として、「常にコピーを生成する(it's also possible to avoid them by ensuring assignments always make a copy)」もはっきりと認められている。

ここでは、原典では「should」だった要素が二次情報では「must」に変化しているという、やはり出典を遡って初めて発見できる問題が隠れている。

---

ここまで、例として出した「値オブジェクトの定義」にどのような問題があるかを述べてきた。しかしながら、二次情報・三次情報ではしばしば次のような縮約が起きる。

1. 一次情報の文脈を削り、「値オブジェクトは immutable にすべき」という一文だけが切り出される
2. さらにそれが、「プリミティブを包んだ immutable クラス」という実装スタイルの一案と結びつく
3. やがて、「値オブジェクト＝プリミティブラッパ＋immutable」が“定義”として扱われるようになる

この過程で、「等価性を値によって判断する」「オブジェクトも含めた複合体として構成可能である」「共有時の問題を回避するためのimmutable」といった本来の情報は失われてしまう。

その結果、次のような現象が起きる。

• ドメイン内のあらゆる整数や文字列を、専用クラスで機械的に包むだけの「値オブジェクト大量生産」が始まる
• それを「原典がそう言っているから」という形で正当化しようとする
• しかし、どのページのどの記述を根拠にしているのかは示されない

ここでは、その意図の有無によらず、「誰かの解釈」が「原典の主張」として権威化される という事態が生じている。
しかし、一次情報へ辿るための手がかり（書名、ページ数）が提示されないため、読者はその解釈が妥当かどうかを自力で検証しにくい。

本来であれば、「どの資料の」「どこの箇所の」「どの記述を」どのように読んで「値オブジェクト」を理解したのかを、最低限でも示すべきである。それを省略したまま「◯◯とは〜〜であり、X氏がそう言っている」とだけ書くことは、意図的にせよ、結果的にせよ、情報源の不透明性で読者を騙す構図になりうる。
情報源が曖昧な説明は、「理解した“つもり”」だけを量産し、読者から「自分で確かめる手段」と「疑う権利」を奪ってしまう。

まとめ：なぜ「わかりやすさ」「説得力」が害を生むのか

そしてここまで扱ってきたのは、「わかりやすさ」や「説得力」そのものではない。それらが不透明性と結びついたときに何が起こるかである。

比喩は情報を丸めて滑らかにする一方で、多くの情報を暗黙的に削り捨ててしまう。
説得力は、その一見した尤もらしさによって、論理の脆弱さや根拠の薄弱さを覆い隠してしまう。
引用先の欠落によって、誰かの解釈が権威を伴って広まり、しかしその原典へのアクセスは困難になってしまう。

結果として、「理解した気分」だけが加速し、「実際の理解」は置き去りになる。

わかりやすさと説得力は、必ずしも良い結果を招かない。むしろ、「わかりやすさ」「説得力」が不透明性を伴うとき、それは誤解を固定化し検証の回路を断つという事態をもたらす。

ここで問題にしたいのは、こうした不透明性を意図的に利用している場合である。能力不足や時間的制約による不備まで、ただちに道徳的非難の対象にしたいわけではない。どこまでを「仕方ない不備」とみなし、どこからを「不透明性の利用」と見なすか、その境界線はなお検討の余地がある。

ただしその事態を意図的に起こすなら、それは『読む側に誤解が生じても構わない／検証できなくても構わない』という前提を飲ませることであり、その意味で倫理的な問題にもなってくる。

ただ、他人のテキストについて「それを意図してやっているかどうか」を外側から判定することはほぼ不可能だ。
実務上問題になるのは、意図の有無ではなく、結果として「限界・範囲・出典が一体化して不透明になっている状態」そのものである。
本稿で「倫理」と呼んでいるのは、最終的にはこの状態を避けるための、外形的にチェック可能なルールの集合である。

---

さて、ここまで見てきた問題はいずれも、「不透明性」という概念に収束する。「不透明性」は、より具体的には次の三つに分解できる。

• どこまで調べたか・どこからが推測かが伏せられている（限界の不透明性）
• 資料の記述と、自分の解釈・主張の境界が曖昧である（範囲の不透明性）
• どの資料のどの箇所を読んでいるのかが示されない（出典の不透明性）

次節では、「不透明性」に対する対策としての「透明性の倫理」について述べる。

「透明性の倫理」とは何か

本稿で「透明性の倫理」と呼ぶのは、端的に言えば次の態度である。

自分の限界と、自分の範囲を明示せよ。

これは読者のためであると同時に、書き手自身のためでもある。
読者には判断材料を提供し、書き手には「わかったふり」を強要する圧力から距離を置く余地を与える。
文化的には、誤読の固定化や、権威が安易に利用される構造を抑制する働きを持つ。

前節で挙げた三つの不透明性に対応するかたちで、「透明性の倫理」は次の三つの実践として整理できる。

• 限界の不透明性に対して：どこまで調べたか・どこからが推測かを示す「限界の開示」
• 範囲の不透明性に対して：事実と解釈と主張を分ける「範囲の開示」
• 出典の不透明性に対して：出典を示しつつ、権威と自分の主張を混ぜない「権威と主張の切断」

以下では、この倫理を構成する三つの要素を順に確認していく。

1. 限界の開示 —— 不確実性を隠した瞬間、文章は正しさを装い始める

限界の開示とは、「どこまで確認し、どこから先が未解明か」「どの部分に推測が混ざっているか」を明示する態度を指す。

限界を隠すと何が起きるか

限界が隠されると、書き手と読者の認識が不均衡になる。

• 読者は、筆者が“そこまで把握した上で書いている”と受け取る
• 仮説や未検証の記述が、確立した知識のように扱われる
• 曖昧さを隠した書き手が、後から自分の文章を訂正しづらくなる

技術記事の誤解が累積していく背景に、この“隠された不確実性”が紛れ込んでいることは珍しくない。

限界を開示することによって生まれる利点

限界の開示は書き手を弱くするのではなく、むしろ余計な義務から解放する。

• 「ここまでは確認した」
• 「この先はまだ理解が浅い」
• 「一次情報を全て追えているわけではない」

こうした線引きによって、書き手は“不必要な確信”を抱え込まなくて済む。
読者は、どこを信頼し、どこを自分で検証すべきか判断できる。
そして文章が勝手に権威化されることを防げる。

実践方法：限界を明示する

• 「一次資料はこの章まで辿ったが、それ以降は確認できていない」
• 「この段落には推測が含まれる」
• 「背景理解が不足しており、今後改訂の可能性がある」

調査ログ（参照資料・読了範囲・未検証部分）を簡潔に添えるだけでも、読者にとっては十分な指針になる。

2. 範囲の開示（事実と解釈の分離）—— 文脈の混在は、読者の検証可能性を奪う

範囲の開示とは、資料の記述と、自分の解釈・主張を混在させないことである。

事実・解釈・主張は本来別の層にある

他資料を参照する文章は本来、次の三つの層から成る。

1. 事実：資料に書かれている内容
2. 解釈：筆者がその記述をどう読んだか
3. 主張：解釈をふまえて筆者が立てる立場

これらが混ざると、読者は「筆者の解釈」を「資料がそう述べている」と誤解しやすくなる^[11]。
結果として、資料の権威が筆者の主張を裏付けるかのように見える構造が生まれる。

この瞬間、読者の検証能力は奪われる。
何を読めばよいか、どこが事実でどこが意見か、その境界が見えなくなるからだ。

実践方法：構造で区別する

構造的に層を分離するだけで十分である。

> （資料からの引用）

ここから先は私の解釈である。
…

この理解を前提として、以下では私の主張を述べる。

文章がこの構造を保っている限り、読者は自力で検証経路を確保できる。
これが範囲の開示の意義である。

3. 権威と主張の切断 —— 引用は事実であって、主張の根拠の代替物ではない

透明性の倫理の最後の要素は、引用した権威と、自分の主張を混同させないことである。

典型的に発生する誤った構造

よく見られるのは次のような展開である。

私はXだと考える。
Yはこう述べている。
したがって、Xは正しい。

この構造は、Yの文脈と筆者の文脈が一致しない可能性を無視してしまう。
にもかかわらず、読者には「YがXを支持している」ように見える。

権威の借用が危険である理由

• 読者が文脈の差異を検証できない
• 筆者の主張が、根拠を欠いたまま権威をまとって流通する
• 反論者が「これはYへの反論になる」と考えて発言を控え、議論が停滞する

引用は事実の提示であり、主張の論証にはならない。引用した瞬間に主張が強化されるわけではないことに注意しなくてはならない。

実践方法：依拠範囲を制限する

• 「Yはこのように主張しているが、この主張に私も同意している」
• 「Yはこの点について有用だが、私の主張全体を支えるものではない」
• 「Yの意図とは独立に、私はこの結論に至る」
• 「Yはこのように主張しているが、私の主張は逆である」

権威と主張を切り離すことで、読者にとっての検証可能性が維持される。

透明性の倫理がもたらす自由

透明性の倫理は、脚注や引用の手間をゼロにしてくれる魔法ではない。むしろ、ある程度の追加コストは確実に発生する。
しかしその代わりに、「わかったふりをし続ける」という、より重い負荷から書き手を解放する枠組みである。

同時に、読者に対しても自由を与えるものである。どこを信じ、どこを疑い、どこを自分の手で確かめる必要があるか、情報が提供されているからこそそれらを判断できる。

透明性とは、知識を閉ざすための規範ではなく、知識が検証可能なまま自由に流通するための最低限の倫理である。

もちろん、あらゆる記事で一次資料を精査し、すべての引用にページ番号を振るのが現実的ではない場面も多い。商業書であればページ都合、WEBメディアであれば文字数上限といった制約もあるだろう。
その場合でも、「これは自分の解釈である」と線を引くことと、「依拠している資料名を書くこと」の二つは、ほとんどの文脈でコストに対して得られるものが大きすぎる。ここは妥協せず、最低ラインとしてしまってよいと考えている。

次に続く節は、ここで言う「透明性」をできるかぎり前景化する書き方を試した例だ。実務上は、必ずしもここまでやらなくてもよいだろう。
ただ、最低限どの資料に依拠しているかと、自分の解釈との境界線だけは引けるはずだ、というのがここで主張したいラインである。
同時に、「やろうと思えば、少なくともここまで透明にできる」というラインを示すものでもある。

なお、本稿で扱ったトピックについて、調査の射程も同一ではない。
たとえば、関数型言語と副作用の例については Haskell の入門書と haskell.jp の記事を主な対象としており、他の関数型言語や論文レベルの議論までは踏み込めていない。値オブジェクトについては Fowler と Evans の著作、およびそれらを参照する二次資料に依拠しており、DDD関連の他文献は今回の検討では対象外としている。クラスとインスタンスの比喩の例についても、言語仕様やリファレンスをざっと追うにとどまっており、オブジェクト指向研究全体を網羅しているわけではない。

SRPの節だけ透明度が高く見えるのは、実践例としてそこに追加コストをかけた結果であって、本稿全体が同じ水準で網羅的に調査されているわけではない。

「透明性の倫理」実践例：単一責任の原則（SRP）を辿る

単一責任の原則（Single Responsibility Principle, SRP）はソフトウェア設計の基礎原則として語られるが、その“基礎”という言葉とは裏腹に、実際には一次資料を辿らなければ理解が容易に歪む概念でもある。
そして、巷で流通する説明の多くは、文脈と定義の両方を縮約してしまっている。典型的には「単一の責務だけを持つように設計せよ」といった説明だが、そのように要約しつつ、「責務」について何を参照しているか明示しないまま解説しているものも多い。

ここでは透明性の倫理がどのように機能するのか を具体的に示すため、「SRPとは何か」の調査を題材とする。

透明性の倫理に従うなら、まずは次の三つを行う必要がある。

• どこまで調べたか（限界の開示）
• 何が資料の内容で、何が自分の解釈か（範囲の開示）
• 引用した権威と自分の主張を混ぜない（切断）

以下では、この構造に沿って SRP を扱う。

1. 調査範囲の開示（限界の明示）

まず、今回の調査で参照した資料を以下に羅列しておく（実際には、参考資料として列挙しつつ、適宜脚注として参照するでも良いだろう）。

• Robert C. Martin（2003） 『Agile Software Development, Principles, Patterns, and Practices』(Pearson Education)
  • SRPの初出資料
• Robert C. Martin（2014） 『The Single Responsibility Principle』 (The Clean Code Blog)
  • Martin本人によるブログ記事
• Robert C. Martin（2017） 『クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計』(アスキードワンゴ)
  • SRPの定義が「変更理由」から「アクター」へ再解釈されている
• DeMarco & Page-Jones の「凝集度」概念
  • MartinがSRPの源流として挙げるが、該当箇所を確認できていない

2. 一次資料に基づく「事実」の提示

まず、資料に実際に書かれている内容を元に、「SRP」の内容を提示する。

『Agile Software Development（ASD）』におけるSRP

ASDの記述に従えば、SRPのアイデアの源泉は、Tom DeMarcoとMeilir Page-Jonesの著作で説明されている「凝集度」(cohesion) の概念にある。^[12][13]
概念自体は、Martinの説明するところでは DeMarco と Page-Jones の「凝集度」の議論を継承したものらしい。一方で、「Single Responsibility Principle」という命名は、Bertrand Meyerから拝借したようだが、これは本人も記憶が定かではないらしい。^[14]

ASDにおいて “responsibility” はこう定義される。

In the context of the SRP, we define a responsibility to be ‘a reason for change’.^[15]

つまり、SRPにおける「責任」は「変更理由」という言葉によって定義される。

さらに Martin は次のように述べる。

An axis of change is an axis of change only if the changes actually occur. It is not wise to apply the SRP, or any other principle for that matter, if there is no symptom.^[15:1]

ASDにおいて、SRPの「変更の理由」は実際に変更が発生してはじめて「変更の軸」となるのであって、その症状が発生していない内から適用するのは賢明でない（not wise）としている。

また、永続化とビジネスルールの分離については次の記述がある。

The Employee class contains business rules and persistence control. These two responsibilities should almost never be mixed. Business rules tend to change frequently, and though persistence may not change as frequently, it changes for completely different reasons.^[16]

ビジネスルールは頻繁に変更される傾向にあるが、永続化はそれほど頻繁に変更されなくとも、全く異なる理由で変更される。故に、この2つはほぼ混ぜるべきでないとしている。

『Clean Architecture（CA）』（2017）における再定義

CAでは、SRPが次のように定義を変更されている。^[17]

モジュールは、たったひとつのアクターに対して責務を負うべきである。

ここで言う「アクター」とは、変更を望むユーザーやステークホルダーの集合のことだ。
ASDでは「変更理由」という抽象的な軸だったものが、CAでは「組織上のアクター」という具体的な軸へと再構築されている。

3. SRPとその変遷について（解釈）

ここからは、上記の事実を踏まえたうえで、ASD・CAそれぞれのSRPに対する解釈を述べる。

ASDのSRPは「技術的依存の爆発回避」が中心にある

ASDの説明は、複数の変更理由を抱えたモジュールが「再ビルド」「再テスト」「再デプロイ」などのコストを同時に引き起こすことを避ける、という意図が基盤にある。^[18]これは「凝集度」に近い古典的設計思想である。

Clean Architecture の「アクター」概念は具体化による取りこぼしを起こす

CAのSRPは「アクター単位で責務を持たせる」という具体的な枠組みになっている。本書の例を用いると、「雇用者の情報を保存する処理はDB管理者が規定するから、関連するアクターはCTOである」「雇用者の給料を計算する処理は経理部門が規定するから、関連するアクターはCFOである」といった具合である^[19]。

しかし、更新内容が「雇用者の給与テーブル変更反映」である場合はどうなるのだろうか。

• DBの更新は技術的責務 → CTO がアクター
• 給与情報は経理的責務 → CFOがアクター

技術的変更と業務的変更が絡むケースでは、アクター単位の切り分けは曖昧になる。しかしそれでも「アクター」という単位に拘るのであれば、「CTO に報告するか / CFO に報告するか」といった組織図ベースの線引きに引きずられて、変更理由そのものから線を引く余地は狭くなる。
私の理解の範囲では、CA の具体化によって、ASD が持っていた抽象度の高さと柔軟性は部分的に失われてしまっている。

以上は、現時点で入手できた記述から私が再構成した理解であり、Martinがアクターによる再定義に踏み切った背景や、どこまでを包含範囲として想定していたのかまでは把握しきれていない。
そのため、この時点での評価は暫定的なものであることを付記しておく。

SRP は「名称は同じでも指す概念が揺らいでいる」

ASDとCAは、その定義の変更によって、単なる言い換えにとどまらずその概念自体が揺らいでいる。

• ASD：技術的依存の制御（変更理由）
• CA：組織構造に基づく責務整理（アクター）

この差異を無視して「SRPとは◯◯である」と一般化すると、SRPの説明は混乱を生じる。ASDに依拠した人とCAに依拠した人とで、会話が噛み合わないおそれもある。

4. SRPに対する評価

ここからは、事実や解釈とは独立した筆者の評価である。

SRPは「単一責任の原則」という平易な言葉で構成されているが、その内実は、ASDとCAのいずれを参照するにせよ、その名称からはやや乖離がある。
「責任」という言葉を一般的な語彙として捉えてはならない。その曖昧さによって混乱が生じてしまうからだ。
ASD基準ならば「変更の理由」と、CA基準ならば「アクター」と、依拠するものに応じて適切な言葉を通じて理解する必要がある、やや複雑な背景を持つ言葉である。

この変遷は、少なくとも次のことを示している。

• 「単一責任の原則」というラベルの下で、異なる軸の概念が語られうること
• どの版の SRP を前提にしているかを明示しない議論は、構造的に噛み合わなくなること

それ以上の「良し悪し」の判断については、ここでは保留する。
ここで重視しているのは、同じSRPという名前が付いているからといって、同じ概念が共有されているとは限らない、という点である。

少なくとも、「SRPとはXである」と断定したくなったときには、自分がASDの定義に立っているのか、CAの定義に立っているのか、そのどちらとも違う自分なりの再解釈なのかだけは、読者が判断できる形で示しておく必要がある。

---

• 何をどこまで調べたか
• どの文献のどの記述を根拠にしているか
• どこから先が筆者の解釈か

これらを開示しなければ、SRP のような歴史的に変動してきた概念は瞬時に縮約され、単純化された“わかったつもり”だけが流通する。

透明性の倫理は、この縮約を防ぐ有力な方法である。

まとめ：「透明性の倫理」実践例

SRP は、技術書やブログでも頻繁に参照される原則の一つだ。しかし、原則が広く流通すればするほど、定義の揺れや縮約が累積しやすい。

• 「責任」が曖昧語に戻される
• 「変更理由」という当初の定義が忘れられる
• 「変更理由」から「アクター」という概念の変遷が無視され、技術的文脈と組織的文脈が混ざる

こうした混乱は、一次資料を参照しないまま説明を続ける文化のなかで自然発生する。

透明性の倫理は、曖昧さや限界を隠さないことで、概念そのものの健全性を守るための防波堤としても機能する。
SRPを題材にすると、その構造がよく見える。SRPに限らず、知識は本来こうした透明性の上で初めて理解可能になる。

結び：透明性は、書き手と読み手の自由を守る

透明性の倫理は、書き手を縛るための規律ではない。
むしろ、断言圧力や完璧主義から書き手を解放する枠組みである。

• 「ここまではわかっている」
• 「ここから先は推測だ」
• 「この部分は一次資料をまだ追えていない」

限界があるなら、そう書いてよい。そう書くことで、読者はどこを信じ、どこを疑い、どこを自分で調べるべきか判断できる。
わかりやすさと説得力、いずれもそれ自体が悪ではない。しかし、透明性を欠いた説明は、たとえ滑らかであっても理解の役に立たない。

わかりやすさや説得力そのものを捨てる必要はない。
ただし、それらは「透明性の上に積み増すもの」として扱うべきだろう。

この記事自体も、挑発的なタイトルや強めの言葉を使うことで、ある種の「説得力」を狙っている。
そのうえで、どの範囲で何を根拠にしているかをできるかぎり開示しようとしている。
ここで言いたいのは、「わかりやすさや説得力を捨てよ」ではなく、「わかりやすさや説得力より先に、透明性のラインを引け」という順序の話である。

まずどの範囲で何を根拠にしているかを開示し、そのうえで必要であれば比喩やレトリックで読みやすさを調整する。
順序を逆転させ、「わかりやすさ」「説得力」の名のもとに不透明性を飲み込ませた瞬間に、この記事で述べてきた問題が立ち上がる。

境界線と限界が明示された場所にこそ、理解の可能性が生まれる。

この倫理は、個々の書き手だけの問題ではなく、そうした説明を評価し、模倣し、引用する側の文化の問題でもある。

参考資料

• "Go To Statement Considered Harmful"
  • https://dl.acm.org/doi/10.1145/362929.362947 2025-12-08 15:15閲覧
• 6.12.3 The truth about metaclasses - GNU Smalltalk User’s Guide
  • https://www.gnu.org/software/smalltalk/manual/html_node/Why-is-_0023new-there_003f_0021_003f.html
• class Class - Ruby3.4 リファレンスマニュアル
  • https://docs.ruby-lang.org/ja/latest/class/Class.html
• Classes - MDN
  • https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes
• Eric Evans（2011）『エリック・エヴァンスのドメイン駆動設計』（翔泳社）今関剛 監訳, 和智右桂・牧野祐子 訳
• Martin Fowler（2005）『エンタープライズアプリケーションアーキテクチャ』翔泳社　長瀬嘉秀 監訳, 株式会社テクノロジックアート 訳
• Miran Lipovača(2012)『すごいHaskell たのしく学ぼう！』 （オーム社）田中英行・村主祟行 訳
• IO モナドと副作用 - haskell.jp
  • https://haskell.jp/blog/posts/2020/io-monad-and-sideeffect.html
• Value Object - martinFowler.com
  • https://martinfowler.com/bliki/ValueObject.html
• Value Objectについて整理しよう
  • https://kumagi.hatenablog.com/entry/value-object
• Robert C. Martin（2003）『Agile Software Development, Principles, Patterns, and Practices』(Pearson Education)
• Robert C. Martin（2014）『The Single Responsibility Principle』 (The Clean Code Blog)
  • https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
• Robert C. Martin（2017）『クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計』(アスキードワンゴ)

脚注

1. ダイクストラの論文「Go To Statement Considered Harmful」を文字った

2. https://www.gnu.org/software/smalltalk/manual/html_node/Why-is-_0023new-there_003f_0021_003f.html 2025-12-08 19:57閲覧
   > The truth starts showing to their eyes about that sentence that everybody says but few people understand: “classes are objects”.'

3. https://docs.ruby-lang.org/ja/latest/class/Class.html 2025-12-08 19:59閲覧

4. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes 2025-12-08 20:06閲覧
   > 'Classes are in fact "special functions", and just as you can define function expressions and function declarations, a class can be defined in two ways: a class expression or a class declaration.'

5. Miran Lipovača(2012) p.160
   > Haskell は、副作用を持つ関数を扱うための素晴らしく賢いシステムを持っているのです。そのシステムが、プログラムの純粋（pure）な部分と、キーボードや画面とやり取りするようなすべての汚い仕事をする不純（impure）な部分とをきっちりと分離してくれます。この2つの部分が隔てられているので、外の世界とやり取りしつつも、依然としてプログラムの純粋な部分を推論したり、純粋だからこそ得られる遅延評価、堅牢性、関数合成などを利用したりできます。
   

6. IO モナドと副作用 - haskell-jp 2025-12-10 19:52閲覧
   > Haskellは純粋な部分だけは目に見える範囲で提供し、非純粋な部分は隠蔽し、純粋に扱うことだけをできるようにしている。(...)こうすることで、Haskellは純粋性を保ちながら、非純粋な動作を扱えるようになっている。

7. Martin Fowler(2005) p.508-509

8. Eric Evans(2011) p.96

9. Value Object - martinFowler.com 2025-12-09 12:55 閲覧

10. Value Objectについて整理しよう 2025-12-09 20:30 閲覧
    > 一番重要なのは「値(Value)」という概念そのもの。それが複数の値の合成物からなる値ならばオブジェクトを定義してプロパティで等価比較する実装手段がいい、これをValue Objectと呼ぶ。だがオブジェクトを取り回す際には言語によっては無意識の共有操作に手を噛まれないようにせよ、回避策としてimmutableにするのもアリだよ。この順が重要である。

11. 深刻なケースだと、「Xを読んで、◯◯であるとわかった」と書いているが、実際にXを読むと◯◯と書かれている箇所は全く存在しない、という実例もある。個人攻撃や晒し上げが目的ではないので、詳細は伏せる。

12. 本稿執筆時点で、デマルコおよびジョーンズが「凝集度」についてどのような説明を行っていたかまでは確認できていない。ここではMartinの記述をそのまま受け取っている。

13. Martin（2003） p.95

14. Martin（2014）
    > In the late 1990s I tried to consolidate these notions into a principle, which I called: The Single Responsibility Principle. (I have this vague feeling that I stole the name of this principle from Bertrand Meyer, but I have not been able to confirm that.)

15. Martin(2003) p.97

16. Martin(2003) p.98

17. Martin（2017）7章

18. Martin（2003）p.96
    >Second, if a change to the GraphicalAplication causes the Rectangle to change for some reason, that change may force us to rebuild, retest, and redeploy the ComputationalGeometryApplication. If we forget to do this, that application may break in unpredictable ways.

19. Martin（2017）7章