何年も前から痛感していることを、何とか頑張って言語化してみようとおもいます。最後の方は将棋も関係しますが、最初は将棋と無関係です。
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時間近くかかったのに、私が言いたいことの言語化に成功した気がしないのですが、これ以上時間をかけられないので今回はここでやめておきます。
まとまっていない文章を読ませてしまい、すみません。
全日本学生将棋連盟の web site の大会記録が2022年度で止まっています。
営利団体じゃないでしょうから、私も非難したいわけではありません。
「多分、手作業で更新しているのだろうなあ」という感想を持ちました。
実は、こういう部分こそ自動化しなければいけない部分です。もし「手作業のままでいい」と思っている人がいたら、その本質的な違いが分かっていないのだと思います。
今、大学4年生は卒論で忙しく、大学3年生は就活で忙しいでしょうから、こういう団体の執行部は大学1～2年生が中心でしょう。ということは、2024年4月か2025年4月に入学してきた学生だということです。
web site は2022年度の情報で止まっていますから、少なくとも2023年度分、もしかしたらさらに過去の分の情報を掲載しないといけません。つまり、自分が入学してくる前の情報を掲載しないといけないのです。
自分の大学の情報だけではありません。全国の様々な大学の、しかもすでに卒業したかもしれない人の情報を集め、その正確さに責任をもって掲載しないといけないのです。
こういう作業は、大会中に (あるいは大会前から) 何らかの方法で情報を自動的に集め、それが自動的に公開 format になって出力される、という仕組みで運用することが望ましいです。
まあ、YAML 書式に frontmatter をつけて Jekyll あたりを通して公開するくらいの仕組みなら github.io ですぐに運用できそうな気がします。もうちょっと丁寧に作るなら database を用意する形になるかと思います。
学生が学業に注力しながら片手間で学生団体を運営するのは、結構大変そうですね。何とか早めに情報が公開されることを願っています。
表題の件、以下に引用します。
今回の件は、運営側の確認不足により発生したものであり、皆様にご迷惑をおかけしましたことを重ねて深くお詫び申し上げます。
今回の問題の本質が「確認不足」かどうかはよくわかりませんが、一般に、準備時間が短くなると「確認不足」は発生しやすいです。
この件を扱っている Yahoo! 記事で、松本博文氏が以下の通り述べています。
筆者は以前、順位戦の組み合わせ抽選を取材したことがあります。棋士、日本将棋連盟の職員、主催紙の担当者による厳正な抽選を経て、厳重なチェックが終わる頃には深夜になっていました。
プロでもアマでも、極力誤りがないように手合いを組むには、充分な時間が必要です。これが県代表を選ぶなど重要な大会になればなおさらです。
例えば、午前に4人1組の対局で2勝勝ち抜けとし、勝ち抜け者で昼に抽選する、というような方式だと確率的に問題が多いことはちゃんと説明できますか?
今までに何度も主張してきましたが、事前申込制の大会に当日飛び込み参加しようとする行為は、本来数十時間かけて検証すべき対局組み合わせを数分間で作らせるような、大変悪い行為です。
大会にもよると思いますが、例えば私の支部が主管する大会では事前申込した状況で無断欠席しても殆ど影響がありません。正直に言うと、「事前申込していたけど当日は大会があることを忘れていました」というようなことになっても運営側としてはほぼ問題ありません。万一そういう方が多数出てきたらちょっと困りますが、それでも当日飛び込み参加しようとする人の迷惑さと比べれば、本当に大したことはありません。
飛び込み参加者がいると、運営側の負担が激増し、長期的には大会運営員のなり手が減ることに (そして支部役員が減ることに) なります。その県の将棋文化を潰すことに繋がります。
事前申込制の大会に参加するなら、必ず事前に申し込んで下さい。
いつもこの blog をお読みくださりありがとうございます。
時々 follow 申請があるのですが、全ての申請を承認しているわけではなく、およそ以下のいずれかに該当する場合のみ承認しております。
- 将棋を中心とする blog である
- 将棋の話題がちょくちょく出てくる blog であり、その記事数が少なくない
- 「子育て」経験だったり同世代だったり、私が共感しやすい
- 思考方法や思想 (政治など) で私が共感する点が多い
なお、この blog では基本的に政治の話題を取り上げません (赤旗名人戦や自由民主党総裁杯は例外です)。また、将棋を中心とする blog であれば、私と立場が異なっていても積極的に承認しております。
逆に、小遣い稼ぎの話題が中心の blog、spiritual な話題が中心の blog は基本的に承認しておりません。
こんな blog ですが、気が向く範囲で読んでいただけると幸いです。
今年もよろしくお願いします。
棋戦や大会を「マルコフ性」という観点で整理したいと思います。
「マルコフ性」(Марковское свойство) とは、確率が過去履歴から独立していることを意味します。
この概念を棋戦や大会に持ち込んで、「マルコフ性がある」(memoryless)、「マルコフ性がない」(memoryful)、の2通りに区分しようと思います。
「マルコフ性がある」棋戦・大会とは、全ての参加者の対局勝利確率が 0.5 と仮定した場合に、籤引き前の優勝確率が過去の履歴から独立している (どの参加者も優勝確率が等しい) 棋戦・大会を指すこととします。分かりにくいので、以下「memoryless」と呼ぶことにします。
「マルコフ性がない」棋戦・大会とは、全ての参加者の対局勝利確率が 0.5 と仮定した場合に、籤引き前の優勝確率が過去の履歴に影響されている棋戦・大会を指すこととします。8大棋戦は全て挑戦手合いですから「マルコフ性がない」棋戦です。分かりにくいので、以下「memoryful」と呼ぶことにします。
(memoryless ≒ stateless、 memoryful ≒ stateful、 と読み替えてもおおよそ理解できるものと思います。)
ただ、2区分だけでは不便でして、当該棋戦 (及びその系列棋戦) の過去履歴についての memoryless/memoryful と、他棋戦の過去履歴についての memoryless/memoryful をそれぞれ区別しようと思います。
以下、調査結果です。棋戦名は通称です。(手抜きですが、Wikipedia から情報を引っ張ってきています。)
| 棋戦名 | 当該棋戦 | 他棋戦 | アマチュア枠 |
| 竜王戦 | memoryful | memoryless | memoryful (系列のアマ竜王戦では前回優勝者が優遇される) |
| 名人戦・順位戦 | memoryful | memoryless | なし |
| 叡王戦 | memoryful | memoryful (段位が上がるほど予選突破に有利) | なし |
| 王位戦 | memoryful | memoryless | なし |
| 王座戦 | memoryful | memoryful (順位戦上位者ほど予選突破に有利) | なし |
| 棋聖戦 | memoryful | memoryful (順位戦上位者ほど予選突破に有利) | なし |
| 棋王戦 | memoryful | memoryful (順位戦上位者ほど予選突破に有利) | memoryful (系列のアマ名人戦では前回優勝者が優遇される) |
| 王将戦 | memoryful | memoryful (順位戦上位者ほど予選突破に有利) | なし |
| 朝日杯 | memoryful | memoryful (他棋戦の過去履歴に影響される) | memoryful (系列の朝日アマ名人戦で前回優勝者優遇あり、学生名人戦は不明) |
| 銀河戦 | memoryful | memoryful (順位戦上位者ほど予選突破に有利) | memoryful (系列のアマ王将戦で招待選手制度あり) |
| NHK 杯 | memoryful | memoryful (他棋戦の過去履歴に影響される) | なし |
| 日本シリーズ | memoryful | memoryful (出場資格自体が他棋戦の過去履歴に影響される) | なし |
| 達人戦 | memoryful | memoryful (他棋戦の過去履歴に影響される) | なし |
| 新人王戦 | memoryful | memoryful (奨励会上位者ほど参加資格を得やすい) | memoryless (系列の赤旗名人戦を一から勝ち上がる以外に経路がない) |
| 加古川青流戦 | memoryless (前の期で優勝しても優遇されない) | memoryless | memoryful (系列のアマ青流戦は参加資格が他棋戦の過去履歴に左右される) |
こうしてみると、殆どの棋戦が memoryful ですね。
このところ、支部活動の負担について色々考えていました。多分、「後継者が出てくるような仕組みになっているかどうか」が大切なのではないか、という気がしています。
すごく大雑把な判定法を提案します。
現時点で65歳以上の方が全て抜けた場合、あなたの支部は存続できますか? (支部会員から抜けるだけでなく、それらの方が所有・賃借している不動産や盤・駒なども全て引き上げられるものとします。賃借については、65歳未満の会員だけで賃借料が払えるなら継続賃借可能とします。)
支部会員数だけではありません。大会などの運営員をやってくれる方が必要人数揃いますか? 全体を指揮できる人はいますか?
以上の判定法に従って「はい」という結論が出せるなら、とりあえず10年～15年後も支部は存続できると思います。「いいえ」という結論なら、10年～15年後の支部存続は厳しいと思います。
私の支部は全会員が65歳未満なのでとりあえず「はい」と言えます。
ただ、支部役員は全員が fulltime 勤労者なので、大会・例会運営の負担が増えると役員を続けられなくなる人が出てくる可能性もあります。
負担が過剰にならない範囲で支部を存続させる方法を考えています。
将棋とは関係ない呟きです。
年末年始休みに入ったのに、やることが多くていきなり徹夜をしてしまいました。現在午前6時48分。
- 2カ月くらい前に新しい laptop PC を買ったので、環境構築をしなければならない状況でした。
- 丁度、2025年12月25日に Ruby 4.0 が公開されたので、それも入れたいと考えていました。今までも Ruby は PC へ複数の版を入れていたので、同様に新 PC でも複数の版を入れたいところです。
- ところが、Windows の package manager (の1つ) である Scoop では、Ruby の manifest が環境変数まで設定してしまう方式になっているので、一筋縄ではいきません。(Ruby の版を導入する順序によって、呼び出される版が変わってしまいます。どんな順序で導入しても私が呼び出したい版を正確に呼び出せる仕組みが望ましいです。)
- そこで、元の manifest を参考に、環境変数を汚さない manifests (Ruby 2.0 ～ Ruby 4.0) を自分で書くことにしました。
- そのついでに、RubyGems の cache は共用にして disk space をある程度節約する形にしようと、NTFS の junction 機能を利用することにしました。
- 元の manifest を見ると…何と、ARM architecture の項目がないじゃないですか。仕方ないので、pull request を書きました。
- 古い Ruby の manifests を見ると、 Ruby 3.x 系列にも不足があります。こちらも pull request を書きました。
- 以上のことを終えたらすでに朝の光が部屋に差し込む時間帯でした。
年末年始休みのうちにやってしまいたいことはまだまだ大量にあります。
- Ruby 4.0 の新機能のうち影響が大きいものについて学びたい
- RBS 関係、特に rbs-inline について学びたい
- bundle gem したものをすぐ RuboCop にかけたら大量に警告が出るのを何とかしたい
- rails new したものをすぐに GitHub へ上げたら CI がガンガン警告を吐くのを何とかしたい (ある程度手をつけた状況)
- PHP 8.5 の新機能のうち影響が大きいものについて学びたい
- 業務で使っている PHP application について、わかる範囲で pull requests を出したい (数日前まで Atlassian がちゃんと使えなくて困っていました)
- 著名な言語を CentOS Stream へ載せる方法をある程度身に着けておきたい、特に package manager 周りを扱えるようになりたい (npm が大嫌いなので pnpm を入れたい、pip もあまり好きではなくて uv を入れたい)
- AWS, GCP をそれなりに使えるようになっておきたい (私の支部の server は GCP 上です)
- development と hosting の区別を分かりやすく説明できるようになりたい (可用性と変動費の関係など)
- 私の県の将棋情報を YAML 形式で整理するための仕組みを構築したい
- 私の支部が次に主管する大会のために今準備すべきことを洗い出したい (一応1年くらい前から準備を進めています)
- 英語の発音教育を体験してみたい (これは時間がなさそう)
- 今まで溜め込んだ画像情報を整理したい、特に gray-scale 画像を PNG (palette 形式) へ高圧縮する自作 script をどんどん走らせておきたい
やっぱり徹夜はやめて、今 (7時16分) から少しでも眠ることにします。
私がプロ棋士集団に期待することの原点は『ヒカルの碁』のこの頁にあります。
囲碁界の外部者である私が言うのはよくないかも知れませんが、社会的地位においても棋力においても、囲碁のプロ棋士には「高み」を維持していただきたいです。
一番弱い現役プロ棋士であっても棋院の通勤圏内で自立して生活できるくらいの年収であってほしいし、年収中央値のプロ棋士には「普通の会社に勤めるよりも稼いでいる」と言ってほしいです。中央値が250万円を下回ると推測されるようなプロ集団であってほしくないです。
rating において、上位30人のうち日本所属者は1人しかいないのに、下位30人のうち日本所属者は26人みたいな、そんなプロ集団であってほしくないです。
勘違いしないでいただきたいのですが、私は、囲碁のプロ棋士の人数をそのままに待遇を改善しろと主張しているのではありません。プロ棋士の人数を絞り込むことで「棋士の高み」を維持してほしいのです。
ちゃんと計算したわけではありませんが、日本の囲碁のプロ棋士の人数を30人くらいに絞り込めば中国や韓国と比べて見劣りしない棋力分布になると思います。棋戦の数は少々減るかも知れませんが、年収の中央値はかなり上がるでしょう。それでこそ「棋士の高み」が維持される、と考えています。
囲碁界は囲碁の普及度に合わせてプロ集団の規模を変えるべきだと考えます。
同様に、将棋界は将棋の普及度に合わせてプロ集団の規模を変えるべきだと考えます。
『ヒカルの碁』を読んだ方なら、この場面をよく覚えていることでしょう。
こういう不正行為 (ごまかし) のことをチート (cheating) と呼びます。
この不正行為をした三谷少年は、自力でこういう技術を身に着けたのか、それとも誰かに教わったのか、それはわかりませんが、もしこういう不正行為を教える囲碁教室があったら、そこは「チート囲碁教室」と呼ばれるのがふさわしいでしょうね。
(わざわざ説明するまでもないことですが、cheating には「強い」などの意味は一切含まれていません。)
様々な方の『伍と碁』の感想を読んでいたら、第1話に出てくる囲碁教室を「チート囲碁教室」と呼んでいる感想があって、ちょっと悲しくなってしまいました。
「チート囲碁教室」というものは、上記のような不正行為の技術を教える教室です。
『伍と碁』は (私が読んだ範囲では) チートなど一切出てきていない健全な漫画だと思います。