ホーム | お問い合わせ Worldwide | Local Sites 
2008.10.13

  ソリューション | プロダクト | サービス | カンパニー | ニュース | カスタマー サポート | パートナー | 全てのオフィス  


ソリューション

ITマネジメント


製品開発/研究開発


公共投資


施設管理/施設保全管理


導入事例

ニールセンメディアリサーチ社におけるソフトウェア開発プロセス導入事例

ソフトウェア開発見積もり精度の向上を目指す



導入背景


 ニールセンメディアリサーチセンターには22,000件の家庭から毎分1,000万件以上 のTV視聴率データが伝送される。IT部門はそれらの膨大なデータを収集・解析し、 彼らの顧客 - 多くはTVステーション、広告主、ケーブルネットワーク等 - に対して 解析した視聴率データを提供するためのソフトウェアや、視聴率を記録するハードウェアへ の組み込みソフトウェアプログラムの開発、保守を行っている。
 現在年間に開発するプログラムはおよそ600本。500名のプログラマが開発を担当している。

導入前の課題


 ニールセンメディアリサーチ社は1996年当時、300名のプログラマで 年間100本のソフトウェアを開発していた。プロジェクトマネージャに よってタスクレベルまでのWBSを作成し、さらにそこにコード行数や 要員のスキルレベルを加味した、一般的な手法でソフトウェア開発計画を立案していた。
 しかし実際には、大半のプロジェクトで完了までの工期は、平均して見積もり時の 1.6倍を要してしまっていた。多くのプロジェクトのスケジュールは慢性的に遅れ、 プロジェクトマネージャや開発者のモチベーションは下がり、さらには顧客からの質問や要求 - 例えば「ソフトウェアのリリースがいつであるか」、「コストはどのくらいであるか」 - に対して信頼ある回答をすることができなくなってしまった。
 この状況を打開すべく同社のCIOであるKim Ross氏の決断により ソフトウェア開発プロセス改善の取り組みが始まった。

実施内容


 1996年秋、ニールセン社はアルテミスのKnowledgePLANを導入してソフトウェア開発 プロセスの分析を開始し、まず過去数年間に実施した複数のプロジェクトの実績データ での検証によるプロトタイプを実施した。
 ニールセンにとってのメリットは、KnowledgePLANが ファンクションポイント(以下FP)法 によってカウントされた数値をプロジェクトのサイズを決めるインプットとしている点にあった。 FPとは、ソフトウェアの持つ機能の数をもとに、そのソフトウェアの規模を測定する手法で、 FPの算出にあたってはソフトウェア内でどのような処理が行われているかを抽出し、 入出力など機能ごとに分類、それぞれを「ファンクション」(機能)と定義するものである。
 FPではファンクションごとにレコードの種類の数やデータ項目数などからファンクションの 「複雑さ」を定義し、個別のファンクションの評価値を算出する。評価値のアプリケーション 全体での合計が「未調整ファンクションポイント」で、さらにソフトウェアの影響度を掛け 合わせて「調整済みファンクションポイント」を算出する。  FP法の導入により、これまではコード行数でしか図ることのできなかったソフトウェアの 規模を以前より客観的・定量的に算出することができるようになった。
 また、KnowledgePLANにはFPによる開発規模のインプットだけでなく、 100以上もの属性の設問に対し入力する必要がある。それらは [開発するソフトウェアは 新規開発か機能拡張か?]や[プラットフォームは何か?]や[使用サイトは単一か複数か?]、 [要員の言語やプロジェクトに対する習熟度は?]、[プロジェクトの管理および技術面での 結束力] 等々、開発するソフトウェアの特性、属性からヒューマンファクタまでの 広範囲な内容に及ぶ設問である。ニールセンはこれに着目した。
 KnowledgePLANを使用してプロジェクトを業界標準データと比較し、 自社の属性を洗い出したことで、彼らは様々な事実を発見した。見積もり時のタスクは、 多くの場合とても楽観的な、時として「希望的観測」で立てられた工数であったこと。 開発フェーズではプログラマの数を増やしたからといって必ずしも生産性があがるわけ ではないこと。見積もり時にリスクはまったくといってよいほど考慮されていなかったこと …その結果として現実と乖離した見積もりとなっていたことを発見した。
 多くのプロジェクトマネージャはこの「原因と結果」に大変驚き、ソフトウェア開発プロセス、 特にソフトウェア見積もり手法の変革に同意した。こうしてニールセンは KnowledgePLANの有効性を見出し、KnowledgePLANをソフトウェア開発プロジェクトの 計画立案、プロジェクトのトラッキングマネジメントのツールとして使用することにした。
 KnowledgePLANを実プロジェクトに適用させるにあたっては、プロセスクオリティ向上の ための組織「プロセスクオリティ コントロールチーム」を結成した。 プロセスクオリティ コントロールチームではFPの資格保持者であるクオリティマネージャ がプロジェクトマネージャと共にプロジェクトのスコープ、サイズ、リソースのサイズを 開発プロジェクト毎に定義した。
 またプロセスクオリティ コンロトールチームはプロジェクトマネージャへソフトウェア 見積もり手法についてのトレーングを実施、開発者にはチームワークや品質向上を 謳ったロゴの入ったポロシャツを提供したり、優秀なプロジェクトには社内表彰をしたり するなど、開発者・社内の意識改革を行う啓蒙活動も同時に行った。
 クオリティマネージャは、プロジェクト実施中はプロジェクトに関する様々な情報を収集、 収集した自社データと業界標準データとでwhat-ifシミュレーションを繰り返し、ついに 自社の要員・状況にマッチしたWBSモデルを完成させた。
 現在ではKnowledgePLANをわずかなメインフレームのメンテナンスプロジェクトを除く、 大半のプロジェクトにて使用されている。

