OpenIDは何故普及しないのか

　インターネット上に各種webサービスが増殖している。また企業内のシステムもweb化されシステムが複数存在するようになって来た。筆者の勤務先でも、ぱっと思いつくだけで3種類社内にある。これに加えて業務上必要な取引先のwebシステム等を加えると10種類位はあるだろう。

　この様にシステムが複数存在するとIDとパスワードの数がその分だけ増加する。このIDとパスワードを一括で管理出来るのがOpenIDだ。OpenIDは、1種類のサービスで使用するIDとパスワードとを他のシステムで使用可能にしてくれるため、ユーザはIDとパスワードとを複数管理する必要がなくなる。

　1組のIDとパスワードとを使い回そうとしても上手くいかない。これはシステム毎にID、パスワードで使用出来る文字が異なる、文字数の制限がある、またパスワードの変更期限が異なる、という事情による。

　しかし、OpenIDは盛んに宣伝されている割には普及していない。これは何故か。

　筆者が思うに、OpenIDの発行元が他のシステムで発行されたOpenIDを受け入れるシステムになっていないからと思う。例えば、mixiではOpenIDを発行している。対応する他システムでmixiのIDとパスワードとを入力する事で他システムの認証を済ませる事が出来る。ところが、他システムで発行された（例えばYahoo!で発行された）OpenIDでmixiは認証出来ない。これではYahoo!、mixiで別々のIDとパスワードとを管理しなくてはならない。

　OpenIDの発行は自社サービスの宣伝になる。他システムでの認証時に、自社サービスのログイン画面に遷移するので、ユーザの記憶順位の上昇には良い影響を与えるだろう。

　しかし、相対的に知名度のあるwebサービス提供者は、認証時に他社システムを経由する事が他社を有すると考えているのか、OpenIDでの認証を提供していない。実際OpenIDで認証が出来るのは相対的にユーザ数が少ないwebサービスである。

　この様にOpenID発行元が考えているのであればOpenIDは普及しないだろう。銀行ATM網が積極的に他社カードとの乗り入れを強化しているのに対して、けち臭い印象を持ってしまう。

Read More

Amazon Market Placeの送料一覧

　今でこそ緩いオーディオファンの筆者であるが、長岡鉄男の推奨レコードは結構探した。1990年頃はレコード盤を手放す人が結構居て、珍しい盤も若干だが持っている。

　しかしながらレコード盤だと聴くのに手間だし、音質よりも音楽に筆者の主眼が移った事もありCDで同一の盤が買えるならCDへ移行したいと思っている。

　そこでAmazon。日本、英国、米国の3箇所を見れば大抵の物は見つかる。面白いのはAmazon自体が販売しているCDでも各国で微妙に差異がある事。探すのはヨーロッパ盤だが、英国で売られていて、日本では売られていない、という事もある。またMarket Place、平たく言えばAmazon出店のレコード屋からも購入出来るのだが、上記の3カ国全てに出品している店、一部だけ出品している店という差異もあるので、商品選択は結構大変だ。

　で。ここから筆者のメモとして配送料金一覧。日本への配送を想定。

日本（Amazon）

　1500円以上で送料無料。1500円以下300円。

日本（Market Place）

　1個340円

英国（Amazon）

　配送1回2.09pond。これに加えて商品1個1.49pond

英国（Market Place）

　1個3.58pond

米国（Amazon）

　配送1回$4.99。これに加えて商品1個$3.99

米国（Market Place）

　1個$6.89

　これを見ると、一番物流が充実していそうな米国-日本の送料が、英国-日本より高いのが面白い。米ドルが下落してもお得感が少ない。

Read More

昔取った杵柄

　2000年頃まで某web siteの更新をしていた。当時は牧歌的な時代でweb siteの中身は静的に生成するのが主流であり、SSIやCGIを使った動的なページ生成は上級者向けであった。筆者はSSIを使っていた。これはページの更新日付をサーバから拾ってきてコンテンツ中に表示させる仕組だった。

　当時のweb site構築では、文章や画像と言ったコンテンツと、ページレイアウトが同一のHTMLに共存しており、一部のレイアウト修正をすると全HTML書き直しという事態に陥るという問題があった。

　現在はページの表示一つ変更するのもスタイルシートで一気に変更出来るし、wikiを始めとするコンテンツ・マネージメント・システムも普及しているので、ページのレイアウト作成と、コンテンツとが完全に分離出来る。これは素晴らしい事だ。

　このbloggerはレイアウトをxmlの形式で流し込める。当時のPage Spinnerでtag手打ちしていた時代と比較すると天国だが、ちょっとした修正でcssなりHTMLの知識が必要になる時がある。このblogの最上部にblog検索のバー（Navbar）があるが、最初これが表示されなかった。何故かと言うと、このレイアウト（借り物である）ではデザインを重視してNavbarを非表示に設定していたのだ。これを表示させるのはxmlをちょっと弄れば良いのだが、cssやxmlの概念を知らないと厳しいだろう。矢張りHTMLやcssを一度は触った方が何かと良い様だ。

