アンジャッシュのすれ違いコントというのがあります。

お互いが誤解をしたまま話が進んでいき小気味いい笑いを誘いますね。

しかしこれが笑えるのはコントだから。現実世界、特にビジネスの世界でこういった「すれ違い」が発生してしまうと取り返しがつかなくなってしまうことがあります。

このすれ違いを防ぐ方法として、IT業界にいいヒントがありそうです。それが今回取り上げる「要求工学」です。
ソフトウェア開発は誤解のオンパレードです。

ソフトウェア開発は「受託開発」という形で進む場合、次のような流れで進みます。

—--------
お客：こういったアプリほしいなぁ

A社営業：あ、それならうちで作れますよ

お客：え？本当。こういった感じでいい感じに作ってほしいんだ。

A社営業：なるほど、開発を連れてきます。

お客：開発さん。「こんな感じでいい感じのもの」をつくってほしいんだ。

A社開発：それでは「こういった感じの機能」はどうでしょうか。これなら納期はこのくらいで…

お客：うん、よろしく頼むよ

—--------

この時にポイントなのが、「まだできていないものを売る」ということです。仕事を受けた段階でまだお客様は実際の製品を見ていません。それでもA社開発はお客の「こんな感じでいい感じのもの」ということをヒアリングして、「こういった感じの機能」と落とし込んである程度お客様と合意をとる必要があります。

この時にお客は開発のプロではないので「こんな感じでいい感じのもの」というふわっとした事しか伝えることができません。
だからと言って、ここでアンジャッシュのようなすれ違いコントが発生しては困ります。実際に完成してから「こんなつもりではなかった！」と言われてしまったら、最悪すべて作り直しになってしまうかもしれないですし、契約破棄でただ働きということも起こりえます。

これは絶対にさけないといけません。

その時にしっかり定義するための手法として今回から紹介する「要求工学」というものが研究されてきたようです。
システム化をするというと、なんとなく「しっかり・かっちり」定義していくイメージがあります。なので、今回はその「しっかり・かっちり」しているであろう要件定義を参考にして、そのほかの分野でも生かすことができないかと考えていきたいと思います。

要求工学とは

「要求工学」とは ソフトウェア開発における、ユーザー要求を仕様化するプロセスについての技術および研究のことをさします。

国際要求工学委員会（International Requirements Engineering Board, IREB）というところで研究が進んでいる様です。

要求のずれは次の3点から発生すると言います。

● ステークホルダによる、多くのことが自明であって明示的に主張する必要がないという間違った前提
● 経験と知識の差異から生じるコミュニケーション問題
● システムを生産的かつ迅速に開発するというプロジェクトへの顧客からの圧力

どれもイメージできるかと思います。

「前提」は思い込みとして強く働きます。例えば略語。業界によって同じ略語でも意味が異なるものはたくさんあります。

「CS」と聞いたときに何を思い浮かべるでしょうか。
「Customer Satisfaction：顧客満足度」としてつかっている場合もあるかもしれないですし、「Computer Science：コンピューターサイエンス」かもしれません。はたまた「CS放送」の略として使っているかもしれませんし、「Customer Support：カスタマー・サポート」かもしれません。とても誤解を生みやすいです。
私にとって「MTG」というとも「ミーティング・会議」が先に連想されますが、「マジック：ザ・ギャザリング(https://mtg-jp.com/)(カードゲーム)」が浮かぶ人も居るでしょう。

こういった前提条件や社内で一般的に使っている言葉を前提としてしまった場合、誤解が生じやすいのは自明かと思います。

業界が異なったりすると、同じ意味で使っている単語でも前提のようなものが異なったりします。
システム開発をするうえで「バグ」「不具合」というのはよくないものですが、スマホのソシャゲーと、自動車の制御システムの「バグ」「不具合」は意味合いが変わってきます。
前者はアップデートで修正すればいいですが、後者の場合、もし「特定条件でブレーキとアクセルが逆に動作する」といった「バグ」「不具合」の場合、最悪人命にかかわってくるでしょう。

経験と知識の差異もありますよね。初心者とベテランでは会話かみ合わないというのはよくあることかと思います。

顧客からの圧力はいやですが、追いつめられると冷静な判断ができなかったり、要求が詰め切れなかったりということが原因でギャップは発生してしまいそうです。

こういったことをどうやって防げばいいのでしょうか。
これから何度かに分けて説明していきます。

何を定義しないとシステム化できないのか

システム開発が目的では無いですが、それでもシステム開発現場で使われている考え方なので、多少はどのようにシステムが設計されていくかを知っておく必要があるかと思います。

「インプット」→「システム」→「アウトプット」と簡略化することができます。

• インプット
  システムはインプットをトリガー(きっかけ)として動きだします。このインプットは様々な事があります。「タッチパネルに触れる」もインプットですし、「ボタンをクリックする」、「特定の時間になる」こういったことをトリガーとして、システムが動作します。

• システム
  インプットされた情報をもとにシステムが何か処理をします。「購入ボタン」が押されたらそれまでにショッピングカートに入力されていた商品を購入処理をして、クレジットカード会社に問い合わせを行い…といった具合です。

• アウトプット
  システムの処理の結果は何らかの形でアウトプットされます。先ほどの購入ボタンの場合「購入が完了しました」と画面上に表示してくれるでしょう。文字情報だけではありません。「音楽アプリ」の再生ボタンを押した場合、「音楽が流れる」という形でアウトプットされます。

「インプット」→「システム」→「アウトプット」
「購入ボタンを押す」→「システムがいい感じに処理をする」→「買い物が完了する」
「特定の曲の再生ボタンを押す」→「システムがいい感じに処理をする」→「曲が流れる」
「特定の時間になる」→「システムがいい感じに処理をする」→「目覚ましのアラームが鳴る」

こういった形で処理が行われて行きます。この「いい感じに処理をする」という部分に齟齬が発生したら大変ですよね。「いい感じに処理をする」という「いい感じ」が私とあなたでは異なる可能性が大いにあります。この齟齬を
こういった部分をしっかり定義していくことがシステムを作っていく上では必要になります。

要求工学の基本プロセス

要求工学は次の4つのプロセスと、1つの管理項目で定義されています。

• 要求抽出

• 要求分析

• 要求仕様化

• 要求確認

• 要求管理

相手のニーズを要求抽出でしっかりと引き出し、分析していきます。その後に仕様という形で文面に起こし、確認をしてもらう。

この時に起こりやすいのが「言った・言わない」という問題です。私たちも日常で経験しますよね。派生形として「そんなつもりで言ったわけでは無い」でしょうか。
人間は忘れやすい生き物ですし、記憶は簡単に捏造します(本人の意志にかかわらず)。そのためにも要求はしっかりと管理しておく必要があります。

それぞれの項目について、しっかり確認してきましょう。

参考：
・要求工学知識体系(REBOK)概説
　https://www.ipa.go.jp/files/000005375.pdf
・要求開発の基礎知識　要求プロセスと技法入門
　https://nextpublishing.jp/book/10544.html