元ネタ:「やはり欠陥だった武雄市の個人情報保護条例」経由、「高木浩光先生、やっぱり間違っています。もっと勉強してください。」

高木氏の所には、こう書いてある。

やはり欠陥だった武雄市の個人情報保護条例（高木浩光＠自宅の日記）より：

ところが、先週公表された、7月10日の武雄市教育委員会臨時会の会議録によると、Tポイントカードの会員番号*1が個人情報に該当しないと、武雄市の職員によって説明されている。

そらみろ、条例でちゃんと明文化しないからこういうことになる。

ここで「ちゃんと明文化しないから」とは、「「個人情報」定義の弊害、とうとう地方公共団体にまで」に、次のように書かれている部分である。

「個人情報」定義の弊害、とうとう地方公共団体にまで（高木浩光＠自宅の日記）より：

しかし、日本の個人情報保護法上は、端末ID等は、「他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるもの」に該当しないとされており、「個人情報」ではないことになってしまう。（総務省の「第二次提言」は単なる提言にすぎない。）

つまり、「他の情報と容易に照合することができ、それにより特定の個人を識別することができる」情報を「個人情報」とするかどうかは、識別情報を提供する組織が決めなければならないよ、と。日本の個人情報保護法では、「個人情報」ではない。が、扱う者が「個人情報に準じる情報」として扱うことはできる。そして、武雄市の場合は、明文化されていない。

それに対して武雄市長は、この様に述べていらっしゃる。

高木浩光先生、間違ってます。（武雄市長物語）より：

括弧書きがない場合も、括弧書きの対象である「他の情報と照合することができ、それにより特定の個人を識別することができることとなるものが機械的に除かれるわけではなく、「「民間向けの「個人情報」定義よりもさらに狭い」と断ずることはできない。これもまた、法制の世界では当たり前のこと。

「断ずることはできない」と。

はい、それは良いです。「断ずる」、つまり「はっきりと判断を下す」ことはできない、と。では、断ずることはできないが、武雄市ではどう扱うのかについては、書かれていない。民間向けの個人情報の定義よりも、広いとも狭いとも判断できない。で、広いの？狭いの？それが、この「高木浩光先生、間違ってます。」の中では広い、つまり「個人情報に紐付く情報も個人情報だ」とおっしゃるわけですね。

そして、7月10日の会議録では「個人が特定できる情報ではなくて、Tカードを使うと会員番号と何月何日何ポイント付いたという情報がCCCのポイントシステムにいく」と、記録されている。この発言をした人にとって、個人情報に紐付いている T カードの会員番号は、「個人が特定出来る情報ではな（い）」と。

高木氏が問題にされているのは、この認識のズレ、ですよね。

高木氏の主張は、「括弧書きがない場合も、括弧書きの対象である「他の情報と照合することができ、それにより特定の個人を識別することができることとなるものが機械的に除かれるわけではな（い）」」が、書かれていないために「他の情報と照合することができ、それにより特定の個人を識別することができることとなるもの」を除いて理解してしまっている人がいる。これは、問題ではないのか。ということ。それに対する武雄市市長の返答は、「書いてないからといって範囲が違うわけではない」の繰り返し。おかしいやん。武雄市市長さん、やっぱり間違っています。もっと国語の勉強をして下さい :p

高木浩光先生、やっぱり間違っています。もっと勉強してください。（武雄市長物語）より：

どういう論理展開であるか不明だが、以前に指摘したとおり、括弧書きがない場合も、括弧書きの対象である「他の情報と照合することができ、それにより特定の個人を識別することができることとなるものが機械的に除かれるわけではなく、「民間向けの「個人情報」定義よりもさらに狭い」わけではない。

狭いわけではないが、では、武雄市の個人情報は、どの範囲なんだ？その説明がないのは、なぜ？「それ違う」とは言っているが、なぜ違うのかという説明はない。なぜ説明しないの？ああ、「国の範囲と一緒」なのか。国の範囲は、「個人情報に紐付いていて、参照可能な情報も個人情報」ですよね。なぜ、それと異なる解釈が展開されているんだろう？

