TOPシステム開発> 【楽々デブドックを書こう!】開発☆ドキュン> 第2回:要求分析するドキュよ (3/3)

【楽々デブドックを書こう!】開発☆ドキュン

【楽々デブドックを書こう!】開発☆ドキュン

第2回:要求分析するドキュよ

著者:シンクイット編集部

公開日:2008/02/08(金)

確認・確認・また確認!

「『正しい』ということを確認しないままで開発者側で共有しても、もし違っていたらそこも手戻りになるってこと、わかったかしら?」

「はい。…今思ったんですけれど『みんなで共有』って、もしかして開発者だけでなく、依頼者もまきこんで共有することが重要なんじゃないですか?」

「もちろんその通り。よく気づいたわね。じゃぁなんで開発者から依頼者まで共有する必要があるか説明できる?」

「そうですね…。それは、問題が発生したときに『何が問題なのか』を判断する基盤として、共通の認識が必要だからだと思います」

「その他にもあるかしら?」

「うーんと、例えば開発者側が開発中に疑問を持ったとして、それがどの要求を満たしているかとか、こうすると要求通りに作れるとか、確認しやすくなりますね」

「そうね。それはすごく重要」

「ほかにも、依頼者側も進行状況や説明を聞きながら、どの要求の部分の開発が進められているのかをチェックしやすくなります」

「はい、正解。ここでもっとも重要なところは『お互いが納得してシステム開発を進められる』という基盤を作り出すことよ。そのためにこそ、要求を定義して確認書を作成し、それを承認してもらう必要があるの」

「はい! わかりました!」

図3:情報を正しく共有できていない場合の流れ
図3:情報を正しく共有できていない場合の流れ

次に決めるのは開発までの地図!?

「さて、ここまでの内容をまとめると図3のようになります。今この開発現場は図3の状態を経て、今に至っているわけです」

「…かわいそう(泣)」

「もちろんそれだけじゃないのが、システム開発の怖いところよ」

「それは次に作るべきドキュメントのことですね?」

「その通り。これはあくまで『ゴールの場所』を大まかに決めたに過ぎないの。本当にゴールを決めるためには、そこにたどり着くまでの地図を作らないと」

「ではでは、C言語を使ってこういう構成で…っと」

「こら! それはまだ早いわよ!」

「(がくがくぶるぶる)」

「いきなり何々通りを右に曲がって三軒目、とか書かないように」

「はいぃ〜(泣)」

「最初にするのは、目的地に行くまでにどんな交通機関を使うか、のような大きな流れを決めることよ。何時何分の電車に乗るとか、どういうルートを通るかはもっと先なの」

「よくわかんないけど、わかりました〜」

「(※ためいき※)来週は、その点についてもっとびしびし教えますからね!」

「(がくがくぶるぶる)…わかりました」

ナレーション「よく質問に答えられたというか、まったく答えられなかったというか、難しい状況におかれてしまったA奈。ほんとに学校で何を学んできたというのだろうか! 次週『基本設計の“いろは”ドキュ』でどっきゅドキュ!」 タイトルへ戻る



INDEX
第2回:要求分析するドキュよ
  予想以上の反響で妖精さんはもっとがんばります!
  どうやって要求を定義する?
確認・確認・また確認!