システム開発プロジェクトでユーザーから要望を聞くとき、その目的を確認したうえで、それを実現するためのより良い解決策を考える。要件定義を担当するSEは、この思考法を習慣化すべきだ――。

 2015年4月20日の本欄「ユーザーに遠慮するSEはバカになる」で、このことを指摘した。

 上記の記事ではあえて上から目線で書いたが、ユーザーからの要望の目的を確認し、より良い解決策を考えるのは容易でない。このことを、記者は経験的に知っている。かつてシステムインテグレータの社内研修に参加させてもらい、要求分析の基礎トレーニングを受けた際、懇意にしていた講師から「(要件定義の記事を書いているので)もうちょっとできると思っていましたが…」と渋面を作られた経験がある。

 要件定義の思考法は、手順を理解したつもりでも、実際にやると難しい。しかも、緻密な思考が求められ、かなり面倒だ。これをただちに習慣化せよというのは、いささか乱暴だったかもしれない。反省し、出来の悪い記者が自分でやってみようと思う。

要望の目的を確認したうえで解決策を考える手順

 要件定義のエキスパートである、日立コンサルティングの水田哲郎氏(マネージングディレクター)によると、ざっくりとした手順は次のようなものだ。

 まず、ユーザーから要望を聞いたら、「経営」「業務」「仕組み」「システム」という四つのレベルのどれに該当するかを考える。経営レベルとは、売り上げ、コスト、利益の改善、事業継続に関するもの。業務レベルは、業務の品質、生産性、スピードの改善に関するもの。仕組みレベルは、新しい業務を構成する業務プロセスや制度・ルールなどに関するもの。システムレベルは、システムの具体的な機能、画面、基盤に関するものだ。

 四つのうち経営が最上層で、システムが最下層。各層の要望は一つ下位層の目的に該当する。具体的には、システムレベルの要望の目的は仕組みレベルの要望に当たる。同様に、仕組みレベルの要望の目的は、業務レベルの要望。その目的は、経営レベルの要望だ。

 例えば販売管理システムの開発で、「受注内容のエントリー時に顧客企業ごとの受注限度額を超えたことを知らせるアラーム機能が欲しい」という要望があったなら、それはシステムレベルだ。次の手順として、ここから経営レベルの要望に達するまで(場合によっては業務レベルまで)、目的を考えていく。

 システムレベルの要望の目的(仕組みレベルの要望)は「アラームが出たときに、受注処理を行えないようにする」。その目的(業務レベルの要望)は「事前の申請・承認がない場合には、限度額を超えて受注しないようにする」。その目的(経営レベルの要望)は「代金の未回収を防止し、コスト増加を抑制する」という具合だ。

 こうして経営レベルの要望を確認したうえで改めて定義する。例えば「売り上げの減少や得意先からの信用低下を起こさずに代金の未回収を防止する」のようなものだ。これを起点に解決策(仕組みレベルまたはシステムレベル)を考える。