本文の中には「私以外にもこの御仁のおかしさについては縷々指摘してあって」と書かれているが、このエントリ（「高木浩光先生、やっぱり間違っています。もっと勉強してください。」）のコメントには、このエントリの著者に対するおかしさの指摘が目立つのは何でだろう？

ところで、この「武雄市長物語」の URL "hiwa1118" ですが、「卑猥（hiwa1）で良いや（118）」に見えるのは私だけ？

ネタ元：「[プログラミング]「型」があるのは福音だよ？」から「変数に型がないということの利点について考える」

うん、面白い。

どのような型の値でも代入できる

　まず基本的なこととして変数に型がなければどのような型の値でも代入できるということです。つまり、受け取るときに、どのような型の値を受け取るのかを意識する必要がありません。

my $str = 'Hello';
my $num = 1;
my $nums = [1, 2, 3];
my $person = {age => 2, name => 'taro'};
my $ua = LWP::UserAgent->new;

「どのような型の値でも代入できる」ということですが、C/C++ でも、ポインターに限定すれば、void とアスタリスクで宣言することで、どのような型のポインターでも代入できますよ。Java や C# なら、Object で宣言すれば、何でも入れられるんじゃないかなぁ？でも、それをやる人は、まず、いない。おおよそ、構造体や関数の型を定義して、それを使う。なぜか。型を明示することにメリットがあるから。そのメリットについては、明示的には書かない。

そして、これは、次と一緒と考えて良いのかな？

変数に型がないと変更に強い

　変数に型がないとソースコードの変更に強くなります。たとえば右辺の返す型に変更があったとしても、受け取る側のソースコードを変更する必要はありません。

# clinetはClientA型でもClientB型でもよい
my $ua = $c->client;

「どのような型でも代入できる」では、初期値の代入しかしていません。しかし、「変数に型がないと変更に強い」では、コーの変更のことにまで言及してあるので、例えば次のようなコードも許される、ということかな？

my $variable = 1;
my $variable = 'abc';

で、「変更に強い」というのを、この様に、「コードを変えなくてもよい」のようにはいわないと思うのですが、どうなんだろう？私がイメージする「変更に強いコード」とは、仕様に変更があったとき、「どの範囲に影響があり、どこを修正すれば良いかがわかりやすいコード」なのですが。ここで言われているのは、「どのような型でも代入可能なので、型が変わったということがわからず、変更しなければならない箇所がわかりにくい」でしかないと思うのです。ああ、「変更しなくていい」だから、変更しなければならない箇所はわからなくて良いのか。でも、変更しなければならない箇所がわかりにくいということは、変更が有効になっていることをテストするコードを書きにくい、ってことじゃないかな？そうすると、コメント欄で、「テストすればわかる」と書かれていることと矛盾します。確かに、テストコードを“書いて”、テストすればわかるでしょう。しかし、テストコードを“書く”のなら、次の所とも矛盾します。

記述量がとても短くなる

　変数の型がないことによって記述量がとても短くなります。

え～～！！テストコードの方が、記述量が短いですって？そんなこと無いでしょう？

ちょっとふざけてみました。いや、かなりまじめ。型を書くという事を「記述量が多い」といいながら、静的型付け言語では不要な「型チェックのためのテストコード」を書くことは、記述量に入らない？テストコードを書く時間は、開発時間に入らない？生産性として勘定しない？そんなバカな。。。

あと、ここも気になった。

複数の型を受け取りたいときに、インターフェースを実装する必要がない

　Javaで大きなの労力といえば、インターフェースの仕組みを覚えて、実装することでしょう。複数の型を受け取りたい変数を作成したい場合は、まずインターフェースを実装することになります。

関数のオーバーロードが不要になる

　変数の型を持つ言語は、型が異なるのだが、処理としては同一の処理を行いたい場合には、オーバーロードという機能を使う必要があります。変数の型がなければ、オーバーロードの機能は必要ではなく、ただ単にif文で分岐すればよいだけなのでとても楽です。

