by antonin
検索
最新の記事
記事ランキング
タグ
雑感(302)
雑談(151) 妄想(126) ニュース(96) 散財(77) web(65) おバカ(59) 検索(54) 親バカ(45) 日本語(41) PC(40) 季節(39) 昔話(35) 信仰(31) 政治経済(29) イベント(27) 言語(25) 音楽(24) 言い訳(22) ビール(15) 以前の記事
最新のコメント
ライフログ
ブログパーツ
ブログジャンル
|
タイトルは「将棋とチェス」でもよかったのだが、新書風に少し遊んでみた。とはいえ、しばらく本題には入らない。 今は人を動かす仕事を半ば放棄していて、まだ自分の手でプログラムを書いているが、最近ようやく新しい言語環境で仕事ができる許可をもらった。新しい言語仕様ではシンプルな記述で耐障害性の高いコードを書くことができる。若干パフォーマンスは落ちるが、今書いているのは高いパフォーマンスを要求されるようなプログラムではないので、そのあたりは問題ない。記述が簡潔になり、個人的には満足している。 ただし、新しい文法による記述の中には古い静的解析ツールに読めない表現があり、古い定型表現を強制してくるようなバイオレーションが出ることがある。最近は仕事の自由度もいくらか上がっているので、ちゃんとJustificationコメントを書き、ここの警告は抑制しろというディレクティブや属性を追記して、テストグリーンになるようにしている。 しかし、これはちょっと別の問題を含んでいるのかもしれないとは思うようになった。同じ言語の新しい仕様には、記述を簡便にするような新しい文法要素が追加されるのだが、それはさほど高度ではないにしても、従来とはいくらか違った概念が持ち込まれている。もちろん、表現としてよりスッキリと書けるように過剰な制約を廃止しただけのものもあるのだが、中には当然、他の実験的な言語で成功した新概念を導入したものもある。そういう新概念は、静的解析ソフトだけではなく、人間にとっても読みにくくなっているという可能性もあるのではないか。 C#のような実用言語の世界では、あまり高度な抽象概念が持ち込まれることはない。それでも、オブジェクトとは即ちメモリアドレスの呼び名の問題である、というような手続き思考の組み込みC言語のパラダイムで職業人としての初期訓練を受けてきた人たちの中には、オブジェクト指向の古典的なパターンにさえ苦手意識を持つ人がいる。そういうファーム上がりの技術者の中には、強力なプロセッサに依存したソフト屋の抽象的なコーディングを嫌う人もいる。 自分も8bitプログラミングを知らないではないので、静的なメモリに対して固定的なルーチンを実行したときの処理速度の高さは知っているし、そういうのを好むのも感情的には理解できる。ただ、私は仕事としてプログラミングを始めたのが今世紀に入ってからなので、あまり古い技巧に精通しているわけでもない。学生時代に独学した、ポインタを使うような「アルゴリズムとデータ構造」なら知っているが、改修による単体テスト項目を最小化して短納期で仕上げる仕様書の書き方だとか、テストコードを書かず、従ってリファクタリングも許されない中でのデバッギングであるとか、そういう実務的な泥臭いノウハウはほとんど持っていない。 仕事でプログラミングを始める前には、独学でいくらか本を読んだのだが、個人的な好みもあって、英語で書かれたテキストの翻訳を読むことが多かった。そこでは間接的に、アメリカでのソフトウェア開発の常識が空気のように含まれていた。しかし日本で実務に就いてみると、アメリカの、殊に西海岸で行われていた先進的な開発とは違うスタイルの開発が行われていて、それはどうやら、大戦前にイギリスやドイツから導入し、その後国内で独自に発展させられた、工部省や国鉄などに起源を持つ工程管理手法の系統らしいことに気付いた。 そういう仕組みが使われているならそれを学ばなければならないのだが、特にシステマティックな理論教育や認証試験制度が確立しているわけではなく(かつてはあったのかもしれないが)、もっぱら先輩から後輩への「OJT」によって新人時代に叩き込まれるのが基本となっているらしい。私は業種も業界も企業系列も全て移動する転職をやったので、新人時代のノウハウをそのまま流用することはできない。ソフトウェア開発面では翻訳書に頼った独学をしたため、テストファーストのアジャイルに近いスタイルが基本になっている。どちらも今の職場には合わない。 新人時代には、標準作業無くして作業管理無しという具合で、実験的段階が終わって定型化してきたどのような作業にも作業標準書を書かされたものだが、今の職場には作業標準書を書く習慣はない。一方で、ウォーターフォール的な厳格な仕様書作成は要求される。ただし、これをやっているのは開発の受け手である立場の要求であって、発注側としてはより自由な、摺り合わせによる漸進的な仕様の洗練化を伝統としている風でもあり、職場には多少の葛藤が残っている。その上、先に述べたような個人的な葛藤もあって、いろいろとややこしい。 日本では学問から実務への展開は重視される一方で、実務から学問へと抽象化していく過程が軽視されていて、結果として学問の陳腐化が早いという問題があるように思うが、これはまた別の話として、ここでは、私の職場にいる日本人のプログラミングスタイルと将棋の関係性について妄想してみたい。 私の職場はそれなりに学歴を積んで社会的素質、いわゆる「人間性」にも大きな問題のない人が集まっているのだが、彼らの書くプログラムが(私から見ると)異様に汚い。古いコードがメンテナンスされて使い続けられているから、古い時代に固有の制約が色濃く残っているというのもあるのだが、それにしてもある種の複雑性が当たり前に認められていて、私が独学したコーディングの優先事項に真っ向から逆らうソースコードが使われている。 彼らのコードは、私の世代なら大学の教養課程で習ったような、今の若い人なら高校や中学で習ったような、ごく初歩的な制御構造だけを使い、その代わりにコード上には見えないグローバル変数の挙動を正確に頭に入れていないと動作を保証できないような複雑さにしっかりと対処したプログラムとなっている。網の目を丹念に編み上げたミクロなネットワーク(糸で編み上げた手芸作品)構造が作られている。 私は記憶力が悪いので、そういう多数の要素が遠くから影響している構造を見ていると頭が痛くなり、独学した原則にならって、リファクタリングにより要素と関係を局所化したい要求にかられるのだが、残念ながらそういうリファクタリングをするための予算は付かないと言われている。リファクタリングせずに品質だけ上げろと言われており、過去の担当者はそれをしていたらしいのだが、私にはこれが難しい。 学生時代の優等生を思い返してみたときに、ある一線を越えた天才的な生徒は、数学の難問などに対して正体不明のパターンを持ち出して一刀両断にエレガントな解を出すのだが、秀才的な優等生は、単調な手順を複雑に、しかし間違いなく繰り返すことで正解に到達していた。いま職場で目にするコードは、この後者の優等生の回答を連想させる。 この、個別には難しくない関係を多数持ち込んで複雑になって私を悩ます問題というと、もう一つ思い出すのが将棋だった。ここでようやく本題に入れた。将棋というのは、まあオセロほどではないにしてもルールは単純で、それぞれの駒の動きを覚えるのはそれほど困難でもない。ただ、一度死んだ駒が生き返ることで、盤面の複雑さはいつまでたっても収束しない印象がある。中盤では、頭を抑えられていた駒が、自分や相手の駒の動きで利きを回復することがあるし、もちろん、将棋では相手から取った手駒を自由な位置に打つことができる。 数学の問題を解くのに複雑な中間過程を扱う秀才だとか、初歩的な制御構造を複雑に絡めて完動するプログラムを書く社員だとかを見ていると、何か器質的な能力を駆使しているのを感じるし、そういう人の評価が高い背景には、将棋というゲームを好む日本人の国民性と何か通底するものがあるのではないかとも感じている。 私は将棋もチェスもあまり良く知っているわけではないし、将棋とチェスを日欧の文化論と絡めた論説はすでに多いので、あまり細かいことを語る気はないのだが、敢えて気付いたことを挙げると、将棋が複雑さを楽しむゲームなのに対して、チェスは複雑さを単純化することを楽しむゲームだという違いがあるのではないかと感じた。 将棋もチェスも、開戦時には静的なピース配置となっており、エントロピーは小さい。そこから、定跡などは使いながらも、徐々に個々の棋譜に固有のエントロピーを足していく。このあたりまでは、将棋もチェスもそう変わらないところだろう。ここから先の将棋とチェスの大きな違いと言えば、将棋ではピースの「成り」がある程度恣意的であることと、取った相手のピースを手駒として自由配置できることだろう。 ポーンのプロモーションは、動けなくなったから動きを変えるという程度のものでしかないし、クイーン以外へのプロモーションはあまり無いと聞く。恣意性がないわけではないものの限定的で、しかもルール改定の過程でその恣意性はより限定される方向へ進んできたとも聞く。そう考えると、チェスというのは、序盤の整然とした状況を中盤の混乱に持ち込みながらも、最終的には混乱を刈り込んで終盤の整然さへと持ち込むゲームに見える。 一方の将棋は、序盤の整然とした状況から急速に混乱に持ち込み、混乱を混乱のまま制したものが勝ちというゲームに見える。チェスも将棋もインドあたりのボードゲームに起源をもっていて、それが西廻りと東回りに発展したものだという。だとすれば、西回りに進んだチェスの愛好家は、複雑さを扱うストレスを好むものの、それを最終的には単純化していくことに喜びを感じる人々であると言える。一方東回りに進んだ将棋の愛好家は、複雑さを扱うストレスそのものに対する耐性を競い合うことに喜びを感じる人々であったと、荒く推定することができる。 ゲームというのは、遊ぶ人が楽しくなるように改定されていくはずだ。であれば、長く遊ばれたゲームのルールには、それを遊んできた人たちの好みが転写されているはずだ。人殺しゲームを咎められたアメリカ人の攻撃性が生み出したのがゾンビゲームだろうし、少女愛を咎められた日本人の偏愛が生み出したのがアニメ絵のゲームだろう。 まあ、そこまで犯罪的に言わなくても、主流にある人々が何を楽しいと感じるかがその地域のゲームに反映されていくのだと考えれば、西洋人は複雑さを解決する楽しみを追求することでチェスを生み出し、日本人は複雑さを競う楽しみを追求することで将棋を生み出したのだと言えるだろう。 そして、高度な抽象概念を使ってシンプルなコードを書くよりも、初等な抽象概念を高度に絡み合わせて複雑なコードを書くことを好む日本の秀才を生み出した背景に、将棋を愛する国民性、タイトルに従って過激に書けば、国民病があるのではないかと考えた。そして、国民病とは言いながら、それが後進性だとか蒙昧だとかは思えない。単に、複雑さを扱うことに長けた典型的な国民の性に合っているのだろう。そういう面では私は全く典型的でない。複雑さは生まれるそばから斬り殺し、抽象概念の墓標を建ててその下に埋めるのを好む。これは、必ずしも教育効果だけではなく、器質的な理由もあるのだと想像している。 ただ、そういうふうに処理のパターンごとに抽象概念の墓標が並んだ殺風景なソースコードに、シンプルだったりエレガントだったりという好意的な印象を抱かず、具体的な内容を隠蔽しようとする意地悪な仕業に見えるという感覚にも想像が到る。だって、あのWikipediaの数学系項目にある説明を見てみれば、そういう気持ちが痛いほどわかるじゃないか。 簡単であることはそれ自体がメリットである、という意見もわかる。一方で、その分野のプロなんだから、ある程度の抽象概念のセットくらいは持ち合わせておけよ、と言いたい欲求もある。どうなんだろうなぁ。また例によって最適点は中庸にあるのだろうが、中庸というのはその場にいると見えなくなるものだ。 自分はどの程度偏っているのだろう。手持ちの書籍やブログの情報を見ると全く偏っていると思えないのだが、身の回りの人々や/.Jのコメントの一部を見ると、私は多少西海岸的なやり方に偏っているようにも思える。大きな企業の社員というのはある種の役人であり、アジャイルな役人というのも確かに困りものではある。でも、アジャイルとは日本的な「摺り合わせ」のスタイルを西洋化したものじゃなかったのか? 科学(science)を技術(technique)に落とし込んでいくのが工学(engineering)であり、技術を陳腐化させて商売の道具にするのが産業(industry)である。そして、技術(technique)から科学知識を再抽出していくのが科学技術(technology)である。エンジニアリングとテクノロジーは表裏一体の関係にあると思うのだが、「日本には技術力がある」というのは一体何を指していたのだろう。 科学知識を定義する決然とした数式の整然さから、工学は混沌とした技術の塊を作り出していく。チェスのスタイルにならえば、ともかくも現実世界に産み落とされた技術たちは、technology(技術学)によって再び整然さを取り戻すべきで、そこからより抽象的で整然とした科学の世界へ返るか、標準技術として産業化の道具になる。一方、将棋の流儀に従えば、技術の混沌さをそのままに扱える技能を持った人が尊ばれ、その言語化し難い何かを人から人へ脈々と受け継いでいくべきなのだ。 Wikipediaの項目などを見ても、System engineeringに比べてシステム工学の貧弱さに暗澹とするが、日本には日本の徒弟制(OJT)に支えられてきた技術(technique)があり、盗まなくても学べば済む知識へと還元していくテクノロジーやエンジニアリングの発展はあまり必要としないのだろう。戦争などをしないのならば、それはそれでいいのではないのだろうか。唐から伝来した雅楽を今に伝える日本人の誇りが、そこにはきっとあるのだ。
by antonin
| 2017-08-27 01:29
|
Trackback
|
Comments(0)
|
ファン申請 |
||