最終出社日

11/25が最終の出社日だった。退職は、12月末ではあるが。

11/23は、祝日だったが、11/25 から毎晩飲みだ。時間がないので、個々の送別が詰まっている。結局、最終出社以降にも２件の送別会を設けて下さる方がいた。

ありがたいことだ。

公式？の送別会って、出たくもないが、義理や立場上出ます・・なんて人がいたりして、言いたいこともいえないしｗやって欲しくもない。


つーか、会社の一斉の忘年会に出て来い、そこで、挨拶しろいう、とんでもない要請もあったりするｗついでにやってやる、とｗ

ひでぇよな・・ｗ

どうでもいいが、退職金の振りこみとか、遅らされたりすると、面倒なんでｗ

退職勧告に従う

日本時間w の11/22、退職の話に従う旨を、会社に返答した。

まあ、あんまりここで、グダグダやったところで、時間と体力の無駄。

次を考えたほうが、よほどいい。

最終出社は、11/25 。早いな・・しかしｗ

失業者・・か。このご時勢にｗ

退職勧告

いやぁ・・きたわ。退職勧告。
会社都合にするから辞めないか。
てか、辞めろｗ


笑ってるけどな。
もう、会社だめだなぁ・・と思っていて、潮時だろうなぁ・・と思っていたので、打ちのめされた感はない。
ないけど、動揺が、ゼロ・・かと言えば、嘘になるかｗ


幸いにして、このあとやることは、自分の中では決まっている。
少しばかり、早くなった、背中を運命が押してくれたのだと、ポジティブに考えることにしておく

プログラマ

世界最高齢の現役プログラマは、何歳なんだろう？

どうせだから、そんなもの目指してみようか。

ＩＴ会社に就職すると、数年プログラムを書くと、ＳＥと称せられ、設計をやり、ＰＬとなりＰＭとなり、管理に周り、営業支援技術やら、営業やらにシフトしていく。
管理職にまわっていく。


それが多くの日本のソフト会社じゃないかと思う。

そういう歩みを、オレも是としてきたんだけどな。

けどね・・もう、いいかな。

知るか、そんなもの。オレは管理書類、くだんらんドキュメントより、プログラムそのもののほうが、いいや。

UNIXに住む

自分も、立派なおじさんの年齢になっていると思うのですが、昔からUNIXに馴染んできたおじさんにとっては、UNIXは使うというより、「住む」という感覚で接しています。バリバリとコードを書いたり、O/Sをいじっていたのは、もう随分前になっているのに、未だにこの感覚は抜けません。たまにシェルのコマンドラインを叩いて、テキスト処理のパイプを、ズラズラとキレイにつなけげ、目的の結果が得られたりすると、正直、気持がいいです。

今の時代で、この感覚を持って、UNIXを使っている人は、それほどいないかもしれません。勿論、皆無ではないことは、わかっています。多くはありませんが、私よりも１０年以上若い世代で、研ぎ澄ましたUNIXグル、ウイザード達がいます。

そういう技術者には、特有の気配・・というか、匂いがします。たぶん、自分がそういうのが好きだからこそ、余計わかるのかもしれません。

さて、まだ、デザインをキチンと入れていませんが、UNIX LINUX専門の仕事情報サイトを立ち上げました。
http://unixwork.jp/

「人が見て見栄えがよい」は、後回し、最低限にしています。どうせ、OPENしてすぐ訪問者はいませんから。
まずは、テキストベースで、検索エンジンにクロールされ、インデクシングされることを狙っています。
デザインは、今週中にブラッシュアップすれば、十分、間に合うでしょう。

このアプローチは、一般のサイトの新規オープンにも使えることがあります。
事前にindex.htmlだけ、簡単でもいいので用意しておくことも、場合によっては有効でしょう。

更新停止

当分、このブログは更新しません。

内容的には、All About に書いていきますので、
そちらを見てやって下さいませ。

フォトコンテスト実績

会社の実績として明らかにしていいお客様というのは、そんなに多くない。
なかなか、ブログにも書けないのだが、今回は、大丈夫なので。

pbSTUDIOという、携帯とPCから写真応募を受け付け、審査や事務局の管理機能も提供するASPサービスをやっている。

http://www.atlas.jp/service/pbstudio/index.html

今回は、ノバルティス ファーマ（株）様に、お使いいただくことになった。

http://www.novartis.co.jp/campaign/photo2007/index.html

ASPとしての提供するので、システムはコンテスト期間中のみ、使っていただく。
同時に、システム運用や、システムでお預かりする個人情報のセキュリティの確保も含め、自分達の責任にて行う。実際、かなり気を使う。

葬儀の時の故人の撮影

pbSTUDIOについて、セッセとコラムを書いている。( AllAbout 向け)
カメラ付携帯で、簡単に応募できる写真コンテストのシステムなんだが。
実績やら想定事例やら、10/20から連続で１週間ほど出していく予定。

そのコラムを書きながらフト思い出した。東京の西のほうにある葬儀屋さんに行った時のこと。
サイト構築の話で行ったが、会社案内の時に、pbSTUDIOの話もしたら・・。
「最近の若いのは、葬式で、写メ、ってのとるんだよね、故人の・・。」
「そりゃあ、遺族の方は、いい気持ちされないですよねえ」
「難しいねえ」
「・・その写真コンテストって、やっぱまずいですよねえ」
「この業界（葬儀）も、どんどん変わってきて、新しい考え方も取り入れるべきとは思うんだがねえ、さすがに、まだ時代が早すぎるなあ。」
「いやあ・・時代が変わっても、そりゃ、ないでしょう」
「あんた、あいてい　とか仕事してるわりに、古い奴だね」

まだ、バカ話続いたが、このへんで。以上、葬儀社の専務さんとのお話。

５年後の未来

そんな未来でもないけどね。

今日の売り上げも大事だけどさ、５年後、みなと、笑っていたいわな。

自分の名前をググる

今までも時々やっていたのだが、上位に出てくるのは、千葉と奈良の造園の会社の同名の人でした。
コラム公開から半月、しっかりＴＯＰに出てくるようにはなった。

まあ実名と顔さらして・・・。誰かが言ってたなあ、「この業界、2chで、実名さらされて、一人前だよ。」う～ん、きっとうれしくないと思う。

AllAboutのコラム掲載開始->アクセス集計５日分

ソースにダンスを躍らせて: AllAboutのコラム掲載開始

8/30にOPEN、9/3 までのアクセス集計結果が出た。
５日間で、露出は670で500PV 。一日100PVか・・。
露出からＰＶへのつながりもそんなに悪くはないな。

９月で3000PVになるって感じかなあ。
立ち上がりとしては、上出来じゃないかしらん。

AllAboutのコラムはここ->

一応、毎日更新してます。

このサイトの値段は！ 2

如月乃庵: このサイトの値段は！で、2,400円だったけど、今日、3200円になった。（サイドメニューの右下）

800円単位であがっているなあ。
なぜ、800円？

更新できんぞ

AllAboutのコラムで、エネルギーとられてる。ブログまで、力がまわっておらん。

PMARKの更新申請も、バタバタで、今日やっとこさ。

AllAboutのコラム掲載開始

先ほど、AllAboutのコラムの公開を開始。
公開予定機能があるので、１週間分は、公開をスクジューリングした。

http://profile.allabout.co.jp/pf/terutakahashi/column/list/

さて、どうなることや。

セキュアプログラミング

WEB セキュアプログラミング

古くからEDPやシステム運用や開発をなされて来た方なら、驚かずに読んでいただけるでしょう。WEBシステム、携帯サイトのシステムというのは、本質的にかなりの危険を含んでいます。不特定多数の人間にＤＢの更新を伴うオペレーションを当たり前のように許可していますが、一昔前のシステムであれば、DBの更新などは、少なくともその組織の中の人間しかありえないと特定できましたが、今はそんなご時世ではありません。

