CardWirthPy/CWXEditor/WSN仕様開発の方針

以下に書く事は全て、@k4nagatsukiの私的な方針です。別のコミッタは別の方針を示すかもしれません。ただし、@k4nagatsukiは2017年3月の時点で唯一のコミッタであり、開発を主導しているため、状況が変わらない限り、これがCardWirthPy/CWXEditor/WSN仕様全体の開発方針と受け取ってもおおむね間違いありません。

以下の文章で「私」とあるのは全て@k4nagatsukiの事です。

目次

1. 前提――CardWirthの状況について
2. 保守的な態度と前進の両立
3. 方針を実現するための手続き
   1. 機能が「穏当」の要件を満たすか検討する
   2. 提案の利点と欠点を明示する
   3. 提案から実装までに充分な期間をおく
   4. 結論が出るまで議論する
4. 過去の事例
5. 最後にちょっと重要な事
6. 他記事の参照

前提――CardWirthの状況について

CardWirthPyはCardWirthの実装の1つです。CardWirthは長年存在するプラットフォームで、多くの愛好者がいます。

この前提から、CardWirthは発展途上の存在ではない、と言う事ができます。これまで積み上げてきたものを保守する必要があるのです。

保守の対象には、システムだけでなく、ユーザが作ってきたたくさんのシナリオや素材も含まれます。それらはCardWirthの財産であって、切り捨てたり危機に陥らせたりする事は避ける必要があります。仕様変更で一部のシナリオがプレイ不能になるとか、これまでのカードイメージが使えなくなるとかいった事態を起こしてはいけないのです。

しかし、それは、CardWirthはこれまでの枠に留まるべきで、前進するべきではない、という事を必ずしも意味しません。シナリオ作家はCardWirthに変数の演算機能が無い事で余計な苦労を背負い込んでいるかもしれません。カードイメージの作者は絵を74×94に縮小するとディテールが潰れてしまう事で悩んでいるかもしれません。CardWirthには、なお付け加えるべき要素や解消すべき問題があります。それらを解決していく事は必要です。

保守と改革は表面上対立しているように見えるくらいのものですから、両立させるのはなかなか難しい事です。しかし両立させる必要がありますし、それは不可能ではありません。いくつか方法が考えられますが、私は以下のような方法を採っています。

保守的な態度と前進の両立

その方法は一言で言えば「穏当な前進」です。付け加えられる新機能は、CardWirth全体から見て「穏当」なものでなければなりません。

それについて語る前に、前提として、CardWirthPy・CWXEditorといったアプリケーションと、WSN仕様を厳密に区別しておかなければなりません。

1. CardWirthPyとCWXEditorは、CardWirth/WSN仕様の1つの実装に過ぎません。代替の実装があれば、ユーザはCardWirthPy・CWXEditorを捨ててそちらへ乗り換える事ができます。
2. WSN仕様は、シナリオのデータ形式です。従って、いくつものシナリオがこの形式で記述される事になります。この形式を取り扱えるエンジンやエディタも複数現れるかもしれません。また、すでにこの形式で作られたシナリオを他の形式へ変換するのは簡単ではないかもしれません。

以上のように、CardWirthPy・CWXEditorよりもWSN仕様の方が上流にあるため、CardWirthPy・CWXEditorの改造よりもWSN仕様の変更の方が重大な結果をもたらす可能性が大きく、より慎重になる必要がある、という事を覚えておいてください。

「穏当」な新機能とは、たとえば以下のようなものです。以下のような要件を満たす機能なら、保守の役割を損なう事無く付け加える事ができるはずです。

1. ユーザから顕在的・潜在的に広く求められており、反対意見も見られないもの。
2. CardWirth全体の設計に馴染む・調和しているもの。
3. CardWirthが持つ既存の要素を損なわないもの。

しかし、追加を検討している機能が本当にこれらの条件を満たすかどうかは簡単に判断できる事ではありません。