Read More

mixiからbloggerへ

　web日記はhyper nikki systemで開始した。このシステムは現在のblogの走りとも言えるが、ダイアルアップ方式の様に日記記述者のIPアドレスが変化する環境では、使いづらかった。これはruriというcookieで記述者の環境を判定、書込権限を与えるためである。

　その後mixiに移ったのだが、閉じた環境には馴染めない。有料会員では自分の日記の検索機能がある様だが、そのために費用負担と言うのも何だかなあと思う。

　で、色々見ていたのだが、tDiary辺りのような日記システムが良いなと思っていたが、google様のBloggerを使った所、昔のhyper nikki systemをも思い出させるインタフェースが備わっていたので、採用した次第。

　右側にAmazonのアフェリエイトを入れてみた。これで大儲け、と甘い考えがある訳では無く、昔からやってみたかったレコード屋の真似事である。ここのアフェリエイトで表示されるCDは故長岡鉄男の推奨盤である。その中で筆者の手持ちや買いたいと思っている物が表示されるので、この手の音楽がお好きな方はどうぞ。

Read More

九十九電機のABL続き

　先日、九十九電機の在庫品を担保にしたABLに違和感を感じる旨記載した。

　ゆっくり考えると、やはりこのスキームはおかしい。

　そもそもABLは借り主が作り出した有形無形の換金が難しい資産、ここには借り主が生み出した付加価値を含む、を担保に借金をするという事だ。つまり、工場の在庫を担保にするのは、工場で原料を加工し付加価値を付けた状態になった事に対して金を貸しているのであろう。工場の原料を担保に、というABLはありえない。

　こう考えると、九十九電機が商品を仕入れただけの状態である店頭在庫は、工場における原料と同じであり、この状態で担保価値というのは無い。正確に言えば価値はあるのだが、この価値はメーカへの代金支払と相殺されるので、差引0という事だ。

　無論、筆者は「小売店のやっている事には付加価値はない。製造業マンセー」と主張しているのではない。小売店の付加価値とは店頭での販売員の対応能力であったり価値を伝える提案力である。しかしこれは究極の無形資産であり、のれん代や商標と言った無形資産より担保査定が難しいだろう。NECリースも苦し紛れに在庫品を担保にしたのかと推測するが、練りが足りないと思う。

　

Read More

九十九電機のABL

　九十九電機が急遽営業を取りやめた。在庫品を担保にABL（Asset Base Lending)による融資を受けており、契約上、民事再生提出後、在庫は販売に回してはいけない。しかし九十九電機は販売を続けており裁判所の保全の仮処分が出た模様。

　契約上はNECリースに理がある。

　それにしても小売業のABLは信用取引二階建相当だと思う。一階部分はメーカから商品を仕入検収した時。検収時に所有権は移転するから、まず仕入分の債務を負う。二階部分は自分の物になった商品を担保にさらにABLで借金をして債務を負う。

　ABLの本来の担保は工場などの「生産はしたけど、未だ販売先から回収出来ていない債権」で、本件の様にメーカから受け入れた商品を直ぐに担保に入れて金を借りるというのはちょっとずれている気がする。

　不動産等の担保に対して抵当順位という概念はあるが、ABLだとどうなのだろうか。メーカと九十九電機との売買契約も、大概「民事再生等を申し立てた場合は売買契約は無効（=商品の所有権は移転しない）」と書いてしておくが、ABLの契約でも同様にしていた様である。

Read More

官公庁入札の実態

　長崎県のIT調達方針の様に、発注元自らが仕様書を作成し入札を行っている官公庁は、非常にまれで羨ましい。大概の自治体、外郭団体はCIOやCIO補佐官という肩書きの人は居るものの、機能しておらず従来の丸投げ発注から大して変わっていない。

　近年一番困ったのが、「現行システムのアプリケーションをマイグレーション」という調達が、蓋を開けてみたら「ソースコードは開発元が持っていて、発注者は持っていません」「ソースコードは落札者が責任を持って、開発元から入手する事。その費用は開発者持ちね」という素晴らしい事態に変化。

　この条件を仕様書に書かないで、仕様書を配った後の質問事項回答として出してくるのはどういう事だ。前提条件の若干の変更なら判るが、これでは開発元以外は参加出来ないぞ。

　発注元はリスクが負えない、という事は判る。しかし、自分たちの不勉強や仕事の怠慢（敢えて言う！）を恥じる事なく、一律落札者へリスク負担させるというのは、公平な調達の妨げである。

Read More