セキィリティの問題は、運用するネットワークやサーバの管理者だけで解決できるものではありません。実は開発者サイドで留意しておくべきことがいくつかあります。ある程度の規模をもつシステム会社さんだと、ちゃんと意識して開発していらっしゃいますが、時々、社内の若い担当者が少しCGIの勉強をして作ったんじゃないだろうかと思えるようなサイトも見受けられます。
もしこれを読んでいる方の中に、サーバ運用担当、システム導入担当の方がいらっしゃいましたら、現在、管理しているサイトのプログラムについて、一度確認をされることをお勧めします。以下の項目は、言語に依存しない事項で、ソースを見なければわからないこともありますが、ブラウザからわかることもあります。

・入力データのチェックをクライアント側スクリプトに頼っていない。
　　　-->ユーザの利便性を求め、JavaScriptを多用するサイトで見受けます。
・全ての入力データからHTMLタグとなりうる文字「<」「>」を取り除いている。
　　　-->100% NGではありませんが、許可する場合は、
　　　　　相当な例外コードが必要です。
　　　　　意識して十分な予算と開発期間をとりましたか？
・HTMLにデータを埋め込む際には必ずHTMLエンコーディング
　　（「<」「>」「&」「"」「'」→「<」「>」「&」「"」「'」の置き換え）
　　　をしている。
　　　-->詳細仕様の議論の際に話題になければ
　　　　　省略されている可能性があります。
・保護が必要な全てのページにユーザ認証機構を組み込んでいる。
　　 -->WEBに不慣れなシステム会社が時々やります。
・事前に推定可能なセッションIDを用いていない。
　　　-->やはりWEBに不慣れなシステム会社が時々やります。
　　　　　また逆にWEBしか経験のないSOHO系のエンジニアが時々やります。
・重要なデータのキーをURLのクエリストリングで受け渡していない。
　　　-->100% NGではありませんが、やる場合は熟慮が必要です。
　　　　　弊社でも、他サイトのシステムとのI/Fのため
　　　　　（先方のミドルウエアの仕様）でやむを得ずやったことがありますが、
　　　　　最低限キーをジャミングする必要があります。
・hiddenフィールドでデータを受け渡していない。
　　　-->100% NGではありませんが、やむを得ずやる場合は、
　　　　　クライアントからの値を信用しないことを前提としたサーバサイドの
　　　　　コーディングが必要です。

このコラムでは割愛しますが、チェックすべき項目は、その他、ＤＢ周りのコーディング、それぞれの言語に依存した項目にも、重要な事柄があります。
IPAのガイドライン等には、一度は目を通し、開発パートナの選択や社内開発に際に、留意いただくべきかと思います。

サイト構築：ゴールのページはどこですか？

Google Ａnalytics をご存知の方は多いでしょう。無料で提供されているアクセス解析、トラッキング解析ツールです。もしご存知なければ、Google Ａnalyticsで、検索してみて下さい。
万能ではありませんが、なかなか優れものです。
これが無料で公開されるまで、私たちもアクセス解析の仕掛をお客様に提案してきていたのですが、実際に自分達で使ってみて、これだけのAPの構築と維持を続ける予算をお客様からいただくなら、サイトの他のこと（機能やサービス）に使ってもらったほうがメリットがあると考えています。利用するためには、各ページにJavaScriptを入れておく必要がありますが、WEB系の開発を行っている会社であれば技術的なハードルになりません。既存サイトのHTMLに入れていくとなると、ページの数だけ手間はかかりますが、リニューアルの際にあわせて行えば、わずかな費用で実現可能です。
Googleに統計情報でも把握させたくない、Googleを信用しきってはいけない社会的立場がある、というクリティカルな会社様や組織でない限り、お勧めしています。

そのGoogle Analitics の機能の中に、「コンヴァージョンの達成」の測定があります。サイトを訪れた方が、最期に何をして欲しいのか、最期にどこのページを見て欲しいのか、そこに至ることがコンヴァージョンの達成です。

サイトを構築する際、あるいはリニューアルの際、意識しておきたいのは、そのゴールページです。ゴールは、ひとつである必要はありません。
ECサイトであれば、商品の購入でしょう。販売サイトでなければ、資料請求やメルマガの購読申込、お問い合わせフォームで見込み客の情報登録をしてもらう・・などでしょう。すでに自社製品を購入された方に商品のメンテナンス情報をPDFで提供するからPDFのダウンロードをしてもらえればいい、という場合もあるでしょう。

ゴールが決まるといろいろなことが検討しやすくなります。
サイトのすべてのページは、そのゴールページへ行きやすくなっているでしょうか？
あるいは、PDFは単純なダウンロードだけでいいのでしょうか？　誰がダウンロードしてくれたかは、その後の営業フォローに役に立ちませんでしょうか？メールアドレスだけでも所得したほうがいいのではないでしょうか？

サイトの目的が販売であれば、売り上げ＝効果で、単純な効果測定ができます。しかしそうでない場合でも、サイトや投入したコンテンツは効果測定を行っていくことが重要です。
効果測定をしておかないと、次に投資するべき事柄、予算を使うべき優先順位は見えてきません。

一番ゴールにつながったページはどんなページだったでしょうか？
一番効果のないページはどんなページだったでしょうか？

今までの広告は、数、露出度が重要な要素でした。ＴＶでも電車の広告でも、あまりターゲットを絞れず、インプレッション（露出）の数や、絶対的刺激度で勝負してきたかと思います。広告を見る人は、自分に必要かどうかを選ぶことができず、とにかく興味があろうがなかろうが、目や耳に入るようになっています。
しかしWEBの場合、ユーザは、必要な情報を選択（検索）して閲覧します。必要でないことは目にふれさせることさえできませんが、必要としている・興味を持ってくれたユーザは、整理された見やすい情報であれば、ＴＶのＣＭ以上に熱心に見てもらえます。

WEBサイトをビジネスに役立たせるためには、いくつか持つべき手段がありますが、そのひとつがアクセス解析です。統計を得る手段は無料で使えるようになりました。解析の入口は、ゴールの確認と、そこに至るための効果的なページの認識です。

もっとも、アクセスや数値データで測れない事柄も存在します。
「社長挨拶」や「会社概要」がこれにあたりますが、仮に、どんなにアクセス数が少ないという結果が出ても、例外はありますが多くの企業の場合、省くべきでないのは自明かと思います。

AllAbout

AllAbout プロファイルにコラムを出すことになった。７月から話があって、ぼちぼち準備をしてきたが、9/1からいよいよ。

このブログは書きなぐり ^^;;だったが、AllAboutは、少しは丁寧に書かないとなあ。

AllAbout用の下書きも、このブログに一度UPすると思います。

OpenしたらURL貼っておきます。

携帯サイトを構築したい

携帯サイトを自らのビジネスに生かしたい。最近、地に足の着いた会社さんからも、そのようなお話をいただくことが多くなってきました。
１,２年前ですと、「これからは携帯だ」と、ハッキリしたビジネスの地盤、勝算やプランもないままで、携帯によって新しいビジネスにトライする、あるいは、新しいモノにすぐにチャレンジする体質の会社さんが多かったと思います。
ひどい話だと「今、サラリーマンなんだけど、辞めて携帯で儲けたいんだけど、何かいいアイデアない？」というような個人の方からの問い合わせもありました。

現在、そういった有る意味軽薄な騒ぎは終息しています。いよいよ本当にビジネスのツールとして、本業の強みをちゃんと持っている会社さんが、携帯サイトを手段として、地道ながら真剣に考えるようになってこられたと思います。

WEBでも携帯でも同じで、私たちが最初にお話をいただいた時に考えるのは、その会社様にとってサイトの構築の目的や目標は何だろうという点です。
ECの販売サイトであれば、比較的簡単な話で、集客し、商品を購入してもらうことがゴールです。その商品を買ってくれそうなターゲットについての仮説をたて、それにあわせたプロモーション、マーケティングの仕掛を実現するシステムにしていけばいいわけです。サラっと書きましたが、勿論、ケースバイケースでイロイロ課題はあります。

