次に、このマトリックスに基づいて私が今まで見聞きしてきた事例を中心に、好きなことに多くの時間を費やしている事例をいくつかケーススタディとして考えてみる。 【「好きを貫く」ケーススタディ】 ネトゲのQuakeIIに没頭するあまり、ping値の良い対等な状況でライバルたちと戦うために単身韓国遠征に出向いたSさん QuakeIIへのひたむきな情熱に関係者は感動、その後の人脈形成パターンにつながる可能性あり。また、こうした企画を立案し実践する能力が向上しているという意味では派生能力習得パターンにも該当する可能性あり。将来ゲームの企画・開発を職業として選択した場合には"Connecting the dots"にも当てはまる。 ドラクエが好きで好きでたまらなくて、キャラクタをレベル99まで育ててはまた作り直すということを毎日繰り返しているAさん キャラクタ作り直しの際に自分なりのキャラクタ育成戦略を練

今日の昼休みはソフトウェアの機能の豊富さについて考えていた。 Google Spreadsheets を初めて使ったときの第一印象は、 「機能が少ない」 というものだった。 Excel と比較してしまうと、グラフが作成できないし、マクロも組めない。 図形を自由に配置することもできないし、使える色も限定されている。 「これでは Excel と比べてあまりにも機能不足だ。 機能が十分に揃ってからリリースすべきだ」 などという議論があったのかもしれない。 事実、Google が昨年末に買収を検討した ThinkFree には、Excel や Word、Power Point のほとんどの機能が搭載されており、Microsoft Office オンライン版と説明されても納得してしまう程、ThinkFree は Office に酷似している。 もし ThinkFree が Google の買収提案を

昨日でこのところ取り掛かっていた大きな仕事が一段落したので、 今日からは待ちに待ったバグ修正の作業を始められる。 この1ヶ月、私はバグ修正がしたくてしたくてたまらなかった。 今朝は出社してすぐにバグレポートの一覧を表示して、 これは早く直さないとまずいな、とか、これはちょっと後でいいかな、とか、 レポートの内容を見ながら優先度順にバグを並び替えていく。 これからこれらのバグが次々に修正されていくのだと思うと、 もうこの時点でワクワクしてくる。 新しいソフトウェアのアイデアを考えるのは大好きだし、新機能を実装するのも大好きだ。 でもバグ修正には他の作業にはない独特の快感がある。 新しいソフトウェアを開発するのは見た目にも派手だし、世間の注目を集めやすい。 それに比べると既存のソフトウェアのバグ修正というのは地味で注目されない作業だ。 だが、バグ修正は確実に誰かの役に立つ。 もちろん、自分の考

楠さんにお誘いいただいたイノベーティブ社会基盤フォーラムというところで、イノベーションについて話している。 そこでまずはイノベーションとは何かということで、メンバーそれぞれが所定のフォーマットでイノベーション･バトンをブログに書くのが私の今日までの宿題である。 (他のメンバーの宿題の成果はこちら: 楠さん、神成さん、中嶋さん、大向さん、許斐さん) イノベーション･バトンの書式は次の通り。 1. イノベーションって何？ 2. イノベーションを生む要因 3. イノベーションを妨げる要因 4. イノベーションを生むためにあなたが工夫していること 5. あなたがすごいと思うイノベーション ということで、以下イノベーション・バトン。 ・イノベーションを妨げる環境 ゆうしゃ ほげほげ はあたらしいサービスのこうそうをかかげた！ チャラリラリラ (*1) むらびとＡ「どうせむりだろ」 むらびとＢ「あいつ

大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、

発想力やある分野における能力について他の人が足元にも及ばないような才能を持つ人が、時間を守るとか、字をそこそこ綺麗に書くとか、人のことを怒らせないとか、そういった誰でもできるようなことがまるでできない、ということは結構よくあることで、こういうケースは要するに、Lv.10 の人は Lv.5 の呪文は唱えられそうなものなのに、Lv.30 なのに Lv.3 の呪文が唱えられないことがある、ということなのである。 また一方で、能力もあり物腰も柔らかく人の発言にもよく耳を傾け、際立つ能力を持ちながら一個人としても周囲の尊敬を集める人が、何らかの理由でその場所を去り、活気を失うのではないかと心配された残された人々が、残された自分たちが、という使命感以上に、はっきりと自分より上に位置する人がいなくなったことによる開放感から、今まで目指すことをしていなかったレベルにまで踏み込み始めて、聖人のように見えたあ

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

どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。

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