Complete Mirage - SIerの給料も語るべきでは
いやー、相変わらずおっしゃる通りです、という感じのkuranukiさんの２つのエントリです。 同じことを思っていても、こんなに構造化して表現できるなんて素晴らしい。 ディフェンシブな開発 ～ SIビジネスの致命的欠陥 アジャイルのレイヤ ～ アジャイルを整理し直して理解する でも勝手に一つだけ問題点というか認識すべき点を追加。 レベニューシェアは確かにあるべき姿に近づいていると思います。 少なくとも、発注者（Servicer）と受注者（SIer）のベクトルが合うスキームになっている。 実際は、ある程度の初期費用が発生することになると思うので、一部これまでの形を残した状態にはなると思いますが、良い方向ですよね。ぜひ進めてもらいたい。 でもこれだけでは解決しない大問題が一つ。 SIerの出す金額、もしくはその元になる単価、そして給料です。 高すぎる金額 金額が高すぎる。これは最近Service
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
IT企業、新卒採用苦戦の理由は「仕事のイメージが悪い」 - @IT
情報処理推進機構（IPA）は、人材不足が深刻化する日本のIT業界の現状を調査するため、IT人材についての実態調査を実施し、1月28日に結果を公開した。大学卒、大学院卒の新卒学生がIT企業に興味を持たなくなったともいわれているが、当のIT企業が新卒採用の課題として挙げた答えのトップは「業界の仕事のイメージがよくない」だった。 調査はIT人材についての総合的な調査の予備調査の位置付け。IT企業とユーザー企業に分けて2007年9月に調査を行った。IT企業は357社が回答。回答企業の65.8％は受託開発ソフトウェア業、12.3％が情報処理サービス業、6.7％がパッケージソフトウェア業など。 IT企業の今年度の新卒採用については40.9％のIT企業が「ほぼ目標どおり」と回答。ただ、「目標を下回った」という企業も3割以上あり、苦戦は続いているようだ。特にほぼ目標どおりの採用を確保している従業員1000
品質についての気づき (arclamp.jp アークランプ)
製造業における品質というのは、多くの場合は生産工程におけるブレのことをいいます。Wikipediaにによるとシックスシグマとは、次のようなもの。 6σの状態とは、ある製品組立工程の品質特性値が正規分布に従うと仮定するならば、6σの外に出る確率は、100万分の3.4である。すなわち、ある工程では100万個製品を組み立てて3.4個のばらつき（不良品）が生じる。「100万回作業を実施しても不良品の発生率を3.4回に抑える」ことへのスローガンとしてシックス・シグマという言葉は使われ、定着していった。 システムでの生産とはランタイム ではシステムでいう生産工程はどこのことでしょうか？ふつうは実装と思われがちですよね。でも、製造業における生産とは「同じ作業を繰り返し行うこと」という前提があります。だからこそ、そこで不良品が出る割合を抑えようと考えるのです。では、システムでいう生産工程とはどこか。それ
空前の人材不足でもエンジニアが大事にされないのはなぜか － ＠IT
2007/11/27 シマンテックは11月27日、世界的に行ったIT環境についての調査結果「State of the Data Center Research」を発表した。企業情報システムの現場では世界的にIT人材が不足。その中でも日本は特に深刻だった。 調査は米Ziff Davis Enterpriseが実施。世界の情報システムの開発、運用に関わる800人以上が答えた。対象企業の平均従業員数は3万1250人。年間の平均IT予算は米国企業で78億円、米国以外の企業は59億円。Global 2000に入る大企業が中心。800人超の回答者のうち、日本の回答者は12.2％を占める。 情報システム管理の世界的な課題は人員の不足。回答者の52％が人員が不足していると答えた。さらに「適切な人材が見つからない」が86％を占めるなど、「エンジニアの頭数ではなく、（優秀な）人材が不足している」（シマンテック
どうせ理系出身者なんていらねえんだよ。
いまさら言ってもしょうがないだろうが、SIerに就職を希望したり内定した人たちに一言いっておきたい。 http://blog.miraclelinux.com/yume/2007/11/post_1ab2.html http://d.hatena.ne.jp/itoyosuke/20071101/1193932945 http://www.atmarkit.co.jp/news/200710/31/ipa.html 元の報道や参加者のブログエントリ見たりすると、ありがち過ぎて泣けるのだ。はっきりいうと、SIerの人事は情報工学科出身者は求めていない。それどころか理系出身者すら求めていない。 口先では求めているというよ。また、現場で最後に「技術的になんとかする」のは理系に期待されることが多いし、実際に期待通りに解決するのは大抵理系だ。しかし評価はされないし感謝もされないよ。とくに給料に反映す
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
プログラマなら人月なんかさっさと超えろ - 矢野勉のはてな日記
Java, プログラミングノリノリで書いてみる。 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 そしてJavaの世界というのは、私のようにJavaが大好きだからやってる、という人間はすごく少数派で、「そろそろJavaでもやっとくか」「Strutsの使い方覚えたからもういいか」「できればJavaなんかいじりたくないなー。俺も早くプログラマに『これやっといて』って言えるようになりたい」という人のほうが多いのが実情なんですね。その点Rubyの世界は、今は「好きだからやってる」人が圧倒的でしょう。プログラム能力の高いJavaプログラマを探すのは、プログラム能力の高いRubyプログラマを探すよりずっと大変だろうと思う。 Javaの世
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
大迫正治 REPEDANT BLOG > 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む : ITmedia オルタナティブ・ブログ
日本のソフトウェア産業は「製造業」よりも「サービス業」に分類される。なぜなら、革新的なプロダクトを研究開発し、一気呵成に市場に展開するよりも、顧客ニーズに沿ったオーダーメイドのシステムを逐次的に開発することが主流となっているからだ。 創業期は受託開発で糊口をしのぎ、徐々に自社製品の研究開発に資金を回して、いつかは自社ブランドで世界を席巻する、というストーリーは巷にあふれるが、これは結局のところローリスクでスタートしながらハイリターンを得ようとする野望であり、実現へのハードルは低くない。その理由は、中毒性のある受託開発と、ソフトウェア産業の悲惨この上ない「重層下請け構造」にある。 １．受託開発では「技術」が蓄積しない 住信インベストメントの辻俊彦氏はご自身のブログで次のように述べている。「クオリティの高い受託開発力は、オリジナリティ溢れる尖った自社開発力を生み出す素地になると思っている。投資
チームリーダー日記 : [メモ]日本人エンジニア派遣業
システム開発の日本人エンジニア派遣業は エンジニアのレベルに関係なく もうそろそろなくなるんじゃないかと感じる。 ＃何を今更、といわれそうなんだけど、 ＃両面とも臨界点に達した感じがする。 ---- これは悲しむべきことじゃなくて、 チャンスだと思ってます。 ---- 自分がどっちに転がるかは、自分の行動次第。 自分の周りがどっちに転がるかも、自分の行動次第。 ---- 今は、Web2.0とは何か？ なんてことを後付けで考えるよりも、 同時代、同年代のエンジニアとして こっちから切り込んだほうが感覚的にわかることが多い気がする。 就業形態とかそういう点。いやもっと前段の話か。 両者はたぶん、どっかで繋がる。 ---- なんというか、 ベテランの方はどちらも肌で感じ取ることができないらしい。 ---- 「目線は自分の進みたい方向に向ける。」 とオートバイの教習所と、スキー学校の両方で習ったな
エンジニアのやる気は報酬だけじゃ維持できない（Page 3） ― ＠IT情報マネジメント
では今度はNさんの立場に立って、あらためてプロジェクトを振り返ってみましょう。 本来、彼はフリーのエンジニアですから、モチベーションの基本が報酬と作業量・時間のバランスです。多くのエンジニアは、ほかに技術的興味やメンバーとの親愛の情、あるいは顧客や仲間の評価などをモチベーションの源泉にしている場合が多いようです。 ただ、彼は技術にもチームメンバーにも顧客にも、興味はありません。彼自身が述べているように、時間とお金を引き換えにして、プロジェクトに参加しているのです。つまり、Nさんは自身を「レンタルプログラミングマシン」としています。そのことを前提に作業しにきている作業者にとって興味があるのは、自身の作業時間と作業内容だけです。 最初からプロジェクトの成否を含めたいかなる「プロジェクト全体の事情」にも、いささかも興味ありません。実は私は彼のようにモチベーション自体を失ったエンジニアをたくさん見
ITサービス業の産業構造は近い将来、間違いなく崩壊する
ITサービス会社は今、技術者不足に悩んでいる。業界自体が若者に不人気で、プログラマ、SEを志す人も減りつつあるという。それはそれで大きな問題なのだが、あくまでも現象論。少し考えてみてほしい。このままでは、ITサービス業の産業構造、ビジネスモデルは人材面の問題から間違いなく崩壊する。これは論理的必然である。 多くの人がもう忘れ始めているが、ほんの2～3年前にはITサービス業界では技術者が余っていた。優秀な技術者はその頃でも足らなかったという議論があるが、総体としてはやはり過剰だった。多くのITサービス会社が危ない案件の安値受注に走ったのも、技術者の稼働率を維持するためだった。下請け会社が容赦ない料金引き下げ要求にさらされたのも、その頃だ。 もともとITサービス業界はその黎明期から、慢性的な技術者不足が続いていた。ITサービス市場は景気変動の影響をほとんど受けず、基本的には右上がり。人さえ手当
よいSEにはよい報酬を，“人月いくら”はもうやめよう
少し前のIT Proニュースで，日本IBM・大歳卓麻社長の「ユーザー企業には，技術者の出席をとらないでいただきたい」，という発言が紹介されている（当該記事）。「技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」，という主旨だ。 私自身も取材のなかで，技術者の数や開発にかかった時間でシステムの価格を決めるのはおかしい，という声を，多くのSEの方々からお聞きする。ベンダーに籍をおくSEからだけではなく，ユーザー企業の方からもである。 システム開発にかかる工数，すなわち“人月”は，価格見積もりの根拠として，現在でも広く使われている。仮に一月100万円のSEが10カ月働いたから1000万円，という見積もりがあったとしよう。では，そのSEが努力して生産性を向上させ，5カ月でシステムを開発できるようになったら，価格は500万円になってしまうのだろうか。
“未来の経営者”にも会うコンサル、案件終了が縁の切れ目のSIer
この前、年配のシステムコンサルタントの人たちと話して、顧客とのリレーションの深さについて思い知らされた。この人たちは、顧客の経営トップとのリレーションが10年、20年と切れずに続く。中堅企業のオーナー経営者だけでなく、4～6年で入れ替わる大企業のサラリーマン経営者を相手にしても同じ。経営トップが代替わりしても、次の経営トップどころか、数代先の未来の経営者とも信頼関係ができている。こりゃ強いな、と改めて感心してしまった。 システム・インテグレータにとって、コンサルティング機能の強化は永遠の課題だ。顧客の経営トップやCIOにインタビューし、聞き出した経営課題をシステム案件にまで落としていくシステムコンサルタントがいれば、SI案件を獲得する上で極めて有利な立場に立つことができる。他社よりも早く大型案件を発掘できるし、事実上、無競争でその案件を獲得できる。逆に、顧客の現場の体制が整いそうもないなど
オープンソースと「オープンデザイン」が出会うとき - 設計者の発言
◆オープンソースの台頭 無償で手に入る業務システム向けの開発・実行環境やフレームワークが急速に充実してきた。Apatche,Eclipse,Seasar2,MySQL,Ruby on Rails等々、枚挙にいとまがない。それらの多くが活発なＯＳＳ(open source software)コミュニティを伴っていて、優れたソフトウエアを開発して社会に貢献したいと願う技術者達の情熱の受け皿となっている。その創造的な流れが止むことはないだろう。 そのような変化を、ソフトウエア業界を牛耳ってきた大規模ＳＩｅｒも無視できなくなっている。初めの頃には品質がアテにならないとかドキュメントが貧弱などと言って相手にしていなかったのだが、いつの間にか実務で使えるレベルまで成熟していることに気づきはじめている。クレイトン・クリステンセンが「イノベーションのジレンマ」で示したさまざまな業界での事例と似たことが、ソ
頭数論 (arclamp.jp アークランプ)
なんか盛り上がっているので参加してみます。火元はこちら。 頭数論はSI業界の確かな事実 別に藤田氏の言い方に違和感は覚えません。SI業界では確かな事実です。 SI企業の事業計画を考えてみると良く分かります。SI企業に対するM&Aをされている方から聞いたのですが、買収先の企業に事業計画書を作らせると、目標売上の数字に対して人月単価で割り算した人数が記載されているそうです。その売上の実現性は営業による案件の獲得でもありますが、重要なのは人材採用計画に他なりません。 つまりSI企業の事業計画とは人材採用計画のことであり、売上は人数に比例して増えるのです。 Web2.0企業では頭数に意味はない で、藤田氏の発言に対して「理解が足らん」というメッセージが多く見受けられます。それは、もちろん正しい。 実はWeb2.0的なサービス企業は「理解が足らん」という話だけで頭数論を回避できてしまうのです。
SIer2.0 @ET研 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 渡辺聡さん主催のEmerging Technology研究会に参加してきました。4月開催のお題は「SIer2.0」です（渡辺さんのレポートはこちら）。 報酬構造の問題 いろいろな議論があったのですが落ちていく先は同じで成果報酬の話でしょうか。特にモノに落ちない成果、いわゆるコンサルや調整などです。 結局、プロジェクトがうまくいくかどうかは「どんなシステムをどう作るのか」という事が現実的であるかに掛かっています。上流で言えばステークホルダー間を調整したり、問題点を明確にしたり。開発現場であれば、良い方式設計を行い良いリソースを集める。 しかし、こうしたシステム作りの環境を整えるという作業に対価が支払われません。上流であればプリ・セールスという言葉で片付けられ、現場では
NameBright - Coming Soon
michys.com is coming soon This domain is managed at
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
untitled