Oracle設定でつまづいてしまい、帰るのが遅くなってしまった。
いくつか納得のいくことと納得のいかないことがあるのでもう少し調べてみて、納得がいけば記事にしたいところだ。

最終的にはOracleのバグっぽい雰囲気になったのだが。。。
Oracleセットアップだけは相変わらず信じられねェ・・・

久しぶりにDBマガジンを読んでみた。

今月号の特集では同一のWebアプリを4言語で開発をしてみてその比較をすることでより言語別の特色を把握しながら勉強しようというもの。選ばれている言語は

• Java(Struts2)
• .net (.NET ASP)
• PHP(CakePHP)
• Ruby(Rails)

それぞれの言語を利用して開発をする…という発想自体は面白いもので、期待してみたのだがちょっと無理やり枠におしこめた感があって、中途半端になってしまっている気がした。
まぁ、そもそも雑誌の一特集でそれらすべてを網羅しようということ自体に無理があるのかもしれない。

個人的には今回紹介されている内容は、どれも中途半端な知識しかないので少しは押さえておきたいところ。仕事で今使わないからどうしても割ける時間は限られてしまう。
かといって、本を読んだだけで自分でコードが書けるようになれるほど自分は器用ではない。
必然的にどれかに絞って学んでいかなければ・・・って、そもそも自分自身今やっていることもあるし。うむむむ

器用貧乏になりそうだ。
とりあえず、今は自分の仕事をこなしつつ次なる目標やプロジェクトを温めていくことに徹するのがいいのかもしれません

今日は久々にCをいじっていた。
久々といっても自分がかかわったことのないプロジェクトの産物で、しかもC++から始めたようなものである私にとってCはどちらかというとなじみのない言語。
カタコト的に取り扱っているレベルだ。

問題が起きている個所に対して調査用のログを出力するように変更してコンパイル実行。
ところが、リンカが文句を言いだす。

エラー LNK2001 外部シンボルXXXXが未定義です

見よう見まねで用意されたmakefileを使用してnmakeしているだけなのだが、うまくリンクができていないようだ。
書き換えた部分が問題とも思えなかったが、一応元に戻して実行しても同じエラーが出てしまう。
つまり、最初から用意されていた環境が悪かったことになる。エラーとされている関数はデバッグ用に使われている関数のようだが、そもそもリリース用にコンパイルしているので使っていないはずなのだが…。

当該ファイルは10年以上前のプロジェクト。当然移り変わりの激しい社内にこのプロジェクトに詳しい人間はいない。
これは困った。どうしていいかわからない

分からないのか。考えてないのか

さて、今回困ってしまったのは

• 自分の関わったことのないプログラムだった
• そもそもCに自信がない
• プロジェクトに詳しい人間がいない
• 変更前の状態であっても動かなかった
• これまではそれで動いていた？

等々の理由があったのだ。
結論から言うと、今回の問題は、複数のmakefileのうち、いくつかがリリース用のコンパイル時にまでデバッグとしてコンパイルするような文言が記述されていたことにあった。
恐らく、何かの調査のタイミングで一時的にmakefileを変更したものの、それを元に戻さずにいたことが今回の問題を引き起こしたのだと思う。

だが、今回解決できたのは論理的に答えを見つけたというよりはどちらかというと”手探りで”とか”手当たり次第に”的な手法によったもの。
後々考えてみると、

• リンクのエラー
• 当該関数はデバッグ用のものと思われる
• makefileが正しいことを証明できる人間がいない
• リリース用のコンパイルオプション指定にもかかわらずデバッグ用関数が混ざる

等の事柄から、

• 変更したオブジェクト周りのmakefileに何かしら問題がある
• 変更したオブジェクト周りにDEBUG条件付きコンパイル以外の個所でデバッグ用関数が用いられている

可能性を考え、答えに結びつけることはできたはずだ。
それを行わずに思考停止してしまったのは問題だ。

