明治5年の布告（太政官布告 第337号）は変更すべし

Facebookの知り合いのとある書き込みで、結構な数の反応があった。「24時間表記の12:xxを、午後0時xx分と表記するというルールに徹底できないだろうか」というもの。同じ時刻（12:30）を、午前12時30分、午後0時30分、午後12時30分と表現するケースがある。（直接関係しないが）当時うるう秒がシステムトラブル発生させるとのことで廃止論がニュースになり、自分が時刻の扱いを気に掛けていたので、その書き込みに少し反応した。

結論めいたことを先に書いておくと、そもそも日本での午前/午後の表記は、明治5年の太政官布告が元になっている。150年近く前の、大昔と言って良いくらい昔の決まりだ。結局混乱したまま/混乱した意見が出るということは、この布告の修正を行うべきと考える。午後0時xx分の表記が有効である旨を明記しておくべきだろう。また、これに限らず、矛盾したり現在とそぐわなくなっている法律や条例が少なくない。技術者などから、法令に関する変更の提言を行っても良い（行うべき）と考える。

明治5年の太政官布告 第337号は、「改暦ノ布告」と呼ばれるもので、太陽暦にするために発行したもの。そのものや、午前/午後を絡めたのは以下あたりが参考となる。

http://law.e-gov.go.jp/htmldata/M05/M05SE337.html

http://ja.wikipedia.org/wiki/%E5%8D%88%E5%89%8D%E3%81%A8%E5%8D%88%E5%BE%8C#.E5.8D.88.E5.89.8D12.E6.99.82.E3.81.A8.E5.8D.88.E5.BE.8C12.E6.99.82

http://www.msoffice.co.jp/MINOTE/Jikan/pg378.html

ウィキにも書いてあるが、本布告は現在でも有効と言われている。

したがってそのまま解釈すれば、24時間表記の12:xxは、午前12時xx分との表記でなくてはならない。ただし、上記のウィキにもあるように、”国立天文台広報普及室はこのような場合は午後0時×分と言うほうがいい”としている。

NICT(日本標準時グループ)も同じような考えであるが、以下のページで昭和51年の小学生からの疑問に対するバタバタぶりも紹介されている。

http://jjy.nict.go.jp/QandA/12am-or-0pm-J.html

現在、日本での午後0時xx分は結構普及してて、テレビ受像器の番組時刻は午後0時（正確には PM 0:00など）と表示する。またNTTの117では、”午前11時50分”、”正午”、”午後0時10分”をお知らせしますとのアナウンスである。したがって、日本での実際的な問題は、デジタル時計等での正午の午後12時（と0時は午前12時）表示と言える。

ただし、英米を含めると、少し話が複雑となる。ご存じのように、英米などでの表記は0時が12:00am　正午が12:00pm である。

http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight

例えば、エクセルで　0:00　と入力して　「h:mm AM/PM」と書式設定すると　12:00 AM　と表示される。12:00だと、12:00 PM。正午を午後12時と表現するのは、その辺りが関係しているのかもしれない。（ただし、本来日本では、「改暦ノ布告」にもあるように、午後12時は午前0時のこと。）

時刻（12時間制）の表記で、1から12を使用するのは、時計の文字盤の影響が大きいのだろう。アラビヤ数字にしろ、ローマ数字にしろ、大抵1～12を使用している。ただ上のウィキに記載されているように、海外の国が全てというわけでもない。フランスやドイツは、また違った表記のようだ。（ネットで調べると、フランスの記載方法は12時を特殊扱いしているようだ。ドイツでの表記は、すぐには見つからなかった。）

時計の上の方の文字盤が、ある時からでも”0”になっていれば、このような混乱は発生しなかったはずである。ところが数字のゼロを発明したのはインドで、アラビヤ数字やローマ数字のずっと後である。今ではアラビア数字にゼロ（0）はあるが、ローマ数字にはゼロはない（はず）。ご存じのように、ローマ数字は5を"V"とかで表現するもの。時計ではローマ数字が使われていることが多いので、時計の文字盤へのゼロ記載は行われなかったと考えられる。なお、ゼロ記載した時計も探せば見つかるので、普及しなかったと言うべきだろうが。

ちなみに、幼児とかだと、時計の見方を親などから学ぶ。長い針と短い針。通常は起きてる朝8時から夜7時くらいまで知っておけばいいので、文字盤のある時計を見ながら午後0時30分の時　「今何時？」と聞かれて「12時30分」とか　「12時半」と答えるだろう。まっ、それは仕方ない。

したがって、0時を含めた24時間制などは学校で習うことになるが、どうも指導要領で24時間制そのものを教えないようになっているようだ。本来指導要領そのものにあたるべきだけど、以下などを参考に。

http://okwave.jp/qa/q6992763.html

0時という概念が教えられないことを考えると、正午を午後12時と言う人は増えていくと思われる。また社会での深夜活動や24時間営業が増えると、0:00（午前0時、午後12時）をまたぐ時刻のやり取りも増えてくる。トータル的に混乱が発生する可能性は増えるだろう。

