決定論的にではなく、相対的に — 道具と方法をめぐる態度

Read in English

本サイトに並ぶ記事は、表面的にはばらばらの話題を扱っています。会議スライドの台形補正、自転車のルート計画、センサーログの二層構成、議事録の標準化、LuaTeX のリモート実行環境、書かない設計の原則 ── 道具と作業の流れの設計判断を、それぞれの分野で言葉にしたものです。

けれどもこれらの記事には、明示していなかった共通の前提があります。道具と方法を「正解の手順」として固定しない、という態度です。本稿はその前提を取り出して言葉にします。以降の記事を読むときの下地として、また本サイトが何をやっているのかの宣言として置いておきます。

「ベストプラクティス」が陳腐化する経験から

ソフトウェア工学の現場で長く仕事をすると、「決定版」「ベストプラクティス」「これが正解」と呼ばれたものが、数年で陳腐化していくのを何度も見ます。

理由は単純で、環境が動くから です。要件が変わる、制約が変わる、道具立て (ツールチェーン) が変わる、チームの構成が変わる、扱うデータの規模が変わる。手順を凍結すると、その凍結時点の環境にだけ最適化された化石が残ります。化石は、環境が動いた瞬間に脆くなります。

だから「正解の手順」を持つこと自体が罠です。持つべきなのは、状況に応じて意味を確認しなおす態度 のほうです ── これは諦めや相対主義ではありません。むしろ逆で、環境が動く前提でなお頑健であろうとすると、固定された手順ではなく可動な態度に重心を置くしかない、という工学的な帰結です。

この態度を、本サイトでは三つの言葉で支えています。媒介性差延検証と妥当性確認 (V&V) の非対称性 です。いずれも理論的な精密化は別の場でおこなっていますが1、本稿では現場の言葉で説明します。

媒介性 — 道具は中立ではない

道具は、目的と作業の「あいだ」に立ちます。そして、あいだに立つ媒介物は 透明ではありません。何が見えるか、何ができるか、何が考えやすいかを、媒介物自身が決めています。

具体的に言うと:

  • バージョン管理を git にした瞬間、開発の単位を「コミット」「ブランチ」「履歴」という形で考えるようになります。git subtree split が自然な操作として手に入る一方、別の粒度での履歴管理は意識から消えます。
  • プログラミング言語を選ぶと、その言語が「自然」と感じる解き方に引き寄せられます。リスト内包表記が当たり前の言語と、それが無い言語とでは、同じ問題でも書き手の発想が変わります。
  • 標高データに国土地理院 5m メッシュ DEM を選べば「橋・トンネルの異常標高」という問題が見えてきますが、30m 解像度のデータを選べばその問題はそもそも視野に入りません。

つまり道具選びは「効率」だけの問題ではなく 「思考の形」の問題 です。だから本サイトの記事は、道具を採用するときに「なぜこの道具か」を毎回問い直します。本サイトの既掲記事 ツールとオーケストレーターを分ける で論じた 単一責務 は、この観点から見ると「道具が媒介する範囲を意図的に絞る」ことです ── 範囲を絞れば、その道具が決める「思考の形」を見通せて、差し替えも効きます。偉大なプログラマは優秀なプログラマのコードを利用する書かない設計 も、自分が書かない部分の「思考の形」を他者の優秀な実装に委ねる、という媒介の選び方です。

媒介物が自分の手の外に置かれることへの警戒 ── 本サイトの既掲記事 腐らない資産を設計する で論じた プラットフォーム税を払わない設計、無料で長期安定な開放形式やオープンソースを選ぶ判断 ── も、媒介性を意識した帰結です。媒介物が他者の都合で変わると、自分の思考の前提が他者の都合で変わってしまうからです。

差延 — 意味は事後的・相対的に立ち上がる

設計を始めるとき、「何をしたいか」は最初から確定していません。確定しているつもりでも、作りながら変わります。

本サイトで何度か触れている 4 段階の手順 ── 「実現したいことの明確化 → 既存コードの調査 → 組み立て (オーケストレーション) の設計 → 足りない道具の実装」 ── は、一見すると上から下に流れる線形の手順に見えますが、実際には 円環をなしています。既存コードを調べると「実現したいこと」の解像度が上がり、組み立てを設計すると「実現したいこと」の輪郭が変わり、道具を実装すると「実現したいこと」が定義しなおされます。目的は事後的に言葉になる のであって、最初に置いた目的は仮置きにすぎません。

たとえば、本サイトの既掲記事 自転車ルートを事前に把握する で扱った route-planner を作っているとき、当初の目的は漠然と「ルート計画ツールが欲しい」でした。区間選択の画面を実装し、斜度のカラーマップを実装し、橋・トンネル補正を実装していくうちに、「自分が本当に欲しかったのは『走る前に距離と斜度の合計を正確に把握すること』だ」と言葉になりました ── これは作る前には書けなかった文です。

設計とは「事前に確定した正解を実装すること」ではなく、やってみて意味を確認しなおすこと です。だから本サイトの記事は、設計判断を「これが正解だった」とは書きません。「こういう判断を、こういう理由で取った」と書きます。判断は環境に対して相対的で、環境が違えば別の判断が正しい、という構造を残しています。

この「相対的に意味を確認しなおす」態度は、記事と記事の関係にも現れます。本サイトの記事は、絶対的な分類体系の中に固定されているのではなく、互いに 相対的な関係 で結ばれます ── 「これはあの記事より具体的だ」「これはあの記事の原則をこの分野に当てはめたものだ」「これとこれは横並びの事例だ」。記事の意味は、隣にどの記事を置くかで変わります。

検証と妥当性確認 (V&V) の非対称性 — 二つは別の営み

