雑談

2017年12月 9日 (土)

せめて作業場所節の名前だけでも覚えて帰ってください

Fujitsu Advent Calendar 2017の9日目です。 このエントリは個人の立場で書いております。 なのですが、 せっかくなので業務で開発に携わっているモノを紹介しようと思います。 説明上、特定の製品の話も出てきますが、宣伝の意図はありません。 くどいですが、このエントリは個人的に書いているもので、所属企業の見解を示すものではありません。

さて、 私が開発に携わっているモノとは、COBOL処理系です。 富士通が何かやっているというニュースが出ると、 「どうせCOBOLだろw」みたいな反応が出たりもする、 みんな大好きCOBOLです。

古代の遺物扱いされることも多いのですが、 コードはまだまだあるところには大量にあります。 ぜひ「知っている言語」の一つに入れておいてもらって、 どこかのシステムの奥底からCOBOLコードが出てきた際には、 げえっと叫んで封印するのではなく、 読んで、場合によっては手直しなどしてもらえればなと思います。

ざっと以下の内容。

おかんについて

まずは、わたしらのおかんを紹介したいと思います。 Grace Hopperです。 COBOLの母です。 おかんがCOBOL作りました。

米海軍准将でした。 けっこう偉大な人なので、 その名を付けた駆逐艦があります。

つまり、うちのおかんはリアル艦娘です。 ハイパー婆さんなのに駆逐艦。 「バブみ」などという言葉ではとうてい表現できない歴史の深みです。 ひげのおっさんとかではなく駆逐艦が作った言語と聞くと、 ちょっとやってみようという気になりませんでしょうか。 なりませんか。そうですか。

Grace Hopperといえば、 コンピューターにおける「バグ」語源にからんだり、 「許可を求めるより後で謝った方が簡単だ」という名言を残したり、 逆回りの時計を壁に掛けていたり、 色々エピソードのある人です。 生きていれば、本日101歳の誕生日です🎂。 1992年に亡くなっていますが、 女性技術者の集まりである"Grace Hopper Celebration"に名を冠されていたり、 去年はアメリカ合衆国大統領自由勲章が授与されたり、 今なお存在感があります。

プログラムのスタイルについて

そんなおかんが開発したCOBOLはLispやFortranと並んで最古参の高級言語のひとつです。 記号をあまり使わず、 英語の文章のようにプログラムを記述していくスタイルです。 試しに簡単なプログラムを書いてみましょう。

       IDENTIFICATION DIVISION.
       PROGRAM-ID. MAIN.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK.
         02 FILLER  PIC X(6) VALUE "Hello".
         02 WK-NAME PIC X(5).
         02 FILLER  PIC X    VALUE "!".
       PROCEDURE DIVISION.
           DISPLAY "? " WITH NO ADVANCING.
           ACCEPT WK-NAME.
           DISPLAY WK.
       END PROGRAM MAIN.

"PROCEDURE DIVISION."と書かれてある行より後ろがプログラム本体になります(『手続き部』)。 この部分はとても文章的です。 まあ、文章的な代わり、 ちょっと複雑な処理を書こうとすると色々書かなきゃならないのが面倒になってくるのですが。 その「本文」の流れに邪魔になる様々な定義はほかの部分、

  • IDENTIFICATION DIVISION(『見出し部』)
  • ENVIRONMENT DIVISION(『環境部』、このプログラムでは省略されている)
  • DATA DIVISION(『データ部』)

に記述するようになっています。

このプログラムは、 例えば"World"を入力すると、"Hello World!"と返すものです。 以下のような感じ。

? World
Hello World!

このユーザー入力を受け取る部分は "ACCEPT WK-NAME."と書かれている行になります。 「"WK-NAME"という『変数』に入力を受け取る」という意味の文です。 この『変数』"WK-NAME"の定義はデータ部にあります。

       WORKING-STORAGE SECTION.
       01 WK.
         02 FILLER  PIC X(6) VALUE "Hello".
         02 WK-NAME PIC X(5).
         02 FILLER  PIC X    VALUE "!".

"PIC X(5)"は、 まあ、ざっくり言えば、「5文字分の領域」という意味になります。 なので、富士通のNetCOBOLの場合、 5文字分入力されるまで入力を待ち続けます。 3文字入力してEnterを押してもあと2文字入力されるまで律義に待ち続けます。 ちなみに、5文字以上を入力すると、余った入力は切り捨てられます。

で、プログラムの最後では、"WK-NAME"を含む"WK"全体を一気に出力しています。

           DISPLAY WK.

今時の感覚からすると、 文字列とかは可変長の「文字列オブジェクト」で扱ってほしいし、 テキストのフォーマットももっと動的に処理すれば使い勝手良いだろうに、 とか思うのです。 まあ、複雑な文字列編集を行うための文とかもあるのですが、 この程度ならばこんなふうに書いてしまうことが多い。

このあたりのデータの取り扱いの感覚が今時の言語との大きな違いではないかと思います。 何と言いますか、発想が帳票的です。 上のデータ定義、 そう思ってみると、 帳票的なイメージがしてきませんか? "WK"という一塊のデータ(レコードと言います)を定義し、 その内部の各欄に6文字、5文字、1文字というサイズを割り当てています ("FILLER"は「名前?名前などどうでもよい」という意味)。

それは構造体のようなものではないのか? 構造体の先祖と言えるかもしれませんが、 今となっては「構造体」で期待するものとかなり違うんじゃないかなあ。 COBOLのレコードは参照が含まれることがほとんどないので、 本当に固定長のべたな領域を区切っていることになります。 領域に余白ができたら自動的に空白を詰めたりします。 ファイルの読み書きもそのレコードをそのままべたに読み書きする感じ。

今の眼からすると、 COBOLはそういった帳票的なデータを加工したり入出力したりするための言語とイメージすると、 分かりやすいんじゃないでしょうか。

「事務作業なんて要するに何かの帳票を読んで別の帳票を作ることだろう」と割り切ったとでも言いますか。 英語の文章的な記述法といい、 おかんは技術者ではない一般の人でも事務作業を自動化できるようなモノを作りたかったのではないかと思います。 今で言えば、Excel的なものでしょうかねえ。 ただ、事務作業向きといっても、 やろうと思えばかなりのことができてしまいます。 それが行き過ぎて、神Excelならぬ神COBOLみたいなコードも大量にあったりします。 適材適所は大事。

ともあれ、 COBOLのデータの取り扱いは今時の言語のデータの取り扱いとは発想がかなり違っています。 この違いが、十進演算と並んで、COBOLの置き換えが結構難しい技術面での原因ではないかと思います。 興味があれば、 COBOLの表の添字付けについても調べてみてください。 COBOLの表は多くの言語での配列に相当するものですが、 多段になっている場合の添字付け方法が今時の言語とまったく異なっています。

ちなみに、 このデータ部の変数を定義する部分(WORKING-STORAGE SECTION)、 日本語では「作業場所節」と言います。 変数は「場所」なのです。 いかにもです。 ここに定義したデータは、C#やJavaなどで言うところのstatic的に割り付けられます。 つまり、もう一回このプログラムを呼び出すと、 "WK-NAME"には前回のデータが残ってます。 いったんプログラムがロードされてしまえば、 メモリ不足やStackOverflowが発生しにくい安心安全設計。 なお、2002年規格以降は、 ローカルなデータも定義できるようになっています。 ローカルなデータは局所記憶節(LOCAL-STORAGE SECTION)という場所に書きます。

いにしえの記法について

上のプログラム、左の余白が目につきます。 実は、この余白(行の先頭6カラム)は行番号領域です。 ですが、今となっては空白にしておくのが吉です。 下手に自動ナンバリングとかしてしまうと、 行を追加/削除した場合に以降の行番号がずれて、 ソース管理上そいつら全部が変更された扱いになってしまいます。

また、7カラム目は標識領域で、 ここに「*」が記述されていたら、その行はコメントです。

こんな調子で、昔のCOBOLのソースにはカラムに意味があります。 古典的な書き方では、73カラム以降はコメント(見出し領域)です。 下手にソースをUTF-8化すると、非ASCII文字を含む行で本文のカラムが増えて、 コード末尾が勝手にコメントになってしまうという事故が起きたりします。 その他、「この要素はこの領域から書き始めないとダメ」みたいな規則もあり、 解析処理を書く際にカラムの考慮が極めてだるいです。 文字コードの問題がからむとなおさら。

なんでこんな書き方をするのか。 今でこそみんなPCを持っていて、 エディタでプログラムを書くわけですが、 昔は一人一台端末を占有しつづけるなどできませんでした。 じゃあ、どうやってプログラムを書いていたかといえば、 こんな紙に書いていました。

コーディング用紙

コーディングシートというやつですね。 この紙に書いたプログラムをコンピューター室に持っていって入力したり、 さらに古くはパンチカードを打ってそれを読み込ませたりしていたそうです。 私自身は経験ないけど。

COBOLの古い書式は、このような昔のやり方に合うようにできていたのでしょう。 今では、カラムを意識しない「自由形式」という書法でも書けるのですが、 デフォルトは互換性のためにこの古い「固定形式」ですし、 なにより大量にある既存のソースが古い形式で書かれています。 カラムの呪縛からはなかなか逃げられない。

現状など

さすがに今となっては、世の中の最前線の課題の解決を期待されるようなことはあまりない、と思います。 が、COBOLの特徴は無限のCOBOLプログラムを内包する世界を創り出してしまっていることにあります。 Unlimited COBOL Worksです。 皆さんも日常生活で間接的にCOBOLプログラムを利用しているはずです。 銀行や自治体のシステムとか、表はWebで操作したとしても、 その最深部ではCOBOLプログラムが動いていたりします。 ちょっと古いのですが、2010年頃、 世界で2400億行のCOBOLコードが稼働しているという話がありました。 現在もまだまだコードが書かれています。 こいつらを無事に動かし続けなければなりません。 そのため、 新しいOSや環境で動くようにしたり、 連携できるようにしたり、 やることはまだまだあります。

で、新しいシステムと連携できるようにしたりすると、 「またCOBOLかよw」などと言われたりするわけですね。 数年前にHadoop対応をしたときも「なんでまた」みたいなコメントがありました。 あれ、ビッグデータをやりたいわけではなく(やってもらってもかまわないのですが)、 既存のCOBOLバッチを分割して並行に走らせたいんだけど、 それを独自の基盤を作るのではなく、 よく知られている基盤の上でやろうという話です。 別に流行りだからと何も考えずにやっているわけではないのです。 いや、何も考えずに流行りものをやってみたいとか、思ったりもしていますけど。