おそらく、「オブジェクト志向設計」を誤解しています。それはおそらく、「オブジェクト指向設計」という字を使うから。oriented は「志向」であって、「指向」ではないのです。明鏡国語辞典には、こう書かれています。

志向:［名・他サ変］意識や思考がある対象に向かうこと。「平和国家の建設を━する」「アウトドア［本物・上昇］━」「指向」とも書かれるが、本来的な用法ではない。「指向」は単に物理的な方向をいう。

指向：［名・他サ変］ある一定の方向をめざして進むこと。また、その方向へ向かわせること。「市場を東南アジア全域に━する」「━性アンテナ」

オブジェクトに指向しかしていないから、オブジェクトを使う事を考える。オブジェクトに志向するなら、そもそも「オブジェクトとは何か」について考えます。そうすると、「処理としては同一の処理を行いたい」など、処理に志向した考え方はしなくなります。オブジェクトに志向していれば、「このオブジェクトとあのオブジェクトで、同一の処理が適用できる」の様になるでしょう。

もちろん、書いてあることもおかしくて、Java, C++, C# では、次のように書くだけです。

void sub()
{
    // 「hoge().DoSomething();」とも書ける。
    IInterface arg = hoge();
    arg.DoSomething();
}

あ、「変数に型がないと変更に強い」に、次のように書いてありましたっけ。「たとえば右辺の返す型に変更があったとしても、受け取る側のソースコードを変更する必要はありません。」と。じゃぁ、同じように書きましょう。「型に追加があっても、実行するところのコードを変更、if - else if を連ねる必要は有りません。勝手に、追加された型の DoSomething メソッドが実行されます。」と。記述量も少ないし、いいよね。

で、わかっていただけないのが、この arg 引数の型が IInterface 以外に変更になったとき、静的型付き言語ではコンパイルすることで検出できるのですが、「動的型付け言語…といって良いのかな？…では、実行“しなければ”わからない」のうち、「しなければ」が「すれば」なのか、どっちだ？！という点。同じように、「テストすればわかる」なのか、「テストしなければわからない」なのか、という問題もある。コメントをされている方々は「しなければ」なのですが、著者さんは「すれば」なんですね。

で、これについては、思うのです。「経験のないものはわからない」と。

もし、著者さんが、小規模の開発、小規模物件の追加改造しかされた経験がないなら、「すれば」でしょう。しかし、大規模から巨大規模の開発しか経験されていない方なら、「しなければ」でしょう。

この間、必要に駆られて SQLite3 を触ったのですが、これって、型の宣言って、無視しやがるのね。INTEGER と宣言したのに、文字列も実数も格納できてしまうorz 私としては「怖い」のですが、アプリケーションの設定を簡易的に保存する手段としては、まぁ、良いかもしれませんね。でも、基幹業務に使いたいとは思わないなぁ。

そういうことで、小手先の技でチョイチョイとつくって、全体を見渡せる範囲に収まっているなら、動的型付け言語って、便利だと思います。一人で全体を見渡せないなら、静的型付き言語の方が便利です。

また、買いもしないのに本屋巡りしてきた。

API、つまり外部との接点のデザインについての本。センスって、磨くことが出来るんですか？でも、良い設計を知って、それを真似ることは出来るはず。

私はポインタで躓いた記憶がないのですが、ちら読みして、何となくその理由がわかったかも。最初に、コンピュータについて説明されています。5つのユニットだのメモリマップだのが。これだ。私は、PC-6001の説明書でこれを読んでいるんだ。Z80で下地があったんだ。というわけで、ポインタを理解する下地として良いと思います。

最近、MSDN フォーラムで「デバッグ実行」のことを「デバッグ」と勘違いしているんじゃないだろうかと思う投稿が複数ありました。「デバッグ実行」をしただけでは、デバッグすることになりませんから。

「良い」ってどんなものなんでしょう？よくわかっていないから、読まねば。