携帯サイトはＷＥＢサイトに比べ、いくつかの特質があります。
情報量の少なさ、文字入力の操作性の悪さ、にも関わらず、若年層に有効なアプローチ方法であるということなどです。
お客様のターゲットの年齢層が高い場合、あるいは個人を対象としていない会社である場合ですと、携帯サイトで何をするのかハッキリさせておかないと、無駄なシステム投資になりかねません。おそらくそういった会社ですと、携帯サイトの構築がそのまま売り上げに直結するかどうかは、疑問が残るでしょう。
しかし、そのような会社でも、若い世代へのリクルーティング、あるいは企業のイメージ戦略の一環として用いるのなら、有効な手段となるでしょう。

携帯サイト構築の重要性や、そこに期待する役割は、会社様によって様々です。
国内の自動車メーカのWEBの統括責任者のお話を伺ったことがあるのですが、
「WEBサイトのアクセスに比べ携帯でのアクセスは１０％に過ぎない」
「車を購入するため情報を欲しがる人にとっては、携帯の表現力では不足している。」
「今現在だけで言えば、携帯からのユーザはまったく重視していない。販売にはほとんど繋がっていない。」
「が、中期的には無視できない。携帯で企業のメッセージ、イメージを伝える努力はこれから重要になってくる。WEBの情報を携帯で出すのではなく、携帯を使うユーザに特化した別の情報を提供することで、効果がある。」
その一方、海外から若い女性向けの商品を並行輸入し販売している会社様ですと、
「携帯で売るのが一番大事。」
「WEBより携帯、ことに深夜のアクセスが非常に多い。」
と、携帯サイトには、積極的に投資をしておられます。

漠然とでも携帯サイトの構築をお考えでしたら、企画・検討段階でも一度お話させていただければと思います。場合によっては、「携帯サイトは、現段階では構築する価値が無い」というアドバイスになるかもしれません。携帯サイト構築の売り上げの多い会社としては、商売として困った話なのですが、「代わりに、こういったことをやりましょう。」というご提案ができるかもしれません。

WEBや携帯に限らず、システム構築の仕事は初期構築だけでは終わりません。長いお付き合いがすることが大事だと思っています。

インクリメンタルかウオータフォールか

どちらが優れているか、などと言う議論ではない。
杓子定規に、「どちらか」しかできないＳＥが、多いのは、困ったもんだ。

ウオターフォールを選択すべき時
・要求がかなり安定している
・設計が比較的単純、セオリーが確立されている。
・長期的な計画や予測が重要
・管理コストも含め、下流での変更が、極めて高くつく

インクリメンタルを選択すべき時
・要求が変化しやすい。要求を出す人さえ業務に精通していない。
・設計が複雑である、定型化されていない
・長期的な計画や予測は、プロジェクトにおいては重要ではない。
・下流での変更を吸収しやすいシカケがある。

プロジェクト推進の手法は、信念や宗教で選ぶべきではない。適切な手法を選ぶことも、ＰＭの腕のうちだ。

個人情報保護：郵便局で思ったこと

今年の初めに引越しをした。
距離にして数百メートルだが、イロイロ手続きをした中で、
郵便局にも転送願いを出した。
引越しの１週間ほど前、氏名、転送元と転送先を申込み用紙に書き、
窓口で提出した。

引越ししてみると、どうも転送されていない。
旧マンションのほうは、新しい入居者もきていないので、
管理人さんに相談してポストをあけさせてもらうと、
転送がされていないことが判明した。

これはマズイと転送願いを出した郵便局へ。
「いったいどうなっているの？書類受け取ったでしょ？」

申込み用紙はない。それは個人情報保護のため、
本局へ持っていってしまっている。と窓口で言われる。
ここには、控えもないのだ。

たしかに、個人情報は、存在するから守らねばならない。
存在しなければ、守る規則も組織も体制も省略できる。
窓口の局に置かず、本局に集中させるのが安心だ。効率がいい。
この郵便局のＰＭＳを決めた人は、いい方法と思ったことだろう・・。

顧客情報を営業マンが持ち歩けば、紛失のリスクがある。
守る立場からは、持たないことが望ましい。
でも、過去の自分の購入履歴や種々の情報を営業は知った上で、
自分に必要な、あるいは向いているサービスや商品を勧めて欲しい。
そうでなければ、ネットでたいていのものは手に入るわけで
営業という人間が介在する意味がなくなる。

勿論、企業の使命として、情報漏洩をさせないことは大事なことだが、
保護の名目で、顧客満足度を犠牲にする愚は避けたい。
先の郵便局の例でいえば、コピーとってファイリングして、
鍵のかかるロッカーなり金庫に保管しておく規則にしておけば
済むことだ。

個人情報を守ることは、企業として大事なことだが、
その企業・組織がが存在することの目的やサービスを
忘れちゃあ、どうしょもない。

PEPSIのバイラル手法

PEPSIコーラのサイトで、ゲームをクリアすると、コンプリートバナーがもらえる。
何となく、少しばかり得意になって、Blogに置いたりしたくなる。

広告費を払ってバナーを置いてもらうのではなくて、
一般の人に置いてみたいと思わせて、バナーを自己増殖させる。
バイラルマーケティングの実例として話に聞いたので、実物見てみたわけだが・・。
この際ですから、おれも、乗せられてみました。しっかりクリアしたので、バナーつけときます。
ゲームは単純なんだが、予想より奥が深く、楽しめた。バナーはわりと簡単にゲットできましたけどね。

でも・・俺はコーラは飲まないんだ。
そういう奴には、そもそも売り上げに効果のある広告ではないが、ジワリと認知度をあげる意味じゃあ、いいアプローチだよな。

個人情報保護と匿名性

個人情報を保護するということが世の流れで、その必要性を否定するつもりは、勿論ない。自分に関した情報が、ひとり歩きして、思わぬところで使われると思うと気持ちが悪い。もっとも、自分は、こうしてブログを書きつつ会社へのリンクも張っているわけで、やはりそれなりの決意のもと、個人情報に分類されることをさらし続けていて、気持悪いも何もないわけだが。。

P-MARKもちょっと前は、所持していなくても仕事になった。が、今ではそうはいかない。取引前に当たり前に確認される。ECサイトのサーバを預かるデータセンターなども、「個人情報を利用する」事業者ではないからP-MARKの必要性はないのかもしれないが、自分達が「このセンターを利用してはどうですか」と顧客に提案する際は具合が悪い。

守るが大事であることは論を待たないが、中途半端な解釈や理解で、行き過ぎた話も耳にするようになってきた。出すことが当然なのに、出せませんという例は、時々ニュースで聞いた。

話が少し飛ぶが、飛騨の有る村の家では、子供達が中学校にはいると表札にその旨が書き加えられる。例えば「ＸＸ中学校１年１組高橋太郎」と、ご主人、奥さんの左に書かれる。これのネタ元は、司馬遼太郎さんの「街道をゆく」の飛騨の話。連載は1986年だ。個人情報保護の観点からは、とんでもない話として、嘲りをうけそうな話だが、それなりの理由がある。

14才で元服・成人という時代があって、武士でなくても、14才は大人として扱われていた。武士は明治時代になってなくなったが、その精神は残った。
自分の名前、所属する組織（学校）を出してもらえることで、大人と見なすよと悟らせ、かつ、そこには、「名を惜しめ」「匿名でない自分の名前で責任をもって行動しろ」という意識が息づいている習慣だ。

保護という大義で担保される匿名性を前提に、無責任な言動をする人が本当に多いと思う。勿論、内部告発など、匿名ゆえに、言える事、書けることもあるだろうし、匿名すべてが悪いとは言わない。

バランスが大事なんだが、世のコモンセンスとして、どこが均衡点になるのかは、もう少し時間が必要だと思う。が、IT業界の真ん中の開発会社としては、世の中庸が定まるのは待ってられない。１００％の正解は誰にも出せないだろうが、「外さない」を担保するためには、やはり関心をもって学んでいきたいと思う。