ハードや環境が変わっても同じ機能を動かし続けることができる、 というのがソフトウェアに期待される役割のひとつだとすれば、 それをしぶとく勤め続けております。 まだ当分、COBOLは使い続けられることでしょう。 COBOLで「先の規格」といえば応仁の頃に制定されたやつのことですが、 現行は2014年版で、 その次に向けても動きが始まっています。

今時の機能をCOBOLで書いてみる

せっかくなので、COBOLでもう少し書いてみましょう。 富士通の.NET向けCOBOL(NetCOBOL for .NET)を使ってみます。 実は、最古参の高級言語であるところのCOBOLは.NETプラットフォームにおいても最古参のサードパーティ言語だったりします。 2000年の.NET Framework発表直後のPDC 2000で、 ゲイツ先生に「わしも昔はCOBOL書いたがな」と紹介されてデモしたりしてます。 Channel 9でビデオを見れます。 COBOLの紹介は1:27:30頃から。今から見ると実に素朴。

ここで、 .NETとCOBOLのデータ型のマッピングなどを説明して、 「COBOLプログラムを.NETの一般的なデータ型で呼び出せるようにラップしてライブラリ化すれば、任意の.NET言語から利用可能になります」 とか述べればそれなりにお役に立つのでしょうが、 それはマニュアルにも書いてあるし、 せっかくのアドベントカレンダーですので、 ふつうCOBOLで書かないような処理を書いてみましょう。

async処理をCOBOLで書いてみます。

お題としては、 以下のような非同期でWeb上のテキストファイルを取ってくるメソッドがライブラリとして提供されているとして、

public class Downloader: IDisposable {
    private HttpClient httpClient = new HttpClient();

    public async Task<string> DownloadText(string uri) {
        string text;
        using (HttpResponseMessage response = await this.httpClient.GetAsync(uri)) {
            if (!response.IsSuccessStatusCode) {
                throw new Exception($"Error: {response.StatusCode}");
            }
            text = await response.Content.ReadAsStringAsync();
        }

        // 以下の行を入れてわざと待たせるようにすると、
        // 非同期に動作していることがGUI上から分かりやすい。
        await Task.Run(() => { Thread.Sleep(3000); });
        return text;
    }
    ...
}

以下のようなイベント処理をもつWindows FormをCOBOLで書いてみます。

private Downloader downloader = new Downloader();
...
private async void button_Click(object sender, EventArgs e) {
    // 処理中はボタンを無効化し、二度押しを防ぐ。
    this.button.Enabled = false;
    try {
        string message;
        try {
            string text = await this.downloader.DownloadText("http://www.msftncsi.com/ncsi.txt");
            message = $"[{DateTime.Now}] {text}";
        } catch (Exception exception) {
            message = exception.Message;
        }
        this.label.Text = message;
    } finally {
        this.button.Enabled = true;
    }
}

テキストのダウンロードは非同期処理なのですが、 その後、ラベルのテキストを更新してボタンを有効化する処理があります。 awaitを記述することで、 そのあたりがすっきり記述できています。 C#のasync/await機能ですね。

実行して、ウィンドウのボタンを押すと、こんな結果になります。

サンプルのGUI

Visual Studio 2017向けのNetCOBOL for .NETは(国内向けには)まだ出ていないので、 Visual Studio 2015 + NetCOBOL for .NET V7で書きます。

NetCOBOL for .NETはWindows Formsをサポートしています。 NetCOBOLのWindows Formsプロジェクトテンプレートからそのままプロジェクトを起こせます。 なぜWPFでないかと言えば、 残念ながらNetCOBOL for .NETでは諸般の理由によりWPFベースのGUIの作成をサポートしていないからです。 だって死にそうな思いで無理くりCodeDOM実装したのに、WPFではまったく別のコード生成インターフェイス使いよるし。 まあ、今となってはどっちみちRoslyn以前のものだけど。

で、Windows Formsを使うとして、 このasync付きのイベント処理をどうやってCOBOLで書くか。 当然、現在のCOBOLにはasync/await構文とかありません。 が、幸いなことに、.NETの機能の多くは素のクラスを使って記述可能です。 genericsを最後に構文に手を入れる必要があった覚えがありません。 LINQだろうがasyncだろうが、素のクラスとメソッド呼び出しだけで、がんばれば書けます。 がんばれば。

というわけで、 上のイベント処理を素のクラスとメソッドを使った処理に展開します。

  • 非同期処理をTask<string>オブジェクトを使う形で記述します。 非同期処理完了後の後続処理の実行はTask<string>.ContinueWith()メソッドを使ってスケジュールします。 C#のasync/awaitの展開では、ContinueWith()を単純に使わずに内部クラスを生成して色々処理をしています。 おそらくawaitが複数ある場合や例外処理をうまく処理するためでしょう。 が、今回の処理程度であれば、ContinueWith()で十分でしょう。
  • GUIはGUIスレッド上で操作しなければならないことに注意します。 C#のasync/awaitの展開ではよしなに計らってくれますが、 自力で展開する場合は自分で実装する必要があります。 ここでは、FormInvoke()メソッドを使います。
  • COBOLでラムダは書けないので、独立したメソッドに処理を記述します。 クロージャーが必要な場合は、そのためのクラスを新たに作らなければなりませんが、 幸いこのケースではそこまで必要ありません。 このForm内にメソッドを定義するだけで十分です。

いきなりCOBOLで書いても分かりにくいでしょうから、 まずC#で書きます。 以下のようなコードをこの後COBOLで書きます。

private Downloader downloader = new Downloader();
...
private void button_Click(object sender, EventArgs e) {
    this.button.Enabled = false;
    try {
        this.downloader.DownloadText("http://www.msftncsi.com/ncsi.txt").ContinueWith(
            new Action<Task<string>>(this.ContinuedProc)
        );
    } catch {
        FinallyProc();
        throw;
    }
}

private void FinallyProc() {
    this.button.Enabled = true;
}

private void ContinuedProcBody(Task<string> task) {
    try {
        string message;
        if (task.Exception == null) {
            message = $"[{DateTime.Now}] {task.Result}";
        } else {
            message = task.Exception.Message;
        }
        this.label.Text = message;
    } finally {
        FinallyProc();
    }
}

private void ContinuedProc(Task<string> task) {
    // GUIスレッド上で処理を行う。
    this.Invoke(new Action<Task<string>>(this.ContinuedProcBody), task);
}

ではCOBOLで書きます。 こういう場合以外なかなか使ってもらえないオブジェクト指向構文(2002年規格で導入)が炸裂します。 全体を載せると長くなるので、イベント処理関連の部分のみ掲載します。 クラス名の定義とかクラス定義の環境部にあるので、ここだけだと記述が完結しないけど、 まあ雰囲気を見てもらえれば。 ソース全体はGitHubに置いています。

一つおことわりを。 以下のソースでは、 メソッドの『ローカル変数』をWORKING-STORAGE SECTIONに書いています。 規格的にはここはLOCAL-STORAGE SECTIONであるべきですが、 NetCOBOLでは、歴史的な事情により、 メソッドの『ローカル変数』はWORKING-STORAGE SECTIONに書きます。

では。

       METHOD-ID. button_Click PRIVATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK-CONTINUED-PROC OBJECT REFERENCE DEL-ACTION-TASK.
       01 WK-TASK OBJECT REFERENCE CLASS-TASK-STRING.
       LINKAGE SECTION.
       01 sender OBJECT REFERENCE CLASS-OBJECT.
       01 e OBJECT REFERENCE CLASS-EVENTARGS.
       PROCEDURE DIVISION USING BY VALUE sender e.
      *    前準備
      *    複雑な型パラメータをもつ型によるメソッドオーバーロードの解決に問題があるので、
      *    ここではAction<Task<string>>ではなく、Action<Task>引数で
      *    Task.ContinueWith()を呼び出す。
           INVOKE DEL-ACTION-TASK "NEW" USING SELF N"CONTINUED-PROC" RETURNING WK-CONTINUED-PROC.
      
      *    ボタンを無効化する。
           SET PROP-ENABLED OF button TO B"0".
           TRY
               SET WK-TASK TO WK-DOWNLOADER::"DownloadText" (N"http://www.msftncsi.com/ncsi.txt")
               INVOKE WK-TASK "ContinueWith" USING BY VALUE WK-CONTINUED-PROC
           CATCH
               INVOKE SELF "FINALLY-PROC"
               RAISE
           END-TRY.
       END METHOD button_Click.
      
      *button_Clickで必ず行うべき後処理
       METHOD-ID. FINALLY-PROC PRIVATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK-BUTTON OBJECT REFERENCE CLASS-BUTTON. 
       PROCEDURE DIVISION.
      * ボタンを有効化する。
           SET WK-BUTTON TO PROP-BUTTON OF SELF.
           SET PROP-ENABLED OF WK-BUTTON TO B"1".
       END METHOD FINALLY-PROC.
      
      *ダウンロード終了後に行いたい処理の本体
       METHOD-ID. CONTINUED-PROC-BODY PRIVATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK-TASK OBJECT REFERENCE CLASS-TASK-STRING.
       01 WK-EXCEPTION OBJECT REFERENCE CLASS-EXCEPTION.
       01 WK-MESSAGE OBJECT REFERENCE CLASS-STRING.
       01 WK-TEXT OBJECT REFERENCE CLASS-STRING. 
       01 WK-NOW OBJECT REFERENCE CLASS-DATETIME.
       LINKAGE SECTION.
       01 PARAM-TASK OBJECT REFERENCE CLASS-TASK.
       PROCEDURE DIVISION USING BY VALUE PARAM-TASK.
      *    タスクをTask<string>型にキャストする。
      *    実際のタスクの型はTask<string>だが、インターフェイス上はTaskにしている。
      *    button_Clickメソッドの手続き部のコメントを参照。
           SET WK-TASK TO PARAM-TASK AS CLASS-TASK-STRING.
      
           TRY
      *      ラベルのテキストを更新する。
             SET WK-EXCEPTION TO PROP-EXCEPTION OF WK-TASK
             IF WK-EXCEPTION = NULL THEN
               SET WK-TEXT TO PROP-RESULT OF WK-TASK
               SET WK-NOW TO PROP-NOW OF CLASS-DATETIME
               SET WK-MESSAGE TO CLASS-STRING::"Format" ("[{0}] {1}" WK-NOW WK-TEXT)
             ELSE
               SET WK-MESSAGE TO PROP-MESSAGE OF WK-EXCEPTION
             END-IF
             SET PROP-TEXT OF label1 TO WK-MESSAGE
           FINALLY
      *      ボタンを有効化する。
             INVOKE SELF "FINALLY-PROC"
           END-TRY.
       END METHOD CONTINUED-PROC-BODY.
       
      *「ダウンロード終了後に行いたい処理」をGUIスレッド上で実行するメソッド
       METHOD-ID. CONTINUED-PROC PRIVATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WK-PROC OBJECT REFERENCE DEL-ACTION-TASK.
       LINKAGE SECTION.
       01 PARAM-TASK OBJECT REFERENCE CLASS-TASK.
       PROCEDURE DIVISION USING BY VALUE PARAM-TASK.
      *    GUIスレッド上で処理を行う。
           INVOKE DEL-ACTION-TASK "NEW" USING SELF N"CONTINUED-PROC-BODY" RETURNING WK-PROC.
           INVOKE SELF "Invoke" USING WK-PROC PARAM-TASK.
       END METHOD CONTINUED-PROC.

