ソフトウェア開発」カテゴリーアーカイブ

分からないとしてしまってはいけない

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

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

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

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

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

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

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

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

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

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

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

等の事柄から、

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

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

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

見積もりに対する考察

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

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
Scott Berkun
オライリー・ジャパン
売り上げランキング: 96079
おすすめ度の平均: 4.5

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

精度か正確さか

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

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

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

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

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

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

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

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

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

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

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

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

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

マイクロソフトのプロジェクトはアートなのか

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

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)
Scott Berkun
オライリー・ジャパン
売り上げランキング: 96079
おすすめ度の平均: 4.5

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

目次

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

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

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

仕様書は必要か?

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

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

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

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

仕様書と設計書の違い

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

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

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

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

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

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

はい、出直してきます

形あるものと形なきもの

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

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

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

JSTQB
http://jstqb.jp/

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

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

iPhoneとFlashとSilverlightと

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機能を実装しているやつ。ってことは、これで使えるのか??ってことで早速インストールしてみた。
f:id:krote:20091006003353p:image

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

f:id:krote:20091006003351p:image

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

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

IIS + Tomcat

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上で動作する以上は動かす方法があるわけで…うーん。どうなんだろう。こればっかりはわからないな。
空き巣の被害じゃないけど、「がんばれば破られるけど、容易に破られるのを防ぐ」ことができれば空き巣の多くは回避できるらしい。ソフトウェアのプロテクトに関してもある程度のところまではそういう妥協をするしかないのだろうか。
プログラムに対する知的財産の保護って難しいものだなって今更ながらしみじみと思ってしまった。

解析魔法少女美咲ちゃん マジカル・オープン!
やねう解析チーム
秀和システム
売り上げランキング: 16229

IEのToolbarを作ってみたが・・・

あれこれと試行錯誤しながら、IEのツールバーを作成して、そこからIHTMLDocumentClass等を駆使してページの操作が行えることは何とかできた。ActiveXコントロールに対する捜査はまだ試してはいないけど、できないことはないだろうと思う。ただ・・・
考えてみると、Webアプリケーションの場合機能が分かれた時に別ウィンドウを立ち上げることがよくある。。。と思う。少なくとも私がテストしたいアプリケーションはそうだ。
この場合、IE8では特に別のIEインスタンスが起動してしまうためにそちらに対しての操作がうまくいかない。うーん、これはちょっとハードルが高そうだ。

ウィンドウをオープンさせるイベントをフックさせて新規のウィンドウではなく、フレームわけした場所にそのウィンドウをオープンさせることができれば何とかできるかもしれないが、そこからもウィンドウを開くといくつフレームを用意するんだー!って話になってしまう
結局、IEとは別の場所から制御するしかないのか。。。しかし、そうすると操作できることに限界が来てしまいそうだ。。。
あああああ

もう寝る

ソフトウェア開発未来会議

以前ご紹介した(id:krote:20090212)ソフトウェア開発未来会議へ話を聞きに行ってきた。会議の形式としてはパネルディスカッション。登場したのは

・東証コンピューターシステムの松倉氏
・イーストの下川氏
・アプレッソの小野氏
・アークウェイの森屋氏
・ジャーナリストの新野氏
・デジタルアドバンテージの小川氏
http://www.developerscafe.jp/future/offline/index.html

