大規模システム開発を成功させる考えかたは10年前と変わらない　――Rational Educational Seminar 2003

　2003年4月25日，日本ラショナルソフトウェアは，オブジェクト指向に基づく方法論や同社のツールの導入事例を紹介するセミナ「Rational Educational Seminar 2003」を開催した．その中で，NTTコムウェア ビジネスイノベーション本部 担当部長の堂山真一氏が，同社におけるRUP（Rational Unified Process）の導入事例を発表した．「RUPの全社導入を開始したのは2001年だが，大規模システム開発を成功させるための本質は10年前とあまり変わっていない」（堂山氏）として，1989年に同社（当時はNTTの一部門だった）が開始した電話交換機用ソフトウェアの開発プロジェクトを紹介しながら，大規模システム開発の問題について解説した（写真1）．

[写真1] NTTコムウェア 堂山真一氏（ビジネスイノベーション本部 担当部長）の講演のようす
堂山氏は大規模システム開発の事例として，主に10年前の開発プロジェクトについて語った．

●リリースの頻度を上げるためにグループを2分

　1989年当時はダイヤルQ2などの新サービスが続々登場し，交換機の開発要望が一気に膨らんだ時期だった．それまで，NTTでは年1回のペースで新しい交換機を開発していたが，それを年2回にする必要が出てきた．そこで，同社は開発チームを二つに分け，それぞれのチームが一つの交換機を2年かけて開発し，交互に（1年ごとに）出荷する体制にした（写真2）．

　ところが，ここで思わぬトラブルが発生することになる．両チームとも，それぞれ自分たちが2年前に開発したソフトウェアをひな型として新機種の開発を行っていた．その結果，それぞれの機種でバグや追加機能が異なり，設計情報を共有できなくなってしまった．

[写真2] 二つのチームがそれぞれ2年かけて開発
AチームはA版の製品を作り続け，BチームはB版の製品を作り続けるという状況だった．

　そこで同社では，開発グループを設計を行うチームと試験（テスト）を行うチームに分け，製品開発の前半の1年を設計に，後半の1年をテストにあてる方法を採用した（写真3）．設計チームと試験チームの人数比は4：6とした．

[写真3] 設計チームと試験チームが1年ずつ開発に携わる
一つ一つの製品開発には2年かけているが，設計チーム，開発チームはそれぞれ1年ごとに新しい製品にとりかかる．

　この方法を採るようになって，予想していなかった効果が現れた．年に2回のペースで製品開発に携わることにより，それまでよりも早く技術者が作業に習熟するようになった．このころ，多数の開発要望に対応するために社内から人手をかき集めていたこともあり，開発グループの中にはソフトウェア開発経験のない人材も多く混じっていた．そのため，必然的にリビジョン管理などをきちんと行うようになり，ソフトウェアの品質が改善したという．

　また，以前はソフトウェアのビルドを行うのは2ヵ月に1回の割合で，ビルドの合い間に修正用の差分パッチを用意して試験を行っていた．しかし，これ以降の開発では毎日ビルドを行う方法に切り替えた．その結果，ソース・コードに加えた修正が翌日にはソフトウェアに反映されるようになった．

●作業負荷が偏らないように動的に人員を配置

　同社では技術者の作業分担はソフトウェアのモジュール単位としていた．ところが，開発途上の機能追加は特定のモジュールに偏って発生することが多く，そのモジュールの担当者が次々と過労で倒れてしまったという．そこで，同社ではモジュール単位に人員を配置するのではなく，機能追加に対して人を配置する方針に変更した．つまり，追加量に応じて担当者の人数が増えるようにした．また，管理者が技術者の提出する日報から作業の進捗状況をチェックし，スケジュールが遅れそうなところの人員を増やす体制にした．

　さらに，同社では各技術者の設計能力を測定するためのテストを実施した．そして，設計能力が高いと判定された人材を中心に設計チームを構成するようにした．また，進捗管理や人員配置の判断を行う管理者を二人配置した．

　なお，NTTコムウェアが設立されたのは1997年だが，その際にもこの「動的な人員配置」の経験が役に立ったという．NTTコムウェアは，NTTの旧「情報システム本部」と旧「通信ソフトウェア本部」がいっしょになってできた企業である．それぞれの部門が独自にソフトウェア開発手法を発展させてきたという背景があり，設立当初は，例えば「試験」ということば一つ取っても，それぞれの出身部門によって細かい定義が異なるような状態だった．そのため，要員の配置転換などが難しかった．そこで同社は，開発グループを分析専門チーム，設計チーム，実装チーム，試験チームに分け，複数のプロジェクトの間で動的に人員を割り当てられる体制を構築した．

●文書管理は「最低限を全員で共有」

　堂山氏は，大規模システム開発を成功させるための注意点として，ドキュメント作成の問題にも言及した．

　同社では，かつて，開発が終わってからいっせいにドキュメントを作成していたという．しかし，試験チームが試験を行う時点でドキュメントがそろっていないと，有効な試験を行うことはできない．とは言え，開発側も忙しくてなかなかドキュメント作りに時間を割くことができない．そこで，最低限必要なドキュメント（ユースケースごとの仕様書，シーケンス図，状態遷移図）だけを事前に作成し，これらを開発グループ全員が共有するようにしたという．なお，以前はワープロ文書形式やテキスト形式などでドキュメントを作成していたが，現在はUMLに基づいてドキュメントを作成しているという．

　同社は，2001年からRUPとUMLの全社導入を開始している．ソフトウェア開発にあたってパートナ企業やソフトウェア・ベンダ，クライアント企業とコミュニケーションをとるときの共通の基盤になること，反復開発やアクティビティ管理などに対応していること，ツールや教育環境が整っていることなどを評価して，RUPを採用した．また，導入に際しては，ある程度トップダウンに新手法を現場に持ち込むことも必要になるという．「RUPを導入するための労力は大きいが，きちんとやればその効果が出ることを実感している」（堂山氏）．