C#のFormが106行(Form1.cs: 38行、Form1.Designer.cs: 68行)なのに対し、 COBOLのForm1.cobは1126行です。 いまどき行数で生産性を計っている方々、 お喜びください。 生産性10倍以上です。

まあ、COBOLのFormにはデザイナが自動生成する特殊コメント等が大量にありまして(しかも事情があってちょっと冗長)、 単純集計だと極端に行数が増えます。 なので、button_Click処理に限定しましょう。 それでも、C#: 16行に対し、COBOL: 83行です。 COBOLのスタイルだとどうしても記述量は増えます。

やはり、言語は適材適所に使っていただいて、 適切な言語で記述された今時のシステムから伝家のCOBOLプログラムを呼び出し、 末永く利用していただければと思います。

謝辞

古来、 COBOL仕様扱う文書はCODASYLへの謝辞を掲載していました。 謝辞を掲載することで、 COBOL仕様書の内容やアイデアを自由に利用することが許可されていました。 せっかくですので、 古式ゆかしく、 CODASYLへの謝辞で終わりたいと思います。 CODASYLはもうないけど。

以下、1984年版の謝辞(「CODASYL COBOL JOURNAL OF DEVELOPMENT 1984」から)。

【謝辞】

COBOLは産業界の言語であり、特定の団体や組織の所有物ではない。 CODASYL COBOL委員会又は仕様変更の提案者は、 このプログラミングシステムと言語の正確性や機能について、 いかなる保証も与えない。 さらに、それに関する責任も負わない。

次に示す著作権表示付きの資料の著作者及び著作権者は、 これら全体又は一部分をCOBOLの原仕様書中に利用することを許可した。 この許可は、COBOL原仕様書をプログラミングマニュアルや類似の刊行物に複製したり、 利用したりする場合にまで拡張される。

  • FLOW-MATIC(Sperry Rand Corporationの商標), Programming for Univac(R) Ⅰ and Ⅱ, Data Automation Systems, Sperry Rand Corporation 著作権表示1958年, 1959年
  • IBM Commercial Translator Form No.F28-8013, IBM 著作権表示1959年
  • FACT, DSI 27A5260-2760, Minneapolis-Honeywell 著作権表示1960年

今後ともよろしくお願い申し上げます。

2017年5月14日 (日)

Windows 10 Mobileユーザーを一時的に増やした話

上の娘の機種変更時のつなぎにWindows 10 Mobileを使った話。 と、おまけで、Windows 10 Mobileをめぐる最近の状況についてちょっと思うところなど。

経緯など

うちには子供が三人います。 下の二人にはエントリーモデルのWindows 10 Mobileを持たせています。 このあたりの経緯は過去に書きました。

子供らの「つなぎ携帯」をWindows 10 Mobileにしてみた話

一方、 上の娘はiPhoneを使っています。 このiPhoneの契約が二年縛りの更新月を迎えました。 で、今になってみると、 うちの他の回線はすべてMVNOにしてしまったし、 こいつもMVNOにして通信料を節約したい。 ところが、都合の悪いことに、このiPhoneはSIMロック解除対応前のものです。

どうしたもんかと、色々費用をシミュレーションしたり娘と話し合ったりして、 「SIMフリーのiPhone SEに乗り換えよう」という結論に達しました。

AppleのiPhone下取りキャンペーン使って乗り換えるぞー。 なに?Apple Storeだとその場で下取分を割引するけど、 オンラインだとApple Storeギフトカードになる? ギフトカードなぞいらん、キャッシュよこせー。 よーし、ゴールデンウィーク中に一家で東京に行く機会があるから、 その時Apple Storeに押し掛けるぞー。 ということで、機種切り替えがゴールデンウィーク中にスケジュールされたのでした。

で、四月の終わり近くにキャリアにMNPの申し込み電話をしました。 例によって転出を思いとどまらせようとするような会話にテキトーに対応していたのですが、 一つ気になる指摘がありました。 予定では切り替えは5月上旬になるのですが、 となると、数日の利用のために5月分の基本料が丸ごと取られてしまうらしい。 「なので、切替えは月のなるべく遅くにした方が...」などとお勧めしてくれるのですが、 こちらは別のことを思いつくわけです。

ピコーン

回線は4月中に切り替え、 iPhone SEを入手するまではWindows 10 Mobileでつなごう。

娘に打診したところ、「一週間ぐらいなら」とOKが出ました。 妹と弟が使っていることもあり、多少の興味はあるようで、まんざらでもなさげ。

機種

機種はMADOSMA Q501を使います。 私がInsider Program入れて遊んでいるやつです。 ちょうど、Creators Updateに相当する10.0.15063.251が降ってきたところでした。 これに対して「電話のリセット」したところ、 都合よいことにOSバージョンは巻き戻らず、 ProductionなCreators Update機ができあがりました。 当時まだ国内のほとんどのProductionな電話にCreators Update降ってきてなかったのに。

MNPしたMVNOのnano SIMをmicro SIMアダプタかませてMADOSMA Q501に載せ、 娘のMicrosoftアカウントを指定し、 OutlookをiCloudのメールアカウントと接続。 あとは好きに設定せいや、 と渡したら、 次の朝にはあっさり実運用しとりました。 この時点でCreators UpdateのWindows 10 Mobile機使っている女子高生って、 日本に数人いるかどうかじゃないか?

というわけで、 わが家におけるWindows 10 Mobileシェアは80%に達しました。

我が家のスマホシェア

圧倒的ではないか、Windows 10 Mobileは。 こまるわー、寡占が進んでこまるわー。

あとは妻だけだけど、 妻は私がX01T時代にメール一本打つのに苦労してたの見てあきれてたからなあ。 今回も上の娘に「Windows Phoneにしたらメール打つのも苦労するで」とか言ってたし(もう今はあまりメール使っていないくせに)、 なかなか手ごわそう。

感想など

娘に一週間ほど使ってみた感想を聞きました。 良い点。

  • タイルのGUIはわかりやすい。
  • 一通りのことは問題なくできる。

悪い点。

  • アプリが少ない。今ゲームとかしてないからいいけど、ゲーム好きな人は困るんじゃないか?(まあねえ)
  • 一部アプリの動きがもっさりしている(まあ、元々そんなに高スペックでもないし)
  • カメラがあんまりきれいじゃない(これはW10Mというよりこの機種の弱い点だな)

その後

予定通り、一週間ぐらいでiPhone SEに移行しました。 家庭内シェアも元に戻ってしまった。

まあ、上の娘もWindows 10 Mobile使ってみてくれたから、よしとするのです。

ちなみに、四月中のMNP切り替えは失敗しました。 元iPhoneのバックアップ等に手間取って、 「当日中の切り替え締め切り」刻限に間に合わず、 5月1日切り替えになってしまった。 あかんやん。

(おまけ)最近のWindows 10 Mobileの話題について

Microsoftの最近の四半期決算にからんで、 「MicrosoftがPhoneビジネスを6月までに終わらせると言った」とか「証券取引委員会に提出した書類で投資項目からWindows Phoneが消えている」といった話が出ており、 またぞろ「Windows Phoneは終わった」みたいに言われています。

Microsoft’s 10Q SEC filing confirms investment in Windows Phone has ended (MSPoweruser)

ざっと見てみたけど、 記述対象となる期間からして、これらは多分Lumiaビジネスを畳んだことを指しているんじゃないかな。 実際、Microsoftの2017会計年度(2017年6月迄)を越えて作業予定があるように見える。 現状、秋のFall Creators Updateに向けてWindows 10 MobileのInsider Preview配信も進んでいるし、 つい最近もSurface Phoneの生存も確認されたし。

Nadella: “We’ll make more phones, but they will not look like phones that are there today.” (MSPoweruser)

今後、Mobileは"Windows 10"の一部分(おそらくはARM版の一部)として活動するんじゃないかな。 Intelがモバイル向けSoCやめちゃったから、 ARM版Windowsを是が非でも何とかしなければならなくなっているしねえ。

で、まあ、Surface Phoneは2017年中に出るのか、2018年になるのか分からないけど、 ハイエンドになるんだろうなあ、と思っています。 一方、あまり具体的な根拠はないんだけど、 Fall Creators Update世代では久々にサードベンダーからハードが出るんじゃないかという気がしています。 関係者のタイムラインとか眺めていると、 なにか動いているんじゃないかなあ、という気がしている。 もちろん、はっきり書いたりしていないんだけど。

なんにせよ、Windows 10ベースのスマホが存続してくれることを切に祈念いたしております。

2017年4月 6日 (木)

PCの時計が1時間進む問題が完全に解決した

前回の続き。 PCの時計が1時間進んでいる問題ですが、 私のPCに関しては問題は完全に解決しました。 わーい。

  • 前回のあらすじ
  • 現状の確認
  • PCメーカーのサポートに問い合わせた→解決
  • 考察など
  • まとめ

前回のあらすじ

  • 自分のPCの時計が1時間進んでいた
  • 原因はPCのファームウェアの設定のせいと確信(thanks to 「「PCの時計が1時間ずれている」の原因 」)。 要するに、四半世紀前ならともかく、現在においてはまったく意味のない"Daylight Savings Enable"がなぜか有効になっているPCがあるということですね。
  • 突如、Microsoftが「修正した」とのニュースが→「えっ?」

現状の確認

Microsoftが修正したとのニュースに「ほんまかいな」と思いつつ、 1日ほど様子を見てました。 しかし、修正は落ちてきませんし、 ツールで覗くとReal-Time Clockの"Daylight Savings Enable"のビットは立ったままです。

念のため、以下の手順で実験をしてみました。

  1. PCのLANから切り離す。WiFiも無効にする(タイムサーバーとの同期を防ぐため)。
  2. Windows上で現在時刻を2017年4月3日午前1:55にセットする。
  3. PC電源を電源を切り、10分放置する。
  4. (10分後に)電源を入れる。
  5. Windows上で時刻を見る。

この結果、時刻は午前2:05頃になっているはずですが、実際には午前3:05頃になっていました。 "Daylight Savings Enable"の仕様通り、午前2時がスキップされています。

