言語の歴史 3 モジュール指向

言語の中*で* プログラムすることと、言語の中*へ*プログラムすることは、大きく異なる。(Gries 1981)
別に稿を書き起こす予定だが、ひとつの言語しか知らないと、その言語の仕様に限定された発想、思考しかできない。いくつかの言語を知っていれば、問題を解決するための最適な処理系の選択ができる。これは堅牢なアーキテクチャの確立のひとつの要素だ。

と、ぶち上げて、モジュール指向の言語の話だが、これ日本で全然、流行らなかった。好きな人の間で、「いいよねえ」「よさげだよねえ」と言ってたんだが、ビジネスベースでは、ほとんど使われてない。それだけ、cのインパクトでかかった。

モジュール=名前空間　として、抽象化されたデータ型を作る。

Ada やっぱりアメリカ国防省がからむ。データ抽象化と情報の隠蔽、パブリック、プライベートの考えなどをもつ。ちなみに、Adaさんという人は数学者で、世界で最初のプログラマと言われる。コンストラクションが難しい時、祈るといいことがあるかもしれない。

Mudula2 ごめんなさい、ほとんど知りません。ライフボード社で扱っていて、処理系売ってたんだけど・・・お小遣いじゃ買えませんでした。

撤退すべき時

もう時効なので。

付き合いの長い会社なんだけど、いかんせん組織が巨大で、セクションた担当によって、「アタリ」が異なり、トラブルこともある。

現場に来てやって欲しいという業務で、一人行ってもらった。
長期続くはなしだが、まずは契約１ヶ月でやって欲しい、と。

営業・収支上のPMはいるが、技術面のPMの働きまで、踏み込んでほしいとの希望で、たしかに、マッチしないと、プロジェクト自体が頓挫する重要なポジション。
慎重になるお客さんの気持ちもわかるし、行ってもらう本人にも納得してもらい、現場に入った。

１ヶ月が過ぎる、少し前。次も、1ヶ月で契約してくれ。
ゴタゴタするのもイヤなので、呑む。

そして、次、また１ヶ月と言い出した。
今まで、そんな話はしたことのないお客さんだったのだが、担当が不慣れだった。ダメならダメでいい、ミスマッチなら、早めに結論出して、次を考えるのが、お互いのためだろうに。
行っている本人がキレ、契約、更新やめましょう。と言い出した。
ごもっとも。オレも、この進め方おかしいと思う。フェアじゃない。

さて、それを言い出すと、
「いや、そんなことないんだ、残ってくれないと、困る」

だが、ここは、やはり引き上げるのが妥当と判断。
この行き違いそのものに、近い将来の問題の種を内包しているように思えた。
その会社全体とのツキアイはまだ続いているが、このセクション？この担当者は、ダメかも・・。

引継ぎやらなんやらで、けして、波風たてることは本意ではなかったし、いたずらにプロジェクトを困らせたいとも思わない。交代がくるまで、その後、２ヶ月は、やった。

バランスが、時に悩ましい。

言語の歴史 2 手続き型 構造化

オブジェクト思考の背景として歴史を知ることの他にも、コンストラクションの重要な決断をするためには、言語の種類、特色は理解しておくべき。どうしてこのシステム構築にあたって、PHP5を選択しているのだろう。いつまで、半人前のＰＧでいいなら知らなくても、考えなくてもいいけど。

COBOL アメリカ国防省向けに作られた。今でも大量に資産がある。
手続き型から進歩も続けていて、構造化COBOLや、最近では、オブジェクト指向の機能を持つCOBOLまである。不勉強で、オブジェクト指向COBOLの詳細は知らない。

Fortan 手続き型でスタートだが、Fortran77では、ブロック構造のIfが追加され、構造化への歩みもしている。

C 低水準に移植性の高いアセンブラとしても使えるし、構造化された制御、マシンからの独立（一応は）など、高級言語としての機能も。1980-1990年代、オープン系開発では、事実上の標準ともいえる。

手続き・構造化は、ずいぶん、がんばってイロイロなことを試みる人たちがいた。
同じようなところを、まとめて、サブルーチンとして使いましょうよ。
アセンブラまでは職人だけだったが、この頃から、プログラムが大衆化して、それこそ、ぐちゃぐちゃになって、コードの書き方何とかしましょうや。で構造化。

ちゃんとやれば、それなりに理解しやすいプログラムになる。でも、再利用できるのはあくまでも、コードのレベル。それ以前の、分析・設計の再利用性は、ない。勿論、コードと業務のつながりは直接的にはなく、ドキュメントのみが頼りになる・・が、このドキュメントが十分であることは・・マレだ。

言語の歴史 1 機械に優しい

オブジェクト指向の必然性を理解する上で、言語や処理系の歴史を、背景として知っておくことは有効だ。

まず、機械語やアセンブラの時代。
当時は、マシンもメモリも高かった。人が、機械様にスリスリしていく必要があった。人間はコンピュータの気持ちになって、0と1の羅列をする。（16進でもいいけど）
アセンブラのニーモニック。ちょっとだけ人にとって意味を持った。でも ADD はマシン語の010011だよね、とマッピング、紐付けしただけ。

長所は、マシンと環境と地球に優しい。エコだったんだな。早いし。
少しでも便利にしようと、歩み寄りもあって、マクロアセンブラとかも出たな。でも本質的には、普通の人には焼け石に水。もう職人芸の世界。
どうしても実行速度を負う、コードサイズを小さくする必要性があれば、今でも使われる。

そして欠点は、勿論、ふつ～の人は見てもわかんねえ。

化け物はいるもんで、16進をみてニーモニックに直せる人間逆アセンブラーとかいたなあ。尊敬されてた。でも俺はできません。

ソフトウエアクライシス対応 5 I/F重視

システムデザイン、アーキテクチャを確立する時、I/Fを重視した設計を進める。コンポーネントに分けることで、並行開発ができる。場合によってはアウトソーシングもできる。
疎結合であれば、依存度も低く、問題の切り分けがしやすい。

この発想がないと、web2.0的な外部システムのサービスを取り入れたシステムデザインは難しい。一応つながってはいるけどね、キレイじゃないよね。って、システムデザインになる。あとで誰かが苦労する。

オブジェクト指向は、現在のソフトウエアクライシスに対応する中心的な要素になり得る。が、オブジェクト指向でやれば、すべてうまくいくというような、魔法の薬ではない。
この問題を考えていくと、ソフト会社って何？ソフトウエア開発って何？　さらには、ソフトウエアエンジニアリングそのものの議論になっていく。
そのあたりは、きっとアジャイルのメンバーのお歴々が、やっていかれると思うので、お任せしておきたい。

