「経営戦略としてのSOAとは何なのか？」──この連載「成功するSOA、失敗するSOA」では、SOAでビジネスを変革するヒントを紹介していきます（日本BEAシステムズ著「ビジネスはSOAで変革する」からの抜粋です）。 エンジニアは総じて頑固です。特に、一度成功を体験したエンジニアは、輪をかけて頑固です。 エンジニアと話していると「SOAでやろうとしていることはEAIと同じである」とか「Webサービスは成熟していないからSOAは無理だ」といい切り、断固としてその説を曲げないという場面に遭遇することがあります。この頑固さが招く誤解が「SOA不要論」となり、SOA推進派に対する抵抗勢力になることがあります。 一般に抵抗勢力とは、技術者にかぎらず、かつて「成功した人間」がなるものです。また老人は頑固であるといわれますが、老人が頑固なのではなく、「成功した老人」が頑固なのです。某政党など、その典型例で

かつて純然たるビジネス向けデスクトップ機能だった「Trusted Platform Modules」（TPM）が急速に広まる兆しを見せている――向こう2～3年の間にコンシューマーPC、サーバ、そしておそらく携帯電話にも普及する見込みだ。 このチップは、ハードウェア内にパスワードまたは暗号鍵を格納する小さな“金庫”として機能し、PCをハッキングされにくくする。1999年にIBMから初めて提供されて以来、ビジネス指向のデスクトップとノートPC上で利用可能になっている。 その後幾つかの進展があり、現在TPMは普及に向けた適切な環境を整えつつあるとみられている。 状況が好転した要素としては、モジュールコストの低下と優れたソフトウェア開発の促進を助けたオープンTPM仕様の策定、MicrosoftがWindows Vistaのセキュリティ機能としてTPMモジュールの採用を決定したこと、企業ユーザーやコ

一国の富、企業の売り上げ、不良品の発生などにおいて分配・分布・発生原因を考えたとき、その大勢は少数の要因によって決定されるという経験則のこと。 イタリアの経済学者・社会学者、ヴィルフレド・パレート（Vilfredo Federico Damaso Pareto）が、欧州各国や米国の統計データに基づいて統計的に所得配分の研究を行い、1896年にローザンヌ大学の論文集に成果を発表した。ここで彼は、経済・社会体制が異なる国々でも、また異なる時期においても、所得金額xとx以上の所得のある人の数Rxの間に「Rx=Ax-α」という定式が成り立つと指摘した。Aは正の常数、αがパレート係数（値が小さいほど富の配分が不平等であることを示す）である。 この研究において当該国のパレート定数は、それぞれほぼ1.5で一定であった。このことからパレートは、社会全体の所得の多くは一部の高額所得者が占めているが、それは国

新しい商品やサービス、技術や知識、ライフスタイルなどが登場したとき、早い段階でそれを購入・採用・受容する人々（層）のこと。 米国の社会学者エベレット・M・ロジャーズ（Everett M. Rogers）が最初に使った言葉で、その著書『Diffusion of Innovations』（初版は1962年）で知られるようになった。ロジャーズは、イノベーション（まだ普及していない新しいモノやコト）がどのように社会や組織に伝播・普及するのかの実証的研究を行い、採用時期によって採用者を5つのカテゴリに分類した。その2番目がアーリーアダプターである。 ロジャーズの普及モデルにおいて、最も重要だとされるのがアーリーアダプターである。 革新性という点ではイノベーターが一番高いが、極めて少数であるうえに価値観や感性が社会の平均から離れすぎており、全体に対する影響力はあまり大きくない。それに対してアーリーアダ

ソフトウェアメトリクスとは ソフトウェアメトリクス（品質測定：メトリクス）とは、ソフトウェア開発をさまざまな視点から定量的に評価したものです。普段実際の開発現場では触れられることの少ないキーワードですが、本記事では「ソフトウェアの品質向上」という視点からソフトウェアメトリクスに焦点を当て、開発現場へのメトリクスの導入方法やその効果について解説していきます。 ソフトウェアにとっての品質 エンジニアなら誰もが、良いソフトウェアを作りたい、という思いを持っていると思います。ところが現実には、理想的なソフトウェアを作成するための十分な時間も潤沢な予算もなかなかないのが現状だと思います。それは、ソフトウェアの良しあし、すなわち品質ということについて、顧客と開発会社双方に十分な認識がないからです。このような“慣習”がソフトウェアの開発業界において「作りっ放しで終わり」という悲しい風潮をまかり通らせる背

第7回目はWebページ上の検索する箇所と、Webページの更新日付に関する検索の秘訣です。（特集：顧客満足度ナンバーワンSEの条件） 調べたい箇所を指定する Webページはどのような構成になっているでしょうか。いろいろな分け方があるかと思いますが、Googleでは、タイトル、本文、URL、アンカーテキスト、と分類した上で、それぞれの部分を指定して検索することができます。 「intitle:」コマンド Webページのタイトルに限定して検索します。タイトルとはtitleタグで囲まれた範囲で、ブラウザのウィンドウ最上部に表示される文字列です。 「allintitle:」コマンド 指定されたすべてのキーワードがタイトルに含まれるページを検索します。 「inurl:」コマンド WebページのURL文字列に限定して検索します。 「allinurl:」コマンド 指定されたすべてのキーワードがURL文字列に