例えばCardWirthEditorにはアンドゥ(元に戻す)機能がありません。ユーザがその機能を欲していた事は明らかで、「イベントアイコンの上でDeleteキーを押してしまった」という嘆きや、アンドゥ機能を持つ他の大量のアプリケーションの存在がそれを裏付けています。ですから、アンドゥ機能は広く求められているといえます。反対意見は見当たらず、それによってCardWirthのゲーム性が変わってしまうというような事もありません。ですから、CWXEditorにアンドゥ機能を加えるのはよい事のように思えます。

ここに1つ、論理の飛躍があります。「反対意見は見当たらない。だから無い」という判断には問題があります。現在その機能が存在せず、実装される見込みも無いから意見を言う必要が無かった、という事があるかもしれません。いざ実装すると、「アンドゥなんてものがあったら正確に操作する心懸けが薄れる」と言う人が現れるかもしれません。

そして、その反対意見にほとんどのCardWirthユーザが同調するかもしれません。あるいはアンドゥ機能がある事で、何か致命的な問題が起きる事が判明するかもしれません(「実際の」アンドゥ機能は幸いそういう問題に遭っていません。これはあくまで例としての話です)。結局、アンドゥ機能は「穏当」の要件を満たしていなかったと判明したとしましょう。そうなったらどうするべきでしょうか。

アンドゥは、CWXEditorというアプリケーション固有の機能です。「では、CWXEditorからこの機能を削除しましょう」という事で、CardWirthPyのようなエンジンやWSN仕様などへ影響を広げずに問題を解決する事ができない事もありません。

では、これがエンジンやエディタ固有の機能ではなく、WSN仕様の新機能の話だったらどうでしょうか。すでにその機能を実装したエンジンやエディタがある、その機能を使ったシナリオまで存在している――という状況になったら、どうやって問題を解決できるのでしょう。事によっては大きな犠牲を払わなければ解決不能ではないでしょうか。

そういう事態は避けなければなりません。ですから、避けるための手続きが必要となります。

方針を実現するための手続き

問題を事前に避けるため、私が採用している手続きは、以下のようなものです。

1. 提案前に、機能が「穏当」の要件を満たすか自分で検討する。
2. 提案の中に、その提案がもたらす利点、考えうる欠点を明示する。
3. 提案から実装までに充分な期間をおき、問題の指摘や反対意見を待つ。
4. 問題の解決方法や反対意見について、結論が出るまで議論する。

この手続きは、WSN仕様の機能を検討する時に最も重視しています。エンジンやエディタ固有の些細な機能であれば、他へ影響を広げずに元に戻す事も容易なので、効率優先で手続きをいくらか省略してしまう事もあります(本当はあまりよくないのですが)。

以下に項目ごとの詳細を書きます。

1. 「穏当」の要件を満たすか検討する

これについて追加で説明する事は無いと思います。上述の内容を参照してください。

2. 提案の利点と欠点を明示する

利点については言うまでもありません。それが無ければ提案の意味がありません。

欠点についてですが、これは以下のような事を指します。

1. 解決する方法がありそうな欠陥。
2. その機能の追加によってCardWirthの既存の要素を「わずかに」損なうような事柄。

1.は自分で解決できなかったが他の人なら解決方法を見出せるかもしれない問題や、将来解決できる見込みがある、といった事柄です。見込みがあるのであれば、実現がいつになるかはさておき提案を出しておくのは悪い事ではありません。

2.は、もっと微妙な話になります。提案された機能に多大なメリットがあれば、CardWirthの大勢のユーザも、既存の要素が若干犠牲になる事には目を瞑ってくれるかもしれません。

例えばメッセージのフォントを変更するというエンジンの機能を考えてみます。この機能は既存のシナリオに犠牲を強いる事があります！ 一部のシナリオは、CardWirthの伝統的なフォントに合わせて作った特殊文字をメッセージ内で使ったり、メッセージによく似た背景セルを出してプレイヤーを驚かせたりしているからです。フォントが変更されてしまうと、そうした演出が台無しになってしまうかもしれません。

