いわブロ - みんなのアイデンティティ: Identity Management & Developement Environment

私事になりますが、８月３１日付けでSunを退職することになりました。旧Netscapeのサーバ製品に付き添って、その頃はAOL傘下にあったNetscapeからSunに移って来たのは、もう７年近く前の話になります。その後、ブランド名は、iPlanet, Sun ONE, Sun Java Systemと変わりましたが、パートナーやSunの皆様の支援を得て、ここまでやって来ることが出来ました。ありがとうございました。

近頃では、これらの製品はオープン・ソース化されて、誰でも自由にその技術的内容にアクセスできるようになって来ました。言うまでもなく、オープンソース・ソフトウェアは、時代の流れになっています。この潮流に乗らない手はないと考えて、次の勤め先を決めました。９月１日からは、オープンソース・ソリューション・テクノロジ（株）にお世話になります。（次の会社の紹介をSunのブログでやるのは適当でないかもしれないので、別の機会にしますが、とてもすばらしい会社です。）

オープン・ソース化されたSunの製品につきましては、External Contributorとして、その改良に協力して行くつもりです。特に、OpenSSOの日立指静脈認証モジュールは、引き続きメインテナンスを担当します。オープンソース・ソフトウェアに関して言えば、Sunの社外からも協力できることは他にも色々あると思います。

退職後はSunのブログを更新することは出来なくなるため、移転先を作りました。未だ、記事は何も書いていませんが。。。

新しい会社のことなどを書いて行く予定ですので、期待していて下さい。

それでは、どうもありがとうございました。

東京の桜は散ってしまいましたが、SCSA　（Sun認定 Solaris システム管理者）試験のパートIIを受けてきました。今は、連休の谷間ということもあり、業務にも少し余裕があります。忙しくなる前に、パートIIの試験に合格しておきたかったのです。試験会場に行ってみると、かなり込んでいました。連休の後半が始まる前日にもかかわらずにです。同じような事情の人が多いためでしょうか。

結果は９０％の正答率　(55/61) で合格でした。問題はこれをどう見るかです。９割も合っていたと見ることも出来れば、１割も間違っていたと見ることも出来ます。しかし、我々の役割のひとつが、『Solarisを含めたSunの優れた技術を日本のお客様に正しく伝えること』であることを考えれば、１割も間違えることは問題です。１０回に１回は間違った情報が伝わってしまうと言うことですから。

言うまでもありませんが、弊社サポートから出される回答が、１０回に１回間違っているということではありません。複数の担当者が必要に応じて検証を行った上で回答を作成しています。気をつけなければならないのは、お客様を訪問して、その場で質問に答えるというようなケースです。簡単な質問でも、即答せず、持ち帰って検討する勇気が必要だと思いました。今回の試験でも、「上手く行けば満点か？」とも思ったのですが、そんなことは全くなかったので。

SCSA (Sun Certified System Administrator for Solaris 10) の試験を受けてきました。この試験にはPart　IとPart　IIがありますが、今回はPart　Iの方に合格しました。

まずは、なぜSunの社員がSolarisの試験を受けるのかについて説明しなければなりません。タクシーの運転手が普通免許の試験を受けるようなもので、受かって当たり前、受からないと少し問題かも？という感じがあるかもしれません。しかし、実際は、そうでもないのです。社員にはそれぞれ担当分野があり、それ以外ではたとえSolarisの機能でも知らないことがあります。日常の業務に追われれば追われるほど、知識に偏りが生じます。また、Solarisは日々進化しています。定期的に勉強しなければ得た知識はすぐに古くなってしまいます。

私はと言えば、Solarisは、それ以前のSunOSの頃から使っていますし、開発や移植のターゲットには必ずSolarisが含まれていました。多くの場合、開発のプラットフォーム自体がSolarisでした。システム管理者として働いたことはありませんが、自分のワークステーションは自分で管理するという意味ではシステム管理もしています。ですから、『Solarisを知っているか？』と聞かれたら、『良く知っています』と答えるはずです。そのため試験にも自信がありました。

