人口13億人という巨大市場で成長し続ける中国企業。顧客数が億単位におよぶなど、大手企業のスケールは世界でもトップクラスだ。そうした巨大企業のシステムは、どんなものなのか。大手3社の知られざるIT活用の実態に迫る。 中国移動---囲い込みをとことん嫌う 2010年7月、中国・上海のIT業界関係者に「富士通ショック」が走った。中国移動通信集団（中国移動＝チャイナモバイル）が、富士通に同社製サーバーなど500台超を一括発注したとの情報が伝わったからだ。中国移動は、NTTドコモの10倍に当たる5億5000万件超の契約を抱える、世界最大級の携帯電話会社である。 中国移動が購入を決めたのは、富士通製UNIXサーバー「SPARC Enterprise」とストレージ「ETE-RNUS」だ。発注総額は40億円を超え、富士通の中国における獲得案件としては過去最大である。 中国移動は、課金処理などを担う基幹シス

奈良県を地盤とする南都銀行で2010年10月29日、残高証明書の発行手数料を二重に引き落とす事態が発生した。原因は、システム担当者がテストデータを削除し忘れるという“うっかりミス”にあった。被害件数は約7000件に達した。 二重引き落としは、あらかじめ決めた日に預金口座の残高がいくらあるかを証明する「継続残高証明書」の発行手数料で発生した。南都銀行は2010年10月29日未明に、2010年4～9月に継続残高証明書を発行した顧客の預金口座から発行手数料を一括して引き落とすバッチ処理を予定していた。万全を期すため同行は2010年10月初旬、事前に口座振替のテストデータを作成し、テスト処理を実行していた。 ここで、同行のシステム担当者がテストデータを削除し忘れた。このため、2010年10月29日未明の時点で、システム内にテストデータと本番データの二つが存在していた。そのままバッチ処理を実行したた

以前に、続：SIerについて。そして「なぜ日本のソフトウェアが世界で通用しないのか」という記事を書きました。そこで中島聡さんの記事に触れました。今日、ふと気になってまたその記事を見返してみました。その記事というか、700以上もブックマークされている、はてなブックマークのコメントを読んでみました。 記事の内容に同感というコメントが概ねなのですが、中には批判的なコメントもそれなりにあります。いろんな考えの人たちがいるんだなと思いました。 ベイエリアのソフトウェア企業って良いよ 私はソフトウェア技術者ではないし、米国企業で働いた経験もまだ1年半ぐらいで、1社だけです。だけど、これはかなりの確信をもっていえます。米国ベイエリアのソフトウェア技術者たちの方が、東京で働くソフトウェア技術者よりも絶対に楽しそうに生きている！これは仕事だけではなくてオフの時間も含めて。（もちろん東京でも楽しく生きている技

問題集みてたらこんな項目があった。 ある開発プロジェクトの見積もり工数は88人月である。 作業を開始した1月〜5月までは各月に10名を投入したが、 5月末時点で40人月分の作業しか完了していない。 8月末までにこのプロジェクトを完了するためには、 6月以降は最低何名の要員を追加する必要があるか。 6月以降の全ての要員の作業効率は、5月までの要員と同じであるものとする 答えは10人なのだが、とっても納得いたしかねる。 ・計算上はそうなることは受け入れられる ・現実は全ての要員の作業効率が同じなんてことはありえない ・追加要員が即時戦力化されることもない ・初期メンバーの作業効率が、1ヶ月目と5ヶ月目で同じなわけがない ・例えば以下のような成長を遂げていても平均作業効率は0.8となる → 1ヶ月目：0.1、2ヶ月目：0.6、3ヶ月目：0.8、4ヶ月目：1.0、5ヶ月目：1.5 試験問題とわりき

