第7回　確認の一手間と理論武装で、推論や日和見主義によるエラーを排除する

前回まで、ヒューマンエラーを引き起こす原因について人間工学と認知心理学の見地から解説した今回はそれらを踏まえ、要求仕様書作成時に発生するヒューマンエラーの具体例と解決策を解説する。

要求仕様書作成時に発生するヒューマンエラーは、「要求のとらえ方を間違える」「達成手段を間違える」「要求のとらえ方と達成手段の両方を間違える」という3つのパターンに分けられる。

まず、要求のとらえ方を間違える大きな要因を3つ挙げる。「誤解」「感情の介入」「推論の間違い」だ（図1）。1つめの「誤解」は文字通り、要求者の言葉や文章を、まったく別の意味と取り違えてしまうことである。

図1　問題のとらえ方を間違える3つの要因

一例を挙げよう。フィリピンの首都マニラ市でのことである。ある商社に勤務する駐在員の奥さんがいた。近所に似たような境遇の奥さんがいて、2人は仲がよかった。ある日、青森から送られてきたというリンゴを友人が持ってきた。2人で食べようということらしい。そこでこの奥さん、お手伝いさんを呼んでこう頼んだ。「リンゴの皮をむいて持ってきて」。そのお手伝いさんはフィリピン人だが、日本語による日常会話にはほとんど問題がない。しかし、この時は首をかしげながらキッチンに入っていった。

その後、おしゃべりにふけっていた奥さんと友人は、お手伝いさんが持ってきた皿を見て仰天した。皿にはリンゴの皮が乗っていた（図2）。奥さんと友人は顔を見合わせて大笑いしたそうだ。しかしこの話、笑えない。

図2　相手の要求を誤解する例

確かに奥さんの要求は、「リンゴの皮を持ってこい」と言っているようにも取れる。とは言え、わざわざ「リンゴの皮をむいて中身を持ってきて」とは普通、言わないだろう。

ある人が当然と考えて要求を説明しているつもりが、相手は思いもかけない誤解をすることは、この例に限らず枚挙にいとまがない。日常生活にも、こうした行き違いの危険が潜んでいる。

ましてや、要求仕様をめぐる打ち合わせでは、業界特有の専門用語が飛び交うもの。よほど業務に精通した人でない限り、話についていくことさえままならないこともある。そうした場での誤解を防ぐには、前もって業界用語集を作成しておき、要求者に確認してもらうなどの対策が必要である。

加えて、自らの知識や概念に基づいて言葉や文章を解釈していく「トップダウン処理」ではなく、与えられた情報をより上位の概念に抽象化しながら解釈する「ボトムアップ処理」を意識する。簡単に言えば、どんなに自明に思える要求であっても、別の表現に変えて再確認する慎重さを持つことである。面倒に思うかもしれないが、こうした思考の癖をつけることにより、要求者が抱いているイメージや意図と自分の理解とのギャップに早期に気づける。

推論は間違いの元

要求仕様を作成する際、要求者の役職や年齢などで、その発言の重要性を判断していないだろうか。「この人は職位が高いから、信頼できる発言をしている」「ベテランだから正しい情報を与えてくれるはず」というような判断である。反対に、経験の浅い部下の発言を聞き流してしまうこともあるのではないだろうか。こうした感情の介入も、要求を正しくとらえる妨げになる。人間は、自らの感情が介入すると、物事を客観的に見られなくなり、冷静に情報を処理できなくなるからだ。

個人の感情が介入することによる情報の欠落を防ぐには、ブレーンストーミングやマインドマップといった発想技法が有効である（これらの技法については、回を改めて詳しく述べる）。

人間の短期記憶が平均7つの情報しか保持できないのは、前回述べた通りである。短期記憶の限界容量を超えた情報がやり取りされると、情報の一部が欠落し、欠落した情報は推論によって変容してしまいやすい。

しかし、要求仕様を作成する段階での打ち合わせでは、7つを優に超えた量の情報が飛び交う。このような場で、どうすれば推論による事実の変容を防げるだろうか。シンプルに考えよう。処理しきれなかった情報を再度確認すればよい。打ち合わせ時に取り交わした事案について議事録を作成し、発言者に内容を確認してもらう、会話を録音しておく、などの対策が有効である。

より根本的な対策としては、推論する余地を極力なくすことである。それには、要求仕様の抽出に多くの時間を割くことが不可欠だ。なぜなら、要求抽出の時間が短いと、本来確認すべき情報の確認漏れが生じたり、要求を多角的に分析する余裕がなくなり、確認できていない部分を推論で補ってしまう危険性が高まるからである。要求者の協力を仰ぎ、要求仕様の抽出にはできるだけ多くの時間を当てよう。

推論による要求仕様の誤りを減らすには、打ち合わせの参加人数にも気をつける。多人数で打ち合わせを行うと情報に一貫性がなくなるうえ、やり取りされる情報量がさらに多くなりがち。このため、多人数での打ち合わせを避け、少人数での打ち合わせを何回かに分けて実施することが望ましい。

日和見主義が解決策を埋没させる

次に、解決策を間違えることで要求仕様書にエラーが生じるパターンについて述べる。このパターンのおもな原因は、「偏見」「慣れ・経験」「日和見主義」の3つである（図3）。

図3　問題の解決策を間違える3つの要因

