3．なぜ「きちん」と見ないでよいのか
●前回の「自転車とプログラミングと」
前回は、自分がプログラミングに有利だと思っている「きちんと見」ない態度と、反対の「きちんと見ることを尊ぶ」ことについて、いろいろ述べました。
今回は、“常識で考えて不利だとしか見えない”「きちんと見」ないことがなぜ可能かについて持論をお話しします。
●おことわり
自分としましても、「目をつぶって自転車に乗れ」とか言うつもりはありません。
ただ、自転車に乗るときの「見方」は、普段の「見方」と違っているはずです。自転車に乗ることができる人なら、無理に没入しなくても自然とその「見方」になるはず。同様に、プログラミングにおいても、没入しなくても自然となる、プログラミングに有利な「見方」があっていいはずだというだけです。
前に見た地球軌道上での学園ドラマみたいなアニメで、このようなエピソードがありました。主人公の女の子（もし実在の人物なら、24世紀のグレース・ホッパーと言われていたかもしれません）が、入学当初に日ごろの実力が出せずあわあわしていたのを、同級生の「細かい情報を技術的に無視したら」というアドバイスで頭角を現した、なんてエピソードがありました。もしかすると、その程度の話なのかもしれません。
では、続きをどうぞ。
●普通なら危険きわまりない
自転車などで道路を走っていると分かると思いますが、機械が行き来する交通の場では、人間の仕草や行動や思考などが巻き起こすような「過度の加速度」は発生しません。
ペン回しやうちわであおる動作でできる加速度が、日常生活の交通の場で一切見られないことはご理解していただけやすいと思います。
そして、プログラミングも間違いなく、「機械が行き来する交通の場」に近い世界です。ゆえに、逆に人文的世界で確実に起こり得る危険に備えることは、意味がないだけでなく、ほかの数千～数万の潜在的な危険に備える能力をそぐという意味で有害ですらあります。
（人文的世界で起こり得る）思いもよらないことを「きちんと見」ていても、筋違いなのです。
●プログラミングとは
「機械が行き来する交通の場」に近いと申しましたが、その特徴として、
- プログラミングはワンパターンである
- プログラミングは、閉じていて発展しない世界である
- プログラミング過程では、文脈に依存して記述を相当圧縮している
ということが挙げられます。
IT分野に携わっている中で、企画する人や折衝する人は、オープンな世界で将来を見据えて考えるかもしれませんが、プログラミングの世界は違います。
周りから見て、恐ろしく保守的に見えると思います。見えるだけでなく、実際そうです。
あと、専門家でない限り「聞かないと分からない」というのもあります。プログラミングの文脈に応じた圧縮があまりに高効率であるため、ほぐして見れば分かる資料にしたうえで保存しろといわれても、膨大かつざんばらになってしまうために無理なのです。
（自分などはいい加減どうでもよくなってきていますが、もっと）若くて技術に真剣な人なら間違いなく、ほかの分野の人から自らの世界の崩壊を守ろうとするはずでしょう。その手段は間違いなく、徹頭徹尾「閉じた発展しない」世界を守ることです。
その世界では、すべての変数やオブジェクトが定義され、加えるものは現行踏襲されたものばかりです。
たとえまっさら状態からフルスクラッチで作ったプログラムであっても、そのプログラム環境の成り立ち（≒そのプログラム環境に備わっている部品の癖）に対して現行踏襲されたものばかりであるはずです。
その点を理解していただくと、「きちんと見」ないこともあり得ると思っていただけると思います。部品の癖なんて、見ても何もありません。
何回も使ってみて、やっていいことや部品にとって自然なことを会得するしかありません。
●全体を見回さなくても危険でない手法
プログラミングで必要な手法は、とにかく「閉じさせ」「発展を止めさせ」る手法です。その代表格として、
- 構造化プログラミング
- クラスや名前空間
があります。
こういう手法は歴然と確立していますが、当然「きちんと」見ようとしても見えません。
これについて、「きちんと見ることを尊ぶ」人間が「意地悪で情報を遮断された」と感じとってもまったく正当です。
ただ、「プログラミングはワンパターン」なので、“意地悪で情報を遮断された”ことに対する対抗手段として「その手法は禁止である」とされると、プログラミングをする人間は本当に困ります。それしかないのですから。
それで、その仕事はあきらめる必要が出てきます（現在のプログラマ不足の一因だと思います）。
●違う意味での「きちん」
『徹頭徹尾「閉じた発展しない」世界を守る』という振る舞いは、時として「技術」と「権限」の問題に突き当たります。
得に（SQL/PSMなどを除く）SQL言語など、万能でない言語の場合、簡素に表現できるようにするために受理できるパターンを制限している関係上、どうしても全関係者に徹底的に「守らせる」「権限」を欲する傾向にあります。
時は流れて……。
いまは、プログラミングをする人にそんな権限は一切ないので、かえってさっぱりしました。「権限」などは、「きちんと見」るリーダーに任せると良いです。もちろん彼らとの対立はありますが、まだ対立の方が、利益相反よりずっとましです。
若くて技術に真剣な人も、そういうリーダーとうまくやり合う必要があると思います。
この点も理解していただくと、「きちんと見」ないこともあり得ると思っていただけると思います。何が正しいかなんて、プログラマには責任がないのですから、大いばりで正しいことを要求すればよいのです。自分のいる車線の前後数メートルを仕切りきればよいのです。
●さらに
初心者の作ったプログラムを「レビュー」と称して見ることがあるのですが、彼らはプログラムのオブジェクトを1つの「エスニック」と見ている可能性があります。
iさんが1万回仕事をしているのに、jさんは100回しか仕事をしないことを憤ったり、flg-1さんばかりひいきしているからflg-2さんの顔も立てないとまずいのでは、と心配してみたりしているとしか思えない場合があります。
個々のオブジェクトは、同じ人の別の指だとか考えれば問題は起こらないかもしれませんが、プログラムのオブジェクトはそれなりに独立性があり、エスニックととらえた方が自然かもしれません。
ただ、このエスニックは人間関係とはまったく様相を異にする存在で、人間を処遇するように「見る」ことは、プログラミングにとって不利になります。もちろん、逆はもっといけません。プログラムのオブジェクトエスニックを扱うように人間を扱うと、極端な「上から目線」となり、規範に反することになるでしょう。
まぁ、今回はこんなことです。次回は、「プログラミングとは実際のところ何なのか」、について考察したいと思います。
●コラムのコメント欄の方針
コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。
ですので、このコラムで、
- わたしは基本的にコメントに答えない
- コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。