産業革命とクラウド
先日、知り合いから「10万年の世界経済史」（グレゴリー・クラーク著、久保恵美子訳）という書籍を薦められた。同書にある産業革命後の紡績工場に関する考察が、今のクラウドコンピューティングを巡る状況を彷彿とさせるのだという。その内容を少し紹介したい。 同じ機械を使っていても生産性に差 筆者はこれまでずっと、「ガンジー」の伝記などの影響もあり、産業革命以後の綿織物産業について、以下のように考えていた。機械化された英国の紡績工場が生み出す綿織物は圧倒的に安価だった。それが、手工業が中心だったインドの綿織物産業を壊滅に追い込んだ──と。 「10万年の世界経済史」によれば、歴史はそう単純では無かったのだという。実は19世紀後半には、インドの綿織物産業も機械化されていた。当時でも工業機械の輸出は今日のように行われていたそうだ。紡績機などはそう高価でもなかったため、綿織物生産の機械化は英国に限らず世界中で可
第2回 Androidをビルドする
では，Androidのソースをダウンロードし，ビルドしてみよう。Ubuntu上でAndroidのエミュレータを起動し，疑似体験できる。Ubuntu 8.10を用いて作業する。Ubuntu 8.04でも同様に可能なことを確認済みだ。ただし，Androidのオープンソース版では，先行してバイナリ提供されていたAndroid SDKと異なる点がいくつかある。最も違う点は，地図検索サービスの「Googleマップ」を利用するライブラリが含まれていないことだ。地図や「ストリートビュー」と連携するアプリケーションは，オープンソース版では動作しない。Android SDKのエミュレータを使う必要がある。 まず，次のツールを用意する。バージョン管理システムの「git 1.5.4」以上，開発環境の「Python 2.4」以上，Java開発環境の「JDK 5.0 update 12」以上，の3つだ。 Ubunt
第15回 リスクを取れば、コストは下がる
そもそもリスクとコストの関係とは？ リスクとは損害や危険な事象の可能性のことであるが、日常社会にも企業活動にも多くのリスクが存在する。天変地異もあれば、盗難や事故もある。病気や怪我をはじめ、保険や証券などの金融関連、環境関連など、あらゆる事象や活動にリスクが伴う。 むしろリスク・ゼロということのほうがあり得ないことであり、無闇（むやみ）に無謬（むびゅう＝誤りがないこと）性を追求するのではなく、リスクを実害のない程度に小さくして安全を確保することが重要だ。そのための管理手法としてリスク管理（あるいはリスク・マネジメント）の概念があり、予防的にあるいは事後的に低減したり回避したりして損失を極小化することが行われる。 情報システム関連でも、リスクという言葉がよく使われる。開発のリスク、運用のリスク、セキュリティーのリスクなどさまざまなリスクが語られ、テクノロジーと人とが絡む複雑で脆弱（ぜいじゃく
楽天、分散キー・バリュー型データストア「ROMA」のソースコードを公開
写真1●楽天テクノロジーカンファレンスでソースコード公開を発表するROMAの開発者 西澤無我氏（左）と、Rubyの開発者で楽天技術研究所フェローのまつもとゆきひろ氏（右） 楽天は2009年10月24日、同社が独自開発した分散キー・バリュー型データストア「ROMA」をオープンソース・ソフトウエアとして公開した。ROMAはスケールアウトが容易で、耐障害性の高いデータストア。「楽天市場」と「楽天トラベル」で、ユーザーによる閲覧履歴の保存にROMAを使用している。同日に開催した「楽天テクノロジーカンファレンス」に合わせて、「github」でソースコードを公開した。 ROMAは、楽天技術研究所フェローのまつもとゆきひろ氏（プログラミング言語「Ruby」の開発者）と協力して、2007年から開発してきた分散キー・バリュー型データストアである（写真1）。Rubyを使った大規模システムを実現するための分散処
オープンソース・ソフトでもうける方法
この不況下で順調に売り上げを伸ばしているITベンダーがある。Linuxディストリビューションのサポートをビジネスの主軸とする米Red Hatだ。 Red Hatの直近の業績発表によると，2010年度第2四半期（2009年6～8月）の営業利益は2754万2000ドル（1ドル100円換算で27億5420万円）で，前年四半期から29％増となった。年間でみても，2009年度（08年3月～09年2月）の営業利益は，8252万1000ドル（同82億5210万円）で，前年から17％増である。日本国内の売り上げは公表していないが「グローバルの業績に準じている」（レッドハット広報）とする。 調査会社の米IDCは2009年7月に，「オープンソースがもたらす収益は，2013年までに年平均22.4％の割合で成長する」という予想を発表した。不況によってコスト削減を図る企業が多いのが主な理由だ。 Red Hatしかも
DBの制約を回避する6つのテクニック
Google App EngineのDBサービスはジョインができないなどの制約があるので，パフォーマンスを高めるには工夫が必要だ。キーワードは「キャッシュ」「非正規化」「分散」「事前計算」など。そのほか，処理性能の予測やフレームワークの利用などに注意したい。 米Googleの「Google App Engine」（以下，GAE）は，Webアプリケーションの開発・実行環境を提供するサービスです。前回はGAEの概要編として，サービスの全体像や開発の流れ，データベース・サービスの概要などを説明しました。Java言語とPython言語で開発でき，各種ライブラリやアプリケーション・フレームワークがそろっている一方で，「データベースのジョインができない」といった制約があることを解説しました。 今回はGAEの設計編として，GAE上で動作するアプリケーションを設計する際のコツを，主にデータベース設計を中心
顧客の幸せを“倍速”で作る
「日本で一番、お客様を幸せにするシステムを作る会社」。 こんな経営ビジョンを掲げて、事業展開するシステム開発会社がある。社員数わずか約20人の倍速開発（東京都豊島区）だ。技術担当の吉沢和雄代表取締役と営業担当の牧貴子代表取締役は今のITサービス業界には、「『お客様が頼んで良かった』『当社は作って良かった』と両者が“幸せ”に思えるシステムを開発することが必要だ」と口をそろえる。 背景には「SEはユーザーに言われたことに責任を持って淡々とこなす。だが、他のSEが担当した部分には責任外と知らん顔。その結果、途中で仕様変更があれば、ユーザーとつまらないことで争いになる」（吉沢氏）ことがある。それを解消するため、他社の“倍”のスピードで開発することにした。残りの半分の時間で顧客のわがままを聞き、かゆいところに手が届くようなシステムに仕上げられるからだ。 牧氏は「お客様が『便利になった』『うれしかった
第7回 社内民主主義との戦い方（その3） 部門の人員を半分にすれば、適正人員数が分かる
部下をお持ちの管理職の皆様方は自部門の適正人員は何人だと認識しておられますか？ 多分、現状の人員数が適当か、あるいは若干少ないと認識されておられる管理職の方が多いのではないでしょうか？ しかし、それは大きな間違いです。 以前、私がBPR（ビジネス・プロセス・リエンジニアリング）を実施した際に、多くの管理者に対して「貴方の部門の人員数は過剰ですか？ 不足ですか？ それとも適正ですか？」と尋ねてみました。結果は予想通り「不足気味です」という回答が一番多かったのですが、私は質問の度に各管理者に対して「会社が2年連続赤字にもかかわらず、人員が不足しているという状況は、この会社の存続意義が無いということですよ」と正すと、全員が沈黙してしまったことを思い出します。 この管理者たちが「人員が不足気味だ」と認識する原因はどこにあるのでしょうか？ それは、彼らの部下たちが「忙しい」と言っていることが大きな原
マイクロソフト伝説の「闘うプログラマー」に関する3年前の誤報
筆者は3年前、ITproで「ついにWindows開発から離れた『闘うプログラマー』」というコラムを書きました。Windows NTのアーキテクトで、ドキュメンタリー「闘うプログラマー」の主人公であるデイビット・カトラー（David Cutler）氏が2006年7月をもって，Windows OSの開発部門を離れたという記事です。実はこれは誤報でした。今回はこのことをお詫びしたいと思います。 3年前のコラムでは、カトラー氏がWindows OSの開発部門からオンラインサービス「Windows Live」の開発部門に異動したことを指して「Windows OSの開発現場を離れた」と表現していました。当時の筆者にとってWindows OSとは、カトラー氏が設計したWindows NTの系譜を引き継ぐ「Windows Vista」と「Windows Server 2008」のことでした。Windows
第20回 「1人月150万円」が「年収1800万円」ではない理由
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回は、「偽装請負」を含むIT（情報技術）業界の多重取引構造について指摘しました。もう少し具体的に見てみましょう。 システム開発に関する契約は、ユーザー企業と元請け企業の間でも、元請け企業と下請け企業の間でも、請負契約であることがほとんどです。つまり委託と受託の関係です。作業範囲や成果物を明確にして、「その範囲をやってもらう」「○○を納品してもらう」といった主旨の契約です。 しかし見積書などをよく見てみると、「○○作業××人月分」といっ
「強く期待」して人を動かす
どんな仕事であれ，自分だけでは仕事が進まなかったり，効率が悪かったりすることが多い。そんなとき，部下や上司，同僚，他部門の担当者，他社の担当者，顧客といった「他の人」の力をいかに借りるかが大切になる。 そうした他の人に動いてもらうための方法はいろいろある。筆者が最近知ってなるほどと思ったのは，相手に「強く期待する」ことで人を動かすというものである。 人は期待されると力を発揮する ある人が他の人から何かを期待される。すると，その人は期待に応えようと力を発揮する。意識的にやっている場合もあれば，無意識に実践している場合もあるだろうが，多くの人が自分でだれかにこうしたことをしたりされたりした経験があるのではないだろうか。教育心理学では，これを「ピグマリオン効果」と呼ぶ。 名前の由来となったピグマリオン（ピュグマリオーン）は，ギリシャ神話に出てくる王様である。現実の女性に失望して自分の理想の女性を
VBAの行き詰まり
VBA（Visual Basic for Applications）はおそらく，マイクロソフトが想定していた以上に，広く使われてしまったのではないだろうか。そのためマイクロソフトは，VBAのベースであるVB（Visual Basic）をVB 6からVB .NETへと大幅バージョンアップをした際にも，“VBA .NET”とはできずに旧態依然の仕様のまま取り残す格好になってしまった。 VBAはマイクロソフトのオフィス・ソフトが備えているプログラミング言語である。1993年にExcelで初めて搭載された。オフィス・ソフトで手作業で行っていた作業を自動化したり，オフィス・ソフトをフロントエンドとするようなアプリケーションを開発したりカスタマイズしたりするのに使われている。 VBAはWordやPowerPointなどでも利用できるが，最も多く使われているのはExcelにおいてである。すべてのケースで
3年前に書いたリコー流の業務改善「TTY」のその後
私はおよそ3年前に、本欄（記者の眼）で「トヨタ流が『なぜなぜ5回』なら、リコー流は『TTY』」という記事を書いた。2006年3月22日のことだ。掲載から3年以上が経過した今もこの記事は読まれ続けている。日経情報ストラテジーはITpro内でCIO（最高情報責任者）やその予備軍の方々向けに情報サイト「CIO情報交差点」を運営しているが、この中のアクセスランキングにも時々顔を出している。 TTYとは、「whaT Then whY」を略し「『何が』の後に『なぜ』が来る」を意味する造語である。リコーで全社構造改革を担当する遠藤紘一取締役副社長執行役員CSO（最高戦略責任者）が作り出した。遠藤副社長は2006年に実施したインタビューで、TTYを浸透させようと図った理由をこう話していた。 「問題が誰の目にも明らかな状態なら、トヨタさんのように、なぜなぜ5回から始められるだろう。しかし、何が起きているのか
Part1 Google App Engineの基礎知識
「Google App Engine」は，米Googleが提供しているWebアプリケーション開発/実行環境です。2008年4月に先着1万人限定でプレビュー版を公開，同年5月末からは人数制限を撤廃して，無料のユーザー登録をすれば誰でも使えるようになりました。ここでは，2008年末時点のGoogle App Engineの使い方を紹介します。 ※ 記事は執筆時の情報に基づいており，現在では異なる場合があります。 最初に「Google App Engine」を簡単に説明しましょう。Google App Engineを一言でまとめると，「面倒な準備をせずに無料で使えるWebアプリケーション開発/実行環境」となります。 タダでGoogleのリソースを活用できる このGoogle App Engineを利用すれば，米Googleが運用している膨大なサーバー群はもとより，Googleのサービス基盤となっ
システムの出来が見違える
手戻りを招く「仕様の認識のズレ」や「仕様の抜け」。これらは質問のコツをつかんでいれば回避できる。システムの出来も見違えるはずだ。 業務部門にいるユーザーにちゃんとヒアリングをしてシステム開発に着手した。それなのに開発が大詰めを迎えたとき「欲しかったのはそういう機能ではない」「このケースの処理がシステムに組み込まれていない」といった不満がユーザーから出てきた──。 仕様の詰めが甘かったために，開発作業の手戻りを余儀なくされることは少なくない。ユーザーが仕様をITエンジニアに伝え忘れていたことで仕様の詰めが甘くなったとしても，「あらかじめユーザーと約束した日までにシステムを稼働できなければ，ITエンジニアの責任になってしまう」と，NTTドコモ 情報システム部の坂本守さん（基盤システム担当部長）は指摘する。 仕様の詰めが甘くなるのは，ITエンジニアとユーザーとの間の「認識のズレ」と，盛り込むべき
第5回 何にでも使えるトヨタの思想
トヨタ自動車の渡辺捷昭社長の講演で、実にトヨタらしい発言をうかがった。「世の中には無駄な仕事というものは無いのです」。こう言われて、どんな仕事にもどこかに価値があるものだと甘い考えを持ったらいけない。その後に続く言葉は、「仕事か無駄かのどちらかしかないのです」 これが一貫しているトヨタの経営思想だ。 「かんばん」や「アンドン」に象徴されるJIT（ジャスト・イン・タイム）のトヨタ生産方式や現地現物の考え方、カイゼン、ムダ取り、どれをとってもどの企業のどのフェーズでも適用することができる。経営とIT（情報技術）にかかわる前向きで楽しいコスト削減のススメも、トヨタ思想のムダ取りを実践しているのと本質的に変わりはない。 システムの再構築プロジェクトに並行して、業務プロセス改善プロジェクトを行う際に、システム科学が提唱するHITシステムを採用した。この手法は社長である石橋博史氏が長年かけて蓄積したモ
［七つの行動パターン］プロとプロでない人のわずかな差
プロのチームは，特別なスキルを持つ限られたメンバーの集団ではない。彼らは誰にでもできる行動パターンを習慣的に実行しているだけである。多くのITエンジニアを育ててきた池田氏に解説してもらう。 池田 輝久 エンパワー・ネットワーク プリンシパル 今，米国のIT企業で注目されるキーワードに「Trusted Advisor」という言葉がある。プログラマ，SE，CE，プロジェクト・マネージャ，ITアーキテクトといった職種にかかわらず，すべてのITエンジニアが目指すべき“プロとしてのあり方”を示したものだ。 直訳すれば「信頼される助言者」ということになるが，この言葉にはエンジニアに対する二つの問いかけが含まれている。 一つは，Advisorという言葉に含まれる「あなたはユーザーに尽くしているか」という問いかけ。自分がAdvisorであるということは，主役はあくまでもユーザーである。自分が成果を上げるこ
ルートキット「StealthMBR」の進化
McAfee Avert Labs Blog 「StealthMBR gets a makeover」より April 19，2009 Posted by Rachit Mathur 最近，トロイの木馬型ルートキット「StealthMBR」（別名「Mebroot」）に新たな亜種が複数登場し，実際に出回っていることが確認された。これらの亜種はこれまでのStealthMBRから大きく変化している（関連記事：StealthMBRの持つ防衛策を見極める/マスター・ブート・レコード（MBR）を狙うルートキットが再び活発に）。 StealthMBRは，これまでに現れたルートキットの中で最もステルス性が高く検出しにくいと言われているはずだ。新しい亜種は，「より深く侵入する」手口を使って検出から逃れようとしている。簡単に説明すると，カーネル・オブジェクト（デバイス・オブジェクト）を乗っ取ってマスター・ブー
［データベース設計編］参照整合性制約機能を多用してはいけない
参照整合性（Referential Integrity）とは，テーブル間のデータの整合性を保つための仕組みである。例えば，「受注テーブルの商品番号カラムには，商品テーブルの商品番号カラムに同じ値がなければならない」といった制約を維持するための仕組みである（図1）。RDBMSはこの整合性を維持するための機能として，「参照整合性制約」といった機能を持つことが多い。これは，定義された参照整合性をチェックし，整合性を逸脱するような値がテーブル内に存在しないようにする機能である。この機能を使用する場合は，テーブル定義の際に「Constraint句」を用いることが多い。 参照整合性制約機能は，誤ったデータがテーブルに含まれないようにするには効果的な機能である。だが，むやみに使うと問題を引き起こすことがあるので，注意が必要だ。 データ移行時にエラー 最も問題が起こりやすいのは，データを移行する際だ。先の
「技」と「心」で会議に臨め
「発言が出ないので、『発言しろ』と上司が促すと、上司の満足を得るためだけに、意味のない発言をする人がいる」──。 本誌は2008年6月末から約1カ月間、「日経ビジネス オンライン」で、会議についての困りごとや悩みを聞くアンケートを実施した。1273人の回答者の半数近くが挙げた悩みは「発言が出ない」こと。自由意見欄ではその実情が切々と語られた。 意見が出たら出たで、「自分の意見を強硬に主張し、人の話を聞かない人がメンバーにいる場合、その人に全体が引きずられてしまう」「全体方針を決定する会議でプロセスの詳細内容に話が及び、憶測でああでもない、こうでもないと出席者全員で堂々巡り」といった具合に進行が迷走する悩みも。その結果、「原案を改善する建設的な意見や代替案が出ず、その場で結論を出せずに持ち帰りとなる」など、せっかく時間を割いても結論が出ずに意思決定が遅れ、参加者のモチベーションも下がるといっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
