独り言v6 » ソフトウェア産業の変化に日本はどう対応したか。これからどう対応すべきなのか
自分の視点で自分なりにソフトウェア産業のありようというのを見つめ直そうと唐突に考えた ソフトウェア産業の16の重大なマイルストーン からの続きで考察篇。元エントリも絡めてみてほしいが、改めて項目だけ抜き出すと以下の通り。 専業プログラマ。 複数人開発。 初歩的な開発プロセス。 専業ソフトウェア会社。 低級言語と高級言語 パッケージソフトウェア 標準ライブラリ 高度な開発プロセスとプロジェクト管理 モジュール化の推進 小規模ソフトハウスとアジャイル開発 RAD/軽量言語 ネットワーク対応 オープンソース 世界規模のプロジェクト管理 /バザールモデル 知識集約型開発 クラウド/ソフトウェアのサービス化 これを元に時代分けをできなくもないだろう。例えば 1-4はハッカーの時代 5-8はメインフレームの時代 9-12がオープン化 13以降がインターネットの時代 とでも分け
偽装請負のススメ：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 偽装請負というのは、コの業界（古い隠語だけれどコンピュータ業界のことね）のいわゆる悪弊であったりするのですが、それぞれについて分からないというお話や勘違いしてることも多いかと思うので、ちょっと整理してみよう。 ● まずは言葉の意味から ■ 請負契約 納品物に責任を負う契約。つまり、成果物が完成しなければ報酬はもらえない。どのように作ったかは個別に契約していない限り問われない。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ■ 委任契約（準委任契約） 作業に責任を負う契約。ちゃんと作業をしていれば（善管注意義務を果たしていれば）成果物がなくても報酬がもらえる。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。 ※ ここまでを分かりや
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
SIerはそこで“新規分野開拓”ですよ。
CakePHPは、PHP言語の高速開発用フレームワークです。日々、発展を遂げる各種フレームワークの動向を見極めつつ、日本発のCakePHP応援ブログとして、最新情報をお届けします。 GoTheDistance 最近SIerがだいぶヤバくなっている件 http://d.hatena.ne.jp/gothedistance/20090723/1248331426 というエントリを見て、一言。 知り合いに小さな工務店をしている人がいるのですが、本人は大工の見習いから始めた人で、「とりあえず、仕事があれば何でもする」というスタンスです。それこそ、エアコンの取り付けから、家を建てるところまで守備範囲が広いマルチな人です。 最近の不況で、仕事が減っているか、と聞いたところ、むしろその逆で、数ヶ月先まで仕事が埋まっている状態だそうです。「大手（上）が入れ替わったとしても、結局、仕事は回ってくる」のだそう
SIerの解体と再生 - ひがやすを技術ブログ
ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの
SIerのすすむみち-ネガキャン反対キャンペーン- - ITっ子の日記
なんだかふとブログを思い出した。最近は忙しくて自意識とでもいうべきか、ブログを書くべしと思うような強い自我を保ってられなかったりする日々が続いたものの、じゃあ精神を病んでたりするかというとそういうわけでもなく、会社は自分にフィットしていて面白い。面白いがゆえに強い自我が抑圧されてしまっているけれど。 昔みたいに純粋に技術をやれないのは、まあ、悲しいところだけれども、でも、ずっと技術ばかりも楽しくないと思う性格であるし、お客様に対するサービスこそが、やはり技術者の本懐だと思うので、純粋なテクノロジー以外にも頭を使うのはとてもエキサイティング。会社さえ間違えなければ、努力を怠らなければ、やはり、SIはとてつもなく面白いよ。自分の目に間違いはなかったと思う。まだまだこれからだと思うけど。 さて、本当に書きたかったのは、ござ先輩の記事に関すること。スーツ一発ツモな会話をしてもう２年近くになっちゃっ
情報サービス産業におけるグロス・ネット - Thoughts and Notes from CA
先日書いた"日本のIT業界はなぜ重層的な階層構造をとっているのか”というエントリーには多くの方にアクセスして頂いた。そして、私にとっての何よりの収穫は多くの方にブックマークも含めコメントやトラックバックを頂いたこと。これらの貴重なフィードバックをもとに本件をもう少し深堀していきたい。 今回のエントリーでは、賛否のあったグロスとネットの問題についてもう少し細かくみてみたい。日本語でいうと「グロス＝総額」、「ネット＝純額」であり、ネットで参考文献を検索するならば、総額/純額という言葉を使用した方がヒット率は高い。ただ、ぱっと見わかりにくいので、本ブログでは引き続きグロス、ネットという言葉をつかっていく。 グロス・ネットの話は、ウェブで検索した限り、"「情報サービス産業」における監査上の諸問題についての解説”が一番まとまっている。グロス・ネットの判定指標が紹介され、その指標が示す事実関係と状況に
夢のあるITには若手が殺到している 刹那的な業態が見切られただけ - 雑種路線でいこう
小野さんの記事を読んで少し悪乗りを反省した。けれどもIT業界の人材不足って、人材育成とか学生へのPRで解決できるのだろうか。僕が西垣氏の発言を読んでムカッときたのは、長期雇用を前提に若い時分は下働きに甘んじろというが、それはあまりに若手の現状認識や、いまどきのIT業界の平均像からかけ離れているのではないか、ということだ。 IT業界に限らず年功序列、長期雇用が成り立っているのは、下請け構造の上部に位置する一握りの大企業に過ぎない。彼らの高給と安定を支えるために、雇用は安定せず、人材開発のための投資もされず使い捨てられる技術者が少なからずいることの問題は、当のIPAがレポートしている。そして人材が行き渡っていないのは、元請けの大企業ではなく、そういった中小の下請け企業ではないか。 そして膨大な数の「業務知識に精通し、かつ、大規模システムをチームワークで作れる人材」を業界が欲する背景に、元請け企
受託開発に「ボリュームディスカウント」は成立するのか？ - なからなLife
IT業界の慣習で、どうしても理解できないことがある。 それは 下請け発注先を整理縮小して、絞り込んだ企業へ発注を集中させる というものだ。 大手ベンダーなら少なからずやっているだろう。 絞り込んだ企業へ集中発注することでボリュームディスカウント効果引き出すことを狙ったものだ、という説明を聞いたことがある。 この手のものは、たいてい「購買部」主導で行われる。 現場は非常に不便だ。 案件の内容によって適した開発委託先は違ってくるし、会社公認「発注先リスト」に乗っていない企業への発注には、 リストへの追加申請自体がおそろしく負荷が高い。 それ以上に解らないのは、ボリュームディスカウントが成立する余地があるのか？ということだ。 製造業のように、大量発注を受けることで、コスト削減に寄与するものがあるのか？ 「ボリュームディスカウントってのは、大量生産方式によるコスト削減効果を、大量発注者に還元する」
株式会社マジカジャパンの羽生章洋が書いてるブログ:契約のこと - livedoor Blog（ブログ）
先日、小室哲哉さんが逮捕されたという記事を見ました。自作の曲の権利を売るということでありながら、その権利を有していなかったということが問題になっているようです。この著作権に絡む問題は、実は私どものような業務システムを作っている商売でも非常に重要なことだったりします。 この契約書の内容ですが、基本的には「いつ・誰が・誰に・何を・どこに・どのように・何個・いくらで」納品するかということを明記しています。この「何を」が役務なのか具体的なブツ（成果物）なのかによって多少変わってきますが、大筋は納品に関することです。それに連動する形で対価のお支払い方法が記載されています。納品できなかった場合のペナルティなども併記されます。 さて、この契約書の中で役務ではない場合に、その成果物の取り扱いにおいて非常に重要なセクションがあります。それが「著作権に関すること」です。著作権者が誰になるのか。どのタイミングで
情シスの逆襲 (mark-wada blog)
先日、情シスオフ会というのがあって、当初ぼくも参加することにしていたが、急遽所用で欠席した。ぼくは元々情シスにいたので、このオフ会に興味があってぜひとも参加したかったので残念であった。 参加していろいろと議論してみたかったので、ここで情シスの課題だとか、あるべき姿などについて書いてみることにする。 そもそも、情シスがどうしてできただとかといったことはぼくも知らないし、あまり意味がないように思うので、現状について考えてみる方がよい。 では今の情シスが抱えている問題は何なのであろうかという問いに対する答えはおおかた次のような答えになるのではないでしょうか。“ビジネスのことにもITのことにもそれほど強くないが、両方のことを考えなくてはいけない中途半端な存在ということ”。 日本には伝統的に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業界の問題は、「多重下請け構造」「派遣」「人月」の三要素なんてのは、業界の常識。 建設的な議論になっていないのが、笑止千万。 まず、後者から考察すると、この問題について万人が納得する解を両者はお持ちなのでしょうか？ 「多重下請け構造」は、製造請負という発注方法がある限りなくなりません。業務が肥大化細分化された中で、社員がすべて高い生産性を持っているわけではありません。業務分担の中で簡易なモノは単価を安くし、難易度の高いモノは単価
IT業界の下請け構造の現実と改善策 - novtan別館
ひがさんに対する消毒たんのツッコミはある意味正しいんじゃないかと思うな。ちょっと補足的に。突っ込まれそうだけどｗｗ 今のSI業界は、大手SIerを中心とした多重下請け構造ですが、その原因の1つには、「大手SIerの社内人件費単価の高さ」があります。 ここでは「社内人件費単価」の意味をプロジェクトに課せられる社員一人当たりの単価とします。 下請け構造がなくならないのは大手SIerの社内人件費単価が高いから - yvsu pron. yas 言葉を繋げれば内容も高尚になると思って「社内人件費単価」なんて言っているのは滑稽に過ぎるwww こんなことは、ふつうに「給与水準」と言えばよいのだ。「意味を」は「定義を」にすべきだし、「プロジェクトに課せられる」は「プロジェクトに掛かる」だろう。「社員」に「プロジェクト」が「課せられる」のであって逆ではないwww 「単価」という言葉は製品商品に用いられるも
プログラミングファースト開発は物神化に並ぶ人月商法脱却の解か - 雑種路線でいこう
プログラミングファースト開発と最初に聞いて、ソフト開発の手順としては当たり前過ぎて、最初は何が新しいのかさっぱり分からなかったんだけど、肝は如何に受託開発でそれを貫徹するかの交渉術や契約形態にありそうだということに合点がいった。人月に代わる値付けの方法、機能や品質に応じた対価を得る手法として、パッケージ販売やSaaSといった共通化と利用者拡大の他に、相対取引での値付けにも新たな道は広がるのだろうか。 実は世の大半の名だたるソフトウェアに厳密な仕様書などないし、受託開発でも設計書と呼ばれているものがコードと同期している可能性はかなり低い。これはソフトにとって役に立つこと、問題を起こさないことが、仕様書通りに動くことよりずっと重視されてきた結果であって、みんな心のどこかで気掛かりではあるけれども、マクロ的には合理的なトレードオフの結果であって必ずしも悪い話ではない。 恐らくプログラミング・ファ
プログラミングファースト開発のアキレス腱 : 404 Blog Not Found
2008年07月21日15:00 カテゴリArt プログラミングファースト開発のアキレス腱 ktkt. プログラミングファースト開発の必要性 - ひがやすを blog これをふまえて考えたのが、以前提案したプログラミングファースト開発だ。 プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。 実は私自身、この言葉が生まれる前から実践してきたのだけど、一つけったいな問題点があるので、それを指摘しておく。 それが何かというと、 客がそれを安易だと勘違いして、安価だと思いやすい こと。 プログラミングファーストの場合、最早だと打ち合わせのその場で動くものを見せたりする場合がある。客が分かっている人だと、その事にボーナスを出
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
単なる「低コストの外注先」ではなくなりつつあるインドのIT産業