LabHub

ブログ

ソフトウェアエンジニアリングにおける認識論：知識と確実性

2026-03-15 · 49 分で読めます · #culture#epistemology#philosophy#knowledge#decision-making#engineering-culture#2026-03

한국어English日本語

認識論とソフトウェアエンジニアリング

序論：私たちは本当に「知っている」のか

ソフトウェアエンジニアは毎日、「知っている」という判断の上で仕事をしている。このコードが何をするかを知っている。このシステムがどう動くかを知っている。このアーキテクチャがなぜ正しいかを知っている。だが、その「知っている」は本当に知識なのだろうか。

2500年前、ソクラテスは「私は自分が知らないということを知っている」と語った。この謙虚な告白が、西洋哲学における認識論（Epistemology）の出発点となった。認識論とは、知識の本質・範囲・限界を探究する哲学の一分野であり、「何を知りうるのか」「知るとは何か」「私たちの信念は正当化されるのか」という根本的な問いを投げかける。

驚くべきことに、この古代の問いは現代のソフトウェアエンジニアリングの核心的な問題とぴたりと重なる。

「プログラムのテストはバグの存在を示すことはできるが、バグの不在を証明することはできない」 - Edsger Dijkstra, "On the Cruelty of Really Teaching Computing Science" (1988)

Dijkstra のこの有名な警告は、本質的に認識論的な主張である。ソフトウェアの正しさに関する私たちの知識は根本的に不完全であるということだ。

この記事では、認識論の主要な概念をソフトウェアエンジニアリングに適用し、技術的確信の罠を分析したうえで、「わからない」と認める文化がなぜより良いソフトウェアを生むのかを探る。

第1章：認識論の核心概念とソフトウェアエンジニアリング

認識論とは何か

認識論（Epistemology）はギリシャ語の episteme（知識）と logos（学問）の合成語で、知識についての学問である。プラトンは知識を「正当化された真なる信念（Justified True Belief）」と定義した。この定義に従えば、何かを「知っている」と言うためには三つの条件が満たされていなければならない。

  1. 信念（Belief）：主体がその命題を信じていること
  2. 真理（Truth）：その命題が実際に真であること
  3. 正当化（Justification）：その信念が合理的な根拠によって裏づけられていること

この三条件をソフトウェアエンジニアリングに当てはめると、興味深い洞察が得られる。

ソフトウェアエンジニアリングにおける「知っている」

認識論的条件ソフトウェアエンジニアリングでの意味よくある錯覚
信念「このコードは正しく動作する」コードを読んで理解したという確信
真理あらゆる入力と状態で実際に正しく動作するテストしたケースでのみ動作を確認している
正当化十分なテスト、証明、検証一部のテスト通過を全体の正しさの根拠にする

Daniel Kahneman は著書 Thinking, Fast and Slow（2011）で、人間の思考をシステム1（速い、直感的）とシステム2（遅い、分析的）に区分した。エンジニアが「このコードは正しい」と判断するとき、働いているのはたいていシステム1である。コードにざっと目を通し、パターンを認識し、直感的に「正しい」という判断を下す。しかしこの直感的判断は、数多くの認知バイアスに対して脆い。

第2章：三つの認識論的錯覚

錯覚1：コードを読んだ＝理解した（可読性の錯覚）

コードレビューで最もよくある罠は、「読んだのだから理解した」という錯覚だ。Gerald Weinberg は The Psychology of Computer Programming（1971）で、すでにこの問題を指摘している。

「プログラミングにおいて最も危険な瞬間は、自分がそのプログラムを理解したと確信したまさにその瞬間である」 - Gerald Weinberg

これは認識論でいう「理解の錯覚（Illusion of Understanding）」である。私たちはテキストを読むとき、実際には深く理解していなくても理解したという感覚を得る。コードもまた同じだ。

可読性の錯覚が生じるメカニズム：

対応戦略：

  1. コードを読む前に PR の説明を先に読まない（アンカリングの防止）
  2. 中核となるロジックは自分の頭の中で実行してみる（手動トレース）
  3. 「このコードが失敗するにはどんな入力が必要か」をまず考える（反証的アプローチ）
  4. 自分が理解したと感じたその瞬間に、もう一度疑う

錯覚2：テストが通った＝正しい（検証の限界）

