技術論

さんざん書き散らしてきておいてなんなんですが、というかさんざん書き散らかしてきたからこそそう思ったんですが。
「こうすればこういうことができるようになる」ということを、単なる技術＝スキルとして語ってしまうということは、結局のところ「やればできる」という精神論にすぎないのではないか、とよーやく得心したというか、なんというか。

たぶん「できないこと」に対して不寛容だということなんだとは思います。なんでできないのかわかんないから。わかんないのがわかんないってやつですね。
例は悪いと思いますが、掛け算がわかんない人がいて、教えたいのは二次関数とかなんだけど、前提となる「当り前の部分」がわかんないから、二次関数が教えられなくて、そもそもなんで掛け算がわかんないのかわかんないみたいな。だってわかる人にしてみたら掛け算は「わかってて当然」なんですもの。
でも最近、そういう態度というかなんというかを客観的に観察する機会があって。「ああ、こりゃだめかもしれん」としみじみと思ったわけです。
こういうこと書くと上から目線とか言われるかもしれませんが、そんなんとは全然違う話です。つーか上から目線なんて表現自体、無駄というか不毛というか。まあそんな個人的な主張はどうでもいいんですけども。

以前というよりはかなり昔、具体的には去年の暮れ頃ですが、id:koutyalemonさんとあれこれやりとりしたときに、システムと個人技術についてのエントリを書いてました。

フレームワークと個人技の境界 - TRPG履歴
http://d.hatena.ne.jp/standby/20071216/p1

で、この時すでにこんなことを書いておきながら、得心したのは最近になってからだっていう、本末転倒っちゃ本末転倒ですが、私としてはよくある話なのです。答えを求めてエントリを書くので、答えらしきものがエントリに書かれていたとしても、それが答えかどうかはその時点での私には判断がついていないのです。つける気がないことも多いです。
閑話休題。

で、「できないことがある人」がいたとして。
で、当然、「その人にできて欲しいことができてない」という状況だとした場合。
できる人からの「こうしたらできるんじゃないか」という例示はまあ優しさとかそういうもんかもしれないんですが、でもそれでできるようになるわけじゃないよねと。
あくまでも「自分はこうやったらできる（できた）」という話にしかならないし、なりえない以上、できてほしいことが結果的にできなかったとしても、その責任はできなかった人にはない。いや、まあ、努力とかそういうのはした上での話ですよ。頑張ったけどダメだったら、まあそれはしょうがないって話です。努力が足りなかったかどうかは問題にしない、ってことになります。
その時にどうするか、ってのは、もうシステム化するしかない、んだと思いますが（つまり、システム化するしかないぐらい努力してもできなきゃ、って前提です）、結局それで、なにかができるようになるわけじゃないんですよね。システム化によって得られるメリットって、「できなくても困らなくなる」だけなんですよね。
問題の解決、はまあしてるんですが、問題をなかったことにしてるとも言える。

というのも、最近仕事で手順書を作ってるんですが、手順書って、「こうやってやれば大丈夫だよ」ってことを書くんですけども、たとえばシステムの構築とか、チューニングを含めた細かい設定とかができるようになるわけじゃないんですよね。マニュアルはマニュアルでしかないというか。
「やりたいこと」が目的としてあって、「それをどうやって実現するか」ってのが設計としてあって、その上で「実際にどうやって設定するか」ってのがマニュアル＝手順書の領域なわけです。
で、手順書に沿ってれば設定はできる。作業はできる。けど、設計を理解できるわけじゃない。逆に、設計を理解してなくても、作業だけはできるようにするのがマニュアルなわけです。
HDDレコーダーがどうやって動いて録画をするかは知らなくても、マニュアル通り操作すれば、HDDレコーダーが設計通りに動いて、結果として目的通りに録画できる、みたいな理屈です。
よいマニュアルは、マニュアルに従ってれば設計も理解できるかもしれませんが、それ自体は副産物です。細かな機微を理解しなくても結果的に同じ効果が得られる、というのがマニュアル、引いてはシステムのメリットです。どれだけ緻密な設計がシステムに施されていようとも、使用者はそれを理解する必要はない。
しなくてもいいってことじゃないです。この辺の微妙なさじ加減がややこしい話ですが。

システム領域とユーザ領域 - TRPG履歴
http://d.hatena.ne.jp/standby/20080724/p1

とどのつまり、システム化というのは、システム設計者という専門家を生み出す仕組みでもある。それを利用するユーザは初心者かつ素人であり、永遠に初心者かつ素人であり続けても、なんら問題はない。どんだけHDDレコーダを使ったからって、HDDレコーダを設計できるようになるわけじゃない、というわけです。
重要なのは、システムの目的は、最終的には使用者＝初心者かつ素人が決めるということです。欲求という名の需要があり、それを充足するという供給があるからこそ、市場が形成される。商業的な目的を抜きにしても、需要と供給の構造は重要かつ必要になります。遊ばれないゲームは無駄どころの話じゃないですからね。
作者＝利用者という構図はありです。そこに必要最低限の需要と供給の関係がありますから。

ある種の矛盾というか、問題を恣意的にピックアップすると、初心者は永遠に初心者のままである、ということになると思う。向上しようと思っても余地がないというか。
そしてさらに突っ込んで考えると、そんな余地はそもそも必要なのか、ということにもなる。CRPGのタイムアタックのように、あるいはやりこみ系のように、使用者として操作に熟達することができるのであれば、システム設計者になれる必要はないということになり、別に初心者が初心者のままでも問題にはならないのではないか、ということ。
より深く理解して遊んだほうが面白い、というのは真理だろうと思う。けど、そんなことしなくても十分面白い、というのも真理で、ずっとそのレベルで、つまり突っ込んで遊ぶようにならなくたって、それでいいんじゃないか、とも思う。
遊び方のスタンス、の話でしかないけれど。いわゆる浅い遊び方をしている人に、海の底のほうから「こっちは面白いよー」と声をかけても、果たして通じるだろうか、なんてことも思う。「なんか息苦しそうだし暗そうだよ」と見えるんじゃないだろーか。

まあこういう発想は仕事柄かもしれないし、私自身が他人の技術にはあまり信を置いていないからなのかもしれません。他人に対する期待というのは、大概裏切られるものです。いい意味の場合と悪い意味の場合がごちゃまぜになった形で。
おそらくマニュアルに限らない話だと思いますが、「ここまでやれば大丈夫」みたいなわかりやすいセーフティーネットはない、ってのと、「じゃあどこまでやるか」ってののバランスなんだと思います。この辺はもう、かけられる手間の総量（工数）は決まってるんだから、その枠内で顧客満足度をどこまで上げるか、ってことになるんでしょう。
そういう意味では、最近のTRPGはニッチな方向に進んでるのかもなあ、なんてことも思いつつ（時間も手間も掛けないという前提があるなら、ニッチなニーズにターゲットを絞るしかないだろうから）。やっぱりもうちょっと簡単に遊べる仕組みが欲しいなあ、なんてことも。用語の統一ぐらいはかってもバチはあたらないと思うんですけども。
どっかの会社でTRPGのRFCみたいなの作りませんかね。業界的にお金ないからたぶん無理なんでしょうけど。

Request for Comments - Wikipedia
http://ja.wikipedia.org/wiki/Request_for_Comments

もちろん、標準の策定は足かせにもなるんですけどね。TRPGが"自由"であろうとする限り、標準は策定されえないんでしょうけど、私の立場は「足かせがあっても遊びやすければいい」ってスタンスですから。