先日、妻が骨折しました。医者は「放っておいても治る」とおっしゃるのですが、そうすると骨がいがんだままくっつくので、固定のための金属を入れる手術をすることにしました。手術の前日、木曜日に入院し、金曜日に手術、土日を過ごして月曜の回診後に退院、という予定です。

さて、妻の医療保険に、入院時に費用の補てんがありました。そこで、保険会社に電話して、必要な書類について尋ねました。その時のことです。

“私”が電話したところ、向こうから「本人様ですか？」という問い合わせがありました。
私「いいえ」
保「本人様と代わっていただく事は可能でしょうか。本人様のご確認が終われば、その後はご家族様でもかまいません」
私「（妻に）本人確認するから代わってやって」
妻「もしもし代わりました」
で、この後、本人確認をするわけですが、妻がしゃべっているのを聞いていると、名前、住所、電話番号、生年月日が、登録されている内容と一致しているか確認していることがわかるわけです。

その内容なら、私でも「本人」と確認されますが？

証券番号が尋ねられるかと思って、保険証券も用意しておいたのだけど、それは尋ねられなかった。すると、何ですか？妻の友人は、妻の氏名、住所、電話番号、生年月日を知っていますが、妻の友人は妻になりすまして保険会社に保険内容を尋ねることができるのですね。

え？それらは、他人には秘密にしておかなければならない情報なんですか？！じゃぁ、名刺に氏名を書いてはいけないのですね？！友達と、手紙の交換もできないのですね？最近は手紙じゃなくメール？じゃぁ、インターネットで通信販売を利用してはいけないのですね！あ、メールって書いたけど、そもそも電話で話をしたらいけないのか。そして、誕生日を祝っても祝われてもいけない、と。

窮屈な世の中ですね。

　すぐそこまで迫っているようですね。うちも、Windows 8 での動作確認を行う仕事がアサインされていますが、いくつか仕事を抱えていて、なかなか触れていません。

　が、RAD コントロールがお目見えしました→RadControls for Metro（telerik.com）さわりたい～

　しかし・・・もう少し、マウスでの使用を考慮した作りにならんのだろうか？それとも、企業での仕事のスタイルが変わらなければならないのだろうか。

ネタもと→「「ビューン」アプリのユーザー閲覧履歴取得、運営会社が説明」

　同社によると、（略）アプリから閲覧履歴と端末識別情報を同社サーバへ送信する仕組みを実装しているという。

　取得した情報から個人を特定することは意図しておらず、また同社のシステム上、取得した情報から個人を特定することは不可能という。

　個人を特定できないことから「個人情報」には当たらないと判断してきた

今回の謎。「個人を特定出来ないところから「個人情報」にはあたらないと判断」の是非について。

「個人情報の保護に関する法律」によると、「個人情報」は、次のように定義されています。

第二条この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。

株式会社ビューンでは、会社が持っているシステムでは個人を特定することが出来ないから、個人情報にはあたらないと判断した、と。

で、疑問。法律では、個人の情報を、“誰が”容易に特定出来るか、について、定義していない、ということ。

個人情報の保護に関する法律では、個人を特定出来る情報に紐付いた情報も、個人情報とされています。ところで、「端末識別情報」は、個人に紐付いています。当たり前ですよね。では、端末識別情報と個人の氏名を関連させた情報を持っているところでは、容易に個人の情報を得ることができる、ということです。

ん？ところで、iOS のアプリの仕組みがよく分からないのですが、iOS のアプリでは、料金の請求は、どこにするのでしょう？つまり、「月額課金」みたいな制度の場合、って事ですけど。この課金が、各会社から行われるのであれば、各会社は個人情報を持っていなければならず、「個人を特定出来ない」と言うことはあり得ない、ですよね。通信会社なり iPhone なのでアップル社？に請求が行って、そこから個人に請求されるなら、各会社は“直接”個人を特定出来る情報を持っていなくても良いかもしれません。