自分にとって不利な状況だとか、逃げ口上になりそうな内容があるとすぐにそちらへ行こうとしてしまい思考が停まってしまう。いけない傾向にある。
忙しいことは言い訳にはならないので、しっかりと。頭を使うよう教訓として覚えておこう。

昨日に引き続きアート・オブ・プロジェクトから

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

posted with amazlet at 09.11.15

Scott Berkun
オライリー・ジャパン
売り上げランキング: 96079

おすすめ度の平均:

バイブルにしています
プロジェクトマネジメントに関する教科書的な一冊
プロマネ、必読
プロジェクト大災害で大炎上
真のマネジメントがここにある

Amazon.co.jp で詳細を見る

精度か正確さか

見積もりの精度はよく問題にはなるが、どれだけ精度が高くても正確でなければ意味が無いというのが本書で言わんとするところだ。ここで言う”精度”とは数字上の精度。
言ってしまうと、小数点桁何桁まで出した数字だろうと、その出す過程が根拠を伴って出されてない限り、何の意味も持たないってことだ。では、根拠のある数字を出す過程とはどんなものだろうか。

ソフトウェアの開発では、いわゆる機械による大量生産のように同じものをひたすらに作るわけではなく、常に一品モノの物作りとなる。
時には技術的に不明確な部分に対して切り込まなければならない開発。。。というよりは”研究”に近いのかもしれないこれら作業を正確に見積もることなんてできるのだろうか？
しかし、お客様に「いくらかかるか分からないし、いつ完成するかわからないけど頑張ります」なんて言った途端に「それじゃ、いつ発注するかわかんないよ？」なんて言われてしまうかもしれないわけで、なにかしら見積もりはしないといけない。

規模が小さい開発であればそこそこの正確さを持った見積もりが出てくるが、規模が大きくなればなるほど見積もり誤差は大きくなる。自己負担分も増えていく。（デスマーチの）鼓笛隊の歩む音が聞こえてきそうだ。

これは経験にゆだねるしかないのだろうか。

一つの答えとしては多分そうなんだろう。ただし、その”経験”は、”会社としての経験”であって”個人としての経験”であっては困るわけだ。
見積もりに対する根拠・仮説を記録しつつ、結果を検証することを繰り返す必要がある。これは積もり積もったデータベースとして、組織の財産としての扱いを受けるべきだろう。

そもそも誰が見積もるのか

ここまで書いて、ふと思ったのは、”見積もりをしているのはだれなのか？”という事だ。
これは”仕様や設計を行っているのはだれなのか？”という事に置き換える事も出来るかもしれない。

本書では見積もりの精度に関して”優れた設計から生み出される”としている。

優れた見積もりというものは、信頼性の高い設計と要求が揃って初めて生みだされるという事です。そしてエンジニアリングにおける優れた情報と優れたエンジニアという2つが揃って初めて生みだされるのです。（P.40）

そんなに多くの事例を見たことがあるわけではないので断言できるわけではないのだが、見積もりや設計を行うのは実際にコーディングを行うプログラマーやプログラマーのリーダーではなく、”過去にプログラムを組んでいた管理職”か、”プログラムを組んだことのない管理職”が多いのではないだろうか？
そして、何かしらの根拠があって見積もっているわけではなく、感覚論で見積もってしまっているのではないだろうか？

そうであるならば、見積もりはリーダーだけでなくプログラマ、品質を管理する担当者（テスター含む）等にも参加してもらい、そもそも出来あがる機能が、業務的に本当に有益な形でお客様に提供できるようになっているのか？等、様々な角度から求め
ていかなければいけないだろう。

ただ、未受注の機能に対してここまで大がかりな見積もり体制を築き上げてしまうと、実は中小のソフトウェア会社では回らなかったりする。要するにお金になるのか分からない作業に対して人を割り当てる余裕が無いということだ。もちろん、そういう企業の場合はプログラマからテスターまで多くの作業を兼任するので必然的に少人数にはなるだろうが、それはそもそも人が足りないわけで、逆にノリで見積もりをしそうだ。