テストスイートがすべて緑になると、コードは正しいのだと信じたくなる。しかしこれは帰納法の根本的な限界に直結している。

18世紀の哲学者デイヴィッド・ヒューム（David Hume）は、帰納法の問題を明確に指摘した。過去の経験は未来を保証しない、と。1000羽観察した白鳥がすべて白かったからといって、「すべての白鳥は白い」という結論を下すことはできない。オーストラリアで黒い白鳥が見つかるまでは、である。

ソフトウェアのテストも同じだ。

テスト結果実際の意味よくある誤解
100件のテストが通過100件の特定シナリオで期待どおりに動作するあらゆるシナリオで正しい
コードカバレッジ100%すべてのコード行が最低1回は実行されたすべての実行経路と状態の組み合わせを検証した
結合テストが通過特定の環境でコンポーネント間の相互作用を確認したあらゆる環境での整合性が保証されている
性能テストが通過テスト条件下で基準値を満たした本番負荷での性能が保証されている

検証手法ごとの認識論的な限界：

錯覚3：本番で動いている＝正しい（帰納法の問題）

「2年間、本番で問題なく動いています」。この一文はエンジニアにとって最も強力な正当化の根拠のように感じられる。だがこれは典型的な帰納的推論の誤りである。

ナシーム・タレブ（Nassim Taleb）は著書 The Black Swan（2007）で「七面鳥の問題」を提示している。毎日えさをもらう七面鳥は、1000日連続でえさを与えられるうちに「主人は自分を食べさせてくれる存在だ」という確信を抱く。1001日目、感謝祭に七面鳥の首は落とされる。1000日分の経験的証拠が一瞬にして無効になる。

ソフトウェアシステムでも同じパターンが繰り返される。

動作するということと正しいということの違い：

観点「動作する」「正しい」
時間の範囲これまで観察した期間未来のすべてを含む
入力の範囲これまで入ってきた入力ありうるすべての入力
環境の範囲現在のインフラと設定ありうるすべての環境
保証の水準経験的（帰納的）論理的（演繹的）
哲学的な位置帰納的一般化普遍的真理

第3章：デカルトの方法的懐疑とコードレビュー

方法的懐疑とは何か

ルネ・デカルト（1596-1650）は 方法序説（Discourse on the Method）（1637）で方法的懐疑（Methodical Doubt）を提示した。その手法は単純だが急進的である。すなわち、疑いうるものはすべて疑い、疑いえないものだけを残せ、というものだ。

デカルトは感覚も記憶も、論理的推論までも疑い、最終的に「疑っている自分自身の存在」だけは疑いえないという結論に達した。有名な「Cogito, ergo sum（我思う、ゆえに我あり）」である。

コードレビューに適用する方法的懐疑

デカルトの方法的懐疑をコードレビューに適用すると、次のような問いのフレームワークが得られる。

ステップ1：前提を疑え

ステップ2：実装を疑え

ステップ3：検証を疑え

ステップ4：自分自身を疑え

方法的懐疑の実践チェックリスト

懐疑の段階問い確認方法
前提を疑う問題定義は正確か要求仕様書と突き合わせる
前提を疑う前提は明示されているかコードコメントと文書を確認
実装を疑う境界値は処理されているか境界値テストの有無を確認
実装を疑う失敗経路は安全かエラーハンドリングを追跡
検証を疑うテストは意味があるかミューテーションテストを検討
自分を疑うバイアスに陥っていないか意識的な再検討

第4章：カール・ポパーの反証主義とテスト駆動開発

反証主義の核心

カール・ポパー（Karl Popper）は20世紀で最も影響力のある科学哲学者の一人である。代表作 The Logic of Scientific Discovery（1934）で提示された反証主義（Falsificationism）は、科学と非科学を区別する基準を与えてくれる。

ポパーによれば、科学的理論は反証可能（Falsifiable）でなければならない。つまり、何らかの観察や実験がその理論を誤りだと示しうるのでなければならない。「すべての白鳥は白い」は科学的主張である。黒い白鳥が一羽いれば反証できるからだ。一方で「神は存在する」や「すべてには理由がある」は反証が不可能なので、科学的主張ではない。

TDDは反証主義の実践である

テスト駆動開発（TDD）は、驚くほどポパーの反証主義に似ている。

