アウトプットツールとしてのCMSを考える（wordpressと代替案あり）

本稿では、

- たかがwordpressのためにお金を払いたくない
- Webサービスにお金を払いたくない
- 無料ホスティングはいっぱいあるのに、動的サービスが有料なのはおかしい

という、前時代的なおじさんがデモデモダッテする様子を見る事ができます。

## WordPressって使えるの？
A. アウトプットが目的でなければアリ、アウトプットツールとして使いたいだけならナシです。

要するに、wordpressの案件をやりたいなら使うべきで、そうでなければ使うべきではないです。

### 個人レベルでDBは必要ない
WordPressというより動的CMSを全否定しますが、個人のアウトプットツールとして考えると、DBは不要です。

たとえば個人で使用している2台のPCがあり、どちらもほどほどに使っているとします。
筆者の環境でもWindowsPC(WSL)とMacPCの２台が存在しており、案件に合わせて使い分けています。
この２台にwordpressを入れた後に、片方の更新をもう一方のPCに適用するのに手動で操作したり、gitなどを使ってプラグインなどを最新化した後にデータベースを書き換える必要があるかもしれません。

DBの代わりになるファイル（いわゆるテキストDB）を作って、そちらを読み込む事で解決できればgit管理もできそうですが、wordpressの場合はなんだかんだでうまく行ったり行かなかったりするので非推奨です（２敗）

### 解決方法
ローカルPCでwordpressの運用をしないのがベターです。
つまり、クラウドPCを作ってその中にwordpressを入れれば解決できます。

もう一つの手段としては、wordpressを入れた端末にネットワーク経由でアクセスする方法です。
リモートツールを使っても構いません。
ただし、wordpressを入れた端末を落とす時に、リモート接続される可能性を考えるとなかなか電源を落としにくくなります。
また、いつでも気軽に電源を落とせないとなると、電気代が気になるのであまり良い選択とは言えません。

あなたの環境に合わせて選んでください。

## 求める要件
- **完全無料**
- 収益化できる（＝アフィリエイトが容易）
  - マルチサイト・マルチブログができる
- ページの表示が爆速
- **運用でイラつかない**
  - 記事の書きやすさ
  - プレビュー機能がある
  - ビルド時間が短い
  - 簡単で直感的な操作性
  - 開発時に環境を選ばない
  - 技術的要件が高くない
  - メンテナンスコストが少ない
    - バニラで使える
    - 障害発生時の原因特定が容易
    - バックアップ・リストアが容易
  - markdownに独自性がある（拡張markdown）
  - fontawesomeが使える

書いていて、婚活かなんかを想起しました…。
要求は多いですが、可能な限り満たせる（＝全部が出来なくても良い）ように検討していきます。

### 要件を満たす解決方法
WordPressにはプラグインがあります。
これがとても優秀で、導入すると当然バニラではなくなりますが、やりたい事（複雑な事）は大体先駆者がいい感じにやって公開してくれています。
後は必要な情報を集めて、あるいは試行錯誤しながら導入をしてみてうまくいったものを採用すればよいです。

今年に私が運用してみたところ、要件のほとんどを解決する事ができました。
が、結局WordPressを選ばなかったため、導入は見送っています。
今回WordPressで解決できたことと、見送った理由について触れていきます。

### 異なる端末で環境構築ができない（冪等性を担保できない）
まず、これが致命的でした。
バックアップやリストアの手順は確立しているので、新規で導入する環境も同様の操作をすれば良いのですが、問題は端末ごとに環境が異なるため、プラグインの設定（パス情報など、データベース側）を都度いじる必要があり、バックアップ促進のため開発環境ごとgitに入れていたのですが、同一環境のためのバックアップとなってしまい、本来想定していた運用ができなくなりました。

たとえば、ハイパワーマシンでビルド、シンクライアントで記事を作成したい場合は活用できません。
これを実現する場合、ハイパワーマシンに接続できるようにして、シンクライアントから記事を作成する方法が手っ取り早いですが、ネットワークから遮断されるとこの方法もうまくいきません。
今回はたまたまネットワークが不安定な場所でマシンを触る機会が多かったため、代案もうまくいかず運用が破綻してしまいました。

### ビルドに時間がかかる
記事数が増えればどうしてもビルドに時間がかかるようになってしまいます。
これは静的サイトジェネレーターを使うなら許容するしかない事象です。
組み方にも寄ると思いますが、200記事のうち、1記事を更新するだけでもビルドに30分掛かるようになってきた頃から、精神衛生上よろしくないので運用が難しく感じてきました。
せっかくgitを使うので、差分だけ取って更新する仕組みを最初から考えておくべきでした。

### メンテナンス（バージョンアップ）が面倒
これはWordPressの宿命です。
結構な頻度でマイナーアップデートがされているので、しっかりと運営されているという意味では信頼感がありますが、アップデートのたびにデグレテストをするのは精神衛生上よろしくないです。
アップデートを検知したらバックアップを取って、念のためにビルドを実施しておきます。
ビルドに成功すれば、アップデートをして再度ビルドし、問題なければgitに組み込む、という運用をしていたわけですが、ビルドに時間がかかりすぎたため、だんだん面倒くさくなりついにはアップデートを放置する状態になったので、思い切って捨てたという経緯です。

