正確で明確な「要求仕様」を作成するのは非常に難しい。それがオフショア開発となればなおさらである。
開発技術の発展により，従来よりも変更に強く，速くシステムを作ることは可能になった。しかし，実物を作らずに「紙上」だけで仕様を正確に定義するのは，いまだにとても難しい。
システム化の対象業務も様々で，近年では経理システムのように定型なものは少なくなった。要求を出す側のユーザーでも，アプリケーションを作成して初めて仕様が見えてくるといったことはよくあることだ。
システムに対する業務的な要求が，時間の流れによって変わってしまうこともよくある。チェンジビジョン代表の平鍋健児氏は，このことをで「ムービングターゲット」，つまり動く標的という言葉で説明している。
オフショア開発の場合，それが顕著になる。日本人同士のように，電車で移動すれば顔を合わせられる位置にいても，仕様に対する意識の違いや，仕様そのものの不明確さに悩まされているのに，海をまたぐとなると簡単に顔合わせもできないし，言葉も文化も違う。もちろん「行間仕様」なんて理解してくれるはずもない。
そもそもソフトウエア開発では，「紙」だけではなかなか意図が伝わらないので，結局のところコミュニケーションを何度もとることになる。その意味で，ソフトウエア開発はコミュニケーションの塊であり，それが薄い状況ではプロジェクトは非常に失敗しやすい。
そして，オフショア先から依頼したアプリケーションができあがってきても，バグだらけで動かなかったり，意図していたものと違ったりして，結局国内で修正する羽目になる。加えて，そのアプリケーションは1クラス何千行もあって，保守できる代物ではなかったりする。
こんなに無駄なコストがかかっていては，オフショアリングをした意味があるだろうか？ また，それは単にオフショア先の問題なのだろうか？ 多少はそれもあろうが，結局日本側で作った要求仕様が，明確でも正確でもないことに大きく起因していないだろうか？
このような現状で，正確で明確な「要求仕様」を作る方法を考えてみよう。
望ましい「要求仕様」とは
仮に，自分がオフショア先だったとしたら，どういう「要求仕様」があればちゃんと作れるだろうか？ もし，自分が作る予定のシステムと全く同じ「動く」システムが，ご丁寧に設計書とマニュアル付きであったりしたらどうだろうか？
設計書だけでなく，完成予定のアプリケーションと「同じ動き」をするアプリケーション自体が「要求仕様」の一部としてあれば，こんなに明確で正確な仕様はないだろう。仕様がわからなければ，設計書を読んで実際に動かしてみて，自分が今作っているシステムが同じ動きをするかを確かめてみればいい。とてもわかりやすいはずだ。
「本番のアプリケーション」の「要求仕様」として「動作するアプリケーション」をとても「早く」作れるならば，「動く仕様」は実現可能なのでは？──これが，今回説明する要求作成術の原アイディアになった。
実は，このアイディアを実現できる基盤がすでに存在しているのだ。一つはRubyであり，一つはアジャイル開発だ。これらをそのまま使うのではなく，「要求仕様としての動くアプリケーション」を作るために使うことが発想の転換ポイントである。
ついついRubyで作るようになってしまった
部門サーバーや簡単なWebサイトといったレベルならともかく，実際の業務システムを作成する場合には，JavaやC#などを使うことが主流だろう。これらは，ミッション・クリティカルで大規模なシステム開発にも向いているし，実績もある。
一方，最近注目されているRubyは，オブジェクト指向スクリプト言語である。現在のところはまだ，ミッション・クリティカル性やパフォーマンスに難ありという感じではある。しかし，学習コストが低く，生産性が非常に高いことが魅力の一つである。
Ruby on Rails（以下，Rails）は，WebアプリケーションをRubyで作成するためのフレームワークである。CoC（Convention over Configuration：設定よりも規約）という考えに基づいて作成されており，Rubyが持つ強力なメタプログラミング機能をフル活用して，コードの重複や冗長性を避けられる。実際に使ってみたイメージは，「自分の意図したこと」だけを書けばよいという感じで，似たようなコードや設定ファイルを何度も書くことなく，システム構築ができてしまう。
RubyでRailsを使って開発したときの生産性は，Javaに比べて10倍と言われている（これは宣伝文句であり，いささか眉唾ではある）。筆者も実際に使っているが，確かにJavaに比べて圧倒的に生産性が高く，なおかつ，良い設計で作ることができる。正直に言うと，最近はJavaで作るのが面倒くさくなって，ついついRubyで作ってしまうようになってしまった。
ここで注意したいのは，この生産性の高さは，コードの自動生成などの機能で達成されているのではないことだ。完全に手作りで作っても，「達成したいこと」に対してのコード量がJavaと比べて圧倒的に少なくて済むという点が重要だ。
変化に強いアジャイル開発
もう一つのポイントは，アジャイル開発である。
日本では，ユーザー企業の情報システム部門の人数が少ないために，一括発注スタイルを選択することが多い。一括発注するためには，ある時期で要件定義をして，仕様を決めてから発注という順になる。また，実際に開発するスタイルもウォータフォールと呼ばれる方法が主体で，要件定義→基本設計→詳細設計→実装といった流れで開発が進んでいくことがほとんどだ。
しかし，現在のJavaや.NET，そしてRubyなどの新しい言語は，技術/機能の向上速度が速いうえに，前述の通り「紙上」で仕様や設計を検証するのは難しいため，基本設計や詳細設計を紙上でこってりやるのは大変効率が悪い。
また，ウォータフォール型開発は，工程の後戻りに弱いため，要件定義をしっかりして，変更をできるだけ少なくする必要がある。しかし近年，要求は変更されるのが当たり前になっている。業務の都合からも，最近の技術の都合からも，ウォータフォール・スタイルで開発することは，かなりムダが多くなってきた。
こうしたビジネスと技術のスタイルの変化を背景にして生まれてきたのが，アジャイル開発だ。
詳細な説明は省略するが，アジャイル開発を実施すると，最初に要件定義をこってり行わなくても，実際のアプリケーションを少しずつ作りながら，要件を決めていくことができる。技術的なリスクが少なくなるし，要件定義という点でも，ユーザーが要件を決めるときに，紙ベースではなく，実際に動くものを見ながら仕様を決められるというメリットがある。
また，変化に強いという特徴もある。仕様の「変化」を前提とした作りになっており，中間成果物があまり必要でない。開発工程の中では，ドキュメント作成はかなりの工数を占めるので，これが少なくなるだけでもかなり効率がよい。
日本のシステム開発文化の壁
このようにアジャイル開発は，現在の技術や業務の都合にとてもマッチしているため，「開発手法」としては大変素晴らしいものである。ところが，以下のような問題のため，日本では頻繁に使われるとは言い難い。
- ユーザー企業の情報システム部員が少なく，仕様を決めて一括請負契約の文化になっている（一括請負契約の場合，最初に仕様を決めておく必要がある ← アジャイル開発は最初に仕様を決めなくても開発できるので，準委任契約で真の効果が発揮されるのだが…）
- 大規模開発には向いていない
- 最初の時点では，作るものが確定していないので見積もりができないという不安がある
このように日本固有のシステム開発文化のため，国内ではあまり使われていないのが現実だ。文化的な側面はなかなか変化しないし，変わる速度も遅い。トヨタ生産方式も，考案してから浸透するまで何十年とかかっているのだ。
しかし筆者は，工夫しながらアジャイル開発で本番の業務アプリケーションをいくつか構築した実績がある。その現場で，現在のアプリケーション開発に非常に向いていることを実感したし，多くのメリットも享受した。プロジェクトの成功率にも大いに貢献すると思う。