LINUXとUNIXの思想2

UNIXの原点の思想について。覚書２

・ASCIIをもって尊しとする
　データの保存は、原則アスキーファイルする。そのＪＯＢに特化したバイナリデータは避ける。組み合わせることを前提とし、効率より移植性を大事にしていけば、出てくる結論は、ASCIIだ。　ここにはデータに対する哲学が含まれる。動かせない、再利用できないデータは死んでいる。特定の何か（人、アプリ）でしか扱えないデータであるとすれば、それはデータを人質にとられている。処理速度の問題？まあね、でも、それ、来年にはもっと早いマシンになってるんだぜ。


・使えるものは使う。作ったものは使い倒す。
　小さく、組み合わせのしやすさに重きをおいた。勿論、それは自分のコードだけではなく人のコードも、組み合わせて使う。自分のコードも使わせる。UNIXのソースコードは無料で配布されていた。秘密にしておく価値があるのか？

・データをしゃぶる、使いまわす。紙に出さない
　紙に出たデータはそこが終着だ。再利用には極めてコストがかかる。検索もできない、暗号化もできない。そのデータは死んでいる。紙に書くな、書くエネルギがあるならASCII入力してしまえ。
　
・１０％の努力で９０％の問題を解決する
　人の生き死にや、銀行口座のシステムで無い限り、９０％の問題に対応すれば十分なことが多い。残りの１０％を満たすためには、それまでの１０倍のリソース、コストを投入しなければならない。
　

LINUX UNIXの思想 １

言うまでもなくLAMP,LAPPの L は、Linuxだ。
若いエンジニアが 2w3w で訪れてくる時、あるは、社員採用に応募してくるサーバ￥ネットワーク系の技術者から、こんな話あった。「Linuxは自信あります。けどUNIXになるとちょっと・・」

おいおい。
勿論、/etcやらのconfig関係は、ずいぶん変わってきているのは事実だ。最近のSOLARIS10は、従来の定番の管理手法が通用しないという泣き言も聞いている（というか、俺も泣きたい）。
まあ事実ではあるな。

で、質問してみる。
「LINUXでも、HP-UXでもSOLARISでも、共通している考え方、原点の思想ってあるんだが、それはわかるかい？」「最初にUNIXを作った人の考え方とか、使いながら考えたり、体感したことあるかい？」
細かいパラメータの違いは各O/Sにあるのは事実だけど、そんなものをたくさん丸暗記したってしょうがない。いつか変わる。そうじゃなく、変わらない思想や考え方が身についているかなあと、たしかめてみている。何とかなりそうだなあと思える人は半分くらいかな。

いくつかのポイントを書いておく。
文中のUNIXはLINUXと読みかえても差し支えない。

・スモールイズビューティフル
　カーネルも、シェルも、各種コマンドも。小さいからわかりやすい、組み合わせしやすい。組み合わせなんて、今でこそコンポーネントが当たり前だけど、当時としては画期的。

・ひとつのことをキチンとやる
　組み合わせすることを前提とすれば、ひとつのことだけ、きちんとできればいい。ひとつのことのレスポンシビリティを保証すればいい。
　クラス設計をする時に避けるべきことに、何でもやっちゃうウルトラなクラスを作らない。先の小さいことはいいことだとあわせ、これは今でも設計開発に通用する原則だ。（不慣れだとついやっちゃうんだよな）

・さっさと試作する
　勿論、これは機能仕様や要求の整理の重要性を否定するものではない。しかし、聞いても、事前に調べても、埋められないことがある。その時には、ちゃっちゃとプロト・サンプコードを書いて、リスクを減らしてしまう。UNIXそのものには、設計書は存在しない。簡単な機能メモは作られたかもしれない。現在、書店に行けば、山ほどのUNIXの仕様について書かれた本がある。しかし、それらはできあがってから書かれたものだ。UNIXそのものの開発プロセスが、レガシーなウォターフォールを排斥して進められてきている。

・実行速度より移植性
　UNIXそのもの開発者の頃でも、「来年にはマシンの性能は、Ｘ倍になる」と言われていた。チューニングなんて意味がない。基本のアルゴリズムがダメダメで、あまりにムダなことをやっているコードや、腐ったSQLの話は別だが。繰り返し使われ、コールされる回数の多いサブルーチンは、チューンする価値はある。
　最も効率のよいコードは、移植性を犠牲にする。あるいは、もっとも、ユーザインターフェースに優れたコードは移植性を犠牲にする。後の話は最近の携帯電話での開発の余談だ。機種独自機能を使えば、１年後は大変だ。

まあ、HP-UXや今のSOLARISに、原点の思想がどこまで残っているの？は、議論の余地があるのは承知しております。
「変わり果てたからこそ、Linuxだけに原点が生きているんだ」という、よくわかっているグルやウイザードの方々には、私ごときは逆らいません。逆らいませんから色紙にサイン下さい。

PHPフレームワーク Ethna(エスナ)

PHP5用のフレームワーク。今回、初めて仕事に使用してみている。規模は２人月。暫定サービスインは、7/13で、その頃には、結論も出せるだろう。

他のフレムワークと比べて、勿論いいところもあるし、足りないところもあるが、メンテをする人が日本であることが嬉しい。サイトはここ->
画面系がsmartyを前提としているあたりも、敷居が低い。

strutsに構造が近く、Mojaviの人にも、似ていると受けとられている。何より、見通しがいいと思わせてくれている。

PHPフレームワーク phrameとMojavi

phrame は、Strutsの設計思想を継承していて、JAVA/Struts 環境から移行してきたプログラマには、習得の面では、非常に魅力的だと思う。開発する組織・会社で、JAVA/PHPのプログラマが兼務することが多いような場合であれば、教育コストを考えると、悪くない選だと思う。しかし、JAVAとPHPの言語仕様が違う現実の中、PHP用フレームワークとして「最適」と断言するには少し無理があると思う。
調査程度はやったが、実プロジェクトには使っていないので、このへんで。

Mojaviは、非常にシンプルなフレームワークだが、PHP用に作られたが故に、フレームワークのもつ共通のメリットの他に、いくつかの優れた特徴を持っている。

Mojaviを使っているチームや組織も多いでしょう。実際、うちの会社でも、ここ何年か、使ってきた。

PHP5を前提としたフレームワーク

「低コストで短い期間で・・」どのようなシステムでもそうだ。社会の要請といってもいい。
特に、Web・携帯アプリケーション開発に対する要望は、よりシビアな昨今だ。
答えのひとつがフレームワークの活用だが、現在MVCモデリングが主流となっている。
フレームワークのメリットは大きく２点ある。
・MVCに代表されるデザインとビジネスロジックの分離による保守性・生産性の向上
・フレームワークというルールに則って実装することによるコードの均一化、品質の向上
などなど、今となってはわかりきったことだが、Windows プラットフォームでは、.NET 、JAVAプラットフォームではStrutsが、事実上のスタンダートとなり、多くのプロジェクトで使われてきた。

その中で、PHPにはデファクトスタンダードと言い切れるフレームワークがない。
PHP4の成功による裾野の広がりから、その状況が変わってきているが、まだ試行錯誤と言えるだろう。
phrame 、Mojavi、 Ethna が気になるところだ。

PHPの歴史 PHP5の優位性

PHP5は、それ以前のバージョンとは、多くの点が改良されている。PHP4の基本的な文法は、Zend Engineと呼ばれるスクリプトエンジンだった。PHP5が多く使われ出している今となっては、異論も多いが、当時としては、洗練された構造かつ容易に拡張可能な言語エンジンとして優れていると言える。これはそれまで、*場当たり*的な拡張を繰り返してきたPHP3に対する反省と要望の賜物だろう。

Zend Engineは、PHP4を成功に導いた。そのため利用用途もより広範囲・大規模になり、エンタープライズ用途にPHPを利用する・・・という、ある意味冒険的な構築も行われた。（当時の僕なら、そんな選択はできなかったかもしれない。）

