タグ

ITに関するqaz76のブックマーク (18)

  • SIerは自動化する対象が違っているのでは?

    多くのSIerフレームワークでは、Excelなどのツールを使ってコードを自動生成することで「製造」コストを下げるということに注力しています。 しかし、アジャイル開発ではContinuous Deliveryにあるように、ビルド、テスト、リリースの自動化に重きを置き、コーディングは初期のひな形生成はしても、最終的には手でメンテナンス可能なクリーンなコードを保つという考え方をします。

    SIerは自動化する対象が違っているのでは?
  • 大規模SIは少数精鋭で乗り切れるのか? - 急がば回れ、選ぶなら近道

    まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術

    大規模SIは少数精鋭で乗り切れるのか? - 急がば回れ、選ぶなら近道
    qaz76
    qaz76 2011/09/05
    人海戦術以外思いつかない「262の法則が...」とか言っている方々へ。。
  • 「社外でも通用するスキル」のくだらなさについて - 極北データモデリング

    自分が長い間勘違いしてたから言うんだけど、 最後に「Firm Specific Skill」と「Portable Skill」の違いについて。前者は直訳すれば「企業特殊技能」と いいまして、社員がその企業ならではの技能を磨き、所属企業とのコミットメントを高めながら共に進んで いくというものです。でも、ホントに若い人が気をつけるべきなのは、自分が所属している企業外に「持ち 運び可能な技能」ではないでしょうか? 大企業で働くと毀損されるいくつかのコトについて - GoTheDistance ここで言うポータブルスキルの正体が何なのかは、よく考えなくてはならない。 ポータブルスキル=「社外でも通用するスキル」「転職時に潰しの効く技術」ぐらいに考えていると大損する。 大企業の人はそう言うけど 業界大手のお客さんと話をしていて、「(うちの会社名)さんは技術があるからいいですよねえ。私らは技術がないか

    「社外でも通用するスキル」のくだらなさについて - 極北データモデリング
    qaz76
    qaz76 2011/08/11
    分かってる分かってる分かってる。<『市場で求められている技術は常に価格競争圧力にさらされているので、そんなものを追っても金銭的に報われることはない』
  • ライブドアブログ|豊富な機能で無料ブログ作成

    いつも上から下までじっと見たり、持ち物を「かわいいね、それどこで買ったの?」って聞いてくる友達がちょっとうざい 【激おこ】家族全員がインフルでダウンしてる時に姑からメール→「何で(夫)が休んでくれたのに病院行かなかったの?」お 前 の 息 子 が 家 事 一 切 し ね ー か ら だ よ

    ライブドアブログ|豊富な機能で無料ブログ作成
  • SIerの真実とかあるあるを俺がひたすら書いていく:ハムスター速報

    SIerの真実とかあるあるを俺がひたすら書いていく Tweet カテゴリ☆☆☆ 2:以下、名無しにかわりましてVIPがお送りします:2011/07/30(土) 17:18:18.76ID:8TwylHlR0 現場で与えられたマシンが 開発環境の最低動作保証環境以下のマシン 3:以下、名無しにかわりましてVIPがお送りします:2011/07/30(土) 17:19:38.23ID:hyKehmtu0 独立系? 5:以下、名無しにかわりましてVIPがお送りします:2011/07/30(土) 17:21:26.09ID:8TwylHlR0 >>3 独立系、メー子、フリーとふらふらしてる 今は某社で正社員 4:以下、名無しにかわりましてVIPがお送りします:2011/07/30(土) 17:19:48.35ID:8TwylHlR0 現場で与えられた開発用のマシンが セキュリティソフトで全ファイル走

    qaz76
    qaz76 2011/08/04
    PGできない人が上流。>『SIerあるある』
  • 「IT業界を去ろう」--そう思った時に見直すべき10項目

    Jack Wallen氏は以前「IT業界仕事を辞めたくなるとき--10の理由を紹介」という記事で、IT業界を離れたくなる理由をいくつかリストアップした。今回わたしはこの記事で、Wallen氏とは異なる観点でIT業界にとどまるべき理由を紹介したい。 1.カネ お金を稼ぐために仕事が大変なのは確かだが、ITプロフェッショナルにはその大変な仕事に見合うだけの稼ぎがある。その給料は単に「いい」という程度ではなく、ずば抜けている。米労働統計局が発表した、「An Overview of U.S. Occupational Employment and Wages in 2010(PDF:米職業別雇用状況と賃金)」(Chart 6)によれば、コンピュータおよび数学関連の職業は平均年収が7万7230ドルであり、2010年の主な職種グループの中で3位を占めている。これよりも年収が高いのは、経営職と法曹職だ

    「IT業界を去ろう」--そう思った時に見直すべき10項目
    qaz76
    qaz76 2011/07/14
    FYI.
  • バッチ処理時間が要件の7倍、SQL最適化から発想変えて対処

    1. 届け先を管理する新設のDBサーバーで、バッチ処理時間が想定の6~7倍と判明 2. 一括ロードツールを使い、メモリー上での処理を活用して1時間以内に収めた 3. SOAサービスの粒度は、カスタマイズの手間を減らすため単純な機能単位にした 「1時間が要件のバッチ処理に当初、6~7時間もかかった。工夫を重ねて、ようやく時間内に収められた」(ヤマトシステム開発 グループソリューションカンパニー 次期NEKOプロジェクト マネージャー 田中諭氏)。 ヤマト運輸が5年ぶりの刷新を進めている基幹システム「第7次NEKOシステム」。住宅に送る「宅配」から、住宅に住む個人の都合に合わせて送る「個配」を目指したものだ。2010年9月には、送り状に記載された届け先の個人名や住所などを登録した「届け先DBサーバー」を新たに稼働させた。これまで送り状に書かれた届け先は、郵便番号など一部の情報しかシステムに登録

    バッチ処理時間が要件の7倍、SQL最適化から発想変えて対処
    qaz76
    qaz76 2011/07/12
    Direct Load Insert with Parallel DMLなら...ってDB2とMQの話かな? <
  • staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して

    何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい

    staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
    qaz76
    qaz76 2011/07/03
    前半の特性要約www <『長期にわたって保守拡張していくようなエンタープライズの基幹システムにおいてこそ、正しいアーキテクチャ設計を頭を使って実施するということが大切になってくるものと私は信じます。』
  • テーブル設計は実装の後に!:ベンチャー社長で技術者で:エンジニアライフ

    株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を(ユーザーインターフェイスの)実装の後に!」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね? ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい(波及する箇所が多い)仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル

    テーブル設計は実装の後に!:ベンチャー社長で技術者で:エンジニアライフ
  • こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して

    ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基は「コードを1行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい

    こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して
    qaz76
    qaz76 2011/06/06
    労働集約的SIの伝統...どうにかしたい。<『...といった悪循環に陥っているケース』
  • IT企業はエンジニアの人月単価をどうやって決めているか?

    意外と知られていない会計の知識。元ITエンジニアの吉田延史氏が、会計用語や事象をシンプルに解説します。お仕事の合間や、ティータイムなど、すき間時間を利用して会計を気軽に学んでいただければと思います。 今回のテーマ:人月単価の計算方法 IT企業の場合、原価の大半は「人件費」です。そのため、ある案件について顧客に見積書を提出する時は、どの作業にどれだけの時間がかかるか工数を概算した上で、社内で定める一定の単価を掛けて「原価の見積もり」を立てます。 人月計算についてはいろいろな問題が指摘されていますが、そもそもこの“単価”は一体どのように決まるのでしょうか? エンジニアとして働く上で、気になるところですよね。今回は人月単価の決め方を解説します。 【1】 人月計算において、考慮すべき要素 まず、人月単価を設定する時に、どのようなコストが含められているのかを見てみましょう。 人件費 最初に思いつくの

    IT企業はエンジニアの人月単価をどうやって決めているか?
    qaz76
    qaz76 2011/05/28
    元請け以下は大概地域相場。<
  • エンジニアたるもの現状に甘んじるな!:@IT自分戦略研究所の「おすすめエンジニアライフ」:エンジニアライフ

    音が語られるエンジニア参加型メディア「@IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 【考え方】渡鬼だって「つながり」の時代がきたよ 【働き方】伸びないベテランエンジニア 【新連載】業務データベースと分析データベース 【考え方】渡鬼だって「つながり」の時代がきたよ TwitterやFacebookなど、いわゆる「ソーシャルメディア」が注目を集めるようになって久しい。ソーシャルメディアの面白いところは、誰が読んでいるかを想像せずに勝手に情報を発信でき、発信した情報から思わぬ人のつながりができるところにあると言えるだろう。 『やっぱり仕事は楽しくなくっちゃ!』の平井彩子氏は、ソーシャルメディアの普及を見て、「『個人』の趣味嗜好が外に出ていく時代においては、『会社』の看板を背負って仕事をする以外にも、別の顔が生まれやすくなる」と予測し、実際に、「そこ

    エンジニアたるもの現状に甘んじるな!:@IT自分戦略研究所の「おすすめエンジニアライフ」:エンジニアライフ
    qaz76
    qaz76 2011/05/19
    そうだっ「何かを変えていく事」か自分達のミッションだったはずだ。<『現状維持バイアス』
  • エンジニアに資格が必要な時、いらなくなる時

    エンジニアに資格が必要な時、いらなくなる時:仕事を楽しめ! エンジニアの不死身力(12)(2/2 ページ) 「いつかは、資格を超えてやる」 資格の議論になると、資格かスキルかの選択になりがちですが、「どちらかが重要」ではなく「どちらも重要」だと筆者は考えます。 初めて出会う人に「自分のことを良く思ってほしい」と考えるは自然なことです。「ワンランク上の自分」をアピールするツールとして、資格を使うのも悪いことではありません。 しかし、信頼や評価は資格だけで得られるものではありません。いつかは「自分そのもの」で信頼が得られるように、継続的に自分を磨いていく必要があります。そのために筆者が意識していることがあります。 日常の仕事をとにかく一生懸命やること 地味なことでも、淡々とやること こうした日常の仕事ぶりに、周りの人は信頼を寄せてくれるようです。日常の仕事の中には、もちろん「面倒くさいな」と思

    エンジニアに資格が必要な時、いらなくなる時
    qaz76
    qaz76 2011/05/09
    (;´Д`A <「おまいらメジャーな資格の1つや2つお持ちですよね」っていう前提のトピック。
  • 「1000人の凡人が一人の天才に負けるエンジニアリング」ではなく「凡人1000人で本当に良いプロダクトを作るエンジニアリング」を指向したい - FutureInsight.info

    非常に刺激的な記事。 http://engineer.typemag.jp/elife/2011/04/post.php 僕のチームラボ社長猪子寿之氏好きは昔からで、出演する番組やUSTは大体チェックしてるし、昔書いた以下のエントリーをきっかけに一度お話させて頂く機会もあった。 チームラボの猪子社長の常人のものではないアカギ的発想について - FutureInsight.info 今回の対談も非常に面白く読んだのだが、最近よくわからなくなってきたのは、小飼弾氏が述べている「1000人の凡人が一人の天才に負けるエンジニアリング」という言葉。というのも、昔は僕もエンジニアリングは一人の天才で全部ひっくり返される可能性があるなー、と漠然と感じていたが、最近はそれって違うんじゃないかと思っている。 一人のエンジニアが全てをひっくり返すにはレバレッジが必要 特にここでシリコンバレー賛美を始めるつもり

    「1000人の凡人が一人の天才に負けるエンジニアリング」ではなく「凡人1000人で本当に良いプロダクトを作るエンジニアリング」を指向したい - FutureInsight.info
    qaz76
    qaz76 2011/04/17
    『日本にマッチするのは...凡人1000人...』日本はWFだし。人月文化だし。数10年前からそうかも。でもそれが達成されるケースでは、一人の天才テクノクラートが存在するのかも。
  • なぜIT部門は提案できない/しないのか?

    経営者は「IT部門からの提案を期待している」と言う。IT部門自身も積極的な提案をするべきだと考えている。それなのに、どうして実現できないのだろうか? 消費者ニーズにマッチした商品を作る“顧客志向マーケティング”が主流であるが、消費者ニーズから革新的な商品が生まれたことはない。 例えば、電球が発明されるまでは、消費者はもっと明るいランプが欲しいと思っただけなので、顧客ニーズを重視したら、せいぜいランプの芯の素材や形状の工夫だけで終わったであろう。ユーザーニーズの調査は“改善”には役立つが、“改革”には向かないのだ。 IT活用で抜的な効果を生むには、ニーズよりもシーズが重要なのだが、技術先行アプローチは厳重に規制される。種をまかせてくれないのだから、抜的な提案ができるわけがない。

    なぜIT部門は提案できない/しないのか?
    qaz76
    qaz76 2011/04/14
    『「必要は発明の母」だという。ところが、瀕死の病人が特効薬を発見した例はない。』
  • キャズム (書籍) - Wikipedia

    『キャズム』(原題: Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers 「深淵を越えて: 主流顧客を対象としたハイテク製品の市場調査と販売」)は、ジェフリー・ムーア(英語版)のハイテクマーケティングについての著書。1991年発売。ISBN 4798101524。 概要[編集] エヴェリット・ロジャーズによる普及学("Diffusion of innovations model")をテクノロジー企業の成長戦略に具体化し適用した事例を述べている。注意すべきことに、ロジャーズによるオリジナルの拡散モデルは殊にテクノロジーに限って述べているわけではなく、ロジャーズ自身は人類学や農村社会学での研究から「拡散モデル」を発見している。つまり、ロジャーズの普遍的な学術研究をテクノロジー

    qaz76
    qaz76 2011/04/14
    イノベーター、アーリー・アドプター、アーリー・マジョリティー、レート・マジョリティー、ラガードの購買層。
  • プログラミング言語がたくさんある理由

    はじめに これからプログラミングを学ぼうと考えた時に、最初にぶつかるのが「どのプログラミング言語を学べばいいのか」という問題ではないでしょうか。 もし、プログラマをやっている知人に「どの言語を勉強すればいいかな」と尋ねた場合、回答は人によって様々だと思います。「まずはCから学ぶべきだ」と言う人もいるでしょうし、「PHPあたりは簡単でいいよ」と言う人もいるでしょう。「日人ならRubyでもやっとけば」と言う人もいるでしょうし、「需要があるからJavaにしたら」と言う人もいるでしょう。 そんな風に様々な答えが返ってきてしまうと、どれを選べばいいのかますます混乱してしまいます。 結論から書いてしまうと、最初に選ぶべき言語は「やっていて一番楽しい言語」か「自分にとって役に立つ言語」ではないかと筆者は考えています。人間、楽しいことや実際に役に立つことでなければ、なかなか長続きしません。楽しいと感じる

    qaz76
    qaz76 2011/04/13
    『穴の大きさによって利用する道具を変えると思います。』一つの理由ではあるかな。
  • M(メガ)G(ギガ)で数えるKMGT計算術

    「3,234,500,000円っていくら?」と聞かれて即答できないPC使いは、KMGT計算術を試してみよう。「5000円の商品を3万人に売ったら?」なんて暗算にも自信を持てる。 ケタ数の非常に大きい数字は、パッと把握するのが困難だ。特に普段電卓などを使い慣れていない職種のビジネスパーソンにとっては、 3,234,500,000円っていくら? と数字を見せられても、すらすらと言えないのが普通だろう。3億2千……なんてつい読んでしまったり、心の中で「イチジュウヒャクセンマン……」と後ろから数えてしまっても笑うことはできない。 ここでポイントとなるのが“,”、カンマだ。このカンマ、英語圏や日では3桁ごとに打つのが慣習。ところが、日語で数字を数える場合、万、億、兆と4桁ごとに区切って読む。そのためカンマが打たれていても日語で読み上げるときには理解が難しい。 つまり、3,234,500,000

    M(メガ)G(ギガ)で数えるKMGT計算術
  • 1