私が所属している組織において、本書でいう”正しい見積もり”が完全に機能しているとはとても言えない。見積もりが個人のスキルによってしまい、引き継ぎも出来ないうえに当たり外れが出始めている。
銀の弾丸が無いとはいえ、組織内において蓄積された基準や、見積もる上でのプロセスを見直す必要がある。
動かなければいけないな

このプロジェクトマネジメントを続けてはだめだ！！もういい加減に成長しなければいけない。
そんな思いからアート・オブ・プロジェクトマネジメントを読んだ

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

posted with amazlet at 09.11.15

Scott Berkun
オライリー・ジャパン
売り上げランキング: 96079

おすすめ度の平均:

バイブルにしています
プロジェクトマネジメントに関する教科書的な一冊
プロマネ、必読
プロジェクト大災害で大炎上
真のマネジメントがここにある

Amazon.co.jp で詳細を見る

目次

• 計画
  • スケジュールの真実
  • やるべきことを洗い出す
  • すぐれたビジョンを記述する
  • アイデアの源
  • アイデアを得た後にすること
• スキル
  • 優れた仕様書の記述
  • 優れた意思決定の行い方
  • コミュニケーションと人間関係
  • メンバーの邪魔をしない方法
  • 問題発生時に行うこと
• マネジメント
  • リーダーシップが信頼に基づく理由
  • ものごとを成し遂げる方法
  • 中盤の戦略
  • 終盤の戦略
  • 社内の力関係と政治

そもそもなぜソフトウェア業界はこんなにもプロジェクトマネジメントを声高にする必要があるのだろうか。
事業規模で考えれば他業界でもっと大きなプロジェクトはたくさんある。もちろん、それらプロジェクトがすべからく成功を収めているかというとそうとは言い切れない部分はあるが、、、

本書はプロジェクトマネジメント全般にわたって書かれてはいるが、ここではこの頃私を悩ませている仕様書に関しての話題に言及したい

仕様書は必要か？

本書ではプロジェクトに必要となる書類として以下のものを定義している

• 要求仕様
  • プロジェクトに期待される様々な物事を文書化するため、作業によって達成されるべきすべての要求と責任の概要を記述する
• 機能仕様
  • 顧客の視点から見た特定のシナリオやシナリオ群における振る舞いや機能を記述したもの。ソフトウェアの機能をユーザーインターフェースを通じて解説し、なるべく技術的な詳細に踏み込まないようにしつつ、物事の動作方法を解説する。要求の一覧ではなく、それを実現するための機能の一覧。
• 技術仕様
  • 機能仕様を満足するために必要となるエンジニアリングアプローチの解説。もっとも複雑なコンポーネントや、他のプログラマが再利用する可能性のあるコンポーネントを開設したり、機能仕様に必要な作業項目に対して技術的な裏付けを提供できるだけのレベルで十分。
• 作業項目一覧（WBS）
  • 機能仕様を満足するために必要となるプログラミング上のタスクを解説したもの。
• テスト基準とマイルストーン達成基準
  • 各テストケースの優先順位と、各マイルストーンにおける品質目標を満足するためには、コードが該当テストケースにおいてどの程度正しく動作する必要があるのかという目標。

私のこれまで携わったプロジェクトでは、要求仕様や機能仕様を合わせて外部仕様書と読んだり、機能仕様と技術仕様がごちゃっとなって内部仕様書と読んだりしていた。ちなみにWBS、テスト基準等はそれぞれの文書として独立させることになる。
恐らく本書で述べられているこれら内容は別に独立した文書である必要はなく、それらを網羅するべきということなんだろう。

私の場合は転職経験があるわけでも、大学でソフトウェア関連のことを学んだことがあるわけではないので他にどういう形の文書があるのかは知らないのが現実だ。
内部仕様書に記述する技術仕様は、どの程度まで記述するのかが問題となるのではないだろうか。仕様書を書くことが本来達成するべき仕事ではないので、これらの切り分けをどうしていくのか…。内部仕様書に関しては、社内の誰に対して文書を書くか？ってことになるのかもしれないなぁ

