Warning: Trying to access array offset on false in /home/cre-ne-jp/www/trpg.net/wp-content/plugins/only-tweet-like-share-and-google-1/tweet-like-plusone.php on line 242

Warning: Undefined array key 0 in /home/cre-ne-jp/www/trpg.net/wp-content/plugins/only-tweet-like-share-and-google-1/tweet-like-plusone.php on line 229
2004年04月号

依頼で遊び倒す─依頼に関する2つの考察

特集: 単発記事
筆者: 桜井@猫丸屋

0.近況報告と前置き

定番のご挨拶と近況など

 春も足早に初夏へと近づきゴールデンウィークも間近に迫った今日のこのごろ、皆様如何お過ごしでしょうか。一ヶ月ぶりの桜井@猫丸屋でございます
 お休み頂いた一ヶ月、何をしていたかと申しますと。
 実は彼女ができてデート三昧なのでした!
 ──なんてわけもなく、ひたすら仕事をしておりました。けっ、社会人は年度末忙しいものだと決まってんだよっ。(逆ギレ)

 まぁこの原稿を書いている今も仕事が忙しいのは相変わらず。要するに仕事を手際よく片付けられないだけの万年大忙し状態というわけでして。
 ただ流石に年度末を過ぎて少しは時間が取れるようになりました。
 この期に乗じてblog.桜井@猫丸屋と言うまんまな名前でblogを始めてみたり、orkutに加入したり。そんなこんなで遊びだけは忘れていなかったりします。(orkutってなんじゃ? という方はグーグルもこっそり「出会い系」–Orkut.com開始の裏にポータル帝国への野望をご覧あれ──まぁ、記事のタイトルそのまんまのサービスなんですが)

 さてはて。毎度の事ながら長い前置きとなりました。
 今回の記事ですが『依頼で遊び倒す! ─ 遊びの幅を広げる2つの考察』と題しまして依頼とは切っても切れない交渉をテーマに、TRPGでの遊びの幅を広げてみようという内容になります。

「なんだ珍しい。お題に沿った記事じゃないか──さてはネタ切れおこしたか?」

 ヤ、ヤだなぁ。ボクだってたまにはお題に沿った記事くらい書きますよ。ホントですよ? ホントですってばぁ。

とゆーわけで、今回の目次!

 今回の目次は以下の通り。
 各章の終わりにはまとめも設けてありますのでお忙しい方はまとめだけでもどうぞ。

  1. 依頼されたり依頼したり:『依頼元』と『依頼者』で考えてみる
    『依頼元』と『依頼先』の関係に着目して、セッション中での『依頼』の位置付け,扱われ方を考えてみます。
    1. 『依頼』で辞書を引いてみた
    2. NPCからPCへの依頼
    3. PCからNPCへの依頼
    4. PCからPCへの依頼
    5. この章のまとめ
  2. 人と依頼とプロセスと:『依頼』をモデル化してみる
    1章の内容から、まるきり視点を変えて『依頼』をシステム的な発想で考察してみます。ちゃんと『モデル化』という考え方の説明から始めますので「モデル化ってなんじゃい?」という方でも大丈夫です。
    1. 5分でわかる(かもしれない)『モデル化』のお話
    2. 『依頼』をバラバラにしてみる
    3. 『依頼元』をバラバラにしてみる
    4. 『依頼先』をバラバラにしてみる
    5. 『頼みごと』をバラバラにしてみる
    6. 『報酬』をバラバラにしてみる
    7. 『依頼』のプロセスを考察してみる
    8. この章のまとめ

1.依頼されたり依頼したり:依頼とは何かを理解する

1-1.『依頼』を辞書で引いてみた

依頼 ─ goo辞書の検索結果
(名)スル
(1)他人に用件を頼むこと。
(2)他人に頼ること。