オブジェクト指向の背景として、現代のソフトウエアクライシスに、文字を費やしたが、次は、オブジェクト指向の背景の２つ目として、言語、処理系の歴史を押さえておく。

ソフトウエアクライシス対応 4 フレームワーク

JavaでもPHP5 でも、いいフレームワークが揃ってきている。c++の時代とはずいぶん違う。
使用実績のあるフレームワークを会社に作っておく。蓄積していく。繰り替えし利用することで、毎回テストされ信頼性があがる。
昔でいえば、サブルーチン、プロシージャ、関数の共通化だったが、いわば局所的なパーツの蓄積。その意味では、ずいぶん進歩はしている。

オブジェクト指向の再利用性は、コードにとどまらず、分析、設計にまで及ぶ。経験も必要だが。

新技術は毎日のように出ていて、クライアントは新しいものが魅力的に見える。だか最新ということは、実運用を踏まえた安定性に欠けるということ。バグがあるに違いない。
だが、取り入れなければ、ジリ貧だ。そのリスクを回避しながら、開発することになるが、やはりインクリメンタル開発となる。とにかく、細くてもいいから、ガイドロープを向こう岸にかける。一番最初に、アーキテクチャーのプロト、サンプルコードを書く。
妥当性の検証はしっかりと。
これで、新しいものを取り入れたフレームワークが作れる。

ソフトウエアクライシス対応 3 アーキテクチャー

サービスインまでの仕様変更。そして勿論、サービスインして運用がはじまってからの機能追加。当然、あるべきものと考えておく。
システムは生きていれば成長する。成長の止まっているシステムは、使われない死んだシステムだ。言い過ぎかもしれないが、１００歩譲っても、世の中やビジネスが変わるのだから、それにあわせていかないシステムやサービスは、いずれ死ぬ。

おたおたするな、ガタガタするな。仕様変更や追加はある。そう割り切っておこう。費用などの点は営業的な話なので、今回は省略するが、問題は、それに耐えられるベースのアーキテクチャか否かだ。

オタオタしないための仕込み。それが安定したアーキテクチャだ。レガシーでいえば「方式設計」だが、オブジュクト思考でやるときには、インフラやベースラインのアーキテクチャ。機能を実現するレイヤ、ビジュアル（プレゼン）を担当するレイヤ。それぞれ独立してメンテできるようにしておく。MVCのフレームワークはいくつもある。その採用もいいだろう。

アーキテクチャがしっかりしていても、オタオタしないためには、条件がある。開発者が信頼に足り、物事の決定の場に立ち会えること。コミュニケーションが十分にとれていること。などなど、オブジェクト指向以外の要素があるが、XP(Extreme programming)について書くときにあらためて。

アーキテクチャの確立については、別途書き起こすが、ここでハッキリ書いておきたいのは、サービスイン前にクライアントからアーキテクチャの変更まで求められるような要望が出た場合、PM,PLは断固とした姿勢で挑むべき。なぜなら、それはプロジェクトのゴールが変更されたと同等のことで、このまま進めても、クライアントは満足するわけがない。もっとハッキリ言えば、必ず失敗する。ならば、プロジェクトの中止、仕切りなおしをするのが、誠意だと考えたい。

アジャイル宣言
契約交渉よりも、ユーザとの協調により価値をおく
計画に従うよりも変化に対応することにより価値をおく

ソフトウエアクライシス対応 2 見積もり

これをちゃんとやらないと、ソフト会社なんてすぐに潰れる。当たり前のことだが。いろいろな方法もあるから、一例を挙げるに留める。

機能の細分化。コードとUTは人日単位まで落とし込む。コード UT以外のやるべきタスクの洗い出し。それを積み上げる。
スケジューリングは、細分化された機能等を、タスクまたはwbs としてカレンダーにマッピング。優先順位もつける。

機能の細分化の際、オブジェクト指向でやる。すなわちオブジェクトや、それに含まれるメソッドが、ビジネスの要素にマッピングされるので、クライアントにも理解されやすい項目となり得る。同時にその見積もりの項目は、必要なクラス一覧にマッピングされる。

要求は変化する。要望は追加される。その要望を実現するために、どうして追加のリソースや工数が必要になるのか、クラス・メソッド一覧にマッピングできる見積もりは、クライアントへ、十分な説明が可能になる。

もっとも、開発論、技術論ではないところで、大枠の金額や納期は圧縮されるんだけど、オブジェクト指向とは関係ないので省略・・。

ソフトウエアクライシス対応 1 クライアントと握る

クライアントの考えていることをシステムデザインにキチンと反映する。当たり前のことなんだが、現実はキチンと決まらない。クライアントとの定例会議の最初の頃は、クライアント自身が考えが至らなかった事柄もある。要望は段階的に出てくる。

ダイナミック、インクリメンタルな開発は世の流れとして必要となる。そのためには、UMLなどを用いて、対クライアント、対内部のコミュニケーションコストを下げておく。オブジェクト指向はビジネスをモデル化することがキモであるから、うまく機能していれば、従来の設計レビューより、クライアントと握りやすい。

リリースは段階的に行う。一気に作るのは、このご時世では危険。小刻みにプロトを出す。外部仕様だけでも早い時期に見せていく。html紙芝居も有効な技。

クライアントの考えていることとは、「要求仕様」とは異なる。ここは大きなポイントだ。
今まで、システム開発の目的は、「要求通りの構築」だった。しかし時代のニーズは、システム開発の目的を「満足とビジネスの成功」にしてしまっている。
要求とは「確定させるよう吸い上げるもの」から「変化するもの、随時対応するもの」になっている。

ゴールとその効果測定（定量）まで、初期にヒアリングし、握っておく必要がある。

ソフトウエアクライシス3 ネット WEB2.0

ネットを前提としたシステムは、不特定多数の利用者を持つ。ネットを前提としていなければ、有る意味閉じたシステムともいえる。有る程度、ユーザが決まっていた。しかし、ネットにUIを持つ・開放するということは、データ更新を伴うオペレーション・操作を不特定多数の人間が行うことを意味している。ネットの前の時代なら、そんなこと怖くてやらなかった。

ネットやWeb2.0になって、ハードやソフトやAPまでも、IPリーチャブルなどこかに置かれている。そういうシステム連携をキチンとデザインできなきゃいけない。少なくとも、それを理解しイメージできてないと、コードもちゃんと書けない。

