最終回の今回は、「要求開発」のシフトフェーズを取り上げます（図1）。
シフトフェーズは、要求開発からシステム開発への橋渡しをするフェーズです。デザインフェーズで定めた新業務をもとに、システムが担うべき役割をシステム要求として定義していきます。デザインフェーズまでは、業務を中心に検討を進めてきましたが、シフトフェーズでは、システムへと視点を移して作業が行われることになります。このフェーズの成果物は、RFP（Request For Proposal:提案依頼書）やシステム化構想書、要件定義書などになります。
シフトフェーズで押さえておくべき勘所
本連載の「第1回 BA/BABOKが注目される背景と「要求開発」が必要な理由」で、要求開発のベースには要求開発方法論「オープンソロジー」があり、それをまとめたものが書籍「要求開発」であると紹介しました。
シフトフェーズに関して、書籍「要求開発」には、「『システムToBeモデリング』『IT基本要求定義』『システム移行計画作成』という活動を通じて、システム移行計画書またはRFPを作成する」とあります。
しかし、シフトフェーズで何をどこまで記載するかや使用する成果物のフォーマットといった具体的な部分までは言及されておらず、成果物についての例示はシステム移行計画書の目次例を記載するにとどまっています。システム要求定義の実際の進め方については、それぞれのプロジェクトに委ねられているのです。
筆者は、要求開発分野のコンサルタントとしてRFP作成や標準プロセス策定など、システム化の超上流工程に多く携わっています。ここでは、要求開発のシフトフェーズを補完する意味で、実際のプロジェクトにおける筆者の経験を踏まえて、この段階で押さえておくべき勘所について説明しておきましょう。
シフトフェーズでは、（1）システムの基本要求を定義する、（2）定義されたシステム要求を最終成果物として文書化する---という2つのことを行います。
システムへの基本要求を定義・文書化する上で注意しなければいけないことは、システム開発に必要な情報を、過不足なく定義するという点です。不足なくというだけでなく、無駄なドキュメントを作成しないということも大切なポイントです。
では、何をどこまで定義すればよいのでしょうか？
システムへの基本要求を定義する目的は、見積もり担当者や開発者といった後工程を担当する第三者に、要求を正確に伝えることにあります。このため、システムの利用者側の視点に立ち、システムで何を実現したいのかを伝えることが、最も重要です（図2）。
システムへの要求を記載する際に、利用者側の視点と開発者側の視点が混在すると、分かりにくいものになります。どのようにシステムを実現するかという実装面について記述しがちですが、それは開発者側の視点です。
ただし、新たに開発するシステムと既存システムを連携するケースでは、機能要件の一つとして、既存システムとのインタフェースといった実装面の情報を示すことも必要になります。
仕事がらRFPや要件定義書を見る機会は多いのですが、中途半端にシステム内部の実装に踏み込んで記載したものが多く見受けられます。システムへの基本要求の定義では、利用者の視点から、システムへの要求を記載することと、作成する文書の目的を考え、書き過ぎないということがポイントです。
それでは、システムへの基本要求をどのように定義していくのか、ケーススタディで見ていきましょう。