仕様書と設計書の違い

設計段階では仕様は固まっていない。未確定な内容が含まれており、それに対する議論や検証を行う必要がある。それらを経て、実際のモノづくりを行う作業の前に仕様書を作るべき。
設計書と仕様書を同時に作成しようとした場合、設計の変更に伴う仕様書の修正工数ばかりが増大していき、仕様書は意味のあるものとして成り立ちづらい。もしくは計画そのものが破たんする。これらは全く別のプロセスとして動かす必要があるだろう。

ううん、言っていることは分かるが…。
実際のところ、現場では設計書と内部仕様と作業指示がめちゃくちゃになっている。内部仕様書が正しく仕様書としてなりたっておらず、中途半端な設計書になっているだけだった。
だからこそ、”何の文書を書くのか”ということが明確になっておらずに、文書の作成に行き詰ってしまっているのだと思う。
そう考えると、これらを全く別のプロセスとして捉えて取り組むというのは分かる話ではあるのだが…。
ううん、時間がないっていう言い訳をしてはいけないのは分かるが時間がない。時間を捻出する手立てを立てなくてはいけないなぁ

多くのすぐれた仕様書では、設計が階層に分けられた上で記述されている。まず最初に、顧客のエクスペリエンスが顧客の言葉で記述されている。次に、基本オブジェクトの大まかな概要とアーキテクチャが記述されている。そして最後に、エンジニアリングにおける、設計上の複雑かつ詳細な問題が記述されている。

ふむぅ
やはり、仕様書か設計書か。
どうしても私は今自分が見ている”仕様書”が頭に入ってしまっていてここで述べている”仕様書”との間には隔たりがあるようだ。この隔たりを解消するにはどうしたものか…。やはりここでいうところの”優れた仕様書”を見てみるのが一番だと思う。

Joel on Softwareでおなじみのジョエル氏のページには氏が”優れた仕様書”のサンプルを出している

• 仕様書とはどんなものか？(Joel on Software)
  • http://local.joelonsoftware.com/wiki/%E3%82%84%E3%81%95%E3%81%97%E3%81%84%E6%A9%9F%E8%83%BD%E4%BB%95%E6%A7%98_%E3%83%91%E3%83%BC%E3%83%882:_%E4%BB%95%E6%A7%98%E6%9B%B8%E3%81%A8%E3%81%AF%E3%81%A9%E3%82%93%E3%81%AA%E3%82%82%E3%81%AE%E3%81%8B%3F

• 機能仕様書サンプル　(Joel on Software)
  • http://local.joelonsoftware.com/wiki/WhatTimeIsIt_Jp

んー・・これ見たことあるな…。たぶんJoel on Softwareにそのまま載ってるな…。

はい、出直してきます

私の管轄しているプロジェクトではないのだが、別プロジェクトが火を吹いている。
なんでもお客様からの品質に関する要望に対して提出している書類が思うように理解されないというものだった。

最初からプロジェクトがつつがなく進行している場合は問題がないのだが、数度問題が発覚するとお客様側の担当者としても黙ってはおれず、チェックが厳しくなる。
ただ単にチェックが厳しくなっているだけならばそれほど問題ではないのだが、ソフトウェアに対する品質管理を担当したことがないお客様がチェックを厳しくしようとするのが結構問題なのだ。

まず、言葉が通じない。
一通り書類を書いたところで、言葉の定義を一つずつ教えていかないとその文書を読むことが出来ていない。普通なら「こんな感じかな～？」っていうニュアンスで乗り切るのだが、”疑いの目で品質チェックをしようとしている”お客様としてはそうはいかない。
もちろん、書き方の問題もある。一言”モジュールテスト”だとか”ユニットテスト”だとか言っても、ソフトウェア業界ですら会社によって言葉が何を指すのかがバラバラな状態であることをよく聞く。
このあたりは、いわゆる製造業だとかその他産業との歴史の差が出ているのかもしれない。ソフトウェアの品質管理においての業界標準となりえるとすれば、国際的にはISTQB規格。日本ではJSTQBになるのだろうか