三省堂提供「大辞林 第二版」より

 唐突に辞書から『依頼』を引いてみたわけですが。
 ──まぁ、これだけでは「じゃぁTRPGでの『依頼』ってなんのさ」という考察にはなりませんね。しごくもっとも当たり前の話。
 ともかくも辞書の意味を踏まえ、まずこの章では依頼元と依頼先という観点から『依頼の3つのパターン』を挙げてみたいと思います。

1-2. NPCからPCへの依頼

 シナリオの導入部としてよく使われるNPCからPCへの依頼。これはもう今さら言うまでもない定番ですね。

 大抵はシナリオ1つの導入で終わりますが、時にはキャンペーンを全体の導入になるようなケースもあります。(気楽な気持ちで引き受けた依頼が──というパターンですね)

 もちろんシナリオの導入部に限る必要はなく、セッションの半ばやラスト近くでNPCからPCへの『依頼』がされてもいいわけです。
 既に動き出した事件の最中、あるNPCからの『依頼』により状況が動き出したり混迷したり──なんて感じで。
 それから次のシナリオへの引きとしてエピローグ部分やクライマックスでNPCからPCへの『依頼』を使うってのもありそうですね。

1-3. PCからNPCへの依頼

 あまり普段は『依頼』と意識されないものとしてPCからNPCへの依頼があります。

 例えば呪文を掛けてもらう,アイテムや人材を手配してもらう,傭兵を雇うなどお金の遣り取りで済むものから、依頼をすることそのもの或いは依頼相手の元にたどり着くところまでが丸々1セッションになるような依頼などまで。
 前者はD&D 3eやソードワールドなどルール的に規定があるケースもあり、利用された経験のある方も少なからずおられるでしょう。
 また後者は、ひと昔前のキャンペーンではガイドブックにも載っていた定番中の定番でした。

1-4. PCからPCへの依頼

 ちょっと珍しい(というよりあまり意識されていない)かもしれないのですがPCからPCへの依頼というのもあります。

 例えば実際のシナリオでどんなものがあるかといえば。
 まず真っ先に思いつくのは七人のサムライ(監督:黒澤 明)的な導入。
 これはダンジョンシネマティーク(朱鷺田祐介 著,富士見書房刊)という本でも紹介されていたのですが、要約すると『最初のシーンでPC一人に仲間集めの仕事を振ってしまう』──つまり最初に振られたPCにその後の導入を委ねてしまうスタイルです。
 このやり方、昔のシステムでは完全にプレイヤー同士の裁量次第で使いどころが難しいものでした。しかし今ならば、FEAR系システムですっかり定着したハンドアウトやコネクションを結ぶルールを上手く使って、なかなかに味のある導入ができそうです。

 またサイバーパンクものや現代物など、必ずしもPC達がチームを組んで一体としてシナリオに臨むとは限らないジャンルでもPCからPCへの『依頼』は多いでしょう。敢えてきちんと『依頼』のステップを踏むことで、より『らしい』セッションになるはずです。
 PC同士の丁丁発止になることで場が盛り上がり、キャラクターの意外な一面を発見・演出するという効果も狙えますね。(もちろん適度なところでブレーキも必要になります。こればっかりではセッションが進みませんから)

 それからPC同士の依頼の処理について。
 演出に留めてしまう遊び方もあります(そしてその方が一般的かもしれません)が、この記事ではPC同士でもきちんとステップを踏んでいく遊び方をオススメしたいと思います。
 と言うのは、幾ら仲間同士だからといって無制限に何かをしてくれるわけではないという原則を踏まえて遊んだ方が面白いから。(もちろんTPOはあります)
 特にチームを組んでいるわけではない場合には、それぞれの立場に応じた損益があります。その辺りを踏まえて遊ぶほうが『意志決定ゲームとしてのTRPG』的にも『キャラクタープレイを楽しむゲームとしてのTRPG』的にもより面白いですし、おそらく上手な遊び方のはずです。(しつこく繰り返しますがTPOはありますよ)
 そしてPCからPCへの『依頼』というのは『立場の違い』を意識しなおし、セッションの中で表現するチャンスになるわけで。ゆえにこの記事では演出だけに留めない遊び方をオススメする次第。

 ──そうそう。
 それから『自分が何をして欲しいか明示的に伝えること(=依頼)をしないと相手もどうしたらいいかわからない』というのもありました。いちいちPCレベルでやってるとセッションの進行が滞りますが、そんなときはプレイヤーレベルででも意思表示をしたいところです。

