どうやって要求を定義する？
「さて、まず要求定義を行う必要があることと、その目的がわかりました。では、その要求をすべて聞き取りし、定義するにはどうすればいいかしら？」
「…関係する人の1人1人に確認するか、依頼側の担当者にまとめて聞き取りするしかないですよね？」
「それでは、さっきいった暗黙知には対応できそうにないわね」
「…そうですね。そしたらどうするとよいのでしょうか」
「それについては『正解はない』というのが答えね」
「そんな〜、それじゃ何にも解決していなくて、デスマーチ一直線じゃないですか！」
「もちろんそのまま手をこまねいているだけでは、そうなるわ。でも『どうしたら要求を定義できるのか』ってことは、みんなが考えていることなの。その1つの例が『MOYA』よ」
「もや？ 『もやもやする〜』の『もや』ですか？」
「名前の由来はそのようね。このMOYAについては『システム作りのもやっと感を解消するMOYA』で詳しく解説しているので、そちらをきちんと確認しておきなさい」
「は〜い！」
「この要求定義の段階で聞き取りできなかった項目があると、そこが手戻りの原因になることが多いの。確かに『早くシステム開発をはじめてほしい』という顧客からの要求はあると思うけれど、しっかりと準備をすすめるべきね」
図2：確認書で要求定義した情報を共有
要求は定義した。その次は？
「必要なステークホルダーの要求がまとまったら、次は何をすればいいかしら？」
「開発スタート！！！ …質問されるくらいだから、それはないですよね」
「…もちろんよ」
「じゃぁ、えーっと、えーっと、次は…」
「話は聞いたからもうよくて、それが正しいかを確認しなくていいの？」
「あ、そうか。本人たちから要求を聞いたとしても、それで進めていいかは…」
「…気づいた？」
「はい！ それを開発者がみんなで共有しないと！」
「…」
「（がくがくぶるぶる）」
「それはもちろん重要。でもその前にもう1つ」
「…そうでした。そうすると、要求定義に基づいて確認書を作って、えーっと、依頼者側に承認してもらう必要があるんですね」
「その通りよ。どんなに面倒だと思っても、1つ1つ承認してもらってこそ、ドキュメントの意義があるの」
「はい！ こんどこそわかりました！」
「（※ためいき※）ほんとかしら…」
次のページ
