navigationUnitus-「知」をもっと、「理」をぎゅっと。Requestを使って複数人でブログメディアを運用する試みタグ:githubwordpressブログメディア運用こんにちは、Unitusのimaizumeです。Unitusが4月から発信してるこのUnitusメディア。ここでは様々な話題で毎日様々なメンバーが記事をポストをしていますが、発足当初は複数人数でのブログ運用のノウハウがありませんでした。複数人で記事を書いたうえでチェック(校正)するにはどうするべきかアイデアや記事をどのように管理すればよいかブログで記事を書いたことがない新入生のメンバーにどう伝えるかそのためにどんなツールを使っていくべきかなどなどをどうするべきかについて、何も分からない状態でスタートしていたわけです。試行錯誤的にやってある程度うまく運用ができるようになったたものの、手動作業やムダな手順も多く、問題が発生するようになりました。Requestを使う運用方法にチャレンジしました。今回は、Unitus内で取り入れたこの新しいメディア運用方法について、導入の経緯から実際のワークフロー、導入に当たってのメリットと障害についてポストしたいと思います。(ドキュメント管理)といったツールを使って、コンテンツやコードを管理しており、これらのツールを使って以下の流れで記事を作成、校正した後公開していました。流れをおおまかに述べると以下のとおりです。(HTMLは複雑でスタイル崩れの原因にもなるため)毎記事に文章の「フォーマットを確認する(1文字の数字は半角、リーダーは半角ドット3つなど)」や「アイキャッチを設定する」といったTODOがあるなどがあります。発足当初は上記の方法で問題はありませんでしたが、次第に幾つかの問題点が浮き彫りになりました。DocumentsとSlackに連携機能はなかったため、校正する側もされる側も、全て手作業で通知をする必要がありました。加えてサービスが分散していたためGitHubのIssueWordPressのURL記事の校正依頼はSlack上で全て個別に通知されていました。通知といってもURLをコピペすれば良い程度のものですが、回数が増えると手間に感じるものです。記事を書いたのに通知をし忘れて校正が進まないといったことも起きていました。校正待ちの記事がひと目で分からない現在校正待ちの記事はどれなのか?という疑問に答えられるような、ひと目で分かる場所もありませんでした。そのためメンバーからの校正依頼通知があっても、投稿者の発言をスターするか、毎回検索窓から「校正」「コメント」などの単語で検索した結果からリンクを踏む必要がありました。最初に作成したアイデアが書かれたISSUEとのリンクが貼られてないため、記事の目的や意図が見えず校正に必要な情報が参照できない状態でした。(#general等)に通知することもあり、さらに情報が分散する結果となりました。Documentsでは、文書ごとに公開範囲や可能な操作が設定できるようになっています。デフォルト設定ではこれが「閲覧のみ可能」となっていたため、せっかく校正しようと思った人が見てもコメントを付けられないという「事件」が多々発生していました。DocumentsでMarkdownを書いても、プレビュー表示ができず実際にどう表示されるかがWordpressに記事を移すまで分からないという問題もありました。Markdown記法に慣れていないメンバーも多いため、分からなくなるとHTMLタグを使用してしまい勝手に個別のスタイルが適用される原因にもなっていました。Documentsで校正した記事は、最終的に手動でWordpressへコピーしていましたが、画像はテキストと違ってWordpressへはそのままコピーされません。従ってテキストをコピーした後、さらに画像をアップロードし直す必要がありました。(エンジニアチーム)が中心となり、校正方法やツールの見直しに乗り出しました。Documentsを廃止し、代わりにGitHubのみで校正を完結させるという方針を採用することにしました。Requestで校正しているという話を聞いていたので、実績があるということで採用することにしました。改善後の運用の流れを示すとこのようになります。(同じ)GitHub上で記事ごとに新しいブランチを作成リポジトリのルートにブラウザ上で新しいMarkdownファイルを作成し、Markdownに記事を書いてコミット続けて今のブランチからPullRequestを作成し、コメント欄に最初の手順で作ったIssueへの番号を記入PullRequest作成はSlackへ自動で通知され、ページに行けば一覧表示される1.コメントをいれる場合はコードレビューの用に行内にコメントをつけていく(これもSlackへ自動通知)画像だけは一度WordpressのメディアアップロードでアップしてからリンクをMarkdownへ埋め込む校正が完了したら全コピーでWordpressへ移して予約投稿し完了その結果、前述のほとんどの問題点が解消されることになりました。Request)の作成、記事の更新、コメント、close全てが自動で通知されるようになりました。Requestと相互にリンクが貼られます。Requestテンプレートを使ったことで、記事とIssueのひも付けが圧倒的に楽になりました。Request一覧から見れるようになったので、参照場所が統一されました。Request一覧を取得させる機能を実装し、毎日朝と夕方に定期で専用チャンネルに通知するようにしました。その結果として、情報がほぼ一箇所に集約され校正する人もいちいち通知を検索する必要がなくなりました。GitHubでは公開範囲の設定がないそもそもリポジトリ自体に入れれば、ファイルごとの閲覧権限という設定はないので、このミスをすることは必然的になくなりました。嬉しいことに、GitHubにはMarkdownファイルをその場でプレビュー表示できる機能があります。そのため、Wordpressに記事を移す前に、おおまかな表示のされ方が確認できるため、フォーマットの記述ミスや見出し、リンクの貼り方などの間違いに気付きやすくなりました。Markdown記法に慣れていない人でも、その場で見て確認ができるので練習しながら書くこともできますね。画像の再アップロードは不要に画像だけは、どうしてもGitHub上でドラッグアンドドロップでの挿入ができません。そこで画像は事前にWordpress側でアップしたうえで、そのURLをコピーしてMarkdownへ挿入してもらいました。Markdownでは細かい表示サイズの指定はできませんが、Wordpressには画像エディタが付属しているのでここでトリミング等すれば良いわけです。Vでそのまま投稿に持っていけるようになりました。上記以外にこんなメリットも。過去からの変更が全て見通せる記事の修正箇所が時系列でわかり、やったつもりで見落としがあった場合もすぐに指摘できます。「GitHubはコマンドを覚えないと使えない...」と思われがちです。そのため、非エンジニアの方々にGitHubを使ってもらうのは難しいと考える方もいるようです。現在はオンラインでファイルを追加したり編集したりする機能があるので、コマンドを使わずにGitHubでファイルを操作出来るようになっています。これを使うことで、非エンジニアでも手順さえ覚えてもらえば簡単にGitHubでファイルのコミットが行えるわけです。Requestテンプレートと呼ばれる機能があります。Requestを新規作成した場合にデフォルトで挿入される文面をテンプレとして作ることが出来るというものです。Requestにはチェック項目や#記号を入れておくことで、最低限入れるべき情報の記入漏れを防ぐことができます。良いことがある分、いくつかの課題もありました。Requestには触れたことがありませんでした。Requestが何をしているのかを体系的に理解してもらうには至っていません。従って今後の勉強会や講習などで、より体系的にGitやGitHubの使い方を伝えていく必要があると思いました。Requestを使った新しいブログの運用方法について紹介しました。hubotからGitHubを参照する部分の実装は、既にインターフェースが用意されていたため思ったほど工数はかかりませんでした。はじまったばかりなので、今後も新たな問題が出てくる可能性はあります。自動化できる部分は他にもあると思っていて、例えば数字や特定の表現に関するフォーマットの校正はCIを使ってブランチにテストを走らせることも技術的には可能かと思います。今後の動向を見守りつつ、上手く行けば一つのノウハウとして続けていきたいと思います。考えよう!この記事を書いた人imaizume野田キャンパスに通い続けて気づけばもう7年目。若手のメンバーに日々元気をもらいながら、学生生活最後の年を駆け抜けています。