NTTデータが、オープンソースの分散バッチ処理ソフト「Hadoop」を使ったシステム構築事業で、2012年度に100億円を売り上げる目標であることが明らかになった。2010年10月12日（米国時間）に米国ニューヨークで開催された「Hadoop World 2010」で、NTTデータの山田伸一常務が発表した。2012年度までに30件のシステム構築、100件のサポート契約を目指す。 Hadoopは分散処理システムを構築するためのミドルウエア。一般的なPCサーバー100台で、およそ200Tバイトのデータを解析できる大型データ分析システムを構築できる。NTTデータは2010年7月に、Hadoopを使ったシステム構築・運用支援サービス「BizXaaSクラウド構築サービス Hadoop構築・運用ソリューション」を開始。10月にはHadoop専業ベンチャーの米クラウデラと提携し、クラウデラ製のHadoo

受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。

前回、「SEは評論家的姿勢を改めて討って出て、SEが抱えているSEのモノ扱い、人月扱いや技術偏重、受身姿勢などSEの問題はSEで解決せよ」と読者のSEの方々へ訴えた。筆者の意見に賛同される方、異論のある方などいろんな方がおられると思う。筆者は長年の経験で本当にそう考えている。 今回は賛同される方や「話は分かるが…」と悩んだり迷ったりしている方々に向けて「では、そのためにSEは何をどう考えて何をやればよいか」について筆者の考えを述べたい。この問題はIT業界で長年続いている非常に難しい問題であるがSEの方々の参考になれば幸いである。 30～40年前の話だが、筆者が現役のSEだった時代はメインフレームの全盛期だった。当時も今と同様、SEがいなければシステムの導入や開発はできなかった。IT企業はもちろん、ユーザー企業もそのことは百も承知だった。だが、メーカー同士の競合が激しかったせいか、システムの

「プログラマはもう要らない」。大手物流会社のシステム子会社で新技術の社内展開を進めるマネージャーはこう言い切る。ここでいうプログラマとは、企業情報システムの開発プロジェクトでプログラムを作成する担当者を指す。ある開発ツールを検証したところ、こうした役割の要員は不要との結論に至ったというのだ。 このマネージャーは記者に対して、ツールを導入した場合の効果をこう語る。「様々な開発言語を知っていて、バグのないソースコードを24時間、延々と高速で書き続ける。そんなスーパープログラマを雇ったのと同じ効果が得られる」。 同社が検証したのは「GeneXus（ジェネクサス）」という開発ツールである。ご存知の方はまだ多くないかもしれない。一口に言えば、アプリケーションの自動生成ツールである。データ項目や画面、業務ルールといった設計情報をGeneXusの表記法で入力すると、ソースコードとテーブル定義情報を自動生

オフショアと日本のシステム開発企業の生産性について。 価格勝負してもオフショアに勝てる訳もなく（その考えがそもそも違うのですが）、生活コストの高い国では生産性で勝負すべきではないかというお話。

自分のブログに書こうとも思ったのですが、会社が特定されてしまいそうなのでここに書きます。どこかに書かなければならないと思ったのは、この事実を誰かに伝えなければならないと思ったからです。 私が勤めていた会社はシステム屋さんです。2タイプの職場があって、一つはお客に注文を受けてシステムを開発してリリースして終了。もう一つはお客の会社に居候させてもらってシステムの維持管理をするというものです。私は後者のほうです。 お客は工場も複数構える結構大きな企業で、様々なプラスチック製品やコンピューター部品を作るところであります。日本だけじゃなくて海外とも取引があったと思います。 1. コンピュターシステムの入れ替えを要求されるこの不況のなか、様々な設備投資の資金を抑える事を進めていた中で、システムについても、もっとコストの安いものをと以前より私の会社の上役達と試行錯誤を繰り返してきたのですが、そもそものお