1-5. この章のまとめ

 この章では『依頼とは何か?』について、最初に一般的な意味で辞書的な意味を引き、次にTRPGにおける例を『依頼元と依頼主の関係』という切り口から三つのパターンを挙げてみました。

  1. NPCからPCへの依頼
    • セッション導入部の定番中の定番だぞ
    • 時にはキャンペーン全体の導入としても使われることがあるんだぞ
    • 導入以外でも既に進行中の事態を進展させたり混迷させたり、次回への引きとして使ったりと用途は幅広いぞ
  2. PCからNPCへの依頼
    • お金の遣り取りで話のつく依頼と、依頼するだけで丸々1セッションになるタイプの依頼があるぞ
    • 前者のタイプはルールブックに規定のあるシステムと、規定のないシステムがあるんだぞ
    • 後者のタイプは、キャンペーンのガイドブックに載るくらい定番中の定番なんだぞ
  3. PCからPCへの依頼
    • 七人のサムライ』+ハンドアウトとコネクションのルールで味のある導入部が組めるぞ
    • PC達がチームを組むとは限らないシステムの場合、セッションの進行中に普通に起こりうるんだぞ
    • 『PCそれぞれの立場と損益を踏まえた行動選択』は、より面白い『意思決定』や『キャラクター表現』に繋がるので活用すると吉だぞ (でもTPOには気をつけようだぞ)
    • 『自分が何をして欲しいか明示的に伝えること(=依頼)をしないと相手もどうしたらいいかわからない』んだぞ (でもいつもPCレベルでやってるとセッションの進行を妨げるぞ。そんなときはプレイヤーレベルで意思表示だぞ)

2. 人と依頼とプロセスと:『依頼』をモデル化してみる

