誰も言いたがらない「Sony が Apple になれなかった本当の理由」
Sony や Panasonic が家電のコモディティ化で大赤字を出して苦しむ一方で、今や株価総額が日本の大手家電メーカー８社の株価総額の３倍以上にもなった Apple（参照）。 この差に関しては、私も含めて、リーダーシップの欠如だとか、ゼネコン型のソフトウェア開発スタイルが悪いとか、ソフトウェアの重要性を理解しない経営者、などのさまざまな考察がされているが、その根底にあるのは、「大企業は一度正社員になった人は会社が倒産の危機にでもさらされない限り解雇してはいけない」という日本特有の雇用スタイル。 家電業界の成り立ちは、日本の家電メーカーが業績をのばしていた高度経済成長期とは大きく変わってしまった。ソフトウェアがものすごく重要になったのはもちろんのこと、ハードウェアに関しても、中国を含む東南アジアが「世界の工場」となった今、「何を自分で作り何をアウトソースするか」がコスト削減の上でも差別化
私が事故後、脱原発派に転向した一番の理由
先日のエントリーに、「論理的に考える力のない人が、 『放射能は危険』→『原発は不要』→『脱原発』 となっているのは理解できます。 普通に論理的に考える力のある人は、 『脱原発したときのリスク』を考え、 脱原発をしないほうがよいのでは？という意見の方が多いと感じています。 中島さんのような方が、なぜ、脱原発一直線なのかが理解できません。 脱原発について書かれるのはよいのですが、 一度、なぜ脱原発を訴えているのか？についても、この場に書いていただけないでしょうか？」というコメントをいただいたので、今回はその質問に答えてみる。 実は、福島第一原発での事故の第一報を聞いた時に最初に私の頭に浮かんだことは、「この事故は、日本だけでなく、世界全体の原子力技術の発展に大きなブレーキをかける事になる。１０００年に一度の津波のためにたまたま起こった事故のために、日本のエネルギー政策を変更したり、原子力発電を
Oracleの「Android訴訟」についてひと言
今日のこちら（米国西海岸）でのもっぱらの話題は、Oracleの「Android訴訟（詳細）」だが、これに関しては、私も含めて「やはり来たか」と見ている専門家は多い。 そもそも、スマートフォン以前の携帯電話用のJavaがプラットフォームとして成功しなかった理由の一つは、J2MEが根っこのところで、NTTドコモ独自のDoJaとモトローラ主導のMIDPに分岐してしまったことにあるし、同じJ2ME間でも実装の差異が大きく "write once, run everywhere" が机上の空論になってしまったことにある。Sunがちゃんとリーダーシップを発揮できなかったためである。 その意味では、J2ME/MIDPとコンパチビリティがなく、Sunから正式にJavaをライセンスしていないAndroidはけしからん、というのは（今はOracleの一部になった）Sunから見れば当然のこと。 「J2MEの時に
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
「金メダリストは『練習が楽しくてしかたがない』からこそ強くなれた」説
技術評論社の WEB+DB PRESS 向けに連載コラムを書きはじめたのだが、その最初のコラムがウェブで公開されたので、リンクを張っておく。 第一回 一生の仕事を選ぶということ 担当の人の「この業界で働く若手のエンジニア向けのメッセージ」を書いてほしいとのリクエストに答えるつもりで書いたのだが、「説教臭くなくて、ちゃんと伝わる」文章を書くのが難しくて結構苦労したので、ぜひとも読んでいただきたい。 この話の核となる部分は、私の「マラソンで金メダルを取る人たちって『過酷な練習に耐える精神力がある』から頂点に立てるんじゃなくて、『他の人たちにとっては苦痛でしかない練習が実は楽しくて仕方が無い』から頂点に立てるんじゃないか」というセオリーにもとづいている。高橋尚子が現役のころの話を聞いていて、つくづく「本当にこの人は走ることが好きなんだなあ。だからこそ誰よりもたくさんの練習をすることができて、その
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