試験の準備のために、翔泳社から出版されている『SUN教科書　Solaris　１０』という本を買いました。「サン・マイクロシステムズ監修！」と背表紙に大きく書かれているので良い本に違いありません。本を読み始めると、ずいぶん知らないことが試験範囲に含まれていることに驚きました。これだとかなり勉強しないと受かりそうにありません。特にプリンタの設定は今までやったことがありません。また、バックアップとリカバリに関してもかなり知識があやふやです。その反面、セキュリティやアクセス制御に関しては、自分の担当分野に近いこともあり問題なさそうなことも分かりました。

心を入れ替えて勉強をしました。上記の教科書を良く読んで、主要な手順は実際にやってみました。SolarisのインストールについてはSPARCとx86について何種類かのパターンを試しました。いつも使っているOSが、突然、最新版のSolaris　１０になったのでびっくりした同僚もいるかもしれません。　――　これから文句がくるかも？　――　また、バックアップ、リカバリについても実際にやってみました。しかし、プリンタの設定に関しては、設定可能なプリンタがなかったのでやっていません。MANページやオンラインドキュメントを読んでオプション等を確認しました。１ヶ月くらい勉強しましたが、実際には２０日（祝日：春分の日）と土、日を合わせた「三夜漬け」です。

試験を受けるまでは自信がなかったのですが、結果は思ったよりも良く、５９問中、５５問正解しました。Sunの社員ならもっと出来て当然という考えもあるかもしれませんが、内容はかなり難しいと思いました。逆に言えば受かることに意味があります。時間のあるときに受験してみては如何でしょうか。

 

先日、SSHAの仕様について問い合わせを頂きました。そのとき気がついたことをお知らせします。

SSHA(Salted SHA)は弊社Sun Java System Directory Serverをはじめ、他のディレクトリ・サーバでも使用されているパスワードを保存するためのアルゴリズムです。パスワード保存のアルゴリズムは多くありますが、多くのサーバでSSHAがディフォルト設定になっています。

"Salt" （塩）はサーバ側で生成する乱数です。サーバは、ユーザから送られて来たパスワードを保存する際に、パスワードにこの乱数を付加した上でハッシュ値を計算します。こうすることで同じパスワードをつけたユーザがいても、サーバ側では異なる値が保存されるため、セキュリティ・レベルが向上します。パスワードに塩で「味付け」するという感じでしょうか。

様々なサーバやツールのSSHAの実装を調べたのですが、気になることがありました。サーバやツール毎に"Salt"の長さが異なることです。弊社のDirectory ServerやOpenDSなどは８バイト派ですが、古くからある他のサーバやツールでは４バイトしかとっていないものがありました。これによりセキュリティ上の問題や互換性の問題が発生するというわけではありません。ユーザから送られてきたバスワードを確認する処理で固定の長さの"Salt"を想定していると困りますが、弊社のサーバを含め他のサーバも私が見た限りは問題ないようです。

と言うことは０バイトでも良いということになります。０バイトの"Salt"を付加するとは、付加しないことと同じです。そのため、０バイトの"Salt"が付加されたハッシュ値を使ったパスワード確認のアルゴリズムはSHAと全く同じということになります。試しにちょっとイタズラしてみましょう。まずSHAを使ってユーザのパスワードを保存します。保存した内容は以下のようになります。

userPassword: {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

パスワード保存のアルゴリズムを示す{SHA}の部分に"S"を追加して｛SSHA}にして見ます。その右側にあるハッシュ値自体には変更は加えません。