2-1. 5分でわかる(かもしれない)『モデル化』のお話

 この交渉モデルは、交渉に関するルールモデルです。特定のゲームシステムに依存しないものとして考えられています。主にシナリオ/セッション中の、比較的重要な交渉(特にプレイヤーキャラクターからの働きかけ)を念頭においています。
 本来、これら単純化されたモデル/ルール化を用いなくとも人はその経験によって交渉/取り引きのノウハウやルールを確立しているものです。
 しかし個々の事例を取り上げていけば、いくら書いても追いつかないほどの量になってしまいます。
 そこで、この交渉モデルは「セッションにおける交渉ルール運用」ではなく、交渉の仕組みを単純化することによる学習効果を主目的として組み立てる事にしました。

 というわけでまた引用から始めてみたわけすが。(ちなみに引用させていただいた記事、今回の特集である『依頼』と密接に関連する『交渉』に関してよくまとまっています。是非ぜひ一読あれ)
 どういう意図で引用させて頂いたかというと『個々の事例を取り上げていけば、いくら書いても追いつかないほどの量に』なるという部分が『依頼』に関してもいえるからです。
 前章では『依頼元』と『依頼先』の関係から3つのパターンを取り上げましたが──あれも、視点を変えてもっと具体的な話にしたら非常に多くなりますよね。
 そうなると書いても書いても終わらない──なんてなコトにもなるわけで、TRPGにおける『依頼』の考察してはなんとも消化不良になりかねない。
 そこで『モデル化』という手法を使ってTRPGにおける『依頼』の本質的な部分を整理してみようというのがこの章です。

 しかし『モデル化』という言葉、あまり日常では馴染みのない言葉です。
 いきなり始めてしまうとご存知ない方にはさっぱり。そうすると記事を書いたボクもがっくり──となっちゃいます。
 なので、ちょっと寄り道して「じゃぁそもそもモデル化ってなんのさ?」と言うところから。

 そもそも『モデル化』という言葉は数学やらなんやらの世界から来てる言葉──なんだそうです。(伝聞形なのはボクがコンピュータの世界での用法しか知らないから。というわけで、元々の数学やらの世界の使い方でなくコンピュータの世界の使い方で説明させて頂きます)
 で、まず『モデル』というコトバは『具体的なモノやコト』を目的にそって簡略化した『抽象的なモノやコト』という意味です。
 そして、この文脈で言われる『簡略化』のことをコンピュータの世界では『抽象化』あるいは『モデル化』すると言います。

 じゃぁ、なんでモデル化なんてことをわざわざするのか,モデル化するとどんな良い事があるのかというお話に繋がっていくわけですが。
 実はしごく単純な発想でありまして。
 先ほども引用させていただいた通り『個々の事例を取り上げていけば、いくら書いても追いつかないほどの量に』なるからなんであります。
 そういう個別処理というのはコンピュータの世界ではスマートでないとかエレガントでないとか嫌われるところであります。それに『個々の事例』の中には余計なものも色々と引っ付いていたりもしていて整理/把握に向きません。
 そこで『個々の事例』の中から『本質的な要素』,『共通的な要素』を抜き出し、個々の要素の関係を整理して改めて関連付けを行う──つまりモデル化をして、できるだけモノやコトを単純に分かり易く加工するわけです。
 効能は『本質的なものだけを取り出せる』,『全体を見通しやすく整理できる』というところでしょうか。
 ギリギリ言っちゃうと「けっきょく人間、単純なコトやモノの方が分かり易いわけさ」ってことなんです。

 というわけで。5分でわかる『モデル化』のお話はここまで。次項からは、いよいよモデル化に移ります。
 ──とは言っても難しく構える必要はありません。
 コンピュータの世界の言葉や手法はできるだけ使いません(ヤ、ボクノ手ニ余ルカラデハ決シテナイデスヨ?)し、そもそもモデル化はモノやコトを分かり易くするために行うわけですから。
 大丈夫、ドロ舟大船にのったつもりで一つ『モデル化』の世界に飛び込んでみましょう。

2-2.『依頼』をバラバラにしてみる

 まず最初に引いた辞書の意味を踏まえてTRPGでの『依頼』というものを文章にしてみます。

 『依頼』は『依頼元(人物/組織)』が『頼みごと』を『依頼先(人物/組織)』に持ちかける行為である。
 このとき通常は『頼みごと』の遂行と引き換えに『報酬(有形/無形問わず)』が支払われるか約束される。

 この文章から『依頼』を構成する要素を抜き出して、簡単な説明をつけてみましょう。

  • 『依頼元』
    依頼を行う人物もしくは組織
    TRPGではPCもしくはNPC
  • 『依頼先』
    依頼を持ちかけられる人物もしくは組織
    TRPGではPCもしくはNPC
  • 『頼みごと』
    『依頼元』が『依頼先』にもちかける用件
    TRPGでは『シナリオのミッション』であることが多いが『既に起こっている事態を進展/混迷させる要素』,『次のセッションへの引き』,『ミッション達成の手段』であったりもする
  • 『報酬』
    『頼みごと』の遂行と引き換えに支払われる(あるいは支払いが約束される)モノもしくはコト
    有形/無形を問わない
    具体的には金銭や価値のあるアイテム,便宜の取り計らいや情報などがあるが、稀に愛情や達成感,感謝など情に訴えかけるようなモノ/コトの場合もある

 これだけです。実に簡単ですね。  ただそれぞれの要素については、まだモデル化の余地がありそうです。次項以降でそれぞれの要素についてもモデル化をしてみましょう。