やはり、太政官布告 第337号に午後0時を明記すべきと考える。具体的には、「十二時　　　午刻」としている部分を午後の方にして、「零時　即午前十二時　　　午刻」へ。そして「十二時　　　子刻」は削除。（零ではなく0が良いかもしれないが、他との整合性の関係。法令関係で零の記載でも0の意味となるのは、既に何かの通達に拠ったかと思う。）

うるう秒の廃止を国際的に議論するなどよりも、日本でのこの混乱を修正する方が先だと考える。うるう秒はそれに応じたシステムがそれなりに構築できているし、天文的なことや時刻の正確性を考えると本来行うべき処理。それを誤作動の懸念でなくすという考えが理解に苦しむ。それなら、サマータイム廃止などを議論すべきかと思ってしまう。システムトラブルを懸念するのなら、非うるう年や、うるう年そのものも廃止しても良いくらいだ。また、なんで日本が廃止論のアメリカなどに賛同したのかとか、電気通信連合の日本団体の総意なのか疑問を覚えた。（アメリカは、GPS自体でのうるう秒を気にしている？　でも、システム的に補正メカニズムがあるので不可解。）

余談をいくつか、、、。

・「英米などでは0時が12:00am」って書いたけど、ほんとはイギリスでは 12.00am との表記。つまり、ピリオドを使用する。イタリアもそのようだ。で、エクセルにその書式を設定できるかというと、日本語版のせいなのか設定できない。

・時計の文字盤でローマ数字を用いることは多いけど、4をIIII、9をIXで表すことが多いそうだ。「時計文字盤」で画像検索すると分かりやすい。

http://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%BC%E3%83%9E%E6%95%B0%E5%AD%97(前出)

・太政官布告 第337号は、現行で効力のある最古の法律（法令）と言われている。

http://www.ceres.dti.ne.jp/~chu/law/toku_003.htm

多分そのこともあって、布告自体を無効や廃止とせずに、訂正で処理したい気持ちになるかと思われる。

・江戸時代の時刻は、干支と数字の4～9の組み合わせである。さらに細かい現在の約30分に相当する”刻”、約3分に相当する”分”の単位があった。

http://www008.upp.so-net.ne.jp/koyama_h/sirabetakoto/mojiban.html

http://www.ffortune.net/calen/calen/yomi99/yomi033.htm　など

”丑三つ時（うしみつどき）”は時代劇などでおなじみだし、午後3時の”おやつ”は江戸時代の時刻表記に由来している。

また、なぜ1～3を使わなかったかというと、そもそも仏教で9を縁起がよいとして鐘をつく数にしたためとか。逆に、刻の後での、ゼロ分の認識が芽生えていた部分もある。例えば「丑初刻　」の後が「丑初刻１分」で、分の所がブランクはゼロを表している。（このあたりは、日本人が色んな文化を受け入れる典型かもしれない。また、日本の明治5年布告時に零時としたのは、分のブランクが広まってたことを意識してのものかもしれない。）

・AM 08:00 などの表示があるが、日本固有のようだ。結局デジタル時計表示の際に、妙に英米のAM/PMの12時間制を利用したのが大きな間違いなのかもしれない。

・明治5年布告では、うるう年を4年毎としている。つまり、グレゴリオ暦に対応していない。そのため、明治31年勅令第90号で、明治5年布告を生かしたままグレゴリオ暦に対応している。（勅令第90号は1行のシンプルなもののようで、明治5年布告のどこを読み違えるとかも書いてないようだ｡）

http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%AC%E3%82%B4%E3%83%AA%E3%82%AA%E6%9A%A6

http://law.e-gov.go.jp/htmldata/M31/M31CO090.html

・うるう秒関連では、ISO 8601で、秒は0から60としている。

http://ja.wikipedia.org/wiki/ISO_8601

日本では、1秒が「セシウム百三十三の原子の基底状態の二つの超微細準位の間の遷移に対応する放射の周期の九十一億九千二百六十三万千七百七十倍に等しい時間」である旨を、「計量単位令」で明示している。しかし、秒が0から60である旨の法令記載は、無いように思える。

ISO 8601で、時刻の24時間制表記は規定されていると言える。ISO 8601に12時間制表記のルール定める考えもあるかもしれないが、結構困難であろう。骨折り損になりかねない。上で述べたように、英米のam/pmとか、コロンではなくてピリオドの利用など各国各様であることが理由である。

正午過ぎの12時間制の表記での問題や由来などを記載してきたが、昭和51年での小学生の質問でバタバタした時に明治5年の太政官布告 第337号の変更手続きを行っておけば良かったのにと思えてしまう。現在なら、うるう秒の事で騒ぐのなら、もっと議論して良さそうな事項にも思える。また、時計協会の認識として0時を用いるのが妥当としながらも、”規正統一をはかることは時期尚早”として変更実施しなかったのも問題といえる。（って、自分たちも時期尚早と言ったまま忘れたり、方便で時期尚早として逃げることもあるので大きな声では言えないか。）

少なくとも（デジタル）時計の表示では、