こういう利用は、Zend Engineの開発者達の想定を越えた広がりだったと思う。当たり前のことだが、大規模サイトを構築する際のコードの再利用性の悪さといった問題を呼んだ。
技術面か、最も問題視されたのは、PHP4のオブジェクト指向機能の弱さで、JavaやC++に慣れたプログラマからは、不満が多く寄せられ抵抗された。

もちろん、PHP4でもオブジェクト指向機能を徐々に加え改善され続けてきた。世の中にはオブジェクト指向COBOLだってあるんだ。付け加えることぐらいは、できるわな。
しかし、基本的なZend Engineの文法を大きく変更することまではできない。そうなると開発者達それぞれが、職人的努力と技量で、PHPなりの記述方法を新たに開拓し、目的を達成しようとした。
努力は涙ぐましい・・。でも、それに変わる処理系がなかったんだよなあ。
職人のような努力をすればするほど、（目的のシステムはできるけれど）、わかりにくコード群になるわなあ。保守性を切り捨てることになる。

さてPHP5は、これらの問題に、抜本的な解決を与えるために作成された。
各種extensionの対応やPEAR、クラスフレームワークの新機能への対応など、JAVA C++の経験者には、「便利」「再利用性高まった」と思える機能も、PHP3やPHP4*だけ*に慣れたプログラマにとっては、敷居が高くなったとも、考えるべき要素が増えたとも、いえる。

PHP5のもつヨサを生かすには、プログラマーやチームに、スキルが要求される。
僕は、2005-2006年、WEBとIP電話の交換機(PBX)の繋ぎこみゲートウエー構築プロジェクトに、PHP5を選択した。従来であればJAVAまたC++を選んでいただろうが。

