興味のある言語にJavaと書いておいたら面接で爆笑された - ひがやすを技術ブログ
Inspired by http://d.hatena.ne.jp/moriyoshi/20100204/1265242273 Javaエンジニアを募集してる会社の採用面接を受けた時の話。 転職エージェントに作れと言われて作ったシートに、「興味のある技術/言語」という欄があったんです。 「女の子ウケするコードの書き方」とか色々書いたけど、プログラミング言語の中で興味があるのはJavaだったので、Javaと書いておいたのですが、それを見た髭面サスペンダーの面接官のリアクションが酷かった。 面接官「Java・・・ふははっ！Java！」 面接官「Javaやってるんですか？ｗｗｗｗｗ」 俺「(唖然)は、はい・・まだ AppEngine にデプロイしたぐらいですが。。」 面接官「Javaはもう古い。大きめのiPhoneがむしろ日本でこそブレイクする」 比べてるのが違うだろうと思ったが、強引な話の展開
GAE/Jは破壊的イノベーション - ひがやすを技術ブログ
クラウドはバズワード的で何がいいのか良くわからないという人も多いことでしょう。その感覚は正しい。クラウドという言葉だけだと、意味が広すぎて、焦点がぼける。 例えば、同じように思われているAmazonのEC2とGoogle App Engineは、まったく違うものです。 Amazonのほうは持続的イノベーション、Googleのほうは破壊的イノベーション。 EC2は、過去の技術をそのまま使える(汎用的な仮想化サービス)ので、連続的な技術なのです。 それに対してGAE/Jは、できることをかなり制限して、しかもRDBMSをすててBigTableにのりかえるっていう非連続ぶり。 どっちがいいというものではありません。 クリステンセンのイノベーションのジレンマ-技術革新が巨大企業を滅ぼすときを読むと、マーケットリーダーである優良企業が、なぜ、ずっと成長を続けることができずに、破壊的イノベーションに滅ぼ
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
CTCと夜の決闘 - ひがやすを技術ブログ
昨日、CTCに「お前は最近、Railsに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、Railsを嫌っていると思っているRuby関係者は、実際多いようです。 「JavaからRubyへ」の本に対して、それはちょっとおかしいんじゃないのといったことはありますが、Railsを嫌いといったことはもちろんないはず。 呼び出されたのは、Rubyの話じゃなくて、Javaの社内フレームワークの話でした。 Struts、Spring、独自データアクセスフレームワークの生産性を何とかして改善したいという悩みでした。裏を返せば、今が低いと思っているということでしょうね。 あるいは、生産性が低いというより、大手SIerにとって必須の大規模開発をするのには、つらいということなのかもしれません。 CTCの話だと、SAStrutsを使えればいいんだけど、
NTTデータと真昼の対決 - ひがやすを技術ブログ
昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは
IT業界は成功するチャンスの多い夢のある業界 - ひがやすを技術ブログ
泥問題、あるいは老害問題で、すっかり評判を落としたIT業界(SI業界)。他の業界へ転職しようと思った人、IT業界には入るまいと思った学生も多く出たことでしょう。 ネガティブな面は確かにあります。老害は一朝一夕にはなくならないことも確かです。 しかし、一方で、努力すれば、成功するチャンスの多い夢のある業界でもあるのです。 いまだにソフトウェアの世界では「下を走ってくる」奴が上に行く余地がどっさり残っている。理由は二つある。 一つはインターネットという別の高速道路網が存在すること。ソフトウェア「エンジニアリング」に限って言えば、こちらの高速道路の方が学校という高速道路よりもずっと充実している。しかも料金ははるかに安い。わざわざ「学歴高速道路」に乗るのはかったるくて仕方がないだろう。 しかし、もう一つの理由を忘れてはならない。それは、ソフトウェア「エンジニア」になるための投下資本が実に少ないとい
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、本当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会
ITゼネコンを倒す方法をみんなで考えよう - ひがやすを技術ブログ
クロスコミュニティカンファレンスの「ITゼネコンをぶっつぶせ」BOFですが、時間が参加しにくいという意見があったので、18:40分開始に変更しました。また、時間も90分に延長し、後半の4,50分は、会場の皆さんとのディスカッションにあてたいと思います。 ITゼネコンの問題点を指摘したい方、ITゼネコンを倒すアイディアがある方、是非、会場にお越しください。 http://www.java-users.jp/contents/events/ccc2008spring/sessions.html#BOF2 また、当日参加できない方でも、いろんな意見をお持ちの方がいらっしゃると思います。「はてぶ」や「はてだ」のコメントなり、トラックバックなりで、引き続きみんなで考えましょう。 「ISIDだってITゼネコンじゃん」と思う方もいらっしゃるでしょう。昔は、そんなこともありましたが、最近は違います。「丸投
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
