STUDIOをエンジニア目線で解剖する
引き続き副業でいろいろなことに挑戦できている。その中の一つがNoCodeによるプロダクト開発。今回はその中でも最近お気に入りのSTUDIOについてがっつりエンジニア目線で書く。
小生、エンジニアとして小規模開発はスクラッチだろうとなんだろうとインフラからネイティブアプリまでなんでもやってきた状態な今はたしてSTUDIOは我々の何を解決するのかを伝えたい。
STUDIOが解決するもの（顧客課題目線）
広い話からしましょう。STUDIOはどこに位置するソリューションのなのか。Webアプリケーションはざっくり「集客・業務支援・サービス提供」の３つの領域のどれかの課題を解決をするものだと考えてみる。「物を売るサイトはサービス提供」「LPは集客」といった具合だ。アプリケーション自体が全てを兼ねていたり、変わったユースケースもあります。例えばメディアのようなものは集客＝顧客支援とも言えます。基本的にはこれらの1つ、もしくは複数の課題を解決するものと考えることができます。
お花屋さんを例に考えてみると
・売上を伸ばすためには「集客」をする必要があり、チラシや紙広告では解決できない速度で情報を伝搬させるために「専用のホームページを作る」ことで解決する
・在庫管理を効率化するという「業務支援」のために「帳簿をデジタル化」することで解決する
・「お店以外の場所で販売する」という「サービス提供」のためにWebアプリケーションを提供することで解決する
多くの技術・仕組みがこれらの課題を解決してきました。1つの領域の課題を解決するものもあれば、複数の領域を横断して解決できる仕組みもあります。例えば以下のような感じで解決手段があります。
この中で今回注目したいのは「集客」。これは下記のように「集客」そのものと、コンテンツ（商品やサービス）が動的（増減したり日で変わる）になるような「集客支援活動」があります。STUDIOはその両方、または一方を解決可能です。
■ 「集客」の課題を解決する例（マッチングアプリの宣伝）
Studio Showcaseを見ると事例が確認できます。
アプリの宣伝をする静的なLP。動的に見えるコンテンツもあるが、リンク先が別ドメインなので、別サイトっぽい？
■ 「集客」「集客業務支援」の課題を解決する例（みらいの食券）
がっつりドメインにLPと入っていて、これが本サイトじゃなくてランディングページ用のサイトであることが分かります。メインコンテンツである食券の情報を動的に日々作成・変更し集客の情報として利用するため、この集客業務が発生します。
事例からもわかるように、STUDIOは基本的に「集客」を求める人にバリューを発揮するサービスだと考えると良いと思います。
STUDIOが解決するもの（開発者目線）
これまでは「集客」の領域はWordPressが解決してきました。私も運用経験があり、利便性などを理解しつつも「WordPressはできることが多すぎて逆に難しい」場合もあると感じています。
■ WordPressの難しさ
WordPressはサーバにインストールするだけですぐホームページを始めることのできる最も有名なアプリケーションの一つです。様々な機能があり、これを拡張することもできます。この自由度の高さがメリットでもあり、デメリットにもなります。
例えば、「レンタルサーバでWordPressを立てて自分のブログを運用したい」と思う時、もちろん参考サイトなどを見れば誰でも構築可能ですが、サーバの契約からドメインの準備、インストールをしてプラグインを入れて、テーマを入れて、、、さらにリリース後は脆弱性対応やバージョンアップやアクセス管理などを準備して、、、など自由度からくる知っておかないといけないこと・やらないといけないことが多い問題が発生しがちです。
もちろんWordPressのホスティングサービスや類似の仕組みを使うことも可能ですが、問題自体というより、問題が発生しがちであることが問題あると思います（ややこしい）。知識を持ってないとこれを回避できない課題がある可能性のある技術を運用することは想定しないリスクやリテラシーを懸念する必要がありこれ自体が大きなコストとなる可能性を持っています。
■ STUDIOはWordPressの課題をどのように解決したか
前置きは長くなりましたが、STUDIOは上記の課題を解決できているように思います。クラウド完結であることや機能を必要最低限にしつつ、サイトを表現するための機能を柔軟に提供しています。具体的に出来ること、できないことをベースで細かく説明します。
STUDIOでできること
なんとなく「いいかんじのNoCodeツール」という印象だったのでちょっと期待値が高いところから色々調べた結果を適宜WordPressと比較しつつ、下記にまとめます。
・既存サービス（LAMP構成のような構成）をリプレースできる？
流石に無理すね・・・自前で実装しているアプリケーションへの導入を考えたときいに置き換え可能なのは「集客」「業務支援（集客作業）」のみとなります。それ以上の機能は持たないため提供できない。例えばログインや販売のような仕組みは持っていない、ただ一部は切り剥がせるかもしれません。ただドメインは別になるため、SEOパワーは懸念。
xxx.comのようなサイトを運営している場合、そのトップページを置き換えるようなことはできないので、lp.xxx.comのようなサイトで運営する必要がある。
【WordPressと比較すると】
AWS上であれば自前でEC2上で動かして、ALBでトップページはWordPressでといったこともできます。またログイン機能のようなものもプラグインで擬似的にできたりするので、やれる範囲はやはり広いです。
・デザインはどこまで融通がきいて、どこまでスキルが必要？
レスポンシブ（タブレット・モバイル）・デスクトップでそれぞれ動的に幅やマージン指定などのプロパティ指定が可能。3カラムや固定ヘッダーなどよくあるレイアウトもパーツ化されておりドラッグアンドドロップで再現できる。
【WordPressと比較すると】
サンプルアプリケーションはあるのですが、テーマみたいな概念はなく、自前でレイアウトは作る必要があります。なのでデザインスキル0であ浸かるということはないと思います。
・アニメーションは準備できる？
設定可能。複雑なことはできないが、hover/appearのようなよく使うエフェクトは可能。
・クリエイティブは自前で必要なのか？
フリー画像やマテリアルアイコンがあり、利用可能。これだけでそれなりにリッチなコンテンツを作れる。
・フォームは組み込める？
問い合わせフォームを作ってメールに転送する仕組みが入っている。
・HTMLやCSSの組み込みはできる？
提供していない。formを吐き出すような営業支援ツールは利用できなそう。
https://help.studio.design/ja/articles/4764247-html%E3%82%92%E7%9B%B4%E6%8E%A5%E7%B7%A8%E9%9B%86%E3%81%97%E3%81%9F%E3%81%84%E3%81%AE%E3%81%A7%E3%81%99%E3%81%8C
・スケール・負荷やトラフィックへの観点はある？
SLAなどは記載がない？
【WordPressと比較すると】
スケールの観点はフルマネージドなWordPressホスティングサービスを使っていれば一緒です。コスト観点で1000円単位でもっと下げたいという希望がない限りはあまり変わらないと思います。
・本番やSTGのような考え方はあるか
ない、ただライブプレビューは便利なのでなくても問題ないように思う。
・権限承認のようなプロセスはあるのか
ない、権限もOwner,Editorのみ。コンテンツの本番更新を承認制にしているときなどはフローの見直しが必要。
・データとの関わり方
外部API連携などはない、外部データを出すような仕組みはない。
・技術力は必要なのか
ない、仕組みさえ理解できればおｋ。
・SEOなどの観点はあるか
ある、ツール連携など、AnalyticsやTag Mangerのようなよくある広告系MAとの連携は十分。
https://help.studio.design/ja/articles/2639194-%E5%A4%96%E9%83%A8%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A8%E3%81%AE%E9%80%A3%E6%90%BA
またキーワード設定なども個別で可能。
【WordPressと比較すると】
AWS環境であればEC2上でWordPressを動かして、ALBでサブディレクトリとしてアプリケーションアクセスも出来るけど、STUDIOだとサブドメ必須なので、検討は必要
STUDIOでできないこと
全然それなりにできないこともある感じです。
・共通のレイアウトの動的な再利用
「たとえば同じレイアウトで文言だけ変えたいけど一部はカスタムしたい」みたいな要件になってくると難しくなってくる。例としてFAQのページがあって、質問と回答は基本的に同じレイアウトだけど一部のパターンだけ別みたいのが難しい。
共通化として「シンボル化」「リスト化」などが用意されているが、動的にこれを構築してカスタムするところまではできていないので、実直に複数の同じレイアウトをコピペする必要がある。
・自分でのフォームの埋め込み
マーケティングツールなどで顧客管理のためにformを埋め込みたいことがある。この時に直接コードは書けないのでiframeを使うなど必要になる。
まとめ
すでに運用されているWebサービスに導入というユースケースでは、プロジェクト単位でのLPの制作やキャンペーンページの量産という観点で効果を発揮しそうに思いました。
急いで作る採用サイトやスポットでのキャンペーンのようなデザイナーのリソースをそこまでかけれないけど運用していきたいオウンドメディアとかに相性がいいんじゃないでしょうか。
今回私も案件を受けたことで、0から触り始めましたが要件を満たす機能のキャッチアップは15hくらい、it's a 即戦力だと感じました。早い段階で実装?に集中できました。またWordPressという選択肢をとっていた場合に説明が必要な脆弱性やスケールの話などもすべて割愛ができているのでコミュニケーションコストも下げれたと思います。
SEOや問い合わせを管理するフォームの管理も、バンドルされているのであまり意識することなく、要件を満たすことができたのでSo Happyでした。
この記事が気に入ったらサポートをしてみませんか？