目標追跡型グローバルソフトウエア生産システムを考える(1)

2008.02.14

　前回は，牛尾剛氏が「オフショア時代を乗り切る明確な要求仕様作成術」というタイトルで，RfS（Ruby for Specifications）の考え方を紹介した。牛尾氏が原稿の最後で紹介してくれたように，RfSは彼と私がディスカッションをするなかで生まれたものである。

　その創造的で刺激に富んだディスカッションを通じて，私は以前から持っていたソフトウエア生産の方法についてそのイメージを鮮明にすることができた。ここではそれを「目標追跡型グローバルソフトウエア生産システム」と名付け，RfSのアイデアと関連付けながら，その可能性とメリットについて説明してみたいと思う。

　RfSとは，Ruby言語，ならびにRubyによって書かれたオープンソースのWebアプリケーション・フレームワークであるRuby on Railsを用いて高速にプロトタイピングを行うことである。その意味では，RfSは一つのプロトタイピング手法でしかない。

　しかし，RfSには二つのポイントがある。第1のポイントは，プロトタイピングの目的が仕様書の作成だということ，そして，第2のポイントは，RfSが要件定義の工程としてアジャイル開発のプロセスの中で実施されるということである。本稿では，この二つのポイントについて順番に説明する。

あいまいになりがちなプロトタイプの目的

　情報システムを開発する際，しばしばプロトタイピングが実施されるが，その目的をあいまいにしたまま実施される場合が少なくない。例えば，画面操作を中心にした機能要件検証のためのプロトタイピングで，同時にプラットフォームの性能評価などの非機能要件検証の目的も持っていたりする。

　それに比べて，RfSによるプロトタイピングの目的は単純明快，機能要件の検証のみである。なぜそこまで単純に割り切れるかというと，RfSのプラットフォームであるRubyやRuby on Rails（以下，Ruby＋Railsと呼ぶ）を実運用で使用するものとは考えないからである＊1。

　実運用に供されることのないプラットフォームは検証する意味がないから検証しない。このような割り切りがあるために，プロトタイピングに使用しているプラットフォームと運用時に使用するプラットフォームを混同した議論に時間を費やす必要がない。結果として，Ruby＋Railsが持つ生産性だけを単純に享受できることになる。

＊1これは実運用で使用してはならないと言う意味ではない。あくまでも使用を前提としないということであり，実運用に供しても何ら問題がないならば，当然使用すべきである。

図1●RfSによる開発工程
[画像のクリックで拡大表示]

RfSが作り出す仕様書とは

　RfSにおけるプロトタイピングの目的は仕様書の作成であると述べた。それでは，RfSで生み出される仕様書とはどんな構成になるだろうか。

　仕様書というと少しおかしいかもしれないが，RfS段階で構築されたプロトタイプそのものは仕様を表現するすばらしい媒体となる。つまり，オフショア開発の現場でRfSの成果物をインストールして実際に使用してもらえば，単に静的なドキュメントのみに頼る場合とは比較にならないほど豊かな情報伝達が簡単に行われることになろう。国内に配置されているRfSアプリケーションをそのままインターネットやVPNを経由してオフショア側に利用してもらっても良い。IP電話やテレビ会議なども有効な補助手段となるだろう。

　当然ドキュメントも必要である。その中にはデータ構造図，データベース設計などの情報構造に関するドキュメントが含まれよう。RfS側のデータが格納されたデータベースそのものがそのままオフショア側の開発に利用できる場合もあるだろう。

　プログラムロジックに関する仕様はどのように伝えれば良いだろうか。一つにはRuby＋Railsのコードや設定ファイルを読み込んでもらうことが考えられる。しかし，それではオフショア側にこれらと本番開発用の言語の両方が理解できる人材を用意してもらわなければならいない。それでは経済的に得策とはいえないので，ここは別途ドキュメントを起こして仕様伝達をしなければならない。

Webサービス・インタフェースという仕様

　プログラムロジックの仕様について，RfSは強力な武器を持っている。それは，Webサービスとしてカプセル化された機能を呼び出すためのインタフェースが自動的に生成されることだ。

