井上 研一 今日、2020年6月15日からメインサイトをWordPress、ドメインはinoccu.comに戻しました。
3月くらいから、ブログに相当する投稿はnote、プロフィールサイトとしてはHugoで生成した静的サイトをGitHub Pagesに置き、さらに技術的なネタはqiitaに書いてみるという運用をしてきたのですが、今日からはすべてWordPressに戻るということになります。そうしようと思った理由を少し書いておきます。
やっぱり自分の書いた文章は自分の手元に置いて一元化したい
結局は、これに尽きます。今まで、サイトを移転することはあってもコンテンツ一元化については基本的に維持してきました。今回のコンテンツ分散はほぼ初めてのチャレンジでした。コンテンツをそれぞれふさわしい場所に置くことによって、コンテンツの一元管理よりも拡散を優先しようというのがその狙いでした。
確かに、拡散効果はあったように思います。noteやqiitaはサービス自体にコミュニティ的な人の集まりがあるし、サービス内のコンテンツをそのコミュニティティ内で共有・拡散する機能を有しています。そのため、自分が書いた文章にスキやLGTMといった反響がスピーディーに返ってくるのは快感だったりします。その快感が次のコンテンツを生み出そうという原動力にもなるので、そのサービス内では非常に良い循環が回っています。それは素晴らしい。
ただ、一方で自分の書いた文章があちこちに置かれているという状況はやはり慣れない。代替策として、プロフィールサイトにはGoogleカスタム検索を置いて、自分の書いた文章を一元的に検索できるようにしたのですが、どうしても手元に置いておきたいという思いが強くなってしまいました。
堀正岳さんがnoteに「noteはストック情報を蓄積する場所ではないのかもしれない」という投稿をしています。
少なくとも私のようにフローのコンテンツとストックのコンテンツの交点で時間とともに文章の価値が増大することを期待しているユーザーの場合、現在のnoteには多少機能的に足りない部分が見えてくるのです。
堀さんが機能的に足りないと指摘しているのは、記事のエクスポート機能がないことと、記事の整理方法がマガジンくらいしかないという2点です。
私のブログには玉石混交ありますが記事が4000本以上あります（そのうち現時点で公開しているのは2200本程度）。何しろブログというものが始まる前の1997年に自分のいわゆるホームページに書いた文章からストックしています。
その2200本か4000本の文章をnoteに移行する気にはなれないし、移行したところで適切な管理ができるとも思わないので、やりません。そうすると、今後書いていく文章は今までの蓄積とは切り離されてしまうのは如何なものか？という不安を感じますし、仮にnote上にこれから数年をかけて2000本の記事を書くことが具体的に想像できるか？というと、それも違うかなと。そう考えると、やはり、noteはストックよりもフローのツールで、自分の手元に置いてあるブログとは別の考え方をする必要があるのではないか？と思うわけです。
そこで、コンテンツは手元に置くことにして、拡散については別の策を考えることにしようと思います。王道的な策となりますが、TwitterやFacebookといったSNSの有効活用です。今までもやってなくはなかったのですが、きちんと設計してやっていたわけではなく、WordPressのテーマやプラグインにその機能があるから、なんとなく使っているという感じでした。今回は、きちんと設計して、やってみようと思います。
HugoじゃなくてWordPress
ちなみに、堀さんはWordPressで構築してきたサイトを静的サイトジェネレータのHugoに乗り換えられています。ちょうど同時期に私もプロフィールサイトをHugoで作っていたので、Twitter上で少しメッセージ交換をさせていただいたりもしました。
なのに、結局、WordPressに戻すの？と、思われるかもしれません。4000本の文章はHTML→Markdownに変換すれば良いし、テーマも大体できていました。それなのに、今回WordPressに戻した理由は、どこからでも書ける環境を作りたかったということです。
いま、WordPressに書ける環境がどれだけあるかというと、いまこの文章を書いているMacBook Pro（Ulyssesを使っています）、iPadとiPhone XS Max（どちらもUlyssesが使えます）、Windowsマシンが2台（Surface Pro LTE AdvancedとOneMix 3）の計5台です。Hugoに投稿するためには、GitとHugo CLIを使える環境が必要なので（GitHub Actionsをうまく使えばHugoの部分は自分のVPSサーバに肩代わりさせられるとは思う）、MacBook ProとWindowsマシンくらいに環境が限られてしまいます。
一方、WordPressであれば、Webブラウザさえあれば更新可能だし、Ulyssesから直接WordPressに投稿することができます。さらに、全ての環境向けにWordPress.comのアプリが提供されているので、それを使うこともできます。
WordPressで充分対応できる目処がついた
Hugoで作ったプロフィールサイトでは、Texを使った数式や、Mermaid.jsでのシーケンス図、さらにReveal.jsでのスライドといった様々な形式のコンテンツを作っていました。TexやMermaid.jsは技術的なテーマについてのコンテンツを作るために必須です。今年度からは大学院生としての活動もあるので、なおさらです。
Reveal.jsはMarkdownエディタで簡単なプレゼンテーション資料を作る、最近使うようになった環境です。有料研修・セミナーの資料は今までどおりPowerPointで作ろうと思いますが、そうでないものについてはReveal.jsでも充分なものができます。
こうした環境をWordPress上でも構築することができました。そのため、Hugoで作っていた資料ページのコンテンツを、全て移行することができました。
また、WordPressにJetpackプラグインを導入することにより、Markdownでコンテンツを作ることが充分可能になったことを検証できました。Ulyssesで書いた文章はWordPressへの投稿時にHTMLに変換されます。そのため、WordPress側でのMarkdown対応は不要です（Ulyssesでの投稿時にフォーマットをMarkdownとすれば、Markdownのまま投稿されます）。しかし、資料ページのコンテンツでコードやTexでの数式などを書く際は、執筆時だけでなく、WordPress上でもMarkdownでコンテンツを管理して欲しいのです。JetpackのMarkdownサポート機能を有効にすると、それが可能になります。これで、例えばTyporaというTexとMermaid.jsのどちらにも対応したMarkdownエディタ（しかも、macOSとWindowsの両対応）でコンテンツを作り、それをWordPressの投稿画面にコピペするか、wp-cliあたりを使って直接更新するといったスクリプトを書いて、WordPressのコンテンツにするということができます。軽微な編集をWordPressの投稿画面上で行う場合も、Markdownのまま編集可能です。
こうしたこともあって、WordPress上であらゆるコンテンツを管理できる目処がついたのです。
あとは、コンテンツの表示スピードです。Hugoは静的サイトを生成するので、表示は極めて俊敏に行われます。一方、WordPressは動的にサイトを生成するため、表示スピードについては分が悪いのですが、Nginx＋php-fpmでのサイト生成や、php-fpmやMariaDBでのキャッシュ有効化といった高速化手法をとることによって、充分なスピードを実現できたと思っています。現時点では、inoccu.comはAzure Virtual MachineのB1S環境で動作しています。この環境は仮想CPU1コア、メモリ1GBというスペックなので、かなり貧弱な部類でしょう。しかも、この環境は新規ユーザであれば１年間無料で使用できます。それで、これだけのスピードが出るのなら、WordPressで充分と言えます。
そんなわけで、今日からは再びWordPressサイトで私の活動などをお伝えしていければと思います。