さあ、ラッピングだ。APIだけ覚えりゃいいにしちゃいましょう。
例えば、オープン系からキャリアスタートの俺が何だかんだ言おうと、ホスト、基幹、汎用には、既存のソフトウエア資産が大量に積まれているのは事実だ。その資産を利用することも必要とされる。だから外側に皮を被せる。ゲートウエイと言ってもいいかもしれない。外からみれば、オブジェクト志向で作られたAPIだけだ。中（裏）では昔のままのレガシーアプリが動いている。中は皮とメッセージ連携、イベントドリブで連動させる。

amazon でも、googleMaps でも、中で、何が動いているかなんて、どーでもよい。
APIで何が提供されているかだけが問題になる。

ブラックボックス化、API化によって、ネットが社会のインフラとして重要度はさらに増してきている。ちょっと前まで、ブラウジング、情報得る、見るだけのお手軽システムだった。せいぜい、ちょいとCGI。

ecサイト。B2B B2C。取引、決済が、ネットをインフラとして電子化されている。それは閉じた世界じゃない。ネットというオープンな世界のテクノロジを使う。xmlを使って、取引の区別をなくそうともしている。（標準化委員会の結論はどうなったかな）
従来のクローズされた世界のシステム以上に、堅牢であり、信頼できることを要求されている。そいつを２ヶ月でやれと求められる。泣いても許してもらえない。

さあ、どうしましょう。

だからこそ、十分テストされた信頼性の高いコンポーネントを使う。それは自分のシステム外でもいい。信頼できれば。
I/F重視、徹底したコンポーネント・モジュール化。

そのシステムデザインをステークホルダが共有する。共有するというのは、単にファイルを共有するということではなく、仕様や設計レベルも含めて共有する。それがないと、前節のインクリメンタル開発は実施が困難になる。そのシカケ、方法のひとつとしてUMLがある。それをチーム開発のリファレンスとする。しかし、UMLで表現すれば、問題が解決するわけじゃない。モデリングが大事であることは論を待たない。モデリングのコアは、アーキテクチャ確立で、これがブレることはプロジェクトのゴールが変わったことを意味する。

ソフトウエアクライシス2 さっさとやらんと他社に負ける

計算機は神様で、電算室、EDP室という神殿があり、技術者は神官であり神主だった。帳票１種類追加してよとお願いすると、完成は１年後ですというご託宣が下ったりした。企画し要求をまとめ仕様を決め、設計、製造、テストまで、２年とか３年でよかった。今でも、インターネットバンキングだと、ページの文言を変更するのに１ヶ月は必要だ。

大半のネットの世界には、そんな幸せはない。
ECサイトを作りたい、というクライアントがいる。
３年前だとカットオーバに３ヶ月もらえた。今じゃあ２ヶ月だ。

さあ、その２ヶ月で、クライアントのビジネスモデルを理解し、時には一緒にモデルを作りつつ、デザインして、コード書いてテストして。
その間に、そのクライアントのライバル・競合会社が、新しい機能をつけたりすると、すぐにつけろ、となる。
携帯のコンテンツをサーブするシステムだと、企画責任者が「ピンクのハートと黄色いハートじゃあ、集客力が違うのよ！」と、直前に言われたりする。PGの「どっちでもいいじゃん」みたいな話は通用しない。それはユーザの嗜好性に基づいたプロジェクトの成否をわける話だから。
画像の差し替えじゃなく、機種依存の絵文字の話だから、かなりややこしい。

開発サイドは、かなり苦しく負荷が高くなる。近々そうなるという話じゃない。もう、そうなっている。

さて、じゃあ、どうするか、だ。

ひとつは、０から作るのはやめましょう、と。
業務・業種で、こういうワークフロがありますね、と。それに対応するフレームワークを作りましょう。コンポーネントの組み合わせを想定しておいて、クライアントの要望をコンポーネントにしてプラグインしていく。
昔からあるパッケージソフトとか、ライブラリー群との違いわかるかな？
コンポーネントとしてプラグインするってところが、オブジェクト指向風。
そして、コードの再利用だけじゃなく、分析・設計の再利用も。
いい悪いというより、そういうスタイルにしなきゃしょうがない。

もうひとつは、仕様変更・追加は必ずあるとリスク管理しちゃう。
リスクといっても、昔のレガシーのころからの工数を大目にするって話ではない。
クライアントとシステムアナリストが、仕様まで落とし込み、コード化がはじまった。しかし、最終は、マーケット、ビジネスを、クライアントとアナリストが読みきったかどうかが大事で、読みが甘いとそこで仕様は変更される。
費用は別として、仮に対応しきれないと、クライアントは満足しないし、クライアントのビジネスは成功しないし、次の仕事はこないし、会社は生き残れない。
最初にいったけど、技術サイドの話じゃない。世の中にニーズの話だ。
アプリの仕様の変更、追加は、クライアントのビジネスの成功のためには、当然のことだ。それが世の中のニーズで、ソフトウエア開発者にとっては、生きていくのがイヤになる時代になった。
だから、インクリメンタル開発。プロトを提示し、早期に確認し、繰り替えし、積み上げの開発が、世の現実のニーズに近い動き方といえる。

以上、webのビジネスサイトを中心に書いたが、組み込みの世界でも、期間圧縮のプレッシャーはかなり強いとのこと。
携帯電話のバグで回収騒ぎがあるが、中身の８０％以上がソフトウエアで、２,３ヶ月のスケジュールで、テストも全てこなせず、品質としては問題があるのはわかっていても、生き残るためには、ヤムナシと市場に投下せざる得ない・・ということも、聞いたことがある。

ソフトウエアクライシス1 組合わせは星の数

ハードウエアや、O/S ミドル。必要とされるソフト数、テクノロジー、要素は増える一方だ。それらを適切に組み合わせることが必要とされている。
さらに、ネットも加わる。ネットを前提として、ＰＣを前提とし、さまざまなデバイスを前提としている。

従来のEDP室に鎮座増します計算機様では、クライアントにとっての意味がなくなってきた。連動して動いていくことに価値や意味が生み出される。組み合わせ、連動の世の動きは、WEB2.0にまで行き着いている。

組み合わせは星の数。とってもやってられない。
で、抽象化、仮想化、I/F重視という考えが出てくる。
オブジェクト指向を使って、まず組み合わせの要素を抽象化しインテリジェントなオブジェクト・仮想化されたデバイスにしちゃいましょう。
そしてその間、I/Fで、どういうプロトコルで、どういうメッセージをやりとりさせますか、という視点から、デザイン、設計を進めていきましょう、と。

これで、設計・デザイン上では、さまざまな機器の違いを吸収して、話そうとする。

そういったことを実現するひとつの方法として、Javaがある。
JVM(Java Virtual Machine)では、APIさえ知っていればいいんだよ、と。SUNが一生懸命その流れを作ろうとしていた。（APIを利用するだけのPGが、本当にPGと言えるかどうかの議論は別の機会-ソフトウエア職人気質-でやる。）

