システム構築に携わる開発者の間で「開発プロセス」に関する注目が集まっている。それとともに,開発プロセスを「自分流」に使いこなして成果を挙げる開発者が登場し始めた。理論体系である「開発プロセス」を,実践に基づく泥臭い言葉で語る人たちが出てきたのだ。

 「とにかく開発生産性を何とかして向上したい」「ソフトウエアの再利用性を上げたい」「開発したシステムの保守性を上げたい」――こうした課題に対する特効薬(「あるいは「銀の弾丸」)は,もちろん存在しない。一つ一つの問題の原因を突き止め,地道に,合理的に解決するしかない。

 「開発プロセス」とは,その解決方法を体系化したものといえる。しぜん,その内容は包括的,体系的なものになる。そう軽々と試したりできるものではない。それにもかかわらず注目が集まるのは,日々苦しめられている問題を根本から解決したいという欲求が高まってきたからだろう。JavaやUML[用語解説]の普及でオブジェクト指向技術への抵抗感が薄れてきたことも大きい。個々の開発者にとっては,世界標準の技術スキルを身につけたいという思いもあるだろう。

 「開発プロセス」として提案されている技術体系の種類は多い。ここではRUP(Rational Unified Process[用語解説] )を「自分流」に使い,結果を出した例を2件取り上げて見てみたい。共に,実装するプラットフォームとしてJ2EE(Java2 Platform, Enterprise Edition[用語解説])を使っている。RUPとJ2EEを取り上げた理由は,知名度が高く影響力が大きいからだ。そして,RUP,J2EEの用語や概念は,システム開発者にとって共通言語の役目を果たすようになると考えられるからだ。

 RUPは「大きすぎる」という声をよく聞く。実際,その全貌を把握するのは容易ではない。J2EEも範囲が広く,全体を理解するのは大変な技術である。だが,RUPにせよJ2EEにせよ,その全部を理解して導入する必要はまったくない。必要な部分に絞って「自分流」に使いこなせばいいのだ。

「こんな図じゃ分からん!」

 RUPの教科書を開くと,「RUPの三本柱は,(1)ユースケース駆動,(2)アーキテクチャ中心,(3)反復型/インクリメンタルな開発」という意味のことが書いてある。これを最初に見てピンとくる人はそう多くはないと思う。平たく言うと,一体どういうことなのだろうか?

 ユースケースは,システムの仕様書であり,また開発プロセス全体の作業手順を決める文書でもある。要は,ユースケースを中心に開発プロセス全体が回る。ここに工夫をこらしたのが,清水建設の事例である。

 同社では,RUPを参考にしつつ独自の開発方法論を構築して活用し,「工事建物データベースシステム(関連記事)」など複数のシステムで成果を出してきた。同社では,エンドユーザーと開発者とが仕様をすりあわせるさい,「LFD(レーンフロー・ダイアグラム)」と呼ぶ書式を使っている(「日経コンピュータ」誌に同社が連載中の記事にはLFDの実例が掲載されている。書籍『仕事のとれるSE』にも同社のモデリング手法に関する記述がある)。

 同社が編み出したLFDは,「ユースケース図」などRUPで使うUMLダイアグラムと同等の情報を記述している。ざっくり言えば,ユースケース図を同社流にカスタマイズした書式がLFDなのである。

 独自の書式を編み出した理由は,UMLによる記述を同社のエンドユーザー部門に見せる仕様書として使うのは難しい,と判断したためである。その理由を清水建設 情報システム部情報コンサルティンググループ課長の安井昌男氏はこう話す。

 「そもそも,エンドユーザー部門の人間が,オブジェクト開発手法を使うような大規模システム開発に参加する機会は何度もあるわけではない。そして,忙しく仕事をこなすエンドユーザー部門のキーパーソンにユースケース図をいきなり見せても,これじゃ分からん,となる。その人の一生に一回あるかどうかの仕事のためにユースケース図を勉強してください,とは言えない」。そこで,現場の「ウケ」が良かったLFDを使い,ユースケース図などを使う場合と同等の効果を得ている。「ユースケースと同じ意味を持ったLFDを中心に開発プロセスが回る。その意味で,当社の方法論は『ユースケース駆動』と呼ぶこともできると思う」

「画面はどうした!」

 「RUPで困ったことは,「画面定義」のドキュメント(文書)が定義されていないことだった」と話すのは,富士通エフ・アイ・ピー システム技術推進部長 兼 コンポーネント開発センタ長の川幡和利氏だ。

 同社では,複数の開発方法論を比較検討した結果RUPを選定し,流通業向けASP(アプリケーション・サービス・プロバイダ)のためのシステムを構築した。同社の場合,先の清水建設とは事情が違った。「ドキュメントをしっかり残して保守性を上げる」ことが開発プロセス導入の狙いの一つだったし,エンドユーザーが仕様書を作成するわけでもなかった。そこでユースケース図などRUPで使うドキュメントは徹底して使った。

 だが,そこで困ったことがある。RUPで定義していない書式が必要となったことである。特に従来型のシステム開発の現場で多用していた「画面定義」の書式がない。RUP導入の「メンター」役のコンサルタントに聞いても「ない」という。「仕方なく,旧来の画面定義の書式をそのまま使った」

 清水建設も,同じ問題にぶつかった。同社の場合は,先に説明した「LFD」と同時に「画面モックアップ」と呼ぶプロトタイプを作成する手法を取っている。画面だけのWebアプリケーションをまず作り,ユーザー部門とも打ち合わせをしながら,それとシステムの内部を結びつけていく方法を採った。

