月: 2016年2月

システムの廃棄

IT業界でシステム開発に携わって、かれこれ15年が経ちました。

大規模システムの保守や機能拡張もやってますが、どちらかというと新しいシステムを一から作る事が多かったです。小規模なシステムだと、納品後数ヶ月くらいで安定運用できてくるので、それ以降クライアントからは音沙汰なし、というケースも多々あります。

最近、5〜6年前に私が開発したシステムを運用終了するという話を、偶然耳にしました。クライアントの当時の担当者が定年退職を迎えた事がきっかけのようです。

ソフトウェアは賞味期限付きのナマモノなのだなぁと、改めて実感しました。

ソフトウェアの経年劣化とは

表面的には、ソフトウェアに経年劣化はありません。今日でも、100年後でも、全く同じように動きます。ソフトウェア本体は不変でも、周囲の環境が変わるため、相対的に賞味期限切れになるのです。

例えば、昔のWebアプリは、WinXP + IE6のPCでのみ動作保証する事が当たり前でした。今、このPCを調達するのはまず無理です。業務ニーズが変わり、従来のシステム仕様のままでは使えないケースもあります。

結局、ソフトウェアを長く使おうとするなら、保守が欠かせないわけです。では、保守できているかどうかは、なにで決まるのでしょう？過去の経験を振り返って考えてみました。

イニシャルコストだけでは長く使えない

IT業界でよく言われている、設計書などの開発ドキュメントの有無というのは、実は直接関係ないのかなと思います。そうではなくて、”ランニングコスト”をきちんと払っているかどうかです。

システム開発は、クライアントから見るとイニシャルコストです。開発が終わって運用が始まると、そこから先がランニングコストです。

クライアントが開発ベンダーと保守契約を結んでランニングコストを払っている場合、仮にある開発者が離任することになっても、保守責任を全うするために「引き継ぎ」という作業が必ず発生します。逆に、保守契約がなければ、ベンダーには引き継ぎしたくなるモチベーションがありません。開発ドキュメントが整備されていようがいまいが、同じことです。開発ベンダーが個人事業主でも大企業でも、同じことです。

開発ベンダーに頼らず、クライアントがプログラミングのできる社員を保守担当に据えるケースもあります。これも、ランニングコストの支払い先が開発ベンダーから自社社員に変わるだけで、本質的には同じことです。

長く運用されているシステムは、どれも相応のランニングコストをかけています。

 

 

なぜ？

私の嫁がアメーバブログ（アメブロ）をやっているのですが、つい最近までバックアップを一切取っていませんでした。まだ始めてから１年くらいしか経っていませんが、ほぼ毎日更新しています。ですので、このデータが消えたらきっと立ち直れないだろうなぁ、というくらいの記事数になっています。

データが消えると言っても、ブログ管理者が、「システム障害発生。バックアップから復旧しようとしましたが、失敗しました。ごめんなさい、てへっ。」と釈明するような事があるとは思っていませんし、「規約違反により、あなたのブログは削除されました。ご愁傷様です。」いう背筋の凍る告知を受ける事もないと思っています。

私が心配しているのは、３歳の息子が嫁のスマホを勝手にいじってブログ閉鎖してしまうだとか、嫁が誤操作して違う記事を消してしまうといったケースです。

結局、自分でスクリプトを組みました

そういう訳で、ブログ記事をバックアップしてくれるツールを探してみたのですが、ピンとくるものが見当たりませんでした。有償のブログバックアップサービスなどもありましたが、追加のランニングコストをかけてまでやるのは、あまり気が進みません。

なので、自分でツールを作る事にしました。以下が、実際に作ったスクリプトです。

<?php
function get_blog_rss($max, $url) {

    if (ini_get('allow_url_fopen')) {
        $rss = simplexml_load_file($url);
    } else {
        $ch = curl_init($url);
        curl_setopt($ch, CURLOPT_HEADER, false);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        $xml_raw = curl_exec($ch);
        $rss = simplexml_load_string($xml_raw);
    }

    $cnt = 0;
    foreach ( $rss->channel->item as $item ) {
        $cnt += 1;
        $pubDate = strtotime($item->pubDate);

        if (strpos($item->title, 'PR:', 0) === FALSE) {
            $filename = basename($item->link) . date('.YmdHi', $pubDate) . ".webarchive";
　　　　　　　# webarchiverのインストールが別途必要です
            system("/opt/local/bin/webarchiver -url {$item->link} -output {$filename}");
            print("[". date('Y-m-d', $pubDate). "] " . $item->title . " -> " . $filename . "\n");
        }

        if ($max <= $cnt) {
            break;
        }
    }

    return $list;
}

