先日上梓した拙書「最速の仕事術はプログラマーが知っている」がありがたいことに大変評判なようで、発売4日後に増刷が決まるなど売れ行きが好調のようです。

もともとこんな刺激的なタイトルの本を書いていいのか、という悩みもあったのですが、編集の方の強い熱意と最初のミーティングの段階で完璧に近いところまで揃えられた目次と企画書を見て、「これは時間を割いてでも書いてみたい」と思い、引き受けることにしました。

実際に世に出ても、「やっぱりこれは書きすぎなんじゃないか」「刺激が強すぎるんじゃないか」と危惧していたのですが、Amazonでの評価も概ね好評のようでほっと胸をなで下ろしています。

やはり書籍というのは発売されるというのは目標の半分で、やっぱり読まれて読者の方に「面白かった」「ためになった」と評価していただいて初めて値打ちがでるものなので、小心者の筆者としてはいつも本が出る度にハラハラしているのですが、「つまんねーぞ金返せ」などと言われなくてよかったです。

本の感想というえのは、けっこう、傷つきますから。人間性の否定ですから。けっこう、くるんですよね。普段、部下にバカにされても、ネットで晒されてもさほど傷ついたりしないんですけど、一所懸命書いた本の内容をバカにされると、やっぱり傷つきます。

ネットの文章というのはある意味で力を抜いているというか、ほとんど推敲なしでアップしているし、読む側も基本的に無料で読んでいただいているのでライブ感というか殴り書き感が重要だったりするのですが、本は一度書いたものを編集者の方と何度もなんども揉んで、練り直して、それから出て行くものなので、やっぱり「コレジャナイ」と言われてしまうと本当に辛いのです。

まあそういうことで傷つかないように、プロの編集者の方が事前に読者の代わりとなって、「ここは残しましょう、ここはもっと膨らませましょう」と原稿をやりとりするのです。編集者の方がいないとなかなか原稿もすすみません。ありがたいことです。

この本もそんなやりとりのなかで、編集者の方に「専門的すぎる」と言われてボツになってしまった部分もあるのですが、そのうちのひとつが「ソースコード管理システムの活用」というテーマでした。

せっかく書いたのに日の目をみないのももったいないので、ここに少し引用しておきます。

　実際はビジネス文書を作ることよりも、じつは管理するほうが大変である。

なぜならビジネス文書の多くは、過去の企画書や契約書をコピー＆ペーストして、その場その場で修正を加えていくものだからだ。
しかし実際にはビジネス文書ほど管理が面倒なものはない。

特に契約書などは、どの客先向けにどの部分をどのような経緯で修正したのか把握するのが大変だ。
結局、どの契約書も頭から何度も読んで細部を確認しなければならない。

さて、プログラマーにしてみれば、総務部や営業部がやりとりしてる書類の管理手法というのは控えめに言ってとても原始的に見える。

彼らはMicrosoft Wordの親切な履歴機能と注釈機能、それと洗練されているとはお世辞にも言えない電子メールとパスワード付zipファイルでやり取りする。しかもパスワードは別便で！

まず第一に、暗号化したメールのパスワードを別便で送るのは無意味である。
なぜなら、メールが何者かによって傍受されている場合、パスワードの書かれたメールも受信するからだ。

次に、ローカル（手元のPC）で展開したファイルを暗号化していない場合はあまりに多い。これも、無意味である。
PCを紛失した場合、機密情報が無制限に漏れることになる。

機密を保持したいと願うなら、ローカルのハードディスク全体を暗号化し、メールは使わずにUSBメモリなどの物理的な媒体で送り、パスワードは口頭で伝えるしかない。

ただ、情報セキュリティは気にすればきりがないので、ある程度のところで諦める必要がある。
とはいえ、パスワードを別便で送るのはナンセンスだ。

もっといいのは、Google Docsなど、最初から暗号化されているクラウドサービスにファイルをアップロードし、クラウド上でだけ、データを閲覧することだ。

これならGoogleのパスワードが流出しない限り安全だし、そもそもパスワードを平文でメールに載せるなんて間抜けなことをしなくて良くなる。

もっと奇妙なのは、契約書などをはじめとする文章のバージョン管理だ。

たいがいの会社は、ファイル名に「20150608_○×商事様お見積り(清水修正).xls」のように長い名前を付けて管理している。
しかしいまどきのオペレーティングシステムではファイルが作成された日時はちゃんと管理されてるから日付は不要だし、だいいち、更新履歴を手動で管理するなどナンセンスである。

そもそもプログラマーたちが管理すべき文書は、総務部や営業部の非ではない。
彼らは1日中、PCの前に座って何をしているのか。

プログラムという文書を大量に書き、修正し、管理しているのだ。
例えば、スマートフォンのオペレーティングシステムであるAndroidのプログラムは全体で１２ギガバイトもある。
ちょっと想像がつかないかもしれないが、12ギガバイトとは、61億4千4百万文字である。本書が12万字くらいだから、この本の5万倍の分量だ。仮に一日一冊本書と同じ文字量を書くとしても、軽く140年はかかることになる。

もちろんこれだけ膨大なプログラムは一人の人間が書いたのでも、一朝一夕にできたものでもない。
Androidの内部にはLinuxという別のオペレーティングシステムが入っており、Linuxの中にはGNUツールチェインというプログラムが入っている。

GNUツールチェインは最も古いもので40年以上前のものだから、いわば人類が40年の月日を掛け、世界中に散らばるキラ星の如き天才プログラマーたちが持てる頭脳の限りを尽くして作り上げ、磨き上げてきた血と汗の結晶が、この12ギガバイトなのである。