さて、@IT に載っている、閲覧情報を取得しているのではないかと指摘しているサイトを見ると・・・どうも、素の HTTP で、通信しているらしいです。どうも、素の HTTP で、通信しているらしいです。大切なので、もう一度書きます。どうも、素の HTTP で、通信しているらしいです。SSL 通信用に準備までされているのに、お疲れ様でした。

はい、素の HTTP で、端末識別情報を流しているそうです。これで、他のサービスが、サービスへの登録情報として端末識別情報と個人を直接識別できる情報を、素の HTTP で流していたなら、それを捕まえた人には、「他の情報と容易に照合することができ、それにより特定の個人を識別することができる」ということになりますね。「電子書籍とプライバシー」のページでも、最後の 「問題点の整理と今後の展望」で、「名寄せの可能性と、それがもたらすもの」で指摘されています。

問題点の整理と今後の展望（電子書籍とプライバシー）より：

「自分の属性を表す情報の集合体」というものがたやすく形成されていきます。キモになるのはこの「情報の集合体」であり、これらの情報は「自分自身」、例えばどこどこにお住まいの誰々さん（何歳）、みたいな直接的な情報を指すわけではありません。

当該ページでは、属性情報だけの集合体を考えていらっしゃいますが、その中に直接的な情報が含まれることもあり得ます。すると、その瞬間に、個人情報に変わります。そして法律では、その個人を特定出来る事について、誰が行えるのかと言うことを定義していません。

ホント、疑問なんですけど、個人情報を含む情報の集合体の上にある情報の集合体を、どういう根拠で、「個人情報にはあたらない」と判断しているんでしょうねぇ？

前のエントリで、aetosさんからコメントを頂きました。

一般論として、CA1063 や CA1816 を抑止するのは不穏な臭いが。

はい、確かに、その通りです。

抑止したい、具体的なコードを示します。まず、MSDN のドキュメントから。

アンマネージ リソースをクリーンアップするための Finalize および Dispose の実装（msdn）より：

Dispose メソッド名のカスタマイズ

場合によっては、Dispose ではなく、ドメイン固有の名前を付ける方が適切なこともあります。たとえば、ファイルのカプセル化では、メソッド名として Close を使用した方が適切です。この場合は、Dispose をプライベートに実装し、Dispose を呼び出すパブリックな Close メソッドを作成します。

この、「Dispose メソッド名のカスタマイズ」を行います。新規にクラス ライブラリ プロジェクトを作成し、次のコードを書きます。

// Dispose メソッド名をカスタマイズしたクラス
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Runtime.InteropServices;
using System.Text;

namespace Practice16
{
    public class Class1 : IDisposable
    {
        private IntPtr handle;
        private Stream file;

        ~Class1()
        {
            this.Dispose(false);
        }

        public void Open(string fname)
        {
            // ハンドルを獲得
            this.handle = Marshal.AllocHGlobal(1024);
            file = new FileStream(fname, FileMode.Open);
        }

        public void Close()
        {
            ((IDisposable)this).Dispose();
        }

        //public void Close()
        //{
        //    this.Dispose(true);
        //    GC.SuppressFinalize(this);
        //}

        protected virtual void Dispose(bool disposing)
        {
            if (disposing == true)
            {
                // マネージ オブジェクトで
                // 破棄が必要なものを破棄
                file.Close();
            }

            // ハンドルを破棄
            Marshal.FreeHGlobal(this.handle);
            handle = IntPtr.Zero;
        }

        #region IDisposable メンバ

        void IDisposable.Dispose()
        {
            this.Dispose(true);
            GC.SuppressFinalize(this);
        }

        //void IDisposable.Dispose()
        //{
        //    this.Close();
        //}

        #endregion
    }
}

このコードを FxCop に通すと、次のエラーが出ます。

CA1816 は、Close() メソッドと Dispose メソッドの明示実装をコメントアウトしているような実装にしていたからで、これは、直しました。

この様に、メソッド名をカスタマイズすると、FxCop はかなり強い警告を表示します。明示実装があるんだから堪忍して欲しい。それとも、Close() と Dispose() の両方を置く？