真正性。英語で言うとAuthenticity。これは「俺が本物だ」という意味です。

今主流の多くのプログラムはソースコードがあり、それをコンパイルなどしてマシンが実行可能な形に変換します。ここにおいて面倒なのがソースコードと実行ファイルの関係です。

自分のところで両方を管理するならば問題はありませんが、世の中では開発を委託するということが頻繁に行なわれます。ユーザ企業がSIerに開発を委託することもありますし、SIerが一部の開発業務を外に委託することもあります。一般の人がWindowsやPhotoshopなどのソフトウェアパッケージを購入することもその一種と言えるでしょう。

ソフトウェアのパッケージの場合、個人も法人もほとんどは実行ファイルだけを購入して終わります。しかし開発を委託する場合にはプログラムソースと実行ファイルの両方を納品してもらうという約束が少なくありません。しかしプログラムソースと実行ファイルが何をもって結びついているか、というと難しい問題になります。

いざというときにばれるから偽者を掴ませるということはないだろうという立場から見ればこれほど危ない嘘もないですので、ソースの取り違えが起きるというのはほとんどないでしょう。しかし万一の引継ぎミスや運用ミスでソースとプログラムに食い違いが発生しても人間の見た目には全然わかりません。

またそのことでソースの一部が欠落し、運悪くその状態でソースを編集してプログラムのバージョンアップを行なうという事故も起こり得ます。運がよければコンパイル時にエラーが出て気づくことができますが、運が悪ければそのままコンパイルされてリリースされてしまう事があるかもしれません。もちろんバージョンアップに関連の深い部分であれば綿密にテストされるでしょうが、変更範囲外で影響はないはずだろう、と目されている部分にソースの取り違えやロストがあったら見逃されてしまうことになります。

となるとテストが大変です。アラン・チューリングの言ったとおりあらゆるバグを見つけられるプログラムはありませんので、バグ発見のすべてを自動化することは難しいでしょう。すると人力で頑張るしかありません。が、人力はお金がかかります。それと作業ミスがつきものです。やるとなればテストに投入できる工数を最大限活用できるようにホワイトボックステストの手順を作って機能を確認することになるでしょう。

ソースコードを自前でコンパイルし、購入した実行ファイルと1ビットも違わずにビシッと同じものが揃うところを確認できれば安心してソースを使うことができるのでしょうが、コンパイラのバージョンなどの環境が違っていたら同じソースから別々のファイルができてしまうという怖さがありそうです。2つのバイナリをチェックして同義のマシン語が書かれているかどうか調べてくれるツールがあればいいんでしょうが、あるんでしょうか。Javaのバイトコードや.netのILならできるんでしょうか。

コンパイル時のログにinputファイルがこれ、outputファイルがこれ、とあればそれを信用したらいいのでしょうが、ログなんてただのテキストファイルでありどこまで信用できるか、というところまで疑い出したらキリがありません。

もしこれらのチェックをしないとなると、開発元の「これが合ってる心配するな」を全面的に信じなくてはなりません。これって何かの話に似ているなと思ったら思い出しました。耐震偽装建築の事件です。

専門外なので間違っているところがあるかもしれませんが、大きな建築物は設計書から作った構造計算書の点検を済ませてから建築し、建築途中に実物を検査してもらい、完成してからも検査してもらうというような流れだったと思います。ソフトウェアも設計書をレビューし、テストを行い、ユーザ検証を行なうといった構えです。

似ているな、と思うのは作りこみでバグ（施工不良）や設計ミスが発覚するところです。両者ともに作り始めて初めて設計ミスによる不具合が露見してきますし、しばらく進めていると、設計書どおりにできていないところが見えてきたりします。ソフトウェアのほうはコンパイルするとソースや設計書がわからなくなってしまいますが、建築のほうも内装まで施工が進むと鉄筋の本数などがわからなくなります。

ソフトウェアではテストをばりばりとやりますし、建築では非破壊検査と言われる建築後の検査があります。また最近では宇宙線を使って鉄筋コンクリートを透過撮影するという壮大な実験が行なわれていました。作ってしまったものを「本当に設計書どおりにできているだろうか。設計書どおりだけど不具合が出ているところは無いだろうか。」と点検するのは大変なことのようです。

これにさらにミスが加わると大変なことです。耐震偽装建築事件では意図的に書類の差し替えが行なわれましたが、計算用の書類と施工用の書類が取り違えられたまま建築が進んでいくなんていうことが起こりえるかもしれません（実際のチェック体制は不勉強ながら存じません）。同じくソフトウェアも設計書が取り違えられたらバグが出ます。

建築とプログラムが決定的に異なる点としては、建築が工事完成後に建物を破壊して工事をやり直すことがとてつもなく大変なのに対し、プログラムでは比較的容易にソースを修正することができます。パッチをあてることもできます。

それにコンパイル自体は何度やっても大変な作業ではありません。実行ファイルを信用せずにソースをすべてレビューし、自前でコンパイルしてから使うという体制を整えれば少なくともソースと実行ファイルの不整合は避けられるでしょう。ただし大変だと思います。このあたりのところはHOSTの仕組みは優れていると思えるところです。

これと同じ事がまた設計書とソースとの間にも成立し、設計書どおりにソースが書かれているかどうかというところがまた怪しいところです。また、ソースを記述するルールを定めて開発することがありますが、ルールを完全無視で書かれたソースというのも存在し得ます。

結論としては「気をつけようね」になってしまうのですが、堅くやろうと思ったらこれほど大変なことはないな、というソース管理の話でした。