Javaを否定するつもりはない。が、大事なのは、Javaそのものではなく、仮想化、抽象化、I/F重視というデザイン姿勢を身に着けること。そして、自分の設計に適用していくこと。
ここを理解できてしまえば、Javaの流行が終わっても、次の処理系に移っていくことができる。

そして、そういう思想でデザインされたシステムこそ、クライアントの資産となりうるのであって、抽象化も、仮想化も十分にされてないけどJavaで書きましたといっても、それの価値には疑問をつけたい。

背景:ソフトウエアクライシス

オブジェクト思考が持てはやされた背景には、ソフトウエアクライシスがある。
最初から技術・開発サイドからどうこうというより、社会的要請、クライアント自身はその要望が進化・高度化してきたことを、開発サイドが、追いかけて出てきた概念だと思う。
はじめに、技術有りではなく、ニーズ有りだった。

その必要性を理解する中心に、ソフトウエアクライシスがある。
ソフトウエアクライシスという類の話は、３０年前からある。が、当時の危機は、ソフトウエアエンジニアが不足していくことが心配されていた。
今は、まあ、数はいる。それこそ、Perl しか書けないPGでも、一応は生きていける。
ちなみに昔は、COBOLができれば一生食えるよねと言ってたけど、食えはするけど、それだけじゃ、上には行けない。変化についていく、世のニーズにあわせて、自分を変革させないと。

今のソフトウエアクライシスとは、ソフトウエアのPGの不足ではなく、いわゆるウオーターフォールで言う上流、クライアントのニーズをモデリング、デザインすることができる人が不足している。ここでいうデザインとは、ヴィジュアルではなく、システムデザインだ。

今できるか否かの自己認識は大事だが、それ自体は問題じゃない。生き残るためには、現在の世のニーズをつかみ、自らをも進化させることが、必須となる。

大阪の本社のソフト会社の営業

資本金３００万　創立３年。社員１７人。今回東京進出。仕事下さい。
「あなたは、営業専門？技術わかります？わかりませんか・・」
「うちが、あなたの会社を信じて仕事を出す理由は？」
沈黙されちゃった・・。可哀そうなんで、ヒント出す。
「実績も、規模もない会社に、営業マン見て、仕事は出せないよ。ホントにできることを訴求してもらわないと。」
「じゃあ、これから話す案件の見積もりやってみる？　でも、あなたちゃんとヒアリングできるの？　俺の話す内容、ちゃんと意味分かる？」

次回、ＳＥ連れてヒアリングします・・とのこと。使えるかどうかは、出てくるＳＥ次第だな。

ソフト会社の営業って職種・・甘くみるなよな・・。

御社の顧客は、やっぱりアダルトサイトが多いですか？

電子決済の代行会社の営業が来た。ようするにECサイトを構築・運用する時に、https でデータ投げて、クレジット会社の与信やらをやってくれるサービス。とりたてて珍しくもないが、他の会社との価格やサービス比較はしておきたい。自分たちの顧客に、ちゃんと提案できるようにネタは仕込んでおかないとね。


訪問してきた営業さん、開口一番。
「御社のお客さまは、どんな業種が多いのですか？やはり海外のアダルト関係とか多いですかねえ」
そうか、君の会社の、クライアントは、そればかりか。じゃあ、きっと他所の代行会社で断られたところを
一生懸命拾って、売り上げにしているのだな。営業として苦労はしてるんだろうな。

いや、でもね、俺たちを一緒にするな。

前も書いたけど、アダルト系の仕事のオファーはけっこう多いんだ。売り上げ苦しい時、ほんとどうしようかなあ、と思ったことが、ナイとは言わない。でも、やらずにすんでる。これからもしたくない。

固い、堅実なお客さんが、いてくれる。そういうお客さんを相手に、がんばって、いい仕事をしようとしている人がいる。自分の部署にも、他所の部署にも。

その場はね、少しは話をあわせてやった。
「男性の一人として、まったく興味がないというキレイ事は言わないが、この会社じゃやらないよ。」

まあ、でも、ちょっと、だめだなあ。不信感＆不快感、バリバリ・・。

オブジェクト指向概論 目的

オブジェクト指向(オブジェクトオリエンテッド)について、基本的な考え方と周辺のモロモロをまとめていこうと思う。これによって、オブジェクト指向の有効性を、ニーズとシーズの両面から説明を、数十回？にわたって試みてみたい。

ブロジェクトのおいて自分がオブジェクト指向を理解しているだけでは、実は足りなくて、社内、組織、チームで、オブジェクト指向開発が有効に機能しないことになる。人に説明できることが重要になる。

試みるポイントは、
ウオータフォールとの比較と経緯。
ＵＭＬの基本文法とモデリングに触れる。

オブジェクト指向開発を、乱暴に、即物的言ってしまえば、UMLで設計をすすめてていく開発プロセスだが、知識があれば成功するわけではない。
若干ではあるがリスク管理にも触れる。

技術者３０才収入限界説

なんか、「技術者３０才収入限界説」というのがあるらしい。ググって見たが、見つからないが、そういうことを言っている３０才がいた。

う～ん・・。
自分の経験から言うと、３０才の時より４０才の時のほうが、稼ぎいいけどな・・。

うちの仕事をしてもらっている個人事業主、フリーエンジニアも３０代が多いけど、まあ、すこしづつだけど、年商という意味では、上がってきてるけどなあ・・。

まあ、ただプログラムを書き、社会常識や仕事の常識を身につけないでいる人で３０才を過ぎた人なら、使いたくない・というより、一緒に仕事をしたくないけどね。３０才前だったら、怒りながらでも、何とか育てようか・・みたいな気もおきるけどねえ・・。

なんか、そんなこと、限界説を言っているよりさあ、がんばって、知恵絞ろうや。
給料は多いほうがいいのは、みんな同じで、だから、いろいろジタバタしてるんだから。

下請法抵触の危険

公正取引委員会のサイトの下請け法トップページに、詳しいことがのっているが、ドキリとしたこと。

何人か、フリーのエンジニア、個人事業主に仕事をしてもらっている。
1997年ごろから、基本は、知り合い・・に近いノリで、口頭で金額と期間と決めて、よろしく・・で、やっていた。支払いを遅らせたこともないし、減額もしたこともない。社長がけっこうそのへんの「せつない」苦労が分かる人で、条件が月末なら「どうせ払わねばならないんだから、１日前に振り込んだら、喜ぶさ」と、毎月心がけてくれている。

