日本アイ・ビー・エム 斉藤肇ラショナル事業部長

米IBMは、米ラショナルソフトウェアを8月に統合、ソフトウェア開発用製品の刷新、強化を図り、「Rational」をIBMの5番目のソフト製品ブランドとして位置づけた。これにともない、日本アイ・ビー・エムも製品出荷を開始している。分析・設計ツール、テスト・ツール、構成管理ツール、開発手法などから構成される「Rational」製品群は、IBMの命題「e-business on demand」構想を実現するための中核となる。

なぜ、IBMは「Rational」を必要としたのか。旧日本ラショナルソフトウェア社長から日本IBMに移り、「Rational」部門を率いる斉藤肇ラショナル事業部長は語る。

「ソフト開発で重要なことは、どれだけ早く実際に運用できるようになるか、依頼主が要望する予算内で、いかに高品質のものをつくるか、ということだ。従来、米IBMでは、WebSphere、DB2にも開発環境はあったが、それぞれアプリケーションサーバー、データベースの開発環境であったため不十分な面がみられた」

「ソフト開発は、IBMが掲げる『e-business on demand』でかなりの比重を占める主題になっている。これがきちんとできなければ『e-business on demand』は実現できない。米IBMがラショナルを買収した背景には、このような状況があった。まず、ビルド(開発)があって、オペレーション、最後に運用、という一連のライフサイクルの循環をサポートするためには、ビルドの部分が、米IBMのミドルウェアには足りなかった。これらの点で、ラショナル買収には大きな意味がある」

「e-business on demand」は、企業と顧客までを統合的なネットワークでつなぎ、顧客、市場の要求など、あらゆる変化に柔軟、迅速に対応することができる事業体制とそのための技術とされる。企業の生産性を向上させるためには、作業工程の改善、資源の再利用、情報共有を進める、といったような点が重要となり、ソフト開発力がこれらを支える。

従来、ソフト開発手法の主流は「waterfall型」がその座に就いてきた。「waterfall型」は基本的にソフトの開発工程を分類して、要求分析、設計、実装、テスト、運用、という順で作業を進める。いわば工場の工程をソフト開発に適用したやり方であり、分析から運用まで、水が滝を流れ落ちるように開発が進んでいくことから、この名称で呼ばれるようになったという。「Rational」は、「waterfall型」の再検討を主張する。

斉藤部長は「waterfall型は考案されてから約30年が経過している。枯れてきてはいるが、問題点はある。この発想では、まずドキュメント作成から入り、当初コードはつくらない。プロジェクトが全体の1/3ほど進捗したところで、コードをつくり始める。となると、完成に近い時点で、何らかの問題が発生した場合、たいへんな事態になる。バグつぶしに徹夜、泊り込みでの作業を強いられる」と指摘する。

これでは結局「納期も遅れてしまう。実際、開発コストの4割をこのような手直しが占めてしまうことがある。サービスインも遅れることになる。予定の予算で収まらなくなる」(斉藤部長)状況がある。どうすれば、改善できるか。

Rationalには、ソフト開発の方法論「RUP(Rational Unified Process)」がある。

「RUPは反復型と呼ばれ、アーキテクチャーをまず固めて、ハードの上でサブシステムを作りこんでいく、アーキテクチャー先行型でもある。最初にリスク分析をして、リスクの高いところから作業を始める。プロットではなく、実際の完成品のコードを初めからつくっていく手法だ。その後はリスクの高い順につくっていくので、最後の段階になってリスクが残る、という最悪の事態が起こらない。これは大きな利点だ」

「Rationalの手法では、進捗の管理が効率化され、工程の管理も自動化されている。これで、エンジニアがいちいちリポートしなくてもすむようになる。チームとしての仕事の進み具合はどうなっているのか、バグはいくつ発生して、どのくらいの時間で直せるか、それらの事項が自動管理される」

ITの世界での時間の進み方は、他の業界の7倍早く進むドッグイヤーなどといわれるが、斉藤部長は「この30年、ハードはたいへん発展しているというのに、ソフト開発はあまり進んでいないのではないか。ソフト開発の工程管理は、マネージャ任せという時代ではなくなった。これだけ時間が経過すれば、現在適用できる部分は少なくなっているのでは」と疑問を呈する。

