野生のプログラミング
概念が豊富であるということは、現実のもつ諸特性にどれだけ綿密な注意を払い、そこに導入しうる弁別に対してどれだけ目覚めた関心をもっているかを示すものである
コンピューターサイエンス vs 野生のプログラミング
よくコンピューターサイエンス(以降CSと省略して表記)が大事だと聞きます。
特に欧米ではエンジニアとしての就職にCSの学位が必須だと言われています。
しかし、日本で働いている限りにおいてはあまり気になったことはありません。
まず、CSが具体的に何を指すのか自分にはよく分かりません。
実際にエンジニアとして働いている人にCSとはなにか？と伺っても明確な解答をしてくれる人もあまりいない気がします。
自分の大雑把な理解だと、大学や大学院における専攻科目の履修内容がそれにあたり、卒業をもって学位が与えられる認識です。
自分は大学に行ったことがないので教育機関でどのような内容を教えているのかは分かりません。
実際の中身についてですが、軽くググった感じだと、データ構造やアルゴリズムの知識だったり、基本情報技術者試験の知識だったり、実際のプログラミングだったり、コンピューターやネットワークにまつわる知識だったり、ソフトウェア工学の内容であったり、人やコンテキストによって様々です。
さて、学位がないとしても上記の内容を網羅的にどこかしらの教育機関でガッツリ学んだエンジニアの人はどれぐらいいるのでしょうか？
自分の過去の職場を思い起こしてみると、大卒でも別の専攻であったり、専門学校出身であったり、高卒であったり、CSの学位を持つに相当する教育履修者にほとんど会ったことがありません。
しかし、エンジニアとして働いている人はたくさんおり、優秀な人もそこそこにはいます。
その優秀な人はCSの被教育経験はないにしても、それ相応の知識は身につけているように思えます。
では、彼らがどのように知識を身に着けたかというと、独学であったり、仕事において業務遂行に必要な知識が漸進的に体に染み付いていった結果だったりします。
ほとんどの人が学問や教育としてCSを身に着けたのではなく、仕事や実践を通じてCSに相当する知識と経験を得ていると考えられます。
この事実は学問的基盤であるCSよりも実践経験、いわゆる野生の思考にこそプログラミングの本質が宿っていると考えることができます。
科学や学問は既存の存在する現象や概念を分析して導き出した思考群であり、学問が発生するよりも前にコンピューターとプログラミングはすでに存在していたのです。
プログラミングが存在するから、それに対する分析欲求の結果としてCSも存在しえるのです。
プログラミングが先に存在しているならばそれを扱うための思考もすでに存在しているはずです。
それこそがプログラミングにおける野生の思考であり野生のプログラミングとも呼ぶべき概念となります。
数あるLisp方言の処理系やPerlやRubyなどのほとんどのプログラミング言語は学問やアカデミズムから生まれたのではなく優秀な個人や集団の思考と実践の結果として誕生したのです。
そういった意味でもプログラミングの始まりは野生の思考からスタートしているのです。
CSは世の中に既に存在するコンピューターやネットワーク、プログラミングを分析の対象として、それを体系化して万人が利用できる知識にしているに過ぎません。
CSがあるからコンピューターやインターネット、プログラミング言語が生まれたわけではないのです。
概念分割欲求
ここまでで、野生の思考(プログラミング)から派生して生まれたのが学問(CS)である話をしました。
ここからトーテムとプログラミングの関係について語っていきたいのですが、まずは野生の思考(プログラミング)から学問(CS)が生まれる過程について考察します。
『野生の思考』では、いろんな民俗学者が各部族のトーテムについて、どのような意味が込められているかを色々考察した遍歴がつらつらと書かれています。
しかし、レヴィ＝ストロースはトーテム単体には意味がないとし、トーテムとトーテムとの差異に意味を見出しています。
民俗学者がやっていたように、ある一つの対象を分析して意味を見出す方法と、レヴィ＝ストロースのように多数の対象を俯瞰してその差異に意味を見出す方法論があります。(自分は互いのアプローチの違いをピックアップしただけで、レヴィ＝ストロースがこの方法論を提唱しているわけではないです)
この2つの方法論が学問体系を作り上げる基本的な欲求として存在している気がします。
例えばソート処理の場合、ソートとしての機能性を追求しアルゴリズムを研鑽する方向性。
もう一つは、バブルソートやクイックソートなどをアルゴリズムごとに分類し、それぞれに概念を与えて知識体系に組み込む方向性です。
一般的な日本語の認識だと前者が科学、後者は学問といったところでしょうか。
後者の学問的アプローチはシステム開発における要件定義にも生きてくる部分があります。
次の例え話がこのパラグラフで一番言いたかったことなんですが、概念を分割して定義することはとても重要です。
あるB2Bのシステムを開発していて「ユーザー」という概念があった場合、それが具体的にどのステークホルダーを指すのか特定することができると思いますか？
例えば自社でWordpress(ブログの運用システム)の開発・保守をサービスとして提供していると考えましょう。
この場合、ユースケースの登場人物として「運用者(自社の人)」「顧客(自社のサービスを契約した法人)」「閲覧者(Wordpressのサイトを見に来る人)」がいることになります。
では「ユーザー」とはどの人を指すのでしょうか？
自社から見れば自社サービスを契約して使ってくれている「顧客」が「ユーザー」と捉えることができます。
しかし、「顧客」からみれば「閲覧者」が「ユーザー」となります。
システム運用上、自社目線と顧客目線の両方の「ユーザー」を取り扱わなければなりません。
よってDDDにおけるユビキタス言語よろしく、自社から見たユーザーは「クライアント」、クライアント(顧客)からみたユーザーは「エンドユーザー」といったように概念を分割することによって立場による認識違いを防ぎ、コミュニケーションを円滑にすすめることができるようになります。
これは未開人が弁別のためにトーテムを利用していたのと同じ動機で成り立っています。
こういった場面でも野生の思考を感じることができます。
トーテムとフレームワーク(種)とサービス(個体)
『野生の思考』ではトーテムを弁別の実践のための道具として解釈している部分が大いにあります。
トーテムは自然から意味を抽出しているのではなく、あくまでも弁別のために自然から名前を拝借しているだけなのです。
分析的解釈ではなく概念を分割し比較することによって得る解釈なのです。
ある対象を分析してその正体を明かすのではなく、ある対象と別の対象とを比較して、その差異からある対象の正体を浮き上がらせることがトーテムの本質的な役割としています。
弁別のための方法論がトーテムなのです。
急に話は変わりますが、ポケモンのピカチュウを思い浮かべてください。
ピカチュウは種族名であって個体名ではないことに気をつけてください。
アニメではサトシは自分のピカチュウをピカチュウと呼んでいます。(ゲームだと自分の捕まえたポケモンに好きな名前を付けることができます)
これは飼っている猫をネコと名付けているようなものです。
そこでマチスとのバトルになり、マチスがピカチュウをくり出してきました。
このとき、マチスもピカチュウをピカチュウと呼んでいた場合、第三者が互いのピカチュウを個体名だけで分別することができなくなります。
そこで「サトシのピカチュウ」「マチスのピカチュウ」のようにマスターの名前を紐付けて呼ぶことにより互いのピカチュウを弁別することができます。
このときの「サトシの」「マチスの」の部分の修飾語が部族の自然の要素からトーテムを借用する使い方と同じ働きをしています。
ポケモンと部族との違いは弁別のための要素をマスター名から拝借したのか自然の動物からなどから拝借したかの違いしかありません。
互いに対象を弁別したいプリミティブな欲求によりトーテムを利用した、という点で同じなのです。
現代社会にあるポケモン一つとってみてもトーテム的な需要は発生しているのです。
ポケモンの例では、種と個体に同一名を採用したが故に弁別の必要性が発生しましたが、プログラミング業界ではこれとは逆方向の問題が観測されます。
あるシステムを作ったとき、そのシステムで採用したフレームワークとサービスとの関係性が重ねられて語られることがあります。
これはトーテムが特殊化としてではなく普遍化として働いてしまう例です。
Ruby on Railsを利用して自分の独自サービスを開発しても、ある程度の距離感から評価を受けると「Railsのシステム」という判で押したような解釈をされます。
これはサービスごとの個別性よりもRailsのトーテムとしての存在感のほうが勝ってしまうからです。
弁別のために利用していたトーテムが逆に概念の収斂化を促進することもあるのです。
またポケモンに戻って例えると、マチスはでんきタイプのトーテムを持っているので、人によってはライチュウやコイルを見ただけでマチスを連想してしまう、といった具合です。
前章で取り上げたWordpressもとてもトーテム力(？)が高いのでWordpressを基盤にして、その上にどれだけシステムを構築しようと「Wordpressのシステム」というトーテムによる普遍化からは逃れられないでしょう。
種から個体弁別のためにトーテムを利用することもあれば、トーテムの持つ吸引力が逆に個体を種に収斂することもあるのです。
プログラミングとトーテム
その他にもプログラミングの世界ではトーテムの息吹を観測することができます。
言語名にはRubyやPerlなど宝石を冠したもの、JavaやPythonのように豆やヘビと紐付いた名前になったものがあります。
PHPやScalaは“Hypertext Preprocessor”と“scalable language”のように言語に対する期待をそのまま名前に反映したものもあります。
実際の生い立ちについては諸説あるでしょうが、言語には何かしらのシンボルとしてのトーテムが設定されていると考えることができます。
技術書の定番であるオライリーの表紙にはインパクトのある生物絵をトップにドンッと掲載しています。
オライリーの表紙を一覧にして眺めているとプログラミングまわりの概念にもトーテムが息づいていると感じませんか？
……感じませんか、そうですか。
トーテムを感じる要素はまだまだこれだけではありません。
プログラミングの世界にはたくさんのジャーゴン(専門用語・概念)が存在します。
デザインパターン、オブジェクト指向などの設計思想、キャメルケースなどのコード記述スタイルなど多様な言葉と概念があります。
これらの各種ジャーゴンは業界内の宗教戦争の火種によくなります。
一番代表的なのはVim vs Emacsのようなエディタ論争あたりでしょうか。
こういった宗教論争が起きる理由は、まずジャーゴンがトーテムとして機能していること。
ついで、前章で言及したトーテムには個体を種に収斂させる効果があること。
最後に、カーストとトーテムに親和性があることが起因していると考えられます。
『野生の思考』ではカーストとトーテムの関係にも言及しています。
カーストは本当の文化を偽って自然化するが、トーテム集団は偽りの自然を本当に文化とするのである
プログラマーの世界ではどのプログラミング言語が一番最高か(もしくはクソか)という醜い言い争いが頻発しています。
この問題自体は個人の好き嫌いとコンテキストに依存する問題なので、どのような結論が導き出されてもどうでもいいのですが、宗教戦争の一つとしてよく観測されます。
この章の最初で言語とトーテムの結びつきを指摘しましたが、言語がトーテムとして機能しているからこそ言語間の差異があらわになり、トーテムの個体から種に収斂する効果が人々をまとめ、そこからカースト付けの動機が発生し、言い争いを生むのです。
トーテム集団としてのプログラミング言語は自身の文化を自然化するための衝動を秘めています。
そこでの衝動欲求がカーストを呼び覚まし、宗教戦争が発生するのです。
概念に染み付いたトーテム性が宗教色を帯び、概念ごとに発生した差異が比較衝動を刺激し宗教論争へと発展します。
また宗教戦争以外でも、トーテムの残滓を観測することができます。
コード規約は相同性はあるもののプロジェクトや現場によってそれぞれ違います。
それぞれの現場で規約は自律性を持ち、それぞれが独自なものへと進化(時に退化)していく過程は部族の持つトーテム性と似通ったものがあります。
キャメルケースとスネイクケースの使い分けや命名規則による弁別のアプローチも概念分割欲求としてジャーゴンを生み、そのジャーゴンがトーテムの類似性を継承しているようにもみえます。
たくさん例を上げたので、そろそろプログラミングの世界にもトーテムの息遣いを感じて欲しいところです。
プログラミングは知識ではなく実践
トーテムについて長々書いてきましたが、ぶっちゃけトーテム周りの話はただの蛇足です。
プログラミングまわりの事象と『野生の思考』の内容を無理やり併合させようとしたあがきです。
プログラミングは野生の思考の産物でCSはその端女でしかないこと。
最初の引用にある概念の細分化の必要性が当エントリで伝えたかったことになります。
実践におけるプログラミングは常に未知との戦いなので、我々は常に「野生」の中でプログラミングを行っています。
学問領域はあくまでも野生で戦う我々をサポートしてくれる万能ツールに過ぎません。
戦場は常に野生であるのです。
最後に野生のプログラミングの実践編みたいな文章を過去に書いていたのでそれを紹介して終わります。
知識とパタン・ランゲージでは知識よりパターン認知が大事という話を(今読むとパターン認知も知識の一つでは？という気がしないでもありません)、spec考とプログラマーにアルゴリズム脳はいらないでは知識よりもトライアンドエラーが大事だという話を書きました。
トライアンドエラーこそが野生のプログラミングであり、知識よりも上位にある実践価値を生みだす水源となっているのです。