そんな信頼をベースにしていたんで、Ｈ１４の下請法改正まで、契約書・発注書、まったく作ってなかった ^^;;
上記サイト見て「いや、これ、うち適用されるじゃん、しかも違反じゃん」
あわてて書類を調える。故意も悪意もないから、社名公開されずに、警告と罰金になる話だろうけど、ちゃんとしといたほうが、いいわな。

関連法規って、油断していると怖いなあ・・。

下請法（下請代金支払遅延等防止法）のこと

公正取引委員会のサイトの下請け法トップページに、詳しいことがのっている。

うちの会社の場合、下請け業者にも該当するし、発注元（＝下請けを使う会社）にも該当する。H14年に改訂されて、ドンピシャで、適用される対象になった。

ある顧客、プロジェクトの担当者とは、メールベースで、納期や金額を合意して着手。だいぶ時日が経過して、契約書の段になり、契約部門の担当者とお話することになった。

勿論、発注時に書面を作る義務が発注先にはあるんだが、今まで、ノートラブルだし、いかに法律があるからとて、あまり固いことを言ってプロジェクト担当者の心証も害したくない。

ところが・・契約担当者が変わって初めてのヤリトリで、いきなりメール来ました。
「お見積りいただきましたが、弊社の希望価格は、ＸＸＸ円です」（約１０％引き）
ギリギリなので、できないと答えると
「弊社予算達成の為、取引先各位に協力をお願いしており、各社様に一段のご協力いただいております。是非、貴社にもご理解をいただきますよう今一度お願い申し上げます」
あ～あ。これって、モロ違反だよな。「下請業者の責任によらない理由での減額」

さあ、どうしよう。
相手に向かって、「あんたら違反」「公正取引委員会にタレコミます」とは言いにくい。で、
「今回、一部を第三者委託をしているので、その理屈をうちの下請け会社に言うと、うちは、下請法違反で摘発されますので勘弁して下さい。」
そしたら
「不勉強なんで、下請け法って良く知らない。どこが抵触するのか教えてくれ」と言う。
う～ん・・。契約担当が知らないの・・まずくないですかあ。

で、最初のＵＲＬを案内するとともに、「第３条書面の作成、第４条減額の禁止に抵触する可能性があり、うちの会社はそんなリスクはとれないので、うちの下請け会社には減額の交渉は一切しません。」とメールした。

いっやあ、プロジェクトの担当者が怒って電話してきた。
「契約担当が、カンカンになっている。うちに喧嘩売ってるのか！」
「いやいや、うちと、うちの下請け会社との可能性について書いただけですから。御社とうちの関係については何にも書いてませんよ」

・・・まあ、でも、普通に公正取引委員会のＵＲＬ見たら、やばいって思うよなあ・・。
「弊社予算達成の為、取引先各位に協力をお願いし」「各社様に一段のご協力」って、メールに書いてきちゃうんだもん・・。

どちらにしろね、うちは調査入るので、調査票に事実を書かなきゃいけないし、うちの仕事をしてもらっている会社に、着手してからの減額なんてする気もないし。

ああ、もう、このお客さん、お終いだなあ・・と思った。
僕の気持ちとしては、喧嘩というより、「あ～あ」が近い。
明白に法律違反なんで、喧嘩という気持ちは通り過ぎてしまった。

そしたら、契約担当から、落ち着いたメールが届いた。
「ご教示ありがとう。では、御社の希望に沿う形で進めます。」
たぶん、上司なり法務なりに相談にいったんだろうなあ。内心、煮えくり返るような想いもしたんだろうなあ。でも、もし、ここで契約担当が怒ってきたら、ほんとに即時に公正取引委員会へ行って、大騒ぎだもんなあ。下手なことは言えるわけない。

で、結局、満額の発注書が届いてきた。値引きナシ。
これで、「減額させたという事実」は、なくなった。記録に残った事実は、「減額の交渉」だけで、これだとたぶん、第４条に抵触はしないで済むんだろうな。

やれやれ。なんか、こっちもホッとした。
苦労して営業して取引開始できて、何回か仕事させてもらって、納品したものの評価もそこそこいただけて、心証は確実に悪くしたと思うが、それでも、金払いやコンプラの問題だと、取引するわけには、いかないし。

Google Maps API のこと２

ポイントを自由におけるツールを作った。
とりあえず

地図は勿論、Google Maps APIを使って表示しているわけで、上のレイヤーにポイントはラインを置いているだけ。

周囲に何を出すか・・ってところが、勝負。
お客さんに見せると、けっこう面白がってくれる。
どう使うか・・ですな。

きっと世界中で悩んでいる人、けっこういるだろうと思われる。

ZenCartのこと2 モバイル版

ZenCart せっかく（？）だから、モバイル版作ってしまおうということになって、やってみた。

UIは、日本の携帯ECサイトに似せたほうが、一般的には戸惑わないで済むだろうなあとやっていくと、中のDBのテーブル定義にも手を入れることにもなってきた。

とりあえず、ベータ版。
今週中に、検索エンジンに登録をはじめる。サンプルショップ

はしょった機能もけっこうある。例えば、商品データは登録できるが、削除の画面はない。（手でＳＱＬ叩きゃ消せるけど）

まあ、イメージはわかるわな。
とりあえず、後は実際に問い合わせがあってから、対処。
次のこと、google MapsのAPIに、パワーの方向が向きつつある。

2W3Wの事情 その１

受託・請負メインの傍ら、こんなことを立ち上げて半年。公式のサイトのほうには、書けなかったことを。

「あるプロジェクトで、JAVAの人が欲しい」と。うちは、1997年ごろから、WEB、ネット絡みの開発が90％でそういう「開発者を貸してくれないか」という話がよくある。もっとも、「貸して・・」と言われて、ハイハイというほど、たくさん人がいるわけでもないし、正直、本業にしていない。

一方、ちょうどタイミングよく、ある会社から、「JAVAできる若者いるけど何か仕事ないですか？」というのが、出てきた。

で、紹介したところ話が成立。うちは実質紹介だけだが、キャッシュバッファを務めるので、5%の手数料をとらせてもらうことになった。
入ってくるお金は３ヶ月単位で、支払い入金は、さらに６０日先。でも、支払いは毎月。仕事の先の与信がしっかりしているところだからできることだけど、それでも、5%は、かなり良心的な数字だと思う。