# 最近のPHPは、タイムゾーン指定が必須です
date_default_timezone_set("Asia/Tokyo");

# 最大バックアップ記事数と、RSSのURL(xxxxは、アメブロのアカウント)を指定します
get_blog_rss(10,'http://feedblog.ameba.jp/rss/ameblo/xxxx/rss20.xml');

PHP 5.5.30で動作確認しています。このスクリプトを動かすには、webarchiverというツールを、（MacPortsなどを使って）別途インストールする必要があります。
ターミナルから、以下のコマンドを入力すると動きます。

#"/path/to/"は、スクリプトの配置先パス
php /path/to/rss_archiver.php

このスクリプトでは、アメブロのRSSから最近の記事一覧を取得して、各記事を、SafariのWebアーカイブ形式でMacのハードディスクに保存しています。

Webアーカイブは、Safariで直接表示できます。ページのテキストや画像がそのまま１つのファイル（正確にはバンドル）にまとめられているので、ファイル管理も楽チンです。

プログラマーの目線で見ると、アメブロって扱いづらいですね。RSSくらいしか使えるAPIがありません。

 

今のところ、イメージ通り使えてます

私は、これを週１回、手動で起動する運用にしています。スケジュールを組んで自動起動させることもできるのですが、バックアップがきちんと取れている事を随時確認できるので、実は手動のほうがお手軽かつ確実だったりします。

このツールを、Macアプリ・Windowsアプリ化して広くリリースすべきでは？とも思ったのですが、私自身はこのスクリプトでイメージ通りの運用ができているので、思いとどまっています。リクエストあれば、ご連絡ください。

 

超小型ドローンプロジェクト「Zano」の頓挫

クラウドファンティングサービスを提供しているKickStarterで、４億円以上の出資を獲得した超小型ドローンプロジェクト「Zano」が、2015年11月に頓挫しました。

Kickstarterは、フリーランス記者のMark Harrisさんに、Zanoプロジェクトが頓挫するまでの経緯をまとめて、記事にして欲しいと依頼しました。その記事がこちら。

実は私、このプロジェクトのBacker（出資者）でした。２万円出資して、見返りに超小型ドローンを１台もらう予定でしたが、頓挫により、手元には何も残らないことが確定しました。ああ、悲しい。

プロジェクトの失敗が投資につくまとう当然のリスクであることは、Backerになる前から理解していました。でも、頓挫を知った時はとてもショックでした。なぜそう感じたのか？そこを深く考えた時、少し見えてきたものがあります。

「寄付」と「購入」

クラウドファンディングに出資するBackerには、「寄付」と「購入」の２つのマインドが混在しています。「寄付」は、直接的な見返りを求めないでお金を渡す行為。対して、「購入」は見返りを貰う前提でお金を渡す行為です。

今回の私は、「寄付」ではなく「購入」のつもりでした。もしこれが、応援したいという気持ちからの「寄付」であれば、特に落ち込むこともなかったと思います。

では、なぜ「購入」のつもりになったのか？表面的な見方をすれば、「２万円投資する見返りに、Zano本体を１台送ります」というプランを選択したからと言えますが、失敗する可能性がある事は理解していたので、そのプランをそのまま鵜呑みにした訳ではありません。

「購入」しようと思った理由

決め手となったのは、デモ動画でした。とても滑らかにスイスイと自在に動く超小型ドローンを見て、「お金さえあれば、すぐにでも量産できるんだ！」と勝手に思い込んでしまったのです。

一般的な製品開発プロセスは、「商品企画」→「試作」→「量産準備」→「量産」です。消化できてないプロセスが多い程、失敗リスクが大きいです。まだ「試作」中のプロジェクトよりも、後は「量産」を残すのみというプロジェクトの方が、失敗リスクが少ないということです。私はデモ動画を見て、Zanoプロジェクトは「量産」を残すのみなのだ、と勘違いしてしまったため、「購入」同然だと思ったわけです。

