2012-01-22
■[TRPG][親方]リアルの中にあるCP
おいちゃんの大好きなTRPGというゲームジャンルの中に、GURPS(ガープス)と言うシステムがありまして、その中でCP(Character Points : キャラクタポイント)という概念があります。
これがさりげなく「現実の考察」において便利だったりするので、ちょろりと書いてみようかと。
GURPSにおいて、CPとは概ね「その人の能力(を数値化したもの)の合計」になります。
つまり、ある人は「剣で戦うこと」が得意であったり、別の人は「魔法で戦うこと」が得意であったり、別の人は「宮廷で噂話との格闘」だったり、或いは「寝屋での以下略」だったり、まぁ個性は色々とあろうかと思うのですが。
同じ「100CPという数値」であれば、大体「同じくらいの強さだろう」という、仮想単位です。
…まぁつまり「得意分野」にうまいこと持ち込むと、25CPのキャラが100CPのキャラに勝てる瞬間もあるのですが(苦笑
言い方を変えると「得意分野にはめ込まない限り」、なかなか勝ち目は薄いってのもまた事実です。
んでまぁ。
このゲームにおいて、スキルは「CPを使って買う」ことを要求されます。
つまりCPってのは実際には「このキャラクタを作成するために消費されたCPの合計」なわけですね。ものっそ擬似的には「貨幣」ってみなしてもいいのかもしれない。
例えば…「剣戟で相手に攻撃を命中させる」という技を。
とある人が1CP支払って覚えると「剣戟：スキルレベル10」になったりします。このゲームだと「50%の成功率」です。
これが2CPを支払うと「スキルレベル11」となり、確立が62.5%に持ち上がります。4CP支払うと「スキルレベル12」、確率が74.1%。
結構違うわけですね。
ちなみに(…旧版の記述だったかもですが)、1CPは大体「200時間の学習と等価」なんだそうで。
200時間って数字はただのゲームタームなのですが、重要なのは「学習時間とスキルが、ある程度比例している」ってこと。
で、ここからが「リアルとの接続」。
多分、本当に多分、なのですが。
Aさん25歳とBさん25歳は、誤差はあるにしても、ある程度「同じ時間数」をすごしていると思うのですよ。GURPS的にいうと「同じようなCPを使ってる」わけですね。
ただ、ンじゃお二人が「どのスキルにCPを突っ込んでいるか」で、お二人のスキルの分布図は、えらいこと変わると思うんですね。
でまぁ…わりとよく見かけたり感じたり思ったりするのが。
例えばエンジニアで「そのわりに社内政治に妙に長けている」人って、どうしても「技術力が低い可能性が多い」ように見えまして。
それって多分「他のエンジニアが技術力の学習にCPを突っ込んでいる配分の中で、社内政治に大量のCP突っ込んでいる(分、技術力の学習にCPがまわせてない)」なぁ、って思うこととか、色々あるですよ。
いやまぁもちろん厳密には「人生の大半は寝てたからCP総計が少ない」とか「元の資質(GURPS的には能力値)が高いから、少ないCPでも高いスキルレベルになるから満遍なく高い」とかまぁ色々あるかとは思うのですが。
とはいえ、ある程度「CP総計」と「CPをどれくらい散らかして、どれくら一点集中させたか」っていう観点は、リアルでも有効なんじゃないかなぁ？ って思うですよ。
なんていう戯言をわりと昔から考えているので、なんとなくメモ。
■[親方]教えるのってやっぱり難しい…からいい勉強になる
相変わらずの教える系ネタです(「教育ネタ」って書くとなんか違うニュアンスが感じられるので、あえて言い方をホンのわずかにひねってます)。
んと…端的には、例えば「ソースコードレビュー」とかその辺にまつわるお話。
比較的楽なところだと
・コメントがない
・明らかなバグがある
あたりで、この辺は鋭く突っ込んで終わり………ってなわけにもいきません。
「"なぜ"このようなバグを生み出してしまったのか」という、相手の思考ルートに思いを馳せて、可能であれば「その原因を元から滅する」ほうがよりよいです。
ただまぁそれでもなお「これは違うよね？」ですみます。
素晴らしいソースコードやインタフェースであれば、その成長をたたえたり祝ったりほめたり言祝いだりしていけばOKです。
問題は、その中間地点。
つまり「明らかなバグではないものの」「嫌なにおいが漂う(可能性のある)」コード。言い方を変えると「とりあえず、自分の好みからはかけ離れた」コード。
ちなみに「下手糞なソースコードレビュアー」は、このあたりを「間違いである」と断じてしまいます、が、おいちゃん的にはそのリアクションは「いかがなものか」感満載でございます。
実際問題として「自分の好みから外れている」コードには、分岐点が存在します。
一つは「考え方や捕らえ方、切り口の違い」。もう一つは「後で厄介な状況が発生する可能性のある、技術的負債を含む」もの。
後者は、きちんと「こういう状況においてこうなるから、この部分についてはまずいから直しましょう」とか言える…のですが。
問題は「どこまで直させるか」。
「全面書き直し」とかいうのは大変に楽ではあるのですが、下手をすると「学習している子のやる気とか意欲とか」そのあたりを、一式、根こそぎ消滅させかねません。
「適切かつ最小限、ピンポイント」な修正の指示は、非常に難易度の高いものがございます。
んで、より難しいのが前者の「考え方や捕らえ方、切り口の違い」。
まず、それを見た瞬間に「考え方や切り口が違うこと」を認識、その直後数秒で「その思考を噛み砕き」「それによって、とりあえず将来"比較的高確率で"起こる可能性のある事象と、その事象をこの実装にぶつけた場合に問題がないか？ 或いは問題があるか？ のシミュレート」をやる必要があります。
正直なところ、脳みその回路が焼ききれそうになる速度と思考量が、ここで発生します(苦笑
それをやった上で「明らかな問題がある」場合、上述の通り「適切かつ最小限、ピンポイントな修正の指示」を。
問題がない、或いは少なくとも見当たらない場合は「一端修正を飲み込む」必要があるんですね。
…ってなことを心がけてやっていくと、他人のソースコードが本当によい、勉強とトレーニングになります。
書いてあるのは、ぶっちゃけ本当に「無茶レベルの」要求ではありますが。
ソースコードのレビュー、などということをしたり、人様に物事を教えたりするのであれば。
自らにも「ある程度のハードル」を課してみる、ってのも一興かと思うのですが、どんなもんなんですかね？
