「ちゃんと確認したはずなのに、なぜ漏れる？」――要件定義で「抜け漏れ」が起きる本当の理由

　こんにちは。M's Business Tools（MBT）です。
　前回は、システム開発でよく聞く「ちょっとした変更」が、なぜ思った以上に大きな影響を与えるのかについて書きました。
　今回は、その少し手前の話です。
　システム導入の打ち合わせで、何度も確認した。
　現場にも聞いた。
　ベンダーとも打ち合わせをした。
　それなのに、システムができてから言われます。
　「あれ？ これってできないんですか？」
　担当者からすれば、
　「そんな話、聞いていない」
　ベンダーからすれば、
　「要件には入っていません」
　現場からすれば、
　「できて当然だと思っていた」
　誰かが手を抜いたわけでもありません。
　それでも、抜け漏れは起こります。
　なぜでしょうか。
　今回は、要件定義で「抜け漏れ」が起きる本当の理由について考えてみます。

■「ちゃんと聞いた」だけでは、要件は揃わない

　要件定義というと、
　「現場の要望を聞く」
ことだと思われがちです。
　もちろん、現場の話を聞くことは重要です。
　しかし、
　「何が欲しいですか？」
と聞くだけでは、必要な要件はなかなか出てきません。
　なぜなら、現場の人は普段の仕事をすべて言葉にしているわけではないからです。
　例えば、毎日行っている売上登録。
　担当者に聞けば、
「売上を入力できれば大丈夫です」
と言うかもしれません。
　でも実際の業務では、
・入力を間違えたら修正する
・注文が取り消されたら削除する
・月末を過ぎたデータは勝手に変更できない
・管理者だけが修正できる項目がある
・変更した場合は履歴を残す
といったルールが存在するかもしれません。
　現場の人にとっては、どれも「いつもやっている当たり前のこと」です。
　だから、わざわざ説明しない。
　ここに抜け漏れの入口があります。

■悪い例：「売上を登録できるようにしてください」

　例えば、新しいシステムについて現場からこんな要望が出たとします。
　「売上を登録できるようにしてください」
　担当者は要件定義書に、
　「売上情報を登録できること」
と書きました。
　ベンダーもその要件を確認し、売上登録画面を作りました。
　商品、数量、単価を入力して「登録」を押せば、きちんと売上が登録されます。
　要件どおりです。
　ところが運用を始めると、現場から声が上がります。
　「入力を間違えたときは、どうやって直すんですか？」
　修正機能を追加します。
　すると次に、
　「先月の売上まで誰でも直せるのは困ります」
という話が出ます。
　さらに、
　「誰が数字を変えたのか分からないと困ります」
という話まで出てきます。
　そこで、
　修正権限を追加する。
　締め処理を追加する。
　変更履歴を追加する。
　結果として追加開発が発生します。

■なぜダメだったのか

　最初の要件、
　「売上情報を登録できること」
　そのものが間違っていたわけではありません。
　問題は、
　「登録する」という一つの動作しか見ていなかったこと
です。
　実際の業務には、
　登録する
　↓
　確認する
　↓
　間違いに気づく
　↓
　修正する
　↓
　場合によっては取り消す
　↓
　締める
　↓
　後から確認する
という流れがあります。
　さらに、
誰ができるのか。
いつまでできるのか。
できない場合はどうするのか。
変更した事実を残すのか。
という条件があります。
　つまり、要件定義で必要なのは、
　「何をしたいですか？」と聞くだけではありません。
　その前後に何が起きるのかまで考える必要があります。

■改善例：「できること」だけでなく「条件」まで確認する

