眠る開発屋blog

1. 「技術力が高い」とはどういうこと？
   クイックソートとかその他色々のアルゴリズムをソラで書ける人よりかは、Eclipseのショートカットを沢山知っている人間のほうが生産性が高いという現実。
   つーかそもそも「技術力が高い」=「（別の誰かが作った）要素技術に精通している」というのは昔からの話か。
2. 最近の話。とある処理を新たに作らなければならないと分かったとき、「とりあえずライブラリを探してきて、有名どころのライブラリなのでロジックもネットに転がっているでしょ」
   「探す技術」が重要なのはいつの頃からか。
3. 昔は「パンチャ」って職業があったんだよね。でも開発環境の発達により今は殆ど見ませんな。
   PGはそうはならないのかな？以前からなるなると言われているけど。
4. Office文書がXMLで保存できるってことはMDAが加速するってことかな？
5. メーカ系の業界内の利益配分の考え方に「スマイルカーブ」ってのがあるけど、システム開発にもその考え方って当てはまるのかな？
6. XPとかイテレーティブな開発の大前提ってPGの判断がユーザまでフィードバックされるってことな気がする。
7. デスマの原因って色々あると思うが、「技術的に難しいことにぶち当たった」ってことよりも「仕様がなんだか曖昧だなぁ。っていうかなんでこのタイミングでそういう仕様が明らかになるわけ？」ってことだと思うけど。だからこそのオンサイト顧客（仕様がすぐに聞ける体制）なのかしら？
8. 優秀なんだけども「立場的に」なかなか表舞台に出てこない人って相当数いるよね。

PGの復権ってもうそろそろマジメに考えてもいいんじゃないのかな。
その結果PGという名前になるか否かは別の話として。

mixiアルバムのサムネイル一覧ツールを作ってみた。
ただ見るだけのホントにちょっとしたツール。
一応、ソースも公開中。あまり美しくないと思うけど。

にしても、今の自分にとってPHPはともかくCSSが一番？な部分だったり。

というか、もっと面白そうなツール考えよう･･･。

やる気の出させ方についてふと。

成果主義批判の文脈でよく出てくるのが、高橋伸夫氏なんだけども、彼の主張する「『次の仕事』で報いるのが日本型年功制」というのはこういう場合でもよく当てはまっていて、「次の仕事が期待出来ないような現場であれば、それなりのことしかやらない」ような気がするけど。

ところで、これはどちらがやる気が出るのだろうね。

1. ２ヶ月で４００万貰える仕事
2. ２ヶ月で２００万しかくれないけど、その後、継続的にいい仕事を回してくれる「かもしれない」仕事

営業的に正しいのは1のような気もするけど、実際に現場の人間をよく働かせる為には後者のほういいだろうね。
お金が貰えるのが確定した瞬間、もし次の仕事が全く期待出来ない状況であるならば（うーん、これも極端だけども）、必要最低限の働きしかしないだろうし。

あと技術屋のモチベーションを上げる参考という意味でこれも。
下請けのコントロールに彼らの職人的プライドを利用する

いやー、にしてもだ、システム業界の人間って下請けとかのやる気を鼓舞するのがホント下手だと思うよ。

ちょっとあるモノが作りたくて、PEARのHTTP_Request を利用して、mixiにPHPからアクセスするPHPライブラリとかを考えていたりします。
今のところは↓な感じでまだぜんぜーん出来ていない。
http://cvs.sourceforge.jp/cgibin/viewcvs.cgi/tgallery/wgallery/lib/MixiSite.class.php
っていうか、つい最近気付いたのですが、phpMixiというものが既にあるっみたい。こちらはsnoopyを利用している模様。
うーん、自分で作るの止めて、phpMixi利用したほうがいいのかなぁ。

ところで作りつつ思いついたことなんだけども、SemanticWeb的なものを考える場合、サイト同士の認証処理というのは遅かれ早かれ必須要素になっていくと思うのだが、セッション処理的なもので行うのがいいんじゃない？ということだ（RESTの発想とはちょっと変わってきてしまうのだが）。
この場合のセッション処理って、「セッション情報はサーバで保持し、クライアントのCOOKIEにセッションIDを保持する」ってことなのだが、現行のWEB認証の仕組みって、ID/PWD入力後、認証状態をセッションに保存する形式が殆どであり、エージェントの仕組みにおいてもそのような仕組みが丸々利用できる可能性がある。
BASIC認証を使ってもいいのだけども、既存の仕組みを生かしにくくなるのではないだろうか。そもそもユーザ管理とBASIC認証を絡めて行っているものってセッションを利用したものに比較し、あまり聞かないような。

話変わって、pearified.comを眺めていて気付いたのだが、「channeldiscover」を利用すれば、既存のPEARパッケージに含まれていないものでも「pear install」でインストールすることが可能になるっぽい。

Using our Channel

To add this channel to your PEAR install, use:

pear channeldiscover pearified.com