それにもかかわらず、メッセージのフォント変更機能はユーザの圧倒的な支持を得ているようです。これは、デメリットを、「よりきれいな自分好みのフォントでメッセージを読める」などのメリットが遥かに上回っているためと思われます。

ですから、CardWirthの持つ要素を「わずかでも」損なうべきではないとは、私は思いません。ただし犠牲が「わずか」で済まない提案はなされるべきではないか、されたとしても相応の試練を乗り越えなければなりません。

この「わずか」の判定に、私は以下のような要件を用いています。

1. その要素を必要としているユーザがいないように見える。
2. 既存のシナリオに致命的な影響(例えば進行不能)を与えたりしない。

ところが、1.についても2.についても見落としの可能性があります。そこで、次以降の手続きが必要になります。

3. 提案から実装までに充分な期間をおく

時間をおくのは、問題の指摘や反対意見を待つためです。特に、反対者が意見を言う機会を確保するためです。提案の段階で反対されるのは、実装してしまってから反対されるよりもずっと望ましい事です。

反対意見の存在は重要です。新機能の提案のような事柄への反対は、保守の立場からなされるものだからです。

意見募集の期間をどれくらい取るかには、確乎とした基準がありません。私は、WSN仕様の場合は「短くても一週間」程度にしています。実際にはそれより長くなる事が多いです。

アプリケーション固有の機能の場合は、後から反対されて、反対意見が妥当だと分かっても、私の作業が無駄になるだけなので、待たない事があります。

4. 結論が出るまで議論する

反対者の意見は自分の提案と同等以上の重みを持って扱うべきです。「なるほど、あなたの意見は分かった。でも私がやりたいようにやる」では、相手の意見は存在しないのと同じで、手続きの意味が無くなり、従って後から問題が噴出する事態を回避する事ができません。そうではなく、「なるほど、あなたの意見は分かった。でもその反対理由はこうすれば解消できる」とか「ではその反対理由を解消できないか考えてみよう」とか「いや、その反対理由は間違っている。根拠はこれだ」とかいった応答をするべきなのです。

誰でも自分の提案に愛着を持っているので、反対者の意見よりも自分の意見の方を重く扱ってしまいがちです。しかしこれは大変な誤謬です。CardWirthは自分独りのものではない事を理解しておかなくてはなりません。CardWirthはすでに、そこに自らの資源を投入してシナリオや素材を作った人々や、プレイヤーの一人一人、みんなのものとなっています。もはや誰も所有する事はできません。

意見を公平に扱うコツとして、「今回の提案は自分ではなく他の誰かによってなされたものだ」と思い込んでしまうのもよいでしょう。実際にそうするのは無理でしょうが、そうしようとする内心の努力は状況を多少よくするかもしれません。また、そうする事で、反対意見を怖れなくても済むかもしれません。反対意見を怖れるのは当然の心理的な動きですが、正しい結論へ向かおうとしている時には害があります。

さて、きちんと意見を聴くとなると、その人がなぜ反対しているのか検討しなくてはなりません。それは明確に書かれておらず、話し合いを通じて引き出していく必要があるかもしれません。反対理由が分かったら、今度はその理由を解消しなくてはなりません。

その話し合いは苦しいものになるかもしれませんが、労を惜しむべきではありません。惜しめばやはり手続きの意味が無くなり、問題は振り出しに戻ります。

話し合い、議論を進める中で、反対理由がどうしても解消できない――実は提案にさほどメリットが無かったり、デメリットが上回っていたり、あるいは致命的な欠陥がある――事が分かるかもしれません。問題を解決できないのであれば、それは実装されるべきではないか、今はまだその時期が来ていない、という事だったのでしょう。自分の主張に無理が出てきたと感じたら、時間をおき、議論全体を念入りに読み返してよく考えるとよいでしょう。「この提案はだめだ」という結論が避けられそうになかったら、すっぱり諦める事が必要です。もちろん、この諦めのよさは反対者の方にも必要となります。どう考えても反対理由が妥当でないと分かったら引き下がるべきです。無理のある自説に固執するのはかかわる全員にとっての不利益です。

