4つの課題 ［1］ 反復型開発プロセスは有効か？ ［2］ ソフトウェアの品質をどう管理するか ［3］ 品質を維持するためのバージョン／構成管理 ［4］ 何がアーキテクチャであるべきか 　今日、ソフトウェア開発をめぐる環境はますますシビアになりつつある。本格的なインターネット社会の到来とともに、企業におけるシステム化要求は増えこそすえ、減る気配はまったくない。しかし、長きに渡る景気低迷のおりからヒト・モノ・カネといったリソースが潤沢に割かれるわけでもない。どうすれば迅速かつ最適の人員で、高品質のソフトウェアを開発することができるのか。 　業界の誰もが心に抱くこうした根本的な問題を議論したのが、、第13回ソフトウェア開発環境展（東京ビッグサイト、7月7〜9日）の日本アイ・ビー・エム ラショナルのブースで行われたトークセッションだ。アットマークアイティ 編集局長 新野淳一氏をモデレータに、SDPテクノロジー・エバンジェリストのIBMのエンジニアと、ソフトウェア開発の第一線で活躍するプロジェクト・マネージャが、ソフトウェア開発の永遠の課題ともいえる4つの点について意見を戦わせた。

［1］ 反復型開発プロセスは有効か？

　ソフトウェアの開発は、常に時間に追われる仕事だ。それでも10年前はまだ余裕があった。最近では、ビジネスに直結するWebアプリケーションの需要が増えていることもあり、開発期間半年、3カ月、酷い時は1カ月で、システムの本番稼動を求められることも少なくない。設計段階で仕様を固め、固まった仕様を基に開発フェイズへ、そして、単体／結合テスト段階へという悠長な開発プロセス（ウォーターフォール型）だけでは、なかなかうまくいかなくなってきた。加えて、システムの要求仕様は極めて流動的になってきている。

　短期、（仕様の）流動化傾向を辿るソフトウェア開発の諸問題を解決するために、RUP、XP、Agileといった開発プロセスが注目を集めている。しかし、これらを実際の開発案件に適用した場合、どの程度の効果が得られるのだろうか。

　トークセッションに先立ち、アットマーク・アイティでは読者アンケートを実施した。「どのような開発プロセスを採用しているか」という問いに対して、ウォーターフォール型が39％、プロトタイピング型が24％、反復型が12％、そのほか5％、採用なしが20％という結果となった。

どのような開発プロセスを採用しているか （n=859）

　セッションではまず、新野氏が巻山氏に反復型開発プロセスの採用について尋ねた。巻山氏は自身がプロジェクトリーダーを務めるいくつかの開発案件で反復型開発プロセスを積極的に導入してきたという経緯がある。

巻山　反復型開発プロセスのメリットは、反復することによってリスクを回避できることです。新しい業務、新しいお客さま、新しい技術の採用など、開発案件に不確実性が存在する場合、反復によって対処できるのがこのようなプロセスの利点です。

　ただ、常に反復型開発プロセスを採用するということは、リスクを担保してスケジュールを立てることになり、後ろめたさが生じるときがあります。何度もプロジェクトをこなしていると（ソフトウェア開発にかかわるさまざまな）不確実性、不確定要素、つまり予測不能な事態が消えていくものです。なので、プロジェクトが“成熟”したと判断した段階で、反復型からウォーターフォール型に戻すという開発スタイルを採用しています。

（左から日本アイ・ビー・エムの米持幸寿氏、同 藤井智弘氏、電通国際情報サービスの巻山展輝氏）

　そして、新野氏は来場者に、反復型開発プロセスの採用状況について尋ねた。結果は「採用している」という回答が全体の1割程度。この数字と読者アンケートの結果について、米持氏に感想を求める。

　米持　（回答者の多くは）反復型開発プロセスを採用しているという意識がほとんどないのではないでしょうか。というのも、小規模な開発だと、実はけっこう反復しているものです、知らぬ間に。だから、たぶん、「反復型開発プロセスを採用していない」という回答は、具体的な方法論、例えば、RUPなど、を使ってはいないということなのだと思います。チーム開発となればそれなりに統制が必要でして、つまり、それが方法論ということになります。

　読者アンケートで反復型開発プロセスを採用しない理由を尋ねると「チーム内にスキルのばらつきがある」「スケジュールや見積もりが立てにくい」「管理職が消極的」「お客さんの認知が得られない」という回答が返ってきた。この結果について藤井氏が発言する。

　藤井　反復型開発プロセスの本来のメリットは、変更に強いことではなく、危険なものを先に潰してしまうということなのです。ウォーターフォール型プロセスでも、最近ではきれいにフェイズを切ったものは少なく、部分的に反復型開発プロセスを採用しています。ウォーターフォールと反復開発は、実はそんなには変わらないのです。

