NEC、自社基幹システムを全面刷新 クラウド化
NECは3月2日、自社基幹システムの全面刷新に着手したと発表した。グループ全体に基幹システム機能を提供するクラウド指向のサービス基盤として構築、TCOと間接部門コストの2割以上の削減と、ノウハウを活用したクラウドサービスを展開していく。 NECグループの国内外の主要関係会社も含む、販売、経理、資材の基幹システムが対象。2010年4月に経理システム、11年4月に販売・購買システムのサービスインを予定している。 BPR（Business Process Re-engineering）により策定したグローバル対応の標準業務プロセスを実装し、業務効率化と国際会計基準への対応、内部統制の強化も図る。ビジネスプロセスモデリングにはARISを適用、SAP ERPを標準システムとして採用する。業務効率化により、12年度までに対象領域の間接部門費用を2割以上削減するとしている。 新システムは、グループ全体へ
株式会社マジカジャパンの羽生章洋が書いてるブログ:価値と価格と給料と - livedoor Blog（ブログ）
私たちは日常的に色々なものを買っています。当然何かを買うときには価格というものを検討材料の一つとして考えます。その価格が自分の求める価値と比較して妥当かどうかを考えているのです。 実は私は幼少期には結構気にしていました。ですがそれが購入の意思決定にどれほど影響を及ぼすかというと、全く皆無と言っても過言ではないと思われます。自分の懐具合と価格と欲しいという気持ちのバランスでのみ、購入するかどうかが決まります。 これは会社において何かを調達する場合でも同様です。例えばスタロジはコンピュータのソフトウェアを作っているのでパソコンを必要とする会社です。ではパソコンを購入するという場合に、何を検討材料とするか。資金繰りと製品価格と購入後の予測効果の兼ね合いです。 先日もデルのPCを1台購入したのですが、それは古いPCだとビルド作業（という工程があるのです）に30分程度かかってしまい現場がストレスを感
日本のIT業界はなぜ重層的な階層構造をとっているのか - Thoughts and Notes from CA
外資系のソフトウェア・ベンダーに転職して1年が経つ。転職するまで日本のIT業界の構造についてじっくり考えることなどあまりなかったのだが、今の会社で仕事をしていると否が応でも考えなければならなくなる。日本のIT業界はアメリカと構造が異なる点が色々あるが、その中でも重層的な下請・階層構造をとっている、ということは特徴として際立っている。本国が作成したパートナー契約を締結しようとか、本国で構築された社内システムをロールアウトしようとすると、大体重層的な下請・階層構造という問題が立ちはだかる。本国アメリカのパートナー契約はバラエティに欠き、多様なパートナーに対応できないし（例えば、システム・インテグレータに対する考慮が足りない）、社内システムも階層の深さへの思慮が足りなく、折角手にした情報を入力する受け皿もなかったりする。また、階層が深いためソフトウェア・ベンダーはお客様との距離が遠くなり、この距
システム内製化に走るユーザー企業とSaaSの親和性
ユーザー企業で再び情報システムの内製化に向けた取り組みが活発になっているという。実際にここ半年ほどでユーザー企業からそんな話をよく聞くようになった。ところで、その一方でSaaSやクラウド・コンピューティングの流れがある。まるで正反対の動きに見えるが、実は同一線上にある。刺激的、かつ表面的に言うと「SIerを外そう」ということだ。 内製化と言っても、いまさらスクラッチでシステムを組み上げる話ではない。日経コンピュータも特集したが、システム開発の外注化で失われた、業務要求の取りまとめ、要件定義、仕様の確定、プロジェクト管理など本来の情報システム部門の能力を取り戻そうという動きだ。もちろんパッケージ・ソフトの活用を前提に開発も行う。外部のITベンダーを使う場合でも、一括請負を止めて、準委任や派遣で手伝ってもらう。つまり、自己責任でシステムを作りましょうというわけだ。 本来なら、これはもう当たり前
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
レバレッジの効く仕事をする (arclamp.jp アークランプ)
エジケンのニッポンIT業界絶望論につられてみる。 さて、その前に「[みんなの回答]IT業界進化論： 絶望する前に”SIer 2.0”を目指せ」（cnet、いつの間にやらトラバがすごいしにくくなってる）。 クライアントとSIerは戦略的なパートナーシップを結ぶ段階にきています。 実際にそのようなアクションを起こしているSIerは、受託開発を切り口として、そこからクライアントの問題点を分析し、追加提案を行っており、時としてイノベーションを起こすこともあります。 SIerがクライアントにとって企業戦略を支えるITを提案できる戦略的パートナーとなるために必要な相手と既に関係を持っているのですから、SIerがコンサル会社に手を伸ばしているのもお分かりでしょう。 確かにそうですが、これはSIer1.0を突き詰めるだけ。コンサルを取り込む動きは受託開発をうまくやりたいから、ということです（コンサルがSI
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
SI業界もネット業界も世界に打って出られない理由 - 雑種路線でいこう
日本のSI業界を垣間みて絶望して逃げ出して、業界を外から捉え直して5年ちょっとになる。日本のソフトウェア産業とかSI業界が世界に出て行けない要因は気合いとか技術力ではなく産業構造や規制に起因していることが分かったし、日本でトップに立った会社が世界に出て成功するかというと難しいと感じている。梅田さんはネットならまだ勝負がついていないから頑張れるというが、僕はメタレベルの問題を考えるとネットも駄目だろうなと諦めつつある。 米国にはSI業界ってあまりなくてコンサルティングとかプロフェッショナル・サービスに分かれているのに対し、欧州では日本的なSIerが結構あって、富士通サービスなど日本勢も頑張っている。この違いはどの辺からきているかというと、結局のところ雇用流動性だ。米国では要らない社員をいつでも切れるから、プロジェクトの中核には技術を分かった人間をインハウスで採る。そういう連中を必要に応じて雇
崩壊した「人月からの脱却」
「人月計算をやめたいんだよね…，どうも納得がいかない」 2008年3月15日号の日経コンピュータで「ITコスト」を取り上げた特集を組んだ。企画の段階で，「○システムなら△円」といった指標が出せないものかと考えたのである。そうした指標があれば，ユーザーがベンダーと交渉したり，逆にベンダーがユーザーに提示する相場観の目安となる。想定したのが不動産情報だ。「新宿のビルで□坪なら×円」といった情報を提供したかった。 そこでユーザーのIT部門とベンダーの両方に取材したのだが，「相場は難しいんじゃない？システムは会社によって違うから」という反応がほとんど。それに続いて「それよりも…」という冒頭の言が出てくる。どうも完成品であるシステムの機能や価値ではなく，それを作るためのコストを問題視しているようだった。 長らく使われてきたこの人月単価や人月計算を，ユーザーとベンダーの両者が止めたいと思っている（注1
ITサービス会社を悩ます「お持ち帰り問題」、解決しないと地方がヤバイぞ
NTTデータが出向政策を見直すそうだ。地方子会社へ出向している従業員2000人強を対象に転籍を求めるとのことで、この原稿の執筆時（1月31日）が募集の締め切り。転籍者の給与水準は3割ほど下がり、9社ある地域子会社が“地場企業”としての競争力強化を図る・・・。この手の企てはITサービス業界でたまに聞くが、果たしてうまく行くのだろうか。 まあ、NTTデータの給与水準から見れば、3割下がっても地方のITサービス会社に比べればまだ高いぞ、なんて野暮なツッコミはよそう。問題は、地方で多くの技術者が活躍できるだけの仕事があるかである。地方による濃淡を無視してマクロ的に言えば、地方にはそこに住む技術者の能力分に見合う仕事はなく、“東京の仕事”に依存せざるを得ない。では、地方で“東京の仕事”をどこまでできるのか。 これは昔からある難問だ。いわゆる「お持ち帰り問題」である。例えば金融機関向けのシステム開発は
SaaSは大企業にこそ普及する
昨年末、このコラムで「SaaSは普及するに決まっている」と言った。今回は別の観点から、SaaS普及の現実味について書いてみる。別の観点とは「ユーザー企業における情報システム部門の弱体化」である。ある意味では当然の話なのだが、このことが要因となって、大手・中堅企業でSaaSが一気に普及する可能性がある。 よく、SaaSは中小企業でこそ普及するという議論がある。私は「そうかぁ？」と思っている。中小企業でIT化が進まないのは、ITを導入できないからではない。その必要がないからだ。だから、必要としない企業にITをSaaSで提供しようとしたとしても、ITの“活用”が進むとは思えない。 もちろん、ないわけではない。例えばBPO（ビジネス・プロセス・アウトソーシング）のような形では、大いにあり得るだろう。経営指導などの一環として中小企業の経営者に会計システムを使ってもらうといったイメージだ。 ただ、こう
まとめ：なぜ人月見積がダメか (ZEROBASE BLOG)
社団法人日本情報システム・ユーザー協会(JUAS)発行の『ソフトウェアメトリックス調査2007』を取り寄せて読んでみましたよ。SI関係の人は必読ですよね。私はいままで知らずに損していました。 そんなこともあり、年の瀬でもあり、今回の記事では表題の件「なぜ人月見積がダメか」について、現時点での総括をします。 人月見積方式の弊害に対する言論 「ユーザー企業は出席をとるな」，日本IBMの大歳社長が提言：ITpro (2001/08/31) 「日本の商慣習でぜひとも変えて欲しいのは，ユーザー企業が我々の技術者の出席をとることだ。出席をとられると我々は開発の生産性を挙げようとする努力をしなくなる。1000人でできる仕事を500人でやってのけると，売り上げが半分になってしまうからだ。技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」。日本IBMの大歳卓
「サービスにはサービス、モノ作りにはモノ作り」でSaaSを考える
SaaSが普及するかどうかという、くだらない議論する人がまだいる。そんなの普及するに決まっているじゃないの。そんなことを言うと、「では、どんな分野で？」と質問される。それも簡単。ものすごくアバウトに言えば「サービス業にはサービス（SaaS）、モノ作りにはモノ作り（ソフト開発）」である。 ここで言うサービス業は、小売なども含めた広い意味でのサービス業で、通信など装置産業は除いたぐらいの意味でとらえてほしい。さて、それを踏まえてサービス業を見渡すと、実はSaaSって既に随分普及しているんだよね。何かというと、既存のASPサービス。POSシステムなんかもASPの形態で提供するのが、既に当たり前になりつつある。 そう言えば、SaaSとASPとは何が違うのかという、これまたくだらない議論があったが、今はさすがにそんなことを言う人も少なくなった。SaaSとASPは機能上の差異ではなく、マーケティング上
どうせ理系出身者なんていらねえんだよ。
いまさら言ってもしょうがないだろうが、SIerに就職を希望したり内定した人たちに一言いっておきたい。 http://blog.miraclelinux.com/yume/2007/11/post_1ab2.html http://d.hatena.ne.jp/itoyosuke/20071101/1193932945 http://www.atmarkit.co.jp/news/200710/31/ipa.html 元の報道や参加者のブログエントリ見たりすると、ありがち過ぎて泣けるのだ。はっきりいうと、SIerの人事は情報工学科出身者は求めていない。それどころか理系出身者すら求めていない。 口先では求めているというよ。また、現場で最後に「技術的になんとかする」のは理系に期待されることが多いし、実際に期待通りに解決するのは大抵理系だ。しかし評価はされないし感謝もされないよ。とくに給料に反映す
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
雑種路線でいこう - どっこいSIerは簡単になくならない
SIerが変わらなきゃってことには同意。けど日本でSIerは当分なくならない。少なくとも解雇規制がなくならないとね。米国で何故ユーザー企業が専門家を雇えるかというと、要らなくなったらクビにできるからだ。例えば汎用機とCobolのシステムをLinuxとJavaに移行する場合は、汎用機オペレータとCobolプログラマを切って、LinuxオペレータｔJavaプログラマを雇い入れる。そういう世界だ。 日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。 今後はユーザー企業がどんどん内製で出来るようなシステム作りを支援する方向に向かわねばならな
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
大迫正治 REPEDANT BLOG > 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む : ITmedia オルタナティブ・ブログ
日本のソフトウェア産業は「製造業」よりも「サービス業」に分類される。なぜなら、革新的なプロダクトを研究開発し、一気呵成に市場に展開するよりも、顧客ニーズに沿ったオーダーメイドのシステムを逐次的に開発することが主流となっているからだ。 創業期は受託開発で糊口をしのぎ、徐々に自社製品の研究開発に資金を回して、いつかは自社ブランドで世界を席巻する、というストーリーは巷にあふれるが、これは結局のところローリスクでスタートしながらハイリターンを得ようとする野望であり、実現へのハードルは低くない。その理由は、中毒性のある受託開発と、ソフトウェア産業の悲惨この上ない「重層下請け構造」にある。 １．受託開発では「技術」が蓄積しない 住信インベストメントの辻俊彦氏はご自身のブログで次のように述べている。「クオリティの高い受託開発力は、オリジナリティ溢れる尖った自社開発力を生み出す素地になると思っている。投資
SIの稼働率 - essence-s
派遣ビジネスかSIかと考えてたら、派遣もやってるSIだったら、リソースが食われるのは当たり前だということだ。 SIに徹するにはやはり空きがでてしまうのを覚悟するべきなんだろうか。 OOスクエアインタビューより引用。 http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview37.html 私は、SIは宿命的に暇な時間が多いビジネスだと思っているんですよ。SIは可能な仕事量が頭数に限られますし、それぞれ案件も期間が違いますから、 売り物として難しいんですよね。やれなきゃ無理して案件取ったって仕方ありませんし、だからしゃかりきに営業もしない。1人が一ヶ月だけ手が空いているときに、都合よく 1人で一ヶ月の仕事っていうのはありませんから（笑）。派遣ビジネスだとそこで無理に切り売りされちゃうでしょうが、受託開発に徹するとそうはなりません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
