![]() |
![]() |
|
Loading
|
@IT > .NETエンタープライズ新時代 第5回 |
![]() |
ビジネス・インフィニティは、国内最大規模のシステム開発会社であるNTTデータと、マイクロソフト、日本ヒューレット・パッカードにより設立された会社である。2001年の創業当初から一貫して.NETによるエンタープライズ・システムの開発を手がけ、現在では、全ての案件でオフショア開発(中国、ベトナムなど)を展開している。そのオフショア開発、そもそも「良い物をいかに安く作るか」という考えの下に始めたのだが、予想外の効果が得られたという。 「オフショア開発のきっかけは、確かにコスト削減でした。しかし実際にオフショア開発を始めてみると、中国は非常に優秀な開発者の宝庫であり、単純なコスト削減以上の価値があることに気付きました。そこでより密接に連携しながら、数多くのプロダクトを共同して開発するようになり、徐々にオフショア開発のノウハウが蓄積されてきました。そうこうするうちに、他社が請け負えないような規模の案件でも着実にこなせるようになり、安定したシステム開発サービスを提供できるようになりました」と、ビジネス・インフィニティの浜村氏は語る。 このようにオフショア開発を用いた大規模システム開発が次々と成功する理由は、単に中国の開発者が有能だというばかりではない。オフショア開発を安定的に実施できる仕組みをビジネス・インフィニティが導入したからだ。それが「リアルタイム・プロジェクト・モニタリング」(以下RPM)である。RPMはNTTデータ・グループで長年蓄積されてきた開発ノウハウに基づく開発と管理を実行するための環境で、そこにビジネス・インフィニティが考えるシステム開発の成功理論を色濃く反映させた作りになっている。その思想について浜村氏は次のように語る。 「これまでの経験とノウハウから、成功の秘訣(ひけつ)は『段取り8割、現場2割』という結論に至りました。段取りとは『開発標準』のことで、例えば開発ガイドラインやコーディング規約、開発手順、管理手順などです。ビジネス・インフィニティでは、NTTデータが長い年月と資金を費やして作り上げてきた完成度の高い開発標準を利用します。一方の現場では、その段取りに従って開発していくのですが、それが本当にきちんと守られているのかを『三現主義』で確かめます。三現主義とは『現場』に行って『現在』開発されている『現物』(=ソース・コードやテスト・データなど)を確認するというものです。つまり、自分の目で見て確かめたもの以外は信用しないというわけです」 しかし、この三現主義を実現するのはとても難しいようだ。 「例えば『現場』といっても、オフショア開発で中国やインドが現場の場合は、いつでも気軽に行けるわけではありません。また『現在』といっても、チーフ・アーキテクトのデスクトップでビルドが行われていたり、ソース管理ツールであるMicrosoft Visual SourceSafeに全員がAdministrator(管理者権限)でアクセスしてしまっていたりすると、どの修正を誰が行ったのか分からない場合があります。また、プロジェクト・マネージャーが開発者のソース・コードを確認する場合でも、これまで管理業務が中心で、コーディング経験の浅いプロジェクト・マネージャーだとすれば、コード・レビューを的確に実施できないかもしれません。さらにテスト状況を確認するにも、テスト項目表を見せられて『やりました』といわれても、実際に行われたのか確証が持てません。つまり、『現物』を確認するにも、何らかの仕組みが必要になります」(浜村氏) このような背景から、段取りと三現主義を守りながら、しっかりと管理するために作られた仕組みがRPMなのである。 「RPMの構想が生まれたとき、一からすべてを作るのではなく、すでに世の中にあるものを効率よく活用して構築できないかと考えました。そんなときにタイミングよくVisual Studio 2005 Team System(=チーム開発環境。以下Team System)のベータ版がリリースされたので、これに白羽の矢を立てました。Team Systemをベースにし、NTTデータ・グループ独自の社内品質管理ツールである「PMワークベンチ」を組み合わせて管理機能を強化することで、RPM環境を完成させました」(浜村氏)
エンタープライズ向けツールのTeam Systemは、統合開発環境Visual Studioを拡張して作られている。Visual Studioは、開発者がなじみやすいプログラム開発機能/テスト機能を数多く搭載しており、人気も実績も非常に高い開発ツールだ。このTeam Systemの強みを浜村氏は「役割分担と自動化を強く意識した製品であり、システムの絶対的な実体であるソース・コードを中心に捉えて管理できる」と評価する。その一方で「品質を作り込むうえで最も重要な設計工程での管理機能が弱く、現在ではタスクの登録などが行える程度」と弱点も指摘した。 片やRPMでTeam Systemと組み合わせて利用される独自の標準品質管理ツールは、「極めて高い品質管理を目指したもので、Excelなどで簡単に利用できるなど、プロジェクト・マネージャーにとって使いやすい作りになっている」(浜村氏)という特長がある一方で、「先ほど挙げた三現主義を実現するために必要なデータ(=現物)の収集方法が考慮されておらず、プログラマに直接口頭で聞いて、それを手入力することを前提としている」(浜村氏)という弱点があるという。 そこでRPM環境では、Team Systemの弱い管理機能を独自の標準品質管理ツールで補い、逆に独自の標準品質管理ツールが弱い三現主義に基づくデータ収集をTeam Systemで補っている。RPMでは、開発のベースとしてTeam SystemとTeam Foundation Server(=Team Systemのコアとなる開発管理のための製品)を使うことによって、リアルタイムに正しいデータ(=現物)を収集できるため、生産的に品質を管理できるようになった。 さらにRPMでは、Team Systemの標準機能で足りない部分はカスタマイズを施すことで、データ収集機能などを強化している。以下の画面はRPM環境の機能を示したもので、赤く囲った部分がカスタマイズが実施された機能だ。
Team Systemにカスタマイズされた機能について、ビジネス・インフィニティの津阪氏は次のように語る。 「Team Systemに標準搭載される機能の中にテスト済みのコードが全体の何%に当たるかというカバレッジ率を調べる『コードカバレッジ測定』機能、ソース管理システムにチェックインする際にクリアすべき条件を設定する『チェックインポリシー』機能というものがあります。この2つを組み合わせ、カバレッジ率の要求基準をあらかじめ管理者が設定しておき、それに満たないコードはソース管理システムにチェックインさせないようにする『コードカバレッジチェックイン・ポリシー』というカスタマイズ機能を作りました。これにより、『テストをしました』という開発者からの報告に頼らずに、テストのカバレッジ状況を正確なデータとして収集できるようになります。ちなみにこのカバレッジ率は必ずしも100%が最良というわけではなく、プロジェクトに応じた適切なカバレッジ率を管理者が定めるべきです。また、さまざまな要因でどうしても設定したカバレッジ率をクリアできないケースも存在します。そのような場合には開発者が理由を記述してチェックインできるようにする機能があり、管理者は、その理由を見て、やむを得ないものかなどの判断を下せます。このように、一定の品質を守る仕組みでありながら、ビジネスをうまく進めるための柔軟性も兼ね備えています」 「また、Team Systemに標準搭載されるバグ登録支援機能はバグ情報収集に大きな力を発揮します。これまで単体テストのバグ登録は、Excelに文章で手書きして管理していたのですが、Team Foundation Serverをベースにして、Team Systemの環境内でバグ登録を行えるようにすることで、作業を大きく省力化するだけでなく、単体テストの結果を事実に基づいて集積することを実現しています。具体的には、Visual Studioでバグが発生したコード部分を右クリックして、[作業項目の設定]−[バグ]というメニューを選ぶと、テスト名や、テスト結果はもちろん、そのテスト実施時のログ情報が自動で入力・添付され、後はバグの分類など残りの項目を入力するだけで済みます。RPMでは、この機能をベースに、標準品質管理ツールで収集すべきバグ情報を入力できるよう、カスタマイズしています。通常の開発作業の流れの中で自然にバグ登録が行えるので、開発者は従来の負担が大きかったドキュメンテーション作業から解放され、開発生産性を向上できます。また、入力ミスの低減と、虚偽入力の防止もできるので、データの確実性が高まるという管理上のメリットも併せて得られます」(津阪氏) このようにRPM環境では、Team Systemを活用することで、高レベルの品質管理を維持しながら、同時に開発生産性の向上を実現したわけだ。
RPMを活用したプロジェクトは、顧客の評価も良好のようだ。 「とあるお客様向けに開発したWebポータル・サイト構築は、3週間で9万ステップというボリュームで、作業量はとても厳しい開発案件でしたが、RPMを活用することにより、予定どおりの迅速な開発が可能でした。さらにこのシステムは、サービス開始から1カ月経っても故障件数がゼロで、お客さまは大変満足されていました」と浜村氏。 こうしたRPMの数々の成功実績は、グループの親会社であるNTTデータに対しても影響を及ぼしつつある。NTTデータでのRPM+.NETの印象、そして今後の意向について、NTTデータの齋藤氏は次のように語る。 「NTTデータが担当する大規模システム開発案件において、開発作業を複数のパートナー企業(協力会社)に委託することがあります。その一角をビジネス・インフィニティが担っているという体制です。このためNTTデータの立場は、徐々にプロジェクト・マネージャー(PM)の指向性が強まってきています。これに従い、先の浜村氏の指摘にもあったたように『開発者からの進捗報告などの不確実なデータ収集では品質が確保できない可能性がある』とする議論があり、最近では『見える化』と『すり抜け率』という言葉が重要視されてきています。『見える化』は、開発工程などを可視化して問題を早期に明らかにしようとすることです。また、『すり抜け率』は、前工程のバグが後工程で発見される割合です。例えば、『本来は設計工程で発見されるべきバグが、後のテスト工程で見つかる』などです。すり抜け率を指標にして、各工程で確実に品質を確保するための施策が現在では展開されており、そのために有効なツールとして、RPMが目に留まりました」 「すでにグループ会社に優れた環境があるのだから、NTTデータとしてもこれを中核に据えて活用できるのではないかという声があります。従来はJavaベースの案件が大勢でしたが、今後は.NETによるシステム開発(特にクライアント部分)も視野に入れていきたいと考えています。これまでNTTデータは、.NETベースの案件開発については、それほど多くを手がけていません。ただしこの背景には、開発経験が長いJavaの方が開発しやすいからという理由だけでベース・テクノロジが決定されており、必ずしも顧客要望というわけではありませんでした。しかし今後は、RPM(=.NET)の利用により、品質向上と進捗の見える化が可能になるなら、Javaだけに依存する理由はありません。今後は、案件の要求などを吟味しながら、必要に応じてRPMの活用を検討していく方向です」(齋藤氏) ■ NTTデータとビジネス・インフィニティが目指すゴールは、明らかに「高品質の確保」である。そのためにRPMが作られた。開発生産性までもが向上したことは、Team Systemの開発者支援機能によって得られた副次的なメリットである。NTTデータは、比較的早い時期から「品質」の課題に取り組んできた。これについて齋藤氏は次のように胸を張る。「NTTデータは、1993年に、ソフトウェア企業としては世界で初めて『デミング賞』を受賞しました。デミング賞は、企業の品質管理の仕組みと活動を表彰するもので、受賞当時は製造業が対象の賞だと見られていました。NTTデータがデミング賞を受賞できた背景には、当時から一貫してソフトウェア開発における品質の改善活動に注力していたことがあります」。 日本においても、オフショア開発は急速に広がっている。この際に重要なのは、「文化の違いを乗り越えて開発案件を成功させるスキル」であり、NTTデータとビジネス・インフィニティが目指す「品質に関する最高の技術」ではないだろうか。浜村氏は力強く次のように語る。「ソフトウェアにはバグがつきもの、といった旧態依然とした考え方がいまだに存在するが、それを認めてしまっては品質向上を望めない。ソフトウェアが本当の信頼を勝ち得るには、あくまでもバグ・ゼロを目指してどうしていくべきかを日々考えていかなければならない」。システム開発において、品質は最も重要なファクターである。オフショア開発などの開発コスト削減策を進めながら、いかに品質の維持向上を達成するか。システム・インテグレータの力量が試されている。
提供:マイクロソフト株式会社 企画:アイティメディア 営業局 制作:デジタル・アドバンテージ 掲載内容有効期限:2007年7月4日 |
|