RUPの導入で本当に生産性は上がるのか？
NTTコムウェアによる反復型開発方法論の全社導入戦略

今回の特集では、全社規模で反復型開発方法論の導入を進めつつあるNTTコムウェアの事例をもとに、ウォーターフォール型開発手法が根強く残る組織内での、意識改革から実際の導入に至るまでの道筋を示す。「四苦八苦の連続で、いまでも試行錯誤している」とNTTコムウェア ビジネスイノベーション本部 担当部長 堂山真一氏は漏らすが、昨年、開発部門ではRUP導入パイロットプロジェクトを4本成功させており、その顔からは自信がうかがえた。

アットマーク・アイティ編集局
Development Style担当
谷古宇浩司

2002/11/29

---

複数の作業標準が社内でまかり通っていた

　NTTコムウェアが自社のプロジェクトに導入した開発方法論は、反復型開発方法論の世界において最も著名な「Rational Unified Process（RUP）」である。同社はなぜ、この膨大な体系を持つ新しい開発方法論を導入しなければならなかったのだろうか？ 堂山氏はいう。「顧客とわれわれとの間で作成するシステムの要求仕様は、常に変化し続ける、ということを受け入れなければ、時代のニーズに対応できないと考えたためだ。ウォーターフォール型の開発プロセスでは、ニーズに対応できない。新しい開発プロセスを真剣に導入する必要性に迫られていた」。

　NTTコムウェアは、NTT社内の情報系システムと通信系システムの開発部門が融合して誕生したシステムインテグレータである。社員数は5900人（2002年10月1日現在）だが、グループやパートナーなど共にビジネスを展開する人員を含めた事業規模は、全国で8000人強に膨れ上がる。同社は、NTTの子会社ということもあり、当初はNTTが最大の顧客だった。主事業は、電電公社の交換機や監視システム、それにデータ通信用汎用コンピュータ「DIPS（Denden Information Processing System）」の開発だった。

　それぞれ歴史があるシステムであり、作業標準もそれぞれで確立されていた。同社にとっては、これがネックになりつつあった、という。例えばDIPSの開発には同社独自の開発標準「Spirit」があった。「SpiritはRUPよりも巨大な体系だ。しかもプロジェクトごと、部署ごとに工程の名称ややり方、テストの意味さえも違ってくる場合があった」と堂山氏は話す。企業規模が巨大なために、開発プロセスがさまざまな所で“方言”を生んでしまう典型だろう。それだけではない。同社が1年間にこなすプロジェクト数はおよそ300件程度。そのうち、作業標準（開発プロセス）は「多いときで16本も存在することがあった」（堂山氏）。

　部署やプロジェクトごとに異なる作業標準が存在することの最大の弊害は、開発要員の流動的な移動ができないことである。プロジェクトごとにバラバラの“標準”を採用していた場合、まったくの部外者が途中からプロジェクトに参加することは作業効率の低下を招く。しかし、それでは作業計画の遅れを補完する人員配置を行うこともできなくなってしまう。さらに、プロジェクトごとの比較検討を行うことによる事後検証も、作業標準の違いで簡単にはできないという問題が出てくるのだ。

　そこで、せめて作業標準は9本程度に減らすべきだ、とする議論が同社内で起こった。9本というのは、例えば1つの統一された開発プロセスがあり、アーキテクチャごとで派生するパターンを9種類程度用意する、ということである。社内では「Customized Spirit」として、Spiritの膨大な開発プロセスの中から必要な要素を抜き出し、カスタマイズを行えばそれで事足りるのではないか、という議論もあった。しかし、受注案件では、J2EEベースのシステム開発注文が増えてくるようになっており、「反復型開発プロセスを導入することで、NTTコムウェアの開発プロセスを抜本的に見直す時期だと思った」と堂山氏はいう。

3年以内にRUP技術者を4000人規模に増やす

　ＮＴＴコムウェアが日本ラショナルソフトウェア(以下ラショナル)の協力のもと、RUPを適用したパイロット・プロジェクトを開始したのは2001年のことである。パイロット・プロジェクトとはいえ、実稼働を前提とした商用システムの開発だった。もちろん顧客も存在する。RUP経験者はゼロ、ラショナルのツール使用経験者ゼロからの出発だった。
　
　結果的に、このパイロット・プロジェクトは成功した。この成功でNTTソフトウェア社内でのRUPの本格導入が決定し、2002年度の目標をRUP経験者400人体制と定めたのである。さらに、3年以内に4000人規模まで拡張する計画も立ち上げた。

最初のパイロット・プロジェクトで RUPのフル適用には無理があった

　パイロット・プロジェクトは2001年で4件がほぼ同時に走ったという。その代表的な事例を紹介しよう。

　3層Web構成からなる新規のサービスシステム群とクライアント／サーバ型の既存の設備管理システム群をネットワークを介して接続、相互を取り持つのは、EAIアダプタで、企業間・システム間通信やトランザクション管理、データ変換、プロトコル変換、ワークフロー制御を行うというのがシステムの概要である。プラットフォームは、UNIXとWindows NTが混在する環境だ。レガシーシステムはDBMS、EJB、CORBAを活用したWebアプリケーションシステムへ変貌することになった（図1）。