他システムとのI/Fすりあわせ等、言語そのものとは無関係の苦労が多いプロジェクトではあったが、PHP5によるコンストラクションそのものや、その後の運用(かれこれ１年）には、何ら問題はなかった。

PHP5でやらせて

LAPP,LAMPの話の場合、つまりほとんどのWEB系開発の場合、特別の事情や制限が無い限りPHP5を使わせてもらいたいとお願いしている。

過去あった特別な事情とは、

・既存サイトがPHP3 PHP4 で作成されおり、プログラム資産の継承が重要な場合。
・利用しているIDCのサービスが、PHP4の利用しかできない場合。
・お客様が、Perlがどうしても好きな場合
・製品版のJVM を用意する予算が有る場合(tomcat はお勧めしない）
・既存のサーバがWINDOWSベースなので、.NetASPでの構築が自然な場合

LAMP LAPP

WEBや携帯サイトの構築において、LAMPあるいはLAPPでの開発のメリットは広く知られるようになり、問い合わせをいただく場合も、それを前提としていることが多い。
実際の受注も、バージョンの差異はあるものの、基本的にこの組み合わせで落ち着く。

LAMP Linux Apache Mysql Php
LAPP Linux Apache Postgresql Php

これは、無償ライセンスでありながら、
・Linux + Apacheの組み合わせの実績、
・大半のWebサイトには必要十分な機能を提供できるMysql Postgresqlの機能
・Java(Tomocat等)よりも軽く安定したPHPの実行エンジン
等が実績として評価されてきたことによるのだと思う。

重宝されているLAPP LAMP ではあるものの、APの規模が大きくなり開発に従事するメンバーが増えてくると、それなりに種々の課題・問題が産まれる。これは別に、LAPP,LAMPに限った話ではないが、LAPP,LAMPも、やはりそれらの課題からは免れない。すべての問題を解決する魔法の手法ではない。
小さな話であれば、品質には大きな影響はなく、やっつけてしまえるものの、規模がある際は、当たり前のシステム構築の手法を積み重ねていく必要がある。

オブジェクト指向 のメリット まとめ

ユーザー・クライアントは、何らかの問題・課題を解決したいが故に、システムを構築する。
オブジェクト指向は、その問題領域の要望・要求の構造と振る舞いを、オブジェクト群とそれらの連携（協調）で、モデル化することができる。
システムのデザイン・設計とそのアーキテクチャも、オブジェクトとそれらの連携
コンストラクションの単位もオブジェクト
再利用・部品化・共通化の単位もオブジェクト。
ユーザの業務から実装まで、オブジェクトという考え方で、トレース可能なものにできる。

ユーザ・クライアントの基本的な考え（コンセプト・ビジネスモデル・ワークフロー）を、抽象化して計算機に入れてしまう。ユーザ・クライアントの心、気持ちを、忠実にシステムに反映させる。

オブジェクトは、極めてカプセル化され自立している。そのオブジェクトに機能が不足している場合、継承で新しいオブジェクトを作る、隣に別のオブジェクトを作りメッセージで繋ぐなどができる。

カプセル化により、中をどうしようと、システム全体としては、問題にならない。オブジェクトの外側のI/Fはそのままにしておき、アルゴリズムを変える、チューンする。I/Fが一緒の別のオブジェクトと入れ替える。

業務から実装までトレース可能なオブジェクト指向だか、その記述に使われるのがUML。

クラス図だけとは言わず、入り口から使用しないと、ありがたみが減ずる。

コンストラクション（設計・プログラミング）の準備

顧客に言われて、いきなりコーディングをするような仕事は、まあ、ほとんどない。コンストラクションにかかる前に、準備がどうしても必要だ。いわゆる上流工程だ。
イテレート、インクリメンタルの開発手法をとるにしても、この上流の重要度は変わらない。
今の仕事の情況では、20-80 が目安だと思っている。すなわち、プロジェクトに関わる総エネルギーの20%を費やして、80%の要求を洗い出し確定させる。
少なくとも、PMが「要求と設計は、かなり精査した。コーディングやデバックで致命的な問題は出ないだろう」と確信できるまで、コンストラクションにかかるべきではない。

もっともこれは、それまでに１行のソースも１個のクラスも作らないと言っているのではない。特に新しい技術要素を利用する場合は、準備段階での、サンプル・プロトによる評価は必須となる。

WEBブラズザベースの構築では、要求を確認するため、HTMLで紙芝居をつくり、クライアントと画面遷移を握っておくと、ほとんどの問題は潰れる。
他システムとのI/Fがあるなら、何より、実際のデータ（サンプル）を求める。設計だけでは、わからないことがある。

順番としては
課題・問題の定義(ゴール設定) ->要求仕様 ->アーキテクチャ確立->コンストラクションとなる。

関連する参考書としては、PMBOKガイドは一読しておきたい。2005年版は2000年版の１．５倍だが、書棚に持っておくべき。

アマゾン->プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project Management Body Of Knowledge

開発手法・プロジェクト管理手法

いくつかの本を読んではきたが、大半の手法が、排他的な姿勢だ。
つまり、この手法以外じゃ、失敗しますよ、これが絶対普遍の真理ですよ、あなたは神を信じなさい。

ハッキリ例外だったのは、XPだった。「使うべきではない」ケースをしっかりうたっている。

腕のいい大工は、その仕事にふさわしい道具を知っている。
腕のいいプログラマは、その案件にふさわしい言語を選ぶ。

官公庁相手の仕事であれば、仕事をしたことを証明するために、多くのドキュメントが必要だ。しかし、３ヶ月のキャンペーンで、使い捨てにするWEBサイトであれば、ドキュメント云々より、その間、動向を見ながら、走りながら治していくことが大事だ。

チームのあり方、プロジェクトの進め方を、一律のモノサシで測ることはできない。

プログラミングの例え4 システムを構築する

システムを構築する。建設をイメージできると思うが、このメタファが一番自然に思える。

小さい工事、それこそ、家の壁に、棚をつけろと女房に言われたなら、ちょっとした採寸とメモで、材料を買って、製造に取り掛かれる。
けれど、セルフビルドでも、家を建てましょうとなると、綿密な計画、プランが必要になる。
ましてや、ビルでも建てるとなれば、家の比ではない。

システム構築は、その規模や目的によって、採用するべき手法が異なる。

情報を見せるだけのWEBサイトと、決済、取引を伴うサイトを同列に扱うことはできない。
２０ページの企業情報を乗せたいサイト構築と１０万ページのコンテンツをもつサイト構築を進めるのに、同じ手法は使えない。

プログラミングの例え 3 アクリエーションする

システムをアクリエーションする。

こういうメタファも使われだしているようだ。

ほんと、メタファ好きだよな

真珠養殖ということなんだが・・。

母の貝が、じわじわと真珠を大きくしていく姿は、イテレート、インクリメント開発に、イメージが近い・・そうだ。

チームの構成員が真珠養殖を良く知らないと、このメタファの使用は無理がある。

プログラミングの例え2 システムを育てる

クライアントさんのシステム担当が、愛情をもっている場合、「育てる」といいたい気持ちもわかる。
いきなり最終目的に行こうとあせるクライアントに「システムは育てるもんですよ」と言ったことも確かにある。

新しい処理系をモノにしようとする場合、hellow worldから、コードを増やしていく。

インクリメンタル、イテレートのプロジェクトにも、当てはまりそうだ。

しかし、まあ、「育てる」と最初に言い出した本人（例のごとくメタファ好きの西洋人だが）は、農場をイメージしていたらしい。秋になるとコードを収穫する・・。う～ん。そうなるとちょっとね。

プログラミングの例え 1 コード（ソース）を書く

コード（ソース）を書く
　ひとつ捨てるつもりで。どうせ書き直すことになる。（Fred Brooks)
ひとつ捨てるつもりだったら２つ捨てることになる(Craig Zerouni)

　書くという比喩、メタファは、プログラムに合っているのか？

　自分ひとりでできる分量をプログラミングして、稼動させるなら違和感はない。
　ひとりの作品として、書く、著述するで、いいかもしれない。

書くとは、オリジナリティが伴う。ソフトウエアは完全にオリジナルだろうか？フレームワークに乗って、クラスライブラリを組み合わせて、他のサイトのサービスを利用して、目的を達するシステムを作ることを、書くというには、無理があるんじゃないかなあ。

　ないものは全て作る、すべて書くという、古の伝説のプログラマ達であれば、「書く」もいいだろう。

　だいち、もう、１人でやる仕事なんて、ほとんどない。

メタファ好き

チームでプロジェクトを進めるとき、メタファの良し悪しが、システム分析やデザインを共有する際、大事だったりする。問題領域を共有するような時にも有効なテクだ。

XPでも、重視してるし、CodeComlete なんかでも。

そういや、新約聖書のキリストの話は、例え話が多く、考えようによっては、メタファだよな。
釈尊は、「こんなことがあった」式だったと思う。（すこし記憶あいまい）

西洋人は、メタファが好きなのか？
抽象化、モデル化って、彼らの民族的なバックエンドにあるのかなあ。
日本人の「恥」の文化みたいに、彼らは子供の頃から、無意識にモデリングをやってるのかしらん。

別に、洋物の技術書を、「舶来物」ありがたく拝する世代ではないつもりだが、けっこう名著、古典って、日本人の書いたもの、少ないよなあ。

支払いサイト

うちの支払いサイトは、月末で締めて、翌月末に現金振込みにしている。
個人事業主、あるいは、一人会社さんを相手にしていると、時々、いろいろな相談がある。
このあたりは、社長が苦労人？で、資金繰りの切ない時代もあって理解があり、事情に応じて、できるだけの融通はお願いしやすい。
とはいえ、頼まれてもダメな例、断る例もある。

ＯＫした例
「今回の請求分*だけ*、３０日後ではなく、早めにお願いできないか。」
毎回のことじゃないし、もうすでに、その月の成果物収めてるし、たいていの場合、ＯＫしてます。

ＮＧの例
「毎月の支払いサイトを３０日ではなく、１５日でやって欲しい」
これは、ダメ。取引条件は、原則一律だし、例外的にその時だけのイレギュラー対応ならともかく、常態にするわけにはいかない。

常連と一見 エステサロンの噂話

お茶を飲みながら、隣の女性二人から、聞くともなく聞いてしまった話。

「ＸＸＸＸってさ、最近、雑誌だかに、でちゃったらしくてえ、な～んか変な客増えたのよね」
「そうそう、それがもう、偉そうでさあ、何様だと思ってるのよ」
「あたしなんか、怒られちゃったわよ。うるさいです、とか。なんで、初めてきた子供に、そんなこと言われなきゃいけないのよ。店員に言ってやったわよ、怒られちゃったんですけどおって。そしたら次行った時、オーナが出てきて、すいませ～ん、って。」
「まあ、そのうちまた静かになるといいんだけど」
「静かにならなかったら、回数券がなくなった、もう行かないわよ」

さて・・。
来客が増えれば、とりあえずに売り上げが増えて、店はうれしいわな。
でも、それだけじゃ、割り切れないこともある。

老舗の食料品を扱う店が、全国展開をして、売り上げは伸びたけど、味が落ちて、常連が離れる。
味が落ちないまでも、希少性が薄れ、誇りを失う。
職人は辞めていき、生産ラインの工員は残る。
モノの維持はなんとかできても、次の発展のコアは、もうない。

de マーケティング。
ブランドだと、製品そのものの工業的価値より高い値段をつける。
単体の利益より、その値段でもいいという人レイヤーの人しか客になって欲しくない。
夢？虚栄心？満足感？そういったものを売るわけだし。

銀座の飲み屋も高いよなあ（笑

業態、業種、そしてターゲットによって、価格設定、ＰＲの範囲、適正な業務規模ってあるんだろうな。
商売をする以上、拡大、成長することを否定するわけじゃない。
だが不自然なことは、自分たちの強みを捨て、成長の原動力を損なうことを、忘れずにいたい。

ディズニーランド

楽しませつつ何かを見せる手本として、ディズニーランドは優秀だ。
１０年以上前、美術館の学芸員さんから聞いた。
当時は、美術品をヨク見せるという観点からの見識で、それは留意してみていた。

WEBの導線、プラニングの立場から、やはりディズニーランドは参考になると、最近聞いた。
人の誘導の仕方、待っている間も楽しみに変える工夫。
インタラクティブなWEBプラニングするなら、ぜひ、その視点から見ておくべき、と。

おじさん一人で行くのも、職場の野郎どもと一緒にいくのもイヤなので、家内と行ってこよう。

会社法の改正

昨年、会社法が、改正・施行されている。

一人でも、資本金が少なくても、株式会社を作ることができる。
まあ、内容的には、有限会社とか合名会社と同等なんだが。

個人事業主を、主に対象としていたが、そういう法人さんからの問い合わせも出てきている。
「法人でもいいですか。」

勿論、かまわない。
自立して、独立して、社長になるってのも、ひとつの夢として悪くないことだし。

だけど、会社にした以上は、資金繰りでの泣き言、タマにはいいけど、毎月はしないでね。
一応、うちは、当月末締め、翌月末、現金振込みで、そんなに悪い取引条件じゃないんだから。

ヤン・アルチュス=ベルトラン写真展 空から見た地球

展覧会・美術館・独り言: ヤン・アルチュス=ベルトラン写真展 空から見た地球

フジフィルムのやっている、ショールムでの展示会。
１訪問者として楽しめました。

WEBで、B2Cのモデルを考えたとき、企業が伝えたいメッセージを、そのまま出したんじゃ、カスタマーには拒否される。

今回で言えば、「写真すごいでしょ、富士フィルムの技術は優秀です。」
でも、それを書いた、コンテンツなり展示なりしたところで、面白くないと、メッセージを伝える前に、来てくれない、立ち去ってしまう。

苦い薬・メッセージを飲ませるため、非常に楽しい展覧会、コンテンツを用意して、メッセージをすべりこませる。

WEBの企画を考えるとき、企業側のゴールのメッセージ、あるいはアクションを規定して、それを達するためのコンテンツを考えるアプローチは、有効だなあと思わせる展覧会だった。

NOVA コムスン

おさがわせ中の２社の社長
事業をする人間として、持っている才覚、嗅覚、エネルギー。
僕などよりも、１段も、２段も優れた人たちなんだろうと思う。

何かを間違えた。
たまたま運が悪く失敗したではなく、何かを勘違いしている。

その何かを、うまく説明できないんだが、誠実とか正直とか、まっとうとか。
法律には触れないけど・・で儲けるなんてことは、もしかしたらバブルの頃は、それでも良かったのかもしれない。
だが、これだけネットが使われ、バズ・コミュが無視できない以上、最後にモノを言うのは、本物かどうか、そして、本物であることを知ってもらう健全な努力だと思う。

年金問い合わせのフリーダイヤル

朝日新聞から。
問い合わせが殺到し、派遣会社からオペレータを増員して対応しているが、ロクに訓練もできず、「すいません、数日経ってから、おかけ直しください。」と、答えさせているそうな。

まあ訓練、教育のできたオペレータを、急に大量に用意できない現実はわかる。
回答するためのコンピュターの端末も足りないから、調べることもできないってのも、たしかに現実だろう。

けどね、ＣＳからいやあ、最悪だよ。

せめてさ、連絡先を聞き出して、「担当からあらためてご連絡させていただきます。混雑しておりますので、ご連絡に１週間ほど、かかるかもしれませんが、ご容赦ください」とか言えよ。
受付番号をお伝えして、紙でもいいじゃん、記録して、本当の職員が、順番に電話していけよ。
とりあえず、あやまっておけばいいから、みたいな人の使い方は、どうしょもないなあ。

客商売だったら、当たり前のことが、どうしてできないんだろうなあ。

B2B2C Valueエクスチェンジ

B2B2CのWEBサイト。

2w3wもサイトだけでとらえると、そう分類できるかもしれない。

B2B2Cの場合、企業と個人とで求めるものが違い。そこをうまく変換することが、サービス提供者のモデルやプラン作成になってくるわけだが。

2w3wの場合はどうだろうと振り返る。
技術者の要望と、企業のニーズと、本質的は相容れないものかもしれない。
サービスを提供する僕たちは、そこをうまく変換できないといけない。だが、事実や現実を不自然に捻じ曲げるのではなく、事実を正視し、現実の「おとしどころ」、「にぎれる」ところを模索する。

エクスチェンジというより、ネゴシエートで、本質はWEBやテクノロジーの枠内で納まることではない。

いろいろな事情

こないだ来た人の話。

ネットワークやサーバーのキッティング・セットアップができる。
家には１０台のＰＣを持ち、３台のサーバで遊んでいる。

ずっと、この業界で仕事をしてきた。が、家の事情もあり、いよいよ医者にならなきゃいけない。単価はどうでもいい。ただ、勉強する時間がとれる仕事を探している。

自社の受託案件では、マッチする業務はない。
開発だと、どうしても期限・納期が迫ると、稼動は長時間になるからなあ。

オーバスキルだけど、単価について妥協の余地があるということなので、ヘルプデスク、オペレーション、サーバーキッティングの業務を中心に探してみることに。

納豆チョコレート

今年に入ってからだが、身近な人、客先現場にいる人の誕生日に本を贈ることにしている。
大半が、技術書。
Code Complete とか、ソフトウエア職人気質とか。以前書いた古典的技術書にリストされているような本。
相手によっては、ビジネス書だったりもする。

客先に行っている人にメールした。
「誕生日おめでとう。プレゼントに、ＸＸＸＸという本を贈ろうと思うんだが、読んだことあるかい？」
返事
「覚えていてくれてありがとうございます。もらえるもんは、何でももらいます。珍しいお菓子とか・・あと、珍しいお菓子とか。ジンギスカンキャラメルは駄目です。」

どうやら、技術書より、珍しいお菓子がほしいらしい・・。

わかったよ、技術書も送るけど、珍しいお菓子も用意するよ。
で、水戸に行く用事があったので、常磐道の友部ＳＡで、「納豆チョコレート クローブ風味」をＧＥＴした。

人には、勧めません。

年間８５万台

どうでも、いいっちゃあ、どうでもいいが。
イギリスでは、年間８５万台の携帯電話がトイレに落ちているそうだ。

ちょっと信じがたい数字ではあるが、人口に対してだと、1.5%。
１００人の会社なり組織なら、１人ないし２人か。
そう考えるとそれぐらいは、いるような気がしてきた。

僕は一度落として以降、首にかけてるし、アドレスデータも対応するようにした。
アドレスは、ＰＣが正で携帯がサブセット。機種変でも、それほど苦労しなくていい。

どうでも、いいっちゃあ、どうでもいいけど、８５万件がインパクトあったので。

モバイルサイト

ある上場企業（製造業）の話。

毎月100万人のユニークユーザが企業サイトを訪れる。コンテンツは10万ページ。
今は、90%がPCで、モバイルは10%に満たない。
だが、この状況は、２,３年で変わるだろう。
今は、「モバイルサイトを作らねば」ではない。しかし、もう無視できない時が、確実に来る。

コンテンツの質も大事なことだが、まず量も、企業サイトにとって重要な問題となる。
必要とされる情報はロングテールまで。維持のインフラコストは、問題にならないのだから。

あとは、コンテンツを効率よく増やしていく仕掛け。システムと体制。
今から、これを準備しておくか否かは、大きな差になるだろう。

一方、その時に、現在の３キャリア別のタグなんてシカケが残っているだろうか？
流れは、フルブラウザと思っているのだが。

WEB・ネットのパイ

例えば、yahooでも、昨年ぐらいから、サイトを利用するユニークユーザの数は3800万程度と推定され、頭打ちになっているという。
もうネットを使う人そのものの増加は多くは望めず、パイの取り合いになった。
ま、人口自体が減っていくわけで、無理からぬ話ではあると思う。

企業のWEBサイトそのものの意味・意義が変わってきている。ある一定以上のアクセスのあるサイトであれば、それこそ、リサーチ会社を不要としてしまう。そのサイトそのものが、マスメディアに近い力を持つ。
自らがメディア足りうる時代になった。宣伝・広報の媒体の利用方法が変わる。

僕らの提案や営業が、顧客のビジンスの成功を意識した時、ともに考えるべき事柄として避けて通れない。
また、そこに営業的な勝機を感じている。

WEB広告営業職セミナー

株式会社宣伝会議のやっているWEB広告営業職セミナーに行くことにした。

自分の経歴からすれば、異分野ではあるが、ここ数年、必要性を感じていた。

システム構築の話で、顧客と話をしている中で、サイトを知ってもらう、収益をあげることについて、ちゃんと話を理解して、それなりの話ができないといけないなあと。また、広告も含めて提案できれば、顧客にとっての利便も図れだろうし、ビジネス拡大のチャンスにもなる。

ただ「プログラムが書ける会社です」だけじゃあ、生きていくのが難しくなるかもしれない(笑　という危機感もあるしね。
６月６日から１０回。水曜日の夕方からミッチリと。
まあ、基本的に、「知らないことを知る」喜びってのは、エンジニア出自の特質かもしれないので、楽しみにはしてるけどね。

会社は誰のもの

日経新聞のネタ。

内部統制が需要になってきたが、内部統制を進めるのは何のため？そりゃあ、会社のためだ、と。じゃあその会社って、誰のモノなのかしらん。そいつを考えましょうや、考えとかないと、内部統制進めようとしたところで、うまくはいきやせんぜ、と。

法学と経済学と経営学の立場からのコメント

法律、商法等では、会社は、株主のもの・・になる。そりゃそうだ、と。
経済学の立場から、資本の有効な活用、経済発展の寄与等から、株主のものと考えるのが妥当・・だそうだ。（オレは専門家じゃないので、コメントできん）
経営学の立場からは、上記を踏まえて、会社の存続には、それ以上の意義を経営者は持たねばならないとする。株主だけのもの・・とはいえない。
その日の記事は、そこまで（続く）

日々の日銭稼ぎに追われているけど、考えておかないとなあ。

ベッカー「人的資本」

経済学の名著だそうだが、それはおいといて。
企業が社員を教育する時、そこにはコストがかかる。そのコストの負担を、どこに求めるのかという洞察が面白い。
会社がもつの？個人がもつの？

これを考えるときに、汎用性のある教育と特殊性（その企業特有の）教育とをベッカーさんは、別けて考えている。

汎用性のある訓練、教育によって人的資本の価値をあげる際、教育投資とそれを回収する期間を考えれば、長期雇用できることが、企業側として必須条件となる。要するに教育に使った金の分、働いてね、と。

逆に、特殊なその企業でしか通用しない知識の場合、ヨソでは通用しない知識であれば、従業員にとっては、長期間働けるという保証がないなら、特殊な教育を受けるべきではない。従業員にとっては、ヨソにも行けないデッドロック。

さて・・。
SOX のセミナー無料でやるから、２年は契約して働いてね、という会社がある。
組み込み・制御系、未経験でもいいから、３年は契約してね、という会社がある。
SOXは、当分需要があるだろうし、組み込みは、特定の処理系に依存しない考え方が身につけば、悪い話じゃないと思う。
が、オレも一緒だけど、常に、その次・・を意識していないと、食い詰めるだろうなあ。

三角関数

２０代のころ、文学部出身の僕は、理系出身のプログラマーにかなりコンプレックスを持っていた。プロッターでグラフを描画するのに、座標を求める必要があるとき、サイン、コサイン、タンジェントが必要だった。

僕が苦労していると、理系出身のＴ君は、当たり前ジャン、常識ジャンと、ちょこちょこと、１ー２行書いて、ホイと渡してくれた。ああ、オレは、この先ＰＧとしてやっていけるだろうか、向いてないんじゃない？とか、けっこう悩んだわ。

だけど、仕事やってく上で、文学部ですからあ、なんていい訳できんしねえ。知らんかったら、調べりゃいいじゃん、以上。

今でも、三角関数は、調べないと思い出せない ^^;;
けれど、調べる方法は、インターネットをはじめとして、ものすごく豊富になってきて、困らない環境ができている。

ＰＧ・ＳＥで、ずっとやってきて、今、営業のような？仕事をしている。
最初は、言い訳してたかもしれない。「おれは、技術者だ、営業は素人だ」
でもね、何年もやってたら、「営業は素人」だなんて、言ってられないんだ。
やらなきゃいけないとなれば、それでメシ食おうとする以上、プロになんなきゃ。

三角関数を覚えてなくても、なんとかなった。
今も、立派じゃないけど、何とか、何かの間違いで、幸運と周囲の人に支えられて・・・何とかなってる。

10年生き延びた本（古典的技術書２）

古典的技術書の続き。

IT、ソフトウエア関連の本は、巷にあふれている。中には、その製品のマニュアルの引き写しそのままだったりする。

そうでないまでも、特定の言語、特定の処理系、特定の技術エンティティに特化した内容のものが多いよなあ。もちろん、そういう詳細を説いた書物って、実用性という意味では優れていて、「高いなあ」と思いつつ、けっこう購入してきたし、たぶん、これからも、昔ほどではないにしろ、必要に迫られて少しは買うんだろうなあと思う。
でも、そういう本って、寿命が短いよね。それらが良書か悪書かという議論じゃなくて、流行の旬の技術要素って、どんどん変わっていくし、そういう本は、その流れにあわせて、どうしても消えていく。十分に実用性があってもね。

そんな中で、１０年以上という歳月、生き延びてきた技術書は、時代を越えて通用する概念や考え方があると思う。
製品やプロダクト、処理系、フレームワークは、これからもどんどん変わるだろう。この業界で仕事していく決心をしているなら、それらの本ににある時間を越えて通用する概念・知識こそ、身につけていきたいし、部下、後輩、仲間に、身につけてほしいと願う。

だけど、これがけっこう大変なんだ。俺は最近は、技術書に限れば毎月１冊だわな。他の分野の本も読まなきゃいけない立場だし。
だけど、月１冊でも、継続していくと、けっこうな力になると思ってます。
１０年で１２０冊。流れやハヤリで消えていく知識の積み重ねではなく、時代を越えて残るＩＴの概念・哲学・思想の蓄積。差が出ると思うよ。


部下・後輩に読ませたい本のアマゾンのリストマニアはこれ

言語の歴史 4 オブジェクト指向

構造化言語も頑張った。が、やはり時代が許さない。

今まで、コンピューターは、本質的に「計算機」として使われてきた。ＸＸシステムとかＸＸアプリ。外装の機能は変わっても、やってることは計算機。

が今は、ネットの携帯、メール等、独立した個々の間ののメッセージツール、コミュニケーションツールになってきた。計算、演算の処理であれば、構造化言語でも十分対応できた。しかし、巨大なネット空間、トポロジー、メッセージ伝送を、モデルとしてとらえようとすると、手続き型や構造化の考え方では、表現が非常に困難。できないといってもいい。
web2.0のシステム概念など、オブジェクト指向そのものだ。

世の中でおきていること、シカケ、ビジネスの仕組み。問題領域、システム化対象領域の多くは、オブジェクト指向で表現するほうが、無理が無い。できないと言ってもいいかもしれない。
オブジェクト指向は、エンジニア、プログラマのニーズや好みで生まれたものじゃない。

C++より後発の、Java PHP5 Ruby などは、ネットを意識して、マシンをまたいでのメッセージ連携、プロセス間通信が、最初からできる。ネットに関係するコンストラクションの際に、今はそれらを選択することが妥当だろう。勿論、次に何が来るかはわからない。

今、ＰＧとしてするべきは、オブジェクト指向を理解したうえで、それらの処理系を使いたい。
JAVAのクラスメソッドをたくさん覚えても、オブジュクト指向を理解したことにはならないんで。

C++ JAVA PHP5 Ruby,Squeak
本稿では、いつもの言語の説明はしない。馴染みは十分あるだろうし。

古典的技術書

久しぶりの更新だ・・。

先日後輩２人と飲んだ。年は１０歳も違う。

だいたいサラリーマンが飲めば、大企業であれば上司、中小であれば社長の批判か、あるいは顧客とのやりとりの愚痴と相場が決まってる。１０歳違おうが、ＩＴ会社であろうが、まあ話題は一緒だったりする。

が、今回は、インフラ対ＡＰの技術論・実装論などで、やたら熱くなった。店に出入り禁止にならないか心配になるくらい。そのうち、攻撃の矛先が、先輩であるオレにむいてくる。

「だいたい、高橋さんなんて、はっきり言ってロートルですよね。（ぐはあ）　でもいいじゃないですか。僕らはそんなこと期待しない。Apacheのconfig のパタメータやら、PHPのクラスのメソッドの細かい仕様やら、oracle のチューニングパラメータを、あんたに教えてもらおうなんて思ってないですよ。
でもね、そういう細かいことは、僕らはいくらでも、必要なこと自分で調べていけるんですけど、常識というか、経験に裏打ちされたノウハウとか、年食った人は、そういうことこそ、教える責任あるでしょ。」

あいたた、痛い、痛い。そんなもんOJTだろと開き直るのも何だかなあ、「じゃあ」と、オレが読んで感銘・影響を受けたいくつかの書名をあげた。いまどきのハウツー、解説じゃなくて、哲学・思想がある時代を超えて通用しそうな本。
「すでに古典だけどな。これは、こういうとこが今でも通用すると思うぞ、ＥＴＣ」

その時の本＋アルファ　アマゾンのリストマニアにまとめた。

いいか悪いかしらんが、少なくともオレは、これらの本からは、かなり影響受けてる。マジ読んで欲しいなあ。

話題にした本のアマゾンのリストマニアはこれ

まあ、ほんと、オレは、いい後輩に恵まれていると思うよ。

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