【87】GitHubから学ぶ：出版業界やどこでも？Google Docとの違いとは

GitHubと呼ばれる、ソフトウェア開発のプラットフォームをご存じでしょうか？システム開発の際に使われるこのWebサービス、実は結構どこの業界でも使われる可能性が高いものなんですよね。今日はそんなGitについて解説！

●GitHubとは？バージョン管理システム？
●出版業界でも？GitHubとGoogle Docの違い
●リポジトリとは？執筆活動にたとえてみる
●まず考え方を理解する・身近なものに例える

GitHubとは？バージョン管理システム？

GitHubとは、そもそもどういう意味なのでしょうか。

・Git=バージョン管理システム
・Hub=拠点・集まり（ハブ空港のハブ）

なので、バージョン管理を行うことができるWeb上の拠点みたいなものです。

バージョン管理？
なんでそんなものが必要なの？という話ですが、
システム開発では複数人が関わることが多いですよね。

その時、様々な懸念が生まれます。

ＡさんとＢさん、同時に作業して保存したら、どちらの情報がどこまで保存されるのか？バッティングしたらどうするのか？

途中でプログラムが変になってしまったが、いつどこでどう間違えたのか分からない。昨日のバージョンに復元できないのか？

チーム全員が編集してどれが最新か分からない！

こういったことが起きるのは想像できますよね。

一人で作業している分には問題ないですが、チームで関わると必ずこういった事態になる可能性が出てしまいます。

そこで、このGitHubを利用することで、

・『いつだれがどこで編集したのか？』が分かる
・『いつでもバージョンによって復元』ができる
・『いつでもどこでも誰でもアクセス』ができる

などのメリットがあるわけです。

出版業界でも？GitHubとGoogle Docの違い

この話をなぜするかというと、このサービス（考え方）、とあるものに通じているなと思って先日IT企業の方になにげなく話していたら「確かに、言われてみればそうだ。気が付かなかった！」と言われたからです。

それは、本の編集です。

編集作業というのは、一人で行う分には楽です。
自分のPCにWordファイルでもおいて、淡々と作業するだけ。

しかし、これが2,3人の共著であったり、編集者チームがあったりすると、当然ですが「いつだれが編集するのか？」「この編集は誰のもの？」「この編集の意図は何？」などコミュニケーションが無駄に発生することになってしまいます。場合によっては、作業が止まってしまうかもしれない。

これは自分も経験があることです。Google Documentでお互いに編集しあえば確かに校閲機能はあり便利なのですが、「昨日のバージョンをダウンロードしたい」「編集ごとにその作業の名前があれば分かりやすいのに」「編集がバッティングしてしまった」といったことがよくあるんですよ。

また、Google Documentにも履歴機能はあるのですが、編集したものが一行一行すべてが反映されて膨大になる一方、数十秒以内に書いたり消したりすると、厳密には一部分だけが履歴になったりします。また、ちょっと作業しただけで履歴が膨大になるので、昔のものまで履歴が残らずに気になるところまで遡れなかったりします。

校閲提案して「承認」という機能もあるのですが、「解決済み」とかいう項目から見るとどうも見づらく、あまりこのインターフェースも好きじゃないんですよね。そもそも句読点ひとつで一行項目が増えるので、編集者がどこまでの文章をどういった意図で手加えてくれたのかが分からづらい。そして見づらい。

そこで、そういった編集もこのGitHubを利用すれば、非常に作業がクリアーになって円滑にチーム"開発"ができると思って話してみたわけですね。そうしたら、確かに概念は同じで、そういった本質を考えれば様々な業界で使えそうだね、という話になりました。GitHubにはプロジェクトボードもあるので、そこでタスク管理もできますしね。

少し調べてみたら、実際に出版業界では使っているらしい、ということが書かれたサイトもありました。

リポジトリとは？執筆活動にたとえてみる

GitHubのようなサービスは他にもたくさんありますが、どうしてこのサービスが今一番主流なのかというと、色々理由はあるのですが、リポジトリの考え方が一つポイントになっていると思います。

