PR

 ユーザーにヒアリングして要求を定義する---このやり方が正しいと思っている開発者は多いだろう。先日,要求開発入門コースの講師をしたときに,システム要求がなかなか獲得できない理由を参加者に聞いてみた。回答は以下のようなものである。なお,参加者はユーザー企業とシステム企業,半々に分かれていた。

  • ユーザーから聞き出したことがコロコロ変わる。
  • 要求を実現するための期間・コストに制約があり,満足してもらえるものができない。
  • 要求があいまいでどのように仕様化すればよいかが開発者に託され,見えなくなる。
  • 開発者が業務を理解していない。

 これらの意見はそれ自体,非常に興味深いが,一つだけ気になる共通点がある。それは,獲得した要求が正しいことを前提にしている点である。

 ユーザーから獲得したシステム要求の根拠はどこにあるのだろうか。その要求は本当に正しいのだろうか。もしユーザーから聞き出したシステム要求の根拠が,どうしようもない現状の業務処理の中で必要とされる要求だったらどうなるだろうか。また,ユーザーが,まったく独自のやり方で確立した業務処理に対してシステムの要求を出しているとしたらどうなるか。

 このような場合の問題は,現状業務のシステム化,あるいは,レア・ケースのシステム化につながることである。本当に正しい姿の業務をシステム化したことにはならないのだ。しかも,その後は,既にシステムがあるから正しい業務処理に変えることができないということになる。つまり,システムが不良財産化してしまうのである。

 これを解消するには,コタツモデルの中で,トップ,業務担当,システム担当の間に存在する壁を取り去り,企業戦略的視点と業務視点から出てくる業務問題の解決方法,およびIT化の視点からの業務イノベーションのアイデア,という3つの視点から創出されるアイデアを結合することで,本来のあるべき要求の姿を作りあげていく必要がある。そのために,分かりやすい形で可視化しなければならず,そこにビジネス・モデリングの必要性があるのだ。

 私が要求開発活動の中で改めて理解したのは,要求は一つの業務課題に対して幾通りも定義できることである。それだけに,現状(As Is)の業務オペレーションを基にシステム要求を出してしまうと,ユーザーにシステムという名の不良財産を背負わせてしまう危険につながることを痛感した。そして,そのような開発を行ってきた今までの自分を深く反省するようになった。

教訓
要求の根拠は業務オペレーションにある。その業務オペレーションに対してあるべき改善がなされているか,また業務オペレーション自体のビジネス価値がどの程度あるかを見抜くことで,要求の重要度を理解できる。

要求は新旧2つの業務モデルのギャップから導かれる

 皆さんは,モデルと要求の関係について考えたことがあるだろうか? 要求開発では,「要求は定義するものではなく,開発するものである」という宣言を根拠に,要求開発のための方法論を提供している。その方法論に定義されたモデルの定義法としては,「サービス構造」「プロセス構造」「情報構造」という3種類のモデル構造を推奨している。

 例えば,「サービス構造」では,ユースケースを使って,その会社あるいは部門が提供しているサービスを図式化する。また「プロセス構造」では,業務フローを使って,サービスを提供するための業務処理(業務オペレーション)を図式化する。さらに,「情報構造」では,サービスを提供するビジネスの中の重要な概念の関係を図式化する。これらのモデルは,「現状(As Is)業務」や「将来(To Be)業務」を可視化するためのものである。

 さて,ここからが本題となるが,これらの3種類のモデル定義と要求との関係はどこにあるのだろうか? モデルを書けば要求は自然と整理できるのだろうか?---当然のことながら答えはNOである。

 では,要求はどのようにして開発するのか? 要求は,現状業務をモデルなどによって理解した後で,将来業務をモデルに描いている最中に,両者のギャップから生まれるものである。つまり現状で実現できていないことのなかで,将来業務としてやるべきことを,試行錯誤の中で決定したところから,新業務の要求が決まってくる。そして,その業務要求の中から,コンピュータ・システムに任せる方が望ましいものが,システム要求として決まっていくのである。

 ここで注意すべきなのは,将来業務モデルを作成したからといって,要求が明確になるわけではないことだ。要求は要求として別に管理する必要があるのだ。もちろん,そうした管理すべき要求を,ユースケースのような図式化されたモデルとして管理することも可能だろう。しかし,要求開発では,そのような要求の図式化については,現在のところ推薦するモデルを提供していない。

 モデルを提供していない点については,特にこれといった理由はない。強いて言えば,業務要求の管理は図式化されたモデルよりもリスト形式の方が管理しやすいという単純な理由からくるものである。

教訓
将来業務モデルを作成したからといって,要求が明確になるわけではない。要求は要求として別に管理する必要がある。

モデルから抽出できない要求もある

 さて,先ほど現状業務と将来業務のギャップから要求を得ると述べた。その際に,現状業務と将来業務を可視化するためにモデルを利用することも述べた。では,業務やシステムの要求のすべてをこの方法によって抽出できるものなのだろうか?

 実は,これとは異なる経路で要求を得ることも多いのである。例えば,最初から企業の将来ビジョンとして描かれているビジネスの方向性にある要求などがそうである。また,次期システムにとって欠かせないビジネス的な狙いから来る要求などもそうである。これらは,特に将来業務モデルを描かないと見えてこないわけではない。モデルを描く前からほぼ決まっている(可視化されている)要求なのである。

 よって,このように最初から明確に分かっている要求は,モデルを描く前に,きちんと管理すべきものである。なぜなら,初めから可視化されているものは,改めて可視化しても,何も生み出さないことが多いからだ。加えて,初めから分かっている要求を見逃すと,後でモデルとしても描かれず要求としても出せなかった,ということになりかねない。要求はすべてモデルから抽出される,といった単純な世界など存在しないのである。

教訓
要求はすべてモデルから抽出されるという安易な考えはやめるべし。

要求は3つの状態をたどる

 要求開発では,要求を3つの状態で管理する。まず1つ目の状態は,「要望状態」である。これは,トップ,業務担当,IT担当から「AのためにBする」というように目的付きの要望として獲得するものである。

 次の状態は,「要求状態」である。これは,獲得した「要望」に対して要求開発チームで,要望の重複削除,類似要望の取りまとめなどの整理をした状態をいう。注意すべきは,この段階では,まだ正式に採用された要求ではなく,将来採用される可能性のある要求だということである。

 そして,最後の状態が「要件状態」である。これは,要求の中から新業務として採用が決定した業務要求とシステム要求のことをいう。つまり,期間とコストを十分考慮したうえで,要求を精査し採用された要求のことである。

 このように,要求をしっかりと管理していくことは要求開発において非常に重要なミッションとなっている。特に,将来必要な要求が「いつごろ必要になるのか」を管理していないプロジェクトになってはいけない。そのためにも,要望,要求,要件の管理はきっちりやっておくべきなのだ。

教訓
要求開発の要求は,状態も含めてしっかりと管理せよ。

(萩本 順三=要求開発アライアンス理事)