(あれ、4月2日だったっけな。 手元に残したメモには4月3日ってあるけど、 "Daylight Savings Enable"の仕様を厳密に解釈すると4月2日が正しいような気がする。 でも、もう直ってしまったので再現させて検証できない… まあ、午前2時がすっ飛ぶ現象が起きたのは確か。)

つまり、時計がずれる問題は直っていない。

PCメーカーのサポートに問い合わせた→解決

ここで意を決して、 PCメーカー(富士通)のサポートに問い合わせを投げました。 問題のPCは富士通 LIFEBOOK WA3/Wです。 これが昨日の夜。

で、今日返事がきました。

(意訳)BIOSアップデートしなはれ。

あー、確かに。 サポートに問い合わせる前に確認するべきでした。 最近、ドライバもほとんどWindows Updateで更新されるので忘れてたよ。

で、サポートページでBIOSを探すと新しいものがありました。 Readmeを見ると、ちゃんと載っているじゃないですか。

■ 5.改版履歴(修正項目)

...略...

(1.20)

  • パソコンの安定性を改善しました。
  • ごく稀に、4月と10月にパソコン内蔵の時計が1時間ずれることがある問題を修正しました。

わーい。 さすがFMVサポート。 こんなくそ面倒くさい問い合わせ分かってもらえるんだろうかと思って、 こんなツイートしてたんですけど、

えらそうなこと言ってほんますいませんでした。

BIOSアップデート後、"Daylight Savings Enable"はちゃんとDisableになっているし、 上記実験をしたら、ちゃんと再起動後の時間が午前2:05になってました。

直った。

考察など

Microsoftが修正したってのは何?

何でしょうねえ… どこかにコミュニケーションミスがあったのかも。 英語サイトを色々検索したんだけど、「修正した」ってニュースは他に無さげだし。 「PCの時計が1時間ずれている」の原因 を書いた人は、 その続編(「PCの時計が1時間ずれている」の原因の解説)で Microsoftのタイムサーバーのマシンでこの現象が発生したんじゃないか、と言ってます。 うーん。 でも、そうだとすると、Windowsの時刻の同期間隔はデフォルトで一週間と聞いているので、 「影響を受けたPCの時計は、日本時間4日未明までに自動で直っているという。」(「PCの時計が1時間ずれる」グローバルで発生「修正した」とMS)なんて言えないんじゃないかな。 よくわからない。

どうして今回だけ騒ぎになった?

これも分からない。 ただ、検索してみると、過去にも時間がずれたという声はあるし、 私も、前に時間がずれて「あれー」と思いながら直したことをぼんやり思い出したし、 実は以前から結構発生してたのではなかろうか。 今回、声が目立ってニュースにも取り上げられたということかも。

あと、最近広く採用されたBIOSにそういう設定のものがあったのかも知れない。

メーカーはもっと広く知らせるべきでは

と思うんだけど、 BIOSアップデートだとするとあんまり安易に勧められないしなあ。 Windows Updateでなんとかならんのだろうか。 ボードのファームウェアとなるとWindows Updateレベルでは難しいのかな。

結局、PC側の原因で問題が発生するのはどういう場合?

  • RTCの"Daylight Savings Enable"がEnableで、
  • RTCがずれるタイミングでPCが動いておらず(停止 or スリープ)、
  • その後PCを起動した場合(電源投入 or スリープ解除)

は確実に起こるかな。 OSがRTCと同期するとずれた時刻がOSに伝わる。

PCが稼働中にRTCがずれた場合はよくわからない。 OSがRTCに書き込む機会があるかどうかに依存するでしょう。

Windowsだけの問題?

いや、違うと思う。 ボード上のRTCがずれるんだから、 ずれた後に起動すれば例えばLinuxでも時間がずれるでしょう。

ただ、Linuxとかの場合、 どういうタイミング・方法でntpサーバーと同期しているのか知らないので、 その影響はよくわからない。 Windowsより短い期間で同期しているマシンが多いような気がする。 知らんけど。

まとめ

PCの時計がずれて直っていない人は、 PCメーカーからBIOSの更新が出ていないか確認してはどうでしょうか。

ただ、 BIOSアップデートは無条件にお勧めできるものでもないので、 アップデートするかどうかは注意事項をよく読んでからお決めください。

2017年3月26日 (日)

Windows Mobileしんでしまうん?

最近、 Windows 10 Mobileを採用していたスマホが、 新モデルではAndroidに鞍替えしていた、 ということが立て続けに2件ありました。

で、「やっぱりねー」みたいな雰囲気を感じるので、 私の見るところなど書こうと思います。 状況は厳しいけど、まだ終わる状況じゃないと思ってます。 ただ、結果的に「空白期間」が生じてしまっているので、 もっとうまく立ち回れないもんですかねえ、 というような話。

なお、これは私がニュース等を見てて個人的に思ったことを書いています。 勤務先はスマートフォンに関連している部署もありますが、 私はそことはほとんど関係ないし(というか関係あったら勝手なこと書けない)。

話は2016年始めの頃から。

2016年始めの時点

あれは2016年の始めだったか。 「Microsoftはスマホを諦めている。はやくそれを公式に認めるべき」みたいな記事が海外で出てました(ちょっと検索してみたけど、探し出せなかった)。 まあ、苦戦しているのは確かだけど、 現在進行形で戦略遂行中で、 次の施策もまだある状況で「諦めてる」と決めつけるのはひどいなあ、と思った憶えがあります。

この頃、 前の年にリリースしたWindows 10をやっとこさでスマホにもロールアウトしたところでした。 これにより、 PCもスマホもその他デバイスも、 Windows系デバイスは「Windows 10」というプラットフォームで統一され、 同じプログラミングモデル(UWP)アプリを書けるようになりました。

で、次の施策は以下だと見られていました。

  • アプリの拡充支援
  • Surface Phone

アプリの拡充支援策としては、例えばAndroidやiOS向けアプリを簡単に向けに移植する「ブリッジ」を提供しようとしていました。 が、結果としてはあまりうまくいっているように見えません。 「Windows Bridge for Android」はキャンセルされました。 「Windows Bridge for iOS」(現在v0.2)は開発が続いていますが、「使った!」という話をまだあまり聞きません。 まあ、アプリ拡充は今となってはWindows 10 MobileだけでなくUWP全体の問題になるので、 この点についてはWindows 10 Mobileの動向がどうあろうともMicrosoftは頑張ってくれるでしょう。

一方、Surface Phoneは、公式にはMicrosoftは発表していません(開発していることは認めているんだっけ?)。 この時点では、PCにおけるSurfaceのように、 新しいコンセプトを提案するようなモデルになると期待されていました。 いや、まあ、今でもそれは同じなんですけど、 登場時期が当初予想されていたより大幅に遅れており、 遅れた結果、もっと切実な問題が起こっていると思います。 これについては次の項で。

2016年夏-秋

2016年夏、MicrosoftはLumiaを作っている元Nokia部門をリストラしました。 また、Lumiaブランドのデバイスの販売を2016年末で終わらせてしまいました。 これは結構衝撃だった。 日本ではLumiaを販売していませんが、 世界的には出荷されているWindows Phone/Windows 10 Mobile機の大多数はLumiaであり、 その「大多数」の供給が無くなるわけだから。

私は、本来この時期にSurface Phoneを出す予定だったのではないかと思っています。 ここでLumiaからSurfaceへのブランド切り替えをする予定だった。 ところが、Surface Phoneが大きく遅れた一方、 Lumiaは次の計画が無いのでラインを継続させておくわけにもいかず、予定通り終了。 おかげで、Windows 10 Mobileは主流となる機種が不在になってしまった。

なぜSurface Phoneが遅れたかは、外部からは知りようがないです。 ただ、以前にわりと信じられていた噂には、 Surface PhoneはIntelのCPUを採用している、というものがありました。 そのため、2016年春のIntelのモバイル向けSoCからの撤退決断はSurface Phoneを直撃し、計画変更を余儀なくされるのでは、 と見る向きもありました。 そう言われてみれば、 冒頭のAndroidに鞍替えした件に関連して、 「今年のSnapDragon 600番台はMicrosoftのWindows 10 Mobileのサポート対象から外れていた」という証言があり、 素人目には「Intelを主力CPUにしようとしてリソースつぎ込み、一方SnapDragonのサポートは絞ってて、あてが外れたんじゃないのかよ」とか疑ったりもするのです。 知らんけど。

で、(再企画したかもしれない)Surface Phoneは(早くとも)2017年秋になるといわれています。 2017年秋といえば、Windows 10のRedstone 3のタイミングです。 Redstone 3といえば、 大きめのアップデートと言われており、 Redstone 2 and Redstone 3 are going to be heavily focused on "innovation around mobile phones."といわれるやつでもあり(ただし、この記事ではSurface Phoneは2017年4月リリースになっている)、 ARM版Windowsの復活であり、 x86エミュレーターが載るわけであり、 このあたりが次のキモだと思うのです。 Surface Phoneにx86エミュレーターが載るかどうかはわからんけど。 素のWindows 10にARM版が復活することで、 よりPC/タブレットとの差が無くなっていく方向に進んでいくんじゃないかな。 ひょっとすると、その先は「Mobile」カテゴリは無くなって、 「Windows 10」でスマホもカバーすることになるかも知れない。

今後の見込み

というわけで、まだ次の計画があるんだから、「諦めた」状況ではないだろう、と思っています。 つい最近もWindows Mobileのプログラムマネージャーの求人しているし

とりあえず、Surface Phone待ちかなあ。 私的には、もうSurface Phoneは「新しいコンセプトを提案してくれるデバイス」ではなく、 「Microsoftがスマホにコミットしていることを宣言するデバイス」として期待を一身に集めております。 本家が主力ブランド(Lumia)を止めて次をどうするか明らかにしていない現状では、 周りもコミットできないでしょう。 でも今年の秋だから、まだ遠い。

何にせよ、 今後の計画の説明なしにLumiaを販売停止すると、「撤退だ!」と思う人もいるでしょうし、 シェアが小さい状況でこんな空白期間ができてしまったらただでさえ心もとないエコシステムが消えてしまいそうで気が気ではありません。 もしSurface Phoneがずるずると伸びると、空白期間はさらに広がっていくことになります。 なんかもうちょっとうまくメッセージとか出せないもんでしょうか。 Microsoftがデバイス出せない状況なのだからパートナー頼みなのに、 パートナーさんに「梯子を外された」とか感じさせてはあかんだろう、と思うのです。 本当にたのんます。

Windows 10 Mobileに将来性はある?

まあ、現状苦しいのは確かだけど、 ぼちぼちスマホ市場の状況も変わりつつあり、 まったく目が無いわけではないと思ってます。

