PictMasterを実行するとVBAのエラーとなる場合の対策について 【8月4日更新】
PictMasterを実行すると次のいずれかのエラーメッセージが表示される場合があります。
「オートメーションエラーです。エラーを特定できません」
「無効なオブジェクト ライブラリです。または定義されていないオブジェクトへの参照を含んでいます」
これらのエラーが発生する直接の原因は、VBAが参照しているファイル MSCOMCTL.OCX が参照不可となっているためです。この現象はしばしばWindows Updateを行なった結果として発生することがあります。
エラーが発生する条件には、Windows Updateの内容、OSの種類、Excelのバージョンが関係するため、条件を特定することは困難です。
これらのエラーが発生した場合は、次の対策を実施して下さい。
[WindowsXPの場合]
[スタート]→[すべてのプログラム]→[アクセサリ]→[コマンドプロンプト]を選び、以下を入力し、Enter を押す。
regsvr32 C:\Windows\System32\MSCOMCTL.OCX
[Windows 7 （32bitの場合）]
[スタート]→[すべてのプログラム]→[アクセサリ]→[コマンドプロンプト]を右クリックし、[管理者として実行]を選び、以下を入力し、Enter を押す。
regsvr32 C:\Windows\System32\MSCOMCTL.OCX
[Windows 7 （64bitの場合）]
[スタート]→[すべてのプログラム]→[アクセサリ]→[コマンドプロンプト]を右クリックし、[管理者として実行]を選び、以下を入力し、Enter を押す。
regsvr32 C:\Windows\SysWOW64\MSCOMCTL.OCX
これらの対策を行なっても解決しない場合は、Windows Updateを行なってみて下さい。解決する場合があります。
マニュアルに上記の対策を追記したファイルを本日（3月19日）アップロードしました。PictMasterのバージョンは5.6で変わりありません。
なお、マニュアルのインストール方法を説明した章に文字コード変換ソフト nkf.exe についての説明がなかったので追記しました。英語バージョンをリリースした際に誤って日本語バージョンのマニュアルからも削除してしまったようです。
PictMaster v5.6 をリリースしました。
PictMaster v5.6 をリリースしました。
変更点は以下の通りです。
【機能改善】
・制約表への値およびパラメータの記入をショートカットメニューからワンタッチで行なえるようにした。結果表への値の記入も同様にワンタッチで行なえるようにした。
制約表および結果表のセルを右クリックすると、次のようにショートカットメニューが表示されるので、記入したい値またはパラメータを選択することでセルへの記入がワンタッチで行なえるようになりました。
パラメータを記入するには、初めにパラメータ用の演算子(=)または(!)を記入してからショートカットメニューを表示させます。
すでに記入されている値またはパラメータをショートカットメニューで選択すると、削除されます。
PictMaster v5.6 は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
変更点は以下の通りです。
【機能改善】
・制約表への値およびパラメータの記入をショートカットメニューからワンタッチで行なえるようにした。結果表への値の記入も同様にワンタッチで行なえるようにした。
制約表および結果表のセルを右クリックすると、次のようにショートカットメニューが表示されるので、記入したい値またはパラメータを選択することでセルへの記入がワンタッチで行なえるようになりました。
パラメータを記入するには、初めにパラメータ用の演算子(=)または(!)を記入してからショートカットメニューを表示させます。
すでに記入されている値またはパラメータをショートカットメニューで選択すると、削除されます。
PictMaster v5.6 は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
近日中にPictMasterをバージョンアップする予定です
考えられる機能はすべて盛込んだつもりでしたが、もうひとつ追加したい機能がありました。それは制約表への記入を、マウスの右クリックで表示されるショートカットメニューからワンタッチで行なえるようにすることです。
現在のバージョンでは、制約表への記入は値の名称を手書きするか、値の並び欄からコピー＆ペーストで行ないます。この方法では、手書きした場合に書き間違いが起こりやすく、また時間がかかってしまいます。コピー＆ペーストでは書き間違いは起こりませんが、記入する値が多い場合は煩雑な操作となり、同じく時間がかかります。
ショートカットメニューから記入することができれば、書き間違いは起こらず、記入時間も極めて短時間で済ますことができます。PictMasterを使っていて起こるエラーの多くは「未定義エラー」だと思います。この機能を追加すればこうしたエラーは一切出ないことになります。
GUIを備えた他の組み合わせテストツールでは、プルダウンメニューから値を選択する方法が一般的です。この点に関して、PictMasterもようやく他のツールと同じ操作性を獲得することになります。
機能追加を行なったPictMasterの新バージョンは３月上旬のリリース予定です。
現在のバージョンでは、制約表への記入は値の名称を手書きするか、値の並び欄からコピー＆ペーストで行ないます。この方法では、手書きした場合に書き間違いが起こりやすく、また時間がかかってしまいます。コピー＆ペーストでは書き間違いは起こりませんが、記入する値が多い場合は煩雑な操作となり、同じく時間がかかります。
ショートカットメニューから記入することができれば、書き間違いは起こらず、記入時間も極めて短時間で済ますことができます。PictMasterを使っていて起こるエラーの多くは「未定義エラー」だと思います。この機能を追加すればこうしたエラーは一切出ないことになります。
GUIを備えた他の組み合わせテストツールでは、プルダウンメニューから値を選択する方法が一般的です。この点に関して、PictMasterもようやく他のツールと同じ操作性を獲得することになります。
機能追加を行なったPictMasterの新バージョンは３月上旬のリリース予定です。
Heisenbug仮説
ソフトウェアのバグのうち再現することが困難なタイプのバグについて適用できる「Heisenbug仮説」というものがあります。Heisenbug（ハイゼンバグ）仮説とは次の意味を持っています。
「そのバグを調査しようとすると変貌したり消えたりするバグ」
要するにバグを再現しようとしてもなかなか再現できないバグを言います。ハイゼンバグという名称は、不確定性原理を提唱したハイゼンベルクからきています。量子力学の創始者の1人であるハイゼンベルク（Werner Heisenberg）は、「位置と運動量の両方を正確に知ることは原理的に不可能である」と語る式を提示しました。不確定性原理とは、例えば電子の位置を正確に測定しようとすると電子の運動量の誤差が発散してしまう。逆に電子の運動量を正確に測定しようとすると電子の位置の誤差が発散してしまうという定理です。
製品出荷後、ユーザ先であるバグが発生したとします。そのユーザ先の製品とまったく同じ環境を構築してバグを再現しようと色々努力しても再現させることができません。バグが発生している製品ではどう操作すればバグが発生するかが分かっていますが、いざテスト環境のある自社内で同じ操作を行なっても正常に動作してしまいます。
こうしたバグが発生する原因には様々なものがあります。私が知っているバグにこういうものがありました。
プログラムが初期化されていないアドレスを参照していたことにより、参照先のメモリの値によってバグが発生するというものです。一般に電源オンで初期化されていないメモリの内容には一定のパターンがあり、アドレスによってall 0かall 1のどちらかになります。ハードウェアが同じ構成なら電源オン時の特定のエリアの値は多くの場合、同じ値となります。ほとんどの製品で同じ値となるので、たまたま初期化されていないメモリを参照していても正常に動作してしまいます。しかし、まれに異なる値となる製品が存在します。そうした製品が出荷された場合にユーザ先でバグが発生しますが、自社内の同じ製品では当該メモリの値が違っているのでバグが再現できないことになります。
このバグの原因がどうして判明したのかは知りませんが、おそらく現象からおおよその見当をつけてソースコードを詳しく調べたのではないかと思います。こうしたバグをテスト段階で発見することは非常に困難です。数百から数千台に一台しか発生しないバグだからです。このようなバグを発見するには開発工程でのレビュー、それもソースコードレビューをていねいに行なうほかないと思います。
ウィキペディアを「特異なバグ」で検索すると、今回のハイゼンバグのほかにいくつかの興味深い特異なバグを知ることができます。
「そのバグを調査しようとすると変貌したり消えたりするバグ」
要するにバグを再現しようとしてもなかなか再現できないバグを言います。ハイゼンバグという名称は、不確定性原理を提唱したハイゼンベルクからきています。量子力学の創始者の1人であるハイゼンベルク（Werner Heisenberg）は、「位置と運動量の両方を正確に知ることは原理的に不可能である」と語る式を提示しました。不確定性原理とは、例えば電子の位置を正確に測定しようとすると電子の運動量の誤差が発散してしまう。逆に電子の運動量を正確に測定しようとすると電子の位置の誤差が発散してしまうという定理です。
製品出荷後、ユーザ先であるバグが発生したとします。そのユーザ先の製品とまったく同じ環境を構築してバグを再現しようと色々努力しても再現させることができません。バグが発生している製品ではどう操作すればバグが発生するかが分かっていますが、いざテスト環境のある自社内で同じ操作を行なっても正常に動作してしまいます。
こうしたバグが発生する原因には様々なものがあります。私が知っているバグにこういうものがありました。
プログラムが初期化されていないアドレスを参照していたことにより、参照先のメモリの値によってバグが発生するというものです。一般に電源オンで初期化されていないメモリの内容には一定のパターンがあり、アドレスによってall 0かall 1のどちらかになります。ハードウェアが同じ構成なら電源オン時の特定のエリアの値は多くの場合、同じ値となります。ほとんどの製品で同じ値となるので、たまたま初期化されていないメモリを参照していても正常に動作してしまいます。しかし、まれに異なる値となる製品が存在します。そうした製品が出荷された場合にユーザ先でバグが発生しますが、自社内の同じ製品では当該メモリの値が違っているのでバグが再現できないことになります。
このバグの原因がどうして判明したのかは知りませんが、おそらく現象からおおよその見当をつけてソースコードを詳しく調べたのではないかと思います。こうしたバグをテスト段階で発見することは非常に困難です。数百から数千台に一台しか発生しないバグだからです。このようなバグを発見するには開発工程でのレビュー、それもソースコードレビューをていねいに行なうほかないと思います。
ウィキペディアを「特異なバグ」で検索すると、今回のハイゼンバグのほかにいくつかの興味深い特異なバグを知ることができます。
デシジョンテーブルの圧縮（整理・縮小）は要注意
通常、デシジョンテーブルは結果に影響を与えない条件がある場合、そうした条件を「任意値」に置き換えます。任意値に置き換えた結果、同じ条件の組み合わせとなるルールを１つだけ残して後は削除してテーブルを圧縮することを行ないます。多くの場合はこの方法で問題となることはありません。しかし場合によってはデシジョンテーブルの圧縮はバグを見逃すことがあります。今回はこうしたケースを取り上げてみたいと思います。
次の仕様があるとします。
仕様1． AとBがYesの場合はYesを返す。ただし、BがNoの場合はNoを返す。
仕様2． AがNoでCがYesの場合はYesを返す。ただし、CがNoの場合はNoを返す。
この仕様のフローチャートは図１となります。
デシジョンテーブルでを圧縮する危険性はこれだけにとどまりません。デシジョンテーブルはプログラムのコーディングでも使用することができます。デシジョンテーブルを圧縮することでコーディングの量が少なくなるので便利な方法です。しかし、テーブルが誤って圧縮される可能性は常に存在します。このことはテストの場合にも同じことが言えます。プログラムが間違っている場合に、圧縮したデシジョンテーブルが間違っているとバグを見逃すことにつながります。
徹底したテストを行ないたい場合には、デシジョンテーブルの圧縮は行なうべきではありません。CFD技法や原因結果グラフでは、圧縮した後のデシジョンテーブルしか得られないので、徹底したテストを行ないたい場合にはそうしたテスト技法の適用は避けた方がよいでしょう。
デシジョンテーブルによっては、圧縮を行なわないと表が大きくなり過ぎる場合があります。そうした場合には、論理上あり得ない組み合わせを削除して表を小さくしたり、独立性の高い条件（他の条件との関連性がない）を選び出し、別のデシジョンテーブルに分割して表を小さくすることで対処します。
デシジョンテーブルを圧縮する危険性については、テスト技法を解説した専門書にも明記されています(*1)。
*1: はじめて学ぶソフトウェアのテスト技法 リー・コープランド著
次の仕様があるとします。
仕様1． AとBがYesの場合はYesを返す。ただし、BがNoの場合はNoを返す。
仕様2． AがNoでCがYesの場合はYesを返す。ただし、CがNoの場合はNoを返す。
この仕様のフローチャートは図１となります。
デシジョンテーブルでを圧縮する危険性はこれだけにとどまりません。デシジョンテーブルはプログラムのコーディングでも使用することができます。デシジョンテーブルを圧縮することでコーディングの量が少なくなるので便利な方法です。しかし、テーブルが誤って圧縮される可能性は常に存在します。このことはテストの場合にも同じことが言えます。プログラムが間違っている場合に、圧縮したデシジョンテーブルが間違っているとバグを見逃すことにつながります。
徹底したテストを行ないたい場合には、デシジョンテーブルの圧縮は行なうべきではありません。CFD技法や原因結果グラフでは、圧縮した後のデシジョンテーブルしか得られないので、徹底したテストを行ないたい場合にはそうしたテスト技法の適用は避けた方がよいでしょう。
デシジョンテーブルによっては、圧縮を行なわないと表が大きくなり過ぎる場合があります。そうした場合には、論理上あり得ない組み合わせを削除して表を小さくしたり、独立性の高い条件（他の条件との関連性がない）を選び出し、別のデシジョンテーブルに分割して表を小さくすることで対処します。
デシジョンテーブルを圧縮する危険性については、テスト技法を解説した専門書にも明記されています(*1)。
*1: はじめて学ぶソフトウェアのテスト技法 リー・コープランド著