ソフトウェア工学に Verification (検証) と Validation (妥当性確認) という用語があります。この二つは構造的に 非対称 です。

  • 検証 は、隣接する二つの段階のあいだの 差異を見つける ことです。仕様と実装、設計とテスト、要件と仕様 ── 隣り合う段階が一致しているかを確かめます。これは機械的に近く、自動化も効きます。
  • 妥当性確認 は、それとは違います。「目的そのものをさかのぼって言葉にする」 ── つまり「そもそも何がしたかったのか」を発見する営みです。これは「目的に合っているかを確認する」ことではなく、「目的とは何だったのかを見つける」ことです。

エンジニアの日常で言えば: テストが全部通る (検証が成功している) けれど、ふと立ち止まって「これ、本当に欲しかったものだったか?」と問う ── その問いが妥当性確認です。そして多くの場合、その問いに答える過程で目的そのものが書き換わります。

この二つを混同すると、「テストが通れば完成」という罠に落ちます。本サイトの既掲記事 記録を標準化する で論じた 段階間の取り決めを尊重する設計 (GPX / KML / JSON など既存標準を発明せず繋ぐ) は、検証の対象 ── 隣接段階が一致しているかを確かめやすくする ── を整える作業です。一方で 腐らない資産を設計する で論じた「10 年後に再分析できる形式を選ぶ」判断は、妥当性確認の場 ── 10 年後の自分が「そもそも何を記録したかったのか」をさかのぼって言葉にできる余地を残す ── を確保する作業です。

差異を見つけること (検証) と、目的をさかのぼって発見すること (妥当性確認) を、別の営みとして扱うこと。これも「決定論的にではなく相対的に」の一部です。妥当性確認で目的が書き換わりうる以上、最初に置いた目的を絶対視できません。

本サイトがこれを実践に落とすと

媒介性・差延・検証と妥当性確認の非対称性 ── この三つを道具設計・記事のつなぎ方・記事の書き方に落とすと、本サイトの具体的な選択が出てきます。

道具設計: 道具は「答え」ではなく「あいだに立つもの」だから、単一責務に閉じて差し替え可能にします。媒介する範囲を明示すれば、その道具が決める「思考の形」を見通せて、状況が変わったときに差し替えが効きます。本サイトの既掲記事 スライド写真の歪みを直すセンサーログを設計する はいずれも、機能を最小に閉じる判断を言葉にしています。

記事のつなぎ方: 本サイトの記事間リンクは、上位/下位の固定的な木構造ではなく、相対的な関係の場 です。「より抽象的 / より具体的」「上下 / 横」が記事間の関係として意味を持ちます ── 本稿は他の記事より抽象的な側に、事例の記事はより具体的な側に立ちますが、この上下関係も絶対ではなく、読者がどの記事から入るかで意味が変わります。

記事の書き方: 「正解の手順」を提示するのではなく、「こういう判断を、なぜ取ったか」を言葉にします。読者には手順をコピーしてほしいのではなく、判断のパターンを別の問題に持っていってほしい のです。「Canny エッジ検出の使い方」ではなく「自動検出を試みつつ手動微調整を残す、という判断をなぜ取ったか」を辿ること ── 後者のほうが、別の分野で別の問題に立ち向かうときに効きます。

検証と妥当性確認の態度: 本サイト自身、何が「役に立つ記事」かは事後的に言葉になります。本稿も、書き始める前は「方法論の前提を整理する記事」という仮置きでしたが、書き終えてみると「本サイトの全記事を貫く下地を宣言する記事」だと言葉になりました ── これは書く前には書けなかった文です。

下地としての宣言

媒介性・差延・検証と妥当性確認の非対称性についての理論的な精密化 ── これらの形式的な定義、OODA ループの一般化との接続、離散の形での定式化を選ぶことの正当化 ── は、本サイトとは別の場でおこなっています1。本サイトはそれを主題にはしません。記事の背後にある下地として指し示すに留め、実地の工夫の場であり続けます。

「踏み込むと知の普遍的な営みになる」線がここにはあります。記号による要素還元的な表現と、その検証と妥当性確認 ── これは知の普遍的な営みそのものです。本サイトはその線の手前に留まりますが、その営みが背後にあることは隠しません。理論が知りたい読者は脚注のプレプリントへ、実装の判断が知りたい読者は本サイトの事例の記事へ ── という分担です。

最後に、本稿の主張を一文に圧縮します。

道具を「正解の手順」にしないこと ── 決定論的にではなく相対的に意味を確認し、状況の変化に柔軟に対応すること ── これが、本サイトで扱うすべての設計判断の前提です。

以降の記事を読むときは、この前提を思い出してください。どの記事も「これが正解だ」とは言っていません。「こういう判断を、こういう理由で取った。あなたの状況が違えば、別の判断が正しい」と言っています。

参考文献


  1. 媒介性の操作的な定義、差延の離散形式での定式化、検証と妥当性確認の非対称性の形式的な扱い、および OODA ループの一般化との接続については、著者の Zenodo プレプリント・シリーズを参照 ── プロレゴメナ (10.5281/zenodo.20122700)、認識論的基礎 (10.5281/zenodo.20122696)、ガバナンス設計基礎原理の適用 (10.5281/zenodo.20122677)、レター版 (10.5281/zenodo.20096463)。一覧と各論文の関連記事は本サイトの プレプリント ページにまとめている。連続を扱わず和分と差分で扱い、測度論的な厳密性の議論を意図的に括弧に入れる選択は、弱さではなく工学的プラグマティズム (Bridgman / Peirce / Quine の系譜) に基づく筋を通した選択である ── この点もプレプリント側で論じている。