ドキュメント読もうぜ

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

さて、納入したプログラム（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 だって、いいんじゃないか？　
自社ドメインのメアドは、ある意味、「ないと恥ずかしい」というのも、あったけど、これからは、どうだろう？　「あちら側」のリソースをマッシュアップすることが、当然になろうとしている流れの中で、そこにしがみつく意味はどれくらいだろう？
勿論、結論を出すには慎重でありたいが、そんな発想の有無や柔軟さ、そもそも必要なの？という問いかけは、ユーザにソリューションを提供する資質、あるいは鍵になるかもしれない。