「一体どうやって作ればいいんでしょう?」

 多くの開発者は,画面(あるいはWebページ)や,データベース設計といった具体的な概念に基づいてシステムを開発していく手法に慣れ親しんでいる。いきなり抽象度の高い設計図を見せられても,最初は目を白黒してしまうことがある。

 清水建設の安井氏は次のように話す。「開発者に,概念クラス図を見せて説明する。「それは分かりましたが,一体どうやってこれを作るんでしょう」とくるんです」。そんな時はどうするか。

 ユースケース図(同社の場合はLFD)には,利用者(人間)とシステムとの間の境界が示されている。その境界には,必ず人間とシステムが会話するためのユーザー・インタフェース,つまり「画面」がある。「だから,この画面と,この概念クラス図をどう結びつけるか考えてちょうだい,と言うんです」。ここまで説明すれば,「概念クラス図」に基づいて,最終的な実装コードを作っていくまでの道筋ができる。システムのアーキテクチャとして採用したJ2EEが,システムの構造を規定してくれているからだ。

 同社の場合は,J2EEアプリケーション・サーバーと,その上で動くStrutsフレームワークを利用している。Strutsは,Apache Jakartaプロジェクトが開発したオープンソースのフレームワークである(解説記事)。Webアプリケーションへの要求を受け付け,処理を実行するJavaクラスを呼び出し,結果を表示するJSP(JavaServer Pages)を割り当てる動作を担当する。このように決まったスタイルの上で実装することで,開発効率は高まる(書籍『入門J2EEシステム開発』には,J2EEのアーキテクチャとStrutsフレームワークに関する記述がある)。

反復の極意は「おたがいに歩み寄る」こと

 RUPの「三本柱」の残る一つが反復型開発である。従来型のウオータフォール型開発モデルに比べ,RUPの反復型開発モデルは革新的に違うものだ,という説明を耳にした人は多いだろう(最近の「記者の眼」でも同テーマが取り上げられている)。しかし,よくよく話を聞いてみれば,「実は昔から,同じような考え方はあった」と証言する人も多いのだ。どちらが本当なのだろうか。

 このテーマで取材中に印象に残ったのは,ある大手ベンダーの技術者の言葉である。「反復(イテレーション)」の意味は,要求,分析,設計,実装,テストと複数の工程の間の断絶をなくすことにある,というのだ。

 例えば設計工程と実装工程はまったく切り離されたものではなく,相互に関連がある。実装上の制約を全く受けない設計はないからだ。それなら,設計者と実装者が相互に歩み寄って一緒に作業をすることで,良い結果を出せるのではないか。「ウオータフォール型」と呼ばれる開発スタイルを採用していても,「うまくいっている」開発現場では,設計者と実装者が真剣にやりとりをしていたはずである。それを体系化したものが「反復型開発」なのだ――「昔からあった」派の意見は,こういうものだ。

 そして,複数の「フェーズ」を繰り返しながら開発することの意味は,「システムを分離可能な疎結合な作りにしておき,「個別撃破」していくことにある」(安井氏)。つまり,反復型開発とは,単に「手戻りを認めた開発手法」なのではない。計画的に,段階的にシステムを作っていく手法としての側面があるというのだ。

 清水建設の場合は,同社のシステム部のSEと開発会社のSEが集まり,会議室の壁面にプロジェクタで「概念クラス図」を大きく投影し,それを見ながら議論するというやり方を採った。上流と下流,あるいは発注側と受注側が同じテーブルについて仕事をすることで,単に文書を受け渡すだけのやり方に比べスムーズに物事が運んだ。

「生産性はどうなの?」

 最後に,「本当に生産性は上がるのか?」という疑問をお持ちの方も多いだろう。答は一様ではない。新しい開発体系に習熟するのに時間が必要であることと,開発者の意識という「メンタル面」の作用が大きいからだ。だが,清水建設の安井氏は「自分たちの方法論で足かけ2年にわたり4種類のシステムを次々と開発していったが,開発者の習熟度はみるみる上がっていった。実装のスピードは数倍というレベルで上がった」と断言する。

(星 暁雄=日経BP Javaプロジェクト)

■最後に,宣伝を一つ。これらの開発成果については,6月30日開催の「第2回 J2EE(tm)カンファレンス」にて,詳しい議論を聞くことができる。参加者の質問を受け付けるBOF(Birds-of-a-Fether)セッションも開催する。「このコラム記事だけでは分からん!」とお感じの読者は,このイベントでぜひ開発者の肉声に触れていただきたい。