iOSとか、そろそろMacとの関係をどうするんだということが問題になってくるんじゃないかな。 新しいモノを世に出す際には、その目的のために鋭く割り切ったようなモノでなければ認知されることはないでしょうが、 いったんブレイクして色々な人が使い始めると、色々な要求に対応せざるを得なくなり、どんどん肥大化していきます。 iPod/iPhoneはその目的を実現するために後にiOSとなるシステムを作ってそれを活用したわけですが、 iPhoneがブレイクして成長した結果、いいかげんiOSも巨大になっているように見えます。 一方、少なくとも先進国ではスマホが飽和しつつあるようです。 成長が鈍ってくると、iOSとOS Xが「二重投資」に見えてきてきつくなるんじゃないかな。

で、iOSに限らず、 PC的なものとスマホやその他デバイスと、少なくともOSは統合しようぜ、 という流れが出てくるんじゃないかと思っています。 となると、Windows 10で各種デバイスのコード統合が済んでいるWindowsは、システム的には一周回って半歩先んじている状況にならないかな。

まあ、それでもアプリ不足をなんとかする必要はあるし、 優位点が生きる状況にするにはマーケティングが必要だし、 そもそも続けていなければ優位点もへったくれもありませんが。

まとめ

使い続けたいので、なんとか存続してください。 まあ、IS12Tの後、4年放置されたのに比べるとまだ何てことないけど(強がり)。

あと、MADOSMA信じてます。

2017年3月 7日 (火)

OAナガシマのおっさんの話(Visual Studio 20周年記念)

Visual Studioは今年で20周年だそうで、 #MyVSStory などというハッシュタグもできていました。

おおっと思ったので、こんなことを書きました。

で、OAナガシマのおっさんのことをちょっと思い出したので、書き残しておこうかなと思います。 実はそんなによく知らないし、 人柄を表すようなエピソードとかも無いんだけど、 大昔、おっさんを店頭で見かけていた頃の話。

OAナガシマとは

私が沼津に来たのは90年代始めの頃です。 地元の人に「沼津のパソコンショップならここ」と教えてもらったのがOAナガシマでした。 「OAナガシマ」という店名からして、 OA事務機器屋が出自なのでしょう。 (そういえば、当時DOS/V雑誌に怪しげな広告を載せていた「大西ジム」も高砂の商店街の文房具屋(ジム = 事務)でした。何回か行ったことある。今検索したら、まだ元気でやっているらしい)

その頃の店は沢田のバイパス沿いにあり、まあ、いわゆるDOS/Vショップでした。 世界的には、ちょうどPC/AT互換機上でWindowsがブレイクした頃です。 日本ではNECやら富士通やら東芝やらが独自規格のパソコンを出しており、 それらは結局PC/AT互換(いわゆる「DOS/V機」)になっていくのですが、 その時点ではDOS/Vはまだ立ち上がりかけの頃でした。 Windowsが盛り上がっており、海外で面白そうな機器やソフトが出るのに、 日本は独自規格のせいでなかなか利用できない。 Windows 3.1とか、USで発売されてから国内発売されるまで1年以上かかったなあ。 各社版の対応に手間取っている、とかの噂でした(本当かどうかは知らない)。 「鎖国状態」とか言われたりしてましたね。今ならガラパゴスか。 お好きな方はPC/AT互換機を個人輸入したりしてましたが、 そういう「DOS/V」世界の窓口がDOS/Vショップでした。 秋葉原ならたくさん店もあるんでしょうが、 地方なもんで、 近所にOAナガシマがあるのはとてもありがたかった。

なんか、DR-DOS買ったこととか思い出した。 冷やかしのつもりで店番してたおっさんに声をかけたら、 勢いに乗せられて気づいたら買ってて、 しばらくDR-DOS使ってたよ。

さて、時は1992年

Windowsはまだ16-bitの3.xの時代。 ちょうどアメリカでVisual Basic 1.0(これがまたちょっとした衝撃だった)が出た翌年。 私は「某言語でVisual Basicみたいのを作ろう」というプロジェクトに配属されました。 当時のWindows開発環境は、コマンドラインベースのMicrosoft C 6.0 + Windows SDK。 デバッガ(Code View)はこんな感じ。 (Microsoftのフォーラムの質問にCode Viewの画面イメージがあったので引用)

Code Viewの画面

せっかくWindowsがGUIを導入したのに、開発環境はキャラクタベースです。 ついでに言うと、会社支給のパソコンはFMRという独自規格。 それに富士通が出しているFMR用のDOSとWindowsとWindows SDKを入れて頑張るわけです。 (ちなみに、富士通の「DOS/V機」であるFMVは翌年秋の発売でした)

そんな中、 このプロジェクトが調査用に購入していたソフトウェアの中にQuick C for Windowsがあって、 これを動かしてみて私は衝撃を受けました。 フルGUIだし、「統合」されていて、ビルドからデバッグまでその上ですべてできる。 Windowsが普及し始めたころで、当時はWebとかもまだ広がってないためググるわけにもいかず、 Petzold本とかを頼りにプログラムを書いて色々挙動を確認するんですが、 この「ちょっと書いて動かしてデバッガで状況を見る」ということがGUI上で一目瞭然にストレスなくがんがん回せる。 生産性、という言葉では気が済まない、なにかパラダイムシフトのようなものが頭の中で起こりました。 目から鱗。

巧みな操作で計算機リソースを効率的に使う、 というのがスマートだと思っていました(まわりの達人的な人はほとんど共用ワークステーションとかにぶら下がってたし)。 しかし、考えたらこれは「パーソナル」なコンピュータなので、 CPUを自分の都合のためにぶん回すのは大正義である、 いや、自分が仕事を遂行するためにぶんぶんぶん回すべきである。 能天気にカーソルキー押しっぱなしてスクロールするのはCPUを無駄に使う頭悪そうなやり方だけど、 それで簡単に目的の場所に行けるならいいじゃないか。 「パーソナル」用機械を好きに使ってさっさと仕事しろよ、ということに思い至ったのでした。

人によってはVisual Basicが目から鱗だったりするようですが、 私はQuick C for Windowsだったなあ(いやまあ、Visual Basicも凄かったけど)。

ということで、 同じく調査用に海外から購入してたGateway 2000のマシン(鉄の筐体、純白の4DX2-66V)を占有し、 DOS/VとWindowsを入れ、Quick Cでごりごりプログラムを書いていました。

そんなこんなしているうちに

アメリカでVisual C++ 1.0が出ました。 「むっちゃ欲しい」と思うわけです。 IDEも進化しているみたいだし、CもC++になっているし。 でも日本では発売していない。

で、とある日曜日にOAナガシマに行ったら、 なんということでしょう。 置いてあるんですね。 でかい箱がでーんと置いてある。 おっさん、どこからモノを引っ張ってきたんだと思いました。 しかも、US価格から想定した値段よりかなり安い。 バッタもんじゃなかろうかとも疑ってまじまじと見てみましたが、どう見ても本物。 結局買いました。 両手でないと持てない大きさで、重かった。 開けてみると、中にはみっしりとWindows APIのマニュアルが入ってた。

当時の写真を探したら、箱が写っているものが一枚ありました。 あまりに部屋が乱雑で全景を出すのはアレなので、一部切り出しますが、箱の奥行をお察しください。

Visual C++の箱

探してみたら、フロッピーディスクまだありましたよ。

Visual C++のインストールフロッピーディスク

安かった理由は謎です。 仕入れ経路で誰か何か間違えてたか。 実はアップグレード版か何かだったりして。

ともかく、 Visual C++というアイテムを手に入れた私は絶好調でぶいぶいいわせながら開発したのでした。 当時まだ私物ソフトの使用禁止とかルール化される前でしたね。 まあ、仕上げには会社設備のMSCでコンパイルするようにはしてたけど。

その後

Visual C++はVisual Basicと統合されてVisual Studioになりました。

一方、 OAナガシマの方は、どんどん店が増えていきました。 本店は沢田から今ある大諏訪に移り、 ZOAという名前で静岡県以外にも店を出すようになりました。 今の正式な社名は「株式会社ZOA」のようですね。 その頃にはもうおっさんを店頭で見ることはなくなりました。 そういえば、Windows 2000の発表時には、 マイクロソフトの発表資料に他のメーカーやショップに並んで、 おっさんのコメントが載っていたなあ。 今検索して探し出したプレスリリースには社名しか出ていないけど、 当時のリリースではこのコメントがおっさんの名前入りで出てて、Webニュース経由で見てのけぞった記憶がある。

そして、一、二年前、 店の営業時間を確認するためにOAナガシマのサイトを見に行って、 間違って「会社概要」を開いてしまったら、 代表者の名前がおっさんじゃなくなっていました。 引退したのかな、とも思ったのですが、 気になったのでIRを見てみたら、 2013年の夏におっさんが亡くなったとの知らせが出ていました。

昔の沢田の店も、 去年更地になり、 ポルシェの店になりました。

その頃(もう四半世紀前)からすると、 PCをめぐる状況も、 OSやソフトや開発環境のあり方もずいぶん変わりました。 一方、その頃作っていたそのソフトは、 幸運にも気に入ってくれた人が結構おり、 バージョンを重ね、 まだ稼働しているものもあります。 ソフトウェアが世に出るのはいろんな人の仕事やら偶然やらが積み重なった結果なのですが、 あのソフトには「おっさんがVisual C++をどっかから引っ張ってきてくれた」という要素も入っているのです。

ということで、 おっさんのご冥福をお祈りします。 と同時に、Visual Studio 20周年おめでとうございます。

2016年12月 8日 (木)

Microsoft Cognitive Servicesがうらやましいのでパチもんを作ってみた

Fujitsu Advent Calendar 2016の8日目です。 なお、このエントリは個人の立場で書いております。

ディープラーニング関連の話を書こうと思います。 とはいえ、あまり技術的なものではないです。 技術的にすごい話は11日目のsakaiakiraさんや、 他の方が書くでしょう。 ここでは、ディープラーニングを勉強していて湧き上がる心の叫びのようなものを取り上げ、 その勢いでとあるサービスを特に意味なく実装することを試みます。

思うこと

要約すると、だいたい以下になるんですけど、

  • MicrosoftのCognitive Servicesがうらやましいという妬み
  • 自分がろくなデータを持っていないという悲憤

念のため。 これは私個人の話です。 富士通としてはディープラーニングをばりばりやっているところがあるはず。

今、多くのソフトウェア開発者がそうだと思いますが、 私もディープラーニングをぼちぼち勉強したりしております。 私としては、 ディープラーニングそのものももちろん興味深いのですが、 それをプラットフォームにしたり、 サービスにしたりといった方面により興味を持っています。

