ユーザが行うべき業務要件定義
拙著「エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと」のご紹介がてら、システム開発を成功させるためのポイントをご紹介する本連載、第三回は要件定義についてです。
要件定義はシステム開発のキモ
システムにどんな機能や性能を持たせるか、使い勝手やセキュリティをどうするかということを決めるのがこの要件定義という工程です。この工程は通常、システム開発の一番最初の方に行いますので、ここで誤った要件を決め、それが後になって分かってしまうとプロジェクトは大打撃を受けます。それまでやってきた設計やプログラミング、テストなどを大幅にやり直しちゃうことになるわけですから大変です。またこの要件の間違いに気づかずにそのままシステムを作りきってしまうと、今度は作っても役に立たなかったり、使えたとしても投資効果が大きく減ってしまったり、使いづらくて不満爆発なんてことにもなりかねず、ある意味もっと重大な事態を招いてしまいます。実際、失敗したシステム開発プロジェクトのうち、およそ９割が要件定義になんらかの問題があったとする調査もあるほどですから、この要件定義はシステム開発の肝とも言える大切な作業になります。
大切なのは業務要件
さて、この要件定義についてその詳しい書き方は拙著や各種の専門書籍・文献に譲るとして、ここでは私が特に大事だなと思うポイントについてお話ししていきたいと思います特に、わたしはかつて裁判所で調停委員や専門委員を務めておりましたので、その関係で失敗プロジェクト、トラブルプロジェクトに関する事例を勉強する身でしたので、そんな数々の失敗例から学んだことから、大切だなと思うことをお話ししていきたいと思います。
拙著でも書いていますが、システム開発の要件(システム化要件)というのは「業務要件」と「システム要件」に大別されます。そして後者のシステム要件は更に「機能要件」と「非機能要件」に分かれます。
但し、この中でユーザつまりシステムを発注した側の人が必ず作らなければならないのは「業務要件」です。拙著の中でも述べていますが、システム化対象の業務とはどのようなもので、それをどう改善したいのか、またそれをどのような言葉で表現するのかということはユーザ自身で行わなければならず、仮にコンサルタントやＩＴベンダーの人が作ってくれたとしても、それはあくまで手伝いであり、責任は必ずユーザにあります。会社の業務と悩みを本当に知っているのはその会社の人間ですから当然といえば当然です。（拙著の中でも主人公のマサト君は、何度となくこうしたことを教えられます。)
逆にシステムにどのような機能や性能などを持たせるかという「システム要件」については、これをユーザが作っても良いですが、業務要件さえきちんとしていればＩＴの専門家であるベンダーさんが作ってくれますし、その方が後続の開発に有効でやりやすいものを作ってくれます。ユーザの役割は業務要件、ベンダーの役割はシステム要件以降としたほうが(無論、お互いに色々と助け合ったり、ダメ出しをすることもありますが)、役割分担がスッキリするかもしれません
業務要件定義の書き方
まず業務要件というのは、まずシステム化対象の業務がどんなことを行うのかを決めます。例えば、ＥＣサイトで商品を販売するという業務はインターネット上の顧客が商品を選択して注文を出すことに対応することですが、これを少し分解して行くことで業務要件を明らかにすることができます。分解とはどういうことでしょうか。方法はいくつかあるのですが、その一つはその業務に携わる人の一続きのアクション毎に区切るという方法を考えてみたいと思います。
ＥＣサイトで買い物をしてもらうには、まずＷＥＢサイト上に商品を紹介したり注文を行えるようにする画面を表示します。ということは「画面を作って表示する」という一連の動作が必要になるわけです。そしてこれを行うのを仮に販促部門が担当者だとすると”販促担当者が新規商品の情報を営業部から入手して販売画面を作成して表示する"という一連の動作を書き出すことになります。これが業務要件の最初の一行になります。続いての動作はどんなものでしょうか。おそらく"顧客がＷＥＢ上のカタログから商品を選択を選択して見積もりの依を出す"ということになるでしょうか。
ここで注意いただきたいのは、業務要件は普通の文章ではありますがその中に必ず必要なものがあるということです。それは「主語(動作する人)」、「入力情報」、「動作や判断」、「出力情報」と言った要素です。最初の一文にこれを当てはめると
主語：販促担当者
入力情報：新規商品の情報
動作・判断：ＷＥＢページの作成
出力情報：ＷＥＢページとその中の項目
と言った具合になるでしょう。システム設計をする際、開発者は必ず操作者・入力情報・論理演算・出力情報という形を意識して処理を組み立てていきます。ですから、要件定義の段階からこうした要素を意識して書いておくことは、後の開発ととても相性が良く設計ミスや要件不備を防止することになります。
さて、こんな風に考えていくと業務要件はも以下のようになっていきます。
販促担当者(主語)が新規商品の情報(入力情報)を営業部から入手して販売画面を作成(動作・判断)して商品名、説明、価格（出力情報）を表示する
顧客(主語)は、ＷＥＢページ(入力情報)から、欲しい商品を選択し、個数と納期を指定した上で(動作・判断)見積もり依頼を送る（出力情報）する
営業担当者(主語)は、国訳からの見積もり依頼（出力情報）に基づき、該当商品の値引き額を定め、在庫を調べた上で見積もりを作成し(動作・判断)、顧客に送信する
(以下略)
動作・判断と出力の区別など多少あいまいになりがちではありますが、要は何をするか、結果何ができるのかが明確に分かるように書けば良いとおもいます。いまは、これを箇条書きで書いていますが、もちろん、もっとわかりやすく図や表にしたり、ＵＭＬなどの規則に従ったフォーマットで書いてもかまいません。これを業務の最初から終わりまできちんと書き切ることができれば、とりあえず業務要件の幹はできあがりです。これ以外に業務量や操作者の数、業務時間など必要な情報はいくつもありますが、そのあたりは、システム要件を作るとき、ベンダーさんが色々と聞いてきますので、それに答えていけば良いと思います。
システム化対象外のところも書く
さて、拙著の中でもマサト君が注意されていますがこの業務要件には、必ずしもシステム化しない部分も書きます。というか、どこをシステム化するかはこの業務要件を書いてから考えても良いくらいです。例えば、上の業務要件の中で、”該当要件の価格の値引き額を定め”という部分は、人間がその場で判断する場合も多いので、システム化はしないかもしれません。また、"見積もりを作成し"のところもコンピュータが作るかもしれませんが、顧客のフォーマットに合わせるのであれば、システムでそれを作らせるより、顧客からフォーマットを貰って人間が作った方が早く、システム化が却って生産性を落とすことだってあるわけです。ですから良いシステムを作るのであれば、業務要件を書いた後、あるいは書きながら、システム化のメリット・デメリットを考慮してシステム化範囲を決めていくのが妥当というわけです。もっとも、企画段階(第一回参照)でシステム化範囲は決定済みという場合もあるでしょう。しかしそうした場合でもやはり、非システム化部分も業務要件には書いておきます。ここを書かないと例えばベンダーのような業務を知らない人が読んだとき、業務の流れを把握できず誤ったシステム要件定義をしたり、もしかしたら、やはりシステム化した方が良いという部分の提案ができなくなるからです。そもそも読みにくいですしね。
具体的なソフトウェアやサービスは後回し
それともう一つ、ここでは極力、実際に利用するソフトウェア、ハードウェアやクラウドサービスの名前は書きません。ここにセールスフォースとか、パワーＢＩ，ＡＷＳという名前が出てきてしまうと、それ自体が持つ機能、持っていない機能などに引っ張られて、本当に自分たちが実現したいシステムから離れて言ってしまうからです。このあたりは一旦、業務要件を定めてから、システム要件でじっくりと考えるのが良いでしょう。
正しいけど、正解じゃない？
目指せ”一つ上を行く要件定義者”
「正しいけど、正解じゃない」・・・目指せ”一つ上の要件定義者”
さて、ここまで業務要件定義のポイントについて書いてきました。拙著の主人公であるマサト君は、こうしたことを箇条書きせず、業務フローという形で書きました。操作者、入力、動作・判断、出力が分かるように書いており、書き方は違っても正しい業務要件定義を書いたのですが。。。しかし、そのフローは役員やエンドユーザからダメだしを受けます。なぜでしょうか？役員達は、フローを見て「正しいけれど正解じゃない」と禅問答のようなことを言います。その答えについては是非本書を読んでいただきたいと思うのですが、どうもマサト君には想像力が足りなかったようです。そして今、世の中で作られている業務要件や業務フローの多くも、このあたりが欠落しており、これのために結果として使われないシステムができてしまったり、要件が不完全で失敗するプロジェクトが多く発生しています。皆さんは、是非、そのあたりのことを学んで、「一つ上を行く要件定義者」を目指してみてください。(了)
参考 細川義洋著
「エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと」