図1 事例1のシステム概要

　当初、担当プロジェクト・サイドからみれば、RUP導入の話は、まさに晴天の霹靂だった。しかし、トップオーダーでRUP適用パイロット・プロジェクトの白羽の矢が当たってしまったのである。やらなければならない。パイロット・プロジェクト始動当時、同社内の作業標準はウォーターフォールであり、社内の決裁をスムーズに通すには、ウォーターフォールを踏襲した開発計画を提出しなければならなかった。すなわち、外部設計に2001年7月の1カ月間を費やし、内部設計に8月の1カ月間、実装に9〜10月までの2カ月間、テストに11〜12月の2カ月間をあて、12月末の出荷、という完全なウォーターフォール型の開発計画を提出したのだ（図2）。

図2 事例1のオリジナル・スケジュール

　だが、実際には実装、試験工程で反復型の開発手法を適用した。要求定義にはUMLモデリングツールRational Roseを活用し、構成管理にClear Case、問題管理にはClear Questを採用した。結果は、1カ月間の開発期間短縮である。「初回からRUPをフルに適用しようとしたことは無理があり、途中、プロジェクトは大変な苦労にみまわれたが、非常に満足できる結果が出た」と堂山氏はいう（図3）。

図3 結果は開発期間が1カ月短縮した（UCM=Unified Change Management：変更管理）

　RUP導入パイロット・プロジェクト初回の反省を生かした第2の事例も紹介する（図4）。

図4 事例2のシステム概要

　BtoC、BtoB、CRMなどのフロントエンドシステムをXMLベースのインターフェイスを通じて社内のDBサーバと接続するというのがシステムの概要だ。ロードバランサで複数のアプリケーションサーバの負荷分散を行った。このシステムの特徴は、5万を超す試験項目数が必要になるなどの膨大な入力パターンが存在したことだ。アプリケーションサーバからDBサーバ内に格納されるデータを参照する際に、異なるDBサーバを参照するケースが出てくる。そのときのトランザクションが、アプリケーションサーバ内のキャッシュ論理によって、システム全体の性能を左右してしまう。開発の佳境はテストであり、設計目標負荷の2倍までかけて、システムの振る舞いを観測し、全体のバランスを調整していった。

　スケジュールは、「方向付け」に2001年5〜7月の3カ月間、「推敲（すいこう）」に8〜9月の2カ月間、「作成」に10〜12月の3カ月間、「移行」に1〜3月の3カ月間を費やし、その後、移行＃1、移行＃2、移行＃3と調整を繰り返した。結果は、納期の完遂である。膨大な時間を費やしたテストには、自動試験ツールを導入したことで、試験稼働の大幅な削減を実現した（図5）。

図5 事例2のスケジュール

“改善”ではなく、“改革”

　全社的に開発プロセスの改善を行うのは容易なことではない。そもそも社内決裁がスムーズに通ることはほとんどない。堂山氏は「4件のパイロット・プロジェクトは結果的に成功した。当初は追加のトレーニング経費などで赤字に転落する覚悟をしていたが、生産性向上分でまかなうことができた。ここまでくるのに、社内の根回しを必死にやらなければならなかった。結局はトップダウンでの改革宣言が必須だと実感した。プロジェクトが成功したいまでさえ、ウォーターフォール開発に慣れた開発者には反復型へジャンプするのに抵抗感があるようだ」感慨深げにいう。

　現在、同社では当初定めた「3年以内にRUP技術者をグループ、パートナー内で4000人育成する」との目標に向け、ラショナルのWeb版教育コンテンツ「Rational WBT」を導入し、社員の育成に励んでいる。なお、Ratinal WBT は他社へもサービスを提供している。

　人員の教育を行いながら、プロジェクトをこなしていくことで、グループ内の人員の役割比率は、従来型の開発プロセスのときと明らかに異なってきているのが分かってきた。「管理」「要求」「設計」といった上流工程の人員比率が上昇し、「実装」「試験」などの下流工程に属する人員は自動化ツールのために低下している（図6）。統一された開発方法論を活用しているために、プロジェクトごとに最適な人員を割り当てられるという流動的な人材活用の利点も生まれたのである（図7）。

図6 NTTコムウェアグループの役割別の技術者比率

図7 NTTコムウェアグループ内における開発体制の見直し

　「開発プロセスの導入をプロジェクト単位で行うには限界が必ずある。“改善”ではなく、“改革”でなくては達成できないということを、今回のパイロット・プロジェクトを通じて実感した」と堂山氏はいう。パイロット・プロジェクトはいずれも、最大70人規模のプロジェクトでの適用だった。同社としては、小規模なプロジェクトだったが、「来年の秋には200、300人規模のプロジェクトにRUPを適用した事例も紹介できると思う」とし、NTTコムウェアグループ全体での開発プロセス改革にさらなる自信をみせた。

【関連リンク】
NTTコムウェア
日本ラショナルソフトウェア

【関連記事】
従来の開発プロセスと現場が抱える課題
新しい開発プロセス「RUP」と「XP」