現場は、きついプロジェクトだった。300時間/月 の時もあった。超過時間に対しての請求はできるものの、本人のことを心配していた。毎月、とんでもない残業が出ていて、うちから支払う金額は、９０-１１０万。こうなってくるとお金の問題じゃなく、過労死でもされたら、とんでもない。
何度かクレームはあげても、プロジェクトも厳しいらしく、改善はされない。
自分自身、PMの経験もあるので、危機的プロジェクトの事情はわからないでもないが、さて、どうしたものか、と思っていたところ、所属会社から「話がしたい」と連絡があった。
「ああ、引き上げるという話だろうな」と思った。
無理のない話だと思うし、ハッキリそのまま仕事先に伝え、勿論、「抜けられたら困る」と泣きつかれるかもしれないが、そこは期間をみて、終息させることになるだろう。

所属の話は、予想通り、「撤退したい」だったのだが、ただ理由が予想外で、本人が会社を辞める、しかも、すぐにでも辞めるような勢いだ、とのこと。

意外だった。紹介だけとはいえ、現場に入った後も何度か会って、飲みにも行き、話もしてきて、投げ出すようなタイプじゃないと思っていたんだが・・。

現場の本人をつかまえ話をしてみた。

別に今いるところの仕事が、いやでいやで仕方がないというわけじゃない。
たしかにきついんだが、それなりに、いいところもある。
ただ・・と、彼は言いよどんだ。
無理やり口を割らせたのだが、所属の会社の評価が納得できない。
今、自分の給料は25万。たぶん、今年は年収で、350万程度。

350万って、月30万弱・・。
うちは、会社としては、彼の会社に平均で100万は払っている・・。

勿論、正社員であれば、仕事がない、売り上げがない時でも、給与は保証していかねばならないし、間接費だってかかるわけで、全部が全部、本人にはわたせない。当然、他の社員とのバランスもあるだろう。会社の全体の収益等の事情もあるだろう。
しかし・・。

「止める資格もないし、そんな気もないけど」
「辞めてどうするんだ？次の仕事決めているのか？」

「好きで、始めた仕事だけど」
「このままこの業界で仕事をしたほうがいいのかどうかも迷っている。少し落ち着いて考えたい。」

ロクな努力も覚悟もなしで、カタカナ・アルファベットのこの業界で、楽して食えればイイネなんてタイプの人間もたくさん見てきている。でも、彼は違う。
努力もするし、辛抱もする。人の話もちゃんと聞き、自分のものにしていけている。
もったいない！

「もし、今の現場の仕事が、イヤだというなら、あきらめるけど現場は抜けられたら、困ると思うよ。
もし、現場がイヤでないなら、今の会社辞めた後、俺のところと、個人事業主として契約して仕事するか？」
「ギャラはいくら欲しいんだ？」

「少し考えさせて下さい」

数日後、彼の希望通りの条件を飲んで、その後２ヶ月、プロジェクトのカットオーバまで、やってもらうことになった。

今いる会社が、受託・請負をメインでやっているので、自分でもすっかり忘れていたが、別に、彼と所属の話は、昔からこの業界で、ザラにある珍しくもない話だ。
だが、ひさしぶりに出会った見事なエゲツナサに、正直、かなり腹がたつのを感じた。所属の会社にも、自分にも。

だめだわ、こんな商売しちゃ。

プロジェクトのニーズも、プログラマにニーズも確かにたくさんあるので、紹介そのものを仕事とすることは、否定しないが、もっと、ストレートに、オープンに、正々堂々とやっていきたい。

じゃないと、寝覚めが悪すぎる。今、自分のオフィスで一緒に働いている人に顔向けできにくいわ。
理想論かもしれないが、めちゃくちゃ大規模にすることを指向しなければ、地道に進んでいけると思っている。

厚顔さと恥知らず

政治ブログじゃありませんが。
北朝鮮のミサイルで思った国際問題とは無関係の雑感。
武部幹事長の敵地攻撃論。
「力ないのに、そういうこと言ってること自体が恥ずかしい」
「アメリカの力を使ったところで、実際にミサイルを全部つぶすなんてできないんだ」との、ＴＶでのコメントを聞く。
いっやあ、こりゃ、本人がこのコメント聞いたら、恥ずかしいわな。きっと、秘書とかが報告するだろう。俺が、もし武部さんの立場だったら、「どえらく無知なところを世界にさらしてしまったあ」と夜ももだえて眠れなかったかも。
でも、政治家という種類の人たちは、そんなことじゃあ、めげないし、悩まないんだよな。めげるのは、志が低いから、想いが足りないからと、口をぬぐって、何もなかったかのように振舞うに違いない。

政治家だけじゃないよな。そういう会社、そういう社長、そういえば、一杯いるわなあ。あきれるような恥知らずの社長いたな。（それはまた別の記事で）

とはいえ、まあ、いいかげん、俺もいい年だし、ＳＥ，ＰＧとしては現役バリバリじゃないし、最近も恥ずかしい間違いも・・しましたあ。たくさんやってます。きゃ～ごめんなさい。
でも、くぐってきた修羅場の数だけは、厚顔になってるかも。恥ずかしいと言って、出ないわけにはいかないし、開き直るしかないし、忘れるしかないし。逃げずに、取り戻すように、今、ここで、トライするしかないし。

朝のニュースで、ミサイルとは関係ないこと、考えちゃいました。

ブログ・システム納品完了

今年になって２件目。
１件目は、ＰＣのみだったけど、今回のは、モバイル版もあり。
けっこう、本当の意味で、やりたがる組織、増えてきたという実感がある。

以前から問い合わせはあったが、自ら発信したいというより、「自分には発信するネタはないけど、そういう場をつくり、そこで何らかの利益をあげたい」みたいな話ばかりだった。
それこそ、「何かＷＥＢで儲かるシステム作って」「けーたいで、何かビジネスしたい」みたいな話が好きな人がアイデアを形にしたくて、相談・商談を持ち込んできていた。

けれど、そういう流れが一巡して、真面目というか、自分達の組織で起きている事や、世に向かって届けたいという意思があり、どこかのブログサービスじゃいやだ、という話が、出てきている。

まあ、それこそ、書いて、WEBに出すことはできるわけだが、その内容を必要としてくれる人に、届ける、必要とする人が見つけてくれる。そういう技術の発展、確立も、大きい要因だな。

かくいう自分も、書いている内容を、「面白い」と思う人に届くであろうという、検索エンジンに対する信頼のもとに、ブログしているわけだが。
検索の仕掛け、ある情報を必要とする人に届ける、見つけてもらう。これも、もう、リッパなインフラになりつつあると思う。

ドキュメント読もうぜ

半年前に納品・検収した、サーバサイドのプログラムがある。ユーザＡ社の要望で、横展開・他社にも利用させることを前提としていたので、ドキュメントはかなりの分量になったが、どうにか検収も通り、また評判も良くて、現在、Ａ社から別の案件の開発もいただいている。

