何年も前から痛感していることを、何とか頑張って言語化してみようとおもいます。最後の方は将棋も関係しますが、最初は将棋と無関係です。
XMDF という電子書籍形式をご存知でしょうか。
SHARP が開発した電子書籍形式でして、XMDF 形式の電子書籍を作るには SHARP 製の tools を購入する必要がありました (どうやら78000円もしたようです)。
日本国内で電子書籍を普及させようとして頑張っていたようですが、世界では既に EPUB が標準の地位を獲得していった頃でした。EPUB は open な規格で、EPUB 文書作成も無料の tools でできる状態でした。
あなたが当時の電子出版事業者だとして、どちらを選びますか? 日本国内でしか使われていない (しかも日本国内ですら普及率がとても低い)、tool が78000円もする、しかも文書を変換したらもう手を入れられない XMDF 形式を選びますか? それとも、世界標準として採用されつつあり、tools も無料で、しかも文書変換後も手を入れられる EPUB 形式を選びますか? (EPUB 形式は、XHTML を ZIP 圧縮しただけのものなので、変換後に手を入れるのも簡単です。)
こんな状況で XMDF が EPUB に勝てるはずがありません。当時から私は「どうして日本人はこういうロクでもない仕組みを作って力を入れるのだろうか」と感じていました。
XMDF の仕様が最初から公開されていて (open で)、tools も有料じゃなくて無料であれば、EPUB に勝てた世界線もあったんじゃないかと思います。大事なことは仕様が open かどうかなのです。
分散 source 管理 system として最も有名な tool は git です。そして最も有名な hosting service は GitHub です。
git は無料ですから、GitHub のような hosting は誰でも可能です。あなたの勤務先が「自社で git server を立てたい」と思ったら、server machine を用意するだけで (物理 server でなくても VPS でも cloud でもよい) git server は無料で立てられます。
にも拘わらず GitHub が企業として成り立つ理由は、hosting とその support に価値があるからに他なりません。GitHub の価格表に書かれている有料 plans を選ぶ企業があるということです。
大切なことは、git 自体は open であるということです。git 自体に対する変更提案の方法はここに書かれています。提案した内容が受け入れられれば後日の git に取り込まれます。
もし git が open じゃなかったらどうなると思いますか? いわゆる vendor lock-in が発生します。そして、将来の vendor lock-in を考えて、人々はそういうものに寄り付かなくなります。XMDF が普及に大失敗した大きな理由の1つがこれでしょう。
vendor lock-in となる危険性を考慮しても普及するものはあります。例えば Google Classroom は、LMS としてみればその機能は本当に貧弱でものすごく使いにくいのですが、Google が hosting している (Google が可用性を担保している) というただその1点だけで普及しています。自社で server 保守者を調達しなくてもいい (自社の従業員に保守業務を割り振らなくていい) のです。
本当に普及させたいものは、source 自体は open にして hosting (や support) を有料にする model がよいです。
source を open にしなくても (vendor lock-in の危険性があっても) 普及させることができる services を提供できる企業は、Google, Microsoft, Apple ぐらいだと思います。
数年前、大会運営 system として Challonge を試してみましたが、使い物になりませんでした。手合いの組み合わせに手を入れられないから、通常の例会に指導対局がからむような手合いが組めないのです。せめて Challonge の source が open だったら、それを入手して改変して自分で host を立ち上げ、便利だったら Challonge 本家に還元する、なんてことができたのですが、closed source ですからそういうことも不可能でした。
これは愚痴っぽくなってしまいますが、こういう大会運営 system って、参加申し込み・当日 check-in・対局組み合わせ・対局発表・結果入力・結果表示、という modules でできているべきなんです。そのうちどの部分を hosting してほしいのか、どの部分は大会運営者側で制御したいのか、ってのを選べなければいけません。
そういうことを区分せず全部一緒くたにして、しかも closed source で SaaS を立てても、たまたまその使い方にあっている場合しか使い物になりません。
例会だと、元奨励会の方に参加していただける場合は多面指しで級位者の相手をしてもらったりします。(私の支部の) 例会は、一番棋力が高い人を選び出す場ではなく、自分の棋力に応じた成果を出したかどうかが評価される場ですから、この多面指しも例会閉会時の表彰の際に評価に含まれるわけです。
大会だと、事前申し込みさえされていれば本人が会場に来ていなくても (check-in できていなくても) 自動的に第1局の時計が進められます。大会の組み合わせ構造は前日までにくみ上げてしまうものですから (実際の組み合わせは当日決めることもあります)、当日 check-in しなくても座席は用意されるわけです。
更には、Challonge の内部で本当に厳正な抽選がされているのかどうかを参加者が知る術がないことも問題です。source が open であり、その source を元に自分で system を構築した場合と比較して Challonge の挙動がおかしくない、ということくらいは最低限確認できないといけません。
より理想的には、hash 関数を利用して、その大会の入力情報を全て揃えたら何度試行しても対局組み合わせが必ず再現される、くらいの検証ができることが望ましいです。
乱数と再現性って相容れないように思われるかも知れませんが、hash 関数の一方向性がその部分を担保している、というのが私の考えです。
将棋大会で必要な乱数って、真の乱数でなくても、「統計的に偏りがない」「運営者であっても予測・制御不可能」の2つの性質を満たせばよいと考えています。その上で再現性があれば、その乱数を用いても問題がないことを参加者が検証できます。
ここのところが、Challonge はできていません。
開発と hosting が分離していれば、これらの問題は解決できます。
開発ってのは、常時張り付く必要はなく自分の空き時間に自由に進めることができます (OSS でなければ納期などあるでしょうが、OSS ではそういうことを気にする必要がありません)。
一方、hosting は可用性の保証がそれなりの負担になります。
私の感覚ですが、可用性には対価を支払う価値があるものの、(囲い込みをしている) 開発に対しては対価を払う価値を殆ど感じません。これは「0円で開発しろ」という意味ではなく、「囲い込まれているものに対してお金を払うことはとても危険」という意味です。
例えば、大会・例会の参加申し込みとか、次の対局相手の表示とか、そういう部分にはお金を払う価値を感じます。しかし、Challonge のように system 側で対局相手を勝手に決めてしまい、そこに手を入れることが一切できずに現場の運用で何とかするしかない仕組みだと、将棋ではとても使いにくく感じます。
機械にしてほしいことは、「この組み合わせでどうですか」と提案してもらうことであり、人間の手を一切入れられずに勝手に組み合わせを決める仕組みは不便です。とりわけ、「どうしてその組み合わせになったのか」という証明が一切出てこない system は、大会運用では採用しにくいと思います。
ここまで書くことに2時間近くかかったのに、私が言いたいことの言語化に成功した気がしないのですが、これ以上時間をかけられないので今回はここでやめておきます。
まとまっていない文章を読ませてしまい、すみません。
