タグ

ブックマーク / blog.livedoor.jp/lalha (14)

  • 「あなたがあたえる - 大富豪ピンダーの夢をかなえる5つの秘密」ボブ・バーグ、デイビッド・マン : 小野和俊のブログ

    「あなたがあたえる 大富豪ピンダーの夢をかなえる5つの秘密」読了。献感謝。 最初このが私のところに送られてきたとき、「なぜこのが私に?」というのが率直な感想だった。というのも、私はいわゆる成功の類に基的に興味がなく、うまくいくためのやり方なんて人それぞれなのではないかと思っているからだ。 だが、私の予想を裏切って、書は面白かった。 5つの事例を通して繰り返されるこのメッセージを「受け取り」ながら考えるのは、自分は何を「受け取り」、何を「与えたか」、ということである。 たとえば、ブロガーとしての自分はどうか。 他の人が書いた記事を面白いと思ったり、ブログで紹介されたに興味を持ったりするのは「受け取る」行為だ。面白いと思ったものを自分の中にしまっておくと「受け取る」だけになってしまうが、周囲の人に面白かったということを伝えたり、自分のブログでも紹介したりすれば、それで興味を持つ人

    「あなたがあたえる - 大富豪ピンダーの夢をかなえる5つの秘密」ボブ・バーグ、デイビッド・マン : 小野和俊のブログ
    h-yano
    h-yano 2008/07/19
    「受け取る」ことよりどれだけ「与えたか」ということ/自分は何を「受け取り」、どんなものを「与える」ことができるのだろうか
  • 小野和俊のブログ:睡眠時間削減で得られるものと失われるもの

    コメント一覧 (16) 1. t.t. 2008年02月18日 20:06 1.睡眠時間を削減した分を全て仕事・勉強に費やした場合のみを想定している 2.「可能性」は確かにあるが、それはあまり高くないと思われる 3.睡眠時間の削減と事例があまり関係ない 2. あきら 2008年02月18日 20:30 アイマスクと耳栓をして普通に寝ちゃだめですか? 質のよい睡眠をって考え方は重要だと思います また仕事以外のOSSや家族への貢献に使うのはどうでしょうか? 3. y 2008年02月18日 22:25 同意します。活動時間が長くても、当は必要でもなんでもない事柄に多くの時間を費していたら意味がありません。睡眠時間を減らすことで思考力が低下し、優先順位をおかしくとるひとをよくみます 4. 昆 2008年02月18日 23:03 睡眠時間を減らして、お風呂でリラックスする時間を増やせば、集中時の

    小野和俊のブログ:睡眠時間削減で得られるものと失われるもの
  • 小野和俊のブログ:IT業界の大企業での生々しい話を5つほど

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

    小野和俊のブログ:IT業界の大企業での生々しい話を5つほど
  • 小野和俊のブログ:持続可能な成長を実現する「ラストマン」という自分戦略: 八百屋になりたい人が肉屋に入ってしまったらどうするか?

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

    小野和俊のブログ:持続可能な成長を実現する「ラストマン」という自分戦略: 八百屋になりたい人が肉屋に入ってしまったらどうするか?
  • 小野和俊のブログ:続・プログラム・デザイナー宣言

    前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点

    小野和俊のブログ:続・プログラム・デザイナー宣言
    h-yano
    h-yano 2006/09/15
  • 「優秀な人」について考える : 小野和俊のブログ

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

    「優秀な人」について考える : 小野和俊のブログ
    h-yano
    h-yano 2006/09/15
  • カッとしてしまう条件 : 小野和俊のブログ

    1. 勝てないと感じている相手に鋭い指摘をされたとき プライドが高い人に起きやすい。 この手のケースでは論理的にカッとなるから手に負えない。 実はお互いに勝てないと感じていたりするともうゴジラ対キングギドラである。 口から絶え間なく吐き続けられる燃えさかる言葉の炎。 2. 対応能力のキャパシティを超えた事態が発生したとき パニックになって周囲に当たり散らす。 逆に卑屈になって極端に低い姿勢で謝り続けることも。 周囲から見ていると別に大したことじゃないのにと思えてしまうことが多い。 怒りの炎は引火する。 昨日あいつがあんなに怒っていたじゃないか。 だから今の俺の怒りだって抑えずに爆発させてしまっていいのだ ムカーッ! 連鎖する怒りの垂れ流し。 4. 極度に忙しくてカリカリしているとき 自分の作業が遅れているだけなのに他の人も道連れにしようとしたりする。 暗黙に自分の仕事が終わるまでみんなを帰

    カッとしてしまう条件 : 小野和俊のブログ
    h-yano
    h-yano 2006/09/15
  • 小野和俊のブログ:諸君 私はプログラミングが好きだ

    諸君 私はプログラミングが好きだ 諸君 私はプログラミングが好きだ 諸君 私はプログラミングが大好きだ 設計が好きだ 実装が好きだ デバッグが好きだ コンパイルが好きだ リファクタリングが好きだ パフォーマンスチューニングが好きだ ペアプログラミングが好きだ クラスの名前を考えるのが好きだ 自分が書いたソースを眺めるのが好きだ Java で C で C++ で C# で PerlRubyPHPPython で Lisp で VB で この地上で行われる ありとあらゆるプログラミング行為が大好きだ 轟音と共にバグを吹き飛ばしていくのが好きだ 空中高く放り上げられたバグが 効力射でばらばらになった時など心がおどる プログラマーの操る キーボードが コンパイルエラーを撃破するのが好きだ 悲鳴を上げて 燃えさかるソースコードから飛び出してきたエラーを テキストエディタで薙ぎ倒した

    小野和俊のブログ:諸君 私はプログラミングが好きだ
    h-yano
    h-yano 2006/09/15
  • 小野和俊のブログ:私がシリコンバレーで学んだ5つの教訓

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

    小野和俊のブログ:私がシリコンバレーで学んだ5つの教訓
    h-yano
    h-yano 2006/09/15
  • 小野和俊のブログ:この先10年で、働くことの意味がきっと大きく変化する

    AdSense や各種アフィリエイト、オークションサイトが登場したことで、 物を書く人や情報提供サイトを運営する人、個人で物を仕入れて販売する人たちは 今までにないまったく新しい仕事の仕方の選択肢を手に入れた。 会社に所属したり会社と契約したりしなくても、 コンテンツやサービスを提供したり、 個人で仕入れた物品をネットで販売したりすることによって、 それだけで十分に生活することができる収益を手にする人が出てきている。 会社に勤務しながらも、 個人でのネットでの収入が家計のポートフォリオの中で無視できない 位置を占めてきている人もすでに数多く存在する。 賃金水準が相対的に低い国では、 AdSense による収入が天から舞い降りた奇跡のように扱われているという。 日でもネットでの収入で毎月数百万円を稼ぐ人があらわれてきている。 これらのネットで提供される仕組みは、 個人が企業で働く意味を改め

    小野和俊のブログ:この先10年で、働くことの意味がきっと大きく変化する
    h-yano
    h-yano 2006/09/15
  • 小野和俊のブログ: むしゃくしゃすることは良いことである

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

    小野和俊のブログ: むしゃくしゃすることは良いことである
    h-yano
    h-yano 2006/09/15
  • 小野和俊のブログ:徹夜をしてはいけない理由

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

    小野和俊のブログ:徹夜をしてはいけない理由
  • 小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい

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

    小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
  • 小野和俊のブログ:プログラマー風林火山

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

    小野和俊のブログ:プログラマー風林火山
  • 1