業務系エンジニアはどうしていくべきか？ - 急がば回れ、選ぶなら近道
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい
第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp
「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニアと仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力（ばりき）のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク（＝作業）の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス
カウンターオファー！？
なんとまあ、まさかとは思っていたが、例のプロジェクトについて相談があった。 プロジェクトを担当する部長から連絡があったのだ。 部長「今回、ソフトウェアの部分を強化する方向で部門として検討していて、20人ぐらいのチームをつくって推進しようと思っています。」 部長「というわけで、このプロジェクトを推進してもらえる人を探しているんですよ。」 私「はあ。」 部長「ついては、まだ日本に居られるわけだし、もう一度、やってみませんか？」 私「は？私ですか？」 部長「ええ。このプロジェクトを元々推進されていたわけですし。社内でもそういう声がありましてね。」 部長「マネージャーのポジションで、給料も1.2倍ぐらいにはなりますよ。」 なんと。 これって所謂カウンターオファーってやつ？ だがしかし、給料は微妙にけち臭い上げ幅である。 こっちが提案していたときには殆ど相手にせずだったくせに、ここへ来て、えらい方向
2006-03-20
http://satoshi.blogs.com/life/2006/03/post_8.html うーん，ほとんど全くその通りなんで突っ込みどころがまるでない． 私はこの業界で多くのエンジニアも使ってきたが、優秀なエンジニアとそうでないエンジニアの生産性は（誇張抜きで）２０対１ぐらいである。そんな簡単な作業しか出来ないエンジニアとも呼べないようなエンジニアが沢山いてもマネージメントが大変なだけである。 これらは常識なのだが，なぜか公式の場やマスコミには存在しないことにされてしまう． そしてもっとも許せないのが、そういった上流→下流という階層構造でプログラムを作る工程そのものだ。(中略) 日本のエンタープライズ系のソフトウェア業界は、そんな根本的に間違ったソフトウェアの作り方を長年してきたために、まるで建築業界のような下請け・孫請け構造が出来てしまい、下流のエンジニア達が十分な経験も得るこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
