こんにちは！ SHE でエンジニアをしている錦織です。
私たちのチームはエンジニアが少なく、作りたい機能に対してのリソースが他のチームと比べても不足しがちな状況です。そのような中でもエンドユーザーにより良い体験をしてもらい、事業を伸ばしていけるような取り組みの1つとして、他のチームと一緒になってワークフローの整備を進めた事例について紹介します。
😕 当時あった課題
開発リソースの向き先の偏り
開発者の数がニーズに対して少ない状態にありました。さらに会社的にも新機能の開発が優先的に進められていることが多く、開発リソースの多くもそちらに向かっていました。サービス体験を良くしていくにあたって Web ページ内容の最適化は大切ですが、リソース配分の優先順位付けの結果、本来最後までやりきりたかった最適化までうまく手がつけられずに次の機能開発に向かってしまい、これまでに作った機能に関する UI のちょっとした変更やリンク先の修正などのリクエストは新機能の開発を進めていく隙間で対応するというような優先順位付けになっていました。
改善施策の実行遅延
そういった状況から、施策実行に求められるスピードとリソース都合による開発スピードがうまく噛み合わず、改善施策開始時期を後ろ倒す検討が必要になったりしていました。
誰がボールをもって進めるべきかの都度判断
あるいは、開始時期を後ろ倒したくないときには他のチームに代わりにお願いすることになってそちらにしわ寄せがいったり、それらの結果どのチームにお願いしたらいいのか・誰に相談するのが最適なのかわからない状況が発生していました。
🧱 KARTE Blocks
以前から SHE では KARTE を使っています。その製品の1つに、 KARTE Blocks というほとんどコードを書かずに UI の出し分け・ A/B テストや計測ができるものがあります。
私のこれまでの経験や周りの話から考えても、開発リソースがボトルネックになったり、データ分析・バナー作成・実装と各ステップごとにチームが大きく分かれていたりと内部的な事情でうまく高速に PDCA サイクルを回せないといったケースは多いように思います。 KARTE Blocks はそういった場面を想定して作られているようで、いいポイントをついた製品だと感じました。
先に述べたような課題に対して、 KARTE Blocks で解決できないか・試験的に導入してみたいという動きがあり、開発側でも検討を始めていきました。実際の運用も見据えて検討を進めていくと、いくつか考慮すべきポイントが浮かび上がってきました。ここではそれぞれの項目についての調査・議論の内容とその結果決めたことについて合わせて紹介します。
🥗 KARTE Blocks の特徴
KARTE Blocks には以下のような特徴があります。
公開されている Web サイトをベースに表示内容を編集する
URL を入力してページを読み込み、最終的なレンダリング結果をもとに、 DOM を選択してその前後・置き換えに Blocks と呼ばれる UI パーツを配置するというような設定方法になります。これによってローカル開発環境を用意しなくても UI を編集・確認することができ、エンジニアでなくても操作しやすくなっています。一方で、本番環境の URL を入力して直接設定する場合が多くなると考えられ、エンジニアのローカル環境で Blocks を含めた動作検証をすることが難しくなっています。
→ 表示に関して不具合があったとき、ローカル環境で再現しない状況になりやすい。
表示対象の設定・ A/B テストによる効果検証が容易
KARTE はユーザーの行動分析・分類、それを生かしたマーケティングなどに強みを持つ製品で、標準機能として接客サービス等でユーザーセグメントを作ったり、クエリやログベースでの配信するコンテンツの出し分けを行うことができます。 Blocks は KARTE の1サービスとして提供されているため、 KARTE の同様の機能を利用し、A/Bテストやセグメント別のBlocksの出し分けを行うことができます。
→ 検証にとても使いやすい。
DOM をフックにして出し分けをする
Blocks の設定をするときの具体的な作業は、 Web サイトに表示されている DOM を選択し、それをフックにして別の UI を Blocks によって追加・編集することです。ここでフックになる DOM の特定に CSS クラスタが内部的に使われています。
→ 機能追加・変更のリリースによって DOM 構造が変わると、設定した Blocks が表示されなくなりやすい。
DOM のレンダリングにインターセプトする
DOM のレンダリングの途中に割り込んで Blocks の設定を反映するような設計になっています。反映までの間に一瞬画面がちらつくといったような挙動を防ぐような仕組みになっています。
→ サービス体験にネガティブな影響を与えにくい。一方で、意図しない表示不具合があったときに Blocks の設定ミスなのか機能実装のバグなのか一見判別がつきにくい。
個別に HTML, CSS, JavaScript を直接設定することができる
Blocks の管理画面のコード編集メニューから直接コードを書いて編集することができます。あまり複雑なコードを書くようだとソースコードの管理が別で必要になったりすると思いますが、簡単な追加や修正ならここからできてしまいます。
→ 簡単な実装ならできるけど、ベストなユーザー体験を提供しようと考えたときにはむずかしい、というか普通に実装したほうが早い。
💭 運用ルールの考え方
以上の特徴を踏まえると、普段サービス開発をしているチームにも少なからず影響は発生しそうということがわかってきました。しかしあまり運用に関して開発側からの干渉を大きくすると Blocks の良さが失われてしまいそうです。そこでなるべく小さくルールを定めて、それに沿った上でなら好きなように使って OK という運用ができたら良いと考えました。
📖 運用ルールとして定めたこと
以上の考え方を基に、以下のような運用ルールの整備をしました。
KARTE Blocks を使って表示したい内容が新しくあるときには、トリガーになる DOM に id 属性を付与する開発チケットを切る
id 属性をトリガーにして表示すれば、多少 DOM の構造が変わっても動かし続けることができます。私たちは KARTE Blocks で使われていることがわかるような id 属性を付与し、コード中にコメントを合わせて残すようにしました。開発は必要になりますが、 id 属性を付与するだけなのでかなり小さいタスクになりました。 CI で Blocks の表示まで検証するのは難しいですが、トリガーとなる id 属性をもつ DOM がレンダリングされていることを検証することで代替します。
例
// karte-blocks-mypage-header: KARTE をつかって動的に UI を追加するときのフックになる id です。削除・変更したい場合は KARTE Blocks の設定をあわせて確認してください。
<div id="karte-blocks-mypage-header">
</div>
Blocks の設定・条件づけは開発主導ではやらない
ここをエンジニアが持つと、ノーコードでいろいろできる Blocks の良さが失われてしまいます。 DOM 構造の変更によって表示されなくなったりすることが発生しない状態にできたら、その先は別のチームがやって ok としました。とはいってもまったく交流がないとそれはそれで柔軟な設定運用ができないケースが発生すると予想されるため、設定に困った場合の開発側の窓口を設けました。
検証環境でもおなじ設定をし、一度動作確認をしたうえで本番環境で設定する
Blocks の対象ユーザーを操作している者だけにすることで本番だけでも動作確認はできますが、検証環境と本番環境の乖離を小さくする取り組みの一環としてこのようにしました。ただ DB 等他の部分まで考えるとまったくおなじ環境で揃えることはコスト的にもできないため、ここを将来にわたって揃える必要があるかは議論していく必要がありそうです。
検証が終わり本格的な機能開発に入りたい場合・細部にもこだわったベストな体験を届けたい場合は、 Blocks ではなく通常の開発フローに則りすすめていく
とにかく最短で検証を行える・ほとんどコードを書かずに UI を出し分けられるというのが Blocks の良さですが、細部にこだわった UI だったり他の機能群と統合された理想的なユーザー体験を提供していくためには Blocks はベストな選択肢とは言えなそうです。その場合は Blocks にこだわらずに通常の開発フローに乗せて進めていくのが良いという確認をチーム全体でとりました。
🐧 おわりに
KARTE Blocks はとても便利である一方で、普段サービス開発をしているエンジニア側にも影響のでてくるツールでもあります。本記事では、開発側からの干渉を最小限におさえつつサービスを安定させ、スピード感を持って各種の検証等を運用していくためのルール整備を行った事例を紹介しました。今後どこまで KARTE Blocks を使っていくかはこれから決めていくべき課題でもありますが、チームをまたいで連携してワークフローを整えるといった今回のようなことは、将来発生する他の組織課題にも活かしていけると考えています。
SHE ではさまざまな専門性をもった異なる職種のメンバーが密に連携をとりながら、スピード感をもってサービス向上に取り組んでいます。もし本記事を読んで興味を持ってくださったなら幸いです。
ここまで読んでいただき、ありがとうございました。
「SHElikes(シーライクス)」を運営するSHEの開発チームがお送りするテックブログです。私たちは社会的不均衡の解決を目指すインパクトスタートアップです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 採用情報 -> bit.ly/3XxywnD
Discussion