問題解決はできなくても一緒に悩むことはできます

それが私のスタンスです。

[TRPG] 依頼型導入とその後の進め方について: Dragonoid Factory
http://dragonoid.txt-nifty.com/df/2009/11/trpg-0ee1.html

きっと「こういうときにはこういう風にPCたちを誘導して・・・」とか「情報の出し方を工夫すれば・・・」とかあるんだろうなぁと思うし、たくさんシナリオを作って実際にセッションをやって時には失敗したりしてノウハウを蓄積していくんだろうなぁとは思うのですが。というより、そこがシナリオ作りとかセッションハンドリングの見せ所なのかなぁ。

いきなりノウハウの話。
誘導とかは私はあんまり考えてなくて、というのは、「状況のセッティングさえできれば、PCの行動は自ずと決まる」と考えているからなわけです。それが誘導だろと言われればそうかもしれませんが、誘導を意識すると、誘導が失敗した時のリカバリが大変なので、とりあえず状況は作るけど好きにしていいよ、というスタンスでいます。
では状況のセッティングはどうするのか。どうやってセッティングするのか。これもまた簡単な話で、「相手がなにが納得できていないのかを確認する」だけです。これは、直接的に(その場で)回答まで出す、ということではないです。なにしろ、伏線に食いついてくれてるだけかもしれないので。
そうなると回答のパターンは決まってて、「問題なければ(メタでもいいから)回答を出しちゃう」「問題があるので回答は後で出ますとだけ答える(回答の存在だけを伝える)」「考えてなかったので気にしないでほしいとぶっちゃける」ぐらいです。
これは、GMの状況だけで判断できるので、GMとしてはやりやすいです。もちろん割り切りがある程度必要だし、回答と違うことをやったら信用なくして終わりですが。


「相手が納得できていない点を聞き出す」=「疑問を聞き出す」なわけですが、これはテクニックというか慣れというか観察しかないと思ってます。
指標として、「発言が少ない」「発言が短い」というのは、疑問を持っている時になりやすい状態ですが、単純に寡黙なだけかもしれないので、その点は念頭に置いて問いかけする必要があります。問いかけに対して「別に」とか返すような人は、寡黙だろうとなんだろうと空気読めないっていうか相手の意図を考えない人なので放置してもいいと思いますが。そもそも無礼です。
オフラインで対面している場合は「早口になる」「声のトーンが上がる」とかも指標になりますが、この辺はオンラインだと確認しようがないのが弱いところです。オンラインの場合は「発言までに時間がかかっているけど実際の発言が短い」とかは悩んでるということの指標なので、突っ込み時ですね。
拙作のチャットソフトでは、発言中表示機能があるので、悩んでるのか、画面見逃してて反応してないのかの違いもわかるので、こういう機能は便利じゃないかなと思ってます。
まあこれはTRPGに限った話でもなく。日常的な話だと思います。


で、(たぶん)本題。

”こういう導入でPCたちに原因を探ってもらう”というシナリオも考えられるわけで、「ではどうしたもんかなぁ」と。

これは、セッションの運用レベルの話、だと思います。
つまり、「今日は戦闘だけやるよ!」とか言いつつ、原因探索ばっかりやらされたらそんなのはイヤンですよね。言葉遣いの問題でもありますが。「今日は戦闘もやるよ!」という言い方でも、戦闘メインなんだろうなー、という期待をするだろうことは言うまでもないことなので。まあ文脈依存なのでこれ自体はそれほど重要な話でもなく。


シナリオの記述時点において、なにが焦点になるかというのははっきりしていると思います。しかし、すでにずいぶんと昔の話のような気もしますが、デモンパラサイトのシナリオ「力の代償」でも、原因の探索と(解決手段としての)戦闘がありますが、GMの好みに応じて、どちらに比重を置くかは使い分けられます。
探索重視でやるなら、「探索重視でやるよ!」と言って、探索パートの描写に重きを置きつつ、できるだけPLの自主性に任せて探索をさせればいい。GMからの誘導なんてのは必要最低限にして、状況証拠だけ出しておけばいい。PLが詰まったら(PLが助けを求めたら)助け舟を出す。シーン中に出すかメタで出すかは好みと状況に応じて。探索重視なのにギブアップもなしにGMが助けてくれると思ってんなら、それはPLが甘えてんです。放置してもよろしい。もちろん、事前に「探索重視だから、こういう風にやるよ!」と宣言して上記の方針を説明するのがマナーかもしれません。
戦闘重視でやるなら、「戦闘重視でやるよ!」と言って、探索パートはさらっと流して、次に行く場所とかも全部メタで指示しちゃうぐらいにして、とにかく戦闘に至る過程だけを淡々と描写すればいい。味気ないぐらいにして、というか全部説明しちゃって、実際始まるのは戦闘シーンからぐらいにはしょってもかまわない。


それがシナリオを運用する、マスタリングする、セッションをする、ということだと思います。つまり、「シナリオ作者の意図」と「シナリオ運用者の意図」は別でも当たり前だと。シナリオ作者は、どういう意図でシナリオを作ったかを記述して説明できたとしても、その通りに運用するかどうかは、シナリオ運用者の手に委ねられている。改変してもしなくても、それは運用者の選択でしかないから。
シナリオの改変もせずにシナリオ通りにやったのに失敗しましたなんてのは、基本的には戯言です。でも三回までは許します。三回も失敗して学習しない人にはつける薬がありませんが、三回ぐらい失敗しないとセッションの運用というのがいかに水物なのかはわからないと思うので。
わかってて失敗しちゃう分には、別にいいと思います。わかってるならシナリオの事前読み込みと問題の予測、それに応じた改変は思いつくでしょうし、それは事後にでも気づけることですので、反省材料を自分で見つけられるでしょうから。どうにも修正がうまくいかないのは単純に経験の問題です。そのうちできるようになるかもしれないし、誰かに師事してみるのもいいかもしれません。
「このシナリオはクソだったから別のシナリオで」と言ってる人は、残念ながらうまくはなれないと思います。シナリオがクソだったのか自分の運用がクソだったのか、少なくとも自分の運用がクソだったという前提で振り返りをしない限り、自分の技術は改善できませんので。
悪かったのは全部他人のせい、なんて言ってる人はうまくはならないと。まあそんだけのことです。わかってても実践するのは難しいんですけども。