男児たるものGoogle App Engine実践クラウドシステム構築を買うべきだ - ひがやすを技術ブログ
なぜなら、Google App Engineを学ぶために一番必要なのは、「何ができないかを知ること」だからだ。そして、この本にはそれが書いてある。それしか書いていないといってもいい。 App Engineは、Googleのインフラを最も効率よく使うことにフォーカスしている。Genericなアプローチではなく、Specializedなアプローチだ。 何かを得ようとするならば、それと等価の何かを支払わなければいけない。App Engineは、Googleのインフラを最も効率よく使うために、「いくつかのAPIが使えない」という対価を支払った。 だからこそ、App Engineを知るためには、最初に何ができないのかを知らなければいけないのだ。 あなたは、その制限という対価と引き換えに、Googleから安価なスケールするプラットフォームを手に入れることができる。 EC2はGenericなアプローチだ
もうエンタープライズJavaなんて捨ててしまえ - ひがやすを技術ブログ
これまでずっとなるべく言わないようにしていたのだが、もう平たく／明快に言うことにしました。 １）エンタープライズJavaはもう立ち直れないと思う。 だから、 ２）GAEを勉強してそのままクラウドというバズワードに踊らされる道を真剣に考えてみて欲しい。 これまでは、１）は言わずに、２）だけ言ってきた。で、「クラウド」の中でも、私が知っている「GAEで開発する」ことの楽しさをなるべく具体的に紹介するようにしてきた訳なのであるが、前半も言うことにしました。 その理由は、若い人に早く気づいて欲しいから。年を取ったら駄目、というわけではないが、あるフレームワークになれて、その経験が長くなってくると、進路変更は大変になる。ところが、多くの人が「もはやそのフレームワークは、時代にあっていない」と気づく頃には、そういう「進路変更大変状態」になってしまっていることが多い訳です。 というわけで、明言することに
GAE/Jは破壊的イノベーション - ひがやすを技術ブログ
クラウドはバズワード的で何がいいのか良くわからないという人も多いことでしょう。その感覚は正しい。クラウドという言葉だけだと、意味が広すぎて、焦点がぼける。 例えば、同じように思われているAmazonのEC2とGoogle App Engineは、まったく違うものです。 Amazonのほうは持続的イノベーション、Googleのほうは破壊的イノベーション。 EC2は、過去の技術をそのまま使える(汎用的な仮想化サービス)ので、連続的な技術なのです。 それに対してGAE/Jは、できることをかなり制限して、しかもRDBMSをすててBigTableにのりかえるっていう非連続ぶり。 どっちがいいというものではありません。 クリステンセンのイノベーションのジレンマ-技術革新が巨大企業を滅ぼすときを読むと、マーケットリーダーである優良企業が、なぜ、ずっと成長を続けることができずに、破壊的イノベーションに滅ぼ
プログラミングをやるのは大手では難しい？ - ひがやすを技術ブログ
私は，現在就職活動をしているものです．仕事は，プログラミングなど（最終的には一連の作業をやりたい）をやりたいと思っているのですがプログラミングをやるには大手では難しいのでしょうか？ ここ最近，大手を中心に何ヶ所か就職のセミナーに行きました．ある会社では開発を行っているらしいのですよくよく質問するとプログラミングは行わないらしいです． 難しいでしょうね。今の大手SIerは、単価の高い上流にほとんどシフトしています。それだけなら、別に問題はないのですが、新人にプログラミングなどを経験させずに、いきなり設計をさせることが多い。例えばこんな感じ。 どうも会社では、僕に上流工程を任せようとしているようです。しかしながら僕は、上流工程にはまったく興味がありません。上流工程のほうが付加価値が高いし儲かるということは一応知っているつもりですが、設計をしたり人の調整をしたり、なんていうことは好きでもないし、
2009年SI企業の不況の乗り切り方 - ひがやすを技術ブログ
不況の嵐が吹き荒れていますが、SI業界の中の人はどうお感じでしょうか。たぶん、仕事が減ってきている気はするけど、製造業ほどひどくないと思っているのではないでしょうか。 ただこれは、不況の波が押し寄せてくるのが、遅いだけです。 SI業界では、プロジェクトが一年くらいかかることも多いので、まだ不況じゃないときに受注した案件分でそれなりに食っていけるのです。しかし、SI業界の主なお客様である製造・金融業界は、案件を凍結したりなど、新規の受注案件はかなり減ってきているので、今やってる仕事が一息ついたら、やることがなくなってくるでしょう。 仕事が減ってまずすることは、人減らしですね。元請なら、下請けをきることが最初に検討されるでしょう。ある程度はこれで調整できますが、直ぐに限界が来ます。今の元請は、下請けに任せていたようないわゆる下流工程を自分たちでは行えないので、単純に下請けをきるだけではすまない
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
このままだとSIerの給与水準は下がっていく - ひがやすを技術ブログ
今後のビジネスの方向性として、たいていのSIerは、上流を強化するだとか、上流にシフトするだとか、上流に専念するなんて答える。 下流には、付加価値がつけられないから、自分たちの付加価値をつけるためには、上流を強化するしかないと思っているSIerの人も多い。 でも、みんなが同じ方向を向いたら、最後は価格競争になる。 日本の市場が厳しくなっているので、ブランド力よりも価格が重要視される割合が増えてきているのです。 ブランド力が通用しない市場は、自然と価格競争になるわけですが、今のSIerは、どこも同じような重量級の開発プロセスだから、開発プロセスでは差がつかない。後は、下請けの単価を下げるか、自分たちの給料を下げるかになってしまいます。 つまり、SIerの給与水準は、今後少しずつ下がっていく。負けているわけじゃないけど、ジリ貧みたいな。 ひがやすを氏の会社がプログラミング・ファースト開発を標榜
離職率の高さが人材を流動化させ業界が活性化する - ひがやすを技術ブログ
またアクセンチュアは「業界平均より離職率が高い」が、「IT業界内での人材の流動化は歓迎すべきことと考えている」と話した。IT業界でのキャリアパスには、コンサルタントやプロジェクトマネジャになるだけではなく、「ベンチャーキャピタリストになったり、アカデミックの道に進むなど色々な方法がある。さまざまな経験をした人材が転職によって交流することで、IT業界は活性化する」とした。 離職率の高さは、一見ネガティブに見えるけど、スキルアップを定期的に実感できるようにすることで、自分に自信をつけ、会社から卒業しやすくするってのは、良い考えですね。 社員にとっては、スキルアップで自分の価値を高められる。 一方、会社にとってもモチベーションの高い社員が一生懸命働くことで、生産性が高まり利益率も上がる。逆にモチベーションの低い社員は、止めざるを得ないようにきびしく競争させるんでしょう。 利益率が高いから、社員に
CTCと夜の決闘 - ひがやすを技術ブログ
昨日、CTCに「お前は最近、Railsに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、Railsを嫌っていると思っているRuby関係者は、実際多いようです。 「JavaからRubyへ」の本に対して、それはちょっとおかしいんじゃないのといったことはありますが、Railsを嫌いといったことはもちろんないはず。 呼び出されたのは、Rubyの話じゃなくて、Javaの社内フレームワークの話でした。 Struts、Spring、独自データアクセスフレームワークの生産性を何とかして改善したいという悩みでした。裏を返せば、今が低いと思っているということでしょうね。 あるいは、生産性が低いというより、大手SIerにとって必須の大規模開発をするのには、つらいということなのかもしれません。 CTCの話だと、SAStrutsを使えればいいんだけど、
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
