現代のソフト開発は映画制作のようなもの――IBM Rationalウォーカー・ロイス氏：Rational Software Development Forum Tokyoリポート

テクノロジーとビジネスのガバナンス。IBM Rationalはソフトウェア開発プロジェクトの透過的な統合管理を目的とした統合プラットフォームを提供している。その背景にあるソフトウェア開発の在り方について、米IBM、Rationalソフトウェア・サービス、バイス・プレジデントのウォーカー・ロイス氏が説いた。

[木田佳克，ITmedia]

　日本アイ・ビー・エムは4月28日、東京ダイヤモンドホールで「IBM Rational Software Development Forum Tokyo」を開催した。

　「Rational」は、ソフトウェア統合開発環境にイノベーションをもたらすプラットフォームとして、IBMが取り組むブランド。同社でDB2やWebSphere、Tivoli、Lotusなどと並ぶ1つであり、Rationalでは、ソフトウェア開発を軸とした企業内ガバナンスを実現するビジネス駆動型のツールが提供されている（関連リンク）。

　「Innovation Driven by Software」（ソフトウェアが駆動するイノベーション）と題した基調講演には、米IBM、Rationalソフトウェア・サービス、バイス・プレジデントのウォーカー・ロイス氏が来日して講演を行った。

　ロイス氏は、ビジネスにおけるソフトウェアとのかかわり、そして従来型の開発手法と今後推進していくべき開発形態を説いた。

　同氏は、Rationalのミッションでは価値提案を重要視していると言い、現代のソフトウェア開発では「経済性」を問うことを忘れてはならないポイントだと言及した。そして、従来の開発手法について問題点を指摘し始めた。

　従来型のガバナンスは、ウォーターフォール型の開発手法を元としていた。この手法は、エンジニアリングの軸を基本としてできあがったものだとロイス氏は語る。

　現代ではユーザーニーズはもちろん、Web上でサービス展開を行うためには反復型開発が必須となっているが、従来型の問題点は前例、経験に基づいてプロジェクトが進むため、プロジェクトが成功する可能性が1回であることだという。

　また、「ソフトウェア開発は橋の建設とは異なる」とロイス氏。その理由について、大作映画では仕様だけを重視することはなく、作品にかかわる経済的な取り組みが必須なことを挙げた。

　「制作管理手法にも近代的なものが要求される。また、制作中には要求変化に対応する必要もあり、仕様だけを重視すべきではない。再計画を繰り返して作り上げていくものだ。このような形態はソフトウェア開発にもいえる。経済性に乗っ取った判断こそがプロジェクト成功のための基準となっている」（ロイス氏）

　どのように具体化すべきか？　ロイス氏は、比較的規模の小さな開発チームでより良い開発環境を構築していくことが重要だと語る。そして、反復型の場合には比較的リスクが高くなるカスタム開発を避けるべきであり、再利用可能なものの構築を重視すべきだという。それはコードだけではなく手法についてもだ。

　講演内のプレゼンデータとして、60％の企業が現代でも従来型の開発手法を採用しており、25％がRUPやUMLなどを用いた反復型の開発手法を導入、残り15％が未来指向なビジネス主導でガバナンスを確立しているという統計が示された。ただし15％の中には、eBayやAmazonなど、従来からのレガシーなシステムを温存していない企業がほとんどであり、IBM社内でもレガシーからの移行をテーマに取り組んでいるとロイス氏は語る。

　さらに、反復型における効果の指針としてロイス氏は、ウォーターフォールでは多くの負荷がソフトウェア統合作業やテストなどに費やされていたものが、ビジネス主導型であれば、分散されて要件定義やマネージメントなど、ユーザー要求を取り入れるプロセスにも十分に注力することができるという。

　一方で、未来型なガバナンスでは、マネジャーや経営層が予測性を把握するためにプラスの面があるが、マイナス面もあることを無視してはならないという。デベロッパーは自由にコード開発に時間を割くべきであり、ドキュメント作成ばかりにかかわることは不幸である、とロイス氏。これらのマイナス面をカバーするためには、統合化されたツールが必須であるといい、デベロッパーが開発に専念できる環境作りこそがRationalのミッションの1つであると語った。

　それではソフトウェアの経済性をどのように上げていけばよいのか？　ロイス氏は幾つかの指針も示した。

　ツールの自動化度合いが重要な1つではあるものの、多くの事例からは「ツールの自動化よりも効果的なのは、複雑性を軽減させること」だという。エンジニアリングにかかわる面で、何百万行のコードを1万行に減らす方が良い結果を得られているという。成功パターンの1つとしてロイス氏は語った。

　同氏は、60〜80年代のプロジェクトの9割が失敗しているとも指摘する。90年代からはオープンスタンダードの登場や再利用、そして教育の現場では大学でソフトウェア開発の授業が増え、ツールもオープンなものが数多く登場してきた背景にも触れた。そして、今後進むべき方向性としては、SOAのテクノロジーを取り入れ、Webサービスとしての再利用はもちろんのこと、カスタム開発を3割程度に押さえて迅速性を重視し、開発チームの分散、その形態を補完するようにコラボレーションのオンライン化、ツールについてもオープンに基づく統合化されたものが理想的であると語る。このような取り組みによって、プロジェクトの成功率は50％に上がるという。

　50％という確立を低いのでは？　と思われるかもしれないが、とロイス氏は補足した。ただし、ソフトウェア開発における経済性などを考慮すれば、現実的な数値であるという。

　何を持って成功と見なすかは難しいところだが、ユーザーニーズを理解し、システムダウンやセキュリティホールへの対処、費用対効果を考慮すれば現実的な比率が見えてくることだろう。