リポジトリとは「貯蔵庫」の意味ですが、Gitには『リモートリポジトリ』と『ローカルリポジトリ』があります。

文字通り、遠隔地からでもアクセスできるのが前者で、ローカルPCに置いておくのが後者です。

これも編集作業にたとえてみると、
リモートリポジトリとは、Google Documentみたいな考え方です。誰でもオンラインでアクセスできます。ただし、Docと違い、これは一つしか存在しません。マスターファイルみたいなイメージですね。

ローカルリポジトリとは、MicroSoft Wordみたいなものです。自分のパソコンのマイドキュメントに保存しておくのが一般的のように、オフラインの環境下に置いてあるものです。当然、関係者全員のパソコンに保存できるので、いくつでも存在します。

ざっくり簡単にいえば、GitHubでは、それぞれのパソコンで執筆したWordファイル（ローカルリポジトリ）をWeb上にアップしてマスターファイル（リモートリポジトリ）にくっつけていく、みたいなことができます。

しかし、それだけだったらGoogle Driveでもできなくなくなくない？？！☆
って感じですよね。

GitHubの優れている点は、これにブランチ(branch)という考え方が加わるためです。ブランチとは文字通り「枝」の意味ですが、プロジェクトが複数に枝分かれするのです。
※ブランチ＝王様のおしゃれな食事のことではありません

なので、Aさんが書いた小説第1章があった場合、編集者Bさんは、その第1章の改変＋第2章を書いた場合、そのファイルを「枝分かれ」させて保存することができます。

編集者CさんはBさんのファイルの続きからそのまま編集しても良いですし、Aさんのファイルから枝分かれさせて編集してもokです。Bさんの文章は全部人間失格レベルだな！って思ったら、Aさんのファイルから編集し始めれば良いです。後からBさんの文章みて「ま、ここの表現は良いかもな」とおもえば、そこだけ持ってくれば良いわけです。
※人間失格レベル＝誉め言葉かそうでない表現なのか...

後からそれぞれの違い（＝システム開発でいえば、ソースコードの差分。データの変更履歴を保存することをコミットといいます）を見て、「こういう考えもありか」「あ、この文章いいね」「このパート素晴らしい、残そう」といった判断ができます。コードの差分だけ保存するので、データ量も膨大になることがありませんし、なによりそこだけ確認すればよいので分かりやすいです。

まず考え方を理解する・身近なものに例える

つまり、Ａさん、Ｂさん、Ｃさんそれぞれがローカルリポジトリでつくった文章を、リモートリポジトリにアップロード（＝プッシュ。レビュワーへの更新の依頼はプルリクエストといいます）するとき、勝手にマスターファイルが更新されるのではなく、枝分かれさせて存在させることで、「いつどこでだれが編集したものなのか」が分かり、「このバージョンを復元させよう」という判断が簡単にできるんですよね。そのうえで、オーナーは、オリジナルのマスターファイルであるリモートリポジトリの更新（＝マージ）をします。

同時に、このようにローカルとリモートに保存しておけば、オフラインでもオンラインでもどちらの場合でも利用できます。またオンラインひとつしかファイルがないとそこのファイルがなにかあったときにすべて消えてしまいますが、ローカルにも保存しておけば「バックアップ」の考え方にもなります。これを分散型といい、逆のことを集中型と呼びます。Google Driveすべてに保存しておけば大丈夫だぜ！というのは一元管理の集中型という意味では便利でありますが、ある意味でリスキーでもありますからね。

最初は見慣れない横文字が沢山出てきて、なんじゃこれむちゃむずいねん☆☆☆、って感じですが、要領覚えていくと便利なことを実感していきます。まだ僕も1か月も経っていませんが、まず大事になるのはどういった目的・考え方のサービスか、であり、それを把握したら細かい作業はGoogleさんに聞けば分かります。

身近なものにたとえてみると分かりやすかったりします。
世界中の方が使っているのですから、それなりにメリットがあるものですし、それなりに便利であれば、自分も似たような考え方のサービスを日常生活で触れているはずです。

今後も、IT業界でもいろいろな場面で使われていきそうです。

それではまた♪