IT業界には「奥が深い症候群」って言葉があってな
使いにくいシステムを使いこなすことに喜びを感じて、使いこなせない人間を見ると罵倒する
そういう人が幅を利かせていつまでも改善がされない
そんな症状だ
https://anond.hatelabo.jp/20200603093957
ソフトウェア・エンジニアが使うツールには、使い勝手の良くないものが割と存在する。その辺の事情に関してはバッドノウハウと「奥が深い症候群」で語られている内容が詳しいのだが、必ずしもそれが全てではない。
例えばGitは、まあ15年ほど開発が続けられているツールではあるが、それでもどちらかと言えば後発のバージョン管理システムだ。しかしオープンソースの有名どころバージョン管理システムを歴史順に「CVS・Subversion・Git」と並べた時、Gitは最後発なのにも関わらず、使いこなせないというユーザは最も多いように見える。
このGitの「使いこなせない」という現象は、「バッドノウハウと『奥が深い症候群』」における議論とは少し方向が違うように思う。
ユーザとしてCVS・Subversion・Git全ての利用経験があるが、CVSやSubversionはちょっと説明を受けただけで「大雑把な使い方の全体像」を理解できた一方で、Gitを使い始めた当初の感想は「どう使えば良いのか分からない」だった。
CVSやSubversionは集中型バージョン管理システムという特徴より、実のところ使い方のスタイルは概ね定まっている。メンバー全員がアクセスできるサーバ上にリポジトリを置いておき、各メンバーの端末にファイルをチェックアウトし、編集し、リポジトリにチェックインする。大抵はこのようなスタイルに固定される。
一方でGitは、使い方のスタイルが定まっているとは言い難い。リモートリポジトリを1つ利用する従来のSubversionっぽいスタイル、リモートリポジトリを持たないスタイル、複数のリモートリポジトリを参照するスタイル等々、割と色々な使い方ができるように設計・実装されている。だからGitでバージョン管理したいなら、まずは自分の環境に合ったスタイルを模索しなくてはならず、模索するためにはGitの内側（表面的な使い方ではなく、操作の背景や内部メカニズム）に目を向ける必要がある。
エリック・S・レイモンドが『The Art of UNIX Programming』で述べたUNIX思想に「ポリシーをメカニズムから分離せよ」というものがある。ポリシー（物事を行うときの原則）は時代と場所で変化する不安定なものであるから、ツールを作る際にはメカニズム（機能）だけ提供するようにしておいて、ユーザには自身のポリシーに沿った形でメカニズムを利用してもらう――という考え方だ。
CVS・Subversion・Gitのいずれも、基本的にはメカニズムのみを提供する。しかしCVSとSubversionはその性質上、大まかな利用スタイルが決ってしまう。私はこれを「暗黙のポリシー」と呼んでいる。
ソフトウェア・エンジニアが使うツールの「使い勝手の悪さ」の一部は、ポリシーがない状態でメカニズムを渡された際の、自由度の高さに起因する。明示的でも暗黙的でも、ポリシーさえあるなら、ひとまずそれに従って使えばよい。使っていくうちに、段々と分かってくるようになるものだ。しかしポリシーが無いと、自由過ぎて困惑してしまう。第一の関門がこれだ。
次に、どうにかこうにかポリシーを定めたら、今度は「ポリシーに沿うようにメカニズムを利用するには、どうすれば良いか？」という問題が生じる。うまい具合にポリシーに合わせるために、メカニズムそのものへの理解を深める必要がある。この点は「ツールの学習コストの高さ」として表面化する。
さらに言えば、「自身のポリシーに沿った形でメカニズムを利用」するということは、言い換えれば「運用でカバー」なのだ（ただしマンパワーではなく「ユーザの使い込み度」というある種の技術力で解決する、という方向だが）。つまりツール利用の熟練度が低い間は運用トラブルは必至だと言える。だから誰しも、commit前にpullしたり、commit後のpushを忘れたりしてしまうのだ。
こんな風に、自由度の高い、メカニズムのみを提供するツールがトラブルを引き起こす例は枚挙にいとまがない。というかUNIXの系譜にあるUnix-like環境のCLIからして、初心者お断りの芳醇な香りが漂う代物だ。
それなのに、GitもUnix-like環境も一部のソフトウェア・エンジニアを惹きつけて止まないし、相変わらずメカニズムのみ提供するツールは作られ続けている。なぜだろうか？
要は、自由度の高さは諸刃の剣なのだ。扱い方をしくじれば大怪我するが、うまくコントロールできれば強力な武器となる。例えばUnix-like環境のCLI信者の大半は、この「熟練度が高くなるにつれて、メカニズムを自在にコントロールできるようになり、飛躍的に生産性が向上する」という体験の中毒患者なのだ。
この辺は（Lispの話題ではあるが）以下の記述が正鵠を射ている。
Lisp系言語が、プログラマに大きな力を与えるという意味で「自由である」ってところにはあまり議論はありませんね。議論はその有り余る自由が利点か欠点かってことでしょう。
Lisperの立場から言えば、その自由は、限界に当たった時にその限界をハックしてさらにその先へ進むためにどうしても必要なことなんです。ハックだから、それが恒久的解決になるわけじゃない。正しい解決は処理系の改善や、もしかするとコンピュータサイエンスの進歩を待たなくちゃならないかもしれない。でも、「今、とりあえず」自分を引き止めている限界を乗り越えたい、と思ってしまうわけですね。
Lisp:よくある正解
ツールの自由度の高さは、現実の開発においてソフトウェア・エンジニアの武器となりうる（偶にしくじって怪我をするが）。だから今でもメカニズムのみを提供するツールが作られ続けているし、熱心なユーザはツールの熟練度上げに熱中している。
ただし熟練度上げの中毒になると「奥が深い症候群」を発症しやすいし、時に自分よりも熟練度の低い人を見下しがちである。ついでに、新しいツールが出てきた時に「今まで使ってきたツールの熟練度」惜しさより否定的な態度をとってしまうことがある。
ところで、ポリシーよりもメカニズムを重視するのは、限られた分野の話だ。一般的な分野の一般的な人は、自由度の高いツールよりも「簡単な操作で、ポリシーに従った結果を得られる」ツールを好む。ソフトウェア・エンジニアが他の分野の人と交流する際には、この辺のスタンスの違いを念頭に置くべきだろう。
