5月16日（月）、情報セキュリティマネジメント試験の合格発表がありました。実は私もこの試験を受けました。久しぶりに情報処理技術者試験だったので、心地よい緊張感を持った合格発表でした。 結果は、見事合格。午前が96点で午後が100点。この試験の書籍も書いて、Webで本試験の対策の連載をさせてもらっている立場からすれば、まあ、こんなものだと思います。 しかし、違和感を感じたのは、その合格率の異例の高さです。なんと、88.0%もあるのです。しかも、得点分布を見ると、受験者の40.7%（7281/17890）が90点以上のスコアなのです。 実は、試験を受けた直後の感想や、周りの受験生の会話の中で、簡単ということは分かっていました。私も自己採点で午後は満点でしたが、全く勉強せずに満点の人が山ほどいたのです。 でも、試験センターの資料には、合格ライン（6割）を変更する可能性があるという記載があ
もう2007年といえば5年前のことになってしまう。時のたつのは早いものです。 当時の増田のエントリが何故か今頃盛り上がっていて、その結果それに言及した僕のエントリも盛り上がっているようなのですが、5年前の状況というのはさすがに古かろう、ということでちょっとアップデートしてみたいと思います。 参考： IT業界で無事にいたいなら銀行に関わるな 銀行SE…かわいそうです… - novtan別館 ここ最近の銀行システムの大きなトピックというのは三菱統合UFJ銀行のDAY2（システム完全統合）と、みずほ銀行の3.11後の大障害とそれに伴う銀行の統合・システム刷新でしょう。 特に後者は銀行システムの停止が社会に与える影響が如何に大きいものかということを体現してくれました。 なんどかリークもされているからここだけの話をすると、みずほ銀行はいわゆる第三次オンラインをちゃんとやらなかった建て増しシステムであ
ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。 富士通、余剰ＳＥ変身作戦 富士通がグループで抱える約３万人のシステムエンジニア（ＳＥ）の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はＳＥ余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。 富士通、余剰ＳＥ変身作戦 実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機
株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
ようつべより転載 ULTRA NEXTGEN AAA Sound Design http://youtu.be/qukCulDOJzg
社団法人日本情報システム・ユーザー協会(JUAS)発行の『ソフトウェアメトリックス調査2007』を取り寄せて読んでみましたよ。SI関係の人は必読ですよね。私はいままで知らずに損していました。 そんなこともあり、年の瀬でもあり、今回の記事では表題の件「なぜ人月見積がダメか」について、現時点での総括をします。 人月見積方式の弊害に対する言論 「ユーザー企業は出席をとるな」，日本IBMの大歳社長が提言：ITpro (2001/08/31) 「日本の商慣習でぜひとも変えて欲しいのは，ユーザー企業が我々の技術者の出席をとることだ。出席をとられると我々は開発の生産性を挙げようとする努力をしなくなる。1000人でできる仕事を500人でやってのけると，売り上げが半分になってしまうからだ。技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」。日本IBMの大歳卓
2NTは無料ブログ、無料ホームページ等、楽しいWEB Lifeをお届けするポータルサイトです。
■編集元：ニュース速報板より「SE悲惨すぎ 徹夜明けの退勤時間と出勤時間の間が１分しかないタイムカード記録を残し27歳自殺」 1 コロちゃん(チベット自治区) :2010/11/20(土) 14:58:52.76 ID:ZOSEk9hp0 ?PLT(13003) ポイント特典 システムエンジニアの２７歳の息子をうつ病による過労自死で失った母親。 徹夜明けの退勤時間と出勤時間の間が１分しかないタイムカード記録が残されており、 「先が何も見えません。このまま生きていくのは死ぬよりつらいと思います」と息子がブログで書き残したと述べ、 「速やかに労働災害を認め息子の尊厳を守ってください。 若いシステムエンジニアを自殺に追い込むのを防ぐためにもよろしくお願いします」と訴えました。 http://www.jcp.or.jp/akahata/aik10/2010-11-20/2010112
新人にソフトウェア開発の作業手順を教えていると、思いも寄らぬ質問を受けて戸惑うことが有る。例えば、先日はこんな質問を受けた。 「仕様書はどの程度まで書けばよいのですか？」 あまりにストレートな質問なので何と答えるべきか一瞬戸惑ってしまったが、考えてみれば仕様書の記載をどの範囲でどのような粒度でどこまで書くべきなのか？という基準は何も存在していないのだ。品質管理の規定に従ってレビューや照査・承認のプロセスは存在するものの、それは書いた後で行われるプロセスだし、ソースコードと違って「動作する」「動作しない」という明確な境界線も存在しない。内容にモレや矛盾が存在する仕様書は珍しくないし、書き手によって仕様の構成や内容が違うことも有るのだ。 しかし、実際問題として仕様書を上手に書く人はいるし、チーム内には失敗事例を元にまとめた仕様書ガイドラインも存在している。だから「完璧ではないけれど、それなりに
「最近、ＰＭになりたくないというエンジニアが増えて、会社でも問題になっているんですよ。」 毎週水曜日の夜に開催している「ＩＴソリューション営業塾」の後、参加者との会食で、ある大手ソリューション・ベンダーの方から、そんな発言があった。 私はその話しを聞いて、「まあ、いつの時代にも、そのような人はいますよ。今に始まった話じゃない。せいぜい、１０人にひとりいるかいないかじゃないんですか？」 すると、別の会社の方が、 「いや、そんなことはありません、うちの場合は、１０人いたら半分は、そんな感じです。」 すると、他の方も同感だと相槌を打った。 「聞くところでは、新卒の入社面接で、『私はＰＭを目指しています』といいなさい・・・という指導を受けているそうです。ＰＭになろうという人が少なくなったので、このような発言をすると採用されやすいからだそうです。」 いやはや驚いた。 なぜＰＭになりたくないのだろうか
SIerでプログラマ(PG)からプロマネ(PM)までやった僕が通ります。 ＰＭになりたくない症候群 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 一度でも失点をしたらそこからリカバリーすることが困難な立場に放り込まれるし、放り込まれたら現場の裁量で何とかするしかないというデフェンシブなやり方に起因する構造的なPM疲弊体質。確かにコレは、嫌悪される理由の１つにあると思います。ただ、それだけではないな、と。技能という側面で考えても嫌悪される理由があるのかな、と思いました。 要はPG→SE→PMというキャリアパス、についてですね。 色々な議論がありますが、何が問題かと言えばプログラマとして未来を奪い去ってしまう所が過多あるってことに尽きるように思います。技術は移り変わるわけですから、プログラマでありたいなら保有スキルが陳腐化しないようにしなくてはな
受託開発って、下請けの仕事だし、お客さんの言われたとおりに作んなきゃいけないし、なんかツマンないよね？ やっぱIT業界は、自社製品とかサービスを作ってナンボの世界でしょ？ そんな勘違いを、今回もきたみりゅうじがぶった切ります。 ひと頃のピークを過ぎたとはいえ、IT業界といえばやはり花ざかりなネット企業。自前のサービスを世に問うて、自らの技術力を頼りに突き進む。当たり前にネットが使われるようになった現在だからこそ、目立つ存在になってます。一方、昔ながらの受託開発はというと？ なんか「つらい」とか、「しんどそう」とか、「下請けってイヤよね」とか。聞こえてくるのはそんな声ばかり。 えーーーーー？ そうなの？ 受託開発って、そんな悲しい言葉ばかりが並ぶモノ？ はてさて、それは以降の物語をご覧あれ。 「オーダーメイド」と聞いて私が思い浮かべるイメージは、「高いけど物はよさそう」というものです。「よい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
