GitHubで追いかける について

ASKAさんの「700番 第2巻|第3巻」を拝読しました。

僕は、中学生のころから、CHAGE & ASKAさんのファンであり、母親と兄と、名古屋のコンサートに出かけたことを強く覚えています。

 

僕たちの影響は、すぐに母にも及び、

家族でCHAGE & ASKAさんのファンになりました。

 

母が、まだ中学生で子どもな兄と僕を、不慣れなコンサートに連れていってくれました。

当時から大人気だったコンサートの、一般販売のチケットでいい席が取れるわけもなく、

また、家計的な事情もあり、ようやく取ってくれたのは広大なコンサートホールの最後尾にある4階の立ち見席でした。

 

それでも、会場に到着した母は、僕と兄を連れて、困惑していました。

こんな大きなホールの、どこで見ればいいのか。

しかも、中学生とはいえ、まだ騒ぎたい僕らを、どこに連れて行けばいいのか・・。

 

母は、会場案内のお兄さんに、声をかけました。

「どこにいけばいいですか?」と。

 

お兄さんは、そっと母と僕らを人通りの少ない場所に連れていき、こう言いました。

「ここに、キャンセルになったファンクラブ会員チケットがあります。

これを持って、2階席に行ってください」

 

もちろん、はっきりとは聞き取れませんでしたが、そんな趣旨のことを伝えているのは理解できました。

僕らは子どもながらに大興奮をしたことを覚えています。

その頃から、今でも、どんなニュースを見ても、

 

子どもが真っ白な布に、そっと親の思想のインクを垂らすように、

親がどんなときも、叱ったり呆れながらでも、最終的には子どもの価値観を信じるように、

お二人のことを、信じています。

 

その中で、WEB屋として気になった箇所があったので、書かせてください。

もしかしたら、そんなことは当たり前にご存知で

もっと深くの洞察や背景がある場合は、無礼を心からお詫びします。

 


ASKAさんの著書の、140ページあたり。

GitHubのことが書かれています。

テレビでは、ギフハブと言い間違えていましたが、やはりこちらだったようですね。

あの後、すぐにこの言葉での類似サービスを探しましたが、

似たようなものに、GIF形式でのネタ動画ページがあるくらいでした。

 

詳細な内容は、当然ここには書かないし、

気になる方は著書を読んでご確認ください。

 

↓こちらのリンクは、広告リンクではなく、普通のリンクです。あえてサムネイルも貼りません。
700番 第二巻/第三巻
http://amzn.asia/0v82wb8


できるだけ、平易な言葉を使って書こうと思います。

IT技術の専門家の方にとっては、「違う」という部分もありますが、

文脈をわかりやすくするために、脚色している箇所はあります。

 

それが、情報操作や、かえって混乱を招かないように気をつけていきますが

最終的には、もう一度検索をして、ご確認いただければ幸いです。

 

GitHubについて

ご存知の通り、プログラマや開発者たちが利用する、「バージョン管理サービス」です。

僕もアカウントを持って、このサービスを使っています。

 

ここで確認をしておきたいことは、

GitHubは開発者同士で変更履歴を確認しあうものであり、

GitHub自体に悪意のプログラムがあるわけではないということです。

 

ただ、もしかしたら、悪意のあるプログラムをGitHubで管理しているユーザーも、いなくはないのかもしれません。

 

それは、

電動のこぎりを持っている人が全員ジェイソンではないように、

中には、日本の林業のために不要な木を伐採しているかもしれません。

 

GitHub自体は管理ツールであり、

素晴らしいソフトを管理している人もいれば

くだらないソフトを管理している人もいるかもしれないということです。

 

そして、万が一ですが、

中には誰かを監視するツールを作っている人もいるかもしれません。

 

GitHubの使い方を、本当に簡単にお伝えすると・・

「リポジトリ」という、プロジェクトの苗を植えます。

「ブランチ」という、プロジェクトの枝を作ります。

これで、1つの苗が、いろいろな栄養素を吸って育つように、

みんなが開発した変更点を吸って育っていきます。

 

それぞれは、これを食べさせると育つという変更点を合成し、「コミット」というアンプルに入れます。

 

それを、苗に注入して「プッシュ」します。

 

こうやって、複数の開発者が

「これがいい」と思う変更点を、リポジトリという苗にどんどん追記していきます。

 

 

