Code for 青空文庫
いや，実は気づいてたんだけどスルーしてた。 だって東京って韓国より遠いんだよ。 東国とか気軽に遊びに行ける土地じゃないし，無理だっての。
青空文庫は現在エンジニアなしで5台のサーバを運用しており、またそれに伴うサーバの老朽化も問題となっています。そこで青空文庫が今後も発展を続けることができるよう、本アイデアソンを通して、青空文庫に興味をもっていただけるエンジニアの方を探し、安定した青空文庫の運営と、将来を見据えた青空文庫の形を模索して参ります。「Code for 青空文庫」の当面の大きなテーマはデータベースですが、今後も青空文庫を技術面でバックアップする活動を続けていく予定です。
そらもようより
まぁ，どのみち定員に達しちゃった（定員60人に対して応募が120人以上とかw）みたいだし。
青空文庫サーバの今と今後より
yomoyomo さんの記事にあるように
青空文庫は日本における電子書籍、フリーカルチャーなどいくつものポイントにおいて最重要な、公共的な意味を持つサービスである
「Code for 青空文庫」アイデアソンと青空文庫の未来 - YAMDAS現更新履歴より
というのは間違いない。
というわけで，問題を整理してみる。
現状の青空文庫
5台のサーバを自前で運用している。
- DNS サーバ
- メールサーバ
- ウェブサーバ : ミラーと合わせて2台あるが，ミラーサーバは2014年10月9日で運用終了
- DB サーバ
運用の仕方は以下のとおり。
- CentOS, Apache, PHP, PostgreSQL を使用
- 入力や校正の作業はメールベースで行っている？ （FAQ 参照）
- ウェブサーバからリアルタイムに DB サーバを参照するのではなく，定期的にウェブサーバにデータをアップロードする。
現状の問題点
- 技術担当者が存在せず，システムの全貌を把握している人がいない。
- 技術担当者がいないのに自前で運用するサーバが多すぎる。
- DB サーバの老朽化。
- 「現状ではDBサーバが飛ぶと青空文庫内のデータ資産が失われる」。まじすか！
- プログラムの中身が分からない。解析未着手。 DB サーバには作品だけでなく作業履歴も記録されている。
現状をどう変えたいか。
- 現状の資産の保全
- その上で新たにシステムを構築する
後で述べるが，システムの replace というのは簡単ではない。 現状の資産はとりあえず維持しつつ，新たにシステムを構築し，順次統合していくほうが理にかなってるとは思う。
個別の論点
現状を踏まえ，議論のポイントを考えてみる。 ただし私は，青空文庫のシステムの詳細を知っているわけではないので，半分以上は推測である。 的外れだったらごめんなさい。
古い資産をどうするか
現状のまま古い設備を新しくしたいだけなら技術の問題ではなく運用の問題。 その場合は現状の構成をできるだけ変えないのがベストで MySQL とか色気を出す必要もない。
（さくらのレンタルサーバを使うために MySQL を使いたいのかもしれないが， DBMS の変更はデータ移行だけの問題ではなく，ソースレベルでの果てしなき不毛な改造作業になることが多い）
まず技術ありきで考えるのではなく Workflow から考える
これは私の経験から言うけど， relpace の仕事でユーザが最も抵抗するのは「手順」を変えられること。 もっというと workflow が変わることを最も嫌がる。 だから，慣れている今の workflow は可能な限り現状を維持して， workflow を実装するための道具立てをより便利にかつ機能的にするか，を考える。 故に現状の workflow の解析は現場のユーザ（工作員）の声をよく聞いて念入りにやるべき。 ここを怠ると，どんな斬新な試みも失敗作になる。
Workflow がなぜ必要かといえば，ユーザが本来の作業に集中するために，付随する単純作業をできるだけ省力化するためである。 加えて管理者（管理職）の作業も省力化できることがポイント。 （更に企業の場合は，「法令順守」の要請から workflow を業務履歴として残す必要がある）
Workflow を変える場合はユーザへの負荷が軽くなる方針で考えれば同意を得やすい。 新奇なことが正しいとは限らない。
小さく始める
DNS サーバやメールサーバは外出し（Google Apps？）を考えているようだが，機能は可能な限り外部の SaaS または PaaS に任せるのがいいと思う。 たとえ専任の技術担当者がいるとしても，たくさんのサーバの面倒を見るのは骨が折れるし，そこから何らかのリスクを抱えることになりかねない。
某上方芸人の言葉ではないが「小さなことからコツコツと」である。
データベースは RDBMS である必然性がない？
青空文庫システムの詳細を知らないので確証がないのだが，公開されている現状の構成で何故 RDBMS である PostgreSQL を使ってるのかよく分からない。 DB サーバがウェブサーバからリアルタイムに参照されるのではなく， DB サーバからウェブサーバに向けて定時にアップロードされるのであれば，トランザクションについてあまり考慮する必要はなく，「NoSQL でバッチ処理」で行けるのではないだろうか。 リアルタイムでなくてもいいのなら DB サーバは無停止型である必要もない。 クラウドサーバを時間で借りて，定時が来たら
- 起動 → データ収集 → バッチ処理 → デプロイ → 停止
とすればよい。 サーバは無停止型でなければならないというのは「クラウド以前」の常識。
作業用のシステムと作品公開用のシステムを分離する
これも確証がないのだが，入力・校正用のシステムと作品公開用のシステムとの連携が密になりすぎているのではないだろうか（だからバックアップもおおごとになる）。 両者を分けると色々とスッキリする。 もっと言うと，入力・校正用のシステムは外出しにする手もある。 それこそ GitHub や Bitbucket のようなサービスを使う手もあるのだ（ユーザが納得すればだけど）。
（GitHub やそれに対応する「継続的インテグレーション」のサービスが優れているのは，ソースコード管理の面倒くさい workflow をかなりの部分自動化できる点にある。 ちなみに，青空文庫公開済みの作品は既に GitHub で公開されているようだが， aozorabunko がユーザ名になってるのが惜しい。 Organization にすれば管理の融通が利くのに）
個人的には Transifex のクラウドソーシングの仕組みは参考になるんじゃないかと思ったりする。
（Transifex はアプリ多言語化のプラットフォームなのでそのままでは使えないけど，コンセプトは参考になると思う。 ちなみに昨年 Transifex のアカウントを取って OpenKeychain の翻訳に参加しようとしたんだけど，一瞬で挫折して今に至る orz）
そして，これは長期的な話だが，入力・校正用のシステムおよび支援ツールをオープンソースとし，「バザール」を構築していけば興味のあるエンジニアが commit しやすくなると思う。
「本の未来基金」の NPO 化を
「「本の未来基金」について」には，青空文庫と本の未来基金との関係についてこう書かれている。
「本の未来基金」と青空文庫の運営は独立しています。「本の未来基金」に寄せられた寄付は、基金の運営に必要な経費以外は全て青空文庫の会計に送られ、その用途は青空文庫に委ねられます。「本の未来基金」はあくまでも寄付の呼びかけと取りまとめ、寄付金の用途の最低限の確認のみ行います。そのため「本の未来基金」は青空文庫より会計報告を受けます。
基金について | 本の未来基金より
他人のお金に口を出すのは自分でもどうかと思うが，いっそのこと「本の未来基金」を NPO 化（できれば公益財団法人に）して会計を引き受け，「本の未来基金」が青空文庫を含む本に関する公益性の高い活動にお金を出す方が色々スッキリするし，寄付するほうも（税金控除が効くので）やりやすいと思うのだが，どうだろう。 日本だけでなく海外へもアピールしていけば更に寄付も集まりやすくなるだろうし，「著作権期限延長反対」や「拙速な TPP への牽制」に対しても有利に活動しやすくなるのでは，などと考えてしまうのだが。
かくいう私自身はまだ「本の未来基金」に寄付できてないので，何とか年内には...
