先日某所で講演をする機会があったのだが、 そこでお会いした大企業に所属されている方からの発言でいくつか印象的なものが あったので、ブログに書くことにした。 中にはぐったりしてしまうような内容のものもあるのだが、 会社が大きくなるとこういうことが起こりえるのだという自分への戒めも込めて。 とある大手 SI の方の話。 会社で 2ch へのアクセスを禁止したところ、開発の速度が目に見えて低下したので、 何が起こったのかと現場にヒヤリングしたところ、今までは困ったときに 2ch で聞いて問題を解決していたが、2ch にアクセスできなくなって、 はまってしまったときにどうにもならなくなってしまったとのこと。 これは Messenger / Skype を禁止している会社にも同様のことが言えるだろう。 プロが 2ch で聞くというのはどうなのかという意見もあるとは思うが、 会社の枠を超えた横のつなが

「いつかベンチャーをやりたいと思ってるんですよ！」 この種の発言は確か私が大学生の頃によく耳にしていた台詞で、その時ベンチャーにまったく興味のなかった私の感想としては、ああ、この人は自分にはあまり関係がない世界のことを話してるな、という感じで、そんな自分がまさか数年後にベンチャー企業をやることになるなんて夢にも思っていなかった。 そんな私もベンチャーを始めてから気付くともう6年が経って、会社も軌道に乗ってきて、ベンチャーを始めるにはどのようなことが大切で、どのようなことをすれば良いのか、ある程度わかるようになってきた。だから今日はそのことについて書こうと思う。 もしあなたが、自分自身で起業しようと思っているなら、ヒトの問題についての最初の関門はクリアしていると言っても良いかもしれない。 というのも、起業の際のヒトの面での最大の問題は、創業者が見つかるかどうか、ということにあるからだ。 もし

私はもともとはプレゼンは完全にアドリブ派で、大まかな流れだけサッと考えて直前に資料をつくって、後はぶっつけ本番で、残り時間を見ながら話す内容をその場で考えてプレゼンする、というのがお決まりのスタイルだったのだが、昨年末あたりから、このやり方だと、内容はそれなりに伝えられても、発言に冗長なところがあったり、表現が洗練されていなかったり、そして何よりも、プレゼンの中にドラマがないというか、良いプレゼンを見ていると、どれも周到に準備されていて、話の展開はもちろんのこと、沈黙のタイミングや長さ、声の調子に至るまで微にいり細にいり実によく考えられており、アドリブのプレゼンだと、このようによく準備されたプレゼンと比較すると、演出の面において決定的に劣ってしまうのではないかと考えるようになった。

私はその戦略をラストマン戦略と呼んでいる。 大学を卒業してサン･マイクロシステムズに入社してすぐにわかったことは、Java を生み出した会社でソフトウェア開発をやろうと思って入社したのに、日本サンはソフトはほとんどやっておらず、ほぼ100%ハードウェアを販売するための会社だったということだった。 野菜を売りたくて八百屋に入ったつもりなのに、間違えて肉屋に入ってしまった。このようなときにどのように行動すればよいか？ 1. 肉屋に入ったのだから、とりあえず肉屋を目指す 2. 八百屋への転職活動を開始する 3. 肉屋の中で野菜についての No.1 を目指す 一番多いのはパターン1の人で、入社の直前直後は熱くソフトウェア開発を語り合った同期の多くは、今ではハードウェアのスペシャリストへの道を目指している。 ラストマン戦略とは、ある所属組織内で自分が一番(最後に立っている人 = ラストマン)になれそ

数年前に某大手戦略コンサルに入った知人がしきりに驚いていたのは、 どのプロジェクトリーダーの下につくかで、 同じ会社の中でもあまりにも仕事のスタイルが違うということだった。 具体的には、彼が最初に配属されたプロジェクトのリーダーは熱血な人であり、 顧客との打ち合わせや提案資料の作成で平日休日問わずいつも24時を回ってしまう。 だから社内での打ち合わせは25時か26時くらいから始まることがほとんどだった。 私はそんな彼の手伝いを何度かしたことがあったのだけれど、 彼が仕事の打ち合わせの途中で抜けてきてオフィスの入り口付近で話すことが多くて、 待ち合わせの時間はいつも26時前後だった。 そのプロジェクトの組織は、ホットな組織だったと思う。 プロジェクトリーダーも、今、自分たちがどのような状況にあり、 何のためにこれだけの時間をかけているかということをきちんと説明できていた。 情熱 少しでも良い

ゲームが大好きで、今も昔もゲームにたくさんリラックスさせてもらって、どんなに忙しいときも最低週に10時間くらいはゲームをして、ゲームからたくさんのことを教えてもらってきた私にとって、最近世の中で言われているような、ゲームが人の攻撃性を育てるとか、ゲームが人間的なつながりを薄めるといった指摘はかなり違和感のあるもので、かと言ってそうした指摘に対して反論を行っていくというのはスタンスとしてあまり好きではない。 だから今日は、自分がこれまでゲームから学んできたことをいくつか書いてみたいと思う。 今一番熱中している World of Warcraft で私は多国籍ギルドに入っていて、普段は時間帯の似ているオーストラリア人のプレイヤーと遊んでいることが多い。彼らのやり方を見ていて面白いな、と思うのは、難しいといわれているところでも、とりあえず行ったことのないところにトコトコと出かけていって、全滅して

