システムの企画プロセスにおいて、ユーザへのヒアリングは重要なインプットにはなるのだが、ここで得た要求をそのまま集めてまとめることが活動の目的だと考えるのは大いなる誤りである。今回は、こうした「ヒアリング&とりまとめ」アプローチについての問題点を指摘し、新たなアプローチを進言したい。

ユーザ企業のゴールは事業戦略の実現

企業がIT投資するのは、当然ながらシステムを作りたいからではなく、投資した以上のビジネス上のリターンを期待してのことである。ベンダー側から見ていると、システム開発自体をプロジェクトととらえがちだが、発注するユーザ企業側からすると、プロジェクト全体はおおよそ図1のようになっている。

図1: ユーザ企業から見るプロジェクト全体像

まず最初に自社の事業戦略をどうするのかの議論があって、結果として、ビジネス上の具体的な要求(例えば、「在庫を減らす」とか「納期を短縮する」など)が導かれ、それを実現するためにシステム要求が導かれてシステム開発に至るのである。システム開発・実運用の結果として、意図した事業戦略が実現したところでプロジェクトの完遂となる。

この一連の流れの中で「ビジネス要求をもとにシステム要求を導く」というところがシステム企画に該当し、この連載でも「要求開発」としてフォーカスしている領域である。ここで最も重要なのは「ビジネス要求」と「システム要求」のトレーサビリティであり、そのシステム要求を満たすことによってビジネス要求を実現できることをロジカルに担保することである。そこをはずすと、「システム要求は満たしたもののビジネス的には結局役に立たないシステム」として、IT投資を無駄にしたことになるのである。

"要求開発"という考え方

世のプロジェクトでは、この過程を明確に意識せずに「要件定義」としてシステム開発の前座のように扱うことも多いようだが、筆者らはこの過程での活動をあえて、「要求開発」と呼ぶようにしている。

「要件定義」というと、ユーザがシステム要求についての答えをもっていて、それを聞き取ってとりまとめる「ヒアリング&とりまとめ」のような作業をイメージしてしまう。先に述べたように最近のシステムは組織横断的であり、営業から配送までの一連の業務など広範囲での最適化を目指さなければならない。それに対してヒアリング対象となる担当者は、実際のところ「自部署についてはわかるが隣の部署になると何をしているかわからない」という状況が普通であり、全体の業務を熟知した上で最適化を考えたシステム要求を語ってくれると期待するのには無理がある。

また、仮に業務の状況がわかっていたとしても、その担当者が出してきた「システム要求」が、せいぜい「○○の機能があれば、きっとXXが実現するだろう」という程度の直感的ロジックによるものならば、上位目的とする「ビジネス要求」の実現につながるものかどうかは疑わしい。

そのように特定のユーザがいきなり出してきたシステム要求は、そのユーザの視野の範囲の業務理解が前提であり、かつ、その担当者の暗黙的ロジックに基づいているということから「属人的、かつ、直観的である」と言わざるを得ない。つまり、違う人に聞けば違う要求になり、同じ人でも違う時に聞けば違う要求になるかもしれないということである。

そのような場当たり的要求を正としてシステムを作ると、「確かに手元は楽になったが、およそ全体最適には貢献しないシステム」になってしまいかねない。読者の中にも「ユーザの言った通り作ったが役に立たなかった」というシステムの経験をお持ちの方は多いのではないだろうか。

担当者の話は、つなぎ合わせてこそ意味がある

ヒアリングは重要な情報収集活動であるし、その過程でユーザの要求を聞くこともまた必要なことなのだが、そこで得なければならないのは、ユーザが作った答えそのものではなく、なぜそのような要求が生まれたのか、その背景にある業務の姿である。

「○○機能が必要」という要求は、突き詰めるとその機能がないために「XXができていない」という業務上の課題の裏返しであり、それを少し構造的に分析すると、プロジェクトで解決すべき課題として絞り込むことができるはずである。そもそもの「ビジネス要求」に関連した要求として語られているならば、課題は「ビジネス要求」の阻害要因ととらえることができる。例えば、「納期の短縮」という大元のビジネス要求に対して、どこかのプロセスがネックになっていて、よって、「○○機能が必要」というような要求が出ているとかである。

一連の業務のそれぞれに関わる担当者の話をつなぎ合わせることによって、はじめて業務の全貌が見えてくる。その際に、前回説明したようにユーザの話をモデル化できれば、これらをまとめた全体地図なるモデルを構築することができるだろう。それによってやっと「全体がどうなっていて、その中でどこに問題があって、どのような手を打つことでそれが改善されるのか」といった理屈による問題解決の世界にことを持ち込むことができるのである。個々の担当者が語っていた要求もそれが全体から見ても取り組むべき課題にまつわるものなのかどうか判断がつくようになる。

業務モデリングの目的として、一般的には、「業務を整理し、理解する」ということになるのだが、ここでの使い方としては、「業務の全体構造を見える化し、そこで現状の業務(As-Is)において課題となっている箇所を特定、それを解決する業務(To-Be)を再設計して、モデル上で課題が解決されることを検証する」ということになる。

業務フローの最適な粒度とは

よく業務フローで議論になるのが、「どの程度の粒度で描くか」とか、「例外的なフローをどこまで描くのか」といったことであるが、上記の目的に照らすとその指針は明らかで、「As-Isでの課題箇所がわかり、それが、To-Beとしては解決される、ということがモデル上で見える」レベルで描けばいいということになる。

ただし、課題は業務フローにだけ現れるわけではない。紙面の都合で詳細は割愛するが、筆者は、業務を(1)サービスモデル(ビジネスユースケース)、(2)プロセスモデル(業務フロー)、(3)情報モデル(概念モデル)、(4)ルールモデル(ビジネスルール)の4つでとらえることとし、課題はこのいずれかのモデル上に出現すると考えている。

机上(これら4つのモデル上)で課題を解消する業務が再設計できたら、それが現場で本当に対応可能なのかを検証した上で、これをサポートするためのシステム機能を定めればいい。このような手順に則ることで、ビジネス要求を満たすシステムであることをロジカルに検証したことになる。

*　　*　　*

筆者らは、ともすれば人系に頼ったやり方になってしまいがちな企画プロセスに対して、エンジニアリングを適用して、ロジカルかつ能動的にシステム要求を作っていくことの必要性を主張し、この活動を「要求開発」とよんでいる。

ユーザが望んでいるからといって、いきなり正解を聞いたかのようにその要求を鵜呑みにしていたのでは、本来の目的である「ビジネス要求」を実現することは難しい。企業がITをより戦略的に活用しようとする中で、ユーザの言ったとおりにしか動けない指示待ちのシステム屋への評価はどんどん厳しくなってきている。

現在、もし「ヒアリング&とりまとめ」アプローチで仕事をしておられるならば、早く「要求開発」アプローチに転換されることをお勧めする。ここでのメッセージは「要求は在るものではなく、開発するものである」ということである。