この膨大な文書がしかも数百万ものプログラマーたちによって入れ代わり立ち代わり、修正されたり追加されたりして、さながら地球最大の百科事典の様相を呈しているのだ。

しかもこれはLinuxやGNUといったオープンソースプロジェクトのごく一部でしかない。

この膨大な文書を管理するため、情報処理の達人である偉大なプログラマー達はもちろんExcelにパスワードを掛けて別便のメールでパスワードを送るなんて馬鹿なことはしなかった。

ことの発端はUnixのリビジョン管理システム(Revision Control System)にあった。
すでに増え続けているプログラムのソースコードを効率的に管理しつつ、昨日のプログラムはうまくいってたのに今日はなんだか動かない。どこを変えたんだっけ？そもそもそこ変えたの俺だっけ？と大混乱に陥るプログラマーを救うための救世主、それがRCSだった。

リビジョンとは、まあバージョンのこと。
日々刻々と修正され、追加される膨大なプログラムの部品たちがいつだれがどのようにどんな目的で修正し追加したのか追いかけることができるようになったのだ。

RCSはその後、CVS（並行バージョン管理システム）、Subversionなどの発展形を生み出し、ここ数年はLinuxの中心部分を作った20世紀最高のプログラマーの一人、リーナス・トーバルズが自ら開発したGitというバージョン管理システムが大流行している。

このGitが非常によくできていて、GihのホスティングサービスであるGitHubはさらによくできている。
プログラムに修正を加えたい部外者は「ここバグってるからこう変えたらどうですか？」という提案ができるようになっており、プロジェクトの管理者が提案を引き受けたり却下したりすることで、爆発的に開発効率が上がった。

これまさしく最強の仕事術を最強のプログラマーが自ら生み出したって話だからね。本書のタイトルに偽りなし！

そういうわけで筆者の会社でも当たり前のようにGitとGitHubを使っている。
むしろそれを使っていない会社はちょっと遅れてるんじゃないかと思うほどだ。

そして、プログラムのように複雑な文章が細かく管理できるならば、とうぜん、契約書のような軽い文章のバージョン管理などお茶の子サイサイなのである。

だから最近IT企業ではGitHubにプログラムだけでなくビジネス文書まで管理させるケースがちらほら増えてきた。どこを誰が修正したか一目でわかるし、だれが一番いっぱい文書を書いたか、仕事をしてるか、ということまでなんとなく図でわかってしまう。GitHub、恐ろしい子！

ただ一方、天才の天才による天才のためのバージョン管理システムであるGitは機能が多すぎて天才にしか把握できず、「人類にはまだ早すぎる」とまで言われている。オーパーツ的なシステムでもある。

だから残念ながらGitはプログラマーが使いこなすのもやや難しいという説もあるので、生半可な覚悟では対応できないだろう。
そのうちOffice365とかで簡単にGitみたいなことができるようにならないのかね。

と、プログラマー達は薄らぼんやり思っているが、プログラマーにとって契約書などのビジネス文書に興味は湧かないので、どうでもいいやと思っている。

しかしバージョン管理システムもない世界でExcelやWordにパスワードかけて送ったりしてる世界はやっぱり牧歌的ですよ。

実際、GitHubでビジネス文書を管理させると変更履歴を追いかけることができたり、検索したりできるので非常に便利です。

もちろん無料で使うと社内の機密情報がだだ漏れですので、ちゃんとお金を払ってプライベートリポジトリを使います。

しかも、出張先でも社内の文章にブラウザからアクセスできるし、ブランチを切れるし、必要に応じてgit cloneすればいくらでもコピーできるので、よほど機密性の高い情報でない限りはGitHubで管理するほうが合理的だという気がします。

特に、テキスト文書などを共同で作業している場合などは、更新履歴がわかるのは便利ですし、Wordの注釈機能や履歴管理機能みたいにめちゃくちゃマシンが重くなって使い物にならない、なんてこともありません。

さらに、差分だけ呼び出して確認することも簡単です。

この差分に対してコメントすることもできるので、契約書などでどの部分が争点になっているか、どのようにして合意形成できたか、というプロセスを記録することもできて非常に合理的です。

これほど便利なシステムを、プログラマー以外が使っていないというのはとても勿体無いと思います。

Git自体は非常に複雑なのですが、GitHubくらいまで噛み砕いてもらえると分かりやすいですし、非プログラマーでも使えるのではないかと思います。

また、GitHubはソースコード管理システム(リビジョン管理システム;RCS)とバグ追跡システム(BTS;Bug Tracking System)が一体化しています。

「ここをこう直したほうがいいんじゃないの?」という提案をPull Requestとして文書の管理責任者におくり、責任者が承認して初めてマスターの文章を修正したり、Pull Requestに対して理由を付記して突き返すなどのこともできます。

議論や変更の経緯が明確になって、引き継ぎも楽だし検索できるしいいことづくめです。

本文中にもあるようにプログラムというのは一編の巨大な文章ですから、これを複数のプログラマーが(数人から数千人あるいは数万人)あとから追いかけたり修正したりするための仕組みがソースコード管理システムなのです。こんな便利なものを使わない手はありませんよね。

取引先の契約書のやりとりや原稿のやりとりも、本来ならこうした仕組みでできると齟齬がなくなって便利なのですが、現状はWordの重たい文章を貼り付けてメールで送りあう(そしてメールボックスの容量が圧迫されてGoogleから「もっと容量が欲しければもっとお金を払え」と脅迫される)という非効率的なやり方はいつまで続くのでしょうか。