偏見は、誤った判断を誘発する。皆さん、こんな経験はないだろうか。あるメーカーの冷蔵庫を購入したら、使い始めて間もなく壊れてしまい、不愉快な思いをした。このため、もう二度とこのメーカーの製品は購入しないことにした─。不良品はそのメーカーだけにあるわけではない。他メーカーの製品でも同様の現象が起きた可能性はあるのに、「このメーカーはだめだ」と思い込んでしまう。こうした偏見は、不合理な行動につながる。そのメーカーがどんなに優れた製品を開発しても、明らかに性能が劣る他社製品を購入するといった選択をしてしまうのだ。

システム開発でも同じことが言える。例えば、ある製品やプログラム言語などを使用したプロジェクトでトラブルが頻発した経験があると、その製品やプログラム言語を二度と使用しないといった判断をしてしまうのだ。その製品やプログラム言語について統計的なデータを収集し、リスクを判断しているのであればよい。しかし、個人的な経験からくる偏見だけで物事を判断すると、効率的な解決策を見逃してしまうことになりかねない。

偏見を持つまでには至らなくても、人間には経験によって頭が固くなっていくという厄介な特性がある。慣れ・経験が、新しい発想やひらめきを阻害してしまうのだ。確かに、過去に成功した解決策を選択することには、リスクを抑えたり、システム開発をスムーズに進める効果を期待できる。しかし、以前経験したプロジェクトの解決策が、現在のプロジェクトにとって最適解であるとは限らない。

要求を満たすための解決策は、要求者が置かれたその時々の立場や環境など全体的な状況を加味した上で選択すべきである。偏見を排除しつつ新たな発想を促すには、先に挙げたブレーンストーミングやマインドマップといった発想技法が有効である。

メンバーが自分とは異なる見解で一致すると不安になり、考えを曲げてしまうことはないだろうか。あるいは、「他の人に同意していればその場を楽に乗り切れるから」と、安易に妥協してしまうことはないだろうか。

これを日和見主義と言う。付和雷同とも言う。いずれも主体的にものを考えることのない人間を指す言葉である。こうした人間の同調特性、いわば「右へならえ」「長いものには巻かれろ」という姿勢は、よい意見や解決策を埋もれさせてしまう。

日和見主義に陥らないための対策は、理論武装して自らの意見に説得力を持たせること、そして自らのモチベーションを高めて安易に妥協しない姿勢を持つことである。

打ち合わせは少人数で

要求仕様書にエラーが生じた際にその原因を突き詰めると、要求のとらえ方と達成手段の両方を間違えていることがある。その背後には、「集団思考」や「目的と手段の取り違え」があることが多い（図4）。

図4　問題のとらえ方と解決策の両方を間違える3つの要因

要求仕様を作成する際、検討期間が短いにもかかわらず楽観的な考えが蔓延し、現状抱えている個々の問題を放置したり、誰かの鶴の一声でその解決策を採用したりしてしまうようなケースが散見される。その結果、何も検討されないまま貴重な時間が過ぎ去ってしまうか、もしくは明らかに現実的ではない決定がされてしまう。これらは、集団思考に陥っている組織で発生しがちな問題である。

こうした問題を防ぐ対策としては、マネジャーやリーダーがチーム内の雰囲気やメンバーの発言に常に注意を払い、集団思考の兆候がないかチェックすることだ。前回、「集団思考の状況」として挙げた8つの項目を、チームの現状と照らし合わせてみるとよいだろう。また、多人数での打ち合わせはできるだけ避け、少人数での打ち合わせを何回かに行う。これも、集団思考を回避する有効な手段である。

目的と手段を混同するべからず

システム開発にまつわるドキュメントは、100種類以上ある。それらの1つひとつに作成する目的がある。

ところが、である。そうした目的を明確に定義できるシステム担当者は意外に少ない。例えば、「システム化企画書の目的は何か」と尋ねると、こんな答えが返ってくる。「経営上のコスト削減」。それは経営がとるべき手段であり、システム化企画書の目的ではない。そう言うと今度は、「経営者の承認を得ること」「開発すべきシステムの概要を明らかにすること」と返ってくる。残念ながら、それらはすべてシステム化企画書の内容を実現させるための手段である。正解は、「システム開発に着手できるようにすること」である。

目的と手段をはき違えたらどうなるか。もし、経営者の承認を得ることが目的化されれば、企画書の内容はどのようなものでもよく、経営者が承認すればこの目的は達成されることになる。果たして、これで役に立つシステムを完成させられるだろうか。

要求仕様書についても、同じことが言える。目的を明確に定義せず要求仕様書の作成に着手しては、要求や解決策を正確にとらえられない。結果的に、仕様漏れによる手戻りや納期遅延といったトラブルが発生してしまう。

では、改めて要求仕様書の目的は何かとシステム担当者に問う。そうすると、再びとんちんかんな答えが返ってくる。いわく、「ユーザーのニーズを整理するため」「RFP作成の基本資料とするため」などなど。前者は要求仕様書を作成するための手段である。後者に至っては、要求仕様書の使われ方であって目的ではない。

目的と手段を取り違えてしまう原因は、日ごろからそのような思考訓練をしていないということに尽きる。システム担当者は、「何のために」を常に考える訓練をしてほしい。

さて、要求定義書の目的は何か。正解は「要求機能を正確に定義すること」である。ゆめゆめお忘れなきように。