そういう意味で、 各クラウドの機械学習サービスだとか、 Microsoft Cognitive Servicesだとか、 GoogleのCloud Vision APIだとかを「いいなー」と見ています。

特に、 Microsoft Cognitive Servicesいいですね。 このCognitive Servicesには色々なサービスが含まれています。 LUIS(Language Understanding Intelligent Service)とかも重要そうですが、 私のお気に入りはEmotion APIです。 ディープラーニングの面白さがシンプルに出ていると思う。

Emotion APIは、 画像を送りつけると、 その中から人間の顔を検出し、 どういう感情を持っているかを推測します。 こんな感じ。

Emotion APIの画面

この例では、 お子さんの顔を検出して、 "happiness"とか"anger"とか8種類の観点での「確率」を計算しています。 この値はこの裏で動いている学習済みモデルの計算結果であり、 正確には確率とは言えないと思うんだけど、 全部足すと1になるように調整されているようなので、 確率っぽい数字になっています。 ここでは「確率」と言っちゃいます。 この例では"surprise"成分90%ですね。

Emotion API本体はJSONを返すWeb APIですが、 以下のWebページでAPIの動きを試すことができます(上の図はこのページ)。

Emotion API (Microsoft Cognitive Services)

Emotion APIは今年春先のBuildイベントで発表されました。 その際に私は「ほほう」と思ったもんで、 いろんな画像を突っ込んでみてブログを書きました。

Microsoft Cognitive ServicesのEmotion APIを使ってみた (使って色々思いを馳せた編) (2016年4月2日)

でですね、 こういうのを提供できるっていうのは、 大量に自前データを持っているからだと思うのです。 Microsoftも色々言われながら、 Bingやめなかったのが生きてますね。 API化するなら、自前データだよなあ(「自前って何」と考えると意外と難しいけど)。

ひるがえって自分なのですが、 いろいろお勉強して、 いっちょやってみよー、 と周りを見回すと、 ろくなデータがないのです。 今まで生きてきて私は何をしていたのだろうかと思ってしまいます。 ディープラーニング学習させるには、 従来とは桁違いの量のデータが必要だと思います。 かろうじて量があるのはテキストベースのデータなのですが、 自然言語は一筋縄ではいかないしなあ。 今の業務上も、あんまり処理するよによさげなデータが出てこない。

そこを工夫してデータを探し出したり、 公開情報をあさったり、 データを持っている誰かのところに出向いたり、 なんとか考えるんだ、というのは分かります。 分かります。 が、個人的にブログでぶっちゃけるぐらいはいいだろう。 「きちんとラベル付けられた大量で自前のかっこいいデータがほしい!(なるべく汎用API化できそうなやつ)」

ということで

以上で言いたいことは大体尽くしているのですが、 それだけではなんですので、 この思いをコードに託し、 Emotion APIの如きサービスを立ち上げてみました。

このサービスは、 顔の画像を送りつけると、 いくつかの観点それぞれに該当する「確率」を返します。 Emotion APIが"happiness"とか"anger"の「確率」を返すのと同様です。 その分類の数はEmotion APIの8分類をはるかに凌駕する10分類です。

では、そのサービスを試してみましょう。 Web APIももちろん用意していますが、 とっつきやすいWeb GUIもあります。 操作はEmotion APIの画面と一緒です。 先程のEmotion APIのお子さんの画像を入れてみると、こんな感じ。 スタイルが本物に比べるとしょぼいけど、気にしない。

Digit APIの画面

はい。 このサービスでは、 顔がどの数字(0-9)に一番似ているかを判定します。 顔の領域の検出機能は残念ながらありません。 というか、入力画像が顔であるかどうかも実は気にしていません。

お察しの通り、 このサービスはディープラーニングにおける"Hello World"たるMNISTをそのまま動かしています。 0-9の手書き数字を認識させるというやつですね。 手書き数字を識別するために訓練されたモデルに 何の関係もない画像を無慈悲に流し込むという鬼畜のごとき所業です。 CNNの無駄遣い。 しかも、 MNISTの入力に合わせるため、 入力画像は問答無用に28 x 28のグレースケールにリサイズします。

要するに、 学習すべきいけてるデータを持たないので、 思い余ってMNISTをそのままAPIにしてみました。 サービスのURLは以下です。

Ipponshimeji Cognitive Services - Digit API

【2017年1月17日追記】 このサービスの稼働は年末で終了させました。

モデルの学習は、 Microsoft Cognitive Toolkit (CNTK)を使っています。 以下のサンプルの03_OneConvDropout.cntkをほぼそのまま実行しています。

CNTK/Examples/Image/GettingStarted/ (GitHub)

ただし、最後の出力だけ変えています。 目的がクラス分けではないので、各ノードの値をSoftmaxを通して「確率」が出力となるようにしています。 この変更も含め、 サービスのソースもGitHubに置いています

CNTKの評価ライブラリの利用については、 はまったところもあるので、 覚えていればまたブログに書きたい。

注意事項など

このサービスはアドベントカレンダーの期間中くらいは動かすつもりです。 Azure Web AppsのB1インスタンス1個(1コア)で弱々と動かしています。 スケールさせるような余裕はありません。 まあ、そんなことはないと思いますが、アクセスする酔狂な人が大量にきたらパンクするかもしれない。

また、判定した画像は保存していません。 ローカルマシンのファイルをアップロードして判定させた場合でも、 そのファイルは保存しません。 メモリ上だけで処理しています。 ただ、「全体でリクエストがいくつあったか」「判定結果」だけはログを取ります。 どの数字に似た画像が多いのかはちょっと興味あるし。

あと、再度念押しですが、このサービスは個人的に勉強がてら作って試しているものです。

おわりに

このサービスの実用性はまったく無いんですけど、 せっかく作ったので、 「誰の顔が一番数字の4に近いか」勝負とか、 忘年会の余興にでもご活用ください。

何人かの写真をぱしゃぱしゃ撮って、 スコアを出して順位をつけるスマホアプリとか作ってくれてもええんやで。

2016年12月 2日 (金)

子供に持たせるスマホとしてWindows 10 Mobileは結構いいですよという話

Windows 10 Mobile / Windows Phone Advent Calendar 2016の2日目です。

Windows 10 Mobileは子供に持たせるスマホとしてもいいですよ、という話を書こうと思います。

ここでの「子供」は小学・中学生くらい。 その子らに「なにかあったらこれで連絡しろ」と持たせるようなやつですね。 うちの場合、中1と小6の子供に、WPJ40-10(セール価格で6980円)にLINEモバイルのLINEフリープラン(データのみ 500円/月)のSIMを入れて持たせています。 計2台を運用。 このあたりの経緯は過去に書きました。

なぜWindows 10 Mobileかと言うと、ぶっちゃけ私がWindows 10 Mobile推しだからです。 とはいえ、 子供に持たせる端末として真面目に考えた場合、 iOSほど高価じゃない端末が選べるとか、Androidよりフリーダムじゃないとかの利点があります。 が、ここでは、それら利点の中でも、Microsoft アカウントを通したペアレンタルコントロールがしっかりしているという点を中心に書こうと思います。

ざっと、以下のような内容かな。

  • Windows 10 Mobileでのペアレンタルコントロール機能
  • iOS/Androidとの比較
  • 三カ月ほど使ってみて

まず、ペアレンタルコントロールとは

ペアレンタルコントロールとは、 子供のデバイスやPCアカウントなどに対して保護者が機能制限をかけることができるようにする機能です。 例えば、以下のようなことができたりします。

  • 年齢制限のあるコンテンツや有害コンテンツへのアクセス制限
  • 特定のアプリの利用制限
  • 課金の管理
  • 子供のデバイスの現在地を探す
  • 利用状況のレポート

Windows 10 Mobileでのペアレンタルコントロールの便利なところ

Windows 10 Mobileデバイスが便利なのは、 ペアレンタルコントロールの設定がWeb側で管理されていることです。 今時できて当然のように聞こえますが、 後述するように、 iOSもAndroidも(少なくとも現時点では)できていません。

そのおかげで、 子供のデバイスが手元になくとも管理作業ができます。 例えば、 禁止サイト中にどうしても見たいページがある場合、 子供はアクセス許可リクエストを保護者に送ることができます。

「アクセス許可をリクエストする」画面

この画面のボタンを押すと、 保護者にリクエストメールが飛びます。 保護者はメール中の「許可」ボタンまたは「無視」ボタンを押してリクエストに応えることができます。 保護者は子供のデバイスに触る必要はありません。 外出中であってもネットに接続できているならば対処可能です。 もちろん、メールを受け取る保護者のデバイスがWindowsである必要もありません。

ペアレンタルコントロールの設定方法

このペアレンタルコントロール設定は、Microsoftアカウントの「ファミリー」設定の一部になっています。 自分の「ファミリー」に子供のMicrosoftアカウントを「子供」として登録すると、 その子供アカウントに対してペアレンタルコントロールをかけることができるようになります。 ちなみに、「ファミリー」に「おとな」としてアカウントを追加すると、ファミリーに保護者が追加されたことになります。

Microsoftアカウントの「ファミリー」設定ページには、 Microsoftアカウントのホームにサインインすることでアクセスすることもできますし、 Windows 10にMicrosoftアカウントでサインインしている場合は「設定」-「アカウント」-「家族とその他のユーザー」の「オンラインで家族の設定を管理」リンクから飛ぶこともできます。

「ファミリー」画面

このページで、対象となる子供アカウントの各リンクから各種コントロール項目を設定できます。

ここでの設定は、Windows 10 Mobileデバイスだけでなく、Windows 10 PCも対象になります。 つまり、 この子供アカウントでのWindowsデバイス上での活動全体をここで集中的にコントロールできます。 上の図で子供アカウントに「2デバイス」と出ているのは、 うちではWindows 10 Mobileに加え、家の共用PCもこの子供アカウントで利用しているからです。

Microsoftアカウントの「ファミリー」の説明は以下でしょうか。

ただ、USの話をそのまま翻訳したんじゃないかという内容もあります。 以下は明らかにUS限定だよなあ。 こんな課金された覚えないし。

ペアレンタルコントロールの例

「ファミリー」の設定を通して、具体的には以下のようなことができます。

  • 最近のアクティビティ(活動状況)の確認
  • アクティビティのレポートを週ごとに保護者へメール
  • 適用するコンテンツ年齢制限の設定
  • 特定のWebサイトアクセスの許可・不許可
  • 特定のアプリ・ゲーム実行の許可・不許可
  • 1日あたりの時間制限と使用許可時間帯の設定(PCへのサインインにのみ適用)
  • ストアからの購入できるものの制限
  • 子供アカウントへの入金(ストアで利用するための小遣いみたいな感じ)
  • 子供のデバイスの位置情報の表示