2-3.『依頼元』をバラバラにしてみる

 『依頼元』をモデル化します。  前項に倣って『依頼元』を文章にしてみましょう。

 『依頼元』は『何らかの事情』により『頼みごと』を『依頼先』に持ちかける。通常、『依頼元』は『頼みごと』の遂行と引き換えに支払う『報酬』の『支払い能力』がある。
 また何らかの『依頼先に関する情報』を持っていることもあるが、その質と量は場合により大きな幅がある。

 この文章から『依頼元』を構成する要素を抜き出して簡単な説明をつけてみます。
 このとき『依頼先』,『頼みごと』,『報酬』は『依頼』をモデル化した時点で別個の要素になっているので外して考えます。

  • 『何らかの事情』
    『依頼元』が『依頼先』に『頼みごと』を持ちかける背景,動機など 具体的には単純に人手が足りない,『依頼元』に能力がない,危険なので自分で実行したくない,『頼みごと』とは別の思惑があるなどがある
  • 『支払い能力』
    『報酬』を支払うための能力
    財力や権力,特定アイテムの所有のほか、『依頼先』との関係に基づくようなものもある(『依頼先』が『依頼元』に対して特別な感情を持っているなど)
  • 『依頼先に関する情報』
    『依頼先』に関する何らかの情報
    身辺情報や人間関係,財政状況など多くの情報をもつケースから、目の前の状況や言動などからの推測のみなど、時々により質と量に大きな差がある

2-4.『依頼先』をバラバラにしてみる

 今度は『依頼先』についてモデル化をしてみます。
 『依頼先』を文章にすると以下のようになるでしょう。

 『依頼先』は『依頼元』から『頼みごと』を引き受ける代わりに『報酬』を受け取る(もしくはその約束をする)。
 このとき『依頼先』は『頼みごと』を遂行するための『遂行能力』と『遂行資源(時間など)』を持つ。

 この文章から『依頼先』を構成する要素を抜き出して簡単な説明をつけてみます。
 このとき『依頼元』,『頼みごと』,『報酬』は『依頼』をモデル化した時点で別個の要素になっているので外して考えます。

  • 遂行能力
    『頼みごと』を遂行するための能力
    TRPGで言うとキャラクターのレベル,能力値,特技などゲーム上のデータで基本的に消耗しないものを指す
  • 遂行資源
    『頼みごと』を遂行するための資源
    TRPGで言うとキャラクターのヒットポイントやマジックポイント,ヒーローポイントなどの消耗のあるデータと、セッション内の時間などを指さす

2-5.『頼みごと』をバラバラにしてみる

 今度は『頼みごと』のモデル化です。  『頼みごと』を文章で表すと次のようになります。

 『頼みごと』は『依頼元』から『依頼先』に持ちかけられる用件である。
 『ミッション』(『達成すべき課題』ないしは『解決すべき問題』)を持ち、その遂行の際には時間制限や禁止事項などの『制約条件』,遂行を妨げる『障害』がある。

 この文章から『頼みごと』を構成する要素を抜き出して簡単な説明をつけてみます。
 このとき『依頼元』,『依頼先』,『報酬』は『依頼』をモデル化した時点で別個の要素になっているので外して考えます。

  • 『ミッション』
    『達成すべき課題』もしくは『解決すべき問題』のいずれか
    稀に二つが同時に『依頼』されることもある
  • 『制約条件』
    時間制限やある種の行動の禁止など『依頼』を遂行する過程で課せられる制限事項
  • 『障害』
    『ミッション』の達成を妨げる様々なもの
    モンスターや罠,法律などなど多岐に渡り、往々にしてリスクに直結する

