なぜ｢Cドライブ｣なのか､知っていますか
ぼへちゃん、今日は新人さんへの研修をやっているようです。 ぼへ：わからないことあったら、何でも聞いてね！ 新人：あの、素朴な疑問なんですけど、なんでCドライブっていうんですか？ ぼへ：それは不思議に思うよね、AとかBとかなくて、いきなりCだものね。昔はね、AドライブとBドライブはフロッピーディスクが使っていたの。まだ、ハードディスクが高価な時代でね、Aドライブには、OSを起動させるためのディスクをいれてね、Bドライブには、アプリケーションを起動させるためのディスクをいれて使ってたんだよー。 それで、その次に使われるようになったハードディスクがCになったってわけ。 さて、ぼへちゃんは得意げに説明していますが新人さんはとてもけげんな顔をしていますね。 あれ、わかってもらえなかったのかな、と思いきや「フロッピーディスクってなんですか」という質問が来ました･･･。 ああ、そうか、この年代だと、フロ
巨大銀行の巨大システム開発で大変素晴らしい経験を得たという話
最近まで、ネット上のIT系ニュースで度々システム障害で我々にネタを提供してくれる某巨大都市銀行の次期システム開発に下請けとして新卒から参画していた。 「某巨大都市銀行の次期システム」という時点でどこの銀行かピンとくると思う。 次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合化してそれぞれのサービスを部品として再利用性やメンテナンス性の向上を図る、いわゆるSOA(サービス指向アーキテクチャ)で作り直そうというものだ。 この辺も心当たりのある銀行と次期システムとかでググれば出てくると思う。 銀行システムをSOAで構築するのは日本では初めて！！すごい！！先進的！！！という触れ込みだったらしいが、立ち上げからいるわけでもなくSOAの利点も結局実感できぬままこの業界から去ってしまったので
IT業界（インフラより）のみんな！アニメのBDを大人買いしてる場合じゃないぞ - kuenishi's blog
飲み会で話していたら、この危険さに気づいている人あまりいなかったようなので。 Google Drive、激値下げ―1TBが月額49.9ドルからなんと月額9.99ドルに アマゾン ウェブ サービスがAmazon Glacierを発表 Facebook uses 10,000 Blu-ray discs to store 'cold' data その衝撃的動画 こうやってニュースを並べると聡明な諸君は気づくだろうが、ストレージの単価がほぼ同じだ。Facebookの記事はコンシューマ向けではないが、単価はそのレベルだろうと想像される*1。 Glacierは登場した当初は「すわテープドライブまでクラウド化か？」という憶測が飛び交ったが、「テープではないらしいぞ」という憶測も登場して実際のところは分からない。GMailはバックアップにデープドライブを使っていたらしいが今でもそうなのかは分からない。
業務系システムのクラウド適用の現状 - 急がば回れ、選ぶなら近道
2013年の夏・秋の状況の整理として記録しておきます。数年したら変わっているか、そもそも自分の仮説が違うかわかるのでそのポイントとしても記述しておきます。 4月以降、「業務系システムのクラウド化」ということで、顧客各社やマーケットへのヒアリングを行ってきています。対象はいわゆるWeb系は除いてあります。曖昧な言い方になりますが一般に「IT業界でエンタープライズ」と言われるセグメントにフォーカスしています。結果としてわかったのは、企業のクラウド利用についての意識は、言われているほどには高くはない、というのが現状です。ただし、これは一様に低い、ということではなく、かなり業界やセグメントや企業規模によって違いがあります。この違いの要因と今後どのようなところに影響するのか、というのが興味の焦点です。尚、これは自分個人の印象や某社でのヒアリングの整理のみをよりどころにしているので、たかだか200社弱
「技術的負債」とは何か。原典とその対応策を探る
負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」（Technical debt）がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。 「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか？ 調べてみました。 カニンガム氏とファウラー氏による「技術的負債」 カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems,
[悪徳商法？支店]: エンジニアのモチベーションを根こそぎ奪う！たった７つの魔法の言葉
１．テスト書かなくていいので、工数減らしてください。 ソフトを作る以上、なんらかのテストは必要です。実行して結果を見るとか、ブラウザで表示するとか。その確認を楽にするためにテストを書くのに、テストを書かないからといって工数が大幅に減るわけではありません。そして、いざバグが発生したりすると、切り分けのために工数が必要になり、「テストが無い部分のチェックの必要」や「不安」がエンジニアのモチベーションを削って行きます。 結局のところ、「バグが発生しないことを前提に」スケジュールが組まれるだけです。 ２．とりあえず動けばいいです。 とりあえず動いたとして、特定の条件で発生する致命的なバグを許してくれるのか許してくれないのか、要求側の胸三寸です。実験レベルと商用レベルでは考慮すべき障害のレベルや影響範囲が異なるのですから、何を求めるのか明確にしないと、ソフトウェアは動きません。なぜなら、コンピュータ
特許庁のシステム開発が破綻した本当の理由
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
コンカチ？ポンチ？トルツメ？：一般システムエンジニアの刻苦勉励：オルタナティブ・ブログ
どこの業界でも業界用語や隠語と呼ばれるものが使われていることだと思います。それらはどこかかっこつけているような響きのある言葉が多く、「ふふん。何を言っているかわかるまい」というようなオーラを醸し出します。特にIT業界ではCGMやSaaSやSNSといった英語の略称がよく使われるため、何を言っているかわからない人を見かけることもあります。ただし、あまり垢抜けない響きを伴った隠語もあります。思いつくものを集めてみました。 コンカチ⇒concatenateから来た表現で、文字列を結合することです。ファイルとファイルを合体させることにも使います。 ポンチ⇒ポンチ絵とも言われるもので、細かい事は抜きにしたイメージを表現する図です。お客様から「ポンチ絵でいいから書いて持ってきて」と言われたら、先方がやる気で受注確度が高いか、自分の話が要領を得ていないかのどちらかです。 トルツメ⇒文字通り取って詰めること
新人SEがSIerに絶望した時に読みたいスライド4選 - ギークに憧れて
新社会人の皆さん､いかがお過ごしでしょうか｡ 最近､SIerに就職した知人が｢会社辞めたい｣というのをちらほら聞く｡聞いてみれば､彼等は仕事で挫折しているわけではない｡むしろ､技術に優れ熱意を持っている事が多い｡ではなぜ辞めたいのかと聞けば､一日中画面のスクリーンキャプチャ撮らされたりCOBOL読まされたりしていて､｢ああ､そっか…そうだよね…｡｣となる｡ そんな時は､SI業界の熱い人達のスライドを見て何かを感じよう！という事で4つ選んでみた｡弊社関係者が多いのは僕のネットウォッチの都合上お許しください｡moon and strategy moon and strategy from toshihiro ichitani 永和の@papandaさんのスライド｡｢自分の生き方を他人任せにしない｣受託プログラマの進路〜アジャイルセールスと手塚モデル〜 受託プログラマの進路 〜アジャイルセールス
業務系エンジニアはどうしていくべきか？ - 急がば回れ、選ぶなら近道
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい
あなたはIT関連の仕事に向いていないかも？--IT業界への不適応度チェック10項目
ITプロフェッショナルが仕事のマイナス面について不満を漏らすというのはよくあることだ。しかしながら、実はあなたがIT関連の仕事に「向いていないだけだ」ということはないだろうか？ IT業界というのは厳しい世界である。この業界で働いた経験がある人であれば、その厳しさは身に染みて分かっているはずだ。そしてIT業界にとどまるべき理由はないとの判断に至る人がいる一方、IT業界に魅力を感じて身を投じようという人もいる。では、IT業界で新たに働くことを検討している人や、IT業界から離れることを検討している人は、どうすれば正しい判断を行えるのだろうか？多くの若者を魅了する一方で使い捨てにするこの業界に向いているかどうかを、どのようにして判断すればよいのだろうか？以下では、IT業界に向いていない人の特徴を10個挙げている。自分自身が当てはまるかどうかをチェックしてみてほしい。 ＃1：根気がない 根気というも
2012年に開発者が学ぶべき10のスキル
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ここ数年、ソフトウェア開発の世界は比較的穏やかだった。しかし、HTML5が地歩を固め、Windows 8がWindowsの開発シーンに大きな変化を迫っている今では、ジェットコースターの日々が戻り、スピードはますます上がってきている。もし最先端に居続けたいのなら、少なくともこの記事で挙げる10のソフトウェア開発スキルを身につけることを検討すべきだ。 1．モバイル開発 モバイル開発を学ぶのに時間を割く価値などないと考えているのなら、考え直した方がいい。2011年のAndroid携帯の世界出荷台数は、ほとんどPCの販売台数と同じだ。他の有名なモバイルデバイス（iPhone、iPad、そして「瀕死状態」のRIMデバイス）を加えれば、販売台数で見
IT業界の仕事を辞めたい？--次に進むべき10の職業 - CNET Japan
わたしが以前に書いたある記事は、ちょっとした反響を呼んだ。「IT業界の仕事を辞めたくなるとき--10の理由を紹介」を書いた後、わたしのメール受信箱は、わたしの挙げた理由に賛同するメールや、どの業界に転職すべきかを尋ねるメールの波に襲われた。しばらく考えて、わたしは「代わりに何をすべきか」という質問に答えるフォローアップ記事を書いてみることに決めた。この記事では、IT業界を離れたいと考えている管理者やコンサルタントに向いている、選択肢としてあり得るいくつかのキャリアを挙げてみたい。 読者はこれを読んで、いくつかのアイデアは説得力があるが、いくつかの項目はピンと来ないと感じるかも知れない。どちらにせよ、この記事の提案は、読者が現在携わっている分野に関係したものだと考えて欲しい（すでに頭に浮かんでいた職業も、考えたこともない職業もあるだろう）。各項目のIT分野との関係は、少し拡大解釈したものもあ
エンジニアとして生きることに迷ったら：＠IT自分戦略研究所の「おすすめエンジニアライフ」：エンジニアライフ
本音が語られるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。本記事では、おすすめコラムを厳選して紹介する。 【考え方】エンジニアはもっとトレーニングに注意を払うべきだ 【考え方】エンジニアに向いてないと思った人へ 【働き方】第12話：“グループ内のトラブルにどう立ち向かう？～メンバー間の確執”の巻（中） 【考え方】エンジニアはもっとトレーニングに注意を払うべきだ 『Crazy for life（セイカツ イチバン、IT ニバン）』のonoT氏は、世のエンジニアがどういうトレーニングを受けているのかということに疑問を呈している。 氏はマラソンを例に出し、「どんなスポーツでも、初心者はいきなりゲームから入ったりはしない。そんなことをしても上達はしない。でも、なぜかランニングに関しては、多くの人がいきなり走ることから始めている
笑ってはいけないSIer 抽出
Kenji HASUNUMA @btnrouge ベンダーがサポートを打ち切ったミドルウェアを「安定版」と信じていつまでも使い続ける。そしてバージョンアップの時に痛い目を見る（その上結果しくじったら会社の信用を失う）。 #笑ってはいけないSIer 2011-11-12 05:22:25
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
プログラマ35歳定年説、定年後の未来 - GoTheDistance
株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理
SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは？ - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行わ
大規模SIは少数精鋭で乗り切れるのか？ - 急がば回れ、選ぶなら近道
まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草食集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術
プログラマー過労自殺「困難な仕事でなかった」大阪地裁、労災請求を棄却 | スラド
大阪地裁は24日、2002年に大阪府豊中市で過労自殺したプログラマーの遺族が、国に労災認定を求めていた行政訴訟について、「本人の能力からみて、特段困難ではなかった」として原告の請求を棄却した（MSN産経ニュースの記事1、MSN産経ニュースの記事2）。 報道によると、自殺したプログラマーは当時27歳で、2001年10月に京都市内のコンピューター会社に入社。翌年6月3日、豊中市内の雑居ビルから飛び降り自殺した。原告側は「入社1年足らずで複雑なシステムを組まねばならないのに、先輩や上司からの指導がなかった」と主張したが、裁判長は「会社の支援体制に問題はあったといいがたい」と退けた。死後、仕事を引き継いだ元同僚は「入社したてでは絶対にこなせない難易度と分量だった」と話し、裁判でも同様の証言をしたが、判決では証言の大半が採用されなかったという。 この報道だけでは、この件で実際にどの程度問題があったの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