　24時間制
　12時間制（12使用）　従来のPM 12:00 →PM 01:00表示
　12時間制（00使用）　PM 00:00 →PM 01:00表示

を選択できるようにしてはどうだろうか。12時間制（00使用）を追加することになるが、ある意味では日本での本来の表示が行えるようになることを意味している。また、そのような表記の国への対応になって便利かと思う。（ただし、具体的に午前/午後で0時を使う国が判明したわけではない。中国語では0時を零点と呼ぶようだが、十二点も表に記載されていてどちらを使っているか良くわからない。このような情報は、いろんな国のネイティブの人に聞いた方が早そうである。）

今回の震災を契機とした防災などの見直しで、法律や条令でおかしいところも指摘されているように聞く。震災の関係で改正されたり発行された法律等もある。普段でも、科学者や技術者による法律変更や法律設定に対する意見があっても良いのではないだろうかと思えた。また、その際には条文など、具体的な所に落とし込んだ方が分かりやすいだろう。それが、場合によっては行政の手間を省いて財政赤字が減るなんて事にも結びつきそうだ。（蛇足ながら、立法サイドが機能し、立法サイドへのアプローチするのが本来の姿だろうが。）

今回の布告以外にも、矛盾を含んだ法令はたくさんありそうに思う。それらの指摘が法律の学者先生などから上がっても良さそうだが、どうなんだろうか。　それらをすっきりさせることで、社会が効率良くなったり間違いが少なくなるような気がする。科学者や技術者、そして法学者などの意識が必要だろう。

iPadでBluetoothマウス利用

iPadでのマインドマップ作成（正確には編集）の目処が立ったので、マウスの利用も本格的に検討を考えた。

そもそもiPadでは、Bluetoothのキーボードは使用できるが、Bluetoothマウスの利用は不可。Jailbreak（いわゆる脱獄）を利用したマウス接続がネットに掲載されていたが、当時はiPadでのマウス利用の必要性を余り感じなかったしJailbreakへの抵抗感もあって止めていた。ちなみにJailbreakは、Appleの認可を受けていないアプリケーションをインストール可能にする行為で、アップルのサービスの対象外。

そもそも、自分のiPadのバージョンは4.3.5。Jailbreakするためには起動毎の操作も必要とのこと。で、調べたら、最近バージョン5.0.1でのJailbreakができたそうだ。

参考にしたのが以下。
http://jailbreak.xxxxxxxx.jp/5-0-1.html

5.0.1にすること自体にも、多少抵抗があった。Macも含めて新しいOSにして、不具合発生や利用しているアプリの対応ができてないなどで懲りたことが何度かあるため。少し悩んだが、「えいやっ」で5.0.1にした。日本語入力が少し便利になっていたり、ブラウザのSafariがタブ形式になって戸惑ったりしたが大きな問題なし。（それにしても、iPadの日本語入力での不便さは変わらない。文節などの区切り変更ができない。あるいは、方法があるのか、時間ができたら調べるけど。）

redsn0wを利用することにした。

参考にしたのは以下のサイト。
http://blog.livedoor.jp/iphonejb/archives/1718844.html

ただし、「以下、デバイスがUSB接続され電源が入っている状態からの説明です。」と赤字で書かれているけど、本来は電源Offからの操作になるはず。誤記かと思われる。その意味では、以下の方が分かりやすいかも。
http://www.blogfromamerica.com/wp/?p=4426

で、redsn0wでの画面で最初が電源Onなのかどうかで混乱したり、そもそも操作がもたついたせいか、redsn0wがハングアップしてしまった。iPadも真っ暗。（あるいは操作で電源Offしたのかもしれないけど。）　ビックリして電源Onを操作したけどOnにならず。がーーん。

何度かホームボタン押したり、電源ボタン押したりしたら、どうにかiPadの電源が入った。良かった～と安堵。ホームページの記載などをじっくり読んだり、操作の予行演習をやってから再チャレンジ。どうにかJailbreakが成功した。

次が、Cydia を使っての 「BTstack Mouse」インストール。以下などを参考にした。

http://maclalala2.wordpress.com/2010/05/11/ipad-%E3%81%A7%E3%82%82%E3%83%9E%E3%82%A6%E3%82%B9%E3%81%8C%E4%BD%BF%E3%81%88%E3%81%BE%E3%81%99/

http://akihisaohmiya.blog.fc2.com/blog-entry-77.html

結構課題なのが、Cydiaでの検索。他のページでも書いてあるけど、日本語入力というか日本語のシステムでは検索しようとすると不具合が発生する。自分の場合、そもそも検索しようとしたらCydiaがハングアップ。何度かやっても駄目で、結局Cydiaで有効な全てのアプリ（パッケージ）を表示させて、スクロールさせながら 「BTstack Mouse」にたどり着いた。

JailbreakにしろBTstack Mouseのインストールにしろ、サブウィンドウでインストールしているコンポーネントやチェック状況の文字列が表示されて、ちょっと面白い。

