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




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

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

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

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

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

予想以上の反響で妖精さんはもっとがんばります!

システム開発をスムーズかつ手戻りを発生させずに進めるには「開発ドキュメント」の存在が欠かせない。2月の特集「楽々デブドックを書こう!」では、さまざまな視点から、この開発ドキュメントについて解説&考察している。

デスマーチ一歩手前の状況にある開発現場では、「ふっ」と意識が遠のいたと思ったら見たことのないコードが書かれていたり、バグが忽然と消え去っていることがないだろうか。これはもちろん「妖精さん」たちの仕業なのである。

本連載「開発☆ドキュン」では、あなたが意識を失っている間に開発ドキュメントを書いてくれている「開発ドキュメントの妖精さん」であるA奈ちゃんとB乃ちゃんの2人の会話を追いかけながら、開発ドキュメントの基本について学んでいる。

知らない間に開発ドキュメントを書いてくれる、といっても、担当する妖精さんのスキルによっては逆にとんでもない事態を引き起こし兼ねない。そういう意味では、今までは学校で勉強していただけで、はじめて現場にでてきたA奈ちゃんは、まだまだ心もとない段階だ。

「…それは、あまりな説明かも。A奈は泣いちゃいますよ」

というわけで、頼りないA奈ちゃんには先輩妖精のB乃ちゃんがサポートとして同行し、きちんと現場指導をしてくれているのである。

「B乃です。ふがいない後輩共々、よろしくお願いします」

「開発ドキュメントって何ドキュか?」では、開発ドキュメントはなぜ必要で、どんなことに役立つかについて、A奈ちゃんといっしょにおさらいした。続く今回は、開発フェーズの中で、まず最初に記述するべき「要求定義」のドキュメントについて解説する。

図1:要求定義の目的
図1:要求定義の目的

第2話「妖精さんがあなたのキモチをゲットする!」

深夜3時、とある会社の開発部では、デスマーチまっしぐらな状況の中で開発者たちが「充電切れ」のように、暫しの休息をとっていた。

「…第2、第3のこんな惨状を生み出さないためにも、私たちの力が必要なんですね」

「そうよ、A奈。開発ドキュメントとはいえない程度のテキストで作業は進まない。だからきちんとしたドキュメントを作ることこそを、私たちがやるべきなのよ」

「まず必要なのは、開発を依頼する人、つまり顧客の要望を聞きだすこと、ですね?」

「そう。そして作るべきドキュメントが『要求定義』ね。この目的はどういうものかしら?」

「はい、まとめると図1のようになります。ここで重要なのは3つです。まず、顧客の求めていることを書面にすること。そして、開発するシステムを利用する組織の形態を決めること。そして顧客が理解していない内容をはっきりとさせることです」

「ちょっとまって。ここでいう『顧客』は、システム開発を発注した人、ということかしら?」

「いえ、開発したシステムの利用に携わる人たち、つまり『ステークホルダー』を含める必要があります」

「はい、よくできました。では、このフェーズの最大のポイントはどこかしら?」

「えーっと、どういうシステムが必要か網羅する必要があります」

「そうね、それは正しいわ。でも開発を依頼する側は、本当に必要なことがすべてわかっているのかしら」

「…えーっと、自分たちでもわかっていないこと、もしくはわかってて当然だと思っていて明示しないものもあります」

「そう。それが『暗黙知』ね。暗黙知をきちんと導き出さないと、本当に必要なものがすべてそろっているとはいえないわね」

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

次のページ



この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。

INDEX
第2回:要求分析するドキュよ
予想以上の反響で妖精さんはもっとがんばります!
  どうやって要求を定義する?
  確認・確認・また確認!
開発☆ドキュン
第1回 開発ドキュメントって何ドキュか?
第2回 要求分析するドキュよ
第3回 基本設計の“いろは”ドキュ
第4回 詳細設計はどうするドキュか?
第5回 テスト関連も忘れちゃだめドキュ!