の面々。最近よく見かける方々がいる。
アークウェイの森屋氏は最近よくこういう場で見かけるようになった。最近見かけるようになったのはただ単に私がそういう場に行くようになっただけなのかもしれないけど。イーストの下川氏はWindowsAzureを使用したサイト(TORIPOTO(トリポト)を作成したという事でTechDaysで紹介されていたので知っていた。アプレッソの小野氏はブログ(http://blog.livedoor.jp/lalha/)も有名だしね。
というわけでどんな話が飛び出るか楽しみで行った

話題の中心は

今回、パネルディスカッションで話される内容として事前に予定されていたのは

  1. 世界不況に対して
  2. クラウドコンピューティング
  3. これからのソフトウェア開発は

という3つのテーマが挙げられていたわけだが、2時間半(30分延長)の時間の大半はクラウドコンピューティングに対して向けられた。
時流というかなんというか、しょうがないといえばしょうがないのかもしれないが3番目のテーマに関してこの面々が経営者の視点からどう考えているのか。今後、どういう風にしていこうと考えているのかを楽しみにしていただけに少々期待はずれだった。
まぁ、軽食ありの休憩を含んだ時間という設定で、この3つすべてに対して2時間では全然足りないということだろう。クラウドコンピューティングに対しての議論がそれだけ白熱したという事もあるのかもしれない。ただ、それぞれの見解や立場の相違から議論そのものは随分と変な方向性を向いてしまっていたのではないだろうか。
確かにクラウドに対しての不安や危惧は尽きないものだけど、それを論じるために集まった訳ではないのではないだろうか。可能性を語る上で危険性に目を向けなければいけないのはその通りなのだけど、限られた時間の中で本来の目的である”幅広い視野に立った将来設計へのヒント”を達成する方向で論じてほしかった。

個人から見たクラウド。組織から見たクラウド

今日一番の収穫だったのは個人から見たクラウドに対する視点だったように思う。
これは、いわゆるiPhoneのAppStoreのように、個人が提供するソフトウェアの一つの形態として成り立たせることを容易にするのかもしれない。
これまで、アイデアはありながらも公開サーバー等を自前で所有・維持する事が出来ないゆえに埋もれていったソフトウェアの提供。これが、たとえばWindowsAzureのような環境を利用する事によって随分と敷居を下げることができるのではないだろうか?企業に勤めていながら、起業というリスクを負わなくても実行できるのではないだろうか?
ちょっとぐらっときた。
なるほど、この視点でAzureを見てはいなかった。まだWindowsAzureの価格設定が出てきていないので実際のところはわからないが、正直”企業向け”という位置づけでしか見ていなかった。もしそういう見方が可能ならば色々とこの界隈は面白い事になるのかもしれない。レンタルサーバーとの違いって奴を見せてほしいものだ。

一方で、組織。つまり企業がクラウドに対してソフトウェアを提供する事に関しては意見は別れた。
クラウド上にこれまでオンプレミスの環境で構築していたサービスを乗せるとなると、対象とするシステムによってその容易さや考慮する内容というものは変わってくるはず。
コンシューマ向けのサービスに関して言ってしまうと、比較的容易であると思う。さらに、サービスの提供期間が短かったりする場合には初期コストを考慮するとクラウドを使用したほうがコストの削減になりそうだ。ほら、芸人のサイトなんていいんじゃないだろうか。2年くらい持てば人気が…。
ただ、企業内のサービス。特にミッションクリティカルな内容になると、“少なくとも今は”難しいように思う。クラウド上のサービスはインターネットありきなので、何らかの回線不具合があった瞬間にどうしようもなくなってしまうのだからだ。手元にデータも何もないので手の打ちようもなくなってしまう。
結局のところ、これらの技術動向に対して、法整備や環境が整っていないのだと思う。ミッションクリティカルな内容になれば必ず日本の企業は”誰が保障するの?どこに訴えればいいの?”ってなるし、個人情報を扱うとなると”プライバシーマークやISMS取ってくれてるの?”となる。もちろん、それらはいろいろな問題を考慮して作られたものであるので否定はしないけどね。しまいには”データは日本にないと駄目だよ”とか言い出しそうだ。
まだまだこれからこれから。どう考えていくのかを考えていかなければいけませんね。

これからの会議

ソフトウェア開発未来会議が、今後どういう話の方向性をたどっていくのか。2回目のオフライン会議があるのかはわからないが、クラウドに限らず話を進めていってほしいと思っている。”ソフトウェア開発者”は別にWebやっている人ばかりではなく、組み込みの開発者もいればローカルのアプリケーションの開発者もいるわけだし。
これだけ目まぐるしく技術内容が変化し続けている業界において、この会議に参加されている経営者の方々がどう考えているのかは気になるところだ。
自分を含め、考えていかなければいけないだろう。

あぁ、また長々と書いてしまった。。。