Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

SIに関するwata300のブックマーク (31)

  • 南米発のツールがIT業界に与えるインパクト

    「プログラマはもう要らない」。大手物流会社のシステム子会社で新技術の社内展開を進めるマネージャーはこう言い切る。ここでいうプログラマとは、企業情報システムの開発プロジェクトでプログラムを作成する担当者を指す。ある開発ツールを検証したところ、こうした役割の要員は不要との結論に至ったというのだ。 このマネージャーは記者に対して、ツールを導入した場合の効果をこう語る。「様々な開発言語を知っていて、バグのないソースコードを24時間、延々と高速で書き続ける。そんなスーパープログラマを雇ったのと同じ効果が得られる」。 同社が検証したのは「GeneXus(ジェネクサス)」という開発ツールである。ご存知の方はまだ多くないかもしれない。一口に言えば、アプリケーションの自動生成ツールである。データ項目や画面、業務ルールといった設計情報をGeneXusの表記法で入力すると、ソースコードとテーブル定義情報を自動生

    南米発のツールがIT業界に与えるインパクト
  • 今年35歳になるので、エンジニアの35歳定年説というやつについて書くぞ - developer’s delight

    エンジニア35歳定年説。IT業界で働く人なら一度は聞いたことがある言葉なのではないかとおもいます。誰が言い出したのか知りませんが、この言葉は非常にタチが悪く、言葉だけが一人歩きしていて多くの人が「35歳くらいになると能力・体力の低下により新しい技術についていけなくなり、引退を余儀なくされる」という解釈をしているようです。しまいには妙な拡大解釈でこのようなエントリまで書かれる状況です。僕の認識をどんぴしゃで書いてくれているエントリがないので、自分の経験を少し書いてみたいとおもいます。僕が「エンジニアは35歳が定年」という言葉を初めて聞いたのは、新卒で就職したソフトウェア開発会社でした。僕が就職したのは、法人顧客のための業務システムを開発している、いわゆるSIをやっている会社でした。ある日、会社の先輩に「この業界、エンジニアで飯をっていけるのは35歳までだから、よく将来のこと考えておいたほう

  • 内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog

    数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発(内製)を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。

    内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog
  • オープンソースによる新しい受託スタイルの提案

    前々回のエントリ「受託開発とGPL」では、受託開発においてGPLのソフトウェアを用いる際に注意すべき点やライセンスの扱いについて書いた。ただし、その視点はあくまでも「GPLはSIerにとって注意すべき≒厄介なシロモノであり、如何に地雷を踏まないようにするか」というものであったように思う。だが、「厄介である」という性質は、裏を返せば「味方につけると頼もしい」ということだ。つまり、GPLは、味方になれば強力で頼もしい存在なのである!今日は、SIerが今の開発スタイルから脱却し、如何にしてGPLを味方につけて戦っていくかということについて語ろうと思う。ちょっとひどい妄想夢物語的な記述も入っているのだが、「何言ってんだコイツ?!」とツッコミたいところをぐっとこらえて最後までお付き合い頂ければ幸いである。 システム全体を再構築するのは大変SIと一口で言ってもその規模は大小様々であるが、業務(基幹系)

    オープンソースによる新しい受託スタイルの提案
  • 大手SIerの利益悪化がとどまることを知らない件 - GoTheDistance

    田中克己の針路IT - ソフト会社に明日はない?:ITpro ____ /::::::::::  u\ /:::::::::⌒ 三. ⌒\       ウソだろ!? 今期、いきなり利益半減? /:::::::::: ( ○)三(○)\          会社どーすんだろ・・・orz |::::::::::::::::⌒(__人__)⌒  | ________ \::::::::::   ` ⌒´   ,/ .| |          | ノ::::::::::u         \ | |          | /:::::::::::::::::      u       | |          | |::::::::::::: l  u             | |          | ヽ:::::::::::: -一ー_~、⌒)^),-、   | |_________| ヽ::

    大手SIerの利益悪化がとどまることを知らない件 - GoTheDistance
  • どうしてプログラマがPMになりたくないのか - GoTheDistance

    SIerでプログラマ(PG)からプロマネ(PM)までやった僕が通ります。 PMになりたくない症候群 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 一度でも失点をしたらそこからリカバリーすることが困難な立場に放り込まれるし、放り込まれたら現場の裁量で何とかするしかないというデフェンシブなやり方に起因する構造的なPM疲弊体質。確かにコレは、嫌悪される理由の1つにあると思います。ただ、それだけではないな、と。技能という側面で考えても嫌悪される理由があるのかな、と思いました。 要はPG→SE→PMというキャリアパス、についてですね。 色々な議論がありますが、何が問題かと言えばプログラマとして未来を奪い去ってしまう所が過多あるってことに尽きるように思います。技術は移り変わるわけですから、プログラマでありたいなら保有スキルが陳腐化しないようにしなくてはな

    どうしてプログラマがPMになりたくないのか - GoTheDistance
  • 契約書のツボ(3)

    「システム開発契約書」とは、ソフトウェアの開発を委託または受託するときの契約書です。 自分が委託する側なのか、受託する側なのかによって大きく内容が変わってきますが、契約書を作成したり、内容を審査したりする際の重要なポイントとしては、以下のものがあります(書では基的に受託者側の立場で解説していますので、ご注意ください)。 なお、システム開発契約の参考書としては、(旧)社団法人日電子工業振興協会によるモデル契約書を解説した「ソフトウェア開発モデル契約解説書」が秀逸です。大手SI企業では、全SEに配布しているとか。これ一冊でシステム開発契約は万全です(プロジェクトマネジャは必携です)。

  • 高木浩光@自宅の日記 - ケータイ脳が大手SI屋にまで侵蝕、SI屋のセキュリティ部隊は自社の統率を

    ■ ケータイ脳が大手SI屋にまで侵蝕、SI屋のセキュリティ部隊は自社の統率を 昨年示していた、 やはり退化していた日のWeb開発者「ニコニコ動画×iPhone OS」の場合, 2009年8月2日の日記 日の携帯電話事業者の一部は、「フルブラウザ」にさえ契約者固有ID送信機能を持たせて、蛸壺の維持を謀ろうとしているが、iPhoneのような国際的デファクト標準には通用しないのであって、今後も、他のスマートフォンの普及とともに、蛸壺的手法は通用しなくなっていくであろう。 そのときに、蛸壺の中の開発者らが、このニコニコ動画の事例と同様のミスをする可能性が高い。「IPアドレス帯域」による制限が通用しない機器では、アプリケーションの内容によっては特に危険な脆弱性となるので、関係者はこのことに注意が必要である。 の懸念が、今や、さらに拡大し、ケータイ業者のみならず、一般のシステムインテグレータの思考

  • 現場のSE, PGが考えるデスマる条件とは:アルファルファモザイク

    当方1年目の新人です。"デスマ"と言うのを最近知りました。 勉強になると思うので箇条書きかなんかで挙げていただけないでしょうか。

  • タイム・コンサルタントの日誌から : Excelで工程表を書いてはいけない

    さる8月、翔泳社主催の「PM Conference 2008」に招かれて講演をした。テーマはプロジェクト・コントロールの技法論で、私が長い間、エンジニアリング業界とIT業界の二足のわらじを履いてきた経験から、両者の比較を論じたものだった。最近のIT業界における「プロジェクト・マネジメント」の認識の普及進展はめざましいものがある。これに対して、エンジニアリング業界は過去10年以上、EVMSの徹底化以外とくに主立った進歩はない。にもかかわらず、両者の違いはいまだ歴然としたものがあり、それはとくにプロジェクト・コントロールの基であるWBSやコントロール・リストなどの使い方で明瞭だ、というのが論旨だった。 ところで、この講演の中で、「工程表のガントチャートExcelで書いてはいけない」と強調した点が、どうも多くの聴衆の注意を引いたらしい。終わってからのアンケートでも、そこに関する感想が少なくな

    タイム・コンサルタントの日誌から : Excelで工程表を書いてはいけない
  • IT業界のシュールな現実(3):下流から見たIT業界:エンジニアライフ

    数年前(もうかなり古いことなので恐縮ですが)、ある大手SIerでのことです。 ●ありがたいお話 突然Webアプリケーション事業部長が話をするから、下請けを含めた開発者全員、会社の大会議室に集まるようにと言い渡されました。大学の大教室のような広い会議室で待っていると、年のころは60歳近く、小柄でやせていましたが重役クラスと思しき事業部長が1人出てきて、講壇に上がり、話し始めました。 話の内容はこうです。わがWebアプリケーション事業部は発足以来、時代の波に乗って高収益を上げてきた。しかしこの数カ月その勢いがなくなっている。個々人の仕事ぶりも沈滞しているではないか。これはいったいどうしたことだ。 わたしもその職場では組織上の問題があると思っていたところでした。さすが大企業、問題をいち早く認識している、と感心したのはそこまで。あとがいけない。その事業部長の見解は、要するにわたしたち開発者の自覚が

    IT業界のシュールな現実(3):下流から見たIT業界:エンジニアライフ