　米持　IBMは昔からウォーターフォール型プロセスを推進してきて、それがいまでも効いています。昔は、コンピュータでできることが少なく、（システムの）デザインを最初にきちんと決めておけば出来上がりは大体決まったものです。いまは（コンピュータに）できることが増えて、バックエンドはそう変わらなくても、フロントエンドでいくらでも見せようが出てきた。ソフトウェア開発は、現時点で利用可能な最新技術を追いかけていく必要があるので、そういう意味では、反復型開発プロセスの方が向いていると思います。ただ誤解しないで欲しいのは、すべてを反復型にしましょうということではないのです。使えるところに使えばいい、ということです。

　藤井　最近、汎用機上の基幹系業務をオープン系システムに移行する案件が増えています。業務そのものは変わらないので仕様書はそのまま流用しましょう、というケースが多いのですが、実際、移行作業を開始してみると、「本当はこうしたい」という要望がザクザク出てきます。このように、要求が明確化されていない開発案件こそ反復型開発プロセスの出番だと思うんですよ。基幹系だから反復型開発プロセスはいらない論理は通らなくなってきていますよね。

［2］ ソフトウェアの品質をどう管理するか

　新野　品質、品質といいますが、ソフトウェアの品質って目に見えませんよね。仕様書に機能や応答速度が盛り込まれることはありますが、保守性の高さやバグの発生率まで言及するケースはまだまだ少ないのが現状ではないでしょうか。プログラマは、納期までに要求された機能を満たすことに精一杯で、チューニングをかけたり、拡張性を考慮したプログラムで納品しようというところまでは頭が回らない。ペアプログラミングやテストファーストといった方法論らしきものがないではないのですが、これが絶対というわけではないようです。

　読者アンケートで「品質向上のためにしていること」を募ったところ、トップ5は「ドキュメントとコードのレビュー」「ユーザーとの十分な合意」「設計標準やコーディング標準」「負荷テストや性能分析」「メンバーの教育」となった。このほか目立った回答には「品質改善タスクチームの結成」「フレームワークの利用」「ペアプログラミング」「休日出勤、徹夜残業」といったものがあった。

品質向上のためにしていること （n=859）

　この結果を受けて、新野氏は巻山氏に現場での経験を尋ねる。

　巻山　米国では仕様書に品質基準が明確に規定されており、その基準を超えるような品質向上努力は一切しません。それに対して、顧客も何もいいいません。ところが日本では、日本の伝統的なモノづくりに対するこだわりもあり、基準を超えても立ち止まることは許されず、究極の品質の追求を余儀なくされてしまいます。顧客もそれが当然だと自然に思っているんですね。もちろん、ソフトウェア開発でも同じ感覚です。すると、われわれとして、どこまで、あるいはいつまで、品質を高める努力をし続ければいいのか。ゴールが分からないということにもなります。これはなかなか難しい問題です。

　米持氏は過去にソフトウェアのメンテナンス業務に従事した経験があり、その際、IBMがワールドワイドで構築してきた「RETAIN」と呼ばれるナレッジデータベースが非常に役立ったという。

　米持　休日出勤や徹夜残業といった体力でソフトウェアの品質を高めようとか考えてはいけませんよ。少なくとも、個人の力ではほとんど無理です。「こうやればうまくいく」というさまざまな人の知識を集積し、データベース化してうまく活用すべきだと思います。

　IBMには「RETAIN」という、サポートのためのナレッジ・データベースがあるんです。サポート要員は、ある障害が生じた時、その状況をレポートとしてまとめることを義務付けられています。障害が発生するたび、逐次報告しなくてはならないのでとても大変なのです。当時は正直言って「なんでこんなことを」と思っていましたが、いま考えると、なるほど、と思いますよ。

　一方、藤井氏はトレーニングという観点から発言した。

　藤井　IT業界では、JavaやUMLの記述に関するトレーニングは熱心に行われるが、プログラムのチェックをどのように行うかという研修を実施しているところはほとんどありません。トレーニングそのもののあり方を根本から見直さないとソフトウェアの品質は向上しないと思います。

　バグを迅速に発見して修正するのではなくて、最初からバグを出さない仕組み作りが重要だと語るのは巻山氏だ。

　巻山　バグを修正して作ったプログラムは、そうでないプログラムに比べてやはり品質が落ちます。バグは出さないに超したことはないんです。そのためには人力ではなく、「仕組み」でバグ消滅を支援する必要があると思います。