例えば、子供のデバイスの位置情報を表示する「地図で[名前]を検索」はこんな感じ。

「お子様を探す」機能

奴は今沼津駅。

iOS/Androidとの比較

iOSもAndroidもペアレンタルコントロールをWeb側で集中管理できるようにはなっていないようです。

iOSの場合、デバイスのペアレンタルコントロール(iOSでは「機能制限」という名前になっています)はデバイスごとに行います。 「機能制限」用のパスコードを知っている人(例えば保護者)が機能制限を設定できる仕組みです。 つまり、機能制限を設定・変更するには、そのデバイスが手元になければなりません。

一方、Apple IDには「ファミリー共有」という機能があり、 家族のデバイスの居場所を探したり、メンバーのiTunesでの購入を制限したりできます。 しかし、iOSデバイスのペアレンタルコントロールとは連携していないようです。

Androidには、OSレベルでのペアレンタルコントロール機能は見当たりません。 強いて言えば、マルチユーザー機能を使って制限付きプロファイルで子供に使わせるのかな。 タブレットではそうできると説明にあるけど、スマホでそれができるのかよく分からない。 ただ、Google Playにはペアレンタルコントロール機能があるようです。 デバイスごとにペアレンタルコントロール管理者用のPINを設定し、 そのPINを知っている人が制限を設定・変更できます。 デバイスごと設定するという点はiOSと同様ですが、 対象がデバイスではなく、Google Playに限定されているわけです。 また、Google Playにも「ファミリーグループ」がありますが、 Google Playでの購入と共有にしか影響しないようです。

Windowsの場合、 上で説明したように、Web側でペアレンタルコントロールを集中管理するようになっています。 これは便利である反面、Microsoftアカウントの利用が必須となってしまいます。 Windows PCもWindows 7世代まではデバイスごとに設定する方式でした。 ローカルIDのままWindows 10に移行したい人にとっては不都合かもしれません。

また、どのデバイスの場合でも、キャリアが提供するサービスや、 セキュリティソフトなどが提供するペアレンタルコントロール機能を利用する方法も考えられます。 が、PCはともかく、スマホの場合、 こういう機能はOSレベルで面倒見てもらう方が筋がいいんじゃないかなあ。

三カ月ほど使ってみて

子供達に色々設定したWindows 10 Mobileを渡して三カ月ほど経ちました。 気に入ってもらえているようです。 まあ、自分のデバイスが持てたというのが大きいんだろうけど。 見ていると、連絡がとれて、Webを見れて、カメラとマップと多少のSNSアプリがあればたいてい事足りているようです。 そういえば、画面が小さいので、縦持ちだとtwitterの公式アプリの「ツイート」ボタンが画面外に出てしまうという問題があったな。 これが高校生とかになるとiPhoneとか欲しがったりするわけですが(高校生の上の子はiPhone使っています)。

ところで、うちの娘は順調に腐りつつあります。 レポートの閲覧履歴とか、なにかやば気な気配が漂うわけです。 レポートには検索ワードも含まれているのですが、 見てはいけないような気がして大丈夫だろうかと思うのです。 検索ワードとかも見られる可能性があることをそれとなく伝えるべきだろうかと迷うのですが、 まあこれも一種のリテラシーなので、 なにかに感づくまであえて黙っていようかなと思っています。

一方、息子は、お母さんの目がないとひたすらYouTubeでゲーム実況を見ています。 あまりに見過ぎるので、YouTubeを一定時間見続けたら「ゴルァ」とメッセージが送られ保護者にも通知が飛ぶ仮想おかんサービスとか作れないかなあと思いました。 が、どうも「ファミリー」はAPIを公開していないようです。 コミュニティにもAPIについて質問している人がいました。

Is there a Family Safety API?

2014年時点で「公開APIないよ」という回答で、 今年また「あれから2年たったけど、どう?」と聞かれて「ない」とそっけなく答えられているので、 望み薄ですかねえ。 何かが一定の値を越えると呼び出されるWebHookみたいなの登録できたらすごく楽なんだけど。 結局、息子には対しては手動で対処しております。

ともかく、このような用途だとWindows 10 Mobileは本当にぴったりだと思うし、 万が一、高校生ぐらいになってもWindows 10 Mobileを使い続けようという気になってくれた時のためにも、 ぜひWindows Mobileには存続していただきたいと思います。

また、今は私(と妻)が子供を見守っている立場ですが、 あと30年もすれば私ももうよぼよぼで「ファミリー」で見守られる方になるかと思います。 「おじいちゃんが散歩と称して出たまま帰ってこない!」「『おじいちゃんを探す』で探せ!」とか、 「アクティビティレポートで見たけど、おじいちゃんそのアニメ昨日見たでしょう?」「ボケてるんやない!好き好んで繰り返し見とるんじゃあ!」みたいな 未来を目指してソフトウェアを開発しつつ生き延びていく所存ですので、 その時まで「ファミリー」も進化していってほしいと思います。

ということで

Windows 10 Mobile / Windows Phone Advent Calendar 2016の2日目でした。 3日目はChiiAyanoさんです。というか、1日目もそうだったから、折り返し?

2016年9月12日 (月)

子供らのWindows 10 Mobileの話(高まるLINE圧力編)

先日の「子供らの「つなぎ携帯」をWindows 10 Mobileにしてみた話」のつづき。

子供らは手に入れたスマホを熱心にいじっています。 まあ、しばらくの間はねえ。 「勝手にゲーム入れるなよ」と言っておいたのですが、 下の息子はそれならばと、 ブラウザで昔懐かしいCookie Clickerを始めました。 今日もひたすらクッキーを増やしております。

さて、 LINEをどうするかという問題が懸案として残っていました。 特に娘は部活のメンバーがLINEを使っているし、 妻が日常的にLINEを使っていることもあって、 「LINE入れろ」圧力が家庭内で高まっております。

問題点は、 データ通信しか契約していない回線でどうやってLINEの初期認証を行うかでした。 多少じたばたやってみたので、その覚え書きのようなもの。

  • LINEのFacebook認証はWindowsでは使えない
  • MVNOではLINEの年齢認証ができないらしい
  • LINEモバイルとな?

LINEのFacebook認証はWindowsでは使えない

電話番号なしでLINE登録といえば、Facebook認証。 しかし、色々試したのですが、 結局WindowsではFacebook認証は利用できないようです。

※Facebook認証は、iOS⋅Androidのみ利用可能です。
SMSが使えず、Facebookによる認証も行えない場合、LINEに登録することはできません。

LINEのヘルプ - Windows Phoneから「SMSが使えない場合はどうしたらいいですか? 」

だそうです。

もう面倒くさくなって、 娘のWindows 10 MobileにLINEアプリを入れ、 家の固定電話の電話番号と関連付けてしまいました。

でも、 うちには他に余っている電話番号がないから、 息子がLINEやりたいといい始めたらもう使える番号がない。

MVNOではLINEの年齢認証ができないことがある

年齢認証はキャリアの契約情報を見ているようで、 MVNOのSIMでは年齢認証できないことがあるようです。 年齢認証できないと、ID検索等の一部サービスが利用できません。

年齢認証は、au(KDDI)、NTTドコモ、ソフトバンクモバイル各社が提供する年齢情報判定サービスを利用し、18歳未満かどうかを確認しています。
契約したSIMが上記3社で提供している年齢情報判定サービスをご利用いただけない場合、年齢認証はできません。

LINEのヘルプから「格安SIMを利用しているが、年齢認証ができない」

この書き方だと「できる場合もある」ようですが、 Webでほかの人の書いているのをざっと見た印象では、 「ふつうはできない」感じ。

まあ、うちの子らはどっちみち年齢認証できる年齢じゃないから関係ないけど。

LINEモバイルとな?

そんなこんなでやっていると、 タイミングよくLINEモバイルが発表されました。

LINEモバイル

一番安いプランだと、

  • LINEの基本的な機能(LINE通話も含む)は使い放題
  • その他のデータ通信は1G/月

で、500円/月。 うちの用途だと、 コミュニケーションをLINE中心にすれば、このプランで十分まかなえるんじゃなかろうか。 子供二人分だと1000円/月で、現在の約2000円/月の半額。 まあ、データ容量は少なくなるし、おまけで運用しているわしのSurface 3の分がなくなるけど。 しかも、SMSなしでアカウント登録できるし、年齢認証にも対応。 ごちゃーごちゃやってた苦労がいらんようになるやないですか。

2週間早く発表されてたら申し込んでいたと思うけど、 もう事務手数料払ってDMM mobileと契約しちゃったからなあ。 正式提供は10月1日からのようなので、 その後回線の評判がよいようならば、 乗り換えるかも。

ということで、 家族グループ内でスタンプが飛び交っております。

2016年9月 4日 (日)

子供らの「つなぎ携帯」をWindows 10 Mobileにしてみた話

下の子供二人に当面持たせる携帯をWindows 10 Mobileにしたという話。

経緯

うちには子供が三人います。 一番上(高校生)はiPhoneを使っています。 高校に入学する時に本人の希望を元に話し合い、 三年間使い続けるという条件でiPhone 6を持たせました。

その上の子には、 高校入学前、 おでかけなどの際の連絡用に単純機能のガラケーを持たせていました。 それは今「おさがり」として下の子ら(中1と小6)が使っています。

で、MVNOが普及してきた昨今、 このガラケーの維持費が機能のわりに割高に思えてきました。 基本料が月1700円くらいで、 帰省やらおでかけやらで実際に通話したりすると3000円越えたりしています。 一方、 例えばDMM mobileのSIM 3枚で月8Gを共有するシェアコース(データ通信のみ)は月額2138円(税込)です。 同じくらいの料金で子供二人分のスマホと私のSurface 3の回線が維持できるではないですか。

ということで、 下の子二人が自分で選んだスマホをもつようになるまでの「つなぎ携帯」として、 シンプルで安価なスマホを買い、データ通信のみで運用してみることにしました。

機種選定

目的から当然SIMフリーの廉価版スマホになります。

まず、iPhoneはこの用途には高価すぎる。

Androidも我が家では印象がよくありません。 うちのNexusに子供らが怪しげなゲームを入れまくって動作をおかしくさせたという過去が脳裏をよぎります。 また、「廉価版Android機」という字面を見るだけでもう怪しさ爆発します。偏見だけど。

ということで、 Windows 10 Mobileにします。 Windows 10 Mobileでペアレンタルコントロールを効かせたスマホを持たせるようにしましょう。 Windows 10 Mobileで不安な点といえば、

  • アプリが少ない
  • (個人的には頑張ってほしいけど)将来性が見えない

