プロセスという名の宗教を信仰する男
Abstract
形式検証もされていない穴だらけの仕様書を聖典として崇め、プロセスを通れば正しいと信じるプロセス原理主義者の生態
基本情報
- 通称: プロセス原理主義者
- 学名: Homo processus rigidus（硬直したプロセスのヒト）
- 役職: リーダーくらい
- 特技: プロセスの遵守、融通のなさ、ロビー活動
- 弱点: 実務、柔軟性、部署の同僚全員
序章：原理主義とは何か
「原理主義」という言葉の起源を辿ると、宗教に行き着く。
20世紀初頭のアメリカで、聖書の無謬性を主張するプロテスタントの一派が「ファンダメンタリスト」を名乗ったことに始まる。
彼らの信念は単純だった。聖典に書かれていることは、すべて正しい。
時代が変わっても、文脈が変わっても、聖典は絶対だ。解釈の余地はない。書かれている通りに従えばよい。
この思考様式は、宗教の外にも広がっていった。
そして今、我々の組織にも一人の原理主義者がいる。
彼が信仰するのは、神ではない。プロセスだ。
第一章：聖典としての仕様書
プロセス原理主義者には、聖典がある。
Excelで書かれた仕様書だ。
その仕様書は、プロジェクトの初期に作成された。形式検証など行われていない。論理的な整合性も確認されていない。専門家のレビューも受けていない。
穴だらけだ。
しかしプロセス原理主義者にとって、それは問題ではない。
「仕様書に書いてある」
これが彼の口癖だ。仕様書に書いてあれば、それは正しい。書いてなければ、それは存在しない。
ソフトウェア開発の現実を知る者なら、この危険性がわかるだろう。
机上で作られた仕様書には、必ず穴がある。実際に手を動かして初めて見えてくる問題がある。専門家でなければ気づけない落とし穴がある。
「計画は役に立たないが、計画することは不可欠である」 ― ドワイト・D・アイゼンハワー
アイゼンハワーの言葉は、計画（仕様書）そのものより、計画するプロセスの中で得られる洞察が重要だと示唆している。
しかしプロセス原理主義者は、この言葉を逆に解釈する。
計画（仕様書）こそが絶対であり、そこから逸脱することは許されない。
第二章：プロセスを通れば正しい
プロセス原理主義者の信仰には、もう一つの教義がある。
「プロセスを通れば、正しいものができる」
これは一見、合理的に聞こえる。適切なプロセスを経れば、品質は担保される。多くの品質管理手法は、この前提に基づいている。
しかし、プロセス原理主義者の解釈は微妙にずれている。
彼にとって重要なのは、プロセスを「通った」という事実であり、プロセスの中で何が行われたかではない。
組織論では、これを「目標の転移」（Goal Displacement）と呼ぶ。手段が目的化する現象だ。
本来、プロセスは「良いものを作る」ための手段だった。しかしいつの間にか、「プロセスを守ること」自体が目的になってしまった。
結果として、プロセスは通ったが、成果物は使い物にならない。
そんな事態が頻発する。
第三章：アクセシビリティという試金石
ある日、プロセス原理主義者にアクセシビリティ対応について質問してみた。
視覚障害を持つユーザーへの具体的な対応について尋ねると、彼の答えは予想通りだった。
要約すると、こうだ。大手プラットフォームのガイドラインに従っている。外部の制作会社もその規則に則っている。だからアクセシビリティは担保されているはずだと。
これは答えになっていない。
「ガイドラインに従っている」ことと「実際にアクセシブルである」ことは、イコールではない。
WCAG（Web Content Accessibility Guidelines）のようなガイドラインは、最低限の基準を示すものだ。ガイドラインに従っていても、実際のユーザーがアクセスできないケースは山ほどある。
本当にアクセシビリティを担保するなら、以下が必要だ：
- スクリーンリーダーでの実機テスト
- 実際の障害を持つユーザーによるテスト
- 色覚多様性を考慮したコントラスト検証
- キーボードのみでの操作確認
しかしプロセス原理主義者は、こう答えるだろう。
「ガイドラインに従うというプロセスを通っています」
プロセスを通ったから、正しいものができているはずだ。検証？そんなものはプロセスに含まれていない。
これが「プロセス信仰」の恐ろしさだ。
第四章：ガードレールなき原理主義
宗教における原理主義を考えてみよう。
古代に書かれた聖典は、当時の文脈で書かれている。著者たちは、数千年後の世界を想像していなかった。
だから聖典には「ガードレール」がない。
「この教えは、技術が発達した未来では再解釈せよ」とは書かれていない。「社会が変化したら、柔軟に適用せよ」とも書かれていない。
結果、原理主義者は古代の文言を現代に適用しようとして、様々な問題を起こす。
同じことが、組織のプロセスでも起きている。
プロジェクト初期に作られた仕様書やプロセスには、ガードレールがない。
「状況が変わったら見直せ」とは書かれていない。「専門家の判断を優先せよ」とも書かれていない。
だからプロセス原理主義者は、古い仕様書を振りかざして、現場を混乱させる。
「愚かな一貫性は、小さな心の小鬼である」 ― ラルフ・ウォルド・エマーソン「自己信頼」（1841年）
一貫性は美徳だが、状況を無視した一貫性は愚かさでしかない。
第五章：仕様変更という悪夢
プロセス原理主義者には、もう一つの致命的な弱点がある。
仕様変更に対応できない。
ソフトウェア開発において、仕様変更は避けられない現実だ。作ってみて初めてわかる問題がある。ユーザーの要求は変化する。技術的な制約が発見される。
アジャイル開発の父たちは、「変化への対応」を最重要原則の一つに掲げた。
しかしプロセス原理主義者にとって、仕様変更は「聖典への冒涜」だ。
ある日、開発中に問題が見つかった。このままでは動かない。修正が必要だ。
彼に変更を提案した。
返答は予測通りだった。進行中であることを盾に、変更を拒否された。
知っている。だから修正が必要なのだ。
しかし彼は動かない。
これは「受動的抵抗」（パッシブ・レジスタンス）と呼ばれる行動パターンだ。表面上は反対しないが、実際には何も動かない。
正面から「やりません」とは言わない。しかし、やらない。
最終的にどうなったか。
プレゼン資料にスクリーンショットを貼り付けて、画面遷移を一つ一つ説明し、「ここをこう直して」と手取り足取り指示を出した。
やっと動いた。
自分で判断する能力がないのだ。誰かが完璧な指示書を作らなければ、一歩も動けない。
第六章：パニックと暴走
仕様変更への弱さは、さらに深刻な問題を引き起こす。
下請けの暴走だ。
プロセス原理主義者の下で働く外部ベンダーは、困惑している。
問題が発生しても、彼にエスカレーションできない。プロセス遵守の一点張りで、実質的な問題解決には協力してくれないからだ。しかしプロセス通りにやっても問題は解決しない。
結果、ベンダーはパニックに陥る。
ある時、ベンダーが暴走した。
技術的な懸念がある要求を、本来のエスカレーションルートを無視して別のチームに直接持ち込んできた。
明らかにパニック状態だった。
なぜこうなるか。上位者が機能していないからだ。
プロセス原理主義者は、問題を解決する能力がない。しかし権限は持っている。
権限を持つ者が問題を解決できないとき、組織は混乱する。ベンダーは「この人に言っても無駄」と学習し、非公式なルートで問題を解決しようとする。
結果、余計な仕事が発生する。関係ない人間が巻き込まれる。コミュニケーションコストが爆発する。
プロセス原理主義者は、プロダクトを作る上で弊害になっている。
皮肉なことに、彼はプロセスを守ることでプロダクトを守っているつもりなのだ。
第七章：なぜ嫌われるのか
プロセス原理主義者は、部署の全員から嫌われている。
これは誇張ではない。観察の結果、彼に好意的な同僚は一人も見つからなかった。
なぜか。
1. 融通がきかない
どんな合理的な理由があっても、プロセスから逸脱することを許さない。緊急事態でも、例外を認めない。
2. 仕事を増やす
プロセスを守るための書類作成、承認フロー、報告義務。彼が関わると、仕事量が倍増する。
3. 責任を取らない
問題が起きても「プロセス通りにやった」と言い張る。プロセスに従った結果の失敗は、プロセスの責任であり、自分の責任ではないという論理。
4. 現場を理解しない
実際に手を動かさないので、現場の苦労がわからない。机上の空論でプロセスを設計し、現場に押し付ける。
5. そもそもいない
個人的な理由で、出社してもすぐに退社してしまう。連絡しても返事が返ってこない。
プロセスを守れと言う本人が、コミュニケーションのプロセスを守らない。
この矛盾に、本人は気づいていない。
心理学では、このような行動パターンを「官僚制的性格」と関連付けることがある。ルールや権威への過度な執着、曖昧さへの不耐性、柔軟性の欠如。
マックス・ウェーバーは『官僚制』の中で、官僚制の合理性を評価しつつも、その硬直性の危険性を警告した。
プロセス原理主義者は、官僚制の悪い面を体現している。
第八章：権限剥奪
興味深い事実がある。
プロセス原理主義者は、かつてもう少し上のポジションにいた。
そして、権限を剥奪された。
何が起きたのか。
周囲の人々と本人の活動状況を見れば、結論は明らかだった。この人は、組織にとってもプロダクトにとっても弊害になっていると。
そして、組織の自浄作用が働いた。彼は降格した。
彼自身も「ロビー活動」に熱心だった。上層部に取り入り、自分の重要性をアピールする活動だ。
しかし、それだけでは限界がある。
最終的には、成果で評価される。プロセスを守っているかではなく、価値を生み出しているかで。
プロセス原理主義者は、プロセスは守ったが、成果は出せなかった。
チームの生産性は下がった。メンバーは疲弊した。プロジェクトは遅延した。
そして、降格。
これは「ピーターの法則」の変形かもしれない（Peter & Hull, 1969）。
通常のピーターの法則は「人は無能になるレベルまで昇進する」と述べる。
プロセス原理主義者の場合、「無能が露呈するレベルまで昇進し、そこから降格した」と言える。
ある意味、組織の自浄作用が働いた珍しいケースだ。
第九章：なぜプロセスに逃げるのか
プロセス原理主義者を観察していて、ふと思うことがある。
なぜ、ここまでプロセスに執着するのか。
一つの仮説がある。
プロセスは、判断を免除してくれる。
ソフトウェア開発には、無数の判断が求められる。トレードオフを考慮し、リスクを評価し、最善の選択をする。これは難しく、責任を伴う。
しかしプロセスに従えば、判断は不要になる。
「プロセスがそう定めているから」と言えば、自分で考える必要がない。失敗しても「プロセス通りにやった」と言い訳できる。
これは「認知的負荷」を下げる戦略だ。
複雑な現実を、単純なルールに還元する。考えなくていい。従えばいい。
しかしこの戦略は、長期的には破綻する。
現実は複雑だ。プロセスでカバーできない状況が必ず発生する。そのとき、判断力を失った人間は対応できない。
プロセス原理主義者が成果を出せないのは、判断する能力を手放してしまったからかもしれない。
第十章：原理主義へのガードレール
「原理主義にはセットでガードレールが必要である」
これは真実だ。
プロセスそのものは悪ではない。適切なプロセスは、品質を担保し、属人化を防ぎ、組織の知識を蓄積する。
問題は、プロセスが「原理主義化」することだ。
ガードレールとは何か：
1. 定期的な見直し プロセスは定期的にレビューし、現実に合わなくなったら更新する。
2. 例外規定 緊急時や特殊なケースでは、プロセスを逸脱できる明確なルールを設ける。
3. 結果による検証 プロセスを通ったかではなく、結果が目的を達成しているかで評価する。
4. 現場の裁量 専門家の判断を尊重し、プロセスより現場の知見を優先する場面を明確にする。
これらのガードレールがあれば、プロセスは「道具」として機能する。
ガードレールがなければ、プロセスは「信仰」になる。
対策
1. プロセスの目的を問い続ける
「このプロセスは何のためにあるのか」を常に問う。目的を見失ったプロセスは、害悪でしかない。
2. 結果で検証する
「プロセスを通ったから正しい」ではなく、「結果が正しいかどうか」で判断する。アクセシビリティなら、実際にアクセシブルかどうかをテストする。
3. 例外を認める文化
プロセスからの逸脱を「悪」としない。合理的な理由があれば、例外を認める文化を作る。
4. プロセス原理主義者を重要なポジションに置かない
彼らにプロセス設計の権限を与えない。与えると、組織全体が硬直化する。
観察者の所感
プロセス原理主義者を見ていると、ある種の悲しさを感じる。
彼は、悪人ではない。むしろ、「正しいことをしたい」という欲求は人一倍強いのかもしれない。
ただ、「正しさ」の定義が歪んでいる。
彼にとって「正しさ」とは、プロセスに従うことだ。結果ではなく、プロセスへの忠誠が彼の正義だ。
これは一種の「認知的閉鎖欲求」かもしれない（Kruglanski, 1989）。曖昧さを嫌い、明確な答えを求める心理的傾向だ。
プロセスは、明確な答えを与えてくれる。「これに従えばよい」と。
しかし現実は曖昧だ。正解がないことも多い。プロセスでは対応できない状況が無限にある。
プロセス原理主義者は、この現実の曖昧さに耐えられないのかもしれない。
だからプロセスにしがみつく。プロセスという「確実なもの」に。
彼が「アクセシビリティ対応されています」と自信満々に答えたとき、彼は本当にそう信じていたのだろう。
プロセスを通ったのだから、正しいはずだと。
その信仰の強さは、ある意味で哀れでもある。
参考文献
- Kruglanski, A. W. (1989). Lay Epistemics and Human Knowledge: Cognitive and Motivational Bases. Plenum Press.
- Peter, L. J., & Hull, R. (1969). The Peter Principle: Why Things Always Go Wrong. William Morrow and Company.
- Weber, M. (1922). Wirtschaft und Gesellschaft（『経済と社会』）. [官僚制の分析を含む]
- W3C. (2018). Web Content Accessibility Guidelines (WCAG) 2.1. W3C Recommendation