眠る開発屋blog

もう納期が間近に迫った案件なのに、
なぜか打ち合わせに出ると、どんどん機能が膨らんでいく気がする。

なんだか局面を見誤っている気がする。

前にもちらと書いたけど、
一つのプロジェクトには「夢を膨らませる局面」「夢を諦める局面」っていうのがあって、
その局面を見誤るとプロジェクト自体が痛い目にあう。

もっと言えば、企画段階では無理なことも含め、好きなことをばんばん言い合えばいいと思う。
企画屋の仕事って好き勝手なことを妄想して、それを一つの理想形に仕上げることだと思うし。

でもスケジュール確定後は始まってからはその手の振る舞いはきついでしょ。

予算とかスケジュールが確定したら、後は黙っておけ、とも思うのだけどもね。
でもサービス精神旺盛な人々が多いと言いますか。

ただ、システム屋ってどうしても「夢を諦める」振る舞いを迫られると言いますか。
そりゃあ自分の発言が実現度合いの担保になっちゃうんだもんなぁ･･･、好き勝手言いたいけれども「システム屋として」参加を要請されているときは概して「企画屋」の役割は要求されてはいないのだし、下手なことは言えないや。

ここがスゴイよlivedoor　技術がわからない人向け易しく説明で、本題とはあまり関係のなさそうなところなのですが、

基本的に理系の人材というのは、優秀になっても無能でも給料が一緒というのが、相場です。
そりゃそうだ・・・理系の人は社内政治に弱い傾向があり、
給料は技重力ではなく、政治力できまるのが日本の会社ですから、給料は安いです。
高い給料を得ようと思ったら、政治＝マネージメントも出来る技術職にならないとダメです。
一番良いのは社長兼技術職なんでしょうが・・・それはめんどくさい・・・
CEOとかCTOとかそういった職業が日本にもできると良いのですが。できないでしょうね。

技術屋がどうやったら政治力をもてるかというと、
とりあえず営業をして「自分の力で」案件を持ってこれれば、発言力は大きくなるのかなぁ、とは思います。
売上とかの数字はある意味絶対的価値だと思いますので。

悪魔に心を売っても納期を守る！ 裏技術で、「納期オーバには受発注の段階で問題がある」みたいに書かれてますが、
じゃあ自分で案件を引っ張ってきてもいいのではないかと、この際。

Web command構想

最近思ったんですが、Webサービスもshell上でパイプとかで繋げられたら楽なのに。

面白い！って思ったら、コメント欄を見ると、それに近いのがあるのか。

ただ、PIPEという発想は今のSOAのモゴモゴ感を突破しそうな気もするよ。

「人員を投入すればする程、コミュニケーションロスが発生する。人員投入という策は銀の弾丸とはなりえない」
というのが『人月の神話』のお話。

まぁ人月の神話自体はほぼ間違ってはいないと思うのだが、
人を投入しなくてはならないときはやはりするべきなのであって、
じゃあ「どういう」人員を･･･否、「どういうポジションに」投入するかだ。

コミュニケーションロスの増大が新たなリスク要因となるのであれば、
「じゃあなるべくコミュニケーションロスが発生しないところへ投入しよう」となるのは当然であって、
単純作業であったり、少しぐらいコミュニケーションロスがあってもまぁ何とかなるだろう、ってところから投入するのは自然に導き出される結論か。

このとき既に参加しているメンバーには
「簡単な作業だからと言って自分の貴重な時間を浪費して行わないように」
という節度ある態度が求められることになる。

「誰が何をやるか？」というのは意外と重要で、
きちんとしたところは開発環境管理者とかドキュメンタリーを専任でお願いできるのだけども、
そこまでPMの頭が回っているのであれば、そもそも火も噴かなかったと言いますか。

アーキテクトに必要なもの、分割への志向をふと読み直して。

例えばだ、営業部門、管理部門、開発部門など部門単位に開発するのが適切なサブシステムを考えて場合、それぞれ部門が全て異なる会社、全て異なる場所だと考えれば、一括して対応するにしても振る舞いが異なるものと思われる。

