俺は守りに入らない、これが今の俺だ - ひがやすを技術ブログ
Seasar Conferenceが久々に開催されます。 興味のある方はぜひお申し込みください。 http://seasar.connpass.com/event/19317/ 正直、話す内容は、個々人にまかされているので、どんな感じになるのかはやってみないとわからないのですが、私は、今取り組んでいることを話したいと思います。 今、私が取り組んでいるのは、 「ダンスマシン(すっげー仮)の開発」 イメージはこんな感じ。 Padをたたきながら、ダンスを組み立てていきます。ダンスは、1,2小節ごとに組み立てていくことがほとんどなので、曲を作るのと同じような感じで組み立てていくことになります。出来上がったダンスは、Audioムービーの静止画の上に、シルエットで踊らせるようなことを考えています。 いわゆる、VJ用のマシンな訳ですが、DJのソフト&ハードと、MIDIで連動させることができ、曲とダンスを
良いエンジニアの育て方 - ひがやすを技術ブログ
人を育てるというのは、とても難しい。 なぜなら、育てる方も未完成な人間だから。 ちょっと経験値のある未完成な人が、経験値の少ない未完成な人と、ともに冒険をし、ともにレベルをあげていくことが、人を育てるってことだと思う。 人を育てようと思うと、どうしても上から目線になってしまう。上から目線だと気持ちも相手に伝わりにくい。気持ちが伝わらないと相手もうまく成長してくれない。 だから、人を育てる機会があったら、ともに冒険をする仲間を持ったと考えよう。きっとその方がうまくいく。 それでは、自分の話をしよう。自分というよりは自分たちの話かな。 2010年、自分は、昼間、ブラ三をやりながら、新規ビジネスの企画を考えたり、プロトタイプを作っていたりしていた。ブラ三をやっていたのは、当然ソーシャルアプリというものを学ぶためだ。ブラ三の能力はかなり向上したけど、仕事ではたいした結果が出せなかった。特に企画考え
SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
新しいサービスを作るのになぜ今が絶好のチャンスなのか - ひがやすを技術ブログ
おとといのエントリで新しいサービスを作る側に回ろうよという話をしました。 受託開発に未来はない? - yvsu pron. yas 新しいサービスを作るというのも難しい話ですが、今は、絶好のチャンスなんですよ。 ガラケーがピークを過ぎ、徐々に衰退し始めている。iPhone/AndroidのようなSmart Phone、iPadのようなSmart Bookも広まりつつある。Goole TVのようなSmart TVも出てきます。 広まりつつあるのがポイント、広まってから新しいビジネスを始めても既に手遅れ。 常識的な人は、国内のSmart Phoneのマーケットは1000万台くらい年間売れてからだよねと思っていることでしょう。2010年は300、400万台程度と予想されているので、まだまだマーケットが小さいと思っているわけです。 国内だと確かにそうですが、グローバルなマーケットで考えると国内の1
受託開発に未来はない? - ひがやすを技術ブログ
私は1年以上、エンタープライズの世界(企業向けSIとか)から離れ、ずっとGoogle App Engineをやっています。今は、Google App Engine + Webkitベースのブラウザで動くHTML5を使ったグローバルな新サービスを提供しようとしていて、新規事業立ち上げのために日々奮闘しているので、エンタープライズな世界に戻ってくることは、基本無いでしょう。 私は、受託開発に未来はないと思っているので、自分でサービスを提供する側に回ろうとしているわけです。受託開発に未来はないといっても、文字通り未来はないという意味で、すぐになくなるわけではないし、生きてくために必要な部分も多々あると思います(うちの会社もSIerだし)が、今後は撤退すべきだろうという判断です。 受託開発になぜ未来がないかというと、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものが生き
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
SIerの解体と再生 - ひがやすを技術ブログ
ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの
ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを技術ブログ
ぼくは水曜日にTokyo Cloud Developerの集まりに出た。 そこで、LLのひとから、「Google App Engineは、Python版以外にJava版も出たけど、サンプル見たけど、たくさんコード書かなければいけなくて、正直どこがいいのか教えて欲しい」という質問があった。 blogに名前を出していいかの了解を得ることを忘れたので、ここには、LLの人としか書けない。 ぼくは、そこで一言申し上げた。あるいはそれは、「申し上げた」というような生やさしいものではないかも知れない。端的な言い方をすれば、ガツンと言ってやった。 客観的に見て、ぼくはガツンと言ってやったと思う。LLな方々を前に、「いまどきのフレームワークは進化しているから、言語による差なんて余りない。仮に、Javaのほうが二倍コードを書く必要があったとしても、開発の中でコードを書いている時間より考えている時間のほうが圧倒
自分の書きたいコードを書け - 脱職業プログラマのすすめ - ひがやすを技術ブログ
良く仕事以外のプログラムをしたことない人っているじゃないですか。ここでいう職業プログラマとは、仕事以外では、プログラムをしない人のことを指しています。 仕事以外でもプログラミングをしている・勉強している人、は、職業Onlyプログラマではなく、職業でもプログラムをしているけど、それ以外にも努力をしている人です。 それは、もちろん何の問題もないんだけど、それだけでは実力はつきません。たぶん、コードを書きながら自分が成長している気がしてないでしょう。あなたの直感は正しい。 何らかのフレームワークを使えば、それなりにできることが増える、それももちろん成長です。ただし、知識のね。プログラミングの力はそれほど変わっていないはず。 自分の経験で言えば、多くの人に読んでもらえないコードは、いくら書いても、実力につながりにくい。人に見せようとするコードは、書いているだけで、いろんなことを考えるし、それが、力
2009年SI企業の不況の乗り切り方 - ひがやすを技術ブログ
不況の嵐が吹き荒れていますが、SI業界の中の人はどうお感じでしょうか。たぶん、仕事が減ってきている気はするけど、製造業ほどひどくないと思っているのではないでしょうか。 ただこれは、不況の波が押し寄せてくるのが、遅いだけです。 SI業界では、プロジェクトが一年くらいかかることも多いので、まだ不況じゃないときに受注した案件分でそれなりに食っていけるのです。しかし、SI業界の主なお客様である製造・金融業界は、案件を凍結したりなど、新規の受注案件はかなり減ってきているので、今やってる仕事が一息ついたら、やることがなくなってくるでしょう。 仕事が減ってまずすることは、人減らしですね。元請なら、下請けをきることが最初に検討されるでしょう。ある程度はこれで調整できますが、直ぐに限界が来ます。今の元請は、下請けに任せていたようないわゆる下流工程を自分たちでは行えないので、単純に下請けをきるだけではすまない
「勉強ができる」ということは「努力し続ける力がある」ということ - ひがやすを技術ブログ
勉強って、ほとんど頭使わないよね。 人様に言われたことを、やればいいんだから。 あんなに頭使わなくていいのに、親は小遣いくれるたし、会社も給料くれた。 親たちはそういう甘い経験をしてきたものだから、つい子供にも「勉強しろ」って言ってしまう。頭を使ったことがなかったんだね、親たちも。 勉強の意味を狭く捉え過ぎていると思うな。「勉強ができる」ということは「努力し続ける力がある」ということですよ。学生のときの勉強だけが勉強じゃない。 学生のころ勉強ができて、高学歴な人が、社会人になってぱっとしないということはあるかもしれない。その原因は明らかですよ。社会人になって勉強しなくなったから、だめになってしまったのです。 学生のときに必要な勉強と、社会人になってから必要な勉強は違う。それぞれの環境やステージによって必要とされる勉強は違うのです。 学生のころ勉強できたとしても、社会人になって勉強することを
日本IBMのリストラが始まった - ひがやすを blog
「日本で「キャリア選択援助計画」を終了させる。浮いた１億ドルの多くを日本での「Ｗｏｒｋｆｏｒｃｅ Ａｃｔｉｏｎ」（＝リストラ）に使い、日本ＩＢＭの収益構造をより競争力のあるものにする。」 かねてから噂のあったIBMのリストラですが、現実におきてるようです。これは、景気後退局面に対するすばやい対応なのでしょうか。 直接の原因は、景気かもしれませんが、根本は、アメリカ流の株主至上主義じゃないかな。株主を大切にするのはもちろん重要なんだけど、株主のため、過度に短期の数字を良くみせようとするところにあるんじゃないかと思っています。これは、IBMに限った話じゃないけどね。 米IBMは、2005年にも欧州を中心に、1万〜1万3000人のリストラをやっています。 とはいえ、会社の業績が悪い訳ではない。米IBMの第一四半期決算は、1株あたり利益、売上高とも前年を上回っている。それでも、株主のため、飽くなき
40になる前に宝くじを買っておけ - ひがやすを技術ブログ
明日で40になる前に、一言言っておきたいことがある。 40になる前に宝くじを買っておけということだ。 「宝くじを買う」というのは、もちろん比喩で、「チャンスをつかもうと行動する」ことをあらわしている。 前に、エンジニアの未来サミットで、よしおかさんもいっていた「宝くじは買わなきゃあたらない」。宝くじは、ほとんど当たるものではないけど、でも、買わなければ絶対にあたらない。これと同じで、「チャンスをつかもうと行動しても、成功する可能性は低いかもしれないけど、でも行動しなければ絶対に成功しない」ということじゃないかと思う。 これは、「成功する可能性は低くても、まずは行動しろ」というメッセージだ。 今、自分は、仕事で何をするかはすべて自分で決めることができる。それで、自分のやりたいこととしてオープンソースにかかわっている。プログラマとしては、かなり恵まれた立場だろう。こうなれたのは、オープンソース
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
勘違い化が進む池田信夫 - ひがやすを技術ブログ
「全文を出さずパーマリンクなし」という仕様が、日本のすべての新聞・テレビ・通信社のサイトで例外なく採用されていることだ。その編集委員は「新聞協会で申し合わせたわけではないが、暗黙の談合みたいなものだ」という。競争をきらう風土によって、日本のウェブはいびつなガラパゴス化した進化を遂げているのである。 ガラパゴス化した進化というのは、日本の携帯のように、ほかでは通用しないような独自の進化を遂げたものについて言うんでしょう。 日本のメディアのサイトが、「全文を出さずパーマリンクなし」というのは、単に時代に後れているだけで、進化とはいわないよ。 新聞サイトも、購読料モデルから検索に最適化してアクセスを稼ぐ方向に転換し、グーグル化しているのだ。 ページビューを稼ぐ方針にサイトを変えることを「グーグル化」というのか、知らなかったよ。たぶん、おいらが無知なせいだと思うけど、違和感あるな。 これに対して、
NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ
昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質
下請け構造がなくならないのは大手SIerの社内人件費単価が高いから - ひがやすを技術ブログ
今のSI業界は、大手SIerを中心とした多重下請け構造ですが、その原因の1つには、「大手SIerの社内人件費単価の高さ」があります。 ここでは「社内人件費単価」の意味をプロジェクトに課せられる社員一人当たりの単価とします。 大手SIerでは、社内人件費単価が外注の単価と比べて、べらぼうに高いことが多い。だから、プロジェクトマネージャも利益を出すために、社員の数を抑え、できるだけ外注しようとするのです。 なぜ、大手SIerの社内人件費単価が高いかというと、1つは、大会社であるため、オーバーヘッドが大きいことです。もう1つは、もともとの人件費の単価が高いこと。優秀な人を集めようとすると、必然的に単価を上げざるを得ません。 それ以上に大きな原因は、単価を下げようとするインセンティブが働かないことです。 大手SIer通しの競争もありますから、ぬるま湯なビジネスをやっているわけではありません。 見積
優秀なプログラマの給料が低いわけ - ひがやすを blog
昨日の開発生産性が低い方が収入が多いって変だよねのエントリでは、企業レベルの話だと、生産性が低いほうが売上が上がるという話をしたんですが、実は同じようなことが、個人レベルでも言えます。 生産性の高い超優秀なプログラマより、社交性の高いそこそこ優秀なプログラマのほうが、評価が高く給料も多くもらえるようになるのです。さすがに、個人レベルだと生産性の低い人が評価が高いということはあまりないけどね。一時的には残業が多くて給料が増えるときもあるかもしれないけど、それはあくまでも一時的なこと。 評価が高いということは、上司にそれだけ認めてもらっているということですが、それではなぜ、優秀なプログラマは、上司に高く評価されないのでしょうか。 「上司に技術をきちんと評価する力がないから」それも多少はあります。でも、主な原因ではありません。会社によって違うと思いますが、評価における技術力の部分は2,3割りに過
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