userPassword: {SSHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

これでもちゃんと認証に成功しました。

以上です。何の役にも立たない情報ですみませんでした。

オースチンから帰ってきて、1週間ほど日本にいた後に、今度はサンタ・クララに来ています。時差ぼけのトリプルパンチで、体調を崩してしまいました。時差の他にも、英語でしゃべることや、道路の右側を車で走ることなど、慣れないことをするため、ストレスもあります。さらに、ミーティングでは、私が英語で一所懸命しゃべっているのにも関わらず、理解しない人もいます。不愉快極まりないことです。

 本当のことを言うと、英語の発音や聞き取りには自信がないのです。しかし、滅多にないことですが、今回に限り、私の方が正しく発音している単語がありました。それを紹介したいと思います。「SQL」というデータベースに問い合わせをする際に用いる言語があります。アメリカ人はこれを「シックル」というように発音します。初めて、「シックル・サーバ」という発音を聞いた時には、シック・サーバと聞こえたため（ルの音が聞こえませんでした）、サーバが病気に罹ったのかと思いましたが、これはSQL　Serverのことでした。

何かと話題になっているMySQLですが、アメリカ人はこれを「マイシックル」というように発音します。しかし、「マイエスキューエル」が正しいのだそうです。もちろんSunの社員はそれを知っています。しかし、「シックル」と言い慣れているため、どうしても会話では「マイシックル」と言ってしまいます。そんなときは、私が、「マイ・エス・キュー・エル」とわざとゆっくり発音すると、相手も慌てて言い直してきます。日本では昔からこう発音しているので、私は言い間違えません。私の人生で今までなかったことです。ちょっとしたストレス解消になっています。

昔、同じようなテレビ・コマーシャルがありましたよね！　――　若い人は知らないかも？。坊屋三郎が外国人の「クイントリックス（松下電器のテレビの名前）」の発音を純日本風の発音で直すというCMです。この情景が浮かんできて、可笑しくなってしまいました。はたから見れば、そんな感じなのかと思います。

ちなみに、 Vaau というロール管理用のソフトウェアもあります。こちらは、日本人の感覚で言えば、「バーウ」と発音すると思いますが、正しくは「バーユ」です。初めは私も間違えましたが今では大丈夫です。おばあさんがお風呂に入っている情景を思い浮かべるようにすようにすれば忘れません。

後一日で、日本に帰ります。 帰ったらソフトウェアの行商です。

 

前々回のブログでオースチンが普通の街というように書きましたが、間違いであったようです。こちらの人と話をしたら"Keep Austin Weird"というこの町のスローガンを教えて貰いました。米国でも大型ショッピングセンターが出来ることにより地域の商店街が寂れたり、大企業が進出することにより中小企業の経営が上手くいかなくなったりすることがあります。これは、ある程度は仕方がないことですが、あまり極端だと米国の町が全て均一になってしまします。そこで、地域の商店やビジネスを守ることによりオースチンの特色を大切にして行こうというのが、このスローガンの意味なのだそうです。実際、テキサス大学があるためもあり、テキサス州のなかでは突出してリベラルな土地柄であると言えます。また、ライブ演奏が盛んであるという特色もあります。

昨日は、Identity Manager開発部門のマネージャにライブ演奏を聴きにつれていって貰いました。とても楽しかったです。

 

出張でテキサス州オースチンに来ています。

通路側の席といつも予約している航空会社なのに、満席のため、窓側の席になってしまいました。出発からちょっと不満。その後、何が起こるかは、花木さんのブログを見て下さい。日本時間の真夜中に大きな荷物を抱えて全力疾走というのはかなりこたえました。ひとりなら絶対に走らないのですが、花木さんが走るので、仕方なく走りました。

良かった点は窓際だったので、きれいな虹が見えたことです。霧のような雲が点在する空模様で、乗っている飛行機の影が雲に映ります。時折その周りを丸く囲んで虹が見えることがありました。長く見ていると、太陽の位置、飛行機と雲との距離、雲の厚さなどから、次にどの雲に虹が見えるかが分るようになります。予想が当たると単純に嬉しかったりもします。

オースチンの印象です。着く前は、テキサスの砂漠で、映画のようにブーツを履いた大きな人が街を歩いていると予想していたのですが、全く違いました。カリフォルニアの街と言われても気が付かないかもしれません。普通に雨が降ったりもします。これだとテキサスに来たという特別なことが無くなってしまいます。そこで写真を載せることにしました。本日の朝食ワッフルです。

 

最後になってしまいましたが、31日（木）にはSun Software Showcase が行われます。是非おいで下さい。

 

 

 

今回はIdentity Managerを使った「名寄せ」処理の実際を説明します。Identity ManagerはSunが一般企業向けに販売しているアイデンティティ管理のためのソフトウェア・パッケージです。

一般企業のアイデンティティ管理においては、個々の記録の持ち主を特定する「名寄せ」処理に付随して、その人に正しい権限を付与する処理も併せて行われます。例えば、ある職位以上の人が決裁権を持つという規則がある場合には、各自の職位属性に従って権限の付与と剥奪が「名寄せ」処理と同時に行われます。そのため、Identity Managerではこれらの処理を行う機能のことを「調整」機能と呼んでいます。各種システムの保存された個人に関するデータを照合することにより、本人を特定し、それに基づき適切な権限を付与するのが、企業向けのアイデンティティ管理製品の特徴です。「名寄せ」はその機能の一部として存在しています。

Identity Managerでは「相関規則」と「確認規則」を使って様々なシステムに散在する記録の持ち主の特定を行います。「相関規則」には、多くのシステムで管理されている、姓、名などの属性に基づき、個人を特定するための条件を記述します。企業では、この他にEMAILや従業員番号が良く使用されます。年金記録の場合は、氏名、性別および生年月日を使用しているそうです。「相関規則」を定める際に最も重要な点は、信頼できるデータを利用することです。企業の場合には、人事部で管理しているデータベースや、給与計算用のデータベースから直接データを取得できれば理想的ですが、情報の機密性から難しい場合もあります。

Identity Managerを使って「相関規則」をシステムに適用すると記録の持ち主が判ります。と、言えれば簡単ですが、実際には設定した規則が厳しすぎる場合には、持ち主がひとりも見つからない場合や、逆に緩過ぎる場合には、複数の候補（または、それらの候補が満たしている条件）が返されます。以下にそれぞれの場合について説明します。

１）ただひとりの持ち主が見つかった場合

 人事担当者などに確認をとった上で、記録と本人との結びつけを行います。企業システムでは、通常は、個人に連絡をして確認するということまでは行いません。

年金記録の場合には、本人宛に「ねんきん得別便」という確認の通知を行うそうです。これは、最終的には全国民に送られますが、初めは結び付くかもしれない記録がある人を優先するとのことです。この際、結びつく可能性がある記録を明示的に示すのではなく、確認を促すことのみを行います。実際の記録の追加や修正は本人が申し出る必要があるそうです。この点は企業のシステムとは大きく異なります。

２）持ち主の候補が複数見つかった場合

「確認規則」を利用します。「確認規則」には、複数の候補者の中から持ち主を特定するために、「相関規則」よるも細かな条件を指定します。企業のシステムでは、上司等の組織に関する情報や入社日などが良く使われます。「確認規則」を分けずに「相関規則」の一部にしてしまうことも可能ですが、これらを分離することにより、それぞれの条件を細かに変更して候補者を絞り込むことが容易になります。また、多くの場合、「確認規則」には「相関規則」に含めると処理に時間がかかり過ぎる条件を含めます。

年金の場合には払い込み期間を「確認規則」として利用することが出来るかもしれません。 確認対象の記録に対応する期間に年金を納めていたという他の記録がある人は、候補者から除いても良いと思われます。

３）持ち主の候補が全く見つからなかった場合

より緩い条件を「確認規則」に設定します。使用したデータ自体に誤りがある可能性があるからです。氏名が一文字を除いて一致し、その他の条件が完全に一致する等の条件が考えられます。どの条件を緩めるのが良いかは、どの様なデータの誤りが多いかに依存するため、試行錯誤が必要になります。緩めすぎれば、多数の候補者が抽出されるため、「確認規則」での絞り込みが難しくなります。

実際には、上記の作業を「相関規則」と「確認規則」に設定する条件を細かに変更しつつ繰り返し行うことになります。それにより、持ち主を特定できる記録を徐々に増やして行くことが可能です。

「Sun Java System Identity Manager 7.0 の配備に関する技術概要」の第３章ではActive　Directory,　SecurIDおよびSolarisに保存されたアカウントを結びつける方法について説明しています。こちらも参考にして下さい。

 

年金問題が毎日のようにニュースで取り上げられています。

人は誰でも年を取ります。そのため、年金問題に無関心でいられる人は少ないでしょう。私も国民のひとりとして、「もう少ししっかりやって欲しい」と心から願っています。また最近報道されることの多い「宙に浮いた」年金記録問題は、私が専門としているアイデンティティ管理（以降ID管理）の「名寄せ」と呼ばれる処理に深く関わっています。ひとりの技術者として「名寄せ」が、実際にはどのようなことを行う処理であるかを以下に説明します。それにより、問題を理解する手がかりを提供できれば、と思ったからです。

とは言っても、私自身は年金の業務に関わったことはありません。また、報道されている以上の情報も持ってはいません。しかし、「名寄せ」処理は、年金以外でも一般企業にID管理システムを導入するに際に必ず必要となるものです。実際の処理は企業毎に細かな点での相違はありますが、手順は基本的には同じです。年金は、その規模、運用してきた期間および関連するシステムの数から考えて、非常に複雑なその応用問題であると言えます。しかし基本を理解することにより、たとえ応用問題までは解けないとしても、「どこが難しいのか」を理解することは出来るようになるはずです。

言うまでもないことですが、実際にシステムを構築された方々を批判することは目的としていません。現在の技術に基づいて過去の技術を批判することはフェアではないからです。現在では、「名寄せ」処理は、パッケージ・ソフトウェアを使って簡単に行えるようになっていますが、それが過去から様々な「負の」遺産を引き継いでいる年金システムにそのまま適用できると考えるとしたら楽天的過ぎると批判されても仕方ありません。

まずは、「名寄せ」がなぜ重要であるかを説明します。当たり前のようですが、報道を見聞きする限り、十分に理解されているようには感じられないからです。「宙に浮いた」年金の前には、「消えた」年金が問題になりました。「消えた」年金問題は、納めたはずの年金の記録が無いという問題です。一方、「宙に浮いた」年金問題は、多量の年金記録が誰のものであるか、持ち主が分からなくなっているという問題です。これらは、同一の現象を異なる立場から見たものに過ぎません。国民の視点からは「消えた」ように見える記録も、実際には、その多くは存在しているはずです。ただ、持ち主が分からなくなっている記録が数多くあり、それが年金を納めた国民の側からは「消えた」ように見え、社会保険庁などの年金を管理する側には、「宙に浮いた」ように見えるだけです。そのため、これらの「宙に浮いた」年金記録の持ち主をはっきりさせる（これが「名寄せ」という処理です）ことにより、「消えた」年金の問題も、ほぼ解決することができます。「ほぼ解決」とまでしか言えないのは、本当に記録が残っていない可能性も考えられるからです。受け取ったにも関わらず記録しなかった場合や、記録を捨ててしまった場合です。しかし、それらは、ここで目的としている技術的な説明の範囲を超えています。また、ひとりの国民の立場からも、そのようなことが数多くあるとは信じたくありません。そのため「ほぼ」という言葉を用いています。

「消えた」年金と「宙に浮いた」年金は、同一現象を異なる立場から見たものであることを説明しましたが、現在では、それぞれの見方により、異なる対策が採られています。まず、「宙に浮いた」年金では、それぞれの記録を本来の持ち主に結びつける、「名寄せ」という処理が採られています。一方、「消えた」年金では、国民からの申し立てに基づき、「消えた」記録の回復を行う作業が進められています。しかし、この方法では、認定基準が「申し立て内容が明らかに不合理ではなく、一応確からしい」のような曖昧なものにならざるを得ず、最終的には「人柄や態度見て総合的に」判断することになってしまいます。これでは、迅速で正確な処理は到底期待できません。また、すべての人が申し立てを行うとは限らないため、網羅性にも問題があります。正しくは、まず、「名寄せ」を徹底的に行い、その結果を国民に知らせた後に、不審な点について国民からの申し立てを受け付けるという手順を踏むべきだと考えます。今のように、両方の作業を同時に進めるという方法では、時間とお金が費やされる割に成果が上がらないことが容易に予測できます。

次に実際の「名寄せ」処理について説明します。まず、それを行う時期についてです。企業にID管理システムを導入する場合には、通常は、構築が終わり、サービスを開始する直前に「名寄せ」が行われます。サービス開始直前は、他にも様々な作業があり、大変な時期ですが、不整合なデータを残したままID管理システムを稼動させても意味がありません。多量の監査エラーが出力されるだけのシステムになってしまいます。残念ながら、「名寄せ」を行って初めて様々なデータの不整合が明らかになることもしばしばです。これらはサービス開始を遅延させる要因となり、様々な方向から早く「名寄せ」の作業を終わらせるように圧力がかかってきます。そこを耐えて、データ整合性がとれた状態でシステムを稼動させるのが将来に禍根を残さない唯一の方法です。

 ここまでが前半です、後半では、弊社が販売しているIdentity Managerというパッケージ・ソフトウェアの機能を紹介するという方法で、「名寄せ」処理の実際を理解して頂く予定です。「名寄せ」はID管理の分野において、基本的な処理であるため、他社製品も同様な機能を持っています。ここで自社製品を例にあげるのは、製品を多くの方々に知って頂きたいという意図もありますが、それだけではなく、「名寄せ」は、現在では一般企業向けに販売されているID管理のソフトウェアに組み込まれている基本的な機能であることを理解して頂きたいからです。

 

今日は私の住んでいる町の廃品回収の日でした。

廃品に限らず、日常出るゴミも、決められた時間帯に、決められた場所にきちんと出すのは、市民としての当然の義務です。そして、それは我が家では私の仕事です。毎朝、その日のゴミを確認して、家の前の所定の場所に置くことを正確に行う必要があります。最近は慣れてきたので、普通にできるようになりましたが、最初のうちは失敗もありました。

朝、カバンとゴミ袋を持って家を出るのですが、家を出たとたん会社のことを考え始めるためか、ゴミのことを忘れ勝ちです。駅の近くまで、ゴミ袋を運んでしまったこともありました。そのときは生ゴミでしたので、それをもって混んだ通勤列車に乗るわけにもいかず、家まで戻りました。目立つ色（オレンジ！）をした生ゴミの袋を持って朝の人の流れに逆らって歩くのは恥ずかしかったです。

それと言うのも、ゴミ回収車に 持っていって貰うためには、私が持っていてはダメで、所定の場所に置いて初めて正式にゴミとして認められるからです。これはJavaのGC(Garbage Collection)の仕組みと同じです。いらなくなったオブジェクトでも、それを持っている人がいる限りはゴミ回収の対象とはなりません。Javaのオブジェクトは、それへの参照が無くなって始めてGCの対象として認められます。

いらなくなったオブジェクトがそれへの参照があるために、GCの対象にならず、ヒープ・メモリ上に残ってしまうことをメモリー・リークと呼びます。これは、性能劣化の原因になるだけでなく、最悪の場合は、メモリ不足により、アプリケーションが動作不能になります。通勤列車に生ゴミを持って乗るようなものです。

長くなってしまいましたが、ここまでが前置きです。本日はSun　Tech　Days　２００７の話をするのでした。11/6-8 に開催されましたSun Tech Daysですが、盛況のうちに終了することが出来ました。ありがとうございました。資料はここからダウンロードすることが出来ます。

ここでは、ハンズオン・ラボのひとつとして行われた"Finding Memory Leaks Using the NetBeans Profiler" (NetBeans 6.0のプロファイラーを使ったメモリ・リークの検出方法）を振り返ります。手前味噌になってしまいますが、特に、Excercise 2. のNetBeansプロファイラーを使って"HttpUnit"のメモリーリークを特定する演習は出色の出来だと思います。

まず、この演習が事実に基づいていることが挙げられます。これは、スペインのAndrés Gonzálezという方がNetBeanプロファイラを使ってHttpUnitのメモリーリークを特定した事実に基づいています。実際にどう見つけたかはここから参照可能です（スペイン語ですが。。。。）。デバッガや、プロファイラ等のツールを使って問題を特定するという演習では、予めわざとらしいバグを仕込んでおいて、それを見つけさせるというものに成り勝ちです。この演習にはそのわざとらしさがありません。

さらに良い点は、問題のメモリーリークはNetBeansのプロファイラ無しでは特定困難であったことです。プロファイラの機能を十分に活用することにより、問題が解決出来ました。一般に、少量で、不定期的に起こるリークは特定が困難です。逆に定期的に大きくリークするのであれば、プロファイラ等のツール無しでも問題の特定は容易です。この演習では、エラー処理の部分で少しだけリークするためツール無しでは特定が困難なものであると言えます。

是非この演習をやってみてください。Exercise 2.だけでも十分な価値があります。正直に言うと、他の演習のなかにはわざとらしいものもあります。ソースコードや手順を含む全ての資料はここからダウンロード可能です。

最後に少しだけ、お詫びと修正です。お勧めしているExercise 2.ですが、添付のコードに少し問題があります。正確に言うと、問題がないことが問題です。メモリー・リークを修正した方のファイルを入れてしまいました。お手数ですが、ダウンロードしたZIPファイルを展開して、JavaScript.javaというファイルの２０４行目のコメントを外して下さい。

本能的に、修正を入れた方のファイルをアップロードしてしまったことが原因です。

 

私の所属する部署は、この数週間、てんてこ舞いの状態です。先週は、朝、出社すると机に突っ伏している人が見受けられました。動かないので、気にはなりましたが、時間がたつと、のろのろ動き出したので心配はなかったようです。

というのも、明日から始まるSun Tech Daysの準備のためです。最新の技術や製品を紹介する資料やデモを時間をかけて準備しました。だから、必ず来て下さい。

こう書くと、如何にも私が努力したように聞こえますが、実は何もしていないのです。しかし、当日は頑張るつもりです。「アイデンティティ管理ソリューション」の出展ブースとハンズオン・ラボにいます。「NetBeansのプロファイラを使ってメモリーリークを見つける」セッションと、「JavaFX」のセッションでは、会場を回ってラボのお手伝いをしています。

是非、来て下さい。

本日はMenlo Parkのオフィスで指静脈認証を使ったAccess Managerのデモを行いました。指静脈認証を見るのは初めてだという人ばかりで、指紋を使った認証とはどこが異なるのかから話を始めました。みなさん興味を持ったようで、質問が多く冷や汗でした。

最後にデモをしたのですが、 それが上手く動きませんでした。今朝、確認したときは何の問題も無く動作していたのに。。。せっかく日本から大事に持ってきたのに残念でなりません。

「こういうことはライブのデモでは良くあるんだよね。」とフォローしてくれた人がいたのはありがたかったです。

とほほ。

 

今週はAmbassador Conferenceに参加するためにMenlo Parkに来ています。

Ambassadorという名前のとおり色々な国の参加者がいます。内容は、新たにに開発された技術や製品の詳細説明です。とても面白いものがあるのですが、ここで紹介出来ないのが残念です。製品発表を待って下さい。
Access Managerの時期バージョンの説明にアーキテクトのPat Pattersonが来ました。そこで認証方式のひとつとして指静脈認証があることを紹介してくれました。他国の人も興味を持ってくれたようです。
開発したものはオープンソースとして公開して誰でも利用可能にする予定です。期待していてください。

 

私の所属する部署は近頃おめでた続きです。先日も私の同僚に赤ちゃんが誕生しました。

おめでとう！今は出張中で直接言えないのが残念です。



それもあって、最近は名前の付け方が部署内でしばしば話題になります。画数はどうだとか、いじめられやすいのではとか、呼びやすいかとか、実に様々なことが考慮の対象になります。はたから見ていても、これから親になる人の期待と不安が感じられ、微笑ましい限りです。

親が子どもに名前を付けるのとはレベルが異なりますが、プログラマにとってもプログラム中の変数や関数にどういう名前を付けるかは、身に付けなければならない大切な技能のひとつです。分かりにくい名前を付ければ、次にそれを読む人が理解し難くなるため、プログラムの保守性が下がります。プログラムの一生を左右すると言えば言い過ぎかもしれませんが。

最近、これに関連して面白いことがありました。あるプログラムは"pumpkin_hour"という変数を使っています。これは、特定の機能が動作しなくなる時間を制御するための変数なのですが、もちろん、シンデレラのかぼちゃの馬車からの連想です。私がこれを最初に見たのは、もう１０年近く前のことになります。とても印象が深かったせいか、最近またお目にかかったときに、すぐに内容を思い出しました。

このような名前の付け方が正しいか否かには議論の余地があるとは思います。全ての変数にこのような素敵な名前が付けられるはずはありません。しかし、私はこのような名前が所々に入ったプログラムを読むのが好きです。

Sunでは製品の開発、テスト、サポートの担当者は世界各地に分散して配置されています。近頃は日本の企業でも日本だけで閉じて仕事をすることは少なくなったと思いますが、Sunの場合は、それが極端です。

先日、ある問題のため製品に早急に改修を施さなければならなくなったことがありました。日本で調査をすると、問題は製品とそれが使用する部品とのインターフェイス部分に起因しているらしいということが分かりました。そこで英国にいる部品の担当者に連絡をとり、仕様を確認し、それを米国にいる製品担当者に伝え製品に改修を加えて貰い、香港にいるテスト担当者に渡しテストをして貰い、それを日本で受取り、最終チェックをした後に提供するという手順を踏みました。これは上手く行きました。偶然ですが、地球の自転と同じ方向に担当者が配置されていたのが作業が捗った理由のひとつです。

このような方法は世界各地にいる専門家の知識を結集できるという利点がある反面、コミュニケーションをとるのが難しいという欠点もあります。例えば、上記の担当者の配置が逆であった場合を考えて見ます。それだけで、数日をロスしてしまう可能性があります。通常のemailによるコミュニケーションが上手くいかない場合には 電話会議を開くのですが、これも日本側にとっては辛い仕事です。各担当者にお願いして出来る限り早く作業を進めて貰わなければならない立場なので、スケジュールに関しては相手にあわせることになります。

先日こんなことがありました。3時に電話会議を設定したので出席するようにとの連絡を受け待っていましたが、誰も参加してきません。確認したところ朝の3時だということが分かりました。

これが真夜中の集いです。

 

昨日でCECは終わったので今日は移動日です。来週行われる製品の企画、開発担当者とのミーティングのためサンフランシスコに移動しました。

CECの良い点は昔からの友人に会えることです。今回はニュージーランド、オーストラリア、香港、アメリカの友人に会うことが出来ました。同じ会社で同じような仕事をしていても働く国が異なれば会う機会は殆どありません。こうした機会は貴重です。

ＣＥＣ（カスタマー・エンジニアリング・カンファレンス）というフィールドエンジニア向けのカンファレンスに参加するため、ラスベガスに来ています。新しい技術や事例を知ることが出来る良い機会です。同様な要件に対して他国のエンジニアがどのようなアーキテクチャを採用したかを知ることはとても役に立ちます。 昨日は"A biometric authentication integrated with JES in a systemic security architecture"というセッションに参加しました。私が担当している指静脈認証をAccess Managerの認証方式として組み込むことに関連していますが、この事例では指紋を使っています。 このシステムが我々が採用した方式と大きく異なるのは 、生体認証情報を集中管理していない点です。生体認証情報は個人が所有するデバイスに収められていて認証に必要な演算もそこで行われます。生体認証情報が外部に出るということはありません。 この方式を採用した理由として、このセッションのスピーカーは、生体認証情報が集中管理された場合、外部に漏れるリスクが高くなることを挙げていました。しかし、この点は納得できませんでした。個々のリスクに対しては現在の技術で対応可能なはずです。どちらかと言えば、生体認証に対する国民感情の差異に起因しているように私は感じました。この事例はイタリアの事例です。 生体認証の導入にあたっては、それぞれの国の事情に合わせた実装が必要であることを印象付けられたセッションでした。