こんにちは！半年ぶりにお手伝いしに戻ってきました、辻@dim0627です。
戻ってきたのに歓迎会がないので多分そういうことなんだろうと思います。
この度、リスタではアルバイト探しのためのジョブリストに加えて、読み物としてのジョブリストマガジンをリリースしました。
やったのはこんな感じのこと。
- コンテンツのニーズ・インテント調査
- ライティングルール策定
- 記事構成作成
- ライター様への依頼
- 記事入稿
- デザイン
- インフラ構築
- 開発
というわけで、ここ2週間くらいの話をまとめてみます。
こんな感じでディレクションしました
今回は「じゃあメディア作って」って言われてからどんなふうに進めたかのお話をしようかと思います。
分業はこんな感じ。
- ジョブリスト編集部: ライター様への依頼、やり取り
- @mikeda: インフラ
- 辻: デザイン、開発、ディレクション
弊社には強靭な編集部隊がいるので、ライティングはそちらのライター様たちにお願いしました。
ライティングルールの策定
なにはともあれライティングルールが必要です。 ライター様との認識の齟齬をなくして円滑に進めるためにも。
弊社のライティングルールはちょっと社内に留めさせていただきますが、株式会社WEB企画の@mizunodayoさんの以下記事などが参考になると思います。
社内ライターさん向けライティングマニュアルを公開します。 - アフィリエイト戦記
この辺はライター様と何をどう分業するかにもよるので、組織によってきちんと設計したほうがいいです。
ライティングフローの策定
弊社ではコンテンツを細かくコントロールしたかったので、以下のようなフローでライター様とやり取りしています。
- （社内）ニーズ調査
- （社内）対象ニーズの記事タイトル、見出し設計
- （ライター様）リード文と各段落のライティング、必要であればタイトルと見出しの改善
- （ライター様）納品
これはこちらが求めている記事をできるかぎり齟齬なく伝えるためのフローで、正直社内の人的コストはかなり高めです。
ただ、ライター様もみなプロとして仕事をしてくださってるので、タイトルや見出しも自由に変えてくださいと伝えてあります。 個人的に、ライター様を信用し敬意を払うのはとても大切なことだと思ってます。
ニーズ・インテント調査
ライティングフローにあるとおり、まずユーザはどんな悩みを持っているのかを調査しました。
ここではいろんなツールを使いますがちょっとここでは省きます！ たぶん定番どころです。
余談ですが、SEOとかでこんなツール使ってるよみたいなのを知る手段がほしくて、なんかそういう集まりとかあれば誘ってください。 まあでもあんまり教えたいものでもないか。
記事構成の作成
調査したニーズに応じて、どんな構成と記事でアプローチすればユーザのニーズに応えられるかをここで決めます。
僕のやり方だとキーワードごとにスプレッドシートでまとめてる感じです。
まず注力する領域の選定
必要なコンテンツがわかったとしても、人的リソースは限られてるのでじゃあ全部作っちゃおうぜ！というわけにはいきません。
もっとも大きなニーズのクラスタはおそらく4,5個に絞られるはずなので、その中でまず何から着手するかを決めました。
弊社のライター様の数であれば2つくらいのクラスタは攻められそうだったので、まずは面接と履歴書に関するコンテンツを作る判断をしました。
プロットの作成
各ニーズに必要な記事がわかったら、それぞれの記事でどんなタイトルでどんな見出し構成があればいいかを決めます。
Webメディアでは見出ししか読まれない事が多いので、見出しだけ読まれても意味が通じる構成になるようにしています。 見出しが結論、段落が補足、くらいのスタンスです。
また、個人的に大切にしているのが、
各記事がそれぞれで完結し、またそれぞれが補完し合う
というちょっと矛盾した関係で、ディレクター（僕）がその関係を把握できるように努力しています。
これが意識されていれば、自然な内部リンク構造がおのずと作り上げられていきます。
プロットまで作ったらスプレッドシートをそのまま依頼します。
納品チェック、継続に必要な資料の作成
ライター様から記事があがってきたら、こちらが求めているものか、ライティングルールに則っているかを確認します。
こちらの意図と違うものなどがあれば、自分で直してしまわずに、できるだけライター様に「なぜそうしてほしいのか」を伝えて直してもらうようにしています。
メディアの運営はライター様の信頼関係と円滑なやり取りが肝です。 信頼関係を築きつつ、こちらのやりたいことを理解してもらうことに注力します。
随時質問などもあがってくるので、よくある質問などは随時ライティングルールに追記し、組織として継続できる体制を作ります。
テクニカルSEO的に考えたこと
メディアはとにかく立ち上げればユーザにリーチするっていう銀の弾丸ではないので、ユーザニーズに加えて技術的なSEOでフォローできる部分はしていくべきだと思ってます。
コンテンツSEOに関してはちょっと余白が足りないし技術ブログなので筋違いだし、ここではテクニカルSEOでやったことをさらっとまとめてみます。
カテゴリはリスクを承知でナイーブツリーに
メディア系コンテンツに限らず、カテゴリ設計って結構困ることが多いと思うんです。
- 複数の親に属したいカテゴリが出てきた
- 階層がどこまで深くなるかわからない
- 何が最上位の親カテゴリになるべきかわからない
- この記事はどのカテゴリに入るんだ（「その他」カテゴリ問題）
みたいな。
まあ1番目はどうしょもないんで設計をちゃんとやれよって感じなんですが、それ以外は自己参照するDB設計にすれば解決するので今回はその設計を採用してます。
その他カテゴリ問題に関しても、「どの階層のカテゴリにも紐付けられる」ようになるので問題ありません。
しかしこれは完全にDBのアンチパターンに踏み込んでるので、@t_wadaさんの資料に発リンクさせていただきますね。
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン、バイブルのように扱ってます。とてもいい本です！
自己参照するモデルの実装
基本的にスピード感が必要な組織ではライブラリをうまく選定して開発コストを落とす方針がベターだと思うんですが、 こういったアンチパターンに踏み込むときにはそのジャッジの観点は少し変わるんじゃないかなと思ってます。
個人的に、ビジネスで丁寧に選ぶべきライブラリがあるときは、決められた選定基準 + メンバーの誰かが利用経験のあるライブラリのみにする、というルールで選定しています。
今回使ったライブラリはawesome_nested_setです。
基本的にめちゃくちゃ複雑なことをやるわけでないのであれば、特にハマりどころはないかと思います。
例えば、紐づくカテゴリの祖先を引くとかになると一覧系でn+1が避けられなかったりしますが（アソシエーションを追加すればなんとかなる）、今回の要件ではその仕様がない見通しがあったので採用を決めました。
以前別の組織でライブラリ選定をしたときに以下と比較していたのですが、最終メンテが古かったりオーバースペックだったりして採用しませんでした。
stefankroes/ancestry: Organise ActiveRecord model into a tree structure
カテゴリごとに説明文を持てるように
一覧ページって、SERPsからランディングしたときに「何このページ」ってなることが多いかなと思うんですよね。個人的に。
なので、カテゴリごとに説明文をもたせて、一覧ページにカテゴリの名前と説明文を表示することでユーザがそのページが何なのかを理解しやすいようにしました。
ま、これは建前でSEO的にあったほうが調整しやすいってのが本音なんですが。
タグは作りたかったけどニーズ調査の時間がなかった
タグって今んとこカテゴリで事足りるんじゃ？っていうぐらいの認識で、それってきっと僕がニーズ調査を深くできてないからかなと思いタグは作るのをやめました。
将来的にはユーザにリーチする1つの経路として作りたいとは思ってます。
検索機能は後回し
ユーザニーズ的にはあるに越したことは無いと思うんですが、ちょっとリリースを優先して実装はしませんでした。
この辺の、機能に関する取捨選択はかなりリリース優先で動いたかなーという感じです。
AMP対応
まあ記事コンテンツならとりあえずやっとく価値あるので。シンプルなページなら2時間くらいで実装できるし。
ところでcssのインライン出力にこんなことやってるんですが、なんかいい方法知ってる人いませんか？？
def stylesheet_amp_custom_tag(path) Webpacker.compile if Rails.env.development? # なんか開発環境だと読めない！！！ body = File.read(Rails.root.join('public', path.slice(1..-1))).remove('!important') "<style amp-custom>#{body}</style>".html_safe end
技術系のあれこれ
Ruby2.5.1のRails5.2.0です。
はじめはJOBLISTのRailsプロジェクトに突っ込もうかと思ってたんですが、@mikedaさんと相談して新しくしちまおうぜということでrails newしました。
スタックはJOBLISTと基本同じで、
- unicorn
- MySQL5.7
- haml
- webpacker
- ES6
- cssnext
な感じです。cssnextだけリスタでは初ですね。
なぜcssnext？
昨今の事情は知らないんですが、
- webpackerでSass(SCSS)を処理するの遅くてやだ
- でもwebpackerならwebpackerで完結させたい
- フォントファイルとかを含むライブラリを使うときに楽なので
- cssnextのフォールバックがすごくいい
- remをpxにしてくれるのすき
- autoprefixerも入ってるし
- webpacker:installするだけで使えるのも楽
Sass(SCSS)に比べて辛いのは以下くらいですかね。
- &記法がめんどう
- たんなるネストでも&が必要
- 変数の呼び出しがめんどう
- var(--color-main)みたいな
- extendぽいことはできてもmixin的なことはちょっときつい
終わりに
再度ジョインして二週間かからずに正式リリースまで行けたのは胸を張って良いことかなと思います！
とはいえサービスはすべてユーザのためにあるもの。 ジョブリストマガジンを、アルバイト探しをしている人の悩みをすこしでも解決できる存在にしていきます。
オープンな募集もいくつかあるので、もし興味ある人がいたらぜひお声がけください〜！
