2016年08月22日
563 Views

WordPressとGitHubのPull Requestを使って複数人でブログメディアを運用する試み

タグ:
github
wordpress
ブログ
メディア
運用

こんにちは、Unitusのimaizumeです。

Unitusが4月から発信してるこのUnitusメディア。

ここでは様々な話題で毎日様々なメンバーが記事をポストをしていますが、発足当初は複数人数でのブログ運用のノウハウがありませんでした。

例えば

  • 複数人で記事を書いたうえでチェック(校正)するにはどうするべきか
  • アイデアや記事をどのように管理すればよいか
  • ブログで記事を書いたことがない新入生のメンバーにどう伝えるか
  • そのためにどんなツールを使っていくべきか

などなどをどうするべきかについて、何も分からない状態でスタートしていたわけです。

しばらくは試行錯誤的にやってある程度うまく運用ができるようになったたものの、手動作業やムダな手順も多く、問題が発生するようになりました。

そのため7月からはよりスムーズにメディアを運営できるよう、新たにGitHubのPull Requestを使う運用方法にチャレンジしました。

今回は、Unitus内で取り入れたこの新しいメディア運用方法について、導入の経緯から実際のワークフロー、導入に当たってのメリットと障害についてポストしたいと思います。

Unitusメディアでの記事作成から公開までの流れ

Unitusでは立ち上げ当初から

  • WordPress (Unitusメディア本体)
  • GitHub (Issue管理用ツールとして使用)
  • hubot (Slackで通知するBot)
  • Slack (全体チャット)
  • Google Docs (ドキュメント管理)

といったツールを使って、コンテンツやコードを管理しており、これらのツールを使って以下の流れで記事を作成、校正した後公開していました。

古い流れ

流れをおおまかに述べると以下のとおりです。

  1. Unitusメンバーの誰かが投稿者になり、提案した記事をGitHubのIssueに登録、記事の目的や概略を記載する
  2. 準備ができたらGoogle Documentsで記事を書き始める
  3. 書き終わったたらSlackにリンクを流して他のメンバーのチェックを受ける
  4. 他のメンバーはGoogle Documentsの記事を見ておかしいと思う表現等を校正する
  5. 入れられたコメントを見て投稿者はそこを修正
  6. 上記を数回繰り返した後、リーダーの最終チェックを受ける
  7. Google Documentsで書いた記事(テキストのみ)をコピーしてWordpressの投稿に貼り付け、画像を再度アップロード
  8. プレビューして問題がなければ予約投稿して完了

また書くときの条件は

  • 記事は必ずメンバーから校正を受ける
  • HTMLではなくMarkdown記法で書く (HTMLは複雑でスタイル崩れの原因にもなる
    ため)
  • 毎記事に文章の「フォーマットを確認する(1文字の数字は半角、リーダーは半角ドット3つなど)」や「アイキャッチを設定する」といったTODOがある

などがあります。

運用における問題点

発足当初は上記の方法で問題はありませんでしたが、次第に幾つかの問題点が浮き彫りになりました。

1. Slackへの通知やGitHubへのリンクが全て手作業

Google DocumentsとSlackに連携機能はなかったため、校正する側もされる側も、全て手作業で通知をする必要がありました。

加えてサービスが分散していたため

  • GitHubのIssue
  • WordPressのURL
  • 記事の校正依頼

Slack上で全て個別に通知されていました。 通知といってもURLをコピペすれば良い程度のものですが、回数が増えると手間に感じるものです。

また記事を書いたのに通知をし忘れて校正が進まないといったことも起きていました。

通知忘れ

2. 校正待ちの記事がひと目で分からない

現在校正待ちの記事はどれなのか?という疑問に答えられるような、ひと目で分かる場所もありませんでした。

そのためメンバーからの校正依頼通知があっても、投稿者の発言をスターするか、毎回検索窓から「校正」「コメント」などの単語で検索した結果からリンクを踏む必要がありました。

通知