さて、納入したプログラム（PHPのスクリプト）を、我々の顧客Ａ社が、別の会社Ｂ社に支給？販売？することになった。Ａ社は、そのプログラムそのもので利益をあげるのではなく、Ａ社とＢ社で業務連携をするのに使う。

5/29 11:00にＡ社から電話がくる。
「動かないってＢ社が言う。ログにエラーが出てる。」
「6/1 にカットオーバなんだ。必達なんだ」と言う。
環境周りが原因じゃないんですか、と伝える。だってＡ社の環境では、今も元気に動いているじゃないですか。
「それはわかっている。うちは、瑕疵、バグだと思ってない。」
「Ｂ社が、バグだと言ってるんだが、我々ではＢ社を納得させられない。」
「何より、時間がない。6/1に動かさないと、広報も動いちゃってるし、非常にまずい。」
「いや～・・それなら、最初からインストール・設定作業を発注して下さいよ」と、言うのは飲みこんだ。そもそも「他所の会社でも自分でインストールできるドキュメント」を要望されていたんだからなあ・・。

「とにかく、動かして欲しい。瑕疵対応じゃないと思っているから、対応にかかった費用は出すから」
うん・・まあ・・お金の問題だけじゃなくて・・当時の担当ＳＥやＰＧは、他の案件についてるし、そっちも月末にあげる成果物めざして、全力で、動いていて、おいそれと、はずすわけにはいかない。6/1って、もう、すぐじゃん！

「6/1って、時間ないですねえ・・でも何とかしないといけないんですよね。今、当時の担当者で、すぐに動けるのは、いないんですが・・・」
「やれるだけ、やってみますか」

Ｂ社のメールが転送されている。
「文字化する。プログラムがおかしいと思われる、エラーＸＸＸ番が出ている、ログはこれ」
う～ん。プログラムに喧嘩売ってるようなメールだなあ。
まあＢ社の本人さんは、実際の開発会社の我々が見るとは思ってなかっただろうけど。

Ｂ社の担当に電話する。
「Ａ社はO/SをEUCで入れている。今、普通に入れるとUTF8ですよね。大丈夫ですか」
「う！　確認します」

Ｂ社から連絡くる。
「EUCでした。」おまけに「どうしてプログラムは、ＸＸでＸＸしてるんですか。おかしいですよね」と言ってきていた。が、とりあえず、無視。その前に確認しないといけないことがある。

次の質問
「モジュール一覧表もらってますよね？ファイルサイズとタイムスタンプあってます？」
「え？？比較してないですけど」
「比較したほうがいいと思いますよ。種々の経緯があり、複数のバージョンがありますから。」
「オペレーションミスで、改行記号が入ったり、コード変わったりしますから」

Ｂ社から連絡くる。
「4ファイル違います。」（・・・あのねえ・・受領の時に確認しろよな）
「違うファイルを tarで固めて、WINDOWSにBINでFTPして、メールに添付して送って下さい。」
送られてくる。内容確認。まあ、違ってはいたが、これが原因はなかった。

次
「ミドルウエア構築手順書、届いていますよね？Ａ社からもらってますよね。」
「もらってます」

次
「文字化けって、PHP のmbstringsあたりの設定が疑われるんですけど」
「php コンパイルの configure は手順書通りやりました？」
「php.iniは、手順書通りですか？」
一方、万が一、自分達のソースに問題があった場合に備えて、開発・試験サーバを準備させる。 保守契約してないし、半年前の納品物なんで、本番と同じ環境は保持してない。 とにかく時間がないから、打てる手はうっておく。

で、結論は・・・ 「ドキュメントは読みしょう」
php.iniドキュメントの中に ちゃんとあるでしょ！

一般ＰＣユーザじゃないんだからこの世界、この業界で、メシ食わせてもらってるんだから提示された文書は、読めよな。この業界じゃなくたって、相手から出てきた書類を読まないでいたら・・普通は仕事していることにならないんじゃない？。

Ｂ社さん・・うちより、ずっと大きな会社で、ＷＥＢの開発や構築、ずいぶんたくさんやっているみたいだし、自信はあったんだろうな。でも、読まないとね・・。ことに、うまく動かない時は・・。

まあ、いいか。そういうことがあるから、うちのような名もなき小さな会社でも、重宝して使ってくれるところがあるのかもしれないなあ・・。

Ａ社さんからは、調査や、やりとりにかかった稼動をいただけることになった。あんまり困ってる時に、ふっかけるようなこともしたくはないんで、実働の数時間分。

たぶんに、こういう時の費用というのは金額の大小というか利益じゃないんですよね。
自分達の納品したものに瑕疵がない、でも巻き込まれて動いた。そのケジメのために・・なんですよね。

新規顧客から入金確認できた

今年から初めて取引をいただいた御客様へ請求したお金の入金（振込み）がされた。勿論、そんな逃げるような会社でも、儲かってないような会社ではないことは、営業初期の段階で確信は持っていたものの、実際に振り込んでいただくと、営業も兼ねてる立場としては、ホットする。やっと一仕事終わったか、と。
去年の秋、９月位だったかな。会社のWEBを見ていただいて、お電話をいただいた。初めての訪問は、双方の会社案内。次の時に、ご担当から案件の詳しい話を伺った。案件として成立し、受注が確定したのが、１２月半ばかな。体制・担当を用意して開発開始したのは、今年の１月。２末に一度納品、検収。ブログサイトの開発で、運用初期のサポートや質問、一般ユーザからのフィードバック（意見・要望）などがおちついて、請求書の発行が、３月末。そして、この５月半ばに入金・・と。足掛け９ヶ月かあ。
請負開発の新規の顧客開拓は、気長というか、地道にやっていくしかないですね。実際、自分が発注する立場の時は、知り合いとかで、スキルやレベルがわかっていれば比較的安心して仕事を出すこともできる。そうでない場合は、はじめは、小さなことをやってもらって、時間をかけて、考え方とか見ていかないといけないものなあ。
自分達の見込み客だって、「こいつら大丈夫かなあ」と思いながらも、リスクをとっていただく決心をして、発注してくれている。「高橋さん、一蓮托生ですよ」「失敗したら、私も立場ないんです」と、発注の時、言われたこともあった。人の情として、誠意を尽くすのは当然として、そういうお付き合いのできる方、会社さんとの出会いは、広告や広報はその機会をつくる重要なポイントだけど、根本は、地道な積み重ねの先にだけ、あるものだと思う。

DMの許諾

電話１件、メール１件、ほぼ同じ内容で、別々の会社から、「イベントやセミナー情報をお知らせしたいので、顧客ＤＢ入力と、メール配信させてもらってよろしいか」と。

