シェア
はてブ
Findy Engineer Lab編集部のゆでたまご（@f43a9a）です。
「編集部の業務をなるべく少ないツールで完結したい！ そうしたらきっともっと効率的にメディア運用ができるはずだ！」というアイデアから、GitHubだけで記事制作できないかチャレンジ企画の連載をスタートすることになりました。進捗状況を逐一レポートして、テックに関わる皆様のメディア・ブログ運用のヒントになる情報を発信できたらいいな、と考えています。
……いきなりこんなこと言われてもワケがわからないと思うので、背景を説明しますね。
どうしてGitHubで記事制作したいのか
編集部の主な業務は、言わずもがな記事を作ることです。記事制作開始から公開までに、どんなアウトプットがあるのかと言いますと……。
記事制作の流れ
企画書: 主にGoogle Docsで制作
連絡・調整: メールやXのDMなどで、取材や寄稿で記事制作協力いただく方に連絡
初稿: 主にGoogle Docsで制作
原稿チェック: Visual Studio Codeでtextlintを使ったり使わなかったり
修正: Google Docsで編集提案を出したり出してもらったり
入稿: CMS（弊メディアの場合ははてなブログ）
部内調整・情報共有
タスク・スケジュール管理: GitHub Projects（最近、Trelloから移行した）
スケジュール管理: Googleカレンダー、Google ToDo リスト（私の場合）
社内連絡: Slack
見てもらいたいのはツールの多さ。タブを高速で開いたり閉じたりする日々を過ごすなかで、長年感じていたことなのですが……。
ツールから別のツールへコピペするのがしんどい
これですよ、これ。「コピペするのがしんどい」。何がしんどいって、コピペのたびに確認や書き換えが発生するのです。たぶん、“文字を書くツール”の使い分けが一番わかりやすいと思います。
例: 記事制作の場合
初稿: Google Docsで制作
それをVisual Studio Codeにコピペして、目視とtextlintで校正すべきポイントを洗いだす
Visual Studio CodeとGoogle Docsの情報を照らし合わせながら、Google Docsで編集提案を出す
必要な修正が完了したらCMSにコピペ → 適切なフォーマットで入稿できているか目視で再確認
修正に置換処理が必要な場合は、CMSからまたVisual Studio Codeにコピペして……（以下略）
Google Docsは原稿をやり取りするのに便利。Visual Studio Codeは原稿をチェック・修正するのに便利。CMSは記事をパブリッシングするのに便利。こんな風に“文字を書くツール”にも一長一短あり、それぞれに役割があります。だから使い分ける。
しかし、ツール間を行ったり来たりしながら作業を進めるとコピペが発生し、その結果としてヒューマンエラーのリスクだったり、フォーマットの相違からくる調整の必要性だったり、ちょっとずつバージョンが異なる複数のファイルだったり……と、手間とトラブルの温床になるアレコレが発生します。
コピペ自体は5秒で終わります。でも、コピペした後のことを考えると少ないツール数（できればワンツール、つまりゼロコピペ！）で済ませたいのです。
GitHubで何とかなりません？ 教えて、武藤さん！
私は学校を出てから10年ほど、フリーだったり社員だったりあちこちの編集部で仕事をしてきて、今年からFindy Engineer Lab編集部所属になりました。そして、テックについて勉強しはじめてビックリしたのは、ITエンジニアリングの領域では効率化・自動化のためのツールがとても充実していること。
特にGitHubにはプロジェクト管理、ドキュメント管理、コードレビュー（原稿チェック・戻しに相当する工程）、CI/CD、コラボレーション、コミュニケーションなど一通りの機能が揃っていて。これが使いこなせれば、編集部運用の効率化につながるのではないかと思った……というのが、今回の“GitHubで記事制作チャレンジ企画”が立ち上がった背景です。いやあ、話が長くなり失礼しました。
しかし、どうしたらいいものか。自分にはさっぱりわかりませんし、自然言語とプログラミング言語の、二刀流のスキルを持つ方でなければ難しそうです。そこで本企画では、長きにわたってITエンジニアリングを活用した技術系書籍の制作経験を持ち、現在は株式会社はてなでエンジニアとして働いている武藤健志（@kmuto）さんにアドバイザーとして入っていただくことにしました。
――……とまあ、そんな次第なのですが、どう思いますか？
武藤さん 現在の記事制作の流れを拝見していると、Google Docsが中心にあるシステムで、かつてMicrosoft Wordファイルでやり取りしていたのがオンラインで共有されているようなイメージですね。ただし、最終的な公開物としてはCMSの「はてなブログ」に置くために、都度Markdown形式にしているものと思います。
Google Docsには、WYSIWYGの調整、画像や表の簡単な貼り付け、Wordインポート、テンプレート、コメント機能、履歴表示、スクリプト実行などなど、多数の優れた機能があります。今の記事制作において、システムの中心たらしめている価値は何でしょうか？ “GitHubで記事制作”はドラスティックなチェンジになるので、まずDocsから脱却できるという素地ができていないと、「不便になっただけじゃん」で終わってしまうかもしれません。Docsで完結させてMarkdown保存したものをフィルタ加工するだけではてなブログへ、という流れも考えられなくはありません。
GitHubは高機能なコラボレーションプラットフォームではありますが、銀の弾丸、万能の願望器ではなく、特にコンテンツ管理の面で見ると、リーダブルなテキスト形式に対してその真価を発揮するのであって、バイナリデータの取り扱いに特段強みがあるわけではありません。また、別のクラウドであるGoogle Docsのデータを直接GitHubで管理できるわけでもありません。DocsのデータをMicrosoft Word等のファイルに（劣化）保存してGitHubにコミットするくらいしかできない、ということですね。
もし制作においてGoogle Docsで特に価値を感じている点が、テキスト形式あるいはGitHubの機能では明らかに不可能なものだとすると、GitHubの仕組みを使って何か効率化しようとしても成功は難しいでしょう。
――武藤さんはコンテンツ制作にGitHubを利用したことはあるのでしょうか？
武藤さん 私も過去の書籍制作で、プロジェクト管理やコミュニケーションツールのみの用途にGitHubを利用したことがあります。しかし、あまりうまくいきませんでした。コンテンツの修正はクラウドドライブ上のPDFにコメントを入れる形で行っていたため、散発的な連絡以外には活用されず、制作の終盤ではもう指示はメールで済ませるほうが早いという状況になっていたのです。
逆に、今Google Docsで行っていることが、テキスト形式あるいはGitHubの機能で十分に代替できる、あるいはもっと柔軟に対応できそうならば、大きなチャンスです。最終的な公開物はテキスト形式の1つであるMarkdown形式なので、序盤からMarkdown形式にして進めれば、GitHubの強みを大いに活かせます。
GitHubを使って編集部の記事制作の運用を効率化するという大目標のためには、最初から最後までテキスト形式コンテンツを中心にすること、関係者皆が自然にGitHubを見たくなるようにそこに情報が集まっていること、という2つの中目標の達成を考えてみるとよいでしょう。
武藤さんの「Google Docsを記事制作システムの中心たらしめている価値は何でしょうか？」という指摘を受け改めて考えてみたのですが、Findy Engineer Labの場合は「URLで共有」「コメント機能」「.mdファイルとしてダウンロード」という3つの機能でしょうか。
ツールバーに並んでいる見出し、太字、箇条書き、リンクといった機能はMarkdownで十分だし、コードブロックやコードスパンに関しては、むしろMarkdownのほうが便利なくらいだし……。弊メディアのようにテキスト主体のテック系Webメディアやブログの場合、記事を作る工程でDocsを使うメリットは意外と小さいのでは？（どちらかと言うと共有・校正・入稿というその後の工程で便利なツール）
次回はさらに具体的な課題整理をして、GitHub活用に向け動いていきたいと思います！