　Webサービスのインタフェースは，サーバーサイドが果たすべき責任を表している。これが，RfSの次ステップとして実施される本格的なサーバー機能開発のための明確な仕様となるのである。

　責任によって納入されるべき製品の仕様を表現するという設計手法は「契約による設計（DbC：Design by Contract）」として知られている。そのメリットは，責任を提示する側が，その実装方法について言及しなくて良いこと，逆に実装側からすれば，創意工夫の余地が与えられるということである。

　そして，このような独立性があるにもかかわらず，実装された成果物が正しいものかを完全に検証することができる。契約による設計は，コンポーネントの設計手法であるが，RfSはそれをより大きな粒度であるサービスに適用する。

　RfSの仕様表現と，これまでウォーターフォール型開発で行われてきた詳細設計を比較すると違いがよくわかるだろう。後者では，プログラマによる実装作業がなるべく単純になるよう，事細かに手続きを説明する。しかし，今日一般的に使われているEclipseやVisual StudioのようなIDE（統合開発環境）は単純作業を前提にしてない。リファクタリングに関するアドバイスのような，設計に対するフィードバックを提供するなど，創造的なプログラマに使用されることを前提にしている。

　RfSでは，前述のような「契約による設計」型の仕様書が与えられるため，今日の開発環境が持つ能力を全く無駄にしない。従来型の設計書では，それをきちんと保守し，ソースプログラムと整合させるのは大変な労力を要するが，「契約による設計」型の仕様書は実装と観点が異なるため，整合性を維持することは繁雑な作業にならない。

図2●「契約による設計」型の仕様書
[画像のクリックで拡大表示]

　前述したRfSが作り出す仕様書に加えて，オフショア側に提供するべきものとして，テスト・プログラムがある。その検査に合格することで，国内側にあるRfS版のWebサービスと等価な機能を持つことが保証されるように，テスト・プログラムを開発しておく。そうすれば，オフショア側でそのテストに合格すれば，そのサーバー機能はRfS版のサーバー機能と全く等価であることが検証されたことになる。

要件のカテゴリと国際分業

　RfSでは，非機能要件を満足するサーバー機能の開発は，基本的にオフショアに依存することになる。特にオフショア側に設計上の配慮を期待したい非機能要件の中身は，図1にも示したように，(1)可用性，(2)性能，(3)運用性などである。このような分業を行うことで，オフショアの有能な技術者や，産業横断的な知識を活用することができるだろう。そのため，有能な人材がボトルネックになって開発が進まない，あるいは開発が失敗するといった事態を回避できる。

　これは，まるで国内に有能な技術者がいないかのような言い方であり，批判を受けるかもしれない。しかし，日本のITサービス業界に，たとえシステムエンジニアやプログラマと称する人材が多くいたとしても，体系的なシステムエンジニアリングの教育を受けた技術者が少ないことは残念ながらまぎれもない事実だろう。

　したがって，非機能要件を満足するための設計のような，高度にテクニカルな作業を最初からオフショアに分担してもらうのは十分理にかなったことであると思う。また，非機能要件はその情報量からしてドキュメント化も用意であり，オフショア開発の宿命である言語の壁もさほど問題とならないだろう。

　オフショア開発を実施できる国のなかでもインドは，非常に明確な要件定義を求めてくる。それに対して日本国内から提示される要件は明確ではない場合が多く，それがオフショア開発失敗の原因になることが多い。その点についてRfSは問題ない。RfSが提供するのはプロトタイプとその説明書としての仕様書である。その意味で，要件は完全にフィクスされていて，あいまいさは全くない。

　繰り返しになるが，RfSにおける国内開発の役割はプロトタイピングである。そして，そのプラットフォームはあらかじめRuby＋Railsと定められており，非機能要件への配慮はいらない。このことで国内側は，顧客に近いという環境を活かした，ていねいな機能要件の洗い出しに専念できる。

　このようにRfSは国ごとのカルチャや生産性の違いも最適に組み合わせて，全体としての効率アップとコストダウンを実現する。