JSTQB
http://jstqb.jp/

しかし、”ユニット”の定義に関して明確になっているわけでは無いんじゃないだろうか？正直なところJSTQBとろうと思ったことないから分からないのだが…。
ただ、いわゆる目に見える機械の”部品”と、ソフトウェアのプログラム上の”部品”とでは実際に手にすることが出来ない分、考え方を変えていかないといけない。

もっとも、お客様にそこまで疑問視されるようなところまでいっている時点で問題なんだけどね。
ただ、ソフトウェアの場合は目に見えないものであるがゆえに、別業界の人に説明する時、言葉に関しては最新の注意を払わないと余計なコストをひたすらにかけることになってしまうなぁ、と思った。
ただ…気をつけないとって言ったところで、自分がその矢面に立たされた時に乗り切れるだろうか？ちょっと考えてしまうなぁ

iPhoneを手にしたことで、より気軽にWebを見ることができるようになりました。
もちろん、PCと違って画面が小さかったり、入力スピードが遅かったりと難点はあるものの、それはモバイル端末なのである意味どうしようもないこと。割りきって使っています。
ただ・・FLASHを使ったサイトを見ることができないんですよね。

アドビ、「Flash Player 10.1」を発表–スマートフォンやネットブックに対応
http://japan.zdnet.com/news/software/story/0,2000056195,20401073,00.htm

現時点では、Flashは『iPhone』上で使用できない。これまでのところ、われわれは必要なサポートをAppleから受けていない

これはどういうことなんだろうか…。Appleが出し惜しみをしているのか、それともAppleとしてはFlashに対してまだまだ問題があると認識されているのだろうか。
いずれにしてもフルブラウザを搭載している以上、Flashを使用しているサイトは必然的に訪れるわけなので、何らかの対策は取ってほしいですね。

Silverlightはどうだろう？

少なくともSafariには無理だろうなぁ～って検索していたらこんなものを見つけた

Deep Zoom style on iPhone – Seadragon for Mobile
http://timheuer.com/blog/archive/2008/12/15/deep-zoom-and-photosynth-on-iphone.aspx

おぉ？
Seadragonと言えば、SilverlightでいうところのDeepZoom機能を実装しているやつ。ってことは、これで使えるのか？？ってことで早速インストールしてみた。

AppStoreで「Seadragon Mobile」で見つけることができる。

起動していくつかのギャラリーの中から高解像度の画像を見ることができる。。。。って、これじゃブラウザとは関係ないじゃないか！！

結局のところ、Silverlightも当然のようにSafariでは使用することができない。他のブラウザではどうなのか？もう少しプラグインであれこれできるものがあってもいいものだが…Appleがそれを許さないんだろうな。
このあたり、もう少し融通が利いてもいいと思ってしまう私はWindowsになれすぎているのだろうか。

2003年ごろに出版された本に、Tomcatを単独でWebサーバー/JSPコンテナとして使用するよりも、IISをWebサーバーとして使い、Tomcatをサーブレット/JSPコンテナとして使うほうが性能が向上すると書いてあった。ここで言う”性能”が何を意味するのかは気になるところではあるけど、ネット上を見てみると、そう言った事例はいくつか見受けられる。
今回の要求内容としては、同一サーバーにてServletによるサイトとASP.NETによるサイトを共存させたいという事。「別にServlet側は8080使えばいーじゃん」って言ってしまうとそれまでなのだがそうもいかないらしい。
あちこちに情報は載っているのだが、情報が分散してしまっているのか”この設定は当たり前だよね”という事なのか、実際にやろうとして手間取ってしまったのでここをチラシの裏としてメモする。
ここではTomcatのバージョンは6.0.18。WindowsはVista（32Bit）でIIS7.0。使用したisapi_redirect.dllは1.2.28になる。

isapi_redirect.dllの配置