残念な現実

ですが、Markさんの記事によると、実態は違ったようです。試作機は、基本的な飛行性能の品質が不十分で、まだ「試作」が終わっていない状況。「量産」にかけるべき出資金を、試作開発で使い込んでしまったようです。（他の用途でも使っているようですが、ここでは割愛）

冷静に考えれば、デモは何回でも撮り直しできるし、”編集”という魔法も使えるから、デモ動画では試作機の本当の品質は評価できないですよね。
もし、投資する前に私がそこを理解できていれば、「寄付」のつもりでもっと少額のプランを選んでいたと思います。２万円という安くない金額をすんなり出せたのは、「購入」するマインドだったからです。

Backerには批判的な姿勢が必要

トヨタ生産方式や失敗学でしきりに言われている、「現地・現物・現人」の大切さを改めて感じました。そこまでしないと、本当の事実は掴めないのだと。
とはいえ、クラウドファンディングの世界では、プロジェクトオーナーと面識もなく、直接会話できる関係にもないのが普通なので、それが難しい。できることといえば、批判的な目でデモや資料に目を通し、疑わしい点があれば、別の情報ルートから裏を取ることくらいでしょうか。クラウドファンディングの出資者には、そういう姿勢が必要なのだろうと思います。
「寄付」のつもりなら、プロジェクトオーナーの言い分を鵜吞みにしても良いと思います。Facebookでいう「いいね！」みたいな感じで、気軽に。

おわりに

今回は、私にとって初めてのクラウドファンディングでした。手元には何も残りませんでしたが、いい教訓は得られたので２万円は安い授業料だったと思います。同じ開発者として、Zanoのプロジェクトオーナーには同情しています。頓挫するまでの間、大変な苦労をしたことだろうと思います。再起に期待。

第7回講演会「情報工学が切り開く医療分野」に参加してきました。
医療の最前線で研究に従事している篠原先生から、情報工学のポテンシャルについて貴重な話をたくさん聞くことができ、とても有意義でした。

その中で、iOS8以降でリリースされているHealthKitの話題もあり、私が今まで持っていたHealthKitに対する違和感をきれいに解消してくれました。

なぜAppleが？

初めてAppleがヘルスケア機能（HealthKit）をリリースしたとき、私は、医療機器メーカーでもないのに、なぜAppleがこの分野に？という違和感を持っていました。Apple Watchの付加価値を少しでも上げる為に、半ば強引に参入したのかな…なんてことを勝手に想像していました。しかし、そこにはもっと大きな意味が含まれていたようです。

医療分野における機械学習の限界

例えば、マンモグラフィーや超音波検査などにより得た乳がんの診断画像を大量に集めて、機械学習させて、がんの有無を画像認識により自動検出したいとします。（乳がん検査は、肉眼では判定しづらいのが現状のようです）この場合、乳がん患者とそうでない人たち双方の診断画像が大量に必要です。

乳がんの発生確率は１０万人のうち５０人くらいだそうなので、裏を返すと、陽性の診断画像を５０人分集める為には１０万人にアクセスする必要があります。

とはいえ、陰性の９万９９５０人の診断結果をどこから取得するのでしょうか？乳がん検査はメタボ検診のように義務化されていないなので、任意で受診する人が１０％いたとしても、残り９万人については、受診データ自体が存在しません。

機械学習や画像認識の技術がどれだけ進んでも、そのベースとなるインプット（ビッグデータ）を集められないので、結果が出せないわけです。

Nを確保できる可能性がある

そんな状況の中で、AppleがHealthKitをリリースしました。
iPhone, Apple Watchは医療機器ではないので、質問票に回答したり、脈を測ったり、軽い運動をさせて加速度センサーで測ってみたりと、できることには限りがあります。

しかし、利用者数が他の医療機器と比べて圧倒的に多いので、病院に行かない多数の健常者から、大量の診断データを収集確保できる可能性があります。（専門用語的に言うと、「Nを確保できる」）今まで、そんな事ができるデバイスは存在しませんでした。

そこまで理解して初めて、HealthKitはAppleがやるべきなのだと納得できました。