追いかける

複数人の開発者で管理をしていると、

僕もよくやりますが・・・エラーを起こしたり、

意図しない反応を示すことがあります。

 

表示が崩れたり、プログラムがエラーを返したり、真っ白な画面になったり。

ここで、「しまった、何か変な変更をしてしまった」と気づきます。

 

こういう時に、バージョン管理があってよかったなと思います。

「一体どの変更点が問題だったんだろう」と、遡って原因を追いかけて、その場面まで戻すことや、原因を特定して修復することができるからです。

 

この一連の行動を、

「リポジトリを遡る」とか色々言ったりします。

 

どうも、開発者は、プログラムやIT関連のことを擬人化する傾向があります。

一時ファイルを保存させることを、「クッキーを食わせる」と言ったり。

 

それこそ、アクセス解析の、行動トラッキング(追跡)を

「ユーザーを追いかける」と言ったり。

 

なので、僕の目から見ると、

「特定のユーザーを逐一追いかけたい」という表現は、理解できます。

 

例えば、プロジェクトメンバーの中の一人が初心者で、

多少挙動不審なプッシュを繰り返していたとしたら、

プロジェクト管理者は、そのメンバーの行動を逐一追いかけておきたいと思うかもしれません。

 

また、優秀なプログラマのことを、少しでも学習したい・参考にしたいと思っている開発者さんは、多少特異ではありますが、

その尊敬するプログラマの挙動を追いかけたくなる気持ちも、理解できます。

 

それは、ASKAさんの曲が大好きな新人アーティストが

コード進行をギターでなんども追いかけるような感覚に似ていると思うのです。

 

つまり、愛着があるから、偉大な人の行動を知りたい。

もちろん、それが実際なストーカーや監視行動につながるのは、絶対ダメです。

ただ表現手法として、「GitHubで追いかける」は、自然なものかなと思うのです。

 


表現の問題はある

「アイドルファンがアイドルの言動を逐一追いかけるように」

という表現自体は、芸能活動をされている方であれば過敏になる部分だと思います。

 

確かに、ドキっとする表現です。

でも、多少過激な表現ではありますが、

行動心理を比喩するという点で言えば、表現方法の問題はあるにしても、内容は理解できます。

 

「ミュージシャンが、コンサートで歌詞を間違えたくないように」
歌詞をステージに出すとか

「大切な音源データをなくさないように」
何重にもバックアップを取る

とか、そういう表現に近いのかな・・と感じました。

不謹慎か不謹慎でないかは、読み手側にもよるとは思うのですが、
GitHubに関して言えば、理解できる行動心理かなと思います。

 

僕も、「素敵だなぁ〜」と思ったホームページは、

作り手の意図を少しでも知りたくて、ソースコードを開いて”追いかけて”みます。

スタイルシートに、開発者の名前があったら、その人のページを見てみたりとか。

 

表現手法に、誤解を招きやすい表現はあるかもですが

表現したい心理は、理解できるものだと感じました。

 


追いかけるための難解な用語

該当ページには、少し難解な用語が並んでいますよね。

差し出がましいとは思いますが、少し解説させてください。

 

GitHubber

GitHubberは、GitHubの利用者(愛用者)のことをさします。

これは、GitHub自体が、求人サイトに投稿している内容からもわかります。

GHEのお客さまをサポートする
GitHubberをウォンテッド!

https://www.wantedly.com/projects/28254

 

Web API と REST API

GitHub の Web API を使えば可能。使いこなすにはスクリプトで REST API を叩ける程度の技術力が必要だが。

こういう部分が出てきますね。

APIというのは、そのサービスを外部サービスが利用できるようにするための、
アプリケーションプログラムインターフェイス となります。

つまり、GitHubで起きていることを、外部のプログラムで利用するための道具。

 

例えば、ギターやキーボードには、その内部で流れている電気信号を外部のスピーカーやアンプや機材に繋げる「オーディオインターフェイス」があるはずです。

プログラムも、内部で起きていることを外部で再利用するためのインターフェイスがあります。

それを、WEB上で使えるので、WEB APIと表現します。

 

REST APIは、WEB APIの形式の1つです。

音楽も、WAVE形式なのか、MP3形式なのか、MIDI形式なのか、いくつか形式があると思うのです。

 