Then you will be able to install our packages by using:

pear install pearified/package_name

つまり一度納品したシステムであっても、ライブラリ化されていれば、オンラインでパッチを配布することが容易になる？ってことかしら。

例えば、技術屋が事業を起こそうと会社を立ち上げた場合、

1. ゆくゆくは自社サービスで一攫千金だ！
2. 当座の運転資金が･･･。とりあえず目先の仕事をどんどんこなそう。
3. 忙しくなってきた。なかなか自社サービスに手を付けれない。
4. 請負だったり受託案件に追われて、瞬く間に月日が流れ、
5. あれ、オレって何がやりたかったんだっけ？

例えば、営業屋だったり企画屋が事業を起こそうと会社を立ち上げた場合、

1. よしいいサービスを思いついた！とりあえず事業計画書だ。
2. このサービスに出資してくれるところ探さないとなぁ。。。
3. 出資してくれる会社も見つかったし、スタッフ集めるか。技術要員も調達して、と。
4. 運転資金もスタッフも確保できて、事業も立ち上がり、
5. 事業も立ち上がったし次のサービスでも考えるか

すごい極端な話だけども、技術屋と営業屋にはこんなイメージがある。
いや、営業屋の例にしても「こんなに美味しく話が運ぶハズはない」のだが、運ばせるのに必要なものがあるとすれば、まず第一に「出資元の開拓」とかであり、少なくとも当人自身には技術力は必要とされない。

というか、当たり前の話だけども、アイディアがあって「売り方」を知っていれば、画期的な新サービスは起こせるのだよ。
新しい技術は「存在すること」を知っていればいいのであって、中身については無知でもいいのだよ。
否、むしろ無知なほうが余計な心配を持たずに突っ走れるので、実現化する可能性が高いだろう。

正直、技術者であっても、何か「面白いこと」を本気でしたいのであれば、「売り方」を学ぶべきと常々思う。
自分の価値の裏付けの為に本来の職務に誇りを持つべきではあるが、実務の範囲のおいて、技術職という括りに拘る必要はない。
ただ、そういった場がなかなか与えられないのはちょっとつまらないことだけど。

ITに限らず「技術の進化」全般に言えることだと思いますが、ITって特に「無人化」というのが重要な使命だったりしますので尚更そうなのかと。
無人レジの記事を読んでふと思った。

個人的には、技術者は「技術は時に人から仕事を奪い不幸にする場合がある」ということを認識しておくべきだろう、と思う。
Amazon等のECコマースの隆盛にしたって、中間業者から仕事を奪う側面もあるだろうし、モノの流れが効率化されたということは･･･、何かがラクになったということは裏を返せば仕事を奪うことだなぁ、と。

Google Blog Searchだけど、AtomとRSS2.0によるフィード出力があるっぽい。

RSS1.0は対応しない？とか？

脚光を浴びる価格最適化技術なんだって。

Appleは今年に入って、小売価格最適化に特化したソフトウェアを開発するRaptの助力を仰いだことを明らかにした。同社はこれにより、移ろいやすい消費者のトレンドに機敏に対応し、それによって何百万ドルという売上を新たに得られるような価格設定戦略を追求しようとしている。

Appleの話はさておいて、小売価格の設定というのはものすごく重要。
システム開発の価格設定（見積もり）についても同様なことが言えそうな。
LOCだろうがFP法だろうが人月ベースだろうが手法自体は実は二の次で「顧客が納得するか否か」がもっと重要なんじゃないのかな、と。

選挙が終わったね、自民が圧勝だった。
ここではこう書いたけど、

下手すると議席減っちゃうんじゃねーの？とか。
まぁ社民とか造反議員とかの票を局所局所ではとれると思うが、大局的にはどうだろうか？

つーか、造反議員の部分もあまりとれなかったようだ。
ここまで負けるとはね。

話題が続いているようだ。
SIerにリスク含めて丸投げ問題がありましたが、政治的当て馬としての発注（失敗も計画のうちになっているもの）は別としても、発注元のシステム担当者の当事者意識が薄すぎるとか、或いは他業務との兼任でなかなか目が行き届かないのが問題なのじゃないのかな。
案件が失敗したら一番困るのは発注元のハズなのに、「信頼してますから、大丈夫ですよね？」とだけ言って、丸投げてしまうのは、「あれ、その程度の真剣さでいいんだ？」なんて思ってしまいます（以前もこれと似たようなことを書いたような）。

つか、もっと発注元担当者はマジメにやれってことだ。

あと見積もりとしての「工数」は「顧客を納得させる為の方便」としか自分は思っていなかったりする。
一人のハッカーが一週間でモノを作り上げたとしても、「顧客が納得さえすれば」１０００万払おうが２０００万払おうがどうでもいいと。
本当は発注側が「その価格が安いか高いか」ってことをもっと勉強すればいいのにね。

つか、もっと発注元担当者は勉強しろってことだ。