　例えば、箱に卵を12個ずつ並べる仕事があるとしましょう。中には（誤って）10個や11個しか並べない人が出てくるでしょう。しかし、箱にあらかじめ12個ごとの仕切りを設置するとほとんど間違いはなくなります。つまり、バグを発生させない仕組みをあらかじめ作っておくのです。

　これと同じように、ソフトウェア開発の場合でも、例えば、エンティティの部分は自動生成するようにしたり、障害を出さないようにするツールを自作するという仕組み作りを積極的に行っています。

　米持　人力に頼っている限り、どんなにルールを作っても、破られる危険性があります。「構造上できない」という方向に持っていかなければならない。オブジェクト指向開発における「隠ぺい」という概念は、ほかの人が開発したプログラムをむやみに触らせない、品質を維持するための工夫といえるでしょうね。

［3］ 品質を維持するためのバージョン／構成管理

　ソフトウェアの品質を維持するための1つの手法として、そのバージョンや構成、変更をきちんと管理するやり方がある。新野氏は、ソフトウェア開発を「チーム戦」と表現した。いま何が起こっているのかをチーム全体で共有できなければ、ただでさえ労力のかかるソフトウェア開発がより困難なものになってしまう。

　論理的にはまったく正論なのだが、開発現場では実際どこまで行われているのだろうか。新野氏の問いに答えて巻山氏が答える。

　巻山　当社（電通国際情報サービス）では、バージョン管理を非常に重視しています。短納期の開発案件が多く、しばしば複数のソフトウェアを同時並行で開発することが多いんです。それぞれの案件で共通のフレームワークを利用していたりすると、フレームワークに変更を加えた途端、さまざまなソフトウェアに影響が出てしまう。バージョン管理ができていないと深みにはまってしまうのです。
　
　そして、新野氏が読者アンケートの結果を披露する。「ソフトウェアやドキュメントの管理方法には何を使っているか」という問いに対し、「各自ローカルで」13％、「ファイルサーバ／グループウェア」が43％、「CSVなどフリーツール」が24％、「商用の構成管理ツール」が15％、「そのほか」が4％だった。

ソフトウェアやドキュメントの管理方法には何を使っているか （n=859）

　逆に「ソフトウェアやドキュメントを管理しない理由は？」という問いに対する代表的な回答には、「そもそもドキュメントを作成しない」「開発中にドキュメントとソースが乖離する」「チーム毎に別会社が開発しており、意思疎通が難しい」「ワンマンPMが情報を公開しない」というものがあった。

モデレータをつとめたアットマーク・アイティの新野淳一氏

　一方、会場の来場者にバージョン／構成管理ツールの利用の有無を問うと、半数以上が「利用している」と答えた。

　米持氏は、チーム開発で重要な、強制力を持った統制ツールとしてのバージョン／構成管理ツールのメリットを強調する。

　米持　アンケートの結果を見ると、開発当事者のノウハウや記憶力に依存している部分が多いようですね。しかし、人に学習させても会社を辞めてしまったら意味がなくなってしまいます。またソフトウェアの開発プロジェクトには、途中で入る人、一時的に力を貸す人など、いろいろな立場の人間が混在します。

　藤井氏もこれからの開発を考えると、ツールでの管理が不可欠になると補足する。

　藤井　いまはソフトウェアの再利用性をできるだけ高めようという時代です。フレームワークの利用も広がっており、「今度作るソフトウェアはバージョンいくつのフレームワークで動かす必要がある」などというケースが出てくる。ソフトウェア同士の組み合わせがどんどん複雑になっていくので、ファイルサーバやグループウェアでの管理ではとても間に合わないと思いますし、現実的でもない。やはり、専用の構成管理ツールを活用すべきだと思います。そうしなければ対応できない時代がすでに来ていると実感しています。問題は、バージョン管理という単純な問題ではないのです。

　巻山　バージョン管理の必要性を感じない人は、携わっている開発案件がオブジェクト指向を採用しているわけではなく、コンポーネントの共通化を気にする必要がないからではないでしょうか。

　オフショア地域を利用して開発プロジェクトを進めている場合、開発拠点が分散するので、例えば、（IBMの）「Rational ClearCase」といったネットワーク機能を持った構成管理ツールを使わないと連携が取れないません。
　
　そのほか、専用の構成管理ツールを活用することで、ソフトウェアの品質を確保するために、開発者にコミットする権限を与えず、テスト担当者がコミットするといった使い方もできます。