Issue(イシュー)

Issueは、その名の通り「問題・課題」です。

例えば、GitHubのリポジトリで公開されているプログラムに、問題や改善点が見つかった時、外部の開発者が「この問題、どうにかしてよ!」と、問題提起を投げかけます。

それを、Issueと言います。

該当の

自分が書いた Issue に対してコメントが書き込まれたりなど自分に絡む更新のみ(を、追いかけたい)。

というのは、自分が問題提起した内容についての対応を”追いかける”ということです。

 

 

なんでも取得できる

このあたり、紛らわしい表現が出ていましたね。

特に、なんどもパソコンをハッキングされているということなので、余計に紛らわしいのではないかと思います。

たぶん GitHub 上の行動ならほぼ何でも取得できるように見える

GitHubが、「IT世界で起きていることを、解析できるようなソフト」だとしたら、上記の文脈は、こう捉えられます。

「インターネットに繋がっている全てのPCで起きている行動なら、なんでも取得できる」

 

しかし、GitHub自体、僕が知っている限りでは、プロジェクトのバージョン管理ツールです。

開発者が、自分のプロジェクトを複数人で管理する時に、間違いが起きた時でも復旧できるようにする「合同開発日記」のようなものです。

この開発日記を、横断して公開している情報をなんでも取得できるのかもしれませんが、

GitHubを通じて、ネットワークに繋がっているすべてのPCの・・というような解釈にはならないような気がしています。

 

ただ、懸念することとしては、

ASKAさんが「埋め込まれた」とおっしゃるように、

GitHub系の何かのプログラムをPCやスマホに埋め込まれていて、

勝手にPCで起きていることを、GitHubのリポジトリとして公開されていたとしたら、それは追跡することもできるのかもしれません。

 

 

ターゲットの今を追う

このあたりも、ややこしい表現ですね・・。

ターゲットがいつ何をしたかの過去全てを知ることはできないということだ。
Twitter と同じく、今を追うべきなのだろう。

上記の前提にもとづくとしたら、以下の内容のように捕捉できます。

「ターゲットとなる、自分が知りたい開発プロジェクトの、過去の開発記録を、すべて知ることはできない。」

これは、GitHubのAPIが

保持されるイベントは直近90日以内あるいは最大300件まで

であることに、起因しているようです。

 

 

ターゲットの Events を取得&記録する

ここも、どきっとする表現ですね・・。

スクリプトを書いて、めぼしいターゲットの Events を取得&記録する仕組みを構築するのみ。

例にならって捕捉するとしたら、

「GitHubの、知りたい開発プロジェクトの変更履歴を取得したいなら、
GitHubが開示しているWEB APIをREST APIを使って取得するスクリプトを書いて、

知りたいめぼしいターゲットの変更履歴(Eventsというパラメーターで取得できる)を、自動で取得&記録する仕組みを構築する」

ということになります。

 


最後に

僕は、ASKAさんの書いたことや、事件のことが

正しいとか、間違いだとかを語る資格がありません。

 

それは、僕が、お二人のファンだからです。

ここで、正否や善悪を語る資格がないのです。

 

僕にとっては、栄光や挫折や、本に書いてあるような失敗や試練も含めて

大切なお二人であり、ミュージシャンなのです。

 

今回、このコラムを書いたことで、

誰かに何かの反応をして欲しいとか、取り上げて欲しいとかは一切ありません。

万が一、ご本人の目に触れることがあったとしても、

「ふーん、そんな見方もあるのね」で、いいと思うのです。

 

ただ、読んでいて違和感を感じたこと、

もし、何か必要な時に、情報や判断材料の1つにしていただけたら嬉しい。

それだけです。

 

ASKAさんは、

僕の知っているGitHub以外の姿を、たくさんみてきているかもしれません。

僕がここに書いたようなことは、すでに僕よりも深く調べ済みかもしれません。

 

なので

考えが間違っているとか、思い違いをしていると、決めつけたいわけではなく

「WEB業界では、一般的には、こういう見方をします」という、材料の一つにしていただけたら幸いです。

 

その上で、つま先でコンとついて、

颯爽と音楽活動に向き直っていただけたら幸いです。

 

アルバム

楽しみにしています。

 

 

株式会社ヒーリングソリューションズ

代表取締役 水野 博文