反証主義TDD
仮説を立てる機能要求を定義する
反証可能な予測を導く失敗するテストを先に書く（Red）
実験で仮説を試すコードを書いてテストを通す（Green）
仮説が生き残れば暫定的に受け入れるリファクタリングし、テストがなお通るか確認する（Refactor）
新たな反証の試みを続ける新しいテストケースを追加する
反証されたら仮説を修正するテストが失敗したらコードを修正する

ポパーは、理論は決して証明されえず、ただ反証されずに残っているだけだと語った。同じように、Dijkstra が述べたとおり、テストはコードの正しさを証明できない。ただ、まだ反証されていないという状態を保っているにすぎない。

反証可能な要求の書き方

ポパーの反証主義は要求の書き方にも適用できる。反証可能な要求は、明確なテスト基準を内に含んでいる。

反証不可能な（悪い）要求：

反証可能な（良い）要求：

Dijkstraの警告を読み直す

Dijkstra は1988年の論文 "On the Cruelty of Really Teaching Computing Science" で、ソフトウェアテストの根本的な限界を次のように説明した。

「プログラムのテストはバグの存在を説得力をもって示すことができるが、バグの不在を示すことは決してできない」

これはポパーの反証主義を正確に反映している。テストが失敗すれば、バグの存在が反証という形で疑いなく確定する。しかしテストが通っても、バグの不在が証明されるわけではない。私たちにできる最善は、より多くの反証の試み、すなわちテストを通じて、コードへの信頼度を漸進的に高めていくことだけである。

第5章：比較表 - 認識論の観点から見たソフトウェア検証手法

総合比較：検証手法と認識論的な強度

検証手法認識論的な類型確信度カバレッジコスト限界
コードレビュー社会的認識論（合意）低〜中状況依存低レビュアーの力量とバイアスに依存する
単体テスト帰納的推論中狭い低相互作用や結合の問題を検出できない
結合テスト帰納的推論中中中環境差に起因するギャップが残る
E2Eテスト帰納的推論中〜高広い高遅く、壊れやすく、全経路の網羅は不可能
静的解析演繹的推論高ルールの範囲内低ルールで表現できる問題しか検出できない
形式検証演繹的証明非常に高い仕様の範囲内非常に高い仕様そのものの正しさは保証できない
本番モニタリング経験的観察事後的実利用の範囲中すでに発生した問題しか検知できない
カオスエンジニアリング実験的反証高障害シナリオ高設計したシナリオの範囲に限定される

検証手法の認識論的な階層

検証手法を認識論的な強度の順に並べると、ピラミッドの形が現れる。

レベル1 - 信念（Belief）：コードの書き手自身の確信。「私はこのコードが正しいと信じている」。認識論的には最も弱い。

レベル2 - 社会的合意（Social Consensus）：コードレビューを通じた同僚の同意。「私たちのチームがこのコードをレビューし承認した」。複数の視点が反映されるが、集団浅慮（Groupthink）に対して脆い。

レベル3 - 経験的証拠（Empirical Evidence）：テストの通過と本番運用の経験。「このコードは1000件のテストを通過し、6か月間本番で動作した」。強力な帰納的証拠だが、未観測の領域における問題を保証するものではない。

レベル4 - 論理的証明（Logical Proof）：形式検証と数学的証明。「このアルゴリズムが正しいことを数学的に証明した」。最も強力だが、適用範囲が限られ、コストが非常に高い。

核心となる洞察は、ソフトウェア開発のほとんどはレベル2から3で行われているという点だ。私たちは絶対的な確実性ではなく「十分な確信」の領域で働いており、それを認めることが認識論的謙虚さの出発点になる。

第6章：ダニング＝クルーガー効果と技術的謙虚さ

ダニング＝クルーガー効果の本質

1999年、心理学者の David Dunning と Justin Kruger はコーネル大学で行った実験の結果を発表した。"Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" と題されたこの論文は、認知バイアス研究の歴史で最も広く引用される研究の一つとなった。

ダニング＝クルーガー効果の核心は次のとおりである。

ソフトウェアエンジニアリングにおけるダニング＝クルーガー

この効果は、ソフトウェアエンジニアリングにおいて非常にはっきりと観察される。