ハイ・パフォーマーの“知”は、移転・共有できるか？：有能プロジェクトマネージャ育成術（1）（1/3 ページ） 世の中に多くの失敗・赤字プロジェクトが存在する一方、どんな難解なプロジェクトでも成功裏に終えるプロジェクトマネージャ（PM）がいる。こうした知恵や能力を移転・共有することはできないのだろうか？ 普遍的課題としての「有能者不足」 ITコンサルタントとして仕事柄、多くのIT関係者とさまざまな課題についてディスカッションをしてきたが、最も共通で、最も普遍的なものの1つが人材育成問題であり、その結果としての有能者不足の問題だ。有能者不足の悩みの事例をいくつか次に挙げる。 ■事例1 ユーザー企業A社では、情報システム部門の企画マン不足を嘆いていた。多角的な事業で構成されるこの企業は、各カンパニーにIT機能を置かず、コーポレートにその機能を少数精鋭の形で集中配置している。各カンパニーからあがっ

第1回　ITILはITサービスの救世主か？：運用管理のベストプラクティス集「ITIL」とは何か？（1/3 ページ） 「ITIL」という言葉が知られるようになった。システムの運用管理を見直すには格好のフレームワークといえる。ITILの内容を見ていく前に、まずはITILの持つ意義を知っておく必要がある。 ITILは本来のIT取得の意味を開かせる！ ITIL（Information Technology Infrastructure Library）の言葉が知られるようになってちょうど2年ほどになる。ITILを検索エンジンのGoogleで検索すると、2002年では50件程度の情報しかなかったが、2005年現在では9万5000件とうなぎ昇りにその情報は増えた。 簡単にITILを説明すると、現在世界でもっとも多くの行政・企業などで活用されているITサービスを行うためのベストプラクティス集といえる（構

IPAのITスキル標準センターが、2006年3月に公表が予定されているITスキル標準（ITSS）ver．2での改訂内容を報告した。 情報処理推進機構（IPA）ITスキル標準センターは7月4日、2006年3月に公表が決まっているITスキル標準（ITSS）ver．2のポイントと、改訂作業に大きな役割を果たすプロフェッショナルコミュニティの活動について報告した。 プロフェッショナルコミュニティは、ITSSで定めるITアーキテクトやプロジェクトマネジメントなどの6職種について、ITSSレベル5以上のハイレベルな人材が自立したプロフェッショナルとして活動する際の業種横断的な母体として設置されている。 IPA プロフェッショナルコミュニティ代表 鈴木俊男氏によると、プロフェッショナルコミュニティの活動は大きく3つ。ハイレベル・プロフェッショナルの現場の体験に基づいた知識をフィードバックしてITSSの充

ソフトウェア開発チームを構成するメンバーは大きく2つの種類に分かれます。開発者とリーダーです。開発者にさまざまなスキルが必要なように、リーダーにもさまざまなスキルが必要です。多様なスキルの中で最も習得が難しいとされているのは、開発者と違う視点を持つことです。もし、（教科書どおりにやっているはずなのに）いまあなたがリーダーとしていま一つだと感じているのであれば、開発メンバーから、リーダーへの視点の切り替えが上手に行われていない可能性があります。 この連載を通じて私がお手伝いしたいのは、視点の切り替えです。切り替えというよりは、「もう1つの視点を持つ」といった方が適切かもしれません。メンバーとして、開発者としてプロジェクトチームに貢献してきたあなたが、リーダーとしてチームに貢献するために追加すべき視点を持つにはどうすればよいか？ 次の3つの切り口で説明していきたいと思います。 3つの切り口：「

デスマーチを止める進ちょく管理の現実解:GanttProjectの導入で進ちょくをコントロールする：明日からできるプロジェクト管理（1）（1/4 ページ） 開発プロジェクトは、何もしなければどんどん混乱していく。計画は破綻し、成果物は四散し、開発要員の心理はズタズタになる。混乱を収拾するのは容易ではない。開発プロジェクトの立ち上げ段階から秩序を導入し、整理整頓されたその状況をカットオーバーまで維持すること。もちろん、それは口でいうほど簡単なことではないのだが、まったく無理なことでもない。本連載では、プロジェクトに秩序をもたらすさまざまな手法を、開発プロジェクトの段階を追って解説していく。そして、手法の説明だけではなく、具体的なツールを使って「どうすれば効率的な管理が可能なのか」という現実的な提案も行うつもりである。ここで使用するツールはすべてオープンソースのプロダクトである。効果的な方法を

この短期連載は、社内のソフトウェア開発プロセスの標準化に日夜取り組んでいるあなたにぜひとも知っていただきたいことをお伝えしていきます。理由は、それ（ソフトウェア開発プロセスの標準化）がうまくいっているという話を、少なくとも私はほとんど聞いたことがないからです。 標準化の目的 そもそもなぜ、開発プロセスの標準化に取り組むのでしょうか。ソフトウェア開発組織の使命は、顧客のビジネスの成功に対する貢献であると、わたしは考えています。そして、日々その貢献度を上げていかなければ競争を生き残れないと感じています。事実、多くの開発組織では、表現に違いはあるものの、同様の内容を自らの使命として掲げています。そして、貢献度を上げるための手段として、自身の開発力を高めていこうとしているのです。 開発力を高めるための手段としては、 特定の分野に特化する 開発期間の短縮 開発コストの削減 品質の向上 といったことが