BTstack Mouseをインストールして、アイコンが出たり、そのアイコンクリックでBluetoothマウスを認識してマウスカーソルが表示された様子。（日本語が表示され、一瞬焦った。もちろん応募しなかったけど。）

その後に、akihisaohmiya.blog.fc2.comの方で書かれている、一緒にインストールされる「Activator」を使って、右クリックをホームボタンに割り付けた。（不要なアプリと思ってインストール後に削除しようとしたが、しばらくそのままにしてて良かった。この機能は便利。）

結構便利だし、今のところ他のアプリを含めて不具合は起きていない。敢えて言えば、時々マウスカーソルの追従が遅くなってイライラする時がある。これは設定の変更で、うまく行くかもしれない。

なおマウスが使えると、ついホイールの操作も可能になって欲しいと思ったけど、どうもそれは無理そう。なので、スクロールする時はマウス操作でドラッグすることになる。あるいは指でのタップ。

常時マウス操作するほどではないだろうけど、マインドマップの編集などでは重宝すると思う。気分的にも一段落。

iPadでのマインドマップツール 続編

iPadでのマインドマップツールを悩んでいる件を既に述べたけど、段々iPadで作業しようとすることが多くなり、解決しようとの思いに至った。以前のブログで書いたように、Mind42で作成できるが修正ができない、→ついつい作業が億劫になる弊害を感じるようになった。

本来Web系のサービスでiPadでもWindowsでも作業できるのが良いが、あまり値段のかかるのは避けたい｡Webサービスで「easy step」も悪くないと思ったら、iPadで編集できない。「Mindmeister」は、再度有料会員になるのも抵抗あるし、、、｡またiPad向けのマインドマップやアウトラインプロセッサーの無料ソフトをいくつか試したけど、ノード変更（子ノードを別の親ノードの下へなど）などが操作できない/操作が見つからなかった。

結局、iPadでのマインドマップツール「iThoughtsHD」を、App Storeから購入することにした。\850。

