ブロゴスフィア全部で一つの作品だ : 小野和俊のブログ
これまでサン･マイクロシステムズが掲げてきたビジョンの一つに、 「The Network is The Computer」というものがある。 この言葉の意味するところは、マザーボード上でCPUやチップセットが接続されて一つのコンピューターを形づくっているのと同様、ネットワークに接続されたコンピューターは相互に接続されて全体を形成しており、ネットワーク全体で一つのコンピューターであると考えられる、というものだ。 ブログの世界に足を踏み入れて感じたのは、書籍や絵画といったものが作品単体として独立していたのに対し、ブロゴスフィア(ブログの世界)のコンテンツは、ブログのエントリも、コメントも、ブックマークコメントも、ブロゴスフィアを構成する諸要素が有機的につながっており、まるでその全体が一つの作品であるかのようだ、ということだった。 リンクを辿っていつの間にか別のブログに移動し、コメントでの指摘に
小野和俊のブログ:ふたつ下のヒューマンマネジメント:5分で人をダメにする技術 - 優秀な部下の能力の芽を摘み取る無能な上司
人の発言に噛み付くようなエントリはあまり書かないことにしているのだが、こんなテクニックを使うマネージャが増えていくことを少しでも阻止したいと強く強く思うので書く。 芦屋広太 ひとつ上のヒューマンマネジメント : 5分で人を育てる技術 (5)言うことを聞かない“自信過剰な部下” 上記の記事は、頭は良いが自分の言うことを聞いてくれない部下を、無能な上司が周囲にネチネチと根回しして物言わぬ奴隷としてこき使っていくためにはどのような小賢しくて汚いテクニックがあるのかを、「マネジメントのプロ」がニヤニヤしながらケーススタディを用いて解説する極めて醜悪で下品な最低の記事である。やや過激な言い方ではあるが、少なくとも私は、そこまで書いても書き足りないくらいの生理的嫌悪感を感じる。 マネジメントが必要となるのは、他人同士でありながら一つの目標に向かっていこうとする行為がそこにあるからであって、仕事が一番大
小野和俊のブログ:持続可能な成長を実現する「ラストマン」という自分戦略: 八百屋になりたい人が肉屋に入ってしまったらどうするか?
私はその戦略をラストマン戦略と呼んでいる。 大学を卒業してサン･マイクロシステムズに入社してすぐにわかったことは、Java を生み出した会社でソフトウェア開発をやろうと思って入社したのに、日本サンはソフトはほとんどやっておらず、ほぼ100%ハードウェアを販売するための会社だったということだった。 野菜を売りたくて八百屋に入ったつもりなのに、間違えて肉屋に入ってしまった。このようなときにどのように行動すればよいか？ 1. 肉屋に入ったのだから、とりあえず肉屋を目指す 2. 八百屋への転職活動を開始する 3. 肉屋の中で野菜についての No.1 を目指す 一番多いのはパターン1の人で、入社の直前直後は熱くソフトウェア開発を語り合った同期の多くは、今ではハードウェアのスペシャリストへの道を目指している。 ラストマン戦略とは、ある所属組織内で自分が一番(最後に立っている人 = ラストマン)になれそ
小野和俊のブログ:仕事に行き詰ったときのための4つの対策
仕事が思うように進まないということは誰にでもあることで、時としてはそれは集中力の問題やモチベーションの問題といった比較的深刻な問題が原因となっていることもあるわけだが、ちょっとした工夫で状況が一変してしまうこともかなり多い。私がこれまで人から聞いたり、自分で見つけたりしたものの中で、今でも結構役立っているのは次の4つの対策である。どれも当たり前と言えば当たり前だが、意識してやってみると結果がかなり変わってくる。
小野和俊のブログ:Ruby に今一番ほしいもの
この半年ほど Ruby を使っていて思うのは、コーディング量が少なくてすむし、プログラム言語的な手触りが良いし、まず作ってみてどれくらい感動できるソフトなのかを確認しながらソフトウェアの仕様自体を見直してスパイラルでつくっていくという開発プロセスも取りやすいし、ライブラリも揃ってきているし、Ruby on Rails のバランス感覚はすばらしいし、といったことである。そういう意味では大絶賛なのである。 それでも、普段 Java をメインで使っていて、時々 Ruby にスイッチすると顔をしかめてしまうような猛烈なストレスに襲われるのは、標準的で、無料で、安定しており、好みに合わせてカスタマイズでき、リファクタリング機能 *1をサポートした IDE が存在しないからである。 もちろんこれは言語そのものの問題ではないが、結果的には、使用する言語を選択する際に、要求の変化などの外部的な変化には強く
小野和俊のブログ:プログラマーとゲーマーは似ている
昔からよく思うのは、プログラミングの快感とゲームをプレイしている時の快感には多くの共通点があるということである。 小学生の頃、ロトのつるぎを手に入れたのだけれど寝る時間になってしまい、次の日は学校に行ってから家に帰るまでの時間、ロトのつるぎを装備したら今まで倒すのが大変だったモンスターとの戦いがどのくらい楽になるのだろうと想像ばかりして、授業が終わると一目散に家に帰ってテレビに噛り付いて新しい武器の切れ味を試した。 これはいわば、試してみたい欲求である。 ゲームをしていてうんざりしてしまうときがあるのは、例えば、工夫する余地がなく、ただひたすらに時間をかけなければ次に進めないような種類のゲームをやっているときである *1。物語を先に進めるのに、なぜここまで単純労働を繰り返さなければならないのかとやきもきしながら、それでも義務感でエンディングまでやってしまう傾向にある私のような性格だとなおさ
交響曲的プログラミング : 小野和俊のブログ
1980年代後半、私が初めてプログラミングに触れた頃、 プログラミングとは人とコンピューターとの一対一の対話であった。 プログラマーにとっての最大の関心事は、 如何に美しくコンピューターという楽器を奏でるかにあり、 鍵盤を叩いてその音色を確かめるように、 キーボードを叩いてコンピューターに指示を送り、 その実行結果を確かめ、 速度を調整し、タイミングを調整し、 CPU やメモリの負荷を考え、 気遣い、対話をする相手は、 一台のコンピューターであった。 これはいわば独奏的プログラミングである。 ソフトウェアについては、 ライブラリとは、その作者のコンピューターとの対話の静的な結晶であり、 サービスとは、その作者のコンピューターとの対話の動的な結晶であり、 そして今私たちが何かを作ろうとするとき、 ライブラリの恩恵を受け、サービスをマッシュアップし、 それらを支える場としてのプラットフォームや
味見ができる時代のソフトウェア開発 : 小野和俊のブログ
スーパーマリオ似の N 氏の話は私にとっていつも刺激的で、 彼はある時こんな話をしたのだった。 料理、音楽、絵画など、 数多くの芸術分野において日本は世界で通用する人物を排出している。 しかしソフトウェアの世界でこれまでそのような人物が出てきにくかったのはなぜか。 それはソフトウェアでは、味見ができないからである。 よい店を訪ねて美味に舌を打つ。 これらはいずれも味見である。 そして日本人は、味見ができるものに対して能力を発揮するのが得意である。 今や時代はオープンソース。 ソフトウェアの味見ができる時代である。 だからこれから先の日本のソフトウェア開発を、 私は楽しみにしているのだと彼は言う。
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
小野和俊のブログ:アプレッソのジョエルテスト判定結果
今週末は熱海の温泉に行ってきた。 行き帰りの新幹線で読んだJoel on Softwareは衝撃的に良かった。 この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。 中でも第三章に書かれているジョエルテストが面白かったので、 これをアプレッソに当てはめて判定してみることにした。 現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。 該当する項目が2から3の会社が圧倒的に多いということなので、 判定結果としてはかなり良い方だと思う。 しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、 「今のままで特に大きな問題があるわけでもないし、 新しい方法を導入することにはリスクも伴う。 このままでも良いのではないか。」 という理由で導入を躊躇したものも多かった。 これらはどの項目についても、マネージャーがどんなに反対したとしても
小野和俊のブログ:私がシリコンバレーで学んだ5つの教訓
1. 会議を最適化する ミーティングのゴールを明確に設定する。 ミーティングの最後に必ず結論と ToDo を確認する。 ミーティングの回数をできるだけ少なくして時間もできるだけ短くする。 ミーティングのトピックごとに関係する人だけ集めて最少人数で議論を行う。 (途中であなたはこのトピックに関係ないから退席して良いです、と指示がでる) 会議を最適化することで労働時間中の実作業時間を最大化させ、労働時間全体を圧縮する。そして、早く帰る。 この体験は、その後自分が会社で会議をしていく上で大きく役立った。 XM(eXtreme Meeting)にも、この時の体験が直接的にも間接的にも影響を与えたと思う。 アドバイザーとしてプロジェクトに参加していたテクニカル・コンサルタントが、技術的に明らかに間違った発言をしたことがあった。 私を含む日本から来ていた何人かのメンバーは、あんな基本的なこともわかって
小野和俊のブログ:続・プログラム・デザイナー宣言
前回書いたプログラム・デザイナーと職人プログラマーとプログラム・デザイナー宣言と同じような感覚を持っている人は意外と多いのではないかと思って探してみたところ、はてなの伊藤さんのエントリ(こちらも)が見つかった。伊藤さんとは何度か話をする機会があったが、ウルティマ・オンラインの話で盛り上がってしまって、今までIT関連の話はしたことがなかった。ブログを読んでいて、伊藤さんもきっとプログラム・デザイナーなのだろうな、と思った。 UNIXにみる世代間の断絶にならって職人プログラマー/プログラム・デザイナー/UIデザイン・プログラマーを表にすると次のようになる。 比較項目 職人プログラマー プログラム・デザイナー UIデザイン・プログラマー 譲れない点
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