waterfall型を主体にしていると「Webベースの開発を迅速に進めることはできない。依然としてメインフレームの発想で開発をしている例が多いようだ。現状に適応した十分な方法論がないままに、しかたなくwaterfall型を使っている、ということではないか」(斉藤氏)。ソフト開発業務の生産性をあげるにはどうするか。斉藤氏は「3つの要因がある」という。これをまとめると、以下のようになる。

1. 習熟度:ビジネスフローでも一般に、生産性はトレーニングで向上する。ただ、最大でも10%程度の改善になる。

2. プロセスの改善、標準化・自動化を進める:トヨタがやったのは、生産技術を動作分析して、ラインに対して要員の位置、工具の位置など、どのように配置すれば最も効率がよいかを検討した。これはやがてロボットによる自動化へとつながり、ラインの速度は上がり、数十%の効率化が実現する。

3. 再利用:さまざまなコンポーネント、図面、アーキテクチャー、ドキュメントなど、2回使えば2倍、10回なら10倍効率は上がる。

「再利用、プロセス改善、習熟度。効率化の効果が高いのはこの順番になる。これまでエンジニアは、他人のつくったものをちゃんと動くのかどうかテストして確認するくらいなら自分でつくった方が早い、となって、再利用は進まなかった。これをUML(Unified Modeling Language:統一モデリング言語)で記述するようにすれば、同じ機能ならこの裏にあるものを使えるはず、とわかる」(同)。UMLは、オブジェクト指向モデルでの分析・設計の表記法を統一するための共通言語で、最近大きな注目を集めている。

企業のソフト開発の発展段階を斉藤氏は次のように分析する。1.マネージャの技量に依存している。2.基本作業の共通化。3.組織レベルのプロセスを整理する。一貫した手法、ツールを備える。4.常に最適化されている。日本では「1」に留まっている場合が多いが「全般的にみれば、いまの日本の状況は『1』ではまずいと気づいていて、何とかしようとは考えている。3を狙っているが、2を経由しないと3には進めない。3を目指している企業は増えてきた。日本は『2』までいけば大きく変わる。米国では、『2』から『3』に進むべく努力をしている」(同)。

諸外国では「インドが進んでいる。というのも、インドのソフト会社は米国企業の下請けからはじめたところが多く、米国の手法をそのまま受け継いだから。逆に遅れている日本企業は、インドの企業に仕事を発注する場合、UMLで書いていなければできない、と指摘されることさえある。中国、台湾は日本と同様のレベルだ。韓国は少し進んでいる、といった段階だろう」(同)。

未だ元気が出ない日本の産業に必要なものは何か。「製造業はハード、ものつくりに従事しているわけだが、今後、たとえば冷蔵庫にもIPアドレスを割り振って庫内管理させるというような使われ方をするようになれば、ハードといってもいわばソフトの塊になる。自動車でもそうだ。これからは、ものつくりのコストに占めるソフトの比重が高くなる。いまや、銀行、証券など金融機関もシステム抜きにしてはサービスを提供することができない。ここで遅れると、競争に負けてしまう。タイムリーに、競合他社より早くサービス提供し勝つためには、ただ単にコストを下げて業務改善するのではなく、仕事、需要をつくるのにコンピュータが必要になる。米国では、ITをうまく利用してWebビジネスを拡大できた。しかし、日本はこの10年間厳しい状況だった。再生のための大きなファクターとして、ソフトの品質向上は避けて通れないだろう。でなければ、全世界の競合に勝てない」(同)。

(大川淳)

日本IBM、新ブランド「Rational」の製品群を市場投入
http://pcweb.mycom.co.jp/news/2003/08/27/11.html

日本IBM、情報統合の施策を強化、データ管理ツールの新製品を投入
http://pcweb.mycom.co.jp/news/2003/05/27/08.html

IBM、Rational Softwareの買収でソフトウエア開発事業を拡充
http://pcweb.mycom.co.jp/news/2002/12/08/50.html

日本アイ・ビー・エム
http://www.ibm.com/jp/