キャリア段階典型的な自己認識実際の力量認識論的な特徴
ジュニア（0-2年）「自分はけっこうできるほうだ」基礎を学んでいる最中知らないことの範囲を知らない
ミドル（2-5年）「知らないことが本当に多い」実務能力が伸びている無知の範囲を認識しはじめる
シニア（5-10年）「知れば知るほどわからなくなる」深い専門性不確実性を受け入れ、活用する
スタッフ以上（10年以上）「状況によって変わる」広い文脈的判断絶対的な答えの不在を認める

ジュニアの開発者が「このアーキテクチャが最高だ」と確信に満ちた声で言うとき、シニアの開発者が「そうですね、私たちの状況ではこういうトレードオフがあって……」と慎重に語る理由はここにある。シニアの慎重さは無能ではなく、メタ認知の発達である。

「わからない」と言うことの価値

ソフトウェアエンジニアリングの文化において、「わからない」という言葉はしばしば弱さと受け取られる。とりわけシニアエンジニアやリードにとって、わからないと告白することは権威の喪失のように感じられることがある。しかし認識論の観点からすれば、「わからない」という言葉は知識の状態を正直に表明したものである。

わからないと言うことに価値がある理由：

  1. 探索を始めさせる：「知っている」という確信は探索を止めるが、「わからない」という承認は調査を始めさせる
  2. 集合知を起動する：一人がわからないと認めれば、他の人たちが自分の知識を共有しはじめる
  3. 誤った決定を防ぐ：不完全な知識に基づく自信満々の決定より、不確実性を認めた慎重な決定のほうが安全だ
  4. 学習の文化をつくる：「わからない」が安全な環境では、質問と学習が活発になる

わからないと生産的に伝える言い方：

第7章：ベイズ推論と技術的意思決定

ベイズ的な考え方

トーマス・ベイズ（Thomas Bayes, 1701-1761）の名にちなむベイズ推論は、新しい証拠に基づいて信念の確率を更新する方法である。中心となる公式は次のとおりだ。

P(A|B) = P(B|A) x P(A) / P(B)

ここで P(A) は事前確率（Prior）、P(A|B) は新しい証拠 B を観察した後の事後確率（Posterior）、P(B|A) は尤度（Likelihood）である。

Daniel Kahneman は Thinking, Fast and Slow で、人間はベイズ更新を自然に行えないと指摘した。私たちは新しい証拠に過剰反応するか、過小反応する傾向がある。

障害の原因分析におけるベイズ的思考

本番障害が発生したとき、ベイズ推論は原因分析の強力なフレームワークを与えてくれる。

シナリオ：API のレスポンスタイムが突然10倍に増加した。

ステップ1：事前確率を設定する（経験と統計に基づく）

ありうる原因事前確率根拠
データベース負荷35%過去の障害で最も多い原因
ネットワークの問題20%インフラ関連障害の頻度
コードデプロイの問題25%直近にデプロイがあった
外部サービス障害15%外部依存が存在する
リソース枯渇5%まれだが起こりうる

ステップ2：証拠を集めて確率を更新する

証拠1：「直近30分以内にデプロイがあった」 -- コードデプロイの問題の確率が上がる（25% -> 45%）

証拠2：「DB クエリのレスポンスタイムは正常だ」 -- データベース負荷の確率が下がる（35% -> 5%）

証拠3：「特定の API エンドポイントだけが遅い」 -- コードデプロイの問題の確率がさらに上がる（45% -> 70%）

ステップ3：更新後の確率に基づいて行動する

ありうる原因更新後の確率対応の優先順位
コードデプロイの問題70%第1順位：直近のデプロイ差分を確認
外部サービス障害15%第2順位：外部サービスの状態を確認
ネットワークの問題7%第3順位：ネットワークメトリクスを確認
データベース負荷5%第4順位：DB の詳細モニタリングを確認
リソース枯渇3%第5順位：サーバーリソースを確認

日常的な技術的意思決定におけるベイズ的思考

ベイズ的思考は障害分析だけでなく、日常的な技術的意思決定にも適用できる。

技術選定：

肝心なのは、証拠に応じて判断を柔軟に更新することである。最初の判断に固着せず、新しい情報が入るたびに確率を調整する習慣が、より良い技術的意思決定につながる。

第8章：ナシーム・タレブの反脆弱性とシステム設計

フラジャイル、ロバスト、アンチフラジャイル

ナシーム・タレブは著書 Antifragile: Things That Gain from Disorder（2012）で、システムを三つのカテゴリに分類した。

