株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理

Enterprise buyer's guide: Remote IT support software Buying for the first time? Know what your options are. Considering replacing what you have? You might just save 25% or more on licensing costs. Here's what to look for and 12 leading remote support tools to consider.

東京大学 浅見研究室は7月12日、情報系の学生や若手エンジニアのための交流企画として、「IT企業はほんとに泥のように働かされるのか～ナナロク世代がお答えします」と題したカンファレンスを開催した。「IT業界のネガティブな側面が指摘される中、その実態を『ナナロク世代』が『ハチロク世代』に向けて伝える」という趣旨で、会場となった東京大学 本郷キャンパスの教室には、大勢の学生や若手エンジニアが集まった。 モデレータはCerevoの岩佐琢磨氏が行った。パネリストとして、大谷陽明氏（ソニー）、尾藤正人氏（ウノウ）、柴田竜典氏（日本オラクル）、加藤篤延氏（NTTコムウェア）が登壇。「個人としての参加であり、それぞれの企業や活動を代表する見解ではない」としながら、それぞれの経験を元にIT業界について語った。 始めに、主催者である東京大学 大学院情報理工学系研究科の川原圭博氏が企画趣旨を説明。「毎年、電子情

少し前に若いエンジニア達と話す機会があった。この春SI企業に入社してプログラミングの研修を受けているという。みんなそれぞれ能力が高い上に、学習の高速道路を爆走中といった感じでネット上で話題になっているような技術情報には十分詳しい。SICPを全部解いたとも言っていたし本当はプログラミングの研修なんか必要ないのだろう。未踏に応募したり勉強会を開催したりするのはこういったタイプなんだろうかとか、いまどきのSI企業の人材獲得能力はすごいなとか思いつつ、でも彼らはこの業界に何を求めてどうなろうとしているのか少し気になったりもした。 これほど優秀で勉強もしてきた人達でも、SIerとしては即戦力にはならない。社会人マナーとか仕事の進め方の話ではなくて、単純に知識不足という意味で。そのため一緒に入社したプログラミング能力の低い社員と同じように扱われる可能性が高い。これはすごく不幸な状態だと思う。SI業界が

フツウのプログラマがフツウに評価される社会を夢見る - kagamihogeのblog 多数のブクマなどの反応ありがとうございます。エントリと俺に対する共感ととるか同情ととるかで意味は違ってきますが、どちらにせよソフトウェア業界に関心を抱いている人が多いという事実は良いことだと思います。 様々な反応を見て考えること・書きたいことは沢山出来たんですが、このエントリに眼が向いている内にただ一点追加というか頼みたいことがある。 コンピュータサイエンス学科出身者を積極的に雇うように動いて欲しい。 俺に対して「貴君のコード次第では雇える」という意見がありました*1。それ自体は非常にありがたいことなんですが、その対象を学生さんたちに向けてはくれないだろうか？ コンピュータサイエンスをかじったことがあること。プログラミングができること。その価値を正しく認識している会社はナンダカンダ言って日本にも結構ある

俺は大学でコンピュータサイエンスを 4 年間学んだ。とはいっても大学自体の学歴・成績は平凡もいいとこ。真の意味でのプログラマのレベルは凡骨もいいところな自覚はある。まぁその大学は自分と似たよーなレベルの人間を毎年輩出してるわけです。 でまぁ、就職活動に真剣に取り組み始めにゃならん時期になんとなしに 2ch （つーかしたらばか）の出身大学の出身学科のスレ見たら驚いた。そこでの議論の趣旨は「コンピュータサイエンスを 4 年学んだ人間はソフトウェア業界以外の進路は何があるか？」だった。 「今更 IT ドカタやる以外ないだろ常考」「公務員ならなんとかなるかも？」「情報科目の教員免許はどうだろうか」「コンピュータに精通した事務員とか会計士とかアリじゃね」「起業とか？　俺たちのスキルじゃ余りにもリスク高すぎるか……」etc,etc ずっとスレを追っていたわけではないが、前向きにソフトウェア業界行きたい

昨年、情報処理推進機構（IPA）が開催したIT業界の重鎮と現役学生による討論会で、学生の持つIT業界への「ネガティブイメージ」が明らかにされたのは記憶に新しい。5月28日、IPAが開催したイベント「IPAX2008」で、再び経営者と学生の討論会が行われた。IT産業が国際的な飛躍をめざすために学生に期待することが今年の討論のテーマ。 学生側は、慶應義塾大学、九州大学、千葉工業大学、東京情報大学、東京工科専門学校から各校2人ずつ、計10人が出席。一方、産業界代表としてCSKホールディングス 取締役 有賀貞一氏と、コムチュア 代表取締役社長 向浩一氏が討論を行った。また、IPAからは理事長の西垣浩司氏が参加した。司会はインプレスR&Dの田口潤氏が行った。 「ポジティブなビジョンを提示して」 「産業を問わず、やりがいのある仕事のイメージ」について学生に質問をしたところ、「達成感がある」「自分の成長

皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。 WBS作成がプロジェクトマネジメント高度化の第一歩 WBS（Work Breakdown Structure）を明確にすることは、プロジェクトマネジメントを高度化する第一歩である。PMBOKでは、スケジュールの作成、予算の作成など重要な計画はすべてWBSをベースに作成する。また、多くのシステム開発やソフトウェア開発も、WBSの定義を行うことを前提としている。 WBSとは、プロジェクトで実施する作業を細分化し、階層構造で示したものである。これがないと、本来であればシ

最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部

今年もIT業界にたくさんの新社会人がやってきたと思います。 そんなみなさんに、一番最初に本音を言っておこうと思います。思いついたことを無責任にぐりぐりと。 全文はこちら

ユーザーの要件定義があいまいでシステム開発中も修正に次ぐ修正。プロジェクトは大幅に遅れて、予算が超過。しわ寄せは下請け、孫請けへ。デスマーチ……。新3Kともいわれるこんな日本のIT業界が2009年4月に大きく変わるかもしれない。そのきっかけとなるのが「工事進行基準」の原則義務付けだ。 【関連記事】 工事進行基準を分かりやすく解説してみよう【基本編】 工事進行基準を分かりやすく解説してみよう【対応編】 工事進行基準（用語解説）とは会計基準の変更によって2009年4月にシステム・インテグレータ（SIer）など受注ソフトウェア開発業に原則として義務付けられる収益の計上方法。開発期間中にその売り上げと原価（費用）を、工事（ソフトウェア開発、システム開発）の進捗度に応じて、分散して計上する仕組みだ。 これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」

「人月計算をやめたいんだよね…，どうも納得がいかない」 2008年3月15日号の日経コンピュータで「ITコスト」を取り上げた特集を組んだ。企画の段階で，「○システムなら△円」といった指標が出せないものかと考えたのである。そうした指標があれば，ユーザーがベンダーと交渉したり，逆にベンダーがユーザーに提示する相場観の目安となる。想定したのが不動産情報だ。「新宿のビルで□坪なら×円」といった情報を提供したかった。 そこでユーザーのIT部門とベンダーの両方に取材したのだが，「相場は難しいんじゃない？システムは会社によって違うから」という反応がほとんど。それに続いて「それよりも…」という冒頭の言が出てくる。どうも完成品であるシステムの機能や価値ではなく，それを作るためのコストを問題視しているようだった。 長らく使われてきたこの人月単価や人月計算を，ユーザーとベンダーの両者が止めたいと思っている（注1