すべての始まり＝「要求」を抽出する：上を目指すエンジニアのための要求エンジニアリング入門（2）（1/3 ページ）

上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。

[前田卓雄，＠IT]

　IT／ソフトウェア業界は厳しい時代を迎えており、われわれは自分なりに生き延びる戦略を再構築し実践する必要がある――そう前回、述べた。その出発点が、顧客の要求を認知・理解し、それらの要求に的確に応えることである。すなわち、「要求エンジニアリング」に取り組むことである。

　現在はあいにく、不況に突入したばかり。「そんな余裕はない」という読者が多いかもしれない。しかし、不況に適した要求（例えば、品質が確保された低価格のITやソフトウェア、あるいはすぐに使えるシステムやソフトウェアに対するニーズ）があるだろう。要求の中身は時代や環境とともに変化しているのである。しかし、要求をどうとらえ、どう対処するか、という「要求への接し方」自体が急変することはない。上流工程を目指す技術者として、ぜひ身に付けていただきたい。

要求は至るところに転がっている

　困難な時代には要求が増え、しかも至るところに点在するようになる。また、将来に向かって要求は限りなく増加する。見方を変えれば、要求をとらえることは、それほど難しいことではない。読者自身も問題を抱えているだろう。手始めに、自分の問題を挙げてみよう。それだけでも随分と参考になる。将来について思いをめぐらせてみよう。足りないものや要求を、あなたはいくつも発見することになるだろう。

　わたし自身、仕事や将来を探さなければならない状態だ。問題はたくさんある。例えば、

• 新しい顧客はどうすれば獲得できるだろうか
• 顧客にはいったいどんな要求があるだろうか
• どうすれば要求を的確につかむことができるだろうか
• 顧客を納得させるような提案ができるだろうか（力量はどうか）
• 顧客が要求する品質や納期、費用対効果を達成できるだろうか
• 競合他社に打ち勝てるだろうか
• 与えられた予算で大丈夫だろうか
• 必要な時期に技術者を確保できるだろうか
• 自分自身の将来設計や能力獲得計画と整合しているだろうか

などである。

　恐らくあなたもこうした問題を抱えているだろう。問題があること、問題を認識し、理解しようとすることは素晴らしいことだ。ただ問題に打ちひしがれるのではなく、もっと積極的に問題を集めよう。「問題は宝の山」である。

　問題がなぜ「宝」に変わるのか。問題自体はうっとうしいものだが、見方を変えよう。その問題の解決方法が見つかれば、あるいは解決の結果を喜んでくれる人がいれば、やりがいにつながる。問題を見つけることは、いってみれば「宝の山」を発見するようなものだ。自分らしい問題をつかまえよう。そして、宝の山に変えよう。

参考：「バグをなくす」には、「バグのない世界」を文章で示せ ― ＠IT自分戦略研究所

要求は不満・不足・問題・トラブル・不愉快なこと・期待はずれ……の裏返し

　われわれは誰しも不満・不足・問題・トラブル・不愉快なこと・期待はずれなことなどを抱えて暮らしている。仕事にも、会社にも、顧客にも、出荷済みの製品にも、いくつもの問題がある。また、新しいことを始めようとすれば、何か困った事態が生じる。予期していた事態もあれば、予想外の事態にいらだつこともあるだろう。つまるところ、不満や問題が生まれる。問題は常に生まれ、なくなりはしないのである。よって、問題との付き合い方に工夫が必要である。問題のとらえ方次第で、新しい、ポジティブな自分が発見できるかもしれない。

　「問題を集めること」と「要求を集めること」は似通ったプロセスを持つ。しかし、ただ不満や問題を集め、文句をいっているだけでは「要求」は生まれない。「問題」と「要求」の違いは、解決したいという意欲、解決に対し犠牲を払ってもよいという覚悟につながっているかどうかだ。問題に埋もれるのではなく、解決への意欲を示すことが大切だ。自分の問題として受け止め、解決を模索する当事者意識が欠かせない。この意識や意欲があれば解決策が見つかる。問題や解決策を生み出す方法は、世の中にはいくつもある。解決策が見つかれば喜ばれるし、解決策が実現できれば対価を支払うようになるだろう。実にシンプルである。

　ここからは、「解決意欲のある問題」を「要求」と呼ぶことにしよう。今回は「要求」の収集がテーマである。要求収集は要求エンジニアリングの最初のプロセスであり、一般に「要求抽出（Requirements Elicitation）」と呼ばれている。