そもそも今までMind42条で作成したマップを、「iThoughtsHD」に移動させる必要がある。ネット検索での上位でヒットしなかったけど、Mind42でのエクスポート形式でFreeMind V9(V8も）あり、そちらでエクスポート。そのファイルをDropBoxに置いて、iThoughtsHDでインポートすることで対応できた。インポートの際に同期する指定も可能だったので、効率良い。しかも同期だとファイル形式も引き継いでくれる（当たり前か）。

Windowsでの利用は、Mind42でDropboxのFreeMindファイルをインポートすることで可能ではある。ただしこちらは自動的に同期はしない。したがって、集中的に作業する時などに限定されて、マインドマップの作業の主体はiPadで行うことになっていくだろう。

ちなみに、iThoughtsHDでのマインドマップそのものでの日本語入力や表示は、自分の使った範囲では問題なし。メニューが日本語でないのはちょっと気になるし、その関係か、Dropboxの指定や同期、一括ダウンロードの操作が、少し分かりにくい気がする。慣れの問題かもしれないが。

まずは一安心だし、この関係で少し延び延びになってた作業をリカバーするつもり。

補足：PC上での操作は、FreeMindを利用してDropbox上のファイルを処理する方法を採用。PC上でファイル操作（PC上でもDropbox同期）した後にPadのiThoughtsHDのマップファイル一覧で見ると、雲マークの他に更新されているアイコンが表示されるのでクリック（タップ）してマップを開くとPCで更新されたマップが表示される。

ソフトウェアテストの見積り

知り合いとのやり取りで、”ソフトウェアテストの見積り”がちょっと話題になったので、メモのつもりで残しとく。そもそもソフトウェアテストの見積りって、テスト項目数がどれくらいになりそうかとかテストのための人員数がどれくらいを見積ることだが、記載されてる例が多くない。バグカーブやソフトウェア開発での見積りと比較すると、書籍や論文への登場は、がくっと減っている。

「基本から学ぶテストプロセス管理」では、11章で”テストのコンテキスト -予算、ライフサイクル、プロセスの成熟度”のケーススタディで、少しイメージしやいものが掲載されている。（ROIに関しても言及しているが、市場で発見されるバグをそこそこの数としているから、日本人には違和感はあるかも。）

他の章ではテストラボの設備などにも言及しているので、ソフトウェアテストの見積りを考える上で参考になるだろう。昨今は、C/Sシステムにしろクラウド利用のサービスにしろ、テスト環境構築をどうするかは大きな課題だし、実運用外のシステムでテストする場合はそれなりのコストが発生するので悩むところかと思う。

「テストプロセス改善」では、”7.4 見積りと計画”でキーエリアとして見積りのことを述べている。

テストケース記述での工数の考え方（ただしある意味当然）が記載されていたり、テスト自体の比率（準備、仕様化、、、）の筆者による経験値などが述べられている。

「ソフトウェアテスト見積りガイドブック―品質要件に応じた見積りとは」の方には、さらに具体的にイメージしやすい掲載もある。特に東京海上日動システムスの事例。テスト工数の全体に占める割合という概算的な数値である。ただし、まずはその数値で金額的な見積りを行うことは有効と、個人的には思う。（もちろん積み上げによる見積りとの併用が望ましいが。）

他にこの本では見積りでのパラメータが豊富に記載されている部分も多いが、具体的な数値とのペアではないのでイメージしやすいかは？　逆に、自組織でいくつかのパラメータを採用して、計測したり市場トラブルやリリース後のトラブル数などと対比することで、見積り精度の向上に役立てることはできるだろう。

ITシステムに対する受け入れテストの工数予想は、開発ベンダーによるインストールからカットオーバーまでの期間に関係する。組込みなどを含めてソフトウェアテストを請け負う企業もあり、そのような企業にとっては請負の見積り金額に関係する。ソフトウェア開発を請け負う場合でも、自テストの工数を加味する必要がある。それらを考えると、精度を高める工夫（と同時に予想との差異分析やその対応）が必要なはずだ。

IEEE829 208ではレベルテスト毎の計画という考えを入れているので、各レベルテスト毎に見積って積み上げることで見積り精度は上がっていくと思われる。レベルテスト（テストレベル）という概念を取り込み、ソフトウェアテストのためのコストを見積ったり計測することで、例えばコンポーネントテストでの自動テスト化/自動テスト拡張なども判断しやすくなると考える。

日経SYSTEMS 1月号「さらば失敗プロジェクト」

日経SYSTEMSの「さらば失敗プロジェクト」、知り合いのつぶやきから数日前に知ってたけど、今日雑誌の方を細部で確認。

いくつかの事例が書かれたルポの方は（失敗例として）頷ける部分もあるが、問題は最初の方の数値の列挙。「プロジェクトのうちに94.5%に深刻な問題が発生して、そのうち89.9%が同じ失敗を繰り返している」としている。

0.945*0.899=0.85　で、前プロジェクトのうち85%は、同じ原因で失敗していると読み取れる。

今となってはアンケートの原文がネットにないので何とも言えないが、今回の記事の本文でも質問は「あなたが現在または直近で関わったシステム開発プロジェクトについてお聞きします。そのプロジェクトでは、右に挙げる問題が発生しましたか？」。（右に挙げる）問題として、スケジュール遅延などがある。本アンケートは、ネットのITpro上で行ったものでその記事は以下。

http://itpro.nikkeibp.co.jp/article/Watcher/20111024/371258/

有効回答は73。上のURLでの記事で分かるように、そもそも、問題意識を持った人が回答したと言える。しかも、今回の記事では、問題がある→深刻な問題発生となっている。（アンケートの設問に、”深刻な問題”とあったのなら撤回すべきだろうけど。）

プロジェクトなので、あるいは定常の業務でも、日々問題は発生する。それを解決していくのが、ある意味プロジェクトマネージャーの仕事。日程遅れなども1割程度は許容範囲だろう。最初の日程は大枠であり、段階的な詳細化などを通じて具体的になっていく。最初の大枠での”案”に対して、1日遅れたら失敗との烙印は普通は押さない。（日経での別調査でも、1割の違いは失敗とはしていないはず。これらは他でのプロジェクト失敗率などと一緒に別途調査。）

また、別の設問は「現在または直近で関わったプロジェクトで発生した問題は、以前にも繰り返し発生しましたか？」。それが、記事では同じ失敗を繰り返しているとの表現になっている。同じ問題の発生と、同じ失敗は違う。多分回答者は、”以前もスケジュール遅れが発生したな～”程度で、Yesにしたのだと思われる。

なんか今回の記事での数字は、言葉で妙にバイアスがかかっているように思えてならない。気になっているのは、この類の数字が学会などでも利用され、まるでIT業界は駄目チームのように受け取られること。就職先として人気無くなるだろうし、社内には過度に反応して非常に細かい管理で対策しようとする所が出てくる。極論だろうけど、開発ベンダーの資金調達などにもマイナスになる。ぎりぎりセーフや上手く回っているプロジェクトが、たくさんあるのに/あるだろうに、、、｡

バグカーブの理想曲線

今朝のブログに引き続き、バグカーブ関連。具体的な（理想的な）バグの累積曲線を考えてみた。

前提は、今朝と同じく以下。

・バグは均一
・ソフトの生産性（修正スピード）は一定
・テスト件数のスピードは一定

以下の数値を設定するものとする。
・全体行数（初期のソースコード行数）
・テスト密度（行辺りのテスト件数）
・単位時間（1日の最大）テスト件数
・テストに対するバグ率

ちなみに、１バグに対する修正行は、テスト相当行数*バグ件数とする。
（テスト相当行数＝テスト1件に相当する行数＝テスト密度の逆数）　多少乱暴な仮定かも知れないが、修正とか修正確認などを考えると、それほどかけ離れているとも思えない。

それをエクセルにしたのが左。（次の写真を含め、ダブルクリック等で拡大できる。）

a2: =F1
b2: =IF(A2>(1/$F$2)*$F$3,$F$3,ROUNDUP(A2*$F$2,0))
c2: =ROUND($F$4*B2,0)
a3: =A2-(B2-C2)*ROUNDUP(1/$F$2,0)

a15は、3960行のテストすべき行が残っており、1日10件のテストをしたので、100行分はテスト完了。ただし、バグが2件発生したので、その対策として20行テストすべき行として追加された事を意味する。（結果的に次の日=a16では、3880行のテストすべき行が残っていることを示す。）

終盤が左。テストすべき行数が減って、テスト件数も減る。（テスト出来る件数分テストしても良いけど）テストで見つかるバグ件数も減って、追加される修正行数も減ることになる。

横軸をテスト件数、縦軸を累積のバグ件数とすると、当初からほとんどが直線（1次曲線）となり、終盤が減衰する曲線となる。それを理想カーブとして良いかと思われる。（行数前提への意見とか色々あるかもしれないけど、行→FPなどの場合でも考え方は同じになると思う。）

なお当然だけど、回帰分析などでカーブを求める場合、何らかの数式になっている方がよい。しかも、原点から連続したものが操作も楽である。今回示したカーブが、回帰分析で使えるような関数の格好になっていればいいのだが、すぐには見つかりそうにない。（もし判明したら、連絡もらえれば幸い。）　

捕捉：カーブが求まらないか、少し考えてみた。

こちらは、終盤でのテスト件数やバグ件数を、整数化しなかったもの。

こちらも、テスト件数やバグ件数を整数化しなかったもの。ただし、初期の行数を調整して、終盤で一旦（テストと行数の関係で切りの良い）100行にしたもの。

2つの終盤で、整数化しないことではっきりするけど、テスト件数がバグ率による等比数列になっていく。バグ件数も、バグ率による等比数列になっていく。

なので、バグ件数は、 k*a＾x の指数関数となる。kは、終盤（最大テスト件数を処理する必要のない段階）での初期の値で終盤の行数に依存する。今回のグラフの例だと1から9かな。aはバグ率。　（表の意味するxはテスト件数により離散的だけど、テスト件数をlimで1件などに考えて行けば、指数関数と考えてOKそう。）

で、指数関数とすると、バグ件数の累積＝積分も指数関数のカーブになる。（積分することで係数は違ってくる。特にバグ率は少数以下なので、係数がマイナスになることで上下反転する。）　

終盤のバグ累積件数を指数関数で近似するのは悪くないだろうが、テスト開始からを指数関数で近似するのは多少無理があるかもしれない。なっ、この辺りになると、実際のデータでの近似曲線間の決定係数の比較になるだろう。

結構自分なりには、すっきりしたかな。

"コーダーとテスターのパラドックス"

昨日Twitterのつぶやきで、信頼度成長曲線の話しにちょっと反応。こちらは、むしろテスト件数などの理想カーブに注目すべきと思って書いたけど、元々品質を測る信頼度成長曲線に注目してたようだ。って、元々そう書いてあったと言えば、そうなんだけど、、、。

で、ふと思ってこっちに補足的なことも含めて書いとく。

まずタイトルは、「アキレスと亀」をもじったもの。”コーダー”とせずにソフト開発者としても良いかもしれないけど、語韻と開発よりも製造に近いイメージがあるので、”コーダー”。ここでの”テスター”は、第三者検証のようなコーダーや設計/開発とは別チームでの検証の人。

「アキレスと亀」って、”ゼノンのパラドックス”とか”ゼノンの逆説”の中の一つで、ウィキなどにも書かれてる。　

http://ja.wikipedia.org/wiki/%E3%82%BC%E3%83%8E%E3%83%B3%E3%81%AE%E3%83%91%E3%83%A9%E3%83%89%E3%83%83%E3%82%AF%E3%82%B9

あるところにアキレスと亀がいて、2人は徒競走をすることとなった。しかしアキレスの方が足が速いのは明らかなので亀がハンディキャップをもらって、いくらか進んだ地点（地点Aとする）からスタートすることとなった。

スタート後、アキレスが地点Aに達した時には、亀はアキレスがそこに達するまでの時間分だけ先に進んでいる（地点B）。アキレスが今度は地点Bに達したときには、亀はまたその時間分だけ先へ進む（地点C）。同様にアキレスが地点Cの時には、亀はさらにその先にいることになる。この考えはいくらでも続けることができ、結果、いつまでたってもアキレスは亀に追いつけない。

この話は、高校の数学で取り上げられるケースが多い。無限級数とか収束。ネットで検索すると分かりやすい解説もあるので、興味あればそちらを。

で、ソフトウェアテストとの関係。アリストテレスをコーダー、亀をテスターと置き換える。そして、スタート地点でのことをテスターに最初に渡すバージョンでの何行かのソフトウェア、スタート後もバグ対策で何行かソフトウェアを作成すると考える。すると、追い越せるかは、テストが完了＝バグ修正の行数がゼロになるかと考えればよい。無限に続きそうに思える点が、ゼノンの逆説とも似てくる。（テストでは、スピードを一定と考えるべきじゃない点は後述。）

ちなみに、ソフトウェアでの理想的なこの類を考える時の前提としてはいくつか考えられる。

１）バグはゼロ

理想という点では分からなくもないが、非現実的。

２）バグは均一

３）ソフトの生産性（修正スピード）は一定

４）テスト件数のスピードは一定

従来の信頼度成長曲線って、３）とか４）はあまり議論せずに、バグ残件がどのカーブにフィットするかの議論が多い。残件は終盤でゼロに近いので、成長曲線の類になるのは当然だが。それはそれで価値があるが、それを理想モデルと言うべきかは疑問のあるところ。また、検証サイドとしては、４）のテスト処理がスムーズに行われない原因を探るべきなのに、（論文や記事が信頼度成長曲線に関するものがほとんどなので）残件バグのカーブの方に目が行ってしまう。そんな気がする。

ゼノンの逆説の解法で分かりやすいのは、横軸が時間で縦が距離のグラフ。ただし、ソフトウェアテストのコーダー側の場合は、縦を行数として、追加行数を考える必要がある。コーダーの生産行数（スピード）はテスト結果の反映を考えて、テスト開始（t0）から追加行数自体は次第に減衰する。t1には、t0からt1直前までに発見されたバグ対策に相当する行数を生産していることになるため。これは（理想モデルでは）等比級数でOK。ゼノンの逆説でのイメージでは、アリストテレスは疲れてきて段々スピードが遅くなるイメージ。

ソフトウェアテストのテスター側は、横軸が時間で、縦軸が件数。これは直線で良いだろう。（回帰テストのことがあるけど、処理件数という点ではスピードは一定が理想。）　等比級数（等比数列の項の総和）は求まるので、バグ率によりトータル行数も算出できる。もちろん、テストが追い抜く時期も判明する。

ここでのテスター側は、回帰テストも含めてテストスピードが一定であることを前提としているが、ある意味目標かもしれない。Twitterでの返信でも書いたけど、そもそもテストの粒度の扱いをどうするかが悩ましく感じる人もいるかもしれない。また、いかに回帰テストを効率よくやるかも目標だろう。

なお、冒頭でバグゼロが非現実的と書いたけど、（第三者検証に対しては）バグゼロに近づける事を目指していることや、実際近づきつつあるのは事実。テストツールでの事前確認もそうだし、イテレーション毎に出荷できるリリースを目指す開発手法なども普及しつつある。なので、ここで述べた追いつくまでの期間や修正行数が、ゼロに近づきつつあるとは言える。

いわゆる信頼度成長曲線で（開発の）状況を分析するのは良いことだと思う。自分自身はアンチ信頼度成長曲線派でもなく、使うべきとの考え。また、対数曲線や二次曲線での近似も悪くないことを、このブログでも書いた。　

http://blog-honda.cocolog-nifty.com/gijyutuya_nikki/2010/03/post-4fef.html

ただ、信頼度成長曲線は信頼度を示すけど、ソフトウェアテスト自体の状況を示している訳じゃない。ソフトウェアテストの状況を知って改善するには、別の指標での監視が必要だし、理想での指標を頭にイメージしておくべきと言える。

ハードウェア受け入れテスト

以前”初期「受け入れテスト」”って書いたけど、ハードウェアの受け入れテストも重要である。以前「受け入れテスト」を書いた時も頭の隅にはあったけど、明記しなかったようで、補足的に今日記載。

ハードウェアの受け入れテストも、開発の初期段階に行われるのは同様。ここでのハードウェアって、社内の新規基板の場合もあるけど、他部署での（先々内販/外販予定の）半導体とか、他社の半導体なども含む。

で結構厄介なのが、ソフトウェアにバグがあるように、ハードウェアも完璧なものが最初からある訳じゃない点。しかも量産を意識している場合、修正ハードウェアを入手できるのに期間を要することが多い。（逆にFPGAのように、変更が容易なケースもある。その場合は、修正確認に付き合わされる頻度が多くなる。）

基板のような場合は、ジャンパー線で修正ということも少なくない。試作機が何台もある場合は、修正済みとそうでないものが混在。ハード屋さんは、出来れば修正台数を少なくしたいと言うし、、、｡

ハードウェア受け入れテストを、誰が実施するかも懸念点だろう。ソフトウェア開発メンバーになることが多いが、テストの頻度やボリュームが大きいと、委託などの方法も検討する必要がある。ハードウェアの一般的な知識や組込みの知識があった方が良いので、人捜しが難しくなる。

結局、この辺りを含めた開発初期の作業項目列挙や人員の手配などの立案や実施が重要だ。開発のその後を、大きく左右すると言っても過言ではない。

結局 Goggleノートブック→Evernoteへ

Googleノートブックが終了ということで、結局WebのスクラップはEvernoteを利用することにした。自分なりの終了を聞いての不満はブログで記載済み。

そもそもEvernoteへ移行するのに、Googleノートブックの各ノートをエクスポート。以前はEvernoteでのインポートはhtmlも可能だったように思うけど、Atom形式のみになっていた。一部htmlでのバックアップは取ってて残りもhtmlでバックアップした後にインポートを実験して、Atom形式のみと判明したので、再度Atom形式でバックアップ。ちょっと疲れた。（Evernoteでのhtmlインポートは、勘違いかもしれない。自分のバックアップ確認などでhtmlへのエクスポートを実施していたため？）

Evernoteでのインポートは、（ノートブックのボリュームが大きかったので）それなりの時間。また、後でローカルPCとかiPadの方も同期させようとしたが、そちらも多少の時間が必要だった。

細部は調べてないけど、インポートはOKと思える。（画像を含むノートの確認をちゃんと行ってないけど、駄目なら諦めるしかないかな。また、Googleノートブックでのセッションの考えがEvernoteではタグになって使い勝手に違和感があるけど、そちらは諦め。）

以前はEvernoteの検索や表示がやたらと時間がかかって、Webスクラップとして使うこと自体をやってなかったけど、今回操作した限りでは、少しイライラするときがある程度。結構バンドルされたりしているのを見聞きしているけど、その関連で開発（資金）などがうまく行っているのかもしれない。

なお、少し使い出すと、いくつか不満も。Webの一部選択後の右クリックでメニューにEvernoteへの保存が出てきて、選択部分のみをスクラップするなどを選択する必要がある。ツールバーでのアイコンクリックでも、メニュー操作の必要性は同様。Googleノートブックに対して1アクション追加することになるのが気になった。

Firefoxのアドオンでどうにかならないか調べてみたけど、上手い方法は無さそう。結局”Menu Editor”で右クリック時のメニューの一番上をEvernoteへの保存に変更することにした。

Ｅｖｅｒｎｏｔｅを使って良かった事項に、iPadでの利用がある。iPadでも直接Evernoteへ保存が出来ないかな～と思って調べたら、上手い方法を記載してあるサイトを発見。

iPadのSafariから、ツイッターやEvernoteに簡単にポストするブックマークレットまとめ

iPadでの操作自体もEvernoteへの保存処理も、ちょっともたもたした感じにはなるけど、iPadでのWeb閲覧が増えているので個人的には非常に便利だ。

Ｅｖｅｒｎｏｔｅを使って良かったもう一つが、Google検索時にもEvernoteの検索を表示する点。Ｆｉｒｅｆｏｘアドオンの「Evernote Web Clipper」のオプション指定によるもので、Google、Bing、Yahoo、Yandex、Baiduでの検索時に、Ｅｖｅｒｎｏｔｅの検索結果も一緒に表示する。

Googleノートブックの中止やそれに伴う移行作業で少しイライラしたけど、EvernoteにしてiPadでもWebスクラップを行えるようになったのは良かった。イライラ自体は収まりつつあるけど、Googleサービスはこれからも少し気をつけながら利用するつもり。

ET2011

今日は、ET2011（Embedded Technology 2011 / 組込み総合技術展）見学。開催場所は、パシフィコ横浜。

http://www.jasa.or.jp/et/ET2011/index.html

ショー会場見学の前に、基調講演を拝聴。

「はやぶさ」－地球帰還までの７年間60億kmの運用を支えたものと新たな展開
〜あきらめない心がつかんだ成果〜

JAXAの川口さんの講演。スライド自体は、写真等は少なく文言（若干英語を併記）がほとんどだったが、話し方や内容で1時間があっという間だった。

冒頭の話しは、予算獲得との関連での、地球内部と小惑星の関係。これは本にも記載されてるかと思う。

次が映画「はやぶさ／ＨＡＹＡＢＵＳＡ」の件。”真実のドラマ”という表現や、川口さん役の佐野史郎さんがヤカンを持ち歩くシーンのことを面白く話された。

個人的に印象深かった逸話は、カプセル回収後にコンビニでジュースを買ったら、店員さんから「砂が入っていると良いですね」と言われた件。「ジュースに砂は、、、」と笑いを誘っていたが、個人的にはウルっとしてしまった。

その後に、ショー会場へ。奥の方から見学したけど、昨年よりは見学者が少ない感じ。震災などの影響かもしれない。海外からの展示は少なくなかったけど、以前との比較では地方からの小さなブースでの展示が増えたかな。後、大きな企業でもテーマ的な展示よりも、サポート企業による展示がほとんどを占めるようになったと感じた。ET2011で初めての展示とか参考出展の類も減ってきたと思えた。

スマートグリッドはコーナーがあったので、いくつかの展示があったが、ブームというほど見学者が多かったり盛り上がっているようには思えなかった。

三洋のプロジェクターなど面白い製品もあったが、製品よりも半導体/半導体関連の展示が多かったと思う。また自分の目線なのか、電気系よりもメカとの連動のような展示が増えたように感じた。メカトロニクス（自分なりのより正確には、メカ+ソフトウェア）って、日本の技術の骨幹とも言えるかもとか、地方の展示が増えてる背景かもとふと思ってしまった。

会場では、知り合いの説明員の人と少し懇談。また、偶然知り合いとも遭遇して少し立ち話した。今年は、講演との関係でETロボコンの決勝も見学しなかったこともあって、技術や製品よりも、講演や知り合いとの遭遇が印象的な展示会になった。