議論の途中で、元々の提案で解決しようとしていた課題を解決する、もっといい案が生まれるかもしれません。そうなれば幸運です。時間はかかるかもしれませんが、その新しい案に対して改めて続きを適用し、実現を目指しましょう。

また、相手が議論に疲れて放棄してしまう事があるかもしれません。これは最も難しい事態で、結論を出せなくなってしまうおそれがあります。放棄しないよう働きかける努力が必要です。それも成果が無かった場合、提案は塩漬けにしてしまうか、あるいは議論の全体を見返して、実は途中で結論が見えていなかったか検討するしかないように思います。

議論の末、提案が通れば、それでやっと実装へと進んでいく事になります。もちろん、実装中や、実装してから正式リリースまでのあいだに新しい意見が来たら、それにも対応しなければなりません。

過去の事例

以上が、これまでのCardWirthPy/CWXEditor/WSN仕様の開発で私がふんできた、あるいはふもうとしてきた手続きです。実際には賛成意見ばかりとか意見無しという形で議論が起こらない事もあるので、スムースに進む事も多いです。いつも時間がかかるわけではありません。

私自身は議論を好んでおらず、もっとはっきり言えばあんな時間も精神も消耗するものは嫌いなので、スムースに行くのは好ましい事です。だから自分で提案を出す時は、なるべく事前に問題を取り除く努力をする事にしています。それはうまくいく事もあればいかない事もあります。

例えば以下は順調に進んだ例です。

• issue #326 効果の精神力回復・喪失で回復・喪失する量を指定出来るように
• issue #444 クーポン所持判定の多岐分岐
• issue #448 クーポン分岐で複数の称号を指定する
• issue #449 ランダム多岐分岐

ひどくこじれた例もあります。

• issue #294 メンバ選択分岐に評価メンバ式を追加
• issue #433→#436 キーコード所持判定分岐の範囲の柔軟化・手札の追加

以下は私の当初の意見や案が通らなかった例です。このような手続きの下では、開発の主権者であっても意見の重みは1人分しか持ちません。CardWirthがみんなのものであるからには、それは望ましい事です。

• issue #83 デバッガを利用するとＥＰが無限入手可能
• issue #257 カードの種類を判別するための追加表示
• issue #405 使用時イベントにおける死亡条件発火の問題への対応

開発に参加する方は、こうした事例を参考に、CardWirthという保守的にならざるをえないプラットフォームに対して、どういう風に新しいものを付け加えていくか、考えていただければと思います。

最後にちょっと重要な事

私はCWXEditorの開発を始めた頃、CardWirth 1.28と付属のCardWirthEditorのヘビーユーザでした。自分でシナリオを作っていましたし遊んでいました。CardWirthPyやCWXEditorが便利なものになっているとしたら、それには私自身がCardWirthの内容を熟知し、私自身の要求を満たすために改良してきた事が大きく寄与しているはずです。

これは開発者として重要な事です。開発者が自分で使い倒すシステムと少ししか使わないシステム、あるいは全く使わないシステムとでは、その出来に雲泥の差がある傾向にあります。数学的な証明があるわけではありませんが、プログラマにとってこれは常識で、「自分でドッグフードを食う」という格言があるくらいです。

機能の提案や、それに伴う議論についても同じ事が言えます。CardWirthを遊び倒した経験が無ければ、本当に求められているものがなんなのかは分かりづらいと思われます。

まずは遊びましょう。そしてシナリオを作りましょう。

他記事の参照

議論や「反対意見」の取り扱いについては、CardWirthPyの名前の変更についてのIssueに書いたコメントも参照してください。

開発において私が唯一のコミッタである、という状況の問題点についてのissue #96があります。2017年3月現在もあまり状況は変わっていませんが、少しずつ前進しているとは感じています。