はじめて1ヶ月、ビルド時間がえらいことになっていく…

Table of Content

静的サイトジェネレータの問題点が早々に浮き彫りになってきました、
恐れていた問題というか、抗えない問題ですね。
記事を書く、カテゴリを作る、タグを作る、ampに対応する…
動的環境(wordpressのアドレス)を増やすたびに、ビルドするhtmlファイルも当然増えるので、仕方ないと言えば仕方がないのですが、快適さはだんだん失われつつあります。

これが、私が去年に静的サイトジェネレータを捨てた理由でもあります。

静的サイトジェネレータを使って記事を書く場合の問題点と解決方法

CSSを適用した状態で記事を確認する方法がありません。
コンテンツを管理するCMS側でうまく設定できればいいんですが、axios等に対応していない場合はうまくいきません。
つまり、JAMStackなサイトでなければプレビューは使えません。
そうでなくても、プレビューサイトを作るのに時間がかかります。
記事を更新するたびに確認作業を行うなら、常にプレビュー機能が迅速に動いている必要があります。

ローカルでWordPressを使ってビルドする強みがここに出てきます。
WordPress単体でプレビューサイトを構築できるので、執筆時は静的サイトビルディングについて全く考えることなく普段使いをしながら、ユーザーに公開する環境については静的サイトなので軽量かつ高速な環境を提供できます。
誤解を恐れずに言うなら、間違えて公開してしまってもpushしない限りユーザーには見れないので、公開設定をしている状態でレビューをする環境があり、開発・検証環境で問題なければpushする事でユーザーに配信ができるので、コンテンツに対してもセキュアな環境が作れます。

ユーザーは表示が速い方がいい、運用者は動作が速い方がいい、開発者はメンテが楽な方がいい

三方良しの理念に基づいています。
開発をラクにすると、ユーザーファーストは失われます。
ユーザーや運用をラクにすると、開発が頑張るしかないです。
割を食いやすい開発者が、ユーザーと運用のちょっとの負荷でシステムの健康管理体制を容易に維持できるなら、開発側のプロジェクトマネージャーあるいは営業渉外担当が働きかけて対応すべきだと思います。
開発で楽をして運用負荷が上がるのでは意味はありませんが、

  • 運用負荷を下げて保守コストも下げられる範囲
  • 運用負荷を下げて保守コストが上がるならやらない
  • 運用負荷を上げて保守コストが下がるならやらない

ぐらいの感覚でシステム化する領域を吟味した方がいいんじゃないかと思います。

経験談: 業務運用システムコンサルタントの目

あんまり大っぴらにプロジェクトの話はできないんですが、考え方とアプローチのお話を少し。
業務改善を考える際に、システムを回収すると一言で言っても、アプローチはユーザー側とシステム側の両面から考える必要があります。

  • ユーザーの入力項目を削減する(項目数、あるいは選択式)
  • ユーザーの入力補助をする(予測変換など)
  • ユーザーの入力を自動化する仕組み(ツールを起動したら画面にデータを投入する)

項目が3つありますが、ユーザーオペレーションの自動化か、システム側の改修か微妙なところがあるためです。
もちろん、現場によってはこれ以外の方法(特に業務連絡)で解消する方法があるかもしれません。
運用自体をシステムに合わせて変えるという、大胆な戦略も必要になるかもしれません。

シェアする