はてなブックマーク子さんへ あれは確か去年の12月10日のことだったと思う。 家に帰って凍える両手を吐息であたためながら ブログのアクセスカウンタを見たら、 昨日まで1日に20件くらいしかなかったアクセスが、 突然200件を越えていて、本当におどろいたんだ。 それが君からのアクセスだってことにすぐに気付かなかったのは、 あの頃はまだブログをはじめたばかりで、 shinobi.jp のアクセス解析を入れていたけれど、 ツールの使い方もよくわかっていなかったからだったんだ。 君がどうやって僕のことを知ったのだろうと気になって仕方なくて、 不慣れな操作で手探りで探して、 「もっと毒吐かないと！」 という言葉を見つけて、最初は何のことかわからなくてすごく戸惑った。 正直に言うと、君の名前はずいぶん前から聞いていたし、 どんな人だろうって気になってはいたんだ。 けれども、あの日までは何となく君に近づ

むしゃくしゃすることは悪いことではなくむしろ良いことである、と最近思い始めた。そういう私は今、とある仕事のことでかなりむしゃくしゃしている。 すべてが思い通りに行くということはつまり今の自分ができる範囲内のことをしているからであり、自分が今できることを越えたところに身を置けば、息を吸って息を吐くように自然にしているだけでは、物事がうまく進まなくなってくる。 ここが一つの分岐点なのだと思う。 「文化は抵抗体があって生まれる」 とかつて私に教えてくれた人がいて、四大文明がどこで生まれたのかを考えろと彼はいう。氾濫する黄河、そのままでは住むことのできない砂漠。それらは手を伸ばせば果物に当たるような食に恵まれた豊かな大地ではないところから生まれてきた。 現時点で自分が苦もなく対処できる場所にいる安楽もある。 しかし、こうも考える。 楽をしてすべてがうまくいくような場所に身を置いてニヤニヤしながらふ

このところとみに思うのは、ソフトウェアを他のソフトウェアを比較するのではなく、ソフトウェアをソフトウェアでないものとこそ比較しなければならないということである。 例えば Ajax vs. Flash を議論するのではなく、Ajax や Flash を駆使して開発された Web アプリケーションでも実現できなくて、しかし今自分の目の前にある紙と鉛筆では実現できることが何かを考えることである。ふと思いつくときというのは、編集性も保存性も高くコピー＆ペースト等の各種機能を持った Word や一太郎で文章や図表を作成しながら考えているときではなく、鉛筆で思いついたことくしゃくしゃになった紙に書きなぐっているときだったりする。 ソフトウェアについて考えてるとき、必ずしも PC やサーバーの上で動作することを前提として考えるのではなく、例えばマッシュアップしたら面白そうだと思うサービスがあったとき、そ

昨夜はシリコンバレーで会社を営みながらいくつもの会社の顧問や社外取締役をつとめているスーパーマリオ似のNさんと飲んだ。50半ばにして10代の若者のようなバイタリティー。経験豊富なだけあって実に話がおもしろい。 曰く、 アメリカ人はすぐミス・ユニバースなどと言う。 日本人は謙虚だから No.1 を宣言するとしてもせいぜいミス・ジャパンである。 ユニバースという言葉は国や地球や銀河系を超えて全宇宙を含むので、 せめてミス・ギャラクシーくらいにしないと他の星雲の人たちが怒ってしまうのではないか。 そんな冗談のような話を真顔でしながら、 彼はこうも言った。 すぐにミス・ユニバースを目指すアメリカ人の気質があってこそである。 狭い範囲で No.1 を目指すことと、 はじめからユニバースの中での No.1 を目指すこととは根本的に違う。 人も組織もやり方も給与体系も短期計画も中長期計画も、何もかも違う

高校の陸上部に入って最初に教えられたことは、400m 走は最後まで全力で走り抜けることはできないから、ペース配分が大切だということだった。 先輩曰く、 1. 最初の 100m スタートダッシュ 2. 次の 100m 全力疾走 3. 次の 100m ペース維持 4. 最後の 100m ラストスパート これは一見、言葉を変えただけで全部全力疾走じゃないかという風にも見えるのだが、実は3番目の 100m で少し力を抜くというのがポイントで、実際、どこかでうまく力を抜かないと良い結果が出ない。 この力の抜き方には人それぞれに得意不得意があって、前半力を出し切ってトップを取る方が精神的に楽だと感じる人、最後まで力を溜めておいて一気に抜き去る方が楽だと感じる人、さらには満遍なく一定のペースを維持するのがやりやすいと感じる人と、人それぞれによって実力を出しやすいペース配分というものがある。 興味深いのは

