編集部GitHub化計画第2回：「関係者が集まる」×「情報が集まる」ために必要な仕組み

Findy Engineer Labのゆでたまご（@f43a9a）です。いつもお世話になっております。

前回のあらすじ

テック系メディアの記事制作にまつわるあれこれを、なるべくGitHubで完結できないだろうか？
やるぞ！
どうしたらいいのか分からないぞ！
有識者に相談しよう！

というわけで、ITエンジニアリングを活用した技術系書籍づくりに豊富な経験があり、現在は株式会社はてなでエンジニアとして働いている武藤健志さん（@kmuto）から、こんなアドバイスをいただきました。

GitHubを使って編集部の記事制作の運用を効率化するという大目標のためには、最初から最後までテキスト形式コンテンツを中心にすること、関係者皆が自然にGitHubを見たくなるようにそこに情報が集まっていること、という2つの中目標の達成を考えてみるとよいでしょう。

今回は、この2つの中目標について考えてみたいと思います。

最初から最後までテキスト形式コンテンツを中心にすること

結論から言うと「テック系Webメディアであれば、この目標は考えなくてもまず大丈夫。自然とテキスト形式が中心になる」と思います。

Webコンテンツの“主体となる要素”を考えてみましょう。YouTubeであれば動画がメイン、TogetterならSNS投稿。マンガ配信サイトの場合は、画像が主体となります。それぞれに適切なツールやシステムがあるはずで、GitHubと相性がいいのはテキスト主体のコンテンツだろう、というのが武藤さんの指摘。

テック系Webメディアのコンテンツでメインになるのは、文章やソースコードでしょう。画像や動画、SNS埋め込みなどがそれほど多くなることはないはず。また、レイアウトが複雑な紙媒体のように、PDFファイルを使って校正することもまずないと思います。

GitHubに備わっているドキュメントやソースコードを管理する仕組みで、十分対応できるのではないでしょうか。

関係者皆が自然にGitHubを見たくなるようにそこに情報が集まっていること

ある程度体制が整っている編集部ならどこでも、“制作中の記事情報が集約されたツール”のようなものがあると思います。例えば、「制作中」「レビュー中」「制作完了」とリスト分けされていて、各カードに担当者がアサインされているTrelloとか、そういったものです（しっかり作り込むと、もっと複雑になると思いますが）。

そこだけ見れば全体状況が把握できるような環境は一見便利そう。しかし、情報が集約されているからこその不便さもある、というのが筆者の認識です。経験則になってしまうのですが、「関係者が集まる」×「情報が集まる」という掛け合わせは意外と相性が悪いと思うのです。

というのも、当たり前ですが、情報を集約してしまうと「一部の情報しか見せたくない関係者」に対して権限を出しにくくなります。Webメディアでいうと、具体的には社外のライターやカメラマン、取材を受けてくださる方など。その人たちには、その人が関わっている記事の進行状況だけを伝えたいのです。

結果として、“制作中の記事情報が集約されたツール”は編集部員専用になり、それ以外の関係者には編集部からDMやメール、Slackなどを使って個別に連絡し、必要な情報だけを共有する――こうなってしまうと手間がかかりますね。せっかく1箇所に集めたものを、わざわざバラバラにしてあちこちに届けているようなものですから。

筆者は上記のような課題認識から、“制作中の記事情報すべてが集約されたスプレッドシート”をベースに、クエリ関数を使って“担当者ごとに個別の記事情報だけが表示されるシート”を作ったことがあります。

こういうカスタマイズをサクッとできるのがスプレッドシートのうれしいところ。しかし、Trelloなどと違ってチャット機能がなく複雑なやり取りが難しいという欠点があり、別のツールでコミュニケーションを取る必要がありました。

そうなると何が困るってスプレッドシートと、DMやメール、Slackといった連絡用のツールに情報が分散しちゃうんですよ。そんでもってトラブったときに、つまり、もっとも速やかに正確な情報を把握したいときに、スプレッドシートに加えてメールまでたどる必要が出てきて、でも全然見つからなくて。担当者に聞いてみたらうっかりCCを付け忘れていたことが分かって。会社員としてはやっぱり再発防止策を考えるわけですけれども、うっかりに対しては究極的には「気を付けようね」以上の対策が取れないと思うので、どうしたもんかなってゴニョゴニョして……。

すいません、話が少々長くなりました。情報はただ集めるだけだと意外とうまく機能しなくて、それを使う人のための工夫が必要。具体的には適切なフィルタリングと、理解を促すコミュニケーションの仕組みが必要ではないか、と思っています。

「関係者が集まる」×「情報が集まる」のために必要な仕組み

さて、このような問題をクリアして、「関係者皆が自然にGitHubを見たくなるようにそこに情報が集まっている」状況を作るにはどうすればいいか。

以上の議論をまとめると、以下の通りです

記事の制作進行状況にまつわる情報が集約できる。
必要な人に必要な情報だけ見せられる（権限がコントロールできる）。
コメントや進捗状況の共有といった、コミュニケーションも取れるようにする。

GitHubでこの3要素を満たすことはできるのでしょうか？　武藤さんに相談してみました。

教えて、武藤さん！

――というわけで、今回の目的ではどんな機能が必要なのか、ある程度見えてきました。GitHubの機能で実現する場合の課題は？

武藤：「必要な人に必要な情報だけ見せられる」という点に関連して、リポジトリ運用について次の3つの検討点が考えられると思います。

プライベートリポジトリを使うか、パブリックリポジトリを使うか。
リポジトリにアクセスするのは誰か。
個人 / 組織、無料 / 有料、どのプランを選ぶか。

1の課題「プライベートリポジトリを使うか、パブリックリポジトリを使うか」について。パブリックリポジトリの場合、世界中に公開され、誰からでもIssueやPRを飛ばせます。記事で紹介したプログラムコードを掲載したり、ユーザーの問い合わせに回答したりなどのパブリックなサポートサイトとして使うには有用かもしれません。

しかし、制作中の記事情報をパブリックにするのは不適切でしょう。プライベートリポジトリを使うことが前提になると思います。

――そうですね。公開前の情報は、関係者だけが見られるように設定したいです。

次に、2の課題「リポジトリにアクセスするのは誰か」について。編集部員のほか、ライターなども含む想定でしょうか？

――Findy Enegineer Labの運用では、「関係者はなるべく入れるようにする」という方針で考えています。ライターのほか、記事制作協力者（インタビューを受けてくださる方など）も想定しています。テック系メディアの場合、エンジニアの方に取材することが多く、GitHubに慣れているでしょうから。

それを踏まえて、3の課題「個人 / 組織、無料 / 有料、どのプランを選ぶか」。プライベートリポジトリの場合、関係者の人数を考慮してプランを選ぶ必要があります。*1