ですが、必要最小限のアプリはありますし、怪しげなアプリが少ないのはこの用途の場合むしろありがたい。 また、どうせ本格的にスマホを持つようになる頃には本人が選び直すだろうから、 向こう三年くらい使うことができれば十分でしょう。

ちょうど、NTT-X StoreのセールでWPJ40-10が安くなっていたので、それにします。 6980円(送料無料)。 白と黒のモデルがあるので、それぞれ一つ。

WPJ40-10

geaneeのWPJ40-10のページから

それぞれ三色のリアカバーがついているので、 好きな色を選ばせることにしましょう。

SIMは上で述べたDMM mobileのデータSIM 3枚のシェアコースにします。月8Gで1980円。

セットアップ

まず、起動して初期設定をした後、 「システムの更新」をかけて最新のWindows 10 Anniversary Updateへアップデートします。

設定中

そして、各自のMicrosoftアカウントと紐づけ。 うちでは、共有の「リビングPC」に各自のMicrosoftアカウントでサインインするような使い方をしていますので、 子供らもMicrosoftアカウントを持っており、 私のペアレンタルコントロールの管理下にあります。 ですので、それを登録するだけで、 メール、カレンダー、OneDrive、OneNote等は関連付け出来ます。 あと、カメラやらMapやら天気やら標準アプリの初期設定。

次にSlack。 うちは家族間の連絡にSlackを使っています(「家族間の連絡手段をLINEからSlackにしてみた話」参照)。 そういえば、 Slackがわりと受け入れられたので、 Wunderlistも導入してみたのですが、 こちらはほとんど使ってもらえていません。 もう一工夫いりそう。 まあ、これは別の話。

さらに音声通話。 データSIMを入れることにしたので、電話番号による携帯回線での通話ができません。 こちらはSkypeを使います。 「インターネット電話」的なものは他にもありますが、 スリープ状態でも着信を取ってくれるものだとやはりネイティブアプリで、 ネイティブアプリをWindows 10 Mobileにも提供してくれているものとなると、 やはりSkypeかなあと。 Microsoftアカウントで使えるのも便利だし。 ということで、 Skypeを入れ、 家族間のSkype網を整備。

後のアプリは必要に応じて入れていくようにしましょう。

最後にクラウド側。 各自のOutlook連絡先を整理。 ペアレンタルコントロールの設定をチェックし、 「お子様のデバイスの位置情報を表示」をオンに。 PCでMicrosoftアカウントを使っているので、 OneDrive等の共有設定は既にできています。

で、セットアップ完了して、 子供らにスマホを渡しました。 下の息子がスマホいつ貰えるんだとしょっちゅう聞くので、 妻が閉口してました。 リアカバーは娘がピンク(彼女のDSとおそろい)、 息子がブルーをご選択。

リアカバー

よかった点

まず、 安く携帯を持たせるという目的を達することができました。

費用(消費税込み)
対象金額備考
初期費用スマホ本体13,9602台
DMM mobile 契約事務手数料3,240
micro SDHCカード2,16032G * 2
運営費/月DMM mobile 回線料金2,1388G共有

スマホ本体の動きも上々です。 CPUがSnapdragon 210でメモリー1GというロースペックはAndroidならばまともに動くような気がしませんが、 Windows 10 Mobileならサクサク動き、実用上まったく問題ありません。 バッテリーも十分持ちます。 このあたり、Windows 10 Mobileの仕上がりの良さを実感します。

事前に見た実機レビューでは、 液晶パネルが弱いというのを読んでました。 まあ、Retinaディスプレイのようなものとは比べようもありませんが、 十分きれいです。 ただ、視野角は確かに狭い。 数人で覗き込むような場合は見ずらいかも。 あと、パネルは指の滑りが悪いので、 保護シートは必須。

Microsoftアカウントがそのまま使うことができ、 PC環境と連携できたことも便利でした。 娘が試しにブラウザでpixvを見ようとして、 ブラウザが検索履歴とか覚えている(PCの履歴と同期している)ことに感心していました。 GoogleでもAppleでも自社モノの設定の同期できると思うけど、 PCと連続性があるのがうちの場合うれしい。

Microsoftアカウントのペアレンタルコントロールの「お子様を探す」も使ってみました。 息子が習い事に行っている時に「探して」みると、 マップ上、鉄道路線上を移動して、 駅で乗り換えている様子が見て取れました。 奴がくそまじめな顔で電車で運ばれているかと思うと、なんかじわじわくる。 まあ、四六時中監視するつもりはありませんが、 いざというとき場所が分かるのは便利。

課題

LINE問題。 部活のメンバー間の連絡とか、 習い事の先生との連絡とか、 今時LINEだそうですよ。 私は複数デバイスやPCとの並行利用がLINEではやりにくいので家族内の連絡にSlackを導入したんだけど、 周りがLINEなのでLINEは必須だと言われてしまいました。 LINEアプリ自体はWindows 10 Mobileにも提供されています。 しかし、問題はLINEアカウントを取得する際の初期認証です。 初期認証に電話回線を通した実在確認(SMSまたは通話)があります。 現状、完全データ通信の契約なので、SMSもできません。 SMS付きだと一回線あたり150円/月アップです。 LINEアカウントにはfacebook認証という方法もあるらしいと聞いたので、 もう少し調べて、どうしようもなければSMSオプションを考えますかね。

電話番号問題。 データ通信契約なので、契約回線で直接通話することができません。 代わりにSkypeを使う計画なわけですが、 Skypeで「電話番号」へ発信するには別途料金が必要です。 まあ、必要な際に実費を払えばよいわけですが。 そもそも、音声通話の主な目的は家族内連絡なので、 電話番号発信はほとんど機会がないはずです。 むしろ問題はSkypeからの発信だと受け側に「発信者不明」と出てしまうことかな。

一方、受信側。 外部から子供らのスマホへ「電話番号」で電話をかけることができません。 これに関しては、ほとんど必要ないんじゃないかな。 LINEを使うようになれば、友達とかとはLINEとLINE通話を使うんじゃあなかろうか。 別途料金を払えば、Skypeで050番号を取れますが、 それなら回線を音声通話付きに切り替えた方が無難そうだなあ(一回線あたり700円/月アップ)。

で、まあ、多少できないことはあるけど、 当面の利用ではSkypeで十分だと思います。 ただ一点、 この方針だと緊急通報(110や119)できない、 というのはちょっと気になります。 うーん。

しばらく運用してみて、 あかんと思ったら音声通話付きに回線を切り替えますかねえ。

そういえば、 息子が習い事の先生にスマホを自慢したら、 「電話番号教えてよ」と言われて「うーん、よくわかんない⤵」みたいな会話がいきなりあったらしい。

まとめ

思惑通り、 わりと低予算でガラケー1台をスマホ2台(+わしのSurface 3の回線)に置き換えることができました。

子供らにも気に入ってもらえたようです。 ガラケーと違って、大きめの画面でインターネットにダイレクトにつながるのは新鮮らしい。 ぼちぼち使いながら、 リテラシーなど身に着けていってほしいと思います。

なお、これにより、家庭内の携帯プラットフォームにおいてWindowsがトップシェアとなりました。 元々、2014年度まではWindowsがトップシェア(ただし同率)でしたが、 近年iOSに押されていました。 しかし、今回のガラケー置き換えにより、再びトップシェアに返り咲いたのでした。

我が家のスマホシェア

この調子で、グローバルでもWindows Mobileが存続可能になるように頑張ってほしいです。 いや本当に、今回のようにiOSでもAndroidでもはまらないニーズがあると思うんで。

シアトルの宇和島屋とわたくし

この夏、八幡浜へ帰省して(「帰省メモ:宇和海と八幡浜のこと」)、 ちょっと思い出したことがあったので書き留めてみます。 シアトルにある宇和島屋というスーパーの話。 大した話じゃないけど。

2000年代、開発していたソフトウェアの関係で、私はしばしばMicrosoft本社に出張に行ってました。 Microsoft本社はシアトル郊外のレッドモンドにあります。 最初の出張は確か直前に同時多発テロが発生し、 会社の渡航中止命令が出てキャンセルになった覚えがあるから、 あれはその翌年だったかなあ。 初めてMicrosoftキャンパスに行き、 近くに取ったホテルの周りを散歩していたら、 交差点の角にUwajimaya(宇和島屋)というスーパーがありました。 宇和島といえば私の生まれた八幡浜の南にある町で、 私の原点である「急行うわじま」の名前の由来の町です。

何やこれは、と思って入ってみたところ、 まあ普通のスーパーでした。 醤油とかお菓子とかで日本物の品ぞろえがありました。 あと、小さな日本グッズコーナーがあったような気がする。

ホテルへ帰った後、WebでUwajimayaのページを見てみました。 本店はシアトルにあり、私が行ったのはベルビュー店のようです。 会社の歴史を見てみると、 予期した通り日系の人が開いた店でしたが、 その創業者(森口富士松)は八幡浜生まれの人でした。

The Whole Story (Uwajimaya)

単身レッドモンドにやってきて、 「あんたらの言うてることと実際の動きが違うやんけー」とかカタコト英語でやりとりして、 きっついなーとか思いながら歩いていて出くわしたものが同じ町生まれの人が異郷に開いた店で、 「縁やのう」と思ったのでした。 まあ、それだけの話なんですけどね。

八幡浜は今でこそ過疎化が進む地方都市ですが、 商業が盛んだった時期があるようです。 思い出してみれば、 祖父母の世代には結構ハイカラな人が多かったような。 城下町だった大洲や宇和島と比べて、 八幡浜はもともと漁港だったせいか、 さばけて外向きな気風があったように思います。

祖父の姉もシアトルに移住していました。 戦中、収容所に入れられて戦後日本に引き上げてきました。 この人もハイカラな人でしたが、 収容所の話は一切しなかったといいます。 上記の宇和島屋の歴史にも収容所のことがさらりと書かれてますね。 色々歴史あり。

最初のレッドモンド出張後、 しばらくして宇和島屋の創業者の奥さん(Sadakoさん)が亡くなったという知らせを何かで見かけました。 上記の歴史によればこれは2002年夏とのことなので、 やはりあれは2002年前半かな。 八幡浜世代が生きている間にその土地に行ったのかと思い、 ちょっとした感慨をもった覚えがあります。 いや、まったく面識とかないのですが。

これを書くにあたってちょっと検索してみたら、 今は日本語のWikipediaにも項目ができていました。 これを読むと、結構有名なのか。

宇和島屋 (Wikipedia)

あと、私が行ったベルビュー店は移転したのかな。 今検索したら、ベルビュー店はベルビューのダウンタウン近くになっているけど、 私が行ったときはMicrosoftキャンパスの少し南にあった。