第2回：要求分析するドキュよ (2/3)

どうやって要求を定義する？

「さて、まず要求定義を行う必要があることと、その目的がわかりました。では、その要求をすべて聞き取りし、定義するにはどうすればいいかしら？」

「…関係する人の1人1人に確認するか、依頼側の担当者にまとめて聞き取りするしかないですよね？」

「それでは、さっきいった暗黙知には対応できそうにないわね」

「…そうですね。そしたらどうするとよいのでしょうか」

「それについては『正解はない』というのが答えね」

「そんな〜、それじゃ何にも解決していなくて、デスマーチ一直線じゃないですか！」

「もちろんそのまま手をこまねいているだけでは、そうなるわ。でも『どうしたら要求を定義できるのか』ってことは、みんなが考えていることなの。その1つの例が『MOYA』よ」

「もや？　『もやもやする〜』の『もや』ですか？」

「名前の由来はそのようね。このMOYAについては『システム作りのもやっと感を解消するMOYA』で詳しく解説しているので、そちらをきちんと確認しておきなさい」

「は〜い！」

「この要求定義の段階で聞き取りできなかった項目があると、そこが手戻りの原因になることが多いの。確かに『早くシステム開発をはじめてほしい』という顧客からの要求はあると思うけれど、しっかりと準備をすすめるべきね」

図2：確認書で要求定義した情報を共有

要求は定義した。その次は？

「必要なステークホルダーの要求がまとまったら、次は何をすればいいかしら？」

「開発スタート！！！　…質問されるくらいだから、それはないですよね」

「…もちろんよ」

「じゃぁ、えーっと、えーっと、次は…」

「話は聞いたからもうよくて、それが正しいかを確認しなくていいの？」

「あ、そうか。本人たちから要求を聞いたとしても、それで進めていいかは…」

「…気づいた？」

「はい！　それを開発者がみんなで共有しないと！」

「…」

「（がくがくぶるぶる）」

「それはもちろん重要。でもその前にもう1つ」

「…そうでした。そうすると、要求定義に基づいて確認書を作って、えーっと、依頼者側に承認してもらう必要があるんですね」

「その通りよ。どんなに面倒だと思っても、1つ1つ承認してもらってこそ、ドキュメントの意義があるの」

「はい！　こんどこそわかりました！」

「（※ためいき※）ほんとかしら…」

次のページ