TRPG.NET > 月刊TRPG.NET / 2004年04月号 >
案内TRPG専門Web雑誌月刊TRPG.NETの記事です。 関連リンク
|
春も足早に初夏へと近づきゴールデンウィークも間近に迫った今日のこのごろ、皆様如何お過ごしでしょうか。一ヶ月ぶりの桜井@猫丸屋でございます。
お休み頂いた一ヶ月、何をしていたかと申しますと。
実は彼女ができてデート三昧なのでした!
──なんてわけもなく、ひたすら仕事をしておりました。けっ、社会人は年度末忙しいものだと決まってんだよっ。(逆ギレ)
まぁこの原稿を書いている今も仕事が忙しいのは相変わらず。要するに仕事を手際よく片付けられないだけの万年大忙し状態というわけでして。
ただ流石に年度末を過ぎて少しは時間が取れるようになりました。
この期に乗じてblog.桜井@猫丸屋と言うまんまな名前でblogを始めてみたり、orkutに加入したり。そんなこんなで遊びだけは忘れていなかったりします。(orkutってなんじゃ? という方はグーグルもこっそり「出会い系」--Orkut.com開始の裏にポータル帝国への野望をご覧あれ──まぁ、記事のタイトルそのまんまのサービスなんですが)
さてはて。毎度の事ながら長い前置きとなりました。
今回の記事ですが『依頼で遊び倒す! ─ 遊びの幅を広げる2つの考察』と題しまして依頼とは切っても切れない交渉をテーマに、TRPGでの遊びの幅を広げてみようという内容になります。
ヤ、ヤだなぁ。ボクだってたまにはお題に沿った記事くらい書きますよ。ホントですよ? ホントですってばぁ。
今回の目次は以下の通り。
各章の終わりにはまとめも設けてありますのでお忙しい方はまとめだけでもどうぞ。
依頼 ─ goo辞書の検索結果
(名)スル
(1)他人に用件を頼むこと。
(2)他人に頼ること。
三省堂提供「大辞林 第二版」より
唐突に辞書から『依頼』を引いてみたわけですが。
──まぁ、これだけでは「じゃぁTRPGでの『依頼』ってなんのさ」という考察にはなりませんね。しごくもっとも当たり前の話。
ともかくも辞書の意味を踏まえ、まずこの章では依頼元と依頼先という観点から『依頼の3つのパターン』を挙げてみたいと思います。
シナリオの導入部としてよく使われるNPCからPCへの依頼。これはもう今さら言うまでもない定番ですね。
大抵はシナリオ1つの導入で終わりますが、時にはキャンペーンを全体の導入になるようなケースもあります。(気楽な気持ちで引き受けた依頼が──というパターンですね)
もちろんシナリオの導入部に限る必要はなく、セッションの半ばやラスト近くでNPCからPCへの『依頼』がされてもいいわけです。
既に動き出した事件の最中、あるNPCからの『依頼』により状況が動き出したり混迷したり──なんて感じで。
それから次のシナリオへの引きとしてエピローグ部分やクライマックスでNPCからPCへの『依頼』を使うってのもありそうですね。
あまり普段は『依頼』と意識されないものとしてPCからNPCへの依頼があります。
例えば呪文を掛けてもらう,アイテムや人材を手配してもらう,傭兵を雇うなどお金の遣り取りで済むものから、依頼をすることそのもの或いは依頼相手の元にたどり着くところまでが丸々1セッションになるような依頼などまで。
前者はD&D 3eやソードワールドなどルール的に規定があるケースもあり、利用された経験のある方も少なからずおられるでしょう。
また後者は、ひと昔前のキャンペーンではガイドブックにも載っていた定番中の定番でした。
ちょっと珍しい(というよりあまり意識されていない)かもしれないのですがPCからPCへの依頼というのもあります。
例えば実際のシナリオでどんなものがあるかといえば。
まず真っ先に思いつくのは『七人のサムライ』(監督:黒澤 明)的な導入。
これは『ダンジョンシネマティーク』(朱鷺田祐介 著,富士見書房刊)という本でも紹介されていたのですが、要約すると『最初のシーンでPC一人に仲間集めの仕事を振ってしまう』──つまり最初に振られたPCにその後の導入を委ねてしまうスタイルです。
このやり方、昔のシステムでは完全にプレイヤー同士の裁量次第で使いどころが難しいものでした。しかし今ならば、FEAR系システムですっかり定着したハンドアウトやコネクションを結ぶルールを上手く使って、なかなかに味のある導入ができそうです。
またサイバーパンクものや現代物など、必ずしもPC達がチームを組んで一体としてシナリオに臨むとは限らないジャンルでもPCからPCへの『依頼』は多いでしょう。敢えてきちんと『依頼』のステップを踏むことで、より『らしい』セッションになるはずです。
PC同士の丁丁発止になることで場が盛り上がり、キャラクターの意外な一面を発見・演出するという効果も狙えますね。(もちろん適度なところでブレーキも必要になります。こればっかりではセッションが進みませんから)
それからPC同士の依頼の処理について。
演出に留めてしまう遊び方もあります(そしてその方が一般的かもしれません)が、この記事ではPC同士でもきちんとステップを踏んでいく遊び方をオススメしたいと思います。
と言うのは、幾ら仲間同士だからといって無制限に何かをしてくれるわけではないという原則を踏まえて遊んだ方が面白いから。(もちろんTPOはあります)
特にチームを組んでいるわけではない場合には、それぞれの立場に応じた損益があります。その辺りを踏まえて遊ぶほうが『意志決定ゲームとしてのTRPG』的にも『キャラクタープレイを楽しむゲームとしてのTRPG』的にもより面白いですし、おそらく上手な遊び方のはずです。(しつこく繰り返しますがTPOはありますよ)
そしてPCからPCへの『依頼』というのは『立場の違い』を意識しなおし、セッションの中で表現するチャンスになるわけで。ゆえにこの記事では演出だけに留めない遊び方をオススメする次第。
──そうそう。
それから『自分が何をして欲しいか明示的に伝えること(=依頼)をしないと相手もどうしたらいいかわからない』というのもありました。いちいちPCレベルでやってるとセッションの進行が滞りますが、そんなときはプレイヤーレベルででも意思表示をしたいところです。
この章では『依頼とは何か?』について、最初に一般的な意味で辞書的な意味を引き、次にTRPGにおける例を『依頼元と依頼主の関係』という切り口から三つのパターンを挙げてみました。
この交渉モデルは、交渉に関するルールモデルです。特定のゲームシステムに依存しないものとして考えられています。主にシナリオ/セッション中の、比較的重要な交渉(特にプレイヤーキャラクターからの働きかけ)を念頭においています。
本来、これら単純化されたモデル/ルール化を用いなくとも人はその経験によって交渉/取り引きのノウハウやルールを確立しているものです。
しかし個々の事例を取り上げていけば、いくら書いても追いつかないほどの量になってしまいます。
そこで、この交渉モデルは「セッションにおける交渉ルール運用」ではなく、交渉の仕組みを単純化することによる学習効果を主目的として組み立てる事にしました。
というわけでまた引用から始めてみたわけすが。(ちなみに引用させていただいた記事、今回の特集である『依頼』と密接に関連する『交渉』に関してよくまとまっています。是非ぜひ一読あれ)
どういう意図で引用させて頂いたかというと『個々の事例を取り上げていけば、いくら書いても追いつかないほどの量に
』なるという部分が『依頼』に関してもいえるからです。
前章では『依頼元』と『依頼先』の関係から3つのパターンを取り上げましたが──あれも、視点を変えてもっと具体的な話にしたら非常に多くなりますよね。
そうなると書いても書いても終わらない──なんてなコトにもなるわけで、TRPGにおける『依頼』の考察してはなんとも消化不良になりかねない。
そこで『モデル化』という手法を使ってTRPGにおける『依頼』の本質的な部分を整理してみようというのがこの章です。
しかし『モデル化』という言葉、あまり日常では馴染みのない言葉です。
いきなり始めてしまうとご存知ない方にはさっぱり。そうすると記事を書いたボクもがっくり──となっちゃいます。
なので、ちょっと寄り道して「じゃぁそもそもモデル化ってなんのさ?」と言うところから。
そもそも『モデル化』という言葉は数学やらなんやらの世界から来てる言葉──なんだそうです。(伝聞形なのはボクがコンピュータの世界での用法しか知らないから。というわけで、元々の数学やらの世界の使い方でなくコンピュータの世界の使い方で説明させて頂きます)
で、まず『モデル』というコトバは『具体的なモノやコト』を目的にそって簡略化した『抽象的なモノやコト』という意味です。
そして、この文脈で言われる『簡略化』のことをコンピュータの世界では『抽象化』あるいは『モデル化』すると言います。
じゃぁ、なんでモデル化なんてことをわざわざするのか,モデル化するとどんな良い事があるのかというお話に繋がっていくわけですが。
実はしごく単純な発想でありまして。
先ほども引用させていただいた通り『個々の事例を取り上げていけば、いくら書いても追いつかないほどの量に』
なるからなんであります。
そういう個別処理というのはコンピュータの世界ではスマートでないとかエレガントでないとか嫌われるところであります。それに『個々の事例』の中には余計なものも色々と引っ付いていたりもしていて整理/把握に向きません。
そこで『個々の事例』の中から『本質的な要素』,『共通的な要素』を抜き出し、個々の要素の関係を整理して改めて関連付けを行う──つまりモデル化をして、できるだけモノやコトを単純に分かり易く加工するわけです。
効能は『本質的なものだけを取り出せる』,『全体を見通しやすく整理できる』というところでしょうか。
ギリギリ言っちゃうと「けっきょく人間、単純なコトやモノの方が分かり易いわけさ」ってことなんです。
というわけで。5分でわかる『モデル化』のお話はここまで。次項からは、いよいよモデル化に移ります。
──とは言っても難しく構える必要はありません。
コンピュータの世界の言葉や手法はできるだけ使いません(ヤ、ボクノ手ニ余ルカラデハ決シテナイデスヨ?)し、そもそもモデル化はモノやコトを分かり易くするために行うわけですから。
大丈夫、ドロ舟大船にのったつもりで一つ『モデル化』の世界に飛び込んでみましょう。
まず最初に引いた辞書の意味を踏まえてTRPGでの『依頼』というものを文章にしてみます。
『依頼』は『依頼元(人物/組織)』が『頼みごと』を『依頼先(人物/組織)』に持ちかける行為である。
このとき通常は『頼みごと』の遂行と引き換えに『報酬(有形/無形問わず)』が支払われるか約束される。
この文章から『依頼』を構成する要素を抜き出して、簡単な説明をつけてみましょう。
これだけです。実に簡単ですね。 ただそれぞれの要素については、まだモデル化の余地がありそうです。次項以降でそれぞれの要素についてもモデル化をしてみましょう。
『依頼元』をモデル化します。 前項に倣って『依頼元』を文章にしてみましょう。
『依頼元』は『何らかの事情』により『頼みごと』を『依頼先』に持ちかける。通常、『依頼元』は『頼みごと』の遂行と引き換えに支払う『報酬』の『支払い能力』がある。
また何らかの『依頼先に関する情報』を持っていることもあるが、その質と量は場合により大きな幅がある。
この文章から『依頼元』を構成する要素を抜き出して簡単な説明をつけてみます。
このとき『依頼先』,『頼みごと』,『報酬』は『依頼』をモデル化した時点で別個の要素になっているので外して考えます。
今度は『依頼先』についてモデル化をしてみます。
『依頼先』を文章にすると以下のようになるでしょう。
『依頼先』は『依頼元』から『頼みごと』を引き受ける代わりに『報酬』を受け取る(もしくはその約束をする)。
このとき『依頼先』は『頼みごと』を遂行するための『遂行能力』と『遂行資源(時間など)』を持つ。
この文章から『依頼先』を構成する要素を抜き出して簡単な説明をつけてみます。
このとき『依頼元』,『頼みごと』,『報酬』は『依頼』をモデル化した時点で別個の要素になっているので外して考えます。
今度は『頼みごと』のモデル化です。 『頼みごと』を文章で表すと次のようになります。
『頼みごと』は『依頼元』から『依頼先』に持ちかけられる用件である。
『ミッション』(『達成すべき課題』ないしは『解決すべき問題』)を持ち、その遂行の際には時間制限や禁止事項などの『制約条件』,遂行を妨げる『障害』がある。
この文章から『頼みごと』を構成する要素を抜き出して簡単な説明をつけてみます。
このとき『依頼元』,『依頼先』,『報酬』は『依頼』をモデル化した時点で別個の要素になっているので外して考えます。
いよいよ大詰め『報酬』のモデル化です。 『報酬』を文章で表すと次のようになります。
『頼みごと』の遂行と引き換えに支払われるモノやコト。
『支払いのタイミング』は前払い,後払い,前後分割など様々なパターンがあり、その内容はふつう『依頼先』にとって何らかの『価値』があるモノやコトである。
この文章から『報酬』を構成する要素を抜き出してみます。 このとき『頼みごと』,『依頼先』は『依頼』をモデル化した時点で別個の要素になっているので外して考えます。
ここまで『依頼』を構成する各要素をモデル化してきました。
これだけでも交渉を考え直すときにヒントになる(なればいいなぁ)のですが──しかしながら個々の要素に着目した分析なので動き方が見え難いですね。
普通、コンピュータの世界でモデル化をする時にはモデル化の時点で個々の要素の動き方も記述して他の要素との関連を図にするんですが──
ただ、そこまでやると今度は図の見方まで解説しなければならない上、例え解説しても見慣れないうちは却ってわかりにくくなります。(あー、決してボクの作業が面倒くさくなるからではないですよ。えぇ、ホントですよ──ホントですってばぁ)
そこで。
ここまでモデル化した一連の内容を踏まえて『依頼』プロセスを追ってみたいと思います。これで動き方も見えるようになるはずです。
なお『依頼』の度に上のプロセス全てが必ず行われるとは限りません。
折衝に当たった担当者達の認識不足によりプロセスが飛ばされてしまう可能性もあります。それに『依頼先』と『依頼元』の力関係が圧倒的にどちらかに偏っていて調整の余地が生じない場合もありえます。
また最も頻繁に見られるだろうケースとしては『時間がそれを許さない』(ゲーム内時間,実時間問わず)という状況でしょう。
実際、セッションで依頼があるたびにいちいちのプロセスを処理していたら時間が幾らあっても足りなくなります。(マスターは常にプレイヤー達を陥れたくて仕方なく、そして不可解なことにプレイヤー達も危険な冒険に飛び込みたくて常に焦れているのです!)
もし『依頼』が単にシナリオの導入部に過ぎない,或いはセッションを進めていく上での過程にすぎない場合には省略されるのが普通ですし、そうすべきです。
この章では、前章とは視点を変えて『依頼』をモデル化しての考察を行いました。
まず最初は寄り道して「モデルとは何か? どうしてわざわざモデル化するのか?」というお話。
それから『依頼』のモデル化を行い、その結果を踏まえて『依頼のプロセス』を考察しました。
実践篇はリクエストがあれば改めて書いてみたいと思います。
とゆーわけで、もし読んでみて何か思うところがあったらば宜しく反響下さいませ。
それではまた来月!
感想・執筆宣言は一行掲示板001へどうぞ。
本記事の掲載月号のリスト
TRPG専門Web雑誌