タグ

itと考え方に関するmoritataのブックマーク (8)

  • 大いなる力には大いなる責任が伴う:公共性と独断専行の自治を求めるプラットフォーム | p2ptk[.]org

    Electronic Frontier Foundation デタラメを信じろと? 何十年にもわたって誇大広告を見せ続けられてしまうと、企業のミッションステートメントを気に留めることなく見過ごしてしまうのは仕方ないのかもしれない。だが、そうした企業との関係を終わらせるという話になると、テクノロジー大手の掲げるモットーは邪悪さを帯びて見える。 「世界の距離を縮める」(Facebook)、「世界の情報を整理する」(Google)、「顧客がオンラインで買いたい商品が何でも見つかる」(Amazon)、「パーソナル・コンピューティングを一人ひとりが利用できるようにする」(Apple)。テック・ジャイアントの創業時のミッションには、我々のデジタルライフに欠かせない存在になりたいという願望が込められていた。 そして彼らは成功した。我々は家族の写真や家計簿、手紙といった秘密のデータをこれら企業に預けるよう

    大いなる力には大いなる責任が伴う:公共性と独断専行の自治を求めるプラットフォーム | p2ptk[.]org
  • 派遣は工程表を作っちゃダメなんですか!?

    連載目次 請負か、派遣か、それが問題だ システム開発にも大きな影響を及ぼす改正民法の施行が、2020年4月に迫っている。 改正法によれば、請負契約での不具合に対する損害賠償請求の考え方や、システムが未完成のまま契約が解除されたときにベンダーが既作業分を請求できるのか、などの考え方が大きく変わる。 一方で、「当該システム開発は請負か否か」の争いは、今でも多い。請負契約であれば、ベンダーはシステムを9割方作り終わっていても、最後まで完成させない限り、1銭ももらえない危険がある。 準委任や派遣であれば、システムの完成とは関係なく、働いた分の代金は払ってもらえる。 プロジェクトが途中で頓挫してシステムが完成しなかったとき、「請負契約だからお金は払わない」とするユーザー企業と「派遣契約だから働いた分は払ってもらう」と主張するベンダーが法廷の場で争うことは珍しくない。 この「請負か派遣(あるいは準委任

    派遣は工程表を作っちゃダメなんですか!?
  • COBOL技術者を絶滅させても何も問題は解決しない | おごちゃんの雑文

    最初はもっとキャッチーなタイトルにしようと思ったんだが、そんなしょうもないことしてもしょうもないんで。 そろそろCOBOL絶滅のシナリオを考えようか 「語るに落ちる」とはこのことである。この人はCOBOLに親でも殺されたのだろうか? こんな炎上芸で問題が解決したら、何の苦労もない。 COBOLのメリットを一々挙げて反論する気はない。しかし、事実として現にCOBOLは多くの場所で使われている。その理由は何か。 あれこれあるのであるが、最大のメリットにして最大のデメリットとして挙げたいと思うのは、 後方互換性の高さ である。 後方互換性が高いことについてのメリットは、誰でもわかることだろう。COBOLもそれを売りにして来た。「古いCOBOL」のコードであっても、現代の最新のCOBOL規格から見てvalidであって、正しく同じ動作をするバイナリが出て来る。COBOLは実に60年近い歴史があるのだ

    moritata
    moritata 2019/04/05
    なんか、タイトルのせいでお互いがすれ違ってる感が… どっちの記事もCOBOLを敵視してないんだけど…
  • 「突然落ちて当たり前」にエンタープライズITは堪えられるのか?

    少し前の話ですが、シアトルのアマゾン社に出掛けて米Amazon Web Services(AWS)の幹部の前でプレゼンをする機会がありました。 前回のこの連載「AmazonがエンタープライズITを『ぶっつぶす』」でも述べたとおり、私は「AWSはクラウド時代の鍵となる存在」と考えています。その一方で、現状の日のエンタープライズITシステムをAWSに移行させるには、技術的、社会的にハードルがあり、簡単ではないとも見ています。 野村総合研究所(NRI)はAWSが日で最初に認定したプレミアコンサルティングパートナーです。AWSを使ったシステム構築の経験は既に幾つもあります。その経験から率直に言うと、AWSを使ったシステム構築は喧伝されるほど容易ではありません。 こうした問題意識があったのでこの機会に、日のエンタープライズITの現場の実情をAWSの幹部に理解してもらい、システム構築や運用を容

    「突然落ちて当たり前」にエンタープライズITは堪えられるのか?
    moritata
    moritata 2015/10/26
    やっぱりこの程度なんだろうなぁ~。自分はクラウドって多少の障害があっても全体で可用性を維持するシステムだと思ってた。この程度の認識でクラウド使うのかーすげえな
  • SIerの中の人がヤル気を失っていく理由 - ひがやすを技術ブログ

    SIerで働いているみなさん。ヤル気十分でいきいきと働いていますか? Yesと胸を張って言えない人、新人の頃はどうでしたか。 入社したころは、みんなヤル気にあふれているんです。なのに、三年も経つとヤル気がな くなって、惰性で仕事をするようになる。 これは、SIerだけでなく、大企業で共通に見られる傾向です。 なぜ、徐々にヤル気を失っていくと思います? それは、「自分の頑張りではどうしようもない」「頑張ってもそれほどプロジェクトが良くなった気がしない」「頑張ってもそれほど評価につながらない」という経験を積み重ねるたびに、だんだんと無気力になってしまうためです。 努力が無効だという経験を積んでいくと、誰も努力しなくなりますよね。そうやってヤル気を失ってしまうのです。 規模の大きいプロジェクトにいるほど、その傾向が強くなります。なぜなら全体に占める自分の割合は、ほんの僅かなので、どんなに努力して

    SIerの中の人がヤル気を失っていく理由 - ひがやすを技術ブログ
  • システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道

    どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ10数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体(特に技能として)化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ

    システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
  • どうしてプログラマがPMになりたくないのか - GoTheDistance

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

    どうしてプログラマがPMになりたくないのか - GoTheDistance
  • IT業界で楽しく仕事をするための10カ条 - @IT

    Java News.jp(Javaに関する最新ニュース)」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」(駆け足の要点説明)でお届けします(編集部) 2009年、日の春は多くの学生さんたちが卒業し、また社会で活躍し始める時期です。 IT業界は3K、7Kなどと、いろいろネガティブな面も取り上げられます。けれども、「ものづくり」の楽しさや、人の役に立つ仕事として@ITで取り上げられるような業種で働こうと考えている人も多いことでしょう。 なんとなくIT業界を選択した人から、もしかしたらあまり気が進まないのに、IT業界に入ってしまった人がいるかもしれません。その一方、プログラミングやコンピュータに関する事柄がとても好きでIT業界に入ってきた人もいるでしょう。 記事では、IT業界を目指している学生さんや入社間もない新人に向けて、より楽しく

    IT業界で楽しく仕事をするための10カ条 - @IT
  • 1