http://apache.justdn.org/tomcat/tomcat-connectors/jk/binaries/win32/
から最新版のisapi_redirect.dllを入手する（isapi_redirect-1.2.28.dllをダウンロードしてファイル名を変更）。
任意のディレクトリへコピーする。ここでは「C:\Tomcat6\bin\isapi」へコピーしたとする。

ここでは32BitのOSでの話なので64Bitでは別なファイル（http://apache.justdn.org/tomcat/tomcat-connectors/jk/binaries/win64/）になる。

isapi_redirect.propertiesファイル作成

isapi_redirect.dllをコピーした場所で「isapi_redirect.properties」ファイルを作成する。中身は以下の通り

extension_uri=/jakarta/isapi_redirect.dll
log_file=C:\Tomcat6\logs\isapi_redirect.log
log_level=debug
worker_file=C:\Tomcat6\conf\workers.properties
worker_mount_file=C:\Tomcat6\conf\uriworkermap.properties
uri_select=unparsed

この内容はレジストリでも代用できる。その場合は「HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0」に対して同様の内容を設定することになるが、ここでは割愛する。レジストリを使うべきなのかもしれないが、代替案があるのであれば、極力触りたくはないものだ。

workers.propertiesファイル作成

isapi_redirect.properiesファイルで指定した場所（ここでは”C:\Tomcat6\conf\”）に「workers.properties」ファイルを作成。
ファイルの中身は以下の通り

ps=\
worker.list=jakarta
worker.jakarta.port=8009
worker.jakarta.host=localhost
worker.jakarta.type=ajp13

uriworkermap.propertiesファイル作成

isapi_redirect.properiesファイルで指定した場所（ここでは”C:\Tomcat6\conf\”）に「uriworkermap.properties」ファイルを作成。
ファイルの中身は以下の通り。ここでは、”examples”サイトへのリダイレクト設定を行う

