今期、当法人は単年度黒字を達成することができた。その直接の原因は、前章で述べたように外部企業からの受託開発が拡大したからだ。しかし、その背景にはVivliostyleプロダクトが充実したこと、そしてそれによってプロダクト間のエコシステムが機能し始めた事実がある。言い換えれば、これらの要因なしに受託開発の拡大もなかったと考えられる。
そこで本章ではVivliostyleプロダクトそれぞれの開発状況を説明する。さらに次期への課題はないかを探っていく。これも繰り返しになるが、当法人は決して少なくない累積赤字を抱えており、その解消が当面の目標となるからだ。
各プロダクトの開発状況について報告する前に、ラインナップにおける位置づけを整理しておこう。近年プロダクトが増えたのは喜ばしいが、それぞれがどのような役割を果たしているのか、全体の中でどのように位置づけられるのか、外側からは分かりづらくなっているからだ。
上記のリンクは、それぞれのリポジトリへのものだ。つまり、上記分類はリポジトリの分類でもある。ただし、上記分類は分かりやすく説明するためのもので、必ずしも厳密なものではない。たとえばVFMはライブラリであると同時に、MarkdownをHTMLに変換するジェネレータの一面ももつ。
では次節以降、上記分類に従いながら今期における各プロダクトの開発状況を、ユーザーイベントでの発表やブログ記事などを参照しながら説明していこう。なお、参考のために期首時点と期末時点のバージョンをカッコ内に示した（プロダクトとしてのリリースの概念がないVivliostyle ThemesとVivliostyle Pubを除く）。
Vivliostyle.jsは実際にCSS組版をおこなうソフトウェアであり、Vivliostyleプロダクトの中核的存在である。幸いなことに本プロダクトは、以下のように今期大幅な機能アップを果たすことができた。
では、これらの機能はどのようにして開発されたのか。当該リポジトリにおける月毎のプルリクエスト数をグラフ化し、前期と比較してみたのが下記のグラフだ（図4／自動処理は除外し、人間によるプルリクエストのみを対象にした。以下同）。
前期も年間を通してコンスタントにプルリクエストを出していたが、今期はそれを上回る開発ペースであったことがわかる。前掲の機能アップも、こうした熱心な開発の結果として実現された。
ここで重要なことは、Vivliostyle.jsの機能アップが、これを組み込んだVivliostyle CLIやVivliostyle Pubにも波及し、直ちにこれらも新機能を実装していったことだ。まさにライブラリとしての本領が発揮された場面だった。
書籍むけ組版に最適化したMarkdown方言であるVFM (Vivliostyle Flavored Markdown)は、今期v1をリリースすることができた。このv1は、きたるべきv2への準備という側面もある。
もともと本プロダクトは、Markdownへの変換エンジンとしてRemarkを採用していた。しかし、その新バージョンRemark 13には過去のバージョンと非互換な変更が多く含まれていることから、その実装は多大な作業量が予想された。
そこで、まずRemark 13なしに実装できる範囲の機能を備えたバージョンをv1としてリリースし、その後v2としてRemark 13への対応に取り組む方針を決めていた。詳細はメンテナーであるakabekobeko氏の発表を参照してほしい。
2021年7月21日にリリースされたv1.0.2が、このRemark 13なしに実現できる機能を実装したものだ。同じく詳細は下記を参照されたい。
v1で解決されたIssue等の一覧は下記の通りだ。Vivliostyle.jsと同様、こうした機能アップは速やかにVivliostyle CLIをはじめとしたプロダクトに実装されている。
Vivliostyleプロダクトが共通して使えるスタイルファイルのライブラリーが本プロダクトだ。スタイルを定義した複数のThemeファイル群と、それらThemeを作成するためのツール群から成り立っている。
今期も複数回のマイナーアップデートをおこなった。しかし成果として取り上げるべきは、むしろ下記ユーザーガイドの公開だろう。
ユーザーは本プロダクトによって、Vivliostyleプロダクトを使う際に新しくスタイルを設定する手間が不要になり、より早く簡単に文書作成ができるようになる。しかし、そのためにはユーザーの需要に応じた多種多様なThemeの公開が必要となる。しかし、私たちだけで多くのThemeを作成・公開するのは現実的ではない。個々のユーザーが簡単に新しいThemeを作ることができ、また、それを気軽に公開してもらうようにしなくてはならない。そうすることでライブラリーとしての本プロダクトがより便利になり、それがさらに新しいTheme作成を促すと言った循環が成立するはずだ。
ところが現状は本プロダクトの認知度が低く、まだまだ目標への道のりは遠い。そこでメンテナーであるyamasy1549氏が考えたのが、まずThemeの使い方、作り方などを知ってもらうためのドキュメント整備だった。上記ユーザーガイドはその第一歩といえるものだ。より詳しくは下記を参照してほしい。
CLI（コマンドライン・インターフェイス）でMarkdownをHTMLに変換、出力できるのが本プロダクトだ。まず月間プルリクエスト数を、前期と比較したグラフを見てほしい。前期ほどではないが、今期もコンスタントに開発が続けられたことが分かる（図5）。
このような開発の結果、今期も本プロダクトはさまざまな機能アップを果たすことができた。中でも大きなものは、仮想環境下で実行できるDockerモードのサポートだろう（v4.0.0）。Dockerはプログラムの実行環境を仮想化してくれる。これにより、OSやブラウザ、Vivliostyle CLI本体をバージョンアップすることで、出力結果が変わってしまうトラブルから解放された。こうした冪等性／信頼性の確保は、実務でVivliostyle CLIを利用したいユーザーにとって不可欠なもののはずだ。
これ以外にもマイナーながらいくつもの機能が追加されている。ここでは本プロダクトのメンテナーであるspring-raining氏が、第4期終了直後に開催されたユーザーイベント「Vivliostyle ユーザーと開発者の集い 2022春」において、「Vivliostyle CLI update - 2022 Spring」として発表したものに従いながら、v4.0.0以降のアップデート内容をまとめてみよう。
--httpオプションを追加
#234--viewerオプションの追加
#234vfmオプションを、CLI内部でのVFM実行時にそのまま渡すことが可能に
#264なお、spring-raining氏はこの時の発表で、本プロダクトの将来構想について以下のように述べている。次期への期待が膨らむ。
本プロダクトは、Vivliostyle CLIの実行環境をインタラクティブに構築することができるソフトウェア、つまりインストーラーである。ただし、今期はメインテナンス的なアップデートが多く、大きな機能アップはなかった。
本プロダクトは、VFMを使った静的サイトジェネレーター（Static Site Generator）として構想されたもので、今期に入って新しく開発がスタートしたプロダクトだ。
もともとのきっかけは、秋のユーザーイベント（2021年11月14日開催のCSS組版 Vivliostyle ユーザーと開発者の集い 2021秋）における自由討議のセッションで、せっかくVFMがv1をリリースするまで成長したのに、これを使ってVivliostyleのサイトや各種ドキュメントが書けないのは残念という声が出たことだった。それに応える形でVFMのメンテナーであるakabekobeko氏が手を挙げ、2022年1月から開発がはじまった。
現在、来期中のリリースを目指して開発がすすめられている。リリース後は vivliostyle.orgをはじめとする、Vivliostyleに関わるユーザー向けドキュメント制作システムに実装していく予定だ。そうなれば、豊富な表現力をもつVFMを使ってVivliostyleに関する情報発信ができるようになる。こうして、ますますVivliostyleのエコシステムが広がることになるだろう。
本プロダクトは、ここまで述べてきたVivliostyle.js、VFM、Vivliostyle Themes、Vivliostyle CLIをクラウド上にデプロイしたWebアプリだ。ユーザーがブラウザ上の左側画面でMarkdownを書けば、即座にCSS組版して右側画面にプレビュー表示する（図6）。
もともとは2019年度（前々期）において、開発資金確保を目的とした未踏アドバンスト事業への応募のために急遽立ち上げられた。コミッター達が一丸となった2ヵ月間の集中開発をへて、2020年5月にPoC（Proof of Concept、概念実証）まで完成させた（前期事業報告書参照）。
しかし、2020年6月に落選が決まった後、少しずつコミッターが去っていき、残ったtakanakahiko氏だけがコツコツと開発を続けてくれていた。そうした状況を一変させたのが2021年11月、AyumuTakai氏の参入だった。ここで、本プロダクトの月間プルリクエスト数を前期と比較したグラフをご覧いただきたい（図7）。
一見すると今期前半において前期よりも多くプルリクエストをだしている（これはtakanakahiko氏の仕事）ものの、AyumuTakai氏が加わった11月〜翌年2月に関しては、さほど前期と今期の違いはないように見える。そこで指標を変えて、月間コミット数を前期と比較したグラフを見てみよう（図8）。
青い線は前期の、緑の線は今期のデフォルトブランチに対するコミット数だ。この2つのラインを見る限り、前掲図7の月間プルリクエスト数と同様、11月〜翌年2月に関してはさほど開発は進んでないように見える。ところがグレイのラインに注目してほしい。これは今期のAyumuTakai氏によるprototypeブランチでの月間コミット数を重ね合わせたものだ。前期4月〜5月のコミット数は4〜5人のチームで開発した結果なのだが、それを凌駕する数のコミットを、たった1人でしていることが分かる。ただし、その開発方法はいささか変則的と言えるものだった。
AyumuTakai氏は11月2日からprototypeブランチで開発を始めているが、2月に入るまでデフォルトブランチへのプルリクエストは出さず、ひたすらprototypeブランチで多くのコミットを積み上げている。もしかしたら、たくさんの改良を次々に加えていった結果、プルリクエストを出すタイミングを失ったのかもしれない。結局、prototypeブランチはそのままにして、2月3日にpre_alphaというブランチを新規作成し、ここからデフォルトブランチへのプルリクエストを1回だけ出している。
この結果、前掲図7で示したプルリクエスト数にはAyumuTakai氏の作業はほとんど現れなかったが、前掲図8においてprototypeブランチのコミット数を重ね合わせることで、彼の貢献が可視化できた。この時のプルリクエスト、アルファ版準備 #142の記録をみると、ここで追加されたユーザーインターフェースの変更や追加した機能のリストを見ることができる。どれも本プロダクトをごく普通に使うためには、必須の要素であったことが分かる（なお、AyumuTakai氏は本業多忙を理由に、3月いっぱいで開発から退いた。彼の貢献に心から感謝する）。
ここまで本プロダクトの開発を直接担当したAyumuTakai氏やtakanakahiko氏の貢献について述べた。しかし忘れてはいけないのは、前節まで説明したVivliostyle.js、VFM、Vivliostyle Themes、そしてVivliostyle CLIのアップデートの成果を、本プロダクトはコンポーネントを入れ替えるだけで、そのまま取り込むことができたということだ。
たとえば、前掲図6を見るとWebフォントを表示しているが、これは本プロダクトではなく、Vivliostyle.jsのアップデートによって実現した機能だ。まさにエコシステムとしてのVivliostyleプロダクトの力を実感できよう。
このようにして、当初の目標よりもだいぶずれ込んだが、2022年4月23日開催のCSS組版 Vivliostyle ユーザーと開発者の集い 2021秋で、本プロダクトのアルファ版公開を告知することができたのである。
ここでは、下記のVivliostyleに関わるユーザー向けドキュメントと、その制作システムを一括して取り上げる。
当法人にとって、もっとも身近な情報発信のツールは上記1におけるブログである。今期は以下の8本の記事を更新した。
また、Vivliostyle Themesの節で新しく追加したことに述べたユーザーガイドは、上記2のうちの一つだ。そして上記3も、Vivliostyle Pubのアルファ版公開に備えて、今期新しく追加したユーザーガイドだ。
いずれも執筆はMarkdownでおこなうが、それをHTMLに変換するコンバーターは、1はJekyll、2と3はdocute、4はPandocとバラバラであるという課題がある。この状況を改善し、さらにVFMの豊富な表現を使えるようにしようというのが、 vivliostyle-sitegenであることは前述したとおりだ。
以上、今期におけるVivliostyleプロダクトの開発状況を説明した。創立当初、当法人のプロダクトは現在のVivliostyle Viewer／Vivliostyle.jsと、Vivliostyle CLIにつながるものだけであった。そこから毎年少しずつリポジトリを増やしていき、前節まで述べてきたようなプロダクト間のエコシステムが機能し始めるところまで辿り着いた。
前章において、今期に単年度黒字を達成したことを報告したが、事業収益のほとんどはVivliostyleプロダクトに関わる受託開発、あるいは過去に納品したプロダクトのメンテナンスにより得られたものだ。つまり当法人の場合、プロダクトの開発とその拡充が、ダイレクトに事業収益確保につながっている。
とはいえ、Vivliostyleプロダクトを拡充しさえすれば、そのまま事業収益が増えていく訳ではない。つまり増益のためにプロダクト拡充は、必要条件ではなく十分条件なのである。では増益を阻むものはなにか。以下のような課題を挙げたい。
上記1の対処として、受託開発以外の多様な収益の確保が必要だ。たとえばVivliostyle Pubを使った事業収益などが挙げられるだろう。また、第3期にスポンサー募集ページを作った後、ほとんど働きかけをしていない寄付金の拡充も真剣に考えるべきだろう。
同じく2については、前章「2021年度正味財産増減計算書」で述べたように、今期は村上代表以外の受託者を確保できたところ、来期も引き続き受託者を確保できるかがカギとなる。たとえば、コミッターの皆さんに受託開発をお願いすることも検討するべきだ。加えて個々のコミッターの負担を減らすために、プロダクト全体でコミッターを増やす努力が求められるだろう。
最後に3については、発注先の多様化は当然として、あわせて前述1の対処がそのまま3への対処ともなるはずだ。