## どうすれば良かったのか？
メンテナンスコストを許容しつつ、なるべくメンテナンスで負荷にならないよう、なるべくプラグインを使わないようにすべきでした。
プラグインは便利な反面、アップデート時のデグレテストの手間が増えます。
ただし、プラグインが動くことを前提とした運用をせざるを得ない場合は、WordPress本体とほぼ同じ位置に当該プラグインの重要性を置き、将来的な変更または他とのバッティングが発生する可能性があった時は取捨選択の判断が必要になる部分を最初から考慮しておいたほうが良いでしょう。

### それでもCMSを使いたい
なぜCMSを使いたいのか？の部分が明確でないんですが、要望として結構多いと感じたのが「自分のサイトを持ちたい」というものです。
ここでは「メンテナンスはしたくないけど、自分のサイトを持ちたい。ただし、既存サイトのサービスに登録して自分のアカウントを運用するものについては自分のサイトとして扱わない」と要件定義します。
「メンテナンスが不要でなるべくバニラで使える高機能なCMSが欲しい」というお話になります。

私が使ってきた中だけの話なので、上記要件を満たせる良いCMSがあればぜひご教示いただいたいですが、ここで推せるのは[adiary](https://adiary.org)です。

https://adiary.org

中身がcgi(perl)なので言語としてはかなり古めかしいですが、管理画面も含めて機能もシンプルにまとまっているため、学習コストは相当低いです。
ブログの設定欄やテーマデザイナーがやや複雑ですが、この辺りはwordpressと比べてもどちらも直感的に使うにはやや難しい設計ですが、プラグインで拡張（複雑化）されるケースを考えるとバニラがベストだと思ってしまいます。

#### 執筆のしやすさ
記事を書くためのツールであるので、絶対に触れておきたいのが執筆のしやすさです。
adiaryは記事を書く時にリアルタイムプレビューがない（運用で対処する必要がある）ため、書きやすさではWordPressに軍配が上がります。
今の御時世だと、リアルタイムプレビューが出来ないのは大きなディスアドバンテージになるので、これだけでadiaryを選択しないという判断も出来ると思います。
正直、私がadiaryからWordPressに出戻りした理由もこれです。
当時はVSCodeで書いてadiaryに移植するという書き方をしていましたが、運用に負担があるといずれ使わなくなるので、初期に感じた直感は大事にしてください。
ボロクソに言っていますが、今もadiaryは独自記法の面白さやテーマの切り替えの楽さ（＝プラグインの設定）と、コミュニティ（公式サイト）は大好きです。

#### 表示速度
処理速度の速さをPRに打ち出しており、サイトの各所に速度を計測できるプラグインが置けるので、その自信ぶりが窺えます。
実際に１年ぐらい開発用・アフィリエイト用などで愛用していましたが、サブディレクトリ型で
凝った事をしたい場合は、直接`.htaccess`をいじる必要があるため、やや上級者向けですがWebサーバーの知識をつけるという目的には限りなくシンプルに学習しやすいです。

また、実際にサーバーをいじれる環境なら、`.htaccess`ではなくconfファイルを書き換えてみましょう。
設定によっては更に高速化が期待できます。分かりやすいのはアクセスが多くなったサイトをapacheからnginxに移行してみた話とかですね。

#### メンテナンス性
なお、これはadiaryだろうがWordPressだろうが、自前でサーバーを持つ・運用するということはサーバーメンテナンスのコスト自体から逃れる事はできません。
自身でメンテナンスしたくない場合はやはりSaasかPaasがベストですが、今回の要件（既存のサイトに～）を考えると考えようによってはIaasでさえも要件から外れる可能性があります。
どちらにせよ、Iaas以上の管理を要求される場合はメンテナンスコストからは逃れられません。

## エンジニアのアウトプットツールとしてwordpressを考える
最初に述べたとおりですが、アウトプットが目的でなければアリ、アウトプットツールとして使いたいだけならナシです。
アウトプットに集中したい場合は、シンプルにQiitaやnoteをはじめとしたブログサービスを使いましょう。
公開しないのであれば、evernoteなんかもオススメです。

要望が多くなればなるほど、技術的要件が高くなるのは実務でも同じですね。
機能は多くの要望を叶えるより、運用でカバーできるものは対応しない方に進めるのが、運用も見据えた長期的なカスタマイズパッケージとしては優秀なのかもしれません。

アウトプットを目的にしないのであれば、よく使われているwordpressの仕様やアップデート状況などを把握する意味でも、普段使いをしておくと近況に敏感になれます。
また、wordpress独自のナレッジも蓄積されるので、案件獲得を目指すなら積極的に活用してみましょう。

## 次の記事
- [(21日目) 家庭教育（プログラミング）に取り組んだ体験から後進育成（IT教育）と採用・被採用について思ったこと](https://qiita.com/nomurasan/items/a9d59eff0c2642833644)
- [カレンダーページ](https://qiita.com/advent-calendar/2022/oreno_nomurasan2022)