SIer

2014/02/12

SIerで生きるエンジニアに送るボトムズ節

ぶっ潰しても、切り刻んでも、焼いても死なない。
時に利己的に、時に利他的にとりまく環境を変えてまで生き延びる。

そう。それが異能の因子だ。

証明して見せろ!己たちの異常さを!!己たちの正体を!!!

ラスト・チェック!!!!

このテストで答えが出るはずだ。

ゴキブリめぇ!ウジ蟲め!!

這いずり回り、のた打ち回り、
五臓六腑を撒き散らしても、生き抜いて見せろ!!!

・・・しかし、生き延びたとしてその先がパラダイスのはずは無い。

ボトムズWeb|ペールゼン・ファイルズ|SPECIAL Vol.7
↑ いきなりムービーが流れるので注意!w

なーんつって。外野がうるせーんだよ。


  このエントリーをはてなブックマークに追加

 にほんブログ村 IT技術ブログ システムエンジニアへ  ← その他のSEブログはこちら・応援クリック歓迎
tsutaken at 12:10|PermalinkComments(1)

2011/08/21

大手SIerで働いています。

Twitter / @wacott: [仕事]大企業で働くとはてなでdisられる。

らしいので、書いておく。( ・∀・)アヒャ

  このエントリーをはてなブックマークに追加

 にほんブログ村 IT技術ブログ システムエンジニアへ  ← その他のSEブログはこちら・応援クリック歓迎
tsutaken at 17:07|PermalinkComments(0)TrackBack(0)

2011/02/23

これからの時代は、商品(サービス)が人に与える価値で勝負が決まる。

販売部門、営業部門に、売上目標を立てるのは愚策である。販売部門や営業部門は、利益を出すための部署であり、利益が出せないのであれば、どんなに売上があっても、営業としては駄目である。営業部門の一人一人に利益目標を与えると、安易な値下げが最も良くないことが営業の現場の人間でもわかるようになる。

一方、生産部門、開発部門が、費用削減を目標にするのも愚策である。そのような目標を立てると、イノベーションが起きなくなる。そして、それどころか、食品の場合、混ぜ物をして、原価を下げようとする。なぜなら、材料費をより下げるしようとする方向に努力が向かうからである。多くの偽装事件が食品業界に生じているのは、食品メーカーの生産部門、開発部門が費用削減を目標にしているからではないか。原価を下げようとすると、混ぜ物、水増し、産地偽装、消費期限切れ商品の再利用が生じる。開発部門は費用を削減して利益確保を目指すのではなく、売れる商品をつくることに専念すべきである。営業部門が「こんな商品売れないよ」と言ったら、開発部門は、素直にそれを認めるべき。「物が売れないのは営業のせい」ではない。これからの時代は、商品が人に与える価値で勝負が決まる。開発が目指すべきは、原価削減による利益確保ではなく、魅力的な商品による売上向上である。

昔のような「作れば売れる」時代は終わった。物の時代から人の時代になったのだから、人を中心に考えなければ駄目だ。その違いは、あたかも、メーカーが作った物(地球)の周りを消費者(太陽)が回っていた天動説の時代から、コペルニクス的転回が起き、消費者(太陽)の周りで物(地球)が回り、生活を育む地動説の時代に移ったようなものである。

前世紀の日本企業は、営業部門に売上目標を、開発部門に利益目標を立てている会社が多かったのではないだろうか。今世紀はそのような目標設定では駄目だ。営業は利益を、開発は売上を目指すべきなのである。

これからのSIerには、この発想が不可欠だと思う。


  このエントリーをはてなブックマークに追加

 にほんブログ村 IT技術ブログ システムエンジニアへ  ← その他のSEブログはこちら・応援クリック歓迎
tsutaken at 12:34|PermalinkComments(0)TrackBack(0)

2011/02/02

プログラムの換金方法を考える職業はプログラマなのか?

頑張って欲しいな〜。

これからは、プログラムをいかに金に変えるかどうかをプログラマが真剣に考える時代です。

でも、色々と疑問が沸いたのも事実。
 ・如何にお金に換えるかを真剣に考えていたら、「プログラマ」では無くなるんじゃないか?
 ・プログラマという「専門家」だからこそプログラミングスキルが磨けるんじゃないか?
 ・スピード感は必要だけど、1人でやらなきゃいけない理由は無いんじゃないか?

プログラムをお金に換えるってことは、
 ・見積りを作ったり
 ・契約書に目を通したり
 ・ユーザの要望を聞いたり
               ・・・etc
しなきゃいけない訳ですから。

だから、ryoasaiさんのように、
私は、めまぐるしく変わる技術の流行に振り回されて生きるより、リファクタリング(私がプログラミングで最も楽しいと思える作業 = リファクタリング)やドメインモデリングのようにより本質的で長い時間をかけて追求するような職人芸としての技術に魅力を感じます。
という方がいても良いと思うんですよね。

そういえば、起業した知人が
 「やりたいことをやろうと思って起業したけど、社長になったらできなくなった」
と言っていたのを思い出しました。

まあ、最終的には
 「プログラマでは無い凡人の私はどうしたものかな〜?」
と言う話にいきつく訳なんですが・・・w


  このエントリーをはてなブックマークに追加

 にほんブログ村 IT技術ブログ システムエンジニアへ  ← その他のSEブログはこちら・応援クリック歓迎
tsutaken at 12:19|PermalinkComments(0)

2011/01/19

Are You 「SIer脳」 or 「アジャイル脳」?

SIerに対するキビシイご意見を発見。

そもそもスキルの低い頭数要員でできる仕事が5年先10年先もずっと取れるという考え方は正しくないのではないでしょうか。
(中略)
わざわざJavaを使ってスクラッチ開発するようなシステムというのは自然に

・パッケージでは得られないような高性能を追求する
・複雑な商品モデルを扱い将来にわたって機能拡張を容易にする
・既存のシステムを組み合わせて全体として統合したシステムを構築する
・今までにない新しい考え方のサービスを実現する

といったような比較的高度な技術力を要求される分野に限られるようになってくるという傾向があるのではないでしょうか。

で、まったくその通りだと思います。
実際、SIerの現場で仕事をしている者の実感として、
「頭を使うことは多いけど、作業ボリュームは少ない仕事」
が増えてきている気がしています。

この業界の技術者には「SIer脳」の人と「アジャイル脳」の人がいるように思います。
(中略)
私もそうですがアジャイル脳の人は本能的に設計とコーディングが切り離せないものであるという考え方に心底ほれ込んでいるのですね。
(中略)
一方SIer脳の考え方では、たとえ繰り返し型開発の価値を認める人であっても、やはり設計(書)が先で、コードはそれに付随して半自動的に製造されるものであるという考え方が根強いようです。

んー。設計書にも種類があると思うんですよね。
システムの全体を語る資料はコーディングより先に必要だと思います。
逆にコードからそれができるのは「すごいなぁ」と。
自分がコーディングしている姿を想像してみると、とてもそこまで気がまわっていません(ToT)

一方、最適なプログラム構造とかを考えるのはコードからで良いと思います。
ある程度リファクタリングを済ませて、最終的に落ち着いてから資料化する方が効率的だと思いますし。

ってことで、やはり私はどちらかと言えば「SIer脳」なのかなぁ??



  このエントリーをはてなブックマークに追加

 にほんブログ村 IT技術ブログ システムエンジニアへ  ← その他のSEブログはこちら・応援クリック歓迎
tsutaken at 12:34|PermalinkComments(2)