特性フラジャイル（Fragile）ロバスト（Robust）アンチフラジャイル（Antifragile）
定義衝撃によって損なわれる衝撃に左右されない衝撃によって強くなる
たとえガラスのコップ岩筋肉
不確実性に対する態度回避抵抗活用
失敗したとき割れる耐える適応しながら成長する

ソフトウェアシステムに適用する

フラジャイルなシステムの特徴：

ロバストなシステムの特徴：

アンチフラジャイルなシステムの特徴：

不確実性を活用する設計と不確実性を拒む設計

設計アプローチ不確実性を拒む（フラジャイル）不確実性を活用する（アンチフラジャイル）
エラー処理「このエラーは起きないだろう」「あらゆるエラーは起こりうる」
キャパシティ計画正確な予測に基づくオートスケールと弾力性に基づく
デプロイ戦略ビッグバンデプロイカナリア、ブルーグリーン、段階的デプロイ
障害対応障害発生後の事後対応カオスエンジニアリングによる事前探索
アーキテクチャモノリシック、密結合疎結合、サーキットブレーカー
データ単一のデータベース複数ストア、イベントソーシング
チーム構成一人の専門家に依存する知識の分散、ペアプログラミング

Netflix のカオスエンジニアリングは、アンチフラジャイル設計の代表例である。Netflix は Chaos Monkey を通じて、本番環境で意図的にサービスを停止させる。この「ストレス」がシステムをより堅牢にする。障害を避けようとするのではなく、障害を活用してシステムを強くするのだ。

第9章：集合知と個人の知識の限界

社会的認識論の観点

伝統的な認識論は個人の知識に焦点を当ててきたが、社会的認識論（Social Epistemology）は知識の社会的な次元に注目する。知識は個人の頭の中にだけ存在するのではなく、集団の相互作用を通じて生成され検証される。

ソフトウェアエンジニアリングにおいて、この観点は極めて重要だ。現代のソフトウェアシステムは、一人が全体を理解するにはあまりに複雑である。だからこそ私たちは集団的な知識のメカニズムに依存する。

コードレビューの認識論的な根拠

コードレビューは単なる品質管理の手続きではない。認識論的に見れば、コードレビューは複数の認識主体による知識の検証という過程である。

一人がコードを書くとき、そのコードについての知識は個人的で主観的だ。コードレビューを通じて他者の視点が加わると、知識は間主観的（intersubjective）になる。これは個人的な信念よりも強い正当化を与えてくれる。

コードレビューがもたらす認識論的な価値：

価値説明認識論的な意味
多視点からの検証異なる背景のエンジニアが同じコードを検討する確証バイアスの低減
暗黙知の共有レビューの過程で文脈と経験が共有される集団の知識が増える
前提の露出書き手が当然視した前提をレビュアーが問う隠れた前提の検証
知識の分散コードの理解が一人からチームへ広がる単一障害点の除去

ADRとRFCの認識論的な役割

Architecture Decision Records（ADR）と Request for Comments（RFC）のプロセスは、意思決定の認識論的な品質を高めるメカニズムである。

ADRの認識論的な機能：

  1. 明示的な正当化：「なぜこの決定をしたのか」を記録し、未来の自分と同僚に正当化の根拠を提供する
  2. 文脈の保存：決定時点の制約と背景を記録し、知識が文脈から切り離されるのを防ぐ
  3. 代替案の記録：検討したが採用しなかった代替案を記録し、反証の試みの痕跡を残す
  4. 可逆性の確保：決定が誤りだったときに引き返すための根拠を用意する

RFCプロセスの認識論的な機能：

  1. 事前の批判：実装前に設計を集団で検証し、コストの低い段階で誤りを見つける
  2. 多様性の確保：多様な背景の意見を集めることでバイアスを減らす
  3. 証拠に基づく議論：主張には根拠を求めることで、単なる意見ではなく正当化された主張を促す

第10章：実践的な含意 - 認識論的謙虚さをエンジニアリング文化に織り込む

「わからない」と言える文化をつくる

組織文化のなかで「わからない」が安全な発言になるためには、構造的な仕掛けが必要だ。

1. リーダーが率先して手本を示す