　同じ売上登録でも、確認の仕方を変えてみます。
　「売上を登録した後、修正することはありますか？」
　「あります」
　「いつまで修正できますか？」
　「当月分なら担当者が直します。でも締めた後は勝手に変えられると困ります」
　「締め後に修正が必要になった場合は？」
　「管理者に頼みます」
　「変更した記録は必要ですか？」
　「誰がいつ変更したのか分かるようにしてほしいです」
　ここまで聞けば、要件は例えば次のように変わります。
　・担当者は締め処理前の売上情報を修正できること
　・締め処理後の修正は管理者権限を必要とすること
　・変更日時、変更者、変更前後の内容を履歴として保持すること
　最初の、
　「売上情報を登録できること」
だけとは、かなり違います。
　これならベンダーも、何を作ればよいのか具体的に判断できます。

■抜け漏れの原因は「確認不足」とは限らない

　こうした問題が起きると、
　「もっと現場に確認しておけばよかった」
と言われます。
　しかし私は、単純な「確認不足」だけが原因ではないと考えています。
　何度打ち合わせを増やしても、
　同じ聞き方を繰り返しているだけなら、同じことしか出てきません。
　大切なのは回数ではなく、
　「どの観点から確認するか」
です。
　例えば、
　誰が使うのか。
　いつ使うのか。
　何を入力するのか。
　間違えたらどうするのか。
　通常どおり進まなかったらどうするのか。
　誰が変更できるのか。
　後から何を確認する必要があるのか。
　こうした観点を持って質問すると、現場自身も意識していなかった業務ルールが見えてきます。

■「言わなくても分かる」が一番危ない

　要件定義で怖い言葉の一つが、
　「それくらい、言わなくても分かるでしょう」
です。
　現場では当たり前。
　社内では当たり前。
　今のシステムでは当たり前。
　しかし、新しいシステムを作るベンダーにとって、それが当たり前とは限りません。
　逆にベンダー側にも、
　「一般的にはこうするものです」
という当たり前があります。
　この「当たり前」と「当たり前」のズレが、完成後に初めて表面化します。
　だからこそ要件定義では、
　当たり前を言葉にする
ことが重要になります。

■要件定義は「要望を集める仕事」ではない

　私は、要件定義を単に、
　「現場から要望を集めて、一覧にする作業」
とは考えていません。　
　現場の言葉の中から、
　何が本当に必要なのか。
　どんな条件があるのか。
　例外はないのか。
　誰がどこまでできるのか。
　それらを一つずつ確認して、
　「作れる条件」に変えていく。
　それが要件定義の重要な役割です。
　「こんな機能が欲しい」
から一歩踏み込んで、
　「誰が、いつ、どんな条件で、何ができればよいのか」
まで考える。
　それだけでも、抜け漏れはかなり減らせます。

■抜け漏れを防ぐのは「注意力」ではなく「観点」

　要件定義の担当者が、すべての業務を頭の中だけで漏れなく確認するのは簡単ではありません。
　経験豊富な担当者でも、見落とすことはあります。
　だから私は、
　「もっと注意する」ことだけに頼らない
ことが大切だと考えています。
　必要なのは、
　確認するための「観点」を持つこと。
　観点が整理されていれば、
　「修正は？」
　「例外は？」
　「権限は？」
　「履歴は？」
と、次に確認すべきことが見えてきます。
　要件定義の抜け漏れを防ぐのは、担当者の記憶力や注意力だけではありません。
　抜けないための「型」を持っているかどうか。
　ここが大きな違いになります。

■次回は「5つの視点」に整理します

　今回は、
　要件定義で抜け漏れが起きるのは、確認回数が少ないからではなく、「確認する観点」が不足していることが大きな原因
という話をしました。
　では、実際の要件定義では、どんな観点から確認すればよいのでしょうか。
　次回は、
「誰が使うか」だけでは足りない
――要件定義で確認すべき5つの視点
として、
　「人・業務・データ・例外・運用」
の5つに分けて考えてみます。
　要件定義の打ち合わせで、そのまま使える形にして紹介する予定です。
　最後までお読みいただき、ありがとうございました。
　M's Business Tools（MBT）では、中小企業のDX・業務整理・システム導入を、現場の視点から分かりやすくお伝えしています。

▶ MBT 中小企業DX支援オフィス

M's Business Tools（MBT）中小企業DX支援オフィス