　米持　余談ですが、（専用の構成管理ツールを活用して）開発者に意図的にコミットさせるという使い方もあります。「Rational ClearCase」では、削除や更新などの履歴がすべて残るので、プロジェクトマネージャが開発者の作業をチェックすることができる。マニュアルで管理すると、開発者の隠れた作業が見えないコストとしてのしかかってきます。セキュアに管理するという意味でもツールの存在は重要だと思いますよ。人力で何とかするものではなありませんし、そもそも人の力には限界がありますから。

［4］ 何がアーキテクチャであるべきか

　最後に提出された課題、それは「アーキテクチャの採用」である。企業では複数の業務アプリケーションが連携し合って稼動している。情報システムが1つの開発方法論でまとまっている方が、処理効率は高く、ソフトウェアの品質も確保しやすいのはいうまでもない。そこで（情報システムの）アーキテクチャを確立すべきだ、という議論が近年活発になってきているのだが、現実はなかなか理想どおりにはいかない。メインフレーム全盛時代からさまざまな標準技術を組み合わせて1つのシステムを構築するオープンシステムの時代、アーキテクチャの重要性はますます大きくなるのである。

　読者アンケートで「どんなアーキテクチャを利用しているか」と尋ねたところ、「J2EE」「Microsoft.NET」「CORBA」「オブジェクト指向／コンポーネント指向」などという答えが返ってきた。だが、これらは果たして「アーキテクチャ」なのだろうか？ そもそも、アーキテクチャとは何なのだろうか。

　米持氏が会場に問い掛ける。「うちの会社はこういうアーキテクチャを採用しているといえる人はいますか」。すると、会場では、ほとんど手が上がらなかった。新野氏が巻山氏の意見を求めた。

　巻山　当社ではJ2EEも採用していますし、フレームワークも使っていますが、これらをアーキテクチャだとは認識していません。アーキテクチャというのは、本来もっと上の層の話なのではないかと思っています。

会場は満員、会場外での立ち見も出た

　現在、企業は、自社の情報の流れをシステム化しようとしています。これが情報システム導入の最大の動機でして、われわれが議論しているのは、じゃあ、どういう“やり方”で情報システムを構築するのが最も効率的で効果的なのか、ということです。そして、わたしはシステム開発の現場に立って仕事をしているのですが、常々実感するのは、あるシステムとあるシステムを連携させる標準の規格がないことなのです。規格が決まっていないと、企業内はもちろん企業を超えてビジネスがつながっていきません。ここでいうビジネスというのは、ビジネスを動かす情報システムそのものであることはいうまでもありません。

　藤井　実は、この質問（「うちの会社はこういうアーキテクチャを採用しているといえる人はいますか」）は私が恣意的に入れたものです。というのも、アーキテクチャとは何かという議論がすごく曖昧（あいまい）になっているというこの現状をどうにかして気付かせたいという思いがあったからです。先ほど、巻山さんが指摘した通り、読者アンケートで登場していた「J2EE」「Microsoft.NET」「CORBA」「オブジェクト指向／コンポーネント指向」はミドルウェア層のアーキテクチャを指す術語で、厳密な意味でのアーキテクチャとは次元の違う話題なのだと思います。

　つまり、企業の情報システムは、事業の環境や技術の変化に迅速に対応するために、中核の部分、変えていく部分といった構造をきっちりと確立していかなければいけませんよね。これを情報システムの形で表現することが実は、アーキテクチャなのではないか、と思います。しかし、「アーキテクチャ」というといつも、J2EEやMVCモデルなどといった大雑把な話になってしまう。「J2EEでアーキテクチャを作っている」というのでは他社との差別化にならないのです。だって、ミドルウェア層の基盤がJ2EEだというのは、つまり、共通基盤を活用していますよ、という話に過ぎないのですから。1ランク上の強みを獲得するには、その企業らしいビジネスの特徴を持った堅牢なアーキテクチャを構築しなくてはいけないのです。

software runs the world−今日、私たちの日常生活は、 IT（情報テクノロジー）と切り離して考えることはできません。 また、変化の激しいビジネス環境では、 ITは生産性向上の手段から企業戦略そのものへと変化しています。 私たちは、「ソフトウェアが世界を動かす」をテーマに ソフトウェア開発の近未来を体感していただく一大イベントを開催します。 この機会に是非、IBM Softwareの最新技術動向、 そして、世界を動かすソフトウェアを肌で感じてください。 開催期日： 2004年10月7日（木）〜8日（金） 会場： ホテル日航東京（台場） 参加費： 事前申込 40,000円（2日間・税込） 当日申込 45,000円（2日間・税込） ※9月15日(水)までの特別割引！2日間 35,000円(税込) 主催： 日本アイ・ビー・エム株式会社 詳細・お申込みは、＜日本アイ・ビー・エムのWebサイト＞で

ソフトウェア開発者ギルドに戻る