要求の旅は終わらない―開発と並走する「要求管理」：上を目指すエンジニアのための要求エンジニアリング入門（6）（2/3 ページ）
上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。
要求が本当に伝わっているか、確かめたか？
要求側は、開発者が要求をよく理解し、期待のものを完成させてくれるか、いつも不安を抱いている。「そもそも要求が伝わっているのか」という不安をなくしておくことは非常に重要だ。それにもかかわらず、要求者は要求が正確に伝わっているかを確かめることなく、開発プロジェクトでは「甘え」とも思える発言を押し通そうとする傾向が見られる。
要求が伝わっているか確認することなく、ひたすら実現すると信じていると、まったく違ったものが作られてしまったり、想像もしないことが起きて驚くかもしれない。例えば、東証・みずほ証券・富士通の（誤った？）発注問題である。明文化して要求を伝えたかどうかはともかく、生じてはならない事態を引き起こした仕様もれ（？）が要求開発・管理プロセス、開発プロセスをすり抜け、運用プロセスで露見したのである。この事件は、要求にかかわる問題がいかにすさまじいかを知るうえで、まさに好例である。
開発プロセスに入ってからも、要求者は開発者の反応を見聞きして「要求が伝わっていないのではないか」と疑心暗鬼になる。一方、開発者の方は「何を要求されているのか、さっぱり分からないが、取りあえず要求された（と思った）ことをやっておこう。それでよいではないか」という受身の姿勢を取ることがある。この姿勢はなぜか要求者に伝わる。要求者にもともとあった心理的ストレスに、開発者のネガティブな反応が加わり、要求者の疑心暗鬼はさらに大きくなり、負のサイクルが加速し始める。失敗プロジェクトの多くは、このような小さな原因から始まる。
では、要求が伝わったかどうか、どうすれば分かるのだろうか。最初は要求自体、あいまいかもしれない。要求者に多くの課題があることは事実だ。しかし、伝えないと始まらない。受け取る側はどうすればよいか。これを解決するには、要求者が要求内容を幾度となく伝え、開発者は要求内容をよく聞き、それを自分だけではなく、要求者にも分かる言葉で復唱するしかない。もし要求があいまいだったり、あるいは疑問があると思えば、要求者に質問することだ。それでもまだあいまいであれば、さらに質問しよう。質問が多い要求とは、低品質な要求のことである。このような要求は排除しなければならない。このプロセスに手抜きが生じると、きっと後悔する。
このような事情から、要求管理プロセスに入っても要求の品質をコントロールすべきである。要求品質の計測を継続することが肝要だ。
要求者との意思疎通を促し、要求の品質を確保しやすくするために、開発者はヒアリングやプレゼンテーションのスキルを身に付けることが望ましい。しかしそれ以上に、要求者に食い付いて要求を発掘し尽くす姿勢が重要だ。こうした姿勢さえあれば、ヒアリングやプレゼンテーションがいまひとつだとしても、それ以上の実力を獲得することが可能であろう。
要求が伝わっても、実現できないことはある
よく聞いた結果、あいまいさがなくなった。しかし、その内容を技術的に実現することが困難な場合、あるいは自分のスキルでは実現できないといった場合、どうすればよいか。
この場合、上司に誠実に伝える、あるいは丁寧に断る、別の方法を考え出すなどの対処が直ちに必要となる。自分のスキルでは困難なことが予想されれば、上司に助けを求める必要があるだろう。一般に、提供できそうもないものを引きずると、後悔につながる。さらに、できそうもないことを開発者が引きずっている事実に上司や顧客が気付かなければ、プロジェクトは破たんするほかない。
このような事態を見過ごさないために、要求者は（あいまいかもしれない）要求を受け取った開発者に、要求が正確に伝わっているか、開発者が要求者に分かる言葉で要求を復唱し説明できるか、確かめなければならない。もし開発者が復唱できなかったとすれば、要求者は開発プロセスの冒頭で、早くも自分の要求が実現しないことを覚悟しなければならない。実現に期待が持てれば、今度は要求の実現過程を追跡しなければならない。
契約にこだわる
要求者と開発者の間には、要求に対する思い、意思疎通力、不備の是正に対する姿勢などに差異がある。だから、契約を明文化することにこだわる必要がある。
前回、「擦り合わせ」について言及した。擦り合わせは日本的な言葉遣いである。契約（書）とどう違うのかは、ここでは取り上げないことにしよう。しかし、当事者間ではっきりさせるべきことをよくよく尋ね合い、疑問を解消し、納得したことを記録に残すことは、誰もが必要とする。もし要求が実現しなかった場合、互いにどうすればよいかまで擦り合わせたことがあるだろうか。
両者が納得できる要求と成果物の授受を確実に行うプロセスとして、例えば、「共通フレーム2007（参考：共通フレーム - ＠IT情報マネジメント用語事典）」で記載されているような中立的なプロセスを、要求者と開発者の間で納得し、適合させて役立てることができるかもしれない。しかし、このプロセスが役立つとしても、要求を明確にしていなければならないことには何ら変わりはない。
その要求は着実に実現しているか
要求する側もされる側も、危うい船出をする。目的地にたどり着かないかもしれない航海である。予定の工数を費やしても、航路を誤れば目的地に着くことはない。だから、目的地に近づいているか絶えず確認しなければならない。そうしなければ、一生懸命にかじを取っているつもりでも、漂流しているのと同じである。また、現在地から目的地までたどり着くために十分な燃料・リソースが残っているかを知らなければ、大海原で日干しになってもやむを得ない。
要求者には通常、開発者の内部事情が分からない。だから、文書で納期やコストを決めることが必要なのである。開発者も実現を危ぶむのであれば、安易に契約したりせず、事前にリスク対策を立てておかなければならない。
開発プロセスに入って以降、要求が着実に実現しているかを確認する主要な手段は「レビュー」と「テスト」である。しかし、それ以前に、要求がどのような変遷を繰り返して最終的な成果物に変わるのかを追跡できなければ、できたものが要求を実現したものか、はっきりしない。
開発プロセスでは、次々と中間成果物の作成に追われるため、開発プロセスを終了時点からさかのぼって考えることが少ない。しかし、「要求を実現する」と前もっていうためには、終了時点で完成するものがどのようなプロセスを経て完成するのか、開発着手前に説明できなければならない。つまり、成果物を完成に導くプロセスエンジニアリングが必要となる（図2）。このプロセス説明を「なるほど」と思えて初めて、要求者は開発者に要求実現を委ねることができる。
こうして開発プロセスが進む。成熟した開発組織では、過去の類似プロジェクトで実施したレビューやテストの結果から、レビューやテストをどれくらい実施すると一定の品質が確保できるかといった、定量的に測定された経験的情報を持っている（ただし、要求についても同様の定量的情報を持っていることはまれである）。過去の経験を生かすことは、類似プロジェクトではとりわけ大切である。類似プロジェクトと比較し、悪い結果であれば一次的な原因から根本原因まで掘り下げてみることが必要である。
Copyright © ITmedia, Inc. All Rights Reserved.