はじめに

さて、SaaS導入のプロジェクト管理のあり方を考えるコラムも最終回となりました。最終回の今回は、特にシステム機能の要件定義（＝要求定義　※当コラム内では要件定義と要求定義の区別を特にせず、同じ意味として捉えます）のあり方について考えてみたいと思います。

BABOKにおける要件定義

まず最初に、そもそも要件定義とはなにか？を考えてみましょう。
ここでは、BABOK（「Business Analysis Body Of Knowledge）を参考に要件定義とは何かを考えてみましょう。BABOKはカナダの「IIBA（International Institute of Business Analysis）」という団体においてまとめられた知識体系で、2008年12月には日本支部も設立されました。

BABIKでは、システム開発の上流工程の初期フェーズに於いてどのようなシステムや機能が必要なのかという「真に有用な機能を明確にしていく作業」に焦点を当てて体系化されています。

※BABOKについて、詳しくはこちらをご参照ください → http://www.iiba-japan.org/topics.php

BABOKにおけるビジネスアナリシスとは、ユーザーが真に必要としているシステム機能を、業務の担当者や関係者と一緒に各業務が現状の姿になっている背景から掘り起こし、明確化していく作業のことを指します。

つまり、真に必要な機能が実装されているシステムを作り上げるためには、ユーザーの現行業務プロセスとその内容をまずきちんと把握した上で、発生している問題や課題、ニーズといった「業務要件」をしっかりと理解し、ユーザーが本当に必要としている機能はなんなのか？を明らかにする必要があります。この要求定義のプロセスが上手くいかないと、見た目上の使い勝手やちょっとした便利機能ばかりが実装されることになってしまい、システム全体としては投資対効果の上がらず、経営の役に立たないものとなってしまいます。

BABOKが策定された背景には、システムを使いたい側（ユーザー側）は本当に必要としているシステムの機能や姿を説明できないし、一方でシステムを作る側（ベンダー側）はユーザーが本当に必要としているシステムの機能や姿を把握できず明確化できない、という問題意識がベースにあります。 これまで多くのシステム開発現場で行われて来た要件定義では、この明確化のプロセスが不十分であり、開発者と顧客の双方で本当に必要なシステムを不明確にしたままスケジュールの都合上、「細かい要件は次フェーズで決める！」などとして要求定義作業を不完全なままプロジェクトを進めてしまうと、結果として"真に必要とする機能が実装されていないシステム（＝使えないシステム）"ができ上がってしまうことになります。

要件定義は誰がすべきか？

少しBABOKの話がながくなってしまいましたが、要は、ユーザー側もベンダー側もシステムで真に開発すべき機能を明確化する作業に慣れておらず、要求定義段階で間違ったものを定義すると、いくらシステム開発自体がうまくいったとしても、利用開始後の評価としては「失敗プロジェクト」となるということになります。

とはいえ、システムのプロフェッショナルでないユーザー側に真に必要な機能を示してくれるように要求することには無理がありますし、もともとシステム開発のプロフェッショナルであるベンダー側にも急に要求定義の高い能力を求める、というのも現実的ではないでしょう。

そうした部分の課題を解決すべき存在としてコンサルタントがいるかと思うのですが、コンサルタントの方もシステムに習熟しているコンサルタントばかりとは限らないのが厄介なところです。（本来、コンサルタントは経営ツールとしての情報システムに習熟しているべきと個人的には思いますが……）

実際のシステム開発現場に於いて、理論的に要件定義を誰がすべきという議論は横に置いて、現実的にはいずれのプレーヤーも要求定義を厳密にするのはもともと無理だと割り切って、むしろ真に必要なシステム機能を洗い出す方法論に焦点を当てるべきだと思います。

そうした３つのプレーヤーの立場の乖離やスキルギャップを取り持ちつつ、必要とされているシステムを構築するために有効だと考えられる方法論として、実際のシステム（画面）を見ながら要件定義に関する議論を進めてゆくスパイラル開発があると言えます。

実際に目に見えるものを共通の議論の土台にして、「何か必要か？」や「これからの業務をどう実施するか」に力点を置いてシステムの要求機能を洗い出してゆくスタンスになります。

この方法は、大規模システムには向きづらいと思われますが、一方で中堅・中小企業向けのシステム開発についてはリスクの少ない開発手法として適用することが非常に有効だと考えられます。

なぜ画面を見ながら要件定義することが有効なのか？

なぜ、画面を見ながら要件定義することが有効なのでしょうか？通常の要件定義と何が違うのでしょうか？
それは、具体性の違いです。通常の要件定義は机上で抽象的な議論をしながら要件を決めてゆきます。最後は情報システムという実体を持ったものを作り出すのですが、その最初の段階としての要件定義は、いわばゼロの状態です。大袈裟に言えば、これまでのシステム開発は、都度「無」の状態から「有」を作り出していたことになります。作る側としては、こうした謂わば芸術にも似たプロセスにものを作る喜びを感じることができていたと言える面はあると思いますが（私自身も、その喜びを感じてきた一人です）、しかし、芸術家が作品ができてみるまで何ができるか分からないとの同じように、システム開発においてもなにができるか分からない、といった面を包含していたことになります。これは、ユーザー側（発注側）にとっては、間違いなくリスクになります。

一方、SaaSによるスパイラル開発では、ものすごく良いものができることは期待できない反面、すでに具体的な動くものが目の前にあるため、導入後のイメージもしやすく、またなによりある日突然画面をみせられて、「こんなのが欲しいんじゃなかった」といったことが起こるリスクを回避することができます。

既にある程度動作するものが目の前にあり、立場の違うメンバー同士が同じ土台に乗って要件定義の議論を進めることができる。この点がまさにシステム開発のリスク軽減と投資対効果の向上に寄与する点です。

最後に

これまで３回に渡りSaaSにおけるシステム開発と従来のシステム開発の違いを見てきました。
個人的には、スクラッチ開発は、個別ニーズが高く、またその投資に耐えられる規模の企業にとって今後も有効な開発手法であり続けると思いますが、一方で中小企業を中心として、これまで適正な投資範囲である程度のニーズを満たすソリューションが提供されていなかったセグメントに対してはSaaSが非常に有効なソリューションとなり得る、と考えています。

リーマンショック以降、企業は規模の大小を問わず投資対効果をシビアに見るようになってきており、その傾向はシステム開発（導入）投資にも同様の傾向が強まっていると感じています。もともと、情報システムは企業の競争力を高めることに寄与すべきツールである筈ですので、この流れは当然のことだと思います。

スクラッチ開発にしろSaaSにしろ、その特徴を良く見極めた上で導入し、システムを利用するユーザー企業の競争力向上に少しでも寄与できるケースが増えることを願ってやみません。