【マーケ×開発で業務改善】月100本の記事を作成するコンテンツチームの入稿フローを改善
当ブログをご覧いただきありがとうございます。エンジニアの高橋です。
今回のブログは『マーケティング部と開発部でタッグを組んで業務改善する』という内容です！
月100本作成するコンテンツチームの入稿フローを改善しました！
取り組みの背景
ユーティルではマーケティング部の新記事チームが毎月100本もの新記事をリリースしています。
ユーティルでは幹事シリーズというマッチングサービスを11種類運営しており、コンテンツマーケティングを行う上で記事の質と量を大切にしています。
新記事チームでは『月間100本の新記事作成』をKPIとして設定しています。
マーケティング部の活動に関してはこちらもご覧ください。
今回の課題について
今回の課題は『記事の入稿工程の改善』です。
ざっくり言うと、記事原稿を作成してから公開できるように原稿内容を登録する工程を短縮できるかという内容です。
【『AIを業務に取り入れられるか試してみる』から抜粋】 新規時作成のフローを整理する中で、いくつかの改善できそうなポイントが見えてきました。
- 作成する記事のキーワード選定
- 難易度：中
- 100記事分のキーワード選定で新記事作成チームとして10時間 / 月の作業時間
- 記事構成の作成
- 難易度：中
- 3～5時間 / 1記事、100記事分で新記事作成チームとして300～500時間 / 月の作業時間
- 入稿
- 難易度：低
- 管理画面からwysiwygエディタで入稿
- 30～40分 / 1記事、100記事分で新記事作成チームとして50～66時間 / 月の作業時間
これまでの運用では、
- 原稿をGoogle Docsで作成
- 新記事作成用ページのエディタにてGoogle Docs上で完成した原稿内容を反映
という流れでした。
コピー＆ペーストで持って来れる部分もありつつ、Google Docs側で設定されているタグ情報などを丸ごと持ってくることによる表示ズレの修正などが発生しており、1記事あたり平均で30〜40分ほど入稿する工程で掛かってしまっていました。
月100本新記事をリリースする換算だと、新記事作成チームとして約50～66時間 / 月の作業時間が発生していたため改善に向けた取り組みが必要な状況でした。
改善への取り組み
課題解決方法の模索
入稿工程効率化を図る上で、どこで何の処理を行うべきかの話から決めていく必要がありました。
- Google Docs上で記事本文となる箇所を整形してコピー＆ペーストができるようにChrome拡張機能を開発する。
- Google Docs APIなどを使って記事をDBに登録できるようにする。
- 新記事作成画面などでGoogle Docsを読み込めるようにする。
- 原稿をGoogle Docsではなく、管理画面上で作成できるようにする。
様々な案が出た中で今回は『新記事作成画面などでGoogle Docsを読み込めるようにする』ことで入稿効率を改善する方針に固めました。
判断指標としては、以下の点が挙げられます。
- 原稿用テキスト作成に関しては業務提携しているライターさんが行うケースもあるため、原稿作成の工程自体を変えると影響範囲が大きい可能性がある。
- マーケティング部や業務提携しているライターさんが使用しているOSやブラウザ、拡張機能などを網羅した対応を考えると、Chrome拡張機能の動作保証コストが高くなってしまう。
- Google Docsはcanvasタグで表示されているため、テキストや画像ファイルなどの形式で取り出すための実装コストが高くなりそう。
要件の確定と実装
『新記事作成画面などでGoogle Docsを読み込めるようにする』をより正確に表すと、『Google Docsで作成した原稿をzipファイルとしてダウンロードし、そのzipファイルをアップロードする』と言う要件に落とし込みました。
zipファイルとしてダウンロードする工程を挟むことで以下のようなメリットがあります。
- HTMLとして出力される。
- HTMLパースを行えるようになる。(PHPのDOMXPathで操作ができるようになる)
- メニューバーで各行の内容を「見出し1」「タイトル」など適切に付与することでタグ判別が行いやすくなる。
- 記事内に登場する画像もcanvasタグではなく画像ファイルとして出力される。
- 記事内の画像はメディアファイルとしてAWSのS3に登録する工程で扱いやすい。
Google Docs上でタイトルとして設定すると・・・
zip内のHTMLでpタグにclass=”title”と言う形で割り振られます。
※titleタグにはGoogle Docsのファイル名が割り振られるので注意してください。
入稿工程を書き出すと以下のような流れになります。
- 対象の原稿記事のGoogle Docsを開き、「ファイル」→「ダウンロード」→「ウェブページ(.html、zip)」からzip形式でダウンロード。
- zipファイルを管理画面からアップロード
- バックエンド側でzipファイルを展開し、HTMLファイルにパース処理を行う。
- 記事本文のテキスト内容を取り出しつつ、zip内のimagesフォルダの画像ファイルをメディアファイルとしてS3に追加。
- 本文内のimgタグのsrc属性を置換した後、新記事として本文箇所のHTMLをDBに登録。
- 新しく登録した記事の編集画面へリダイレクト。
HTMLパース処理での記事タイトル取得の例です。
※対象HTMLファイルはstorage内に格納する形で書いているので環境に合わせて読んでください。
HTMLパース用ライブラリを入れるかどうか実装前に議論して、今回は標準クラスのDOMXPathで実装しています。
(改めて公式ドキュメントをしっかり読み込むいい機会になりました)
効果測定
zipファイルのアップロードから記事の登録までは数秒〜10数秒程度で完了し、CSS装飾などをGUIで行ったりCTA用のボタンを追加で挿入などを加味しても10分程度で完了するとのレビューをいただいています。
1記事に掛かる時間 × 月100本 = 月間の入稿作業時間の式となるため、
導入前：1記事あたり30～40分 × 月間100記事 = 約50～66時間 / 月の作業時間
導入後：1記事あたり10～20分 × 月間100記事 = 約16.5～33時間 / 月の作業時間
入稿作業に掛かる工程が時間ベースで約50％〜66％削減できているため、効果があると言える結果だと思います。
記事本数が今後も増えていくことを考えると、これから効果を発揮する機能だと捉えています。
今後の改善点
入稿する段階で「CTAボタンの設置などに規則性があるか」といった点については既にヒヤリングしており、機能改修を進めることでまだまだ作業時間の短縮の余地はありそうなので、新記事チームと共に開発を進めていきます。
また、今回の施策を通じてマーケティング部側が抱いている新機能や既存機能の改修の要求について、部署の垣根を超えて話し合うきっかけになっています。
これまで「関係部署で起案して、開発側に依頼する」という社内受託状態だった段階から「開発部と関係部署でスクラムを組んで要求分析の段階から踏み込んで課題解決を進める」というように能動的に業務フローの改善ができるのは、強い組織になっていく上で必要なことなので、今回のような動き方を開発部全体としてできるような体制作りができるようにしていきます。
まとめ
費用対効果などを考えた上でどうやって課題を解決していくかを考えるのが個人的に好きなんだなと改めて認識できた意味でも、良い施策に携われたなと思いました。
- 業務改善へのアプローチ視点を持つ。
- 開発内の色んなタスクに優先順位をつけながら物事に取り組む。
- 費用対効果やメリット / デメリットなどを考えながら開発する。
こういった視点を持っている人だと、色々チャレンジできる環境だと個人的には感じています。
「人生の中で働いている時間の割合は大きいからこそ、仕事自体に目的など持って楽しめるか」という話を入社時に言われたことを今回の施策に取り組みながら思い出していました。
(ユーティルに入社して一番最初に言われたことで、個人的にずっと頭に残るいい言葉だと思っています)
『楽しみながら課題解決にアプローチしたい』という方と、カジュアル面談でお話だけでもできる機会を頂ければ幸いです。