サービス業で製造業をしたがる理由がよくわからない． - 後悔^H^H公開日記：別館
SIer っていうのは，サービス業だと思うんすよ．経済産業省的分類でも，実体的にも． でも、これってしかない場合もあるかなと思います。だって、中に製造技術がないんだもん。 別にその製造を外注にするというビジネスモデルが悪いと言っている訳ではなくて、それでお金儲けがちゃんと出来てるならそれでいいです。ただ、このまま技術が空洞化しつづけたら間違いなく淘汰されていく気がします。 で私は製造したい人なんです。作りたいです。技術を身につけたい。でも、社内に製造の技術はない。だったら外に学びにでるしかない。外部のセミナー、コミュニティーに飛び出してみるしかないのかなと思っています。 サービス業だからって，作る事がないわけではなくて，例えば飲食店なんて調理がなきゃ始まらないわけですが． しかし調理は，飲食店の構成要素の一つでしかありません．空間とか"おもてなし"とか，その店なりの付加価値がなければ飲食店
はてなブログ | 無料ブログを作成しよう
晴天の価値 2月中旬に出張で千葉へ行った。5日間の滞在中はずっと快晴で、気温は20℃に迫る春のような暖かさだった。仕事は朝から晩まで現場を走り回る過酷なもので、身体的にも精神的にも追い込まれた。毎朝、京葉線から見える美しい景色を眺めて正気を保っていた。太平洋へ燦々と…
人生いろいろ、技術者もいろいろ、搾取されないに越したことはないよね - 雑種路線でいこう
受託調査＆研究補助→ユーザー企業コンサル→通信事業者コンサル→Web企画構築→金融SE→研究・コンサル→パッケージベンダ・マーケ→パッケージベンダ・技術渉外のおいらが来ましたよ。 こんなことをいっては「上流」にいる方々には失礼かもしれませんが、IT業界は上流にいるほど得になるような構造になっています。それぞれのプロジェクトについて自分のところで十分な経費を確保してから下流に流しますので、下流にいるほど仕事がきつくなります。それをうすうす感づいているから、若い人は少しでも上流に行きたがります。PGをしばらく勤めたらSEに、SEを少しやったらコンサルに。産卵まぢかの鮭でもあるまいに、自分の技術レベルも分からないまま、やみくもに次のステップを目指そうとする。 実はプログラムを書かなきゃいけない仕事ってやったことないんだけど、Web企画構築の時はベンチャーで大手ISPに提携を申し入れ「お前らに顧客
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
IT業界の未来について - オオカミさんに囲まれた、か弱きヒツジのつぶやき
どうやら、インターネットの片隅でブログを通して論戦をしているみたい。 くわしくは、こちら。 「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか VS 元請けにこだわる理由 どちらかといえば、オイラは後者のはぶあきひろ氏の立場に近いのかな。規模は、大幅に異なるけど。 元請けと下請けのどちらがいいなんて議論は、はっきり言って無意味。 また、SI業界の問題は、「多重下請け構造」「派遣」「人月」の三要素なんてのは、業界の常識。 建設的な議論になっていないのが、笑止千万。 まず、後者から考察すると、この問題について万人が納得する解を両者はお持ちなのでしょうか？ 「多重下請け構造」は、製造請負という発注方法がある限りなくなりません。業務が肥大化細分化された中で、社員がすべて高い生産性を持っているわけではありません。業務分担の中で簡易なモノは単価を安くし、難易度の高いモノは単価
ニッポンのSIが置かれている隘路と展望 - 雑種路線でいこう
まあ別に給与水準が下がれば転職すればいいし、それが産業のダイナミズムって気もするんだけど。ニッポンのSI業界が置かれている隘路って1990年代以降オープン化でハードの利鞘を稼げなくなったところに、開発生産性の劇的な向上と技術サイクルの短期化で生産性格差が劇的に拡大し、プロジェクトの失敗リスクが増大したことにある。かかる環境変化で、以前から潜在的な問題であった系列取引、重層的下請け構造、人月商法、人材の低い専門性といった課題がリスク要因として浮き彫りになった。 ブランド力が通用しない市場は、自然と価格競争になるわけですが、今のSIerは、どこも同じような重量級の開発プロセスだから、開発プロセスでは差がつかない。後は、下請けの単価を下げるか、自分たちの給料を下げるかになってしまいます。 つまり、SIerの給与水準は、今後少しずつ下がっていく。負けているわけじゃないけど、ジリ貧みたいな。 残念な
IT業界の下請け構造の現実と改善策 - novtan別館
ひがさんに対する消毒たんのツッコミはある意味正しいんじゃないかと思うな。ちょっと補足的に。突っ込まれそうだけどｗｗ 今のSI業界は、大手SIerを中心とした多重下請け構造ですが、その原因の1つには、「大手SIerの社内人件費単価の高さ」があります。 ここでは「社内人件費単価」の意味をプロジェクトに課せられる社員一人当たりの単価とします。 下請け構造がなくならないのは大手SIerの社内人件費単価が高いから - yvsu pron. yas 言葉を繋げれば内容も高尚になると思って「社内人件費単価」なんて言っているのは滑稽に過ぎるwww こんなことは、ふつうに「給与水準」と言えばよいのだ。「意味を」は「定義を」にすべきだし、「プロジェクトに課せられる」は「プロジェクトに掛かる」だろう。「社員」に「プロジェクト」が「課せられる」のであって逆ではないwww 「単価」という言葉は製品商品に用いられるも
コンサルを増員したってSI案件の提案力は上がらない：ナレッジ！？情報共有・・・永遠の課題への挑戦：オルタナティブ・ブログ
土曜日の日経朝刊の企業面に「ITコンサルタント増員 企業向け提案力強化」という記事が載っていた。 記事の内容は、NTTデータや富士通といったSIer大手がIT戦略の提案やシステムの企画を行うコンサルタントを拡充するというもの。両者とも数百名規模で増員するとされる。NTTデータについては今年の4月に既に同様の報道でコンサルタントを1000名体制にするとされていたがその続報にあたる。 SI業界に於いては、コンサルタントの増員というブームは周期的に唱えられる（私から見ると）不思議な経営手法である。景気が悪くなり顧客企業でのIT投資が伸び悩み売上が減りそうに時期になると必ずこのお題目がでてくる。 前回のブームは、2000年から2001年頃のITバブル崩壊直後で、私の机の引き出しにしまってあった「コンサル強化記事スクラップブック」によると、当時も以下のようなニュースが流れていたことがわかる。 200
Amazon EBSと日本のシステムインテグレータの行く末 - Thoughts and Notes from CA
Amazon EBSというAmazon Web Serviceの新しいサービスが開始された。強烈なまでに投資と試行錯誤を繰り返しながら、着実にCloud Computingの持ち駒を増やすAmazon。きれいごとだけでなく、泥臭く、そしてスピード感をもって一歩一歩着実に進むその姿には本当に感服する。 米RightScaleや米Ylasticのような，Amazon EC2の仮想マシンを管理するサービスを提供する事業者も，Amazon EBSへの対応を表明している。ユーザーはこれらサード・パーティのサービスを使用することで，EC2とEBSを組み合わせたクラスタ運用やデータベース運用などを省力化できる。 また、Amazon EBSの発表というプラットフォームの更新に伴い、早速そのサポートを表明するIT企業が直ぐにあらわれる辺りに景気後退をものともしないアメリカのIT企業の躍動感を感じる。 そして
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
プログラミングファースト開発のアキレス腱 : 404 Blog Not Found
2008年07月21日15:00 カテゴリArt プログラミングファースト開発のアキレス腱 ktkt. プログラミングファースト開発の必要性 - ひがやすを blog これをふまえて考えたのが、以前提案したプログラミングファースト開発だ。 プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。 実は私自身、この言葉が生まれる前から実践してきたのだけど、一つけったいな問題点があるので、それを指摘しておく。 それが何かというと、 客がそれを安易だと勘違いして、安価だと思いやすい こと。 プログラミングファーストの場合、最早だと打ち合わせのその場で動くものを見せたりする場合がある。客が分かっている人だと、その事にボーナスを出
プログラミングファースト開発は物神化に並ぶ人月商法脱却の解か - 雑種路線でいこう
プログラミングファースト開発と最初に聞いて、ソフト開発の手順としては当たり前過ぎて、最初は何が新しいのかさっぱり分からなかったんだけど、肝は如何に受託開発でそれを貫徹するかの交渉術や契約形態にありそうだということに合点がいった。人月に代わる値付けの方法、機能や品質に応じた対価を得る手法として、パッケージ販売やSaaSといった共通化と利用者拡大の他に、相対取引での値付けにも新たな道は広がるのだろうか。 実は世の大半の名だたるソフトウェアに厳密な仕様書などないし、受託開発でも設計書と呼ばれているものがコードと同期している可能性はかなり低い。これはソフトにとって役に立つこと、問題を起こさないことが、仕様書通りに動くことよりずっと重視されてきた結果であって、みんな心のどこかで気掛かりではあるけれども、マクロ的には合理的なトレードオフの結果であって必ずしも悪い話ではない。 恐らくプログラミング・ファ
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
年功序列がITの進化を阻害している? - ひがやすを技術ブログ
例えば、ITは1980年代以降のものですから、その頃すでに企業の中堅になっていた世代の人たちが、いま企業において決定権を持っているわけですね。その人たちは、新しい技術に適応力を持っておらず、ITが得意なのは若い人です。だから、もし会社の中でITを活用するようなことになったら、下克上が起こる。 そういう人たちがITの導入に積極的な考えを持つとは考えられません。これは、日本型企業のひとつの特徴である年功序列制が、新しい技術の導入に抑制的に働くことを意味します。 会社の中で、ITを活用するようになったら、ITの得意な若手によって下克上が起こるそうです。どんな下克上なんでしょうね。 まぁ、これはネタだと思いますが、でも、鋭いところもある。 「日本のSIの生産性は20年間進化していない」と読みかえてみると、実はあっているんじゃないでしょうか。ITの技術は、常に日進月歩ですよ。これはまちがいない。SI
泥の業界でも仕事は宝石なこともあるんだよ - GoTheDistance
id:wa-renさんの所でこれと同様の立ち位置のイベントが開かれていた。お疲れさまでした。 ネタ元 "第1回 泥カン"無事終了。まとめと一部スライド公開 泥カンについて一言 情報系学生のための交流企画「IT企業はほんとに泥のように働かされるのか」レポート ITギョーカイ俯瞰図 あの絵はポンチ絵だからあんまりマジで突っ込まれるとwa-renさんもちょっとツラいと思う。でも｢SI目線｣から見たらあの絵はいい絵だと思います。SIの｢S｣は業務システムの｢S｣なので仕事の単位が会社単位になる傾向が圧倒的に強く、id:amachangが疑問に思ってたBtoC市場の仕事はSIにはふってこないことが多いです。個人顧客用のWebサイト(通販とか)は大抵子会社に作らせているんじゃないかなってふと思いました。ツタヤにおけるツタヤオンラインとかね。 泥ってなんやねん それよりも何よりも、｢泥のように働く｣から
情報系学生のための交流企画「IT企業はほんとに泥のように働かされるのか」レポート - 西岡Blog
情報系学生のための交流企画「IT企業はほんとに泥のように働かされるのか」レポート 情報系学生・ 若手エンジニアのための交流企画「IT企業はほんとに泥のように働かされるのか」ナナロク世代がお答えします、 というイベントが東大研究室主催で行われるというので、参加してきました。 個人所感としては、「IT業界は泥のように働かされるのか？」→「IT業界の全てで泥のように働かされるわけではない。少なくとも僕はそうは感じなかった」というパネリスト達のメッセージは、学生達に伝わったのではないかな、と思いました。IT業界をイメージするための場は構築されつつあるのかなと。 以下レポートになります。基本的に、走り書きでメモした内容なので、間違いが多いとは思います。間違いがありましたら、 コメントなどでお知らせいただければ幸いです。 イベント目的2008年5月28日、IPAが開催したイベント「IPAX2008」に
株式会社マジカジャパンの羽生章洋が書いてるブログ:本当にERPは効果を出しているのか？ - livedoor Blog（ブログ）
ERPと呼ばれるものがあります。エンタープライズリソースプランニングの略で、経営資源計画と訳されます。統合基幹システムという言い方のほうが最近では一般的になりつつあるようです。要するに大きな業務システムということです。 業務システムの世界は大きく二分されていて、フルスクラッチ派とパッケージ派に分かれます。そして日本はスクラッチ派がまだまだ大勢を占めており、パッケージを導入する場合にもカスタマイズと呼ばれる、つまりパッケージに独自修正を加える比率が非常に高いとされています。 この事態をして「日本の業務は」云々をいう方が多いです。いわくもっとパッケージに合わせるべきである、と。独自の業務にこだわるからシステムの導入に膨大な手間がかかるのだといいます。 さて、では海外で業務をパッケージに合わせて導入をした企業がその後いったいどれほどの業績向上を達成したのでしょうか。これを追いかけると、実はさほど
プログラミングを単純労働と捉える3つの理由 - GeekFactory
int128殿の会社では、 >プログラミングは誰でもできる、頭を使わない作業 と思う方が多くいるのかしら？ http://d.hatena.ne.jp/int128/20080414/1208181589 うちに限らず、多くの大企業SIerではプログラミングを単純労働と捉えています。その理由は3つあります。 （1）プログラミングは業務をプログラムに落とし込む単純労働 SIの開発手法（の考え方）は30年前から進化していません。業務をプログラムに落とし込む作業は誰がどうやっても同じようになるという思想に基づいています。現在のように高品質なフレームワークやライブラリが溢れる時代では、いかにそれらを組み合わせて作るかが効率化の鍵になります。組織のトップが進化した設計思想を理解しようとしないのは問題です。 30年前の設計思想であれば、プログラミングは業務をプログラムに落とし込む単純労働です。 （2）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
民間システム開発撤退、エーティーエル、社員半減
takeda-soft.jp