グループウェアの新しい使い方「ひとり言スレ」──サイボウズ・ラボ
ラボの“生態”を明らかに──。4回目を迎えた今回のラボめぐりは、グループウェアなどで有名なサイボウズから分社したサイボウズ・ラボ。2007年に入社したばかりの西尾泰和さんに話を伺った。 ラボの“生態”を明らかに──。4回目を迎えた今回のラボめぐりは、グループウェアなどで有名なサイボウズから分社したサイボウズ・ラボにお邪魔した。話を伺ったのは、2007年に入社したばかりの西尾泰和さんだ。いつもはラボめぐりの取材をしてもらっている秋元裕樹さんも、今回は所属元ということで西尾さんのサポートに回った。 東京・赤坂という都心の一等地にそびえ立つプルデンシャル・タワー。サイボウズ･ラボは、このビルの1室にラボを構えている。所属する研究者十数名の席がレイアウトされている作業スペースで、オフィス家具好きの筆者が注目したのは、特徴的なワーキングチェアとデスクである。 PCを使った作業に適する姿勢は、ワーキン
技術者論
僕が最初に入った会社では、産業用の生産装置の電気設計のエンジニアをやっていました。 新入社員で現場から入って溶接したり板金したり制御板作ったり、一からモノ作りを学んで、エンジニアとしての原点は今でもそこにあります。 生産装置ってで何が一番大事かと言えば、装置を利用されるお客様の製品を安定して生産すること、ただ一点です。 装置が壊れたときに、遠方、時には海外（日本）にいるエンジニアが一々出張しないと直らないという装置は業務上のリスクに繋がります。だから、部品は簡単に交換できるように作るし、ソフトウエアもある程度であれば、その会社の保全のエンジニアがいじれるように作らなくてはいけません。 そういう中で、装置はそのままで、制御に使っているコンピューターを、その会社の標準仕様に合わせることが求められることがあります。 単純に企業の系列的な都合もあるし、保全のエンジニアがいじれるメーカーにあわせて作
プログラマの労働価値
プログラマの労働価値は、そのソースコードのクオリティでも、書いた行数の長さでもなくて、成果物がもたらす価値によってのみ決まる。 いくらエレガントなコードを書いたところで、それが1円も生まなければ・・・金銭だけじゃなくブランド価値なども含めて・・・・ビジネス的に価値は全くない。つまり本来は報酬の対象にならない。 受託業務の場合は、受発注する側が成果報酬などのリスクを取らないのであれば利益を先に確定したいのは受託する側も受託に出す側も共通したリスク回避の切り分け手段なので、そこを重視するが故に、不確定な見積もりだけに売り上げを依存させましょう、というトレードオフがあるに過ぎないんじゃないだろうか。 つまりお互い幸せになるための手段が、事前見積もりでいつまでに納品しますよ、という契約をしてしまうこと。 この一番大事なステージを、うまくやれる会社か否かか、という違いが受託ですげー苦労するかそうでも
分裂勘違い君劇場 - プログラマが他のいかなる職業とも決定的に異なる理由は「誰にでもできるつまらない仕事」の生産性にある
法務でも、人事でも、営業でも、運送でも、接客でも、掃除でも、ほぼあらゆる仕事において、 「誰にでもできるつまらない仕事」をさせたときの生産性は、有能な人間と無能な人間で、劇的な差は出ません。 「誰でもできる簡単な営業」なら、超優秀な営業マンと、凡庸な営業マンで、仕事の成果に劇的な違いはでません。 「誰にでも出来る簡単な接客」なら、超有能な窓口係でも、凡庸な窓口係でも、仕事の能率は大して変わりません。 通常、能力によって仕事の能率に劇的な差が出るのは、「難しい仕事」をさせたときです。 有能な営業マンは、難しい営業交渉を、手際よくまとめ上げる。失敗する頻度も少ない。 平凡な営業マンは、難しい営業交渉だと、ときとして有能な営業マンの５倍もの手間をかけ、しかも、失敗する確率は５倍だったりする。 こうして、有能な営業マンは、平均的な営業マンの１０倍以上の生産性をたたき出します。 しかし、あくまで、そ
わたしが知らないスゴ本は、きっとあなたが読んでいる: コンピュータの名著100冊
仕事でコード書いてた頃の話。 机上に「本」というメディアは無かった。プログラミングといえばお手本のコピペ＆手直しで仕上げてた。だから、せいぜい入門書やリファレンスといった辞書的なやつだけで、3年もすれば「古い」と引き出しの中へ。 だから、いつまでたっても上手なのは「お作法」だけ。あたりまえだ。仕様を実装したコードに「似た」コードやパターンを探し出す→コピペがプログラマの仕事だと思ってたから。ネットの情報が「全て」であって、「考える」とは、「いかにお手本に合わせるか」だったから。 プログラマというよりも、むしろ「コーダー」。その辺は「プログラマになれなかったわたし」[参照]に書いた。 ここでは、「コンピュータの名著・古典100冊」の既読リストで恥さらし。いかにちゃんとした本を読んでいないかがよっく分かる、なさけない。 本書はプログラミングに限らず、ソフトウェアエンジニアとしての libera
【Open Source Revolution!】「オープンソース時代には，優秀なエンジニアは志の低い企業から逃げていく」，スターロジック 羽生社長
「企業とエンジニアとOSSの三角関係」。スターロジック代表取締役兼CEOであり，Seasarファウンデーションの理事も務める羽生章洋氏（写真1）は，2006年5月15日に開催されたオープンソース関連イベント「Open Source Revolution！」で，このような刺激的なタイトルで講演を行った（関連記事）。優秀なエンジニアはなぜオープンソース・ソフトウエア（OSS）の開発プロジェクトに引き寄せられるのか，それを踏まえて企業はどのような点に気をつけなければならないのかについての自説を披露した。 OSSには様々なものがある 羽生氏はまず「OSSといっても様々なものがある」と指摘。OSSと十把一絡げに言うのは，ちょうど「欧米」と言うのと同じだとした。実際には，欧と米は違うし，欧の中でも英国とドイツとフランスは違う。羽生氏はOSSにおける違いとして次の四つを挙げた。 「地域」…ソフトウエアの
転職します。
グローバルスコープのblogにわざわざ書くほどのことでもないような気がしたんですけど、眠る開発屋blogさんを見ていて、書きたくなったので書いてみます。 どうやったら夢に付き合うことができるのか 「これこれこういうWebサービスを立ち上げたいのだけども、システムの仕事してくれない？」という話をよく聞く。 これから立ち上がる事業なので当然のことながらあまり予算がない。 報酬自体も、こちらが想定していた見積もりの４分の１だったり１０分の１だったりする。 ?中略? でも、やるからにはそれなりに「理由の成立する」案件として受けたいと考えている。 「理由が成立するのであれば」会社の案件として受けるのも可能だからだ。 受託がビジネスである以上、非経営者の判断としては、適切な工数で成果物を提供し、顧客満足度を実現し、利益をいかに出すか否かという一点のみに集約せざるを得ないのと、決して、自分がよかれと思っ
眠る開発屋blog - 統一ランキングと情熱
AFTERTOUCH surreal SxGx maniac cinema&book; review *めぐりあうたびに溺れて 見失うたびに胸焦がしてた* InverseDiaryFunction SxGx ｷｪｪｪｪ Ｎ山家の人々 Dairy ☆質問ﾀﾞｲｱﾘｰ☆ ネタ帖 むらみぃ 世の中とあたしの繋がり GOOBERS ++今日のechiko++ ロストマインドガール * mayumi blog * モウソウｔagebuch 読書感想日記☆ネタバレ注意警報！ 癌と煙草と酒と 俺の道 toro's bｌog. ++ torog ++ ココアシガレット・アンダーグラウンド Deportare gorf net AFTERTOUCH surreal ２ちゃんねるの超怖い話 maniac cinema&book; review CARLTON1976 平凡な日々 秘密のホンネ ゴリラ秘話。 Ｌ
小野和俊のブログ:徹夜をしてはいけない理由
どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」：Goodpic
This shop will be powered by Are you the store owner? Log in here
PG、SE、PM に求められるコミュニケーションスキルの違い
この記事のまとめ。長文エントリごめん。 「コミュニケーションスキル」と一言でくくられるが、中身は多岐に渡る プログラマ（PG）は、「確認するスキル」が最重要 システムエンジニア（SE）は、「絵にするスキル」が最重要 プロジェクトマネージャ（PM）は、「言うことを聞かせるスキル」が最重要 コミュニケーションは全人格的なスキルで、その真髄は「人を動かす」こと ン十年前、入社したての頃はCプログラマだった。その後、SEとして仕様折衝、設計に携わった。時折、炎の海に放り込まれ、コードを書いたりテストをしたり、リアルバトルを止めに入ったりと火消し屋のキャリアを積む。 その後、PM見習いでチームリーダーをしているうちに、要件定義のさらに上流に引き寄せられ、今では開発現場を離れてコンサルタント（非IT）の丁稚をしている。 システム開発の工程を河上へ遡及するにつれ、スキル不足を痛感した。わたしに最も足りな
わたしが知らないスゴ本は、きっとあなたが読んでいる いきなりコンサルタントに抜擢されたSEが読むべき3冊
この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む本。 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる SEとしての分をわきまえるなら「RFP＆提案書作成マニュアル」で準備しておく SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」 コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。 このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。 で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ロングテール時代のSI
http://d.hatena.ne.jp/habuakihiro/20060203