タグ

itとIT業界に関するMikatsukiのブックマーク (8)

  • SI事業者の不都合な真実、「お客様のため」というごまかし - ベテランIT営業が教える「正しいITの使い方、営業の使い方」

    「日のソフトハウスの大半はSIビジネスを核とし、大手SIerのゼネコン構造の中に組み込まれ、技術力やソリューション、営業力の不足を補ってきた経緯があります。 技術力や何がしかの商用Package等、それなりの強みを持ったソフトハウスはPrime-Projectを受託することができますが、規模が小さいため、Primeを取れない現実も有ります。それでも、特徴あるソフトハウスは良い方です。しかし、これは数多有るソフトハウスの5%未満ではないでしょうか? 95%はゼネコンの階層構造の一角を占めて、SIビジネスでべているのが実情です。」 「(大手SI事業者の場合、)経営層がProject Managementに長けた人達で占められており、ビジネスソリューション創出の投資を行う=一定のリスクを取る、という発想が極めて薄いということです。彼らはProject Managementを通じて、如何にリス

    SI事業者の不都合な真実、「お客様のため」というごまかし - ベテランIT営業が教える「正しいITの使い方、営業の使い方」
  • IT業界で生きる技術者に勧める100冊みたいなもの - 未来のいつか/hyoshiokの日記

    ふと思い立ち、「人月の神話」「理科系の作文技術」とかIT業界で生きる技術者に勧める100冊みたいなのを考えてみた。どんなものがあるのだろうかとtwitterで聞いてみたら、「100人のプロが選んだソフトウェア開発の名著」というのを教えてもらった。というか、わたしも一冊紹介していることをすっかり忘れていた。すいませんすいません。(ぺこり) そこで、久しぶりに、読み返してみた。というか今までじっくり読んでいなかった。すいませんすいません。そして未読のものに付箋をつけた。付箋だらけになった。 100人のプロが選んだソフトウェア開発の名著 http://www.seshop.com/1satsu/100nin/ それはともかくの紹介もさることながら、それにまつわるお話が面白い。読んだことがないの紹介だと、ふーん、そうなのかぁーと思うこともあれば、ぜひ読んでみたいと思うものもあり、自分の趣味と皆

    IT業界で生きる技術者に勧める100冊みたいなもの - 未来のいつか/hyoshiokの日記
  • 個性的ならOK?――著作権法で守られるソフトウエアの条件

    IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する連載。前回は不幸にも情報漏えい事件が起きてしまったら、漏えいに関与するシステムの開発や保守を担当しているITベンダーにはどのような責任が生じるのかを、裁判例を基に解説した。 今回から複数回にわたりソフトウエアの著作権について解説する。他者に不意な「マネ」をされないように、そして、知らず知らずのうちに他者の権利を侵害しないように、参考にしてもらいたい。 IT紛争における重要テーマでありながら、今まで、この連載で扱ってこなかった問題がある。著作権だ。コンピューターのプログラムや設計書の著作権が誰に帰属するのかを争った裁判の数は多く、この連載でもいつかは取り上げなければならないと考えていた問題だが、今回ようやく時宜を得た。 IT開発に携わる者であれば、当然に知っておかなければならない問題でもあるので、今回以降取り上げる判例などを参考に

    個性的ならOK?――著作権法で守られるソフトウエアの条件
    Mikatsuki
    Mikatsuki 2017/01/01
    でなにが違法なのかな? プログラムの個性、特別な工夫があるコードは著作物なのかな?
  • プログラムの「盗用」は阻止できるか?

    前回より解説しているソフトウエアの著作権問題。前回は、ソフトウエア開発において作成される設計書が著作物として認められるためには、そこに「創作性」や「表現上の工夫」が必要であることを述べた。 今回は「プログラムの著作権」について考えてみたい。最初に取り上げるのは、昭和57年に出された古い判決だが、プログラムの著作権について、おそらく裁判所が初めて考え方を示したものであり、その意味で一つの原則と言ってもいい判例である。 プログラムにも著作権が認められる。ただし「原則」として 東京地方裁判所 昭和57年12月6日判決より抜粋して要約 ある大手ゲームソフトメーカー(以下 原告)が、作成したゲームソフト(コンパイル後の機械語)をテレビゲーム機内蔵のROMに格納して販売していたが、あるゲーム会社(以下 原告)が、このROMを取り出し、別のゲーム機に組み込んで販売した。 原告は、この行為がプログラムの著

    プログラムの「盗用」は阻止できるか?
    Mikatsuki
    Mikatsuki 2017/01/01
    でなにが違法なのかな? プログラムの個性、特別な工夫があるコードは著作物なのかな?
  • もしプログラムを書かなくてもよくなったら、どうする? - アーキテクチャをスマートに。

    もうすぐ春ですね。 自己啓発も兼ねて、現場のエンジニアに向けて問い掛けをしてみようと思います。 新人エンジニアにも伝わるよう、話のレベル感を配慮したつもりです。 ちょっと怖い話かも。 SI業界の現場のプログラマ(およびそれを目指す人たち)に問う。 SI開発の現場で、もしプログラムを書かなくてもよくなったら、どうする? たとえば、 オフショア(中国などの外国にプログラミングを外注すること)や 自動生成ツール(設計書から自動的にプログラムを出力するツール)の発達 などによって、近い将来、プログラミングしなくてもシステムが作れるようになるとしたら、どうなると思いますか? 面倒な作業が減ってうれしい? いや、僕らの仕事がなくなってしまうんじゃない? 仕事がなくなることはない。 いや、仕事がなくなることはないと思います。 なぜなら設計という仕事が残っているから。(もちろん、設計より手前の上流工程も。

    もしプログラムを書かなくてもよくなったら、どうする? - アーキテクチャをスマートに。
  • 2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道

    というわけで2014年に突入ですが・・・ 景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。 とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減(または横ばい)というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よ

    2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道
  • IT業界の人を応援!! 資格取得ガイド(IT資格難易度一覧)

    IT資格難易度一覧(ベンダー資格)の難易度の補足 レベル5 OracleMasterプラチナ、CCIEは、共に下位の資格を取得した後に実技試験の 結果資格を取得出来る資格です。 レベル5の資格を1つでも持っていれば、間違いなくその分野のプロとして周りに 認められる事は間違いありません。 転職、社内評価共に高い評価を得る事が出来る資格です。 レベル4 レベル4の資格は、それ単体の試験での合格で取得する事は出来ない資格です。 MCSEはMCPを7つも取得した後になれる資格ですし、CCNPもCCNAを取得後に 4つの資格を取得する事が出来た後に取得出来る資格です。 入社5~6年目までには取得しておきたい資格です。 レベル3 レベル3の資格もそれ単体の試験での合格で取得する事は出来ない資格です。 MCSAはMCPを4つも取得した後になれる資格ですし、CCDAもCCNAの取得レベル が前提の資格です

  • SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro

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

    SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro
  • 1