via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
異論はたくさんあると思うし、答えは一つではないと思うので、私見です。 そんなにバグが無い状態をめざさなきゃいけなくて、それが実現できるんだというなら、ロジックをハードウェアにでも焼き込んでしまえばいい。ロジックをソフトウェアで書くのは、変更に対応するためだ。 ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国 でもね、目指さなきゃならんと思うんですよ、場合によっては。全システム金額計算とセキュリティーの塊である銀行の基幹系システムをやっている身としては、１００％バグのないシステムを作るのは無理だけど、１００％バグのないシステムを目指すのは義務だと思っている。結果として、バグによって起きる障害は少ないし、起きた結果として預金が消えてなくなって痕跡も残らない、ということもない。 それだけ厳しいことをやっている理由の一つには、不正を看過しない、という要素も含まれている。もっとも、昨今の銀
最近そもそもバッチ処理というものを知らない人達を見ることが多くなりました。某プロジェクトで「いや、ストプロってよくわからないんですよ。最近書いたことないし。」という話をずーっと聞いていたのですが、本人はバッチ処理という意味で話していたことが後から判明した、ということがありました。 ああ、この人はSQLでのバッチ処理しか知らないのですね、とちょっと衝撃ではありました。とうとうそーゆー時代になったかと。 まず、誤解のないようにいうとバッチ処理、という言葉自体はIT固有のものではないです。生産管理や物流や、そういった業務では普通に「バッチ」という言葉をIT以外で使います。ただし意味はある程度同じで、「一定の塊を一度に処理をする」ということです。物流システムの業務要件なんかを詰めているとバッチっていうと、どっちのこと？なんて普通に聞かれたりします。その意味ではバッチの対義語がリアルタイムというのは
psで使うオプションについてつらつら調べたので、メモ。 psのオプションには、UNIXオプション（ハイフンで始まるもの）とBSDオプション（ハイフンを付けないもの）の2つの流派があり、それに加えてGNU psではハイフン2つで始まるロングオプションが使える。 このバージョンの ps が受け付けるオプションにはいくつかの種類がある。 1 UNIX オプション。まとめることが可能で、前にはダッシュを置かなければならない。 2 BSD オプション。まとめることが可能で、ダッシュを使ってはならない。 3 GNU ロングオプション。前に二つのダッシュを置く。 man ps より おそらく一番メジャーなのは、「ps -ef」（UNIXオプション）と「ps aux」（BSDオプション） それぞれの出力例は以下の通り。 $ ps -ef UID PID PPID C STIME TTY TIME CMD
元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 人を泣かせる花粉より、人を笑わせる胞子でありたい。こんにちは、きのこる先生です。ヤツ（花粉）らの破壊力はすさまじいものがありますね。皆さま、いかがお過ごしでしょうか。 さて、本連載もついに最終回です。今回のテーマは「転職したいITエンジニアが知るべき97のこと」。タイトルの元ネタはもちろん、私の愛する“きのこ本”こと、『プログラマが知るべき97のこと』。 前半は過去の連載を振り返った「まとめ編」。転職についてのあれこれをおさらいしてみてください。後半では転職について特に重要なこと――「ソーシャル転職」「面接」「新人エンジニアの心構え」について解説します。 ラブレターは読まれてなんぼ――
昨日と今日、都内で行われているイベント「デベロッパーズサミット 2012」、通称デブサミは、デベロッパーにとってすっかりおなじみのイベントになりました。というのも、今回が10周年なのです。 10年の節目として、今日は最後のセッションでデブサミ10周年（およびマイクロソフトのドットネット10周年）をお祝いするパーティが開かれる予定で、実は僕がその司会を務めさせていただくことになっています（残念ながらすでに参加者は締め切られたようです）。アスキー、アットマーク・アイティ、アイティメディアと、デブサミの主催社である翔泳社さんとはずっと競合会社にいた僕がデブサミでパーティの司会をするなんて、数年前には予想もできなかったことですね。 とはいえ、同じ業界にいるライバルというのは、実は交流があったりお互いにリスペクトする間柄だったりします。僕がアットマーク・アイティにいた頃から「ウチでもデブサミみたいな
インフラエンジニアを厳密に定義しないであえて使うことをお許しください。 だいたいは、ゼロスタートの山崎さんの記事を見てほしい。 巷で聞かれる、「インフラエンジニアの深刻な不足問題」は、実は「コード書けるインフラエンジニアの深刻な不足問題」であり、それは「コード書けるインフラエンジニアへの深刻な給与不足問題」なのではないかと思うのです。 インフラエンジニアに15年前にはいった人(私は大学卒業が15年前なので感覚で語れるのはこのころから)は特にインフラエンジニアなどとは呼称されていなかったはずです。オープン系サーバ屋、オープン系ネットワーク屋、汎用機のプログラマ、IPのネットワーク、ATM、sonet、INSのエンジニアなどのように分類されていたように記憶しています。もちろん複数の分野を持つ人、持たざるをえなかった人が時代を推進していたことは事実です。しかし、そのように区分されて業界にはいって
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
知人が退会出来ないことで有名な GREE を退職出来ない話。 匿名ダイアリーにでも書こうと思ったが、文章および内容の責任を明らかにする為に名前を明らかにして書く。 知人がグリーを退職しようとしている。その人がグリーに入社した経緯を書くとその人を簡単に特定出来てしまう。しかし簡単に書くと、 100% 本意で入社したとは言えない（と僕は傍目に見て思う ）。 その知人は極めて優秀なインフラエンジニアだ。コードも書ける。得難い人材と言えると思う。 しかし一身上の都合でグリーを退職することとなり、その旨会社に伝えたところ「辞めるなど許さない」「君は四人分の働きをしていたのだから四人分の金を払え」などと極めて理不尽な、脅し としか受け取れないリプライを受けていた。 さらに退職にあたって「IT エンジニアとして今後一定期間働かないこと（要約）」極めて受け入れ難い契約を追加で要求された。 また退職の書面が
もう何周目になるのでしょうか。｢情報システム部門が経営に貢献できていない｣というこの手の話は。 システム部門再生 - 経企部門が吐露する「システム部門への不満」：ITpro なんか色々ダメだしされていますが、重要なポイントは１つだけです。システム部門がビジネスに貢献するためには、自社の事業に対する理解が必要なだけではなく、その遂行手段である業務プロセスの理解が必要だ、という圧倒的な事実があることだけ。WhatとHowはクルマの両輪だと。で、この手の問題はシステム部門の問題ではなく経営の問題だという水掛け論が水びだしになるまで色んな人にされてFUDが残るのも味わい深いポイントであります。 自分達で管理できないものを改善できるわけが無い システム部門が業務プロセスの改善に貢献できない理由。突き詰めれば１つだけです。自分達で管理できずに、安易に外部に投げているからです。管理できないシステムをたく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く