タグ

programmingとITindustryに関するraituのブックマーク (24)

  • 理解されない本当のIT業界--ここでの職業が持つ10の短所

    多くの知り合いのITプロフェッショナルと同様に、わたしも時々、友人や家族からIT業界仕事ができないかと頼まれることがある。なぜか、そう頼んでくる人の多くは、IT業界に働いている人はみな百万長者か億万長者だと思っているらしい。またIT業界年収について勘違いされているということ以外にも、IT業界の外部にいる人は、この業界の仕事がどれほど大変かを理解していないことが多いようだ。 このサイトの読者にはITプロフェッショナルが多いため、この仕事のメリットとデメリットはどちらもよく知っているはずだ。わたしがこの記事を書いた理由は、読者が次にIT業界仕事について非現実的な期待を抱いている友人から働きかけを受けた時に、相手にこの記事を送ればいいようにすることだ。 1.労働時間が長い IT業界にはあらゆる種類の仕事があるが、そのほとんどには1つの共通点がある。労働時間が長いということだ。IT業界で働き

    理解されない本当のIT業界--ここでの職業が持つ10の短所
    raitu
    raitu 2011/12/01
    アメリカもだいたい同じシリーズ
  • IT業界を目指す大学生へ - Islands in the byte stream (legacy)

    新卒準備カレンダー 2011春という企画のエントリです。来であれば3/11日の投稿でしたが、東日大震災があったため日の投稿となりました。 東日大震災を目の当たりにして衝撃を受けつつも、身の回りでは困難があるわけでもないので何もしないのがもどかしく、しかし実のところ何もできることはなく、Twitterを眺める、NHKを眺める、コーディングするなどして過ごしています。しかし、電力不足等の懸念はあるものの、春からは社会人になることは依然として明らかです。であれば、今は粛々と日常生活を送るしかありません。そういう訳で、平常モードでポストします。 お前誰よ? [twitter:@__gfx__]と申します。この春からDeNAで働くPerlプログラマです。Perl好きが高じてPerlの仮想マシンをpure Perlで実装したりしたことがあります*1。Shibuya.pmやYAPC::Asiaで

    IT業界を目指す大学生へ - Islands in the byte stream (legacy)
  • テクノロジー : 日経電子版

    メルカリやLINEなど個人向けネットサービス大手がブロックチェーン(分散型台帳)技術への取り組みを格化させている。ブロックチェーンは仮想通貨を実現する技術として注目を集めたものの…続き 育つか「トークンエコノミー」 投稿と「いいね」に報酬 [有料会員限定] LINEが独自コイン 国内はポイント、海外仮想通貨

    テクノロジー : 日経電子版
    raitu
    raitu 2010/08/26
    「残念なことに日本では、SEは米国ほどの評価を確立していない」
  • 派遣PG時代の思い出

    @vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。 2010-05-11 12:42:06

    派遣PG時代の思い出
    raitu
    raitu 2010/08/14
    IT業界の格差はほんと凄い。しかしこれだけみてだから業界全部がだめ、みたいな言説も勘弁してほしい。上は上ですごいのだから。
  • プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance

    アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山大@クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基的にニッポンの受託開発のプロジェクトの場合は、大きく2つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ

    プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
    raitu
    raitu 2009/02/13
    現在の日本のプログラマの扱いは、未だ汎用機のころのものを引きずっているからこうなってる。昔よりプログラミング言語が遙かに強力になったからこそ、今この違和感が生まれている。
  • kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥

    Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方(ビジネスモデル)に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー(経営者)にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい!・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、

    kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
    raitu
    raitu 2008/08/25
    何故日本のIT業界があまり技術革新が進まないかについて。
  • 今必要とされている『IT』 : could

    IT (Information Technology) はみなさんにとってどういった意味をもつ言葉でしょうか。効率的に情報を行き来させる技術の総称と説明することが出来ます。「IT革命」という言葉のようにバズワード化してしまった部分もあるので、逆に意味が分からない怪しい領域に見られている可能性もなくはないでしょう。未だに IT 業界と呼ばれるところはどうも別世界に見られているような印象もあります。 技術を見えなくする 技術という言葉があるので確かに技術的なことではありますが、人に使ってもらうものを作るために技術だけで簡潔した例は今までありません。今のケータイ・インターネットの火付け役になった i-mode にせよ、新しいゲームプレーを提案した Wii にせよ、最新の技術を使ったわけでもなければ、ほとんどの方が技術をきちんと理解して利用しているわけではないです。技術中心ではなく、人を注意深く観

    今必要とされている『IT』 : could
    raitu
    raitu 2008/08/04
    多分ここら辺の話→小野和俊のブログ:続・プログラム・デザイナー宣言 http://blog.livedoor.jp/lalha/archives/50058753.html
  • プログラミングできない人を集めて開発するのはさすがにもう無理 - aike’s blog

    NTTデータと真昼の対決 - ひがやすを blog NTTデータの人とひがさんの話がかみ合わないのは、想定している低スキルプログラマーのレベルがまるで違っているのだと思う。ひがさんは(地頭は良くて)経験が少ない人をイメージしているように見える。まあ分かっててわざと主張してる気もするけど。 あらためて言うまでもないけど、プログラミングって素質がすごく重要な世界なわけで。どうにもかわいそうで、なんとかしてあげたいのに、やっぱりどうしようもないくらいプログラミングに向いてない人っている。学校や新入社員研修で何ヶ月もプログラミングを教わってFizzBuzzが書けないレベルの人をこれまで何人も見てきた。 そんな人でも、プログラムの1行ずつを日語で説明したような仕様書と、来の言語機能の一部しか使わせないコーディング規約と、能力に合わせたスケジュールがあれば、最低限の品質つまり保守可能なレベルのソー

    プログラミングできない人を集めて開発するのはさすがにもう無理 - aike’s blog
    raitu
    raitu 2008/07/17
    id:sshi->「何ヶ月もプログラミングを教わってFizzBuzzが書けないレベルの人」「そんな人でも、(中略)仕様書と(中略)コーディング規約と(中略)スジュールがあれば(中略)ソースコードをなんとか書き上げることができる。」
  • NTTデータと真昼の対決 - ひがやすを技術ブログ

    昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは

    NTTデータと真昼の対決 - ひがやすを技術ブログ
    raitu
    raitu 2008/07/17
    //そうするとデータの人は言うわけです。すごいコードと、そうでないコードが入り混じると保守がしにくくなる。//「すごいコード」の定義を統一すべきなんだろう
  • 銀行の言語事情 - novtan別館

    といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。 今やメガバンクになってしまいましたが、僕がIT業界に入ったときはまだ都銀と呼ばれていた某銀行でのお話。用語について一切説明せずに行ってみる。世代チェッカーかも。 ホスト系 今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。 言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を

    銀行の言語事情 - novtan別館
    raitu
    raitu 2008/07/01
    某都銀のシステム構成//メインフレームで過去遺産のホスト型//メインCOBOL、コアはPL/Iやアセンブラ シェルはJCL RDBにそろそろ行けるかも?//中継はオープン系UNIXでC//front endはjava//端末はWEB//社内はWEBorSAP
  • SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro

    ユーザー企業のみなさんは、システム開発プロジェクトを進める際、ITベンダーに次のような依頼をしたことはないだろうか。 経営判断でシステムの稼働日は決まっている。だが、肝心の要件は固まっていない。「何としても納期を守ってくれ。要件定義と並行して、仕様が固まっている部分から、開発作業に着手してくれないか」。 すでに開発が済んだ部分について、利用部門から大きな仕様変更の依頼が来た。「予算はもう増やせない。申し訳ないが、最初に契約した金額のままで修正してくれないか。次の案件も御社に発注するから」。 新システムの予算を何とか確保した。あとはこの予算でシステムを開発してもらうだけ。「ハードウエア込み、要件定義から運用設計まで、すべて一括で契約してほしい」――。 頻繁とは言わないまでも、システム開発を進めるうえでは“よくある話”だ。問題があると分かっていても、経営層や他部門からの要請で、こうした依頼を

    SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro
    raitu
    raitu 2008/07/01
    ウォーターフォールの仕組みを明文化・規格化したらどうなるかなー。要件定義が曖昧だった所が何とかなるプラスが浮き上がるか、プロトタイプ的作業が出来なくなるマイナスが浮き上がるか。
  • 技術者社長が語る「プログラマはキツい?いや、楽しいでしょ!」 (1/4)

    元サイボウズの社長であり、現LUNARR CEOの高須賀 宣さんと、ユビキタスエンターテインメント CEOの清水 亮さん。日米のエッジな企業経営者のお二人にプログラマ人生から、日米のモバイルに対する認識の違い、最近注目しているテクノロジまで語り尽くしてもらった。全3回に分けてお送りするこのガチンコ放談。まず、第1回目は「プログラマ人生とは」「日米の思考の違い」「ネットの世界の成功の条件」だ。 プログラマはキツい? いやいや、楽しいでしょ 清水 ゆっくり高須賀さんとお話させていただくのは今日が初めてですよね。いきなりですけど、サイボウズがグループウェアを発売したのはいつでしたか? 高須賀 1997年の9月でした。 清水 そうだったんですか。実は僕が初めてCGIでプログラムを書いたのが1998年ぐらいで、グループウェア的なモノを作ったんですよ。もう1年早ければ、サイボウズに勝てたかもしれない(

    技術者社長が語る「プログラマはキツい?いや、楽しいでしょ!」 (1/4)
    raitu
    raitu 2008/06/30
    サイボウズ元社長高須賀さんとshi3zさん//日米の考え方の違いについてなど//シェア、「各個人に分ける」という状態と、コモン、「ともに所有する」という状態のどちらが心地よいかという考えかた//
  • プログラマが仕様を決めればいい - GoTheDistance

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

    プログラマが仕様を決めればいい - GoTheDistance
    raitu
    raitu 2008/04/11
    SI上流工程でのレビューってそんなもんなんだ/よくそんなんで回るなーと思ったけど、回ってなかったねそういえば//
  • 「渡された仕様書を実装するサラリーマンプログラマ」の悲哀

    @ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − @ITより引用】 これは言語の問題ではなく、日のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理レシピに似ている」というエントリーで書いたが、来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ

    raitu
    raitu 2007/10/11
    //Railsはプロダクティビティを格段に上げると言われているが、この手の進化が目指すところは、最終的には「人間が書く仕様書=マシンが理解できるプログラム」の世界。//そうなるでしょうね。ああ、転職したい。
  • “21世紀のプログラムを作る君たち”に伝えたかったこと

    個人が成し遂げられることはどんどん大きくなっている。常識は短期間で変わる。今貴重なものは,やがて過剰になる。日市場を世界からへだててきた日語の壁はなくなろうとしている。ネットの向こうにいる仲間を信じよう---「U-20プログラミング・コンテスト」という,20歳以下を対象にしたコンテストに参加した若い技術者たちに,伝えたかったことだ。 ここ3年ほど,このコンテストの審査会にオブザーバという名目で立ち会わせてもらっている。なにしろ審査員のひとりであるまつもとゆきひろ氏が「私が応募しても入賞できないかもしれない」というレベルの高さである。思わず唸る完成度の高い作品あり,思わず吹き出してしまうユーモアのある作品あり。記者は好きに意見だけ言って審査の責任は負わないという美味しい役目でもあり,こんなに無料で見させていただいていいのだろうかというくらい楽しませていただいている(関連記事)。 ところで

    “21世紀のプログラムを作る君たち”に伝えたかったこと
    raitu
    raitu 2007/10/05
    //そして何より大事なのは,どんな仕事でもそうだけど,自分の仕事が好きだと,楽しいと思えることだと思う。//今そう思えていない自分を振り返って泣きそうになる。
  • 「初級シスアド」消える――情報処理技術者試験が大改革へ ― @IT

    2007/09/07 情報処理推進機構(IPA)は9月7日、情報処理技術者試験を改革する中間報告を発表した。同日からパブリックコメントを受け付けて、最終報告を11月にまとめる予定。人気の「初級システムアドミニストレータ試験」が別試験に吸収されるなど、大変革といえそうだ。 改革の柱は2つだ。現行試験は情報システムの開発側と利用側にカテゴリが分かれているが、この区別を取り払い、開発側と利用側で試験を共通化する。IPAの情報処理技術者試験センター長の澁谷隆氏は「ベンダ側と利用側が同じレベルになってきちんと会話できないと、有効なシステムは作れない」と改革の狙いを説明する。もう1つはこれまでになかったレベル分けの導入だ。ITスキル標準や組み込みスキル標準、情報システムユーザースキル標準との整合化を図り、これらのフレームワークで導入されているレベル分けを情報処理技術者試験にも適用した。 新試験では、新

    raitu
    raitu 2007/09/08
    id:keibutごめん読み間違えた//現行の「基本情報技術者試験」「ソフトウェア開発技術者試験」に対応する新試験として新試験の「基本情報技術者試験」(レベル2)と上位の「応用情報技術者試験」(レベル3)//が正解か
  • 人月計算とExcelとスーツの世界より

    俺の住む世界はアイティーとやらに支えられているらしい。 アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。 そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。 昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。 だから自分はシステム会社に向いていると思った。 実際、資格取得を勧められて始めた勉強は楽しかった。 浮動小数点数、オートマトン、SQL、スタック、木、論理式。 パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。 楽々と基情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。 研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。 現場に出て、番機に触った。 30年間親会社を支え続ける偉大なシステムの中身を、わくわくし

    人月計算とExcelとスーツの世界より
    raitu
    raitu 2007/08/31
    //今はただ、ネット越しに見つめるRDBやAPIやxpや正規表現やアジャイルやRailsやwikiがまぶしい。//ものすごく同意な組み込み系開発な俺。とりあえず職場にwiki導入してみたりしてるよ。あとRubyつかって仕様書だしてみてるよ
  • 要件定義カード1枚8万円──脱・人月商売宣言 - @IT

    「1タスク8万円」という価格体系を提示し、人月商売からの脱却を宣言するスターロジック代表取締役兼CEO 羽生章洋氏 「二度と人月商売はしません」──スターロジックは7月19日、都内で開催した自社イベント「StarLogic Conference2007」において、エンドユーザー自身による要件定義に基づき、「要件定義のカード1枚当たり8万円(税別)」という価格体系でシステム構築ビジネスを進めていくと発表した。従来の「人月」に基づく見積もりと比べて、1/3から1/5の価格になるという。 「人月換算でコストを請求する商習慣こそが、SI業界のさまざまな問題の根源。人月から脱却するには、納得でき、分かりやすい価格体系を提示することだ」(スターロジック代表取締役兼CEO 羽生章洋氏)。 低コストにできる理由は、ユーザー自ら要件定義を行い仕様を最初に明確にする点と、実装段階で自動生成により生産性を追求し

    raitu
    raitu 2007/07/20
    //「人月換算でコストを請求する商習慣こそが、SI業界のさまざまな問題の根源。人月から脱却するには、納得でき、分かりやすい価格体系を提示することだ」//
  • プログラマが会社で生きていく為の4つの条件:アルファルファモザイク

    >>13 Cを5、6年やった後Javaに移行したが、1年半じゃとてもとても。 Java界隈の最新のトピックについていけるようになるまで、たっぷり5年はかかったと思う。 つか、やってもやっても新しいのが湧いてくるのできりがねえ。

    raitu
    raitu 2007/07/16
    SPA系プログラマなかんじの意見が多い。//この職は能力やコードの重要性を数値化するのが難しい//こりゃたしかにそうだが。
  • 最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― @IT

    2007/07/05 日情報システム・ユーザー協会(JUAS)は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「(短

    raitu
    raitu 2007/07/06
    この公式は抑えておきたい