これまでこのブログではソースコードが出てくるようなエントリは書かないことにしていた。 ブログをはじめてからもプログラミング関係で書きたいと思ったことはいくつかあったのだけれど、 プログラミングのブログは別のブログとして立ち上げようかどうかなどと考え、 結局ソースコードが出てきそうだったら書くのをやめることにしていた。 けれど、日々ソースコードを書いているのも自分の一面だし、 ブログが分かれてしまうとサイトが複数になって管理するのも見るのも不便なので、 このブログにプログラミングというカテゴリを追加することにした。 ということで第一弾。 ファイナライザ・ガーディアン(Finalizer Guardian)。 Effective Javaで紹介されている方法でとても便利なのだけれど、 Google で検索したところ日本語のサイトではほとんどヒットしなかったのでここで紹介することにした。 ファイ

今週末は熱海の温泉に行ってきた。 行き帰りの新幹線で読んだJoel on Softwareは衝撃的に良かった。 この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。 中でも第三章に書かれているジョエルテストが面白かったので、 これをアプレッソに当てはめて判定してみることにした。 現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。 該当する項目が2から3の会社が圧倒的に多いということなので、 判定結果としてはかなり良い方だと思う。 しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、 「今のままで特に大きな問題があるわけでもないし、 新しい方法を導入することにはリスクも伴う。 このままでも良いのではないか。」 という理由で導入を躊躇したものも多かった。 これらはどの項目についても、マネージャーがどんなに反対したとしても

小学校四年生の頃だったろうか。 毎週決まった曜日に、 10点満点の漢字テストがあった。 連休明けか何かでテストのことをすっかり忘れていた私は、 これまで9点か10点しかとったことのなかったテストで、 0点をとった。 親に言うことはできなかった。 答案用紙が返される日に 母親から結果を聞かれて、 漢字のテストはなくなったと答えた。 赤い文字で0点と書かれた答案用紙を 家に持って帰ることができず、 学校のごみ箱にも捨てることができず、 くしゃくしゃに丸めて教室の自分の机の奥にねじ込んだ。 答案用紙が返される日が来るたびに、 机の奥は、押し詰められた0点の答案用紙で一杯になっていった。 もうみんなに追いつけない。 踏み外してしまった。 自分だけ置いていかれてしまった。 道をはずれてしまった。 取り返しのつかないことになってしまった。 私は勉強をしない子供になった。 次第に他の教科でも手を抜くよう

会社で問題が起きたとき、なぜそんな問題が起こったのかと詳しく話を聞いていくと、 問題を構成するほとんどすべての項目について、ミスコミュニケーションがその根本の原因となっていることがある。 誰かが手を抜いているわけではない。誰もが前向きに一生懸命やっていこうとしている。 それでも、ミスコミュニケーションが重なると、問題が次第に大きくなり、修復することが難しくなっていく。 場合によってはその積み重ねが相手に対する不信感を生み、人間関係に悪影響を及ぼすこともある。 ミスコミュニケーションは人の問題であり、簡単には解決できないようにも思える。 しかし、対策の打ちようはある。 【ミスコミュニケーションの分類】

何を始める場合にも、新しいことを始めようとするときには、すでに世の中にある何らかのものと競合する場合がほとんどだ。そして、すでにあるものに対して、不足することが一切なく、しかも優れていることまである、という完璧なものを新しくつくろうとすることは、絶望的に難しいものであるように思えることが多い。 しかし、ある一点でのみ勝つことができるものをつくることは比較的簡単である。 谷を埋める = 負けている箇所を補うこと 山を作る = 勝つことができる箇所をつくること 既存のものより優れている点よりも、既存のものに負けている点があることの方が目に付きやすい。ネガティブな人でなくとも、一点だけ勝てる点があるが、他のすべての点ではすでに世に出ているものに負けると言われたら尻込みしてしまって新しいことを始める気持ちが挫けてしまうかもしれない。 そういう、一瞬光るものが見えた気がしたけれど、調べていくと何とな

アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ

1. 会議を最適化する ミーティングのゴールを明確に設定する。 ミーティングの最後に必ず結論と ToDo を確認する。 ミーティングの回数をできるだけ少なくして時間もできるだけ短くする。 ミーティングのトピックごとに関係する人だけ集めて最少人数で議論を行う。 (途中であなたはこのトピックに関係ないから退席して良いです、と指示がでる) 会議を最適化することで労働時間中の実作業時間を最大化させ、労働時間全体を圧縮する。そして、早く帰る。 この体験は、その後自分が会社で会議をしていく上で大きく役立った。 XM(eXtreme Meeting)にも、この時の体験が直接的にも間接的にも影響を与えたと思う。 アドバイザーとしてプロジェクトに参加していたテクニカル・コンサルタントが、技術的に明らかに間違った発言をしたことがあった。 私を含む日本から来ていた何人かのメンバーは、あんな基本的なこともわかって