う～ん、はっきり言って見ないです。
迷惑メールに分類し、そのまま自動でゴミ箱です。

どこかで、ＩＴ会社の経営者向きに、わけわからんセミナーでもあったのかな。「メールを使ったセールスプロモーション」
10年前なら、効果あったかなあ。

逆に、お聞きしました。「ＸＸさん、あなた、その類の案内、丁寧にみますか？毎日数百通メール来るんですよ。来たら、興味じゃなくて、不快な思いを持ちますよ・・」
ご納得いただけたようです。たぶん、送ってこないでしょう。

PHP5の仕事

今、うちの受託開発で細かい話は、大半がPHP5の開発。１年前からそんな感じだな。それまでは、perlとかASPとか、tomcat JAVA なんて話もあったんだけど。
その他、PHPできる人貸して下さい・・なんてのも、増えました。
けど、それも、もう、いつまで続くのかな。

-->こんな記事


言語やフレームワークって、それぞれ思想があって、人間で言えば適材適所で使う・・みたいな使い分けがいる・・てのはテクノロジーの正論。でも、実際は、けっこう、「はやり」で決まっちゃうことが多いよな。

まだ、わからんところだけど、とりあえず、Ruby では、遊んでおこうかな。

素敵な問い合わせ電話

「双方向の動画配信システムの構築を御願いできるところを探しているんですが・・」
（あ、おもしろそ～、やりた～い）
「一応口外しないで欲しいんですが、いわばネットキャバクラなんですよね」
（お断りしました。だいぶ前のことなんで、もうどっかに実現されてるかも）

「あのさ～、けーたい使って、な～んか儲かるビジネスしたいんだけど、何かないっすか」「いま、リーマンなんだけど、けーたいで、ビジネスしたいんですよ、おれ」
（あったら、自分でやってます）

「ケータイでビジネスしたいけど、金ないんすよお。儲かったら山分けでどうですか」「いや、いい企画なんですよ。絶対儲かりますって」
（勿論、企画次第ではあるし、ちゃんとした会社とタイアップしたこともあるけど、ギャンブル系の話だったし、何だか話し方も、あんまりなんで、ご辞退申し上げました）

別に聖人君主を気取るつもりはないし、リスクをとらないつもりもないんだけど。働いている人が、自分の女房、旦那、子供、彼女、彼氏、両親、兄弟、親戚、友人等に、守秘義務の制限はあるんだが、「俺（私）の会社、このサイトの開発・製作やったんだよね」と胸を張って言えるようでありたいわ。

ZenCartのこと

ECサイトのオープンソースのZenCartのことなんだが。

とりあえず、サーバを用意し、インストールし、ダミー商品を登録してサンプルショップを作ってみた。

いや、ここまで、けっこう大変でねえ・・。

JPのコミュニティ、がんばってると思います。頭下がります。
でも、やっぱ、バグあるんですわ。
本家のサイトにいくと、それは直っていたりもしたし、勿論、直ってないこともあったりして。
けっこう、中いじりました。 まあ、オープンソースだからね。当然といえば、当然ですが。

今日現在は、紹介のためのコンテンツは未完だけど、スタティックHTMLのこと、ぼちぼちとできてＵＰできるだろうと思われ。

「ソフト会社ですう、上流からできますう、得意ですう。」
幸い、自分達の力は、わかる方にわかっていただいて、何とか仕事があって食いつないでこれてるんだけど。その「できる」ということ、そうあり続けることが、一番大事なことであるのは変わらないものの、自分達が「できる」ということを、知ってもらわないと、知ってもらう努力なり工夫がないと、こりゃ、仕事は、増えないですわ。

その一環として、得意な「オープンソースの活用」のサンプル作りをやってみた。
結果、効果がわかってくるのは、数ヶ月先だろうけどね。
まずは、トライ。
仮説・検証（効果測定）・修整。そんな積み重ねなんだろうな。

Google Maps API

いわずもがなの、Google Maps API なんだが・・・。ひとひねり加えたくて携帯版 Google Maps を試みてもらったところ、Google Maps APIを利用したJavaScriptはサイズが大きいため、読み込めず、エラーになってしまふ。
また、JavaScriptを使わずに使うことは禁止されているから、加工してみせる・・・、ということも、まずかろう。

ま、違うことかんがえますか。

A9 OpenSearch

分散されたサイトの検索ができ、トラフィックもわかるるしかけ・・と聞いて、けっこうすごいな、と思った。いやいや、どうやって実現しているんだろう？　顧客のＡ社とかに持っていきゃあ、飛びつくかも。
http://www.a9.com/

コンテンツを持っているサイトが、RSSまたはAtomで検索結果を出せるようにするもので、それをAggregatorと呼ばれるサイトに登録したり、パーソナルなRSS Readerで読んだりすることで利用する。RSS/Atomに拡張されたメタデータを組み込むことで、それを理解できるインターフェースと情報のやり取りをすることができる。

結果を取りまとめて１つのリストにするわけでもなく、別々に表示。ん～、Online RSS Readerかあ。
この先の展開は気になるところだけど。

ブログタイトルの意味

勿論、「ミイラにダンスを躍らせて」である。メトロポリタンミュージアム館長の回顧録。確か白水社から出版されている。
あらゆる手段を講じ、美術品を求め、商業、学術との狭間が興味深い。

純粋なテクノロジーを求めたい気持ちと、企業としての利潤の追求。そんな自身の生業をひっかけてみた。

Web1.0->Web2.0 パラダイムシフトと自社インフラ

たかだか１００人程度の会社なんだが、インフラの会合があった。
整備なりルールを作るという基本、今は確かに必要だろう。

ネットのあちら側、向こう側のリソース・データ・サービスを活用し、結合し、価値を生み出すWeb2.0。
ある意味、インフラの強化は、それこそ時代やトレンドに逆行しているような気もしはじめている。

大艦巨砲主義、昔の神聖なるＥＤＰ室、そんな匂いも感じるな。

例えば、自社にメールサーバが当たり前のように置かれるが、本当に必要なんだろうか？
gmail だって、いいんじゃないか？　
自社ドメインのメアドは、ある意味、「ないと恥ずかしい」というのも、あったけど、これからは、どうだろう？　「あちら側」のリソースをマッシュアップすることが、当然になろうとしている流れの中で、そこにしがみつく意味はどれくらいだろう？
勿論、結論を出すには慎重でありたいが、そんな発想の有無や柔軟さ、そもそも必要なの？という問いかけは、ユーザにソリューションを提供する資質、あるいは鍵になるかもしれない。