さらに、最初に作成したアイデアが書かれたISSUEとのリンクが貼られてないため、記事の目的や意図が見えず校正に必要な情報が参照できない状態でした。

チームが大きくなると、個人の独断で普段と違うチャンネル (#general等)に通知することもあり、さらに情報が分散する結果となりました。

3. 校正のGoogle Docsの公開設定を間違えて直るまでコメントできない

Google Documentsでは、文書ごとに公開範囲や可能な操作が設定できるようになっています。

しかしデフォルト設定ではこれが「閲覧のみ可能」となっていたため、せっかく校正しようと思った人が見てもコメントを付けられないという「事件」が多々発生していました。

公開設定1

公開設定2

4. Google DocumentsではMarkdownのプレビューができない

Google DocumentsでMarkdownを書いても、プレビュー表示ができず実際にどう表示されるかがWordpressに記事を移すまで分からないという問題もありました。

さらにMarkdown記法に慣れていないメンバーも多いため、分からなくなるとHTMLタグを使用してしまい勝手に個別のスタイルが適用される原因にもなっていました。

5. 画像の再アップロード問題

Google Documentsで校正した記事は、最終的に手動でWordpressへコピーしていましたが、画像はテキストと違ってWordpressへはそのままコピーされません。

従ってテキストをコピーした後、さらに画像をアップロードし直す必要がありました。

運用方法の改善提案

そこでimaizumeを含むUnitusメディア技術部 (エンジニアチーム)が中心となり、校正方法やツールの見直しに乗り出しました。

改善策にはいくつかの案が浮上しましたが、最終的には Google Documentsを廃止し、代わりにGitHubのみで校正を完結させるという方針を採用することにしました。

元々有名なWebエンジニアの方さんが、技術雑誌に書く記事を編集社の方とPull Requestで校正しているという話を聞いていたので、実績があるということで採用することにしました。

詳しくはこちらを御覧ください

Github を使って雑誌原稿を書く – naoyaのはてなダイアリー

改善後の運用の流れを示すとこのようになります。

新しい流れ

  1. Unitusメンバーの誰かが投稿者になり書きたい記事を提案 (同じ)
  2. 提案した記事をGitHubのIssueに登録し、記事の目的や概略を記載する (同じ)
  3. GitHub上で記事ごとに新しいブランチを作成
  4. リポジトリのルートにブラウザ上で新しいMarkdownファイルを作成し、Markdownに記事を書いてコミット
  5. 続けて今のブランチからPullRequestを作成し、コメント欄に最初の手順で作ったIssueへの番号を記入
  6. PullRequest作成はSlackへ自動で通知され、ページに行けば一覧表示される1.コメントをいれる場合はコードレビューの用に行内にコメントをつけていく(これもSlackへ自動通知)
  7. 画像だけは一度WordpressのメディアアップロードでアップしてからリンクをMarkdownへ埋め込む
  8. 校正が完了したら全コピーでWordpressへ移して予約投稿し完了

その結果、前述のほとんどの問題点が解消されることになりました。

1. 全イベントがSlackへ自動通知され、Issueとの相互リンクも簡単に

通知

元々あったGitHubのリポジトリからはSlackへ自動で通知が飛ぶようになっていたので、この運用方法になってからは記事(Pull Request)の作成、記事の更新、コメント、close全てが自動で通知されるようになりました。

またGitHubでは、#つきで番号を書くと自動的にその番号のIssueやPull Requestと相互にリンクが貼られます。

これと後述するPull Requestテンプレートを使ったことで、記事とIssueのひも付けが圧倒的に楽になりました。

2. Pull Requestページでまとめて校正待ちの記事が見れる

校正一覧

校正待ちの記事はPull Request一覧から見れるようになったので、参照場所が統一されました。

しかしそれでも「いちいちGitHubのページへ行かないと一覧表示ができないのは不便」と思ったので、別途hubotにGitHub上のPull Request一覧を取得させる機能を実装し、毎日朝と夕方に定期で専用チャンネルに通知するようにしました。

taro

その結果として、情報がほぼ一箇所に集約され校正する人もいちいち通知を検索する必要がなくなりました。

3. GitHubでは公開範囲の設定がない

そもそもリポジトリ自体に入れれば、ファイルごとの閲覧権限という設定はないので、このミスをすることは必然的になくなりました。

4. GitHubではMarkdownのプレビューが可能

プレビュー

嬉しいことに、GitHubにはMarkdownファイルをその場でプレビュー表示できる機能があります。

そのため、Wordpressに記事を移す前に、おおまかな表示のされ方が確認できるため、フォーマットの記述ミスや見出し、リンクの貼り方などの間違いに気付きやすくなりました。

さらにMarkdown記法に慣れていない人でも、その場で見て確認ができるので練習しながら書くこともできますね。

5. 画像の再アップロードは不要に

画像だけは、どうしてもGitHub上でドラッグアンドドロップでの挿入ができません。

そこで画像は事前にWordpress側でアップしたうえで、そのURLをコピーしてMarkdownへ挿入してもらいました。

Markdownでは細かい表示サイズの指定はできませんが、Wordpressには画像エディタが付属しているのでここでトリミング等すれば良いわけです。

その結果、校正段階からWordpressに画像がアップされているため再アップロードが不要になり、全コンテンツをCtrl + A, Ctrl + Vでそのまま投稿に持っていけるようになりました。

さらに上記以外にこんなメリットも。

過去からの変更が全て見通せる

commit log

記事の修正箇所が時系列でわかり、やったつもりで見落としがあった場合もすぐに指摘できます。

また進捗が見えるうえ、Slackに通知されるため心理的な安心感(焦燥感)が得られます(笑)

ブラウザ上で完結

ブラウザ

「GitHubはコマンドを覚えないと使えない…」と思われがちです。そのため、非エンジニアの方々にGitHubを使ってもらうのは難しいと考える方もいるようです。

しかし現在はオンラインでファイルを追加したり編集したりする機能があるので、コマンドを使わずにGitHubでファイルを操作出来るようになっています。

これを使うことで、非エンジニアでも手順さえ覚えてもらえば簡単にGitHubでファイルのコミットが行えるわけです。

IssueテンプレートとPull Requestテンプレート

Pull Requestテンプレート

GitHubにはIssueテンプレートとPull Requestテンプレートと呼ばれる機能があります。

端的に言うと、IssueやPull Requestを新規作成した場合にデフォルトで挿入される文面をテンプレとして作ることが出来るというものです。

例えば Issueには記事の締め切りや担当者を入れる欄を、Pull Requestにはチェック項目や#記号を入れておくことで、最低限入れるべき情報の記入漏れを防ぐことができます。

導入にあたっての障壁

一方良いことがある分、いくつかの課題もありました。

GitHub上で起こっていることが感覚的に分かりづらい

メンバーの多くは、これまでISSUEの管理ツールとしてGitHubを使ったことはあったものの、ファイルののコミットやPull Requestには触れたことがありませんでした。

そのため、守るべき手順として「こうすれば良い」ということは分かっていても、実際にPull Requestが何をしているのかを体系的に理解してもらうには至っていません。

従って今後の勉強会や講習などで、より体系的にGitやGitHubの使い方を伝えていく必要があると思いました。

まとめ

以上、Pull Requestを使った新しいブログの運用方法について紹介しました。

hubotからGitHubを参照する部分の実装は、既にインターフェースが用意されていたため思ったほど工数はかかりませんでした。

しかしまだはじまったばかりなので、今後も新たな問題が出てくる可能性はあります。

また自動化できる部分は他にもあると思っていて、例えば数字や特定の表現に関するフォーマットの校正はCIを使ってブランチにテストを走らせることも技術的には可能かと思います。

今後の動向を見守りつつ、上手く行けば一つのノウハウとして続けていきたいと思います。

合わせて読みたい