2-6.『報酬』をバラバラにしてみる

 いよいよ大詰め『報酬』のモデル化です。  『報酬』を文章で表すと次のようになります。

 『頼みごと』の遂行と引き換えに支払われるモノやコト。
 『支払いのタイミング』は前払い,後払い,前後分割など様々なパターンがあり、その内容はふつう『依頼先』にとって何らかの『価値』があるモノやコトである。

 この文章から『報酬』を構成する要素を抜き出してみます。  このとき『頼みごと』,『依頼先』は『依頼』をモデル化した時点で別個の要素になっているので外して考えます。

  • 『支払いのタイミング』
    『報酬』がいつの時点で支払われるか
    前払い,後払い,前後分割,一定期間にわたって分割などがある
  • 『価値』
    『報酬』がどんな価値をもつか
    金銭的価値,特別なサービス,特権,情報などが一般的だが、稀に愛情や達成感,感謝など情に訴えかけるような精神的価値の場合にもある

2-7.『依頼』のプロセスを考察してみる

 ここまで『依頼』を構成する各要素をモデル化してきました。
 これだけでも交渉を考え直すときにヒントになる(なればいいなぁ)のですが──しかしながら個々の要素に着目した分析なので動き方が見え難いですね。
 普通、コンピュータの世界でモデル化をする時にはモデル化の時点で個々の要素の動き方も記述して他の要素との関連を図にするんですが──
 ただ、そこまでやると今度は図の見方まで解説しなければならない上、例え解説しても見慣れないうちは却ってわかりにくくなります。(あー、決してボクの作業が面倒くさくなるからではないですよ。えぇ、ホントですよ──ホントですってばぁ)

 そこで。
 ここまでモデル化した一連の内容を踏まえて『依頼』プロセスを追ってみたいと思います。これで動き方も見えるようになるはずです。

  1. コンタクト
    『依頼元』から『依頼先』にコンタクトが取られる。
    • 『依頼元』はふつう『依頼先に関する情報』をある程度もっている。
    • しかし、ごく稀に“たまたまそこに居合わせた誰かに頼むしかない”等の理由で全く情報を持たないケースもある
  2. 依頼
    『依頼元』から『依頼先』に『頼みごと』を持ちかける。
    • このとき『依頼先』に『頼みごと』と『報酬』が提示される
    • ただしその内容には偽りや隠蔽,歪曲などがある可能性もある
  3. 『頼みごと』の評価
    『依頼先』は『頼みごと』の内容を評価し、自分(たち)に遂行可能か,また『報酬』は適正かを評価する。
    通常、このステップは後述の4.『依頼元』の評価と並行して行われる。
    • 遂行可能かは自分(たち)の『遂行能力』,『遂行資源』と『頼みごと』の比較により評価する
    • 評価の結果、頼みごとの難易度が判定される
    • 『報酬』が適切かどうかは、前のステップで判定された頼みごとの難易度から評価される
  4. 『依頼元』の評価
    前述の2.依頼でも述べたが『依頼元』は『頼みごと』や『報酬』に関する情報を偽ったり隠蔽,歪曲したりしている可能性がある。
    そこで『依頼先』は『依頼元』に関しても信頼に足るかどうか,嘘をついていないか,何か誤魔化していないかなどを評価する。
    通常、このステップは前述の3.『頼みごと』の評価と並行して行われる。
    • 『頼みごと』と『報酬』の内容から信頼性を評価する。
      『頼みごと』に不自然な箇所はないか? 本来想定されるハズの『制約条件』や『障害』で欠けているものはないか? 或いは『報酬』の価値は不当に低かったり不自然なほど高かったりしないか? などが評価基準となる。
    • 『依頼元』に関する情報から、その信頼性を評価する。
      『依頼元』に妙な噂はないか,『依頼元』と『頼みごと』の関連に不自然なところはないか,『依頼元』の挙動に不審な点はないかなどが評価基準となる
  5. 『頼みごと』と『報酬』の調整
    前述の3.『頼みごと』と4.『依頼元』の評価を踏まえ、『依頼先』は『頼みごと』の条件の調整を試みることができる。
    • 『ミッション』のうち『達成すべき課題』のボリュームは調整可能であることが多い
    • このとき『障害』に関して『依頼元』と調整することは難しいハズである
    • 『制約条件』にも調整の余地があるかもしれない
    • 『報酬』は『依頼元』の『支払い能力』に応じて最も調整の余地がありそうな要素である
  6. 『依頼先』の再評価
    普通、前述の5.『頼みごと』の調整と並行して行われる。
    調整として求められた条件に対して応じるかどうか判断するために『依頼先』の信頼性や実力の評価を行う。
    • 『依頼先に関する情報』が評価の重点ポイントである
    • また『依頼先』が目の前で見せている言動も重要なポイントになる
      例えば無闇に『報酬』を吊り上げたり『障害』や『制約条件』に対して過度に難色を示したり、或いは『遂行能力』に疑念を抱かせるような言動があれば著しい減点に繋がる
  7. 条件の合意
    3.『頼みごと』の評価~6.『依頼先』の再評価を経て、『依頼先』と『依頼元』の間に合意が形成されたらプロセスは終了し『依頼』は成立となる。
    ただし逆に合意形成に至らない場合には『依頼』は不成立となる。

 なお『依頼』の度に上のプロセス全てが必ず行われるとは限りません。
 折衝に当たった担当者達の認識不足によりプロセスが飛ばされてしまう可能性もあります。それに『依頼先』と『依頼元』の力関係が圧倒的にどちらかに偏っていて調整の余地が生じない場合もありえます。
 また最も頻繁に見られるだろうケースとしては『時間がそれを許さない』(ゲーム内時間,実時間問わず)という状況でしょう。

 実際、セッションで依頼があるたびにいちいちのプロセスを処理していたら時間が幾らあっても足りなくなります。(マスターは常にプレイヤー達を陥れたくて仕方なく、そして不可解なことにプレイヤー達も危険な冒険に飛び込みたくて常に焦れているのです!)
 もし『依頼』が単にシナリオの導入部に過ぎない,或いはセッションを進めていく上での過程にすぎない場合には省略されるのが普通ですし、そうすべきです。