私は1年以上、エンタープライズの世界(企業向けSIとか)から離れ、ずっとGoogle App Engineをやっています。今は、Google App Engine + Webkitベースのブラウザで動くHTML5を使ったグローバルな新サービスを提供しようとしていて、新規事業立ち上げのために日々奮闘しているので、エンタープライズな世界に戻ってくることは、基本無いでしょう。 私は、受託開発に未来はないと思っているので、自分でサービスを提供する側に回ろうとしているわけです。受託開発に未来はないといっても、文字通り未来はないという意味で、すぐになくなるわけではないし、生きてくために必要な部分も多々あると思います(うちの会社もSIerだし)が、今後は撤退すべきだろうという判断です。 受託開発になぜ未来がないかというと、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものが生き

３００人のスパルタがプログラマの職業を紹介するそうです システムエンジニアにも当てはまるかも・・？

3，4年前にSI業界を去り、そっから自社開発等を転々とし、最近たまたまSI業界の現場に戻ってきた。 なんていうか、なんにも変わってない気がした。 相も変わらずの人月開発。 デスマにおちいり、とにかく人増やし。 テスターだけは増えたけど、回す人がいないため、空き稼働が多発。意味なし。 申請書類だけは山のよう。 だれが何やってるかわからず。 管理G、管理チーム、管理者、多々いるにもかかわらず、 なんかの会議で状況を誰も把握できずに、担当者を直呼び出し。 テストは当然手動確認。 前後のインタフェースが当然バグだらけ。 単体レベルのバグが総合で頻発し、全然試験進まず。 管理者はEXCELの表に値を埋めることしか頭になく。 終電、徹夜、始発帰り、ホテル住まい、タクシー帰り当たり前。 世の中探せば、ましな職場はいくらでもあるのに、 なんでこんな現場に留まってるのか理解に苦しむ。 また何年か後に顔出して

印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 帝国データバンクは8月9日、2001年から2010年7月までのシステム・ソフトウェア開発業者の倒産件数や負債額などをまとめた。それによると、2010年は7月までの倒産件数が107件で、過去最悪となった2009年に迫る勢いで推移しており、8月以降の動向が注目されるとしている。 2001年以降の倒産は累計で1113件となっており、特に2008年以降に急増する動きを見せているという。1113件の内訳は、業歴別では10年未満の倒産が47.7％、負債規模別では5億円未満が92.7％、態様別では破産が91.6％を占めているとしている。

20年以上にわたりシステム構築の現場で仕事をしてきた筆者の経験では、プロジェクトの失敗を探ると要件定義までの上流工程の問題に行き着くことが多い。定義した要求に過不足がある、要求の内容が誤解を生む表現になっている、整理が不十分なまま要求が個条書きされており整合が取れていない──。こうした事態が、みなさんの現場でも起こっていないだろうか。 利用部門などから要求を引き出して分析し、それを基にソリューションを立案してその妥当性を検証する。さらに、要求の変更を管理していく。ソリューション企画から要件定義までの上流工程を中心に、こうした要求にかかわる一連の作業をいかに行うかが、プロジェクト成功の大きなカギを握る。 しかし多くの現場には、要件定義までの上流工程について標準的な方法が存在せず、ITエンジニアの属人的スキルに頼っているのが実情だろう。スキルの高いITエンジニアが要件定義までの工程を担当するか

上流で品質を作り込むことを狙い，設計レビューを強化する現場が増えている。しかし，長時間に及ぶレビューは現場の負荷を高め，メンバーを疲弊させる。それだけの労力を投じても，重大な設計ミスが必ずしも減らないのが現実だ。3人のITエンジニアが座談会でその実態を語った。（聞き手は中山 秀夫＝日経SYSTEMS） 情報システムの信頼性に対する要求が厳しくなるなか，品質管理を強化し「設計ミス」をなくそうとする動きがあるようです。みなさんの現場では，いかがでしょうか？ Aさん：私は製造業のシステム部門に勤めています。設計の品質向上は，大きな課題になっていますね。テストでバグをつぶすのではなくて，もっと上流できっちり品質を作り込んでいこうという方針です。最近はレビューの強化に取り組んでいます。レビューの回数を増やしたのに加えて，設計レビューで有識者を必ず入れるルールになりました。 有識者は具体的にはどんな人