導入効果


 ニールセンではKnowledgePLANを使用した見積もりをプロジェクトで二度実施している。一度目は初期の概算見積もり時に、二度目はデザインフェーズ終了時点に、プロジェクトの詳細が決定しサイズや必要技術、要員計画を加味し計画立案用として使用している。 る。
 プロセスクオリティ コントロールチームが策定したWBSモデルにより開発計画の予測精度が高まり、図が示している通り、年を追うごとにプロジェクトの遅延が減り、現在は工期の乖離が平均106%と劇的に改善した。
 またKnowledgePLANが持つ業界標準データと比較検討、その相違点を分析、認識することで、自社の弱点、改善すべき点が浮き彫りとなる。それらの有形・無形の課題をひとつひとつクリアしていくことで体質強化につながった。
 自社のモデルが確立したことでアウトソーシングする際にも適正な工数が判断できるようになったことも大きな成果となっている。
 現在ニールセンは大規模プロジェクトのみならず、2週間に1度リリースするような小規模のXP開発、アジャイル開発にもKnowledgePLANを適用している。
 期待していた以上の副産物として、事業計画に合わせた要員計画が立案できることが挙げられる。KnowledgePLANの持つ業界標準データを自社データと合わせシミュレーションすることで、過去に全く経験のない分野においても精度の高い見積もりが可能となったのである。

まとめ


 ニールセンが専門の組織を設置してまで見積もりに力を入れていることは、「見積もりの精度を上げる」ことを最終目的としているためではなく、顧客との契約を遵守できる見積もりを行うためである。製品を「時間通り」に投入できることは、顧客からの信頼を得るだけに留まらず、コストの削減が図れ、機会損失を減らし、リターンを予想通りに得ることができる。
 ニールセンは全社でCMMレベル2を取得しており、現在はレベル3の取得を目指し取り組みを続けている。

プロファイル


 ニールセンメディアリサーチ社は40カ国以上で展開する視聴率調査会社。USでの社員は3,000名。

ピープルメーター
 これまでニールセンは、各放送地域における視聴率をまとめる際、主要都市ごとに 「ニールセン・ファミリー」と呼ばれる約500世帯を対象として、どの番組を視聴したか 日記式に記録してもらい、郵送してもらう手法をとってきた。現在では、視聴した番組を 「家族の誰が視聴したか」までを含めて自動的に記録する、ピープルメーターという高性能の セットトップボックスの導入を開始した。このメーターは、フロリダ州のニールセン社の データセンターに、電話線を介してデータを伝送する仕組みになっている。
(一部http://hotwired.goo.ne.jp/news/news/business/
story/20040419104.html
より抜粋)
 ニールセンのIT部門では、このピープルメーターへの組み込みソフトウェアや解析用ツール等種々のソフトウェアプログラムの開発、保守を行っている。

ファンクションポイント法 【FP法】


e-wordより引用
 ソフトウェアの持つ機能の数をもとに、そのソフトウェアの規模を測定する手法。 ソフトウェアの開発費用や工数などを算定する際に使われている。1979年にIBM社のA.J.Albrecht氏が考案した方式である。
 FP法が開発される前は、ソフトウェアのソースコードの行数(SLOC; Source Lines of Code)やファイルサイズなどがソフトウェアの規模の尺度として用いられてきたが、FP法の登場で以前より客観的・定量的にソフトウェアの規模を算出することができるようになった。
 FPの算出にあたってはソフトウェア内でどのような処理が行われているかを抽出し、入出力など機能ごとに分類、それぞれを「ファンクション」(機能)と定義する。
 さらに、ファンクションごとにレコードの種類の数やデータ項目数などからファンクションの「複雑さ」を定義し、個別のファンクションの評価値を算出する。
 評価値のアプリケーション全体での合計が「未調整ファンクションポイント」で、さらにソフトウェアの影響度(上下35%)を掛け合わせて「調整済みファンクションポイント」を算出する。
 FP法の普及を図るために1986年に国際団体IFPUG(International Function Point Users Group)が発足し、1996年には日本支部のJFPUG(Japan Function Point Users Group)も設立された。また、ISOでFP法の標準化作業が行われている。

サイトマップ | プライバシー
 
© 2001-2008 Artemis International Solutions Corporation. All Rights Reserved.
利用規約に従いウェブサイトをご利用いただきます。
サイトの利用条件.