技術リーダーやマネージャーが「私もこの部分は確信がありません」と言うとき、チーム全体の心理的安全性が高まる。Google の Project Aristotle の研究は、心理的安全性（Psychological Safety）が高い成果を出すチームの最も重要な要素であることを明らかにした。

2. 不確実性を記録する慣行をつくる

3. 質問を促すメカニズムをつくる

仮説検証サイクルとしてのスプリント

アジャイルのスプリントは、ポパーの反証主義の観点から読み直すことができる。

スプリントの段階反証主義的な解釈
スプリント計画仮説の設定：「この機能をこう実装すればユーザーは満足するだろう」
開発仮説の具体化：コードという形で仮説を明確にする
テスト反証の試み：仮説が誤りでありうるシナリオを探索する
デプロイ実験の実行：仮説を現実の世界にさらす
レビュー・振り返り結果の分析：仮説は反証されたのか、暫定的に受け入れられたのか

不確実性を認める技術文書の書き方

技術文書で不確実性を扱うためのフレームワークを示す。

確信度の表記システム：

表記意味使う場面
CONFIRMEDテスト、証明、または公式文書で確認済み検証済みの事実を書くとき
EXPECTED確信は高いが、直接検証はしていない文書に基づく推論のとき
ESTIMATED経験と直感に基づく推定性能や容量を見積もるとき
ASSUMED未検証の仮定、後で確認が必要仮定を明示するとき
UNKNOWNわからない、追加調査が必要未知の領域を示すとき

この表記を技術文書に一貫して適用すれば、読み手は各情報の確実性の水準を即座に把握できる。

第11章：チェックリスト - 認識論的謙虚さを実践するエンジニアの習慣

毎日の実践

毎週の実践

意思決定時のチェックリスト

コードレビュー時のチェックリスト

障害対応時のチェックリスト

結論：ソクラテスの知恵、エンジニアの謙虚さ

2500年前のソクラテスの「私は自分が知らないということを知っている」という告白は、今日のソフトウェアエンジニアリングにおいて、かつてないほど切実に必要な知恵である。

私たちがつくるシステムはますます複雑になり、相互に結びつき、予測しにくくなっている。この複雑さを前にして、「完全に理解した」という確信は最も危険な形の無知である。

認識論がソフトウェアエンジニアリングに与える核心的な教訓は、次のとおりだ。

  1. 知識は絶対的ではない：コードの正しさは、証明ではなく反証の不在によってしか主張できない（ポパー）
  2. 確信はバイアスを隠す：私たちの判断はさまざまな認知バイアスによって歪められる（Kahneman）
  3. 不確実性は敵ではなく情報である：不確実性を活用すれば、システムはより強くなる（タレブ）
  4. 集団の知恵は個人の確信より強い：コードレビュー、ADR、RFC は贅沢品ではなく認識論的な必需品である

Gerald Weinberg が50年前に語ったとおり、プログラミングは究極的には心理的な活動である。そして認識論的謙虚さは、より良いソフトウェアをつくるための最も根本的な心理的資質だ。

「真の知識とは、自分の無知を知ることである」 - ソクラテス

技術的な謙虚さは弱さではない。それは複雑性と不確実性の世界で生き延びるための、最も強力なエンジニアリング原則である。

参考資料

  1. Karl Popper, The Logic of Scientific Discovery (1934) - 反証主義の基本原理と科学的方法論
  2. Edsger Dijkstra, "On the Cruelty of Really Teaching Computing Science" (1988) - ソフトウェアテストの本質的な限界
  3. Daniel Kahneman, Thinking, Fast and Slow (2011) - 認知バイアスと意思決定の心理学
  4. Nassim Taleb, Antifragile: Things That Gain from Disorder (2012) - 不確実性を活用するシステム設計
  5. David Dunning and Justin Kruger, "Unskilled and Unaware of It" (1999) - ダニング＝クルーガー効果の原論文
  6. Gerald Weinberg, The Psychology of Computer Programming (1971) - プログラミングの心理的側面
  7. Nassim Taleb, The Black Swan (2007) - 極端な不確実性と予測の限界
  8. Google Research, "Project Aristotle" - 高い成果を出すチームの核心要素としての心理的安全性

原文を読む: https://www.youngju.dev/blog/culture/2026-03-15-epistemology-software-engineering-knowledge-certainty.ja

コメント

まだコメントはありません。

ログインするとコメントできます