2-8. この章のまとめ

 この章では、前章とは視点を変えて『依頼』をモデル化しての考察を行いました。
 まず最初は寄り道して「モデルとは何か? どうしてわざわざモデル化するのか?」というお話。
 それから『依頼』のモデル化を行い、その結果を踏まえて『依頼のプロセス』を考察しました。

  1. 『モデル』とは何か?
    • 『具体的なモノやコト』が目的に沿って簡略化された『抽象的なモノやコト』なんだぞ
    • 『人間、簡単なモノやコトの方が分かり易い』のでモデル化は有効なんだぞ
  2. 『依頼』のモデル化
    • 『依頼』は『依頼元』,『依頼先』,『頼みごと』,『報酬』の4つの要素から構成されているぞ
    • 『依頼』を構成するそれぞれの要素は、また別の要素から構成されているぞ
  3. 『依頼』のプロセスに関する考察
    • 『依頼』のプロセスはコンタクト,依頼,『頼みごと』の評価,『依頼元』の評価,『頼みごと』と『報酬』の調整,『依頼先』の再評価,条件の合意からなるんだぞ
    • それぞれの内容は2-7.『依頼』のプロセスをモデル化してみるを参照なんだぞ

最後に

 というわけで、今回の記事はここまで。
 ホントは、この考察を踏まえてシナリオ作成なりセッションへのハンドリングでの実践の仕方まで書きたかったんですが──
 考察部分を書いてるうちに膨れに膨れ上がり、一本の記事としては長すぎて散漫になってしまったので断念。いやぁ、ひとくちに『依頼』と言っても奥が深いものですねぇ。(決して途中で気力と時間が尽きたからではないですよ──いや、それもあるんですが、えと、それだけではないですよってコトで)

 実践篇はリクエストがあれば改めて書いてみたいと思います。
 とゆーわけで、もし読んでみて何か思うところがあったらば宜しく反響下さいませ。
 それではまた来月!


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)