「全体最適」って常に考慮しなくてはならないだろうから、「これって可能なのかよ？」って話もあったり。

ただ全てがサブシステムとなり、それぞれがREST（とかSOA）でつながるというのは難しいことなのだろうか。

なおRESTの場合、それぞれのノード間はPULL型のメッセージモデルになるとは思われるのだが、マスタサーバのレコードが削除された時とかは一般的にはスレーブってどう振舞うのかしら？って思ったり。

個人的には「もうあまり難しいこと止めましょうよ」っていつも思うのだけども。

徹夜をしてはいけない理由

忙しいときはどんな会社にだってあるし、連日徹夜を余儀なくされる時期だってあるだろう。
しかしそんな時、自分は個人・会社ともに大きな危険にさらされているのだということを自覚しながら、よく気をつけながら徹夜したり、させたりするべきである。

同意。
というか、世の中には自分達の会社の半分の労働時間で倍の生産性、利益を上げている会社も「常に」存在していることも知るべきである。
長労働時間をしたからすごく儲かるというわけではない。
徹夜ＯＫの社内文化はその当たり前の感覚を狂わせると思う。

で、どうすれば徹夜を免れるか。
とりあえずは早め早めの「気づき」かな。

Gooラボなんてあるのね。
Googleラボは有名だが、サイボウズラボだったり、最近は自社のR&D的取り組みを広く開示しようとするIT企業が目に付く。
ブランド活動の一環なんだろうな。
でもこういうのは面白い。

一ヶ月ぐらい前（！いまやもう一ヶ月も前！）にこことかここで「Web2.0はGeek向けのマーケティングである」と看破されている訳だが、まぁそれはそれでいいんじゃないの、と思う。

ラボ話と絡めて話すと、Geek向けの広告活動が増えてきたと言うか。
アルファなんちゃらとかいう人達に取り上げられればよいのかな、と言うか。

話は変わって、紅白の出場歌手が発表されているのだが、知らない人多いなぁ、テレビ見ないからかな、WaTって誰？

RSSは知っているけどWaTって誰？っていう人もいる一方で、
WaTは知っているけどRSSって誰？っていう人もいる。

インターネットの普及により入手する情報の偏り･･･興味のある情報だけしか頭に入れなくて済む･･･という状況がますます顕著になってきていて、もしそのセグメントの中だけで十分に商売が成立するのであれば、Web2.0ってラッパを吹くだけでゴハンが食べられるのならそれでいいじゃない、別に一般の人々が知らなくてもさ、とも思う。
（そもそも「一般」って何？）

まぁ何にせよ、ラボという公開実験の手段は有効なのかもしれない。
標準化団体を組んであーでもないこーでもないとやるのも一つの手だろうけどさ。
でも例えば使い勝手のいいツール（とかWebのサービス）にAPIプロトコル組み込んで配布して、そのプロトコルが普及さえすれば、あとはビジネスモデルはどうにでも組み立てられるんじゃないの？という気もする。（プロトコルビジネスモデル）

言い換えた方がよさげなリスト。

1. 使う => お願いする
2. 外注 => 協力機関
3. 丸投げ => 上流工程から入ってもらい力を発揮してもらう

「どういう言葉が使われているか？」ということでも企業の品格が分かるのかもしれない。
そして品格の低い企業は得てして仕事のやりかたが煩雑だったりする。

品格は高いに越したことがない。
今は取引がなくても、会話の隅々で出てくる言葉の使い方には気をつけたほうがいい。

ってイベントやらないかなぁ。
PHPじゃなくてもPerlでもOKだけど。
（LightWeightだったら他でもいい）

Java屋とPHP屋が交互にプレゼンやって、最後にトークセッションやって、優劣を決定するの。
いや、「ケースバイケースだよね」って結論は分かっているのだけども、なんか面白そうじゃないですか、こういうの。
言語に拘らず会社対抗でもいいかも。
３対３ぐらいでプレゼン対決して、勝ったほうが懇親会の飲み代はタダになるみたいな。

日経平均225銘柄のマップだってさ。
視覚化？見える化？ちょーだいじ。