examples/*=jakarta

IISに対する全てのアクセスをTomcatに対してリダイレクトする場合には「uriworkermap.properties」ファイルに対して
/*=jakarta
のように書く形で設定する。「uriworkermap.properties」ファイルの記述方式としては
[URL]=[WORKER_NAME]
になっている。

例えば、JSPとServletに対してはTomcatで処理するけどそのほかはIISで処理したい時には

examples/*.jsp=jakarta
examples/servlet/*=jakarta

のように記述することになる。ASPとJSPの同一サイト内での共存が可能に！需要あるのか？

IISに対する設定

1. IISマネージャにてサーバーホームより「ISAPIおよびCGIの制限」を開き”isapi_redirect.dll”を追加する。説明は適当で。
2. IISマネージャにてサイト配下の”Default Web Site”を選択。”ISAPIフィルタ”を開き同様に”isapi_redirect.dll”を追加する。名前はなんでもいい
3. IISマネージャにて、”Default Web Site”に対して”仮想ディレクトリ”の追加を行う。エイリアスには”jakarta” 。物理パスは”C:\Tomcat6\bin\isapi”を入力する。
4. 追加した仮想ディレクトリを開き、”ハンドラマッピング”を開く。”スクリプトマップの追加”を実行し、下記内容を設定する。

要求パス：*
実行可能ファイル：C:\Tomcat6\bin\isapi\isapi_redirect.dll
名前：jakarta

1. IIS再起動

上記手順によって、”http://localhost/examples/“に対してのアクセスがTomcat側にredirectされる形になった。TomcatがWebサーバーとして動作する”http://localhost:8080/examples/index.jsp“は当然としてIIS側からもちゃんと動作するって言う事ね。

この話を聞いた私の最初の理解だと、仮想ディレクトリ”jakarta”に対してアクセスを行った場合にTomcatに対してリダイレクトするのだと思っていた。だが実際は違って、IISのサイトに対してアクセスがあった場合に拡張設定された仮想ディレクトリ”jakarta”を利用してisapi_redirect.dllが起動。uriworkermap.propertiesに記述されたサイトでフィルタがかかりTomcatにリダイレクトされるって言う事かな？このあたりの理解はまだ足りないかもしれない。

C#を勉強したいっ！っていう個人的思いとは裏腹に、会社の思惑は別のところにあって、今携わっているプロジェクトではJavaを使用しています。
実際のところ、マネージメント業務が多すぎて自分でソースをいじる機会が少なくなってきてはいるのですが、部下をうまいこと使いながら少しずつ私自身も身につけていけるよう試みています。
それにしても、これまで扱っていたのがIISやC++。次に使うのがTomcat＋Javaという、まったく異なる環境なのでそれはそれで面白そう。
あぁぁぁぁぁああああ。だれか代わりにマネージャやってくんないかなー
なんて思ったり思わなかったり。

ソフトウェアとセキュリティの組み合わせだと、真っ先に思いつくのはウィルスや不正侵入を防ぐ話だ。ウィルスや不正侵入によってもたらされる被害は増えているんだろうけど、今日は違う話。不正コピーの話だ。

ソフトウェアのコピー

ソフトウェアの不正コピーを防ぐ方法として私がぱっと思いつくのは

• 指紋認証
• USBキー
• ワンタイムパスワード

実際に私が使ったことのあるのはUSBキーによるプロテクト。プログラムの中から指定のUSBキーがPCに刺さっていないとプログラムが動作しないという、比較的ポピュラーな方法（だと思う）。
ネットを介して認証を行うプログラムや、PC固有の環境変数を利用したものも使ったことはある。
こういう認証技術とそれをクラックする技術ってのはいたちごっこなんだろうなぁと思っている。まぁ、いたちごっこといっても、苦労して新方式の認証技術を取り入れたとしてもそれを打ち破るのは早くて数時間なのだろうから勝負になっていないのかもしれない

今ではコピーだけとは限らないらしい

ちょっとしたことで、そういうセキュリティ関連を手掛ける企業の方と話をする機会があった。そこで聞いた内容は私にとってはちょっと驚きだった

• プロテクトを破るというよりはプロテクトを使う側を狙う。つまり実行ファイルを書き換えてしまう
• プロテクトを無効にするだけじゃなくて、別なキーで起動できるように書き換えることもできる
• 解析してソースコードを取得。それを別な形で作り変えて再販する
• CADデータや設計情報は速攻で流出して売買される
• ロボット等に搭載されているプログラムにも同様のことが言える
• 改変されたプログラムで、あっさりと取られて相手に理論武装され、結果裁判でも負けてしまうこともある

等々。まぁ、技術の詰まったプロテクトキーをがんばって攻略するよりは実行ファイルの内容を書き換えてしまったほうがよっぽど早いだろうってのは言われてみればその通り。ただ、私が抱いていたイメージでは
お金を払わなくてもシェアウェアが使用できる
ってのが不正コピーなわけだったので、それを自らの収入源に変えてしまおうというのは、なるほどって思ってしまった。さすがにかの国はやることがすごいな、と。そりゃ強制開示を求めてきたりもするわな。
ま、今となってはかの国に特定される内容ではないのだろうけど。

どうするのか

実行ファイルが弱いのであれば、実行ファイルそのものを暗号化してしまおうというのが、今回お話を聞いた内容であった。
実際のところどうなんだろうなぁ…。結局のところいたちごっこなのではないだろうかと思ってしまったのが本音である。どれだけ暗号化を施そうとしてもPC上で動作する以上は動かす方法があるわけで…うーん。どうなんだろう。こればっかりはわからないな。
空き巣の被害じゃないけど、「がんばれば破られるけど、容易に破られるのを防ぐ」ことができれば空き巣の多くは回避できるらしい。ソフトウェアのプロテクトに関してもある程度のところまではそういう妥協をするしかないのだろうか。
プログラムに対する知的財産の保護って難しいものだなって今更ながらしみじみと思ってしまった。

解析魔法少女美咲ちゃん マジカル・オープン!

posted with amazlet at 09.07.03

やねう解析チーム
秀和システム
売り上げランキング: 16229

Amazon.co.jp で詳細を見る