最近は余暇の時間の大半を、新サービスの開発に投下している（年内リリースが目標）。
さて開発人員2名の余暇でシステムを作ろうとした際に、最も大事なのはスコープ管理であることはおおむね同意してもらえると思う。
つまり作らなくていいものは作らないの精神だ。
コンポーネントとしてのwordpress
そこで提案したいというか、目下検討中なのがシステムコンポーネントとしてのwordpress運用である。
wordpressをプラットフォームにしてSNSやらECサイトを作る発想は数多いが、これはwordpressを開発すべきシステムの一部として運用する発想を意味する。
具体的には何に使うのか。静的コンテンツ管理である。
いうまでもなく、wordpressのコンテンツ（テキスト+画像等のメディア）管理に関するUIはかなりこなれている。
少なくとも同等の仕組みを、自前のシステムに組み込むのにはちょっと躊躇する程度には。
サービスを開発するにあたって、お知らせページや、キャンペーンページなどこまごまと日々コンテンツを作成・管理していかなければならないことは目に見えているが、ここを作りこむのは正直工数がもったいない。
で、あるなら別途立てたwordpressをコンテンツプロバイダーとして、wordpressのjson api(テーマとして自作してもよし、プラグインで対応してもよし)を自前システムが叩いてコンテンツを表示できればいくらか工数が削減できるのではないだろうか。
という目算。
実際に採用するかどうか
正直これだけだと、wordpressを運用するコストのほうが高いかな・・という気がしている。
自分で書くと割とめんどくさい写真などのメディア管理機能を任せられるのは結構うれしくはあるが、肌感覚として釣り合うかどうか微妙なところだ。
コンテンツ管理がよりサービス内で重要な位置を占めるか、ほかにwordpressに委譲したほうが楽な部分があるかによって天秤の傾きが私の中で変わりそう。
小規模システムを受託開発する時に私が気をつけていることにも書いたが、モノリシックな構成のほうが見通しのよさは優位性があるので。
ブログにこの記事を書いた理由
システムの設計には正解はない。
将来的に何が必要になるのか（ロードマップ）、今どうしておけば最小の実装で済むのか、運用時に負担にならないか。想定している性能は出るか。コードを書きやすいか、読みやすいか。
まぁ、そういういろいろな評価の尺度があって、その中でひとつづつ折り合いをつけていく必要がある。
それらはもちろんトレードオフの関係の中で選択されていくのだが、システムのドキュメントには最終的に採択されたアーキテクチャのみ（あとせいぜい採択の理由）が記述され、競ったアーキテクチャや、それぞれの利点などは残らない。さすがに残すのも違う気がする。
しかしブログやそれに類するものであれば、後からシステム設計の判断を評価するという意味でいいのではないかと思ったのだ。
以上。
コメント