下請け構造がなくならないのは大手SIerの社内人件費単価が高いから - ひがやすを技術ブログ
今のSI業界は、大手SIerを中心とした多重下請け構造ですが、その原因の1つには、「大手SIerの社内人件費単価の高さ」があります。 ここでは「社内人件費単価」の意味をプロジェクトに課せられる社員一人当たりの単価とします。 大手SIerでは、社内人件費単価が外注の単価と比べて、べらぼうに高いことが多い。だから、プロジェクトマネージャも利益を出すために、社員の数を抑え、できるだけ外注しようとするのです。 なぜ、大手SIerの社内人件費単価が高いかというと、1つは、大会社であるため、オーバーヘッドが大きいことです。もう1つは、もともとの人件費の単価が高いこと。優秀な人を集めようとすると、必然的に単価を上げざるを得ません。 それ以上に大きな原因は、単価を下げようとするインセンティブが働かないことです。 大手SIer通しの競争もありますから、ぬるま湯なビジネスをやっているわけではありません。 見積
分離発注と分割発注で大手SIerが没落? - ひがやすを技術ブログ
これは，1社に“丸投げ”する代わりに，そこが使っている下請け企業を調べて，何社かの下請け企業に直接発注する方法です。元請け企業の“オーバーヘッド費用”を削減できるので，この方法を有効に活用できると，おおげさではなく，開発費用は半減します。 上流工程と下流工程で発注するベンダーを変える(分離発注)ことにより、競争によってコスト削減を目指す。これは、まぁわかりますね。ありそうでなかったのがSI業界における分割発注です。 元請けに頼まず、複数の下請けに対して分割で発注するわけです。下請けにとって見れば、元請けがマージンととらないから、利益率が上がる。発注元にしてみれば、元請けに余分なマージンを払わなくてすむ分、コスト削減ができる。 この方法の懸念点は、元請けがSIをやらない分、その負担は、発注元のシステム部が追うことになります。それが可能なら、この「分離発注」と「分割発注」は、十分に有効な方法で
ガラパゴス、ガラパゴスってうざいんだけど - ひがやすを技術ブログ
ガラパゴス諸島では、外界から遮断された環境で生物が独自の進化を遂げた。これになぞらえて、国内市場に安住して世界に通じる製品やサービスを生み出せなくなった日本のＩＴ業界を「ガラパゴス化」と呼び懸念する声が2007年ごろから広がりだした。ケータイ先進国といわれながら海外市場からの撤退を余儀なくされた携帯端末業界や、国内企業頼みのシステム開発業界などがその例で、最近はＩＴ業界内でも「ガラパゴス化」問題が議論されるようになっている。 単純に世界に通じていれば良いというもんでもないでしょう。ある分野で負けずに勝ち残っていればそれでいいんじゃないの。 ガラパゴス、ガラパゴスって本当にうざったい。 別に国内に留まれっていってるわけではないですよ。国内に向いたサービスもあれば、世界共通でやったほうがいいサービスもある。海外に出ないから一律悪いみたいな固定概念は、おかしいんじゃないのということです。 フレー
IT業界は成功するチャンスの多い夢のある業界 - ひがやすを技術ブログ
泥問題、あるいは老害問題で、すっかり評判を落としたIT業界(SI業界)。他の業界へ転職しようと思った人、IT業界には入るまいと思った学生も多く出たことでしょう。 ネガティブな面は確かにあります。老害は一朝一夕にはなくならないことも確かです。 しかし、一方で、努力すれば、成功するチャンスの多い夢のある業界でもあるのです。 いまだにソフトウェアの世界では「下を走ってくる」奴が上に行く余地がどっさり残っている。理由は二つある。 一つはインターネットという別の高速道路網が存在すること。ソフトウェア「エンジニアリング」に限って言えば、こちらの高速道路の方が学校という高速道路よりもずっと充実している。しかも料金ははるかに安い。わざわざ「学歴高速道路」に乗るのはかったるくて仕方がないだろう。 しかし、もう一つの理由を忘れてはならない。それは、ソフトウェア「エンジニア」になるための投下資本が実に少ないとい
優秀な技術者をラインマネージャにすると「だめ」になる - ひがやすを技術ブログ
たいていの会社は、部長だとか課長だとか呼ばれるラインマネージャがいます。ラインマネージャの仕事は、部下が能力を発揮できるようにサポートしてあげることです。 会社の中で、昇進していくとは、平社員 -> 課長 -> 部長 -> 取締役のように役職を上げていくことです。役職の名前は、会社によって違うと思いますが、その仕組みはどこも一緒でしょう。 でも、実はここに問題があります。 あなたが優秀な技術者で平社員だとします。その仕事ぶりが認められて、課長に昇進することになりました。そのとき、あなたは、給料と引き換えに、大好きだった技術者のポジションを失うのです。技術のために時間を費やすことは許されず、管理業務に追われる日々が続きます。 ラインマネージャは、技術よりも組織を動かすほうが好きな人にとっては、やりがいのあるポジションです。しかし、「管理業務なんかめんどくさい」「技術で世の中を変えてみせる」と
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、本当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
