InfoQは今回，iRiseのイノベーションソリューション担当シニアディレクタであるMike Hughes氏に，同社のラピッドプロトタイプおよび要件定義プラットフォームであるEnterprise Visualization Platformについてインタビューした。
Hughes氏はその話の中で，近年の開発における要件定義と要件管理について，特にアジャイルチームでの要件の扱いと開発業務で直面する問題点をあげた上で，顧客要求の伝達という面での，インタラクティブな図やプロトタイプの有用を説明している。さらに氏は，インタラクティブなプロトタイピングのリーンスタートアップへの応用や，要件定義および要件管理の将来についても論じている。
InfoQ: 要件定義と要件管理の展開について，最新の状況を説明して頂けますか？ソフトウェア産業ではどのようになっているのでしょう？
Hughes: 開発チームによるアジャイルの採用，あるいは開発文化の大きな変革に注目が集まる一方で，要件定義や要件管理ツールへの関心は，長い間，先細りという状況でした。最近になって，アジャイル方法論を補完して，その適用範囲の拡大を支援するための要件ツールに，新たな関心が見られるように思います。大規模な組織の多くには，開発チームの世界規模での分散という現実があります。このようなチームが地理的および時間的コミュニケーションギャップを埋める手段として，要件ツールへの要求が高まっているのです。
それと同時に，開発の進捗を見る指標として，単に“動作するソフトウェア"というだけではなく，価値のあるソフトウェアであることの重要性が認識され始めています。アジャイルメソッドや，最近ではDevOpsメソッドが，チームの迅速な開発とデプロイを支援してきましたが，それでもなお，結果が顧客のニーズを満たさないこともあります。真のビジネスバリューを提供できる適切な要件を定義して，可能な限り早く目標を定められるようにチームを支援することに，私たちが注力しているのは，そのような理由からなのです。
InfoQ: 一般的なアジャイルチームでは，要求事項はどのように扱われていて，日常的な作業ではどのような問題に直面しているのでしょうか？
Hughes: ほとんどのアジャイルチームでは，要求事項のようなユーザニーズの表すために，ストーリを使用しています。一般的なユーザストーリはテキストの一文に過ぎず，解釈の余地をかなり残しています - チームが分散している場合は特にそうです。単純なユーザストーリは曖昧に過ぎることが多く，特に全員が一箇所に集まっていない場合，実装のベースとして使用するには不完全なのです。その結果はスプリントの終了時に，ユーザストーリの拒否や大幅な書き直しになって戻ってきます。
アジャイルはウォーターフォールよりもずっと優れていますが，この基本的なコミュニケーションの問題に関しては，改善の余地は多いにあると思います。プロダクトオーナとしてユーザストーリの意図を効率的に表現するには，どうすればよいのか？ 世界の反対側にいるビジネス関係者にあなたの提案を評価してもらうには，どうすればよいのか？コード作成を担当する開発者に何が必要なのかを説明するには？フィードバックがEメールの山に埋もれてしまわないようにするには？
InfoQ: 顧客と開発者の間で要件を伝える手段として，インタラクティブな図やプロトタイプがどのように利用できるのか，説明して頂けますか？
Hughes: 最高のフィードバックは，ソフトウェアを初めて手にしたユーザからのものです。 重要なのはインタラクションです。スクリーンに写し出した絵と，実際にスマートフォン上でドロップダウンをクリックし，データを入力し，ページをナビゲートしてもらうのとでは，効果の面でまったく比較になりません。ユーザがソフトウエアをより早く体験して，フィードバックを提供してくれる - これこそが，アジャイル方法論の強みなのです。
ユーザが自分自身のニーズを明確にできることはまれなので，これは非常に重要です。実際の製品に - あるいはもっと効率的に，実際に機能を体験できるプロトタイプに触れてみて初めて，設計上の問題や要件の誤り，ユーザビリティの問題などが分かるのです。
このように，現実的なプロトタイプを短期間で構築して提供できれば，フィードバックの取り込みやユーザストーリの検証が簡単になります。これにコンテキストを提供するインタラクティブな図を組み合わせれば，要件とビジネスバリューをより一層理解することができます。コードを書く前にこれらすべてを実施することが，適切なソリューションを獲得する上で，より早く，無駄の少ない方法なのです。
InfoQ: DevOpsでは，開発や運用のプロフェッショナルがユーザと一緒になって，集中的に作業することになります。このようなコラボレーションを行う上で，iRiseツールスイートがどのように利用できるのか，いくつか例をあげて頂けますか？
Hughes: DevOpsでは，ビルドや検証の自動化，コードのデプロイなど，継続的インテグレーションに関連する部分に注目が集まることが多いのですが，DevOpsの対象はソフトウェアのバリューチェーン全体であることを忘れてはなりません。DevOpsにはITからビジネスバリューまで，すべての段階に関わる人が関係しているのです。
iRiseはコーディングを開始する前に，プロトタイプとインタラクティブな図，ユーザストーリをキャプチャし，開発チームとユーザで共有することを可能にします。さらにALMプラットフォームとの統合により，その情報がiRiseプラットフォームによって確実に把握され，開発対象のシステムへと自動的に引き継がれます。計画作業，コーディング，テストスクリプト作成など，すべてに関わるチームメンバが，プロトタイプ化されたユーザストーリを確認することで，ユーザストーリだけでなく，そこに意図されたビジネスバリューも容易に理解できるようになります。
InfoQ: インタラクティブなプロトタイプは，リーンスタートアップのアプローチでも有効でしょうか？実際にこのような方法を行っている例はありますか？
Hughes: リーンスタートアップでは，ビルド-検証-学習というフィードバックループが中心となります。リアルなプロトタイプは，ユーザに最小限の実現可能なアイデアを示して，フィードバックから学ぶという意味では，コードを実行するのと同じ目的を果たします。プロトタイプは数時間で組み上げて，簡単に提供できるので，非常に短い時間枠で新たなアイデアを試すことが可能なのです。
その良い例はiRiseそのものです。新製品の機能を検討する過程で，私たちは，まさにこれを行っています。プロトタイプを使って新たなアイデアをユーザに提示し，その反応から学び，アプローチを適応させることで，顧客価値として私たちが知っているものに対して，開発チームが集中していると確信することができるのです。
InfoQ: 要件の定義と管理に関して，今後どのようなことが期待できると思われますか？
Hughes: SaaSベースの製品の急増によって，ビジネス上の問題定義やソリューションの記述と精査，その後の計画と追跡における選択肢が拡大するとともに，そこからソフトウェアを定義することの責任も重くなっています。フィーチャーヘビーで導入の難しいこれまでの要件プラットフォームに対して，最近のソリューションは，使い勝手(ease-of-use)を重視し，クラウドを採用することで，ソフトウェアインストールに関する課題の回避に成功しています。
しかしながら，製品開発の責任の一部にのみ焦点をあてた製品が大部分を占めているため，プロダクトリーダたるあなたが業務を効率的に遂行するためには，さまざまなツールを組み合わせて使わなければならない状況に変わりはありません。このような断片化されたツール環境では，構築中の製品を全周囲的に把握することが難しいのです。プロダクトマネージャの必要とする機能をすべて提供するのは無論のこと，ソフトウェアのバリューストリームをサポートする他プラットフォームとの迅速な情報交換を実現する上でも，要件定義と要件管理ツールの進化が求められています。