８つの質問で、Java SI業界の現状を知る - レベルエンター山本大のブログ
Webサービス系の会社の隆盛があって、人材流出が騒がれたのが１−３年ぐらい前だろうか。 SIの産業の人材動向が、今どうなってるかって？ 大方の予想より凄惨ですよ。 それが分かる方法がある。JavaWeb技術者に技術力を問う８つの質問によってだ。 SI業界のエンジニアの平均レベルを知りたくって、いろんな会社さんのJavaWeb開発者（経験者）向けに以下のような８つの質問を継続的にしている。 対象者としては、Java経験３から１０年ぐらいの現役バリバリのはずのJavaエンジニアだ。 その８つの質問というのはこんな問題だ。 JavaWeb技術者に技術力を問う８の質問 インターフェイスのメリットを一言で表して下さい。（筆記解答） HttpRequestオブジェクトからPostされたデータを取得するServletのメソッドは何ですか？（筆記解答） Sessionのスコープを端的に説明してください。（
この国から"SE"を滅ぼしませんか？ - Scribbles
この国において、"SE"と呼ばれる職種は廃絶すべきだと思います。USのように設計も実装もできる「プログラマー」「ソフトウェアエンジニア」という職種に統一すべきで、Excelで「設計書」なるものを書くことしか能のない自称"SE"はfireすべきです。 参考まで、USで"Systems Engineer"というと、会社にもよりますが概ね基盤系のエンジニア（ネットワークエンジニアなど）を指すようです。 僕の経験上、該当者は概ね入社3～5年目の女性"SE"に集中していますが、この人達は顧客のいいなりに実装不可能な「設計書」書き上げて、それを下請け（パートナー；僕は「助っ人」として敬意を持って接しています）に丸投げするというひどい有様。以前、僕がTISの３次請けで働いていた時、２次請けの凄腕エンジニアがTISプロパーの口達者な若手女性"SE"を閉口させるまで責め立てていた（要旨は「ロクに実装もしたこ
はてなブログ | 無料ブログを作成しよう
うめぇヨーグルトソースでもいかがですか。個人差にもよりますが。もしよろしければ。 お久しぶりです。 最近うんめぇ〜と思ってるヨーグルトソースがあるので、書いていこうと思います。 ヨーグルトとハーブ類をもりもり使うので、そういうのが食べられない方にはうんめぇソースではないです。ごめんなさい…。もしよろしければお茶だけも…旦~ 【用意する…
モダンなSIをやりたいなら今すぐGxPに行くべき | nagaseyasuhito Daily works.
さて、突然ですが2012年3月末をもちまして丸々4年間お世話になったグロースエクスパートナーズ株式会社(GxP)を退職します。 転職するにあたり色々な会社を見ていくうちにいままで見えていなかったGxPという会社が見えてきて結構いい会社だよなあ、と改めて感じたので思い出がてら簡単にご紹介します。結論から言うと 今風にSIやりたいならGxP一択しかないよ！ ということです。 JavaでエンタープライズなSI会社です [snap url=”http://www.gxp.co.jp/”]「時代はGUNDAM、Java(笑)はオワコン」とか言う人もいてJavaでSIやってる会社というと不安を感じる人もいるようですが、実際なかで働いたり勉強会参加したりOracleのJavaへの関わり方を見ると、なんだかんだ言ってまだまだメインストリームで在り続けるだろうなと思います。 どちらかというと日本でのJava
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
【業界】システム設計書の納品単位【常識！？】
システム設計書の納品単位に関しての話をまとめました。 いろいろあるんですね。 次は石版で納品しようと思います。
新規サービスサイト制作の受託開発はなぜ上手くいかないのか - 思っているよりもずっとずっと人生は短い。
メモ。 自分で自社サービスを運営する立場になってわかったこと。あんまりよそで言われてないような気がするので書いてみます。ちなみに業務システムとかは関係ないです（というのは最後にもちょっと触れます）。 ふつう、受託開発では、９割がた成功する、というか失敗しないように開発の体制を組みます。まあ仕事で請けているので当たり前の話ですね。もっとも、先方のスケジュールや予算の都合で、７，８割くらいになる場合もあります。その場合は始める前から残念感というか貧乏くじ感があったりしますが、断れない場合もあるので仕方ありません。それでも、基本的にはそんなに失敗しないようなスキームにしようとするはずです。 ところが。新規にビジネスとしてサービスを立ち上げようとする発注側に立ってみると、「９割がた成功する」という基準はちょっとありえないことに気づきます。言ってみれば、新規サービスを作るということは、新規に事業を起
まとめ：なぜ人月見積がダメか - Zerobase Journal
社団法人日本情報システム・ユーザー協会(JUAS)発行の『ソフトウェアメトリックス調査2007』を取り寄せて読んでみましたよ。SI関係の人は必読ですよね。私はいままで知らずに損していました。 そんなこともあり、年の瀬でもあり、今回の記事では表題の件「なぜ人月見積がダメか」について、現時点での総括をします。 人月見積方式の弊害に対する言論 「ユーザー企業は出席をとるな」，日本IBMの大歳社長が提言：ITpro (2001/08/31) 「日本の商慣習でぜひとも変えて欲しいのは，ユーザー企業が我々の技術者の出席をとることだ。出席をとられると我々は開発の生産性を挙げようとする努力をしなくなる。1000人でできる仕事を